sinfactura-types 1.10.618 → 1.10.620

package/dist/caea.d.ts

@@ -78,13 +78,26 @@ declare global {
      * pre-submit reasons: a period with a missing snapshot reads
      * `MISSING_DET_SNAPSHOT` even if its siblings were also rejected.
      *
+     * `ARCA_CONFIGURATION_REFUSED` — the job DID submit, and ARCA refused the
+     * whole call with a configuration code: today only 1204, the punto de venta
+     * the call carried is not registered at ARCA as Sistema "CAEA – Fact.
+     * Elect.". No retry can clear it; the next daily run informs the period once
+     * an operator fixes it, and the fix depends on the period. A `zero-movement`
+     * period is reported on the store's `caeaPointOfSale`: register that number
+     * at ARCA, or point `caeaPointOfSale` at one that is. An `inform` period
+     * reports its vouchers on the punto de venta each was issued on: register
+     * THAT number at ARCA — re-pointing `caeaPointOfSale` does not help vouchers
+     * already issued. Derived from the row's `informConfigRefusal`, which names
+     * the code and the punto de venta. Ranked after the three pre-submit
+     * reasons and before `DET_REJECTED`.
+     *
      * `READ_FAILED` — not a job decision: the invoice read behind this period
      * threw (a throttle, a transport error), so the screen cannot say whether the
      * job would inform it. `owedInvoices` is then `0` as a lower bound and
      * `invoiceReadTruncated` is `true`. Refetch; it clears on the next successful
      * read.
      */
-    type CaeaPeriodHeldReason = 'DATA_DRIFT' | 'NO_CAEA_POINT_OF_SALE' | 'MISSING_DET_SNAPSHOT' | 'DET_REJECTED' | 'READ_FAILED';
+    type CaeaPeriodHeldReason = 'DATA_DRIFT' | 'NO_CAEA_POINT_OF_SALE' | 'MISSING_DET_SNAPSHOT' | 'ARCA_CONFIGURATION_REFUSED' | 'DET_REJECTED' | 'READ_FAILED';
     /**
      * The per-period facts `GET /caea` DERIVES AT READ from the period's invoices.
      *
@@ -110,8 +123,9 @@ declare global {
      * `held` — `true` when the period has ended, is still awaiting inform, and the
      * inform job will not flip it to `informed` on its own — for EVERY refusal the
      * job makes: the three it decides BEFORE submitting (drift, no CAEA punto de
-     * venta, a missing snapshot) and the one it learns AFTER submitting
-     * (`DET_REJECTED`, carried on the row by the job's own stamp) — or, for such a
+     * venta, a missing snapshot) and the two it learns AFTER submitting
+     * (`ARCA_CONFIGURATION_REFUSED`, `DET_REJECTED`, each carried on the row by
+     * the job's own stamp) — or, for such a
      * period, when the read behind these facts failed and the answer is unknown
      * (`READ_FAILED`). `false`
      * means not held — always present, never absent. `reason` is present exactly
@@ -124,6 +138,35 @@ declare global {
         held: boolean;
         reason?: CaeaPeriodHeldReason;
     }
+    /**
+     * The coded refusals of `POST /caea { mode: 'inform' }` (the `error` field).
+     *
+     * `CAEA_PERIOD_NOT_ACTIVE` (404) — no `active` period for that
+     * `period`/`order`: it was never requested, or it is already `informed`.
+     * `CAEA_PERIOD_NOT_ENDED` (409) — the fortnight is still open.
+     * `CAEA_PERIOD_SETTLING` (409) — it closed less than a minute ago; retry.
+     * `CAEA_INFORM_IN_PROGRESS` (409) — another run (the daily cron or a second
+     * click) holds the period's inform lock; retry shortly.
+     * `CAEA_INFORM_CONFIGURATION_REFUSED` (502) — ARCA refused the Inform with a
+     * configuration code (today only 1204: the punto de venta is not registered at
+     * ARCA as a CAEA one). Nothing was informed and the period stays `active`.
+     * `data` is {@link CaeaInformConfigurationRefusedData}. Retrying does not
+     * help until an operator acts, and `message` names the fix for the refused
+     * method: for a zero-movement report, register the punto de venta at ARCA or
+     * point `caeaPointOfSale` at one that is; for issued vouchers, register
+     * `data.ptoVta` itself at ARCA.
+     */
+    type CaeaInformErrorCode = 'CAEA_PERIOD_NOT_ENDED' | 'CAEA_PERIOD_SETTLING' | 'CAEA_PERIOD_NOT_ACTIVE' | 'CAEA_INFORM_IN_PROGRESS' | 'CAEA_INFORM_CONFIGURATION_REFUSED';
+    /**
+     * `data` of `502 CAEA_INFORM_CONFIGURATION_REFUSED`: ARCA's `code`, the
+     * punto de venta the refused call carried, and the period it was for.
+     */
+    interface CaeaInformConfigurationRefusedData {
+        code: number;
+        ptoVta: number;
+        period: string;
+        order: 1 | 2;
+    }
     /** One entry of the `GET /caea` period history: the stored row plus what the read derives. */
     type CaeaPeriodView = CAEAPeriod & CaeaPeriodDerived;
 }

package/dist/cart.d.ts

@@ -1278,6 +1278,12 @@ declare global {
      * enforced by `tsc` rather than discovered at runtime. Supplying more than one
      * is legal; the server tries `cartId`, then `terminalId`, then `customerId`.
      *
+     * ⚠️ A `cartId` is a DEMAND, not a first preference: when that row is gone —
+     * checkout deletes the cart it converts — the write is `404 CART_NOT_FOUND`
+     * and writes nothing. It never falls through to the other two and never mints
+     * a replacement. Drop the id and address by `terminalId`/`customerId` to start
+     * a new sale.
+     *
      * ⚠️ `cartId` names a specific walk-in ticket; `terminalId` can also resolve
      * the till's open walk-in. A walk-in has no `customerId`, so the sparse
      * `PK-customerId` lookup cannot find it.

package/dist/invoice.d.ts

@@ -508,6 +508,12 @@ declare global {
             rejectedDets: number;
             codes: number[];
         };
+        informConfigRefusal?: {
+            code: number;
+            ptoVta: number;
+            refusedAt: string;
+        };
+        informOverdueAt?: string;
     }
     /** Result of requesting a new CAEA code for an upcoming period. */
     interface CAEARequestResult {

package/dist/order.d.ts

@@ -2004,6 +2004,18 @@ declare global {
         creditOverride?: {
             reason: string;
         };
+        /**
+         * The sale's whole charged total goes on the customer's account (a till's
+         * "cuenta corriente" sale). Create only; never beside `tenders`.
+         *
+         * It is a credit directive, not a payment. It adds no tender leg, so
+         * `amountPaid` / `financialStatus` stay those of an unpaid order. It books no
+         * receivable either: the caller still records that through `POST /account`.
+         * What it buys is the create's {@link Order.creditWarning}, computed from the
+         * order total against the customer's ledger balance, and the ledger figures
+         * on a {@link Order.creditOverride} sent with it.
+         */
+        onAccount?: boolean;
         /**
          * Tender legs to ring against this order, as RAW input — NOT the persisted
          * `Order.tenders`, which is why `Partial<Order>` is narrowed with `Omit`

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "sinfactura-types",
-	"version": "1.10.618",
+	"version": "1.10.620",
 	"description": "Shared wire and entity contracts for the SINFACTURA platform.",
 	"type": "module",
 	"main": "dist/index.js",