POST /tenants/{tenantId}/sales/invoices/{id}/recognize-revenue

tenantSalesPostInvoicesByIdRecognizeRevenue · Sales

Human Supabase USER only; permissions sales.read, accounting.post. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación

SupabaseBearer · http bearer