Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
First define the source of truth
The order can start in website, CRM or ERP, but payment must be connected to one stable identifier.
Before integrating with 1C, MoySklad or another accounting system, decide where the order is created and which identifier connects every layer. If website, CRM and ERP create separate documents without one payment id, reconciliation becomes manual work.
A minimum model should include internal payment id, order id, invoice id, provider reference, amount, currency, paidAt, fiscal status and refund status. These fields matter to developers, operators, accounting and support.
- do not create several independent invoices for one payment;
- send only verified final status to ERP;
- store provider reference and internal payment id;
- separate order, payment attempt, receipt and refund.
How to connect payment, receipt and refund
Fiscal receipt and refund should be separate events linked to the original payment.
After successful payment, the accounting system often needs more than paid status: fiscal receipt data, invoice closing, shipment or service activation. If receipt creation is synchronous inside payment flow, fiscal service failure can block the customer journey.
A more reliable approach is asynchronous receipt handling: payment is closed, fiscal task is created and receipt result returns to CRM/ERP. Refund should also be a separate event with amount, reason, original payment link and its own fiscal status.
- create receipt only after confirmed payment;
- do not mix paid and fiscal success into one status;
- support partial refund as a separate scenario;
- show operators mismatches between payment and receipt.
What to check during daily reconciliation
ERP reconciliation should find exceptions: paid by provider but not closed in accounting, or refunded without a correct accounting update.
Daily reconciliation should compare provider, website, CRM and ERP data. It should look not only for missing payments, but also amount, currency, receipt status, refund, timezone and manual correction mismatches.
A good process does not force accounting to review every payment. It closes exact matches automatically and shows a short exception list with reason, owner and retry history.
- provider paid, ERP unpaid;
- ERP closed, provider failed or cancelled;
- receipt missing after paid;
- refund exists in provider but not in ERP;
- manual fix without audit trail.
FAQ
Can payment be sent to 1C or MoySklad immediately after customer redirect?
Prefer not. Backend should first verify status with the payment provider or process a trusted webhook, then send final event to the accounting system.
What if receipt creation fails after successful payment?
Keep payment in paid status and move fiscalization into retry or manual review. These statuses should not be merged, otherwise operators will not see where the failure happened.
Is separate ERP reconciliation needed?
Yes, if ERP is the accounting layer. But it should be part of one process across provider, website, CRM, ERP, receipts and refunds.
