---
name: cleverence-mslx
description: >-
  Read, understand and safely edit Cleverence Mobile SMARTS (Склад 15 / Магазин 15)
  configuration stored as .mslx files - the XML algorithm graphs that drive handheld
  terminal (ТСД) workflows in 1C integration projects. Use this skill whenever the task
  touches Cleverence / Mobile SMARTS / "Клеверенс" / ТСД algorithms, .mslx files,
  document types or operations (обработчики) on the terminal, menu/scan/КМ logic on a
  scanner, calling 1C online from the TSD, or "почему скан не срабатывает / действие не
  найдено / кнопка не работает" on a handheld - even if the user does not say ".mslx"
  explicitly. Covers the action graph, transition chaining, OperationAction parameter
  mapping, the online 1C call mechanism, marking-code (КМ) line operations, and the
  CL_-copy rule for not breaking vendor operations on update.
---

# Cleverence Mobile SMARTS (.mslx) configuration

Cleverence "Склад 15" / "Магазин 15" runs handheld-terminal (ТСД) logic as **algorithms**:
a directed graph of **actions**. The Mobile SMARTS Panel stores each document type and
each operation as a single-line XML file with the `.mslx` extension. Editing these by eye
is error-prone; the failures are almost always *broken transitions* or *wrong variable /
field names*, not XML syntax. This skill encodes how the graph works and how to change it
without breaking it.

## Mental model

- **DocumentType** `.mslx` (под `Documents/DocumentTypes/...`) - a whole terminal workflow
  (e.g. "Сборка контейнера"). Its root is `<DocumentType>`.
- **Operation** `.mslx` (под `Documents/Operations/...`) - a reusable sub-routine called by
  documents or other operations. Root is `<Operation>`.
- Both contain `<Actions>` - the ordered list of graph nodes.
- The Panel and the MS Server work off a **server database**, not necessarily the git
  working copy. Editing a file on disk changes nothing until the config is transferred to
  the server (Сервис -> Сравнение конфигураций, or copying into the live DB + restart).
  **If the Panel shows old behaviour after your edit, suspect a stale/never-transferred
  file before suspecting your change.**

## The single most important rule: CL_ copies of vendor operations

Vendor operations (typical Cleverence обработчики, usually under `Operations/EN/...`,
`Operations/Основные/...` etc.) get **overwritten on Cleverence updates**. Editing them
directly is like editing a vendor 1C extension - your change disappears on the next update.

So:

| What | Rule |
|------|------|
| Our own document type (e.g. «Сборка контейнера») | Edit **in place**. Do not clone. |
| Our own operation (in the project root `Operations/`) | Edit **in place**. |
| A **vendor/typical** operation we need to change | Make a copy `CL_<Name>` (placement below), edit the copy, and in the caller switch `operationName` to `CL_<Name>`. |
| A new operation | Prefix `CL_` (latin). |

Copy only the operations you actually change. If the change is inside a nested vendor
operation, copy that one and repoint its `CL_` parent at it - do not clone the whole chain.

**Where to put a CL_ copy.** Put it in your own branch of the operations tree -
`Documents/Operations/` (the root) - **not** inside the vendor subfolder it was copied from
(`Documents/Operations/EN/...`). The Panel resolves a call by the operation's `name`, not by
its file path, so a `CL_<Name>` in `Operations/` fully serves callers that use
`operationName="CL_<Name>"`. Keeping the copy in the vendor subfolder (a) puts it among files
that get overwritten on update, and (b) risks **two files with the same `name`** if the Panel
later re-exports the operation into the root - a duplicate that conflicts on import. So: after
creating/moving the copy to `Operations/`, delete any stale same-`name` file left in the
vendor subfolder.

## How the action graph flows

Every action decides where control goes next. Read `references/graph-mechanics.md` for the
full rules; the essentials:

- **Sequential fall-through**: an empty `nextDirection=""` means "go to the next action in
  document order". This is why the **physical order of `<Actions>` matters** - inserting an
  action in the wrong place silently changes the flow.
- **Named transitions** point to an action's `name`. Resolution is **case-insensitive**
  (a button direction `«Просмотр факт»` resolves to action `name="Просмотр Факт"`). So if a
  transition "is not found", the cause is almost never letter-case - it is a genuinely
  missing action (often a stale file on the server).
- **ConditionAction** branches with `yesDirection` (TRUE) and `noDirection` (FALSE); empty
  means fall through to the next action.
- **QuestionYesNoAction** branches with `yesDirection` / `noDirection`.
- **QuestionAction** (a menu) has three parallel arrays - `Buttons`, `ButtonTexts`,
  `ButtonDirections` - matched by index. They **must stay the same length**; a button whose
  `ButtonDirection` names a non-existent action throws "действие для перехода не найдено".
- Built-in targets that are not action names: `back`, `return`, `abort`, `exit`, `home`,
  `process zero`, and `""`.
- **`indent` = visual nesting in the Panel tree, not control flow.** Each action carries an
  integer `indent`. Logically subordinate actions (a `process zero` branch under the scan
  window, the body executed inside a condition) must have `indent` **greater** than their
  parent - they appear *shifted right* in the Panel algorithm tree. Flow is driven by
  `nextDirection`/named transitions, **not** by `indent`; but leaving a flat `indent=0` on
  nested actions renders the structure wrong/flat in the Panel and is a real defect to fix.
  When you copy or hand-edit a `.mslx`, **preserve/set `indent`** on the nested actions (it is
  easy to lose it on a copy). `mslx_inspect.py` indents its dump by this attribute, so a flat
  structure shows up at a glance.

## Calling another operation: parameter mapping

`OperationAction` invokes a sub-operation by `operationName` and maps variables explicitly:

- `InKeys` / `InValues` - the sub-operation's variable name / the caller's expression.
  Expressions are wrapped in braces: `InValues = {GO.GetBarcodeData(ScannedBarcode)}`.
- `OutKeys` / `OutValues` - the sub-operation's result variable / the caller's variable.

Many shared variables (`BarcodeData`, `IdentificationCode`, `CurrentItem`, ...) are global
to the session, so some calls pass nothing and rely on globals. When in doubt, look at how
the operation is already called elsewhere (grep for its `operationName`) and copy that
contract verbatim - guessing variable names is the #1 cause of "scan does nothing".

## Calling 1C online from the terminal

To run a 1C function live during a scan, use an `InvokeMethodAction` against the 1C
connector. The function name you pass must be a **method of the integration data processor**
(вендорская `ИнтеграционнаяОбработка_*`), and it must return a `ТаблицаЗначений` (not JSON).
The full mechanism, the thin-wrapper pattern (with vendor markers), and what is *not* an
online call (the "Список произвольных кодов" is field mapping, not a call) are in
`references/online-1c-call.md`.

## Marking codes (КМ / КИЗ) and document lines

The marking code on a document line lives in `Item.МаркаИСМП` (and `Item.ГрупповаяУпаковка`
for aggregates) - **not** `Item.Марка`. You match against the recognised `IdentificationCode`,
which is produced by `GetIdentificationCode` from `BarcodeData`, not against the raw scanned
string. Reuse the ready operations (`FindMCInDocument`, `DeleteCurrentItemFromDocument`,
`IsMarkingCode`) instead of hand-writing queries. See
`references/km-and-document-operations.md`.

## Editing methodology (do this, in this order)

1. **Inspect first.** Run the bundled tool to see the real graph and current links:
   ```bash
   PYTHONIOENCODING=utf-8 python scripts/mslx_inspect.py "<file>.mslx"
   ```
   It dumps every action (type, name, operationName, directions, In/Out mapping) and then
   validates: XML well-formedness, that every transition resolves, and that menu button
   arrays are balanced.
2. **Find the proven pattern.** Before writing new graph logic, grep the existing operations
   for one that already does it and copy its action structure and variable contract. The
   codebase almost always has a working precedent (scanning, finding a line, deleting a line,
   confirming, calling 1C). Reusing it beats inventing.
3. **Make point edits.** `.mslx` is one long line; use exact-string Edit, keep ids stable
   where you can, and keep the action order consistent with the fall-through you intend.
4. **Re-inspect.** Run `mslx_inspect.py ... --validate` again. Zero dangling transitions and
   balanced button arrays is the bar before you hand it back.
5. **Remember the transfer step.** A validated file on disk is not yet live - it must reach
   the MS Server. Tell the user to transfer it and to confirm by checking that a changed
   `operationName` (e.g. `CL_...`) shows up in the Panel.

## When a scan "does nothing" on the TSD

Before suspecting the graph, rule out the input itself - the graph is usually innocent:

- **`Ctrl+V` into the debugger window is NOT a scan event.** A scan window catches input via a
  `KeyToAction barcode="{any}"` KeyJump, which fires on a *scan event*. Pasting text into the
  field with `Ctrl+V` is keyboard input - it does not trigger the `barcode` KeyJump, so
  "nothing happens". Use the debugger's *emulate-barcode* function (a dedicated barcode input),
  or a real scanner.
- **DataMatrix loses its GS separators on copy-paste.** A ЧЗ marking code (DataMatrix) contains
  the GS control char (ASCII 29). Clipboard/Notepad strips it, so even if the input lands,
  `GO.GetBarcodeData()` won't recognise the КМ structure. Only a real scanner (or the emulator)
  preserves GS.
- **The config may not be on the server.** The debugger runs the server copy; an edited file in
  the repo is not live until transferred (Сервис -> Сравнение конфигураций).
- Only after these: check the graph. Confirm the scan window has `KeyToAction barcode="{any}"`
  pointing at the scan-handling action, and (with a breakpoint in the debugger) whether that
  action is even reached. If it is reached but bails out, inspect `BarcodeData` - the code was
  read but not recognised.

## Linking a TSD document back to its 1C document (dedup on completion)

When a TSD document must, on completion, update an **existing** 1C document instead of creating
a new one, the back-link is a Panel **setting**, not graph logic: in the БП open *"Настройка
загрузки полей шапки документа"* and the rule whose target (приёмник) is the `Ссылка` field,
match mode **Поиск по GUID**. The **source attribute** of that rule is a classic trap:

- **`Идентификатор`** - the MS document's own Id. This is the **correct** source for dedup. It
  is stable for one TSD document and is exactly what the vendor completion code resolves the 1C
  reference from (`ШапкаДокумента.Ид`). Use this.
- **`Идентификатор исходных документов`** (`ИдИсходныхДокументов`) - **wrong** for the back-link
  of a TSD-created document. If an online step creates/re-creates the 1C document and writes its
  GUID here, a **fresh GUID can arrive on every completion** -> the GUID search never matches ->
  a new 1C document is created each time = **duplicates** (often without a warehouse). This
  attribute is for the "document assembled from several 1C documents" case, not the back-link.

Symptom this fixes: every *завершение* on the TSD spawns a second 1C document. Root cause is
almost always the `Ссылка` rule pointing at *Идентификатор исходных документов* instead of
*Идентификатор*. The vendor completion path only ever resolves the 1C ref from
`ШапкаДокумента.Ид` - writing a GUID into `ИдИсходныхДокументов` does nothing for dedup.

Caveat for TSD-created docs: their MS Id is `new_<guid>`. A hand-rolled
`Документы[Тип].ПолучитьСсылку(Новый УникальныйИдентификатор(Ид))` throws on the `new_` prefix
(invalid GUID) and, inside a bare `Попытка`, silently falls through to creating a duplicate; the
*Поиск по GUID* rule handles the prefix correctly.

## Reference files

- `references/graph-mechanics.md` - action types, every transition attribute, fall-through,
  button arrays, KeyJumps, common caveats. Read when editing graph flow.
- `references/online-1c-call.md` - the InvokeMethodAction -> integration-processor ->
  ТаблицаЗначений mechanism, the wrapper pattern, what is not an online call.
- `references/km-and-document-operations.md` - КМ line fields, IdentificationCode, the ready
  find/delete/recognise operations and how to chain them.

## Constraints in 1C-integration projects

Vendor extensions and 1C extensions are not edited directly - mark project insertions and
prefer copies/wrappers. In this family of projects code and docs avoid the letter "ё" and
long dashes. Confirm destructive or shared-state actions (config transfer to Test/Prod)
before doing them.