Embat Operations API

`Operation` represents an accounting operation with a pending amount to settle — typically an invoice or bill due from or to a `Contact` (client or supplier). An invoice with several due dates is modeled as several operations, one per due date. `customId` is the unique identifier of an operation: set your own value to use as your ERP operation ID, or let Embat auto-generate one. Operations are the counterpart of `Payment`s: each payment created against an operation reduces its `pendingAmount`, and once the full amount is settled the operation's `status` automatically becomes `paid`. Operations can also be grouped into an invoice group or remittance (see `operationsCustomIds`), reference a `Contact`, be classified with a `Category`, and carry custom `attributes`. **Typical flow:** 1. **Notify Embat of invoices/bills issued in your ERP.** Create the operation with its due date and amount: ```json POST /operations/{companyId} { "customId": "invoice-2024-001", "issuanceDate": "2024-01-01T00:00:00Z", "dueDate": "2024-01-31T00:00:00Z", "currency": "EUR", "concept": "Consulting services January", "amount": 1250.50 } ``` 2. **Track settlement.** As payments are recorded against the operation (see `Payments`), its `pendingAmount` decreases and `status` moves from `pending`/`overdue` to `paid`. Once an operation already has a payment recorded against it in Embat, most of its fields can no longer be updated — see the create/update endpoint descriptions for the exact rules. 3. **Keep dates and status in sync.** Use `PATCH /operations/{companyId}/{customId}` (or the bulk variant) to correct `dueDate`/`paymentDate`, update `status`, or attach `attributes` — or resend the full operation with `POST`, since sending a `customId` that already exists updates the operation instead of duplicating it. 4. **Group operations into a remittance (invoice group).** Create the individual operations as usual. When your ERP later groups and pays them together, send one more operation representing the remittance — `documentType: invoiceGroup`, the grouped total as `amount`, and the grouped operations' IDs in `operationsCustomIds`: ```json POST /operations/{companyId} { "customId": "remittance-2024-07", "documentType": "invoiceGroup", "amount": 3750.0, "issuanceDate": "2024-07-01T00:00:00Z", "dueDate": "2024-07-31T00:00:00Z", "paymentDate": "2024-07-31T00:00:00Z", "operationsCustomIds": ["invoice-2024-001", "invoice-2024-002", "invoice-2024-003"] } ``` Embat marks every grouped operation as `paid` with `pendingAmount: 0` and links it to the remittance. From then on, the grouped operations' lifecycle is managed through the remittance: updating them directly has no effect, and resending the remittance without some of them releases those operations back to `pending` with their full pending amount. Use `DELETE /operations/{companyId}/{customId}` to cancel an operation that no longer applies.