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. 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.

1

Request

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

2

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.

3

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.

Was this page helpful?