Working in the 1C web client

Working in the 1C web client

Open it with browser_open_1c — never with a login you ask for

browser_open_1c opens this workspace's 1C base in a browser session already signed in. Plank fetches the 1C sign-in from the customer's connector at that moment and types it itself; you never see, receive or handle the password, and you must never ask the user for it or try browser_request_user_login for a base it opens.

A base with no connector (every 1cfresh.kz base, for one) has no web-client connection, and browser_open_1c answers with a sentence saying so. Do not retry it. Open the base's own URL with browser_request_user_login and ask the person, in one sentence, to sign in themselves in that tab — you still never ask for or see the password. Everything below applies once the base is open.

• Give it an integration_label (e.g. 1C). If no session has that label it is created, and the user gets a tab where they can watch.
• It answers with the base's title and whether it signed in now or was already signed in. Then drive 1C with browser_snapshot, browser_click, browser_type as usual.
• If it says the workspace has no 1C web-client connection, tell the user it is set up by the Plank team — do not improvise a login.
• If it says the connector did not answer, the customer's machine or its VPN is down. Say so; retrying in a loop does not help.

Use the web client only for what OData cannot do

OData is faster, scriptable and verifiable — use it first (Working with 1C over OData). The web client is for the few things OData refuses:

«The kit has no command for it» is not one of them. Creating or editing catalog items (nomenclature, counterparties, contracts) and documents is ordinary OData writing — when no kit script does it, write the script yourself (scripts/1c/odata/_odata.py: read first, dry run, identifier check against duplicates, one object at a time, re-read after). Do not open the web client for it and do not ask the person whether you may write a script.

• Merging duplicate catalog items (nomenclature, counterparties). Over OData a document's row accepts no change of item on some configurations, posted or not, and a register's records cannot be rewritten at all (the record set reads, PATCH answers 400, PUT 405, POST only creates). 1C's own processing replaces a duplicate everywhere — documents and register records — in one step.
• Reading a form 1C does not publish over OData.

Never believe the screen. Every write you make here, prove afterwards with an OData read.

Merging two duplicate items — the measured procedure

One pair at a time. The user confirms every pair before step 7.

1. Open the processing. Администрирование → Обслуживание → expand Корректировка данных → Поиск и удаление дублей. Close the start page first if a section list does not appear.
2. «Искать в». Press «…» beside the field and pick the catalog in the chooser «Область поиска дублей» — the exact row (for nomenclature: «Номенклатура», not «Номенклатура ГСВС»), then «Выбрать». Trap: typing the name into the field shows it but does not select it — the filter dialog then still opens for the previous catalog. You know it took when the «Сравнивать» rule changes (for nomenclature: «Наименование совпадает по похожим словам»).
3. «Отбирать» — exactly the two items. Press «…» → «Правила отбора …». On the row «Ссылка» / «В списке», open the value, untick any stale values, then type the code of each item into the value cell and tick the suggestion whose name is the item you mean — a code can bring back two unrelated cards (see «Building the merge list» below), so the code alone is not a selection. Trap: the «+» in that dropdown opens «… (создание)» — a form for a NEW card. Close it without saving. Press «ОК»; the field must read «Ссылка В списке '<item>; <item>'».
4. «Найти дубли >» only searches. While «Прервать» is shown it is still counting usages across the base — wait.
5. Check which one is the original. 1C marks the item with the most usages as the original (arrow). Select it, press «Открыть» and read its Code. If it is not the item you mean to keep, select the right one and «Отметить как оригинал». Close the card without saving.
6. Snapshot before writing. Over OData, count every row that references each of the two items (every entity set whose field references this catalog; for a composite field use cast(guid'…','Catalog_X') without a namespace prefix). A set that refuses to be read is unknown, not zero — say so.
7. «Удалить дубли >» — after the user's go-ahead. It replaces the duplicate with the original everywhere and then disposes of the duplicate the way the customer chose (next section): by default it marks it for deletion, which can be undone; some customers ask for the duplicate to be deleted outright instead.
8. Prove it. Repeat the OData count: the duplicate must have 0 rows, the original the sum of both before, set by set; documents that were posted are still posted. If the duplicate was marked, its DeletionMark is true; if it was deleted outright, reading it by Ref_Key finds nothing.
9. If 1C says «могли возникнуть дубли в других списках», count the named list for the two items before and after. On the live base this was first measured on, it was a false alarm — but check, don't assume.

Two items that share one code cannot be told apart in step 3 by typing the code — stop and ask how to pick them.

Mark or delete — the customer decides, in writing

1C can dispose of a merged duplicate two ways: mark it for deletion (the default above — reversible, and the mark itself is a trail of what was merged) or delete it outright once every reference has moved. Which one is the customer's decision, never a default you pick. A customer may ask for outright deletion — one pilot did — and then:

• Test base first. Run the approved list on a test copy, let the customer check it (stock balances by warehouse before and after, a few documents that carried the duplicate, their own reports), and only after their «ок» run it on the live base.
• A backup of the live base before you start — made by their administrator. An outright deletion cannot be undone.
• Keep your own trail. Nothing marked remains to show what became what, so before each merge save the duplicate's card (every field) and the list of documents that referenced it.
• Find the setting on the test base. Where the processing asks how to dispose of the duplicates depends on the configuration version; locate it there, not on the live base.
• Never «Удаление помеченных объектов» wholesale. A catalog usually holds items somebody else marked; delete only the duplicates on the approved list.

Building the merge list

A list of pairs is what the customer approves, so a wrong row is approved too. Three things that went wrong on a real list, each caught by the customer's accountant rather than by us:

• A code is not an identity. In one 7,380-card nomenclature folder, 27 codes each belonged to two unrelated cards — «Кнопки» and silicone spaghetti tongs under one code, a freezer and a vape device under another. A list resolved by code put tongs and a ruler under «Кнопки»: 6 of 219 rows were wrong. Key the list by Ref_Key; show the customer code + name + group for both cards; and flag every row whose code another card also carries, so the person doing step 3 picks by name.
• Re-resolve against the base as it is now. A candidate list built before a clean-up can point at cards whose names have since changed — two «Песок очищенный» candidates had become «Песок в мешках 20-25 кг» and a road reagent. Re-read every card just before publishing the list and drop rows whose names no longer describe one product.
• One row per duplicate. The same card can reach the list from two sources (a pair list and a later sweep); deduplicate by the duplicate's Ref_Key, and never let a card that is being deleted be the one kept in another row.

Things that are not yours to decide

• Which of two items to keep, when their groups, units or descriptions differ — ask.
• Any item that is fuel, or anything the user has said not to touch.
• Whether a merged duplicate is marked or deleted outright — the customer's, in writing (above).
• Physically deleting marked items («Удаление помеченных объектов») — that is the customer's own decision, never yours.