01
Опишите операции, которым действительно нужен ЭДО
Фитнес-клуб работает одновременно с физическими лицами, компаниями, поставщиками, арендодателем и сервисными подрядчиками. Для розничной оплаты посетителя обычно важны payment и фискальный чек. Для корпоративного договора появляются счёт, акт и другие юридические документы. Закупка бара, ремонт тренажёра и аренда помещения создают входящие документы. Один общий список файлов скрывает разницу между этими процессами.
Начните с карты операций. Укажите источник, плательщика, получателя услуги, обязательные документы, момент подготовки, ответственного и финальный статус. Корпоративный пакет абонементов может требовать счёт до оплаты и акт по итогам месяца. Разовая услуга подрядчика начинается с входящего договора или акта. Возврат требует корректирующего процесса и ссылки на исходную операцию.
ProGym хранит EDO pack как связь документов одной бизнес-операции. Источником может быть checkout sale, заказ или другой нейтральный объект Taska Core. Такой подход сохраняет исходные данные и позволяет расширять список продуктов платформы. Фитнес-специфичная таблица копий документов для этого не нужна.
- корпоративная продажа членства;
- закупка товаров бара;
- ремонт и обслуживание оборудования;
- аренда и коммунальные услуги;
- возврат или корректировка операции.
02
Разделите оплату, фискализацию и юридический документ
Банковская оплата подтверждает движение денег. Фискальный receipt регистрирует розничную операцию у выбранного провайдера. ЭДО фиксирует юридический обмен между организациями. Эти события могут относиться к одной продаже, но имеют разные идентификаторы, сроки и причины ошибки. Статус paid не означает, что акт подписан. Статус sent у документа не доказывает поступление денег.
В модели клуба каждая сущность сохраняет собственный lifecycle. Payment проходит pending, processing, succeeded или failed. Fiscal receipt ждёт отправки, фискализируется либо требует retry. EDO document создаётся как draft, передаётся оператору, подписывается, отправляется, принимается или отклоняется. Сводный экран показывает связи, а исправление выполняется в нужном контуре.
Такое разделение особенно важно при закрытии месяца. Бухгалтер сверяет банковский отчёт, кассовые смены, фискальный журнал и документы контрагентов. Автоматический чек-лист может показать три failed receipt и два пакета без акта. Общая зелёная галочка по продаже скрыла бы обе проблемы.
03
Подготовьте реквизиты и канонические строки
Автоматическая сборка работает только на качественных исходных данных. Карточка организации хранит юридическое название, ИНН, адрес, банковские реквизиты и налоговые настройки. Контрагент получает те же проверяемые поля. Номенклатура содержит единицу измерения, цену, ставку НДС и ИКПУ или МХИК, когда это требуется форме.
Строки продажи становятся каноном пакета. Количество, цена, скидка, налог и сумма фиксируются один раз. Счёт, акт и ЭСФ используют этот набор по своим правилам. Человек не переносит позиции между таблицами и кабинетом оператора. Изменение каталога позже не переписывает уже согласованный документ.
Перед созданием внешнего черновика система проверяет gaps. Отсутствующий ИНН, адрес или обязательный код блокирует передачу и показывает конкретную причину. Сотрудник исправляет источник, повторяет сборку по контролируемому сценарию и получает проверяемый результат. Ложный статус sent при неполных реквизитах запрещён.
- реквизиты собственной организации;
- ИНН и адрес контрагента;
- позиции, единицы и количество;
- НДС и коды номенклатуры;
- неизменяемый снимок после согласования.
04
Собирайте исходящий пакет из продажи
Когда корпоративный клиент оплачивает пакет членств, checkout sale уже знает плательщика, состав, сумму и валюту. Команда compose создаёт EDO pack и документы, предусмотренные политикой клуба. Повтор события после таймаута использует тот же источник и возвращает существующий пакет. Дубли счетов и актов не появляются.
Каждый документ хранит тип, направление, legal status, внутренний document instance и связь с оператором. Пакет показывает минимальный итоговый статус и gaps. Менеджер видит, что продажа оплачена, бухгалтер видит готовность документов, а руководитель может перейти к исходной операции. Роли ограничивают доступ к финансовой и юридической информации.
Автоматическая отправка обычно создаёт лишний риск. Сначала сотрудник проверяет стороны, позиции и сумму. Затем внутреннее согласование фиксирует одобренный снимок. После этого создаётся операторный черновик. Юридическая подпись выполняется уполномоченным человеком. Такая последовательность сохраняет скорость и контроль.
05
Подключайте Didox через защищённый gateway
Для подключения нужны partner token, user key, выбранная среда и язык. Секреты передаются серверу по защищённому каналу, шифруются через Fernet и не возвращаются в API. Staff-интерфейс показывает публичное имя, sandbox или production, health status, время проверки и безопасную ошибку. Логи не содержат токены и PDF целиком.
Health-check обращается к профилю Didox и подтверждает доступ компании. При создании draft сервер формирует PDF из document instance, проверяет лимит размера, продавца и покупателя, затем вызывает оператор. Полученный operator document ID сохраняется в Taska. Повтор команды под блокировкой возвращает тот же ID.
Закрытый ключ E-IMZO остаётся у бухгалтера и Didox. ProGym не просит загружать его на сервер и не имитирует подпись. Бухгалтер открывает подготовленный черновик, проверяет, подписывает и отправляет. Taska синхронизирует доступный статус оператора для общего журнала.
- sandbox перед production;
- шифрование partner token и user key;
- живая проверка профиля;
- один внешний draft на документ;
- подпись в кабинете оператора.
06
Превратите входящие в управляемую очередь
Входящий документ полезен после назначения следующего действия. ProGym опрашивает Didox по курсору и повторно захватывает безопасное окно дня. Уникальная связь организации, оператора и operator document ID превращает пересечение в идемпотентный upsert. Повторная синхронизация обновляет статус и не создаёт копию.
Правила смотрят на тип документа и список ИНН. Более высокий приоритет применяется первым. Результат может назначить ответственного, создать задачу со сроком, добавить watchers и запустить BPM. Например, входящий акт поставщика получает бухгалтера и дедлайн 24 часа, а договор подрядчика запускает юридическое согласование.
Журнал показывает название, контрагента, ИНН, legal status, время получения, задачу, процесс и связанный пакет. Обычный сотрудник видит назначенные ему документы. Пользователь с edo.view_all или edo.admin видит организацию целиком. Другая tenant-база остаётся недоступной.
07
Настройте ежемесячную подготовку
Повторяющиеся акты и счета не требуют ручного напоминания. Профиль хранит день месяца, часовой пояс, режим, источник, контрагента, состав документов, подключение и ответственного. Draft-only создаёт внутренний пакет или операторный черновик. Approval передаёт результат в выбранный BPM-шаблон.
Каждый запуск получает period key вида год и месяц. Уникальное ограничение не позволяет выполнить один профиль дважды за период. Ручная кнопка полезна для проверки и восстановления, но возвращает существующий durable run. Ошибка записывается с кодом и сообщением, следующий профиль продолжает работу.
В интерфейсе бухгалтер видит next run, last run, active state и историю. Пауза использует optimistic version. Если два администратора одновременно изменили профиль, один получит stale version и обновит данные. Это защищает расписание от тихой перезаписи.
- день месяца и Asia/Tashkent;
- состав пакета;
- ответственный и BPM;
- один запуск на период;
- история результата и ошибки.
08
Свяжите ЭДО с закрытием месяца
Перед закрытием периода команда проверяет незавершённые продажи, оплаты, кассовые смены, складские расхождения, fiscal receipts и EDO packs. По документам полезны количество draft, waiting signature, sent, accepted, rejected и failed. Drill-down ведёт к конкретному пакету и источнику.
Метрики строятся без секретов подключения и сырого содержимого документов. Для анализа достаточно организации, направления, типа, статуса, суммы, даты, времени обработки и источника. Customer IDs и operator tokens не нужны в общем маркетинговом датасете. Доступ к экспорту подчиняется тем же permissions, что экран.
Руководитель оценивает время от продажи до черновика, от черновика до отправки, долю отклонений и просроченные входящие. Рост missing requisites укажет на качество CRM-данных. Долгая подпись покажет узкое место процесса. Автоматизация должна сокращать конкретный интервал, а не просто увеличивать число созданных файлов.
09
Проведите sandbox и FIELD-приёмку
Начните с одной тестовой организации и Didox sandbox. Подключите аккаунт, выполните health-check и убедитесь, что секреты отсутствуют в ответе. Создайте безналичную продажу, соберите пакет, проверьте стороны, строки, сумму и gaps. Повторите compose и draft после имитации потерянного ответа. Пакет и внешний документ должны остаться в одном экземпляре.
Подпишите и отправьте документ в Didox тестовым уполномоченным пользователем. Запустите outbound sync и сравните operator ID, номер и статус. Затем подготовьте входящий документ, выполните sync дважды и проверьте одну проекцию, назначение, задачу и BPM. Измените правило с устаревшей version и получите conflict.
Создайте monthly profile, выполните его дважды в одном периоде и найдите один run. Проверьте ошибку неполных реквизитов, недоступность оператора и восстановление после health-check. Завершите mobile QA на 390 пикселях, RU, UZ, EN, tenant isolation и audit. Только после этого конкретное подключение клуба получает production-статус.
Отдельно проверьте роли. Менеджер с edo.compose собирает пакет, но не меняет подключение. Бухгалтер с edo.send создаёт operator draft и видит безопасные данные соединения. Администратор управляет правилами, профилями и синхронизацией. Сотрудник без edo.view не получает журнал даже при известном URL. Пользователь с обычным просмотром видит только назначенные входящие, а edo.view_all открывает журнал организации. Каждая мутация сохраняет автора, request ID и безопасный payload аудита.
Негативный сценарий должен быть таким же подробным. Уберите адрес контрагента и подтвердите блокировку draft. Передайте неподдерживаемый тип и получите проверяемый 422. Отключите sandbox, выполните sync и убедитесь, что интерфейс показывает ошибку вместо пустого успешного журнала. Восстановите соединение, повторите запрос и найдите прежние документы без дублей. Проверьте старую version правила и профиля, неверный BPM template, отсутствующего assignee и источник с чужой организацией.
Для запуска в сети повторите тест на одном филиале и одном юридическом лице, затем добавьте второе подключение. У каждого соединения должны сохраняться собственная среда, курсор и health. Пакет использует выбранное connection ID и не переключается на первый доступный аккаунт. Такой контроль защищает сеть с несколькими юридическими лицами от отправки документа через чужой договор оператора.
- шифрование и отсутствие секретов;
- точные стороны, строки и сумма;
- idempotent pack, draft и inbound sync;
- задача, BPM и optimistic version;
- один monthly run;
- реальный статус в кабинете Didox.