# EDO & e-signature

The `docflow` category covers Russian electronic document flow (ЭДО) and adjacent systems — sending, receiving, and signing documents. Signing a document with a qualified e-signature (КЭП) is handled by a dedicated tool, separate from `connector_execute`.

## Document-flow connectors

These connectors are reached through the standard [connector flow](/docs/connector-flow). The catalog includes, among others:

- **Diadoc** (`diadoc`) and **SBIS** (`sbis`) — EDO operators: send, receive, and sign documents.
- **Kontur.Extern** (`kontur_extern`) — reporting and document exchange.
- The **1C** family (`onec_accounting`, `onec_trade`, `onec_document_flow`, …) — RPC-style document operations.
- **MoySklad** (`moysklad`) — trade documents and inventory.
- **Chestny ZNAK** (`chestnyznak`) — product marking codes and documents.
- **HRlink** (`hrlink`) — HR electronic document flow (КЭДО).

## Signing with a qualified e-signature

`sign_document` is a **standalone tool**, not a connector call. It produces a qualified e-signature (КЭП) through the **CryptoPro browser plugin**, so the private key never leaves the user's machine. Its `service` argument is constrained to the EDO operators it rides on: `diadoc` or `sbis`.

### Request

The assistant calls `sign_document`, which emits a `signature_request` to the frontend and pauses (a human-in-the-loop form bridge).

### Sign in the browser

The user picks a certificate and signs in CryptoPro. The detached CMS signature is produced **client-side** — the backend never sees the private key.

### Forward

The signature comes back over the form bridge; the tool forwards it to the underlying EDO connector (Diadoc / SBIS) and returns the status to the assistant.

**Human-in-the-loop**

Signing always pauses for the user — it is never silent. The request times out if no certificate is selected within the signing window.