Electronic documents and signing

A new specialist starts on Monday. Before Monday you need a signed contract, an acknowledgment of the internal policy and liability rules, and by the end of the month a payslip as well. Print it, wait for the person to come in, file it in a folder, then a year later search that folder for one specific sheet. The EDM section takes the paper out of that chain: the document lives in the CRM, and the recipient signs it via a link.

Where it is in the CRM

• Documents: Finance → EDM. Two tabs — Dashboard and Documents.
• Settings: Settings → Integrations, the Documents section, the Internal EDO card.

To be upfront about the interface's limits: the section's page is an overview — widgets, a filterable document list, and a document card with an event history. Creating a document, applying the seal, sending it for signature and generating a PDF have no screens in the dashboard — those are API methods; the integration card has Actions buttons for them, but they take parameters as JSON. What the document's recipient sees and does, on the other hand, is built as a page — and that part is described in detail below.

What counts as a document

Types split into two groups. External — tax invoice, adjustment invoice, act of completed works, invoice, waybill. Internal — visit, estimate, agreement, payslip, memo, policy or regulation, and a custom document.

The system assigns the number itself, by type and year: an agreement becomes ДГВ-2026-0001, an act АКТ-2026-0001, a payslip ЗП-2026-0001. Numbering is counted within the company, so the salon next door has its own numbers.

Document states: draft, signed, sent, registered with the DFS, received, processed, rejected, cancelled. Transitions are not arbitrary: only a draft can be signed, and only a signed or registered document can be sent. Every step lands in the document's history as a separate line — created, signed, seal applied, sent, viewed by recipient, signed, rejected, everyone signed. This history is visible on the document card.

Seal, director's signature and settings

Settings live in the Internal EDO integration and are set once: company name, EDRPOU, address, phone, the director's name and position (Director by default).

Seal and director signature images are accepted as PNG, JPEG or GIF up to 2 MB. Uploading is done through separate API methods: in the integration's settings form, the corresponding field is a text field that stores the path to the file already uploaded.

Then come the settings that affect every document: the default signature method, whether to apply the seal and director's signature automatically, which channels to notify the recipient through (email, SMS, Telegram), how many days a signature request stays valid (seven by default), how many days before sending a reminder (three), the PDF template — standard, minimal, detailed or branded — and whether to add a QR code for verification.

Sending for signature

A document is sent for signature to a list of recipients: name, email, phone. A separate request with its own random token is created for each one, and the link looks like sign.beesection.com/sign/<token>. The expiry period is counted from the moment of sending — seven days by default.

If the signature method is PIN, the system generates a six-digit code, stores only its hash, and puts the code itself into the email or SMS. The email with the link is always sent when email notifications are enabled; SMS only goes out if you enabled that channel separately and the recipient has a phone number on file. As soon as at least one message has gone out, the document moves to the "Sent" state.

A request can be cancelled (only while it is still pending) or resent. A resend can do something a new request cannot: if the deadline has already passed, it extends the link for the same seven days and returns the request to pending, and for a PIN signature it generates a new code. The number of resends is kept on record.

How the recipient signs

The recipient opens the link and sees the document: number, type, the sending company, the amount, the content, and marks for the seal and the director's signature. The fact that it was opened is recorded — the request moves to the "Viewed" state, and a line about it appears in the document's history.

There are five signature methods: a simple checkbox, a signature drawn with a finger, an uploaded signature image, a PIN code and an SMS code. Which ones are available is decided by the request: PIN is offered only if a hash is stored for it, SMS only if there is a phone number. When more than one method is available, the recipient picks. Consent is mandatory either way: without the "I agree" checkbox, a signature is not accepted.

Along with the signature, the time, IP address and browser of the person who signed are stored. The recipient then gets a confirmation email with a verification code, and once every recipient has signed, the document moves to the "Received" state and a separate entry is added to the history. Instead of signing, a recipient can decline — with a reason, which is also stored.

The page carries exactly as many restrictions as needed to stop a stranger with the link from abusing it. An SMS code lives for five minutes, new codes can be requested no more than once a minute and no more than five times an hour: SMS costs the salon money, and the link is public. A PIN or SMS code can be entered wrong five times — after that the code is wiped and a new one is required. An expired link shows an "expired" page rather than the signing page; an already-signed one shows a page with its state.

Reminders, expiry and verification

Three things are done by commands that run on a schedule on the server:

• edo/expire-requests — marks overdue requests every hour;
• edo/send-reminders — sends reminders every day at ten to those with three days left before the deadline (one person will not get a reminder more than once a day);
• edo/cleanup-pdf — removes generated PDFs older than thirty days.

The document's PDF is built on demand and freshly every time: the document may have changed since the last generation, and yesterday's file cannot be handed out for "download". If the "QR code for verification" setting is on, the file gets a block with a verification code and a link to the verification page — as text for now, not a code image.

The verification page is public: given the document's code, anyone — a bank, a landlord, a counterparty's accountant — sees the number, date, type, state, company, amount and the list of who signed it, with dates. The recipient sees the same code and link in the confirmation email after signing. Without the code, the page shows nothing.

What to do

Fill in the settings before the first send: without the director's name and the seal, a document formally looks empty, and there is no way to change that after the fact in an already-signed document. For documents signed by an outside person, use PIN or SMS instead of a simple checkbox — those are what make a signature verifiable. And keep the expiry command running: a request whose deadline has passed but that still shows as "awaiting signature" is more confusing than getting no answer at all.