Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Сначала нужно определить источник истины
Заказ может родиться на сайте, в CRM или ERP, но платеж должен быть связан с одним стабильным идентификатором.
Перед интеграцией с 1C, МойСклад или другой учетной системой нужно решить, где создается заказ и какой идентификатор связывает все контуры. Если сайт, CRM и ERP создают отдельные документы без общего payment id, сверка быстро превращается в ручную работу.
Минимальная модель должна включать internal payment id, order id, invoice id, provider reference, amount, currency, paidAt, fiscal status and refund status. Эти поля нужны не только разработчику, но и оператору, бухгалтерии и поддержке.
- не создавать несколько независимых счетов на один платеж;
- передавать в ERP только проверенный финальный статус;
- хранить provider reference и внутренний payment id;
- разделять заказ, платежную попытку, чек и возврат.
Как связать оплату, чек и возврат
Фискальный чек и возврат должны быть отдельными событиями, связанными с исходным платежом.
После успешной оплаты учетная система часто должна получить не только paid-статус, но и данные для фискального чека, закрытия счета, отгрузки или услуги. Если чек создается синхронно в момент оплаты, сбой фискального сервиса может заблокировать клиентский сценарий.
Практичнее обрабатывать чек асинхронно: платеж закрыт, задача на фискализацию создана, результат чека возвращается в CRM/ERP. Возврат тоже должен быть отдельным событием с суммой, причиной, ссылкой на исходный платеж и своим fiscal status.
- создавать чек только после подтвержденной оплаты;
- не смешивать paid и fiscal success в один статус;
- поддерживать partial refund как отдельный сценарий;
- показывать оператору расхождения между оплатой и чеком.
Что проверять в ежедневной сверке
ERP-сверка должна находить исключения: оплачено у провайдера, но не закрыто в учете, или возвращено без корректного отражения.
Ежедневная сверка должна сравнивать данные провайдера, сайта, CRM и ERP. Важно искать не только missing payments, но и расхождения суммы, валюты, статуса чека, возврата, timezone и ручных корректировок.
Хороший процесс не заставляет бухгалтера просматривать все платежи. Он автоматически закрывает совпадения и показывает короткий список исключений с причиной, ответственным и историей повторных проверок.
- provider paid, ERP unpaid;
- ERP closed, provider failed или cancelled;
- receipt missing after paid;
- refund exists in provider but not in ERP;
- manual fix without audit trail.
FAQ
Можно ли отправлять оплату в 1C или МойСклад сразу после redirect клиента?
Лучше нет. Сначала backend должен подтвердить статус у платежного провайдера или обработать доверенный webhook, а затем отправить финальное событие в учетную систему.
Что делать, если чек не создался после успешной оплаты?
Оплату нужно оставить в paid, а фискализацию перевести в retry или manual review. Эти статусы лучше не смешивать, иначе оператор не поймет, где именно сбой.
Нужна ли отдельная сверка для ERP?
Да, если ERP является учетным контуром. Но сверка должна быть частью общего процесса: провайдер, сайт, CRM, ERP, чеки и возвраты.
