Stage 1 · Upload & confirm payment method
Upload the Razorpay export. Each row's payment-method type is derived from method + card_type + bank charge. Review and confirm — status goes Draft → Payment method confirmed. AR / invoice numbers are created later, not taken from the file.
| Seq | Entity description | Refund / Payment | Date | Amount | Bank charge | Total | Payment method | Status |
|---|
Stage 2 · Load sales invoices & map ↩ Invoice API
Pull the sales invoices from the invoice API (Dataverse mp_Invoice), then map each payment-method-confirmed payment to its invoice — auto-suggested by amount (Total = invoice). Status → invoice matched.
| Seq | Entity description | Date | Amount | Bank charge | Total | Payment method | Invoice mapping | Status |
|---|
Stage 3 · Upload to AutoCount → AutoCount
One step, straight into AutoCount: 1. create the Sales Invoice (create_ar_invoice) → 2. wait for its doc no → 3. create the AR Payment (create_ar_payment) knocking that doc off. Where the invoice and the payment disagree on amount the pair is not batched — it is flagged manual create required. Status → Knockoff done.
| Seq | Entity | Date | Total | Bank charge | Payment method | Invoice | Doc pair | Status |
|---|
Master Data ↩ from AutoCount Desktop
Invoice API mp_Invoice · mp_Debtor
The MASTER PAW invoice API — a deployed Azure Function that stores sales invoices and debtor master data in Dataverse. This page reads what it actually holds and creates records by hand. Stage 2 reads the same invoices; Master Data Sync pushes debtors here.
| Doc no | Order no | Date | Debtor | Final | Source | Map | AC |
|---|
| Code | Name | Phone | TIN | Currency | Active |
|---|
Every call below is live against this deployment. Send the key as X-API-Key — a client key (sik_…); this page never shows the real one. Bodies are JSON; POST is a whole-record upsert on the logical key (doc_no / debtor_code / pay_id), so a field left out is cleared — use PATCH for partial updates.