@revenexx/node 0.1.0 → 0.1.1

package/dist/services/inventories-stock.d.mts

@@ -6,6 +6,15 @@ import '../query.mjs';
 import '../enums/address-type-row-tone.mjs';
 import '../enums/address-type-row-create-request-tone.mjs';
 import '../enums/address-type-row-update-request-tone.mjs';
+import '../enums/approval-rule-approver-type.mjs';
+import '../enums/approval-rule-condition.mjs';
+import '../enums/approval-rule-effect.mjs';
+import '../enums/approval-rule-create-request-approver-type.mjs';
+import '../enums/approval-rule-create-request-condition.mjs';
+import '../enums/approval-rule-create-request-effect.mjs';
+import '../enums/approval-rule-update-request-approver-type.mjs';
+import '../enums/approval-rule-update-request-condition.mjs';
+import '../enums/approval-rule-update-request-effect.mjs';
 import '../enums/assets-source.mjs';
 import '../enums/attribute-value-bucket.mjs';
 import '../enums/auth-mail-source.mjs';
@@ -119,6 +128,8 @@ import '../enums/payment-term-tone.mjs';
 import '../enums/payment-term-create-request-tone.mjs';
 import '../enums/payment-term-update-request-tone.mjs';
 import '../enums/payment-vocabulary-tone.mjs';
+import '../enums/pending-approval-approver-type.mjs';
+import '../enums/pending-approval-status.mjs';
 import '../enums/price-ending-rule.mjs';
 import '../enums/price-entries-adjust-response-rounding.mjs';
 import '../enums/price-entries-adjust-response-rounding-mode.mjs';
@@ -141,6 +152,11 @@ import '../enums/product-grid-column-source.mjs';
 import '../enums/product-label-source.mjs';
 import '../enums/product-label-attribute-source.mjs';
 import '../enums/products-kind.mjs';
+import '../enums/purchase-request-status.mjs';
+import '../enums/purchase-request-event-name.mjs';
+import '../enums/purchase-request-item-type.mjs';
+import '../enums/purchase-request-item-create-request-type.mjs';
+import '../enums/purchase-request-item-update-request-type.mjs';
 import '../enums/reorder-point-source.mjs';
 import '../enums/reservation-status.mjs';
 import '../enums/price-on-request-reason.mjs';
@@ -178,6 +194,8 @@ import '../enums/shipping-weight-unit-row-tone.mjs';
 import '../enums/shipping-weight-unit-update-request-tone.mjs';
 import '../enums/stock-movement-type.mjs';
 import '../enums/store-asset-request-visibility.mjs';
+import '../enums/submit-item-type.mjs';
+import '../enums/submit-result-outcome.mjs';
 import '../enums/validation-failed-response-status.mjs';
 import '../enums/vocabulary-default-tone.mjs';
 import '../enums/vocabulary-source.mjs';
@@ -238,7 +256,7 @@ declare class InventoriesStock {
      * @param {string} params.reason - Why the stock is being corrected — this is the audit trail a stocktake leaves behind. Owed unless `movement_reason_required` is 'none' (its default, 'adjustments', asks for one exactly here); missing where it is owed, the call is 400.
      * @param {string} params.sku - Inline single-item form: the article number to move (instead of `product_id`).
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      */
     inventoriesAdjust(params?: {
         items?: Models.InventoryAdjustItem[];
@@ -247,7 +265,7 @@ declare class InventoriesStock {
         quantity?: number;
         reason?: string;
         sku?: string;
-    }): Promise<Models.Error>;
+    }): Promise<{}>;
     /**
      * The batch correction route — a stocktake, breakage, shrinkage — and the manual way `on_hand` is ever put right. Quantities are SIGNED: a positive one adds to the balance, a negative one takes it away, and neither is written onto the row directly. Each item is booked into the movements ledger as an `adjustment` and the balance follows, so a correction leaves a record of who changed what and why instead of a number that silently differs from yesterday's. A reason is mandatory unless movement_reason_required is 'none'.
      *
@@ -258,10 +276,10 @@ declare class InventoriesStock {
      * @param {string} reason - Why the stock is being corrected — this is the audit trail a stocktake leaves behind. Owed unless `movement_reason_required` is 'none' (its default, 'adjustments', asks for one exactly here); missing where it is owed, the call is 400.
      * @param {string} sku - Inline single-item form: the article number to move (instead of `product_id`).
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesAdjust(items?: Models.InventoryAdjustItem[], locationCode?: string, productId?: string, quantity?: number, reason?: string, sku?: string): Promise<Models.Error>;
+    inventoriesAdjust(items?: Models.InventoryAdjustItem[], locationCode?: string, productId?: string, quantity?: number, reason?: string, sku?: string): Promise<{}>;
     /**
      * THE stock call of this app, and a batch one: name any number of items and each comes back with `on_hand`, `reserved` and the derived `available` (their difference, computed on read and stored nowhere), summed across the locations in scope and broken down per location, plus `orderable` — whether this much of it can be promised at this moment. An item this app has never seen is NOT an error: it comes back tracked:false, and the storefront decides whether an untracked item sells freely. It is also the most customised surface this product has in the field. A tenant whose stock really lives in an ERP — SAP live stock is the ordinary case, not the exotic one — replaces exactly this one capability, 1:1, with a custom app through the gateway's capability override, while every other route here keeps doing the stock-keeping CRUD unchanged. That is why the request and response shapes below read as a contract to be implemented rather than as an implementation detail: whatever ends up answering this path has to answer in these terms.
      *
@@ -271,7 +289,7 @@ declare class InventoriesStock {
      * @param {number} params.quantity - Inline single-item form: how many are wanted (default 1). It decides `orderable` and nothing else.
      * @param {string} params.sku - Inline single-item form: the article number to move (instead of `product_id`).
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      */
     inventoriesAvailability(params?: {
         items?: Models.InventoryAvailabilityItem[];
@@ -279,7 +297,7 @@ declare class InventoriesStock {
         productId?: string;
         quantity?: number;
         sku?: string;
-    }): Promise<Models.Error>;
+    }): Promise<{}>;
     /**
      * THE stock call of this app, and a batch one: name any number of items and each comes back with `on_hand`, `reserved` and the derived `available` (their difference, computed on read and stored nowhere), summed across the locations in scope and broken down per location, plus `orderable` — whether this much of it can be promised at this moment. An item this app has never seen is NOT an error: it comes back tracked:false, and the storefront decides whether an untracked item sells freely. It is also the most customised surface this product has in the field. A tenant whose stock really lives in an ERP — SAP live stock is the ordinary case, not the exotic one — replaces exactly this one capability, 1:1, with a custom app through the gateway's capability override, while every other route here keeps doing the stock-keeping CRUD unchanged. That is why the request and response shapes below read as a contract to be implemented rather than as an implementation detail: whatever ends up answering this path has to answer in these terms.
      *
@@ -289,10 +307,10 @@ declare class InventoriesStock {
      * @param {number} quantity - Inline single-item form: how many are wanted (default 1). It decides `orderable` and nothing else.
      * @param {string} sku - Inline single-item form: the article number to move (instead of `product_id`).
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesAvailability(items?: Models.InventoryAvailabilityItem[], locationCode?: string, productId?: string, quantity?: number, sku?: string): Promise<Models.Error>;
+    inventoriesAvailability(items?: Models.InventoryAvailabilityItem[], locationCode?: string, productId?: string, quantity?: number, sku?: string): Promise<{}>;
     /**
      * The movements ledger, read end to end. Every stock change this app has ever made is a booking row in it — a receipt, a correction, a hold, a release, a shipment, a return — which is what lets one list be an audit trail and an event feed at the same time: these are the rows the `stock_movement.created` event carries, so a consumer that missed an event catches up by paging here. Append-only: the ledger has no update and no delete, because a correction is another booking. `order=created_at.desc` is the feed order.
      *
@@ -310,7 +328,7 @@ declare class InventoriesStock {
      * @param {string} params.metadata - Exact-match filter on `metadata`. Free-form, and two keys this app writes itself: `backordered` — on a `reserve` booking, how much of the hold was not covered by stock on hand; `shortfall` — on a `shipment` booking, how much was committed that was not physically there (`on_hand` floors at 0, so the difference is recorded here instead of vanishing). The WHOLE jsonb document is compared, serialized as JSON — this is equality, not a key lookup or a containment query, and a value that does not parse is answered 400.
      * @param {string} params.createdAt - Exact-match filter on `created_at`. Exact timestamp. There is no range filter on the ledger — page it with `?order=created_at.desc` instead.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      */
     inventoriesMovementsList(params?: {
         limit?: number;
@@ -326,7 +344,7 @@ declare class InventoriesStock {
         reason?: string;
         metadata?: string;
         createdAt?: string;
-    }): Promise<Models.Error>;
+    }): Promise<{}>;
     /**
      * The movements ledger, read end to end. Every stock change this app has ever made is a booking row in it — a receipt, a correction, a hold, a release, a shipment, a return — which is what lets one list be an audit trail and an event feed at the same time: these are the rows the `stock_movement.created` event carries, so a consumer that missed an event catches up by paging here. Append-only: the ledger has no update and no delete, because a correction is another booking. `order=created_at.desc` is the feed order.
      *
@@ -344,29 +362,29 @@ declare class InventoriesStock {
      * @param {string} metadata - Exact-match filter on `metadata`. Free-form, and two keys this app writes itself: `backordered` — on a `reserve` booking, how much of the hold was not covered by stock on hand; `shortfall` — on a `shipment` booking, how much was committed that was not physically there (`on_hand` floors at 0, so the difference is recorded here instead of vanishing). The WHOLE jsonb document is compared, serialized as JSON — this is equality, not a key lookup or a containment query, and a value that does not parse is answered 400.
      * @param {string} createdAt - Exact-match filter on `created_at`. Exact timestamp. There is no range filter on the ledger — page it with `?order=created_at.desc` instead.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesMovementsList(limit?: number, offset?: number, order?: string, id?: string, locationId?: string, productId?: string, sku?: string, type?: InventoriesMovementsListType, quantity?: number, orderRef?: string, reason?: string, metadata?: string, createdAt?: string): Promise<Models.Error>;
+    inventoriesMovementsList(limit?: number, offset?: number, order?: string, id?: string, locationId?: string, productId?: string, sku?: string, type?: InventoriesMovementsListType, quantity?: number, orderRef?: string, reason?: string, metadata?: string, createdAt?: string): Promise<{}>;
     /**
      * A movement is one booking row in the ledger, and the ledger is append-only: there is no update and no delete, because a correction is another booking. `quantity` is SIGNED and its sign follows the `type` — a receipt books +5 and the reserve that promises those goods books −5, even though the reservation it created carries +5 as a positive hold. GET /inventories/vocabularies/movement-types is the list of types with the words for them. A booking says what changed, not what the balance became: it carries no running total, so the row's story is read by listing the ledger for that location and item rather than by fetching one id. `location_id` is a plain uuid and not a foreign key, so a booking outlives the location it was made at and this route will happily hand back one whose location no longer resolves — that is the audit trail doing its job, not a broken row. Fixing a wrong booking is another booking (POST /inventories/adjust); nothing here can be edited or removed.
      *
      * @param {string} params.id - The ledger booking.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.StockMovement>}
      */
     inventoriesMovementsGet(params: {
         id: string;
-    }): Promise<Models.Error>;
+    }): Promise<Models.StockMovement>;
     /**
      * A movement is one booking row in the ledger, and the ledger is append-only: there is no update and no delete, because a correction is another booking. `quantity` is SIGNED and its sign follows the `type` — a receipt books +5 and the reserve that promises those goods books −5, even though the reservation it created carries +5 as a positive hold. GET /inventories/vocabularies/movement-types is the list of types with the words for them. A booking says what changed, not what the balance became: it carries no running total, so the row's story is read by listing the ledger for that location and item rather than by fetching one id. `location_id` is a plain uuid and not a foreign key, so a booking outlives the location it was made at and this route will happily hand back one whose location no longer resolves — that is the audit trail doing its job, not a broken row. Fixing a wrong booking is another booking (POST /inventories/adjust); nothing here can be edited or removed.
      *
      * @param {string} id - The ledger booking.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.StockMovement>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesMovementsGet(id: string): Promise<Models.Error>;
+    inventoriesMovementsGet(id: string): Promise<Models.StockMovement>;
     /**
      * Books a delivery into the receiving location (the caller's location_code, else the default_location_code setting), creating the stock row if the item is new. A reason is optional unless movement_reason_required is 'all'. Takes a batch or one item inline.
      *
@@ -377,7 +395,7 @@ declare class InventoriesStock {
      * @param {string} params.reason - What the ledger should record about this receipt — a delivery note number, a production order. Owed only when `movement_reason_required` is 'all'; the contract does not require it, because whether it is owed is the tenant's setting and not this route's rule.
      * @param {string} params.sku - Inline single-item form: the article number to move (instead of `product_id`).
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      */
     inventoriesReceive(params?: {
         items?: Models.InventoryStockItem[];
@@ -386,7 +404,7 @@ declare class InventoriesStock {
         quantity?: number;
         reason?: string;
         sku?: string;
-    }): Promise<Models.Error>;
+    }): Promise<{}>;
     /**
      * Books a delivery into the receiving location (the caller's location_code, else the default_location_code setting), creating the stock row if the item is new. A reason is optional unless movement_reason_required is 'all'. Takes a batch or one item inline.
      *
@@ -397,10 +415,10 @@ declare class InventoriesStock {
      * @param {string} reason - What the ledger should record about this receipt — a delivery note number, a production order. Owed only when `movement_reason_required` is 'all'; the contract does not require it, because whether it is owed is the tenant's setting and not this route's rule.
      * @param {string} sku - Inline single-item form: the article number to move (instead of `product_id`).
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesReceive(items?: Models.InventoryStockItem[], locationCode?: string, productId?: string, quantity?: number, reason?: string, sku?: string): Promise<Models.Error>;
+    inventoriesReceive(items?: Models.InventoryStockItem[], locationCode?: string, productId?: string, quantity?: number, reason?: string, sku?: string): Promise<{}>;
     /**
      * The replenishment worklist: the stock rows that have run down far enough that somebody has to order more, in one list rather than as a query a caller has to build. Computed on read, so it is never stale: a row alerts when available (on_hand − reserved) has fallen to or below its own reorder_point, or the reorder_point_default setting when it carries none. A point of 0 never alerts. Answers enabled:false with an empty list when reorder_alert_enabled is off — a tenant replenishing from an ERP should not be told twice.
      *
@@ -439,7 +457,7 @@ declare class InventoriesStock {
      * @param {boolean} params.restock - Do these goods rejoin SELLABLE stock? A merchant decision, not a fact: apparel usually restocks, hygiene articles never do, many merchants inspect first. Omit it to follow the `restock_on_return_default` setting. `false` answers `restocked: false`, moves nothing and books NOTHING — there is no movement to write, because no stock moved, and that is the branch that makes this route a 200 while its sibling `receive` is a 201.
      * @param {string} params.sku - Inline single-item form: the article number to move (instead of `product_id`).
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      */
     inventoriesRestock(params?: {
         items?: Models.InventoryStockItem[];
@@ -450,7 +468,7 @@ declare class InventoriesStock {
         reason?: string;
         restock?: boolean;
         sku?: string;
-    }): Promise<Models.Error>;
+    }): Promise<{}>;
     /**
      * Whether a return rejoins sellable stock follows restock_on_return_default, overridable per call with 'restock'. When the answer is no the response says restocked:false and nothing moves — there is no movement to book, because no stock moved. That branch is why this route answers 200 and its sibling `receive` answers 201: a restock may legitimately create nothing.
      *
@@ -463,10 +481,10 @@ declare class InventoriesStock {
      * @param {boolean} restock - Do these goods rejoin SELLABLE stock? A merchant decision, not a fact: apparel usually restocks, hygiene articles never do, many merchants inspect first. Omit it to follow the `restock_on_return_default` setting. `false` answers `restocked: false`, moves nothing and books NOTHING — there is no movement to write, because no stock moved, and that is the branch that makes this route a 200 while its sibling `receive` is a 201.
      * @param {string} sku - Inline single-item form: the article number to move (instead of `product_id`).
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesRestock(items?: Models.InventoryStockItem[], locationCode?: string, orderRef?: string, productId?: string, quantity?: number, reason?: string, restock?: boolean, sku?: string): Promise<Models.Error>;
+    inventoriesRestock(items?: Models.InventoryStockItem[], locationCode?: string, orderRef?: string, productId?: string, quantity?: number, reason?: string, restock?: boolean, sku?: string): Promise<{}>;
     /**
      * A stock level is ONE item at ONE location, and it carries two numbers, neither of which is the sellable one: `on_hand` is what is physically there INCLUDING everything already promised, and `reserved` is what has been promised — it never reduces `on_hand`. What may still be sold is their difference, and it is derived on read and never stored, so there is no `available` column to read, filter or order by. This is the operator's view — the whole book, filtered by location or by item — not the shop's: a storefront asking "can I sell five of this" wants POST /inventories/availability, which sums an item across locations and answers `orderable` instead of leaving the caller to subtract. Two things this list will not do: it has no range filters, so "everything running low" is GET /inventories/reorder-alerts and not a query here; and it does not promise one row per item per location — no unique index enforces that. POST /inventories/stock refuses a duplicate with a 409, but that is a check and not a constraint, so a row written past it, or one that predates the guard, still splits an item's balance in two, and the write routes find and update whichever of them the database returns first.
      *
@@ -484,7 +502,7 @@ declare class InventoriesStock {
      * @param {string} params.createdAt - Exact-match filter on `created_at`. When the row was created.
      * @param {string} params.updatedAt - Exact-match filter on `updated_at`. When this row was last written.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      */
     inventoriesStockList(params?: {
         limit?: number;
@@ -500,7 +518,7 @@ declare class InventoriesStock {
         metadata?: string;
         createdAt?: string;
         updatedAt?: string;
-    }): Promise<Models.Error>;
+    }): Promise<{}>;
     /**
      * A stock level is ONE item at ONE location, and it carries two numbers, neither of which is the sellable one: `on_hand` is what is physically there INCLUDING everything already promised, and `reserved` is what has been promised — it never reduces `on_hand`. What may still be sold is their difference, and it is derived on read and never stored, so there is no `available` column to read, filter or order by. This is the operator's view — the whole book, filtered by location or by item — not the shop's: a storefront asking "can I sell five of this" wants POST /inventories/availability, which sums an item across locations and answers `orderable` instead of leaving the caller to subtract. Two things this list will not do: it has no range filters, so "everything running low" is GET /inventories/reorder-alerts and not a query here; and it does not promise one row per item per location — no unique index enforces that. POST /inventories/stock refuses a duplicate with a 409, but that is a check and not a constraint, so a row written past it, or one that predates the guard, still splits an item's balance in two, and the write routes find and update whichever of them the database returns first.
      *
@@ -518,10 +536,10 @@ declare class InventoriesStock {
      * @param {string} createdAt - Exact-match filter on `created_at`. When the row was created.
      * @param {string} updatedAt - Exact-match filter on `updated_at`. When this row was last written.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesStockList(limit?: number, offset?: number, order?: string, id?: string, locationId?: string, productId?: string, sku?: string, onHand?: number, reserved?: number, reorderPoint?: number, metadata?: string, createdAt?: string, updatedAt?: string): Promise<Models.Error>;
+    inventoriesStockList(limit?: number, offset?: number, order?: string, id?: string, locationId?: string, productId?: string, sku?: string, onHand?: number, reserved?: number, reorderPoint?: number, metadata?: string, createdAt?: string, updatedAt?: string): Promise<{}>;
     /**
      * Registers an item at a location. The row is born at ZERO and never gets a balance from this call: `on_hand` and `reserved` are NOT accepted, because they are the running total of the movements ledger, so an opening balance is a receipt (POST /inventories/receive) rather than a field here, and the only thing that ever moves either number afterwards is another booking. What this row carries is its identity (location + `product_id`/`sku`), its `reorder_point` and its metadata. `location_id` is the only field a create cannot omit; every other column is optional or defaulted by the database. The one rule that is a CHECK rather than a column is that a row has to identify its item, so `product_id` or `sku` has to be there as well. Mostly you do not need this route at all — every stock call creates the row it is missing — and a second row for an item this location already tracks is answered 409: no unique index enforces one row per item per location, so that row would split the item's balance across two rows the write routes cannot tell apart, each of them updating whichever the database returns first. That guard is a check before the insert and not a constraint, so it closes a double click or a re-run import and does not claim to close a race between two simultaneous creates.
      *
@@ -531,7 +549,7 @@ declare class InventoriesStock {
      * @param {number} params.reorderPoint - The available quantity at or below which this row belongs on the replenishment worklist (GET /inventories/reorder-alerts). Null falls back to the `reorder_point_default` setting, so replenishment works without a threshold per SKU; 0 never alerts, which is how one row opts out.
      * @param {string} params.sku - The article number this row tracks when there is no product id, which is the normal case for an ERP-stocked catalogue. Exact match, and the identity every stock call may use instead of a uuid.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.StockLevel>}
      */
     inventoriesStockCreate(params: {
         locationId: string;
@@ -539,7 +557,7 @@ declare class InventoriesStock {
         productId?: string;
         reorderPoint?: number;
         sku?: string;
-    }): Promise<Models.Error>;
+    }): Promise<Models.StockLevel>;
     /**
      * Registers an item at a location. The row is born at ZERO and never gets a balance from this call: `on_hand` and `reserved` are NOT accepted, because they are the running total of the movements ledger, so an opening balance is a receipt (POST /inventories/receive) rather than a field here, and the only thing that ever moves either number afterwards is another booking. What this row carries is its identity (location + `product_id`/`sku`), its `reorder_point` and its metadata. `location_id` is the only field a create cannot omit; every other column is optional or defaulted by the database. The one rule that is a CHECK rather than a column is that a row has to identify its item, so `product_id` or `sku` has to be there as well. Mostly you do not need this route at all — every stock call creates the row it is missing — and a second row for an item this location already tracks is answered 409: no unique index enforces one row per item per location, so that row would split the item's balance across two rows the write routes cannot tell apart, each of them updating whichever the database returns first. That guard is a check before the insert and not a constraint, so it closes a double click or a re-run import and does not claim to close a race between two simultaneous creates.
      *
@@ -549,48 +567,48 @@ declare class InventoriesStock {
      * @param {number} reorderPoint - The available quantity at or below which this row belongs on the replenishment worklist (GET /inventories/reorder-alerts). Null falls back to the `reorder_point_default` setting, so replenishment works without a threshold per SKU; 0 never alerts, which is how one row opts out.
      * @param {string} sku - The article number this row tracks when there is no product id, which is the normal case for an ERP-stocked catalogue. Exact match, and the identity every stock call may use instead of a uuid.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.StockLevel>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesStockCreate(locationId: string, metadata?: object, productId?: string, reorderPoint?: number, sku?: string): Promise<Models.Error>;
+    inventoriesStockCreate(locationId: string, metadata?: object, productId?: string, reorderPoint?: number, sku?: string): Promise<Models.StockLevel>;
     /**
      * Stops tracking one item at one location. A stock level is ONE item at ONE location, and it carries two numbers, neither of which is the sellable one: `on_hand` is what is physically there INCLUDING everything already promised, and `reserved` is what has been promised — it never reduces `on_hand`. What may still be sold is their difference, and it is derived on read and never stored, so there is no `available` column to read, filter or order by. A deleted balance is not recoverable: the ledger is the audit trail, not the source of truth, and nothing in this app ever replays it to rebuild a number — so the next receipt for the same item here creates a FRESH row at zero, standing next to movements that say otherwise. That used to be a trap a caller discovered afterwards. It is a stated property now, because the route REFUSES while the row still holds anything, and answers 409 with what it holds. The two things that block are the location delete's two, asked of one row. A reservation still `active` against this item at this location is the sharper one: /release and /commit look their stock row up by (location, item) on the very next call and would find nothing, so the hold would lower no `reserved` and /commit would book the whole quantity as a shortfall — orphaned immediately rather than eventually. `on_hand` above zero is the stronger one: deleting a LOCATION at least meant "close this warehouse" and took the balances as a side effect of the cascade, while this row IS the balance, so the delete can only ever mean "no longer tracked here" — true once the number is zero and a lie while it is not. POST /inventories/stock/{id}/adjust to zero is the operation that makes it true, and it BOOKS the movement, so the stock leaves through the ledger instead of vanishing with the row. Nothing points at it by foreign key, so the database takes nothing else with it. History therefore never blocks and is never deleted — the ledger is keyed on (location, item) and never on this id, so its bookings survive a row that is gone, BY DESIGN, exactly as they survive a location that is gone.
      *
      * @param {string} params.id - The stock row.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      */
     inventoriesStockDelete(params: {
         id: string;
-    }): Promise<Models.Error>;
+    }): Promise<{}>;
     /**
      * Stops tracking one item at one location. A stock level is ONE item at ONE location, and it carries two numbers, neither of which is the sellable one: `on_hand` is what is physically there INCLUDING everything already promised, and `reserved` is what has been promised — it never reduces `on_hand`. What may still be sold is their difference, and it is derived on read and never stored, so there is no `available` column to read, filter or order by. A deleted balance is not recoverable: the ledger is the audit trail, not the source of truth, and nothing in this app ever replays it to rebuild a number — so the next receipt for the same item here creates a FRESH row at zero, standing next to movements that say otherwise. That used to be a trap a caller discovered afterwards. It is a stated property now, because the route REFUSES while the row still holds anything, and answers 409 with what it holds. The two things that block are the location delete's two, asked of one row. A reservation still `active` against this item at this location is the sharper one: /release and /commit look their stock row up by (location, item) on the very next call and would find nothing, so the hold would lower no `reserved` and /commit would book the whole quantity as a shortfall — orphaned immediately rather than eventually. `on_hand` above zero is the stronger one: deleting a LOCATION at least meant "close this warehouse" and took the balances as a side effect of the cascade, while this row IS the balance, so the delete can only ever mean "no longer tracked here" — true once the number is zero and a lie while it is not. POST /inventories/stock/{id}/adjust to zero is the operation that makes it true, and it BOOKS the movement, so the stock leaves through the ledger instead of vanishing with the row. Nothing points at it by foreign key, so the database takes nothing else with it. History therefore never blocks and is never deleted — the ledger is keyed on (location, item) and never on this id, so its bookings survive a row that is gone, BY DESIGN, exactly as they survive a location that is gone.
      *
      * @param {string} id - The stock row.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesStockDelete(id: string): Promise<Models.Error>;
+    inventoriesStockDelete(id: string): Promise<{}>;
     /**
      * A stock level is ONE item at ONE location, and it carries two numbers, neither of which is the sellable one: `on_hand` is what is physically there INCLUDING everything already promised, and `reserved` is what has been promised — it never reduces `on_hand`. What may still be sold is their difference, and it is derived on read and never stored, so there is no `available` column to read, filter or order by. Read it to see one item's position at one place, and to get the id the two row-scoped routes take: POST /inventories/stock/{id}/adjust corrects this balance, and GET /inventories/reorder-alerts reports it by this id. What it does not answer is how the balance got here — that is GET /inventories/movements filtered by the location and item on this row, because a movement points at (location, item) and never at a stock row id.
      *
      * @param {string} params.id - The stock row.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.StockLevel>}
      */
     inventoriesStockGet(params: {
         id: string;
-    }): Promise<Models.Error>;
+    }): Promise<Models.StockLevel>;
     /**
      * A stock level is ONE item at ONE location, and it carries two numbers, neither of which is the sellable one: `on_hand` is what is physically there INCLUDING everything already promised, and `reserved` is what has been promised — it never reduces `on_hand`. What may still be sold is their difference, and it is derived on read and never stored, so there is no `available` column to read, filter or order by. Read it to see one item's position at one place, and to get the id the two row-scoped routes take: POST /inventories/stock/{id}/adjust corrects this balance, and GET /inventories/reorder-alerts reports it by this id. What it does not answer is how the balance got here — that is GET /inventories/movements filtered by the location and item on this row, because a movement points at (location, item) and never at a stock row id.
      *
      * @param {string} id - The stock row.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.StockLevel>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesStockGet(id: string): Promise<Models.Error>;
+    inventoriesStockGet(id: string): Promise<Models.StockLevel>;
     /**
      * Partial update of everything on the row EXCEPT its balance: reorder_point, metadata, identity. on_hand and reserved are dropped from the body — every stock change is a movement, and a body carrying nothing else is answered 422 with the route that was meant (POST /inventories/stock/{id}/adjust).
      *
@@ -601,7 +619,7 @@ declare class InventoriesStock {
      * @param {number} params.reorderPoint - The available quantity at or below which this row belongs on the replenishment worklist (GET /inventories/reorder-alerts). Null falls back to the `reorder_point_default` setting, so replenishment works without a threshold per SKU; 0 never alerts, which is how one row opts out.
      * @param {string} params.sku - The article number this row tracks when there is no product id, which is the normal case for an ERP-stocked catalogue. Exact match, and the identity every stock call may use instead of a uuid.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.StockLevel>}
      */
     inventoriesStockUpdate(params: {
         id: string;
@@ -610,7 +628,7 @@ declare class InventoriesStock {
         productId?: string;
         reorderPoint?: number;
         sku?: string;
-    }): Promise<Models.Error>;
+    }): Promise<Models.StockLevel>;
     /**
      * Partial update of everything on the row EXCEPT its balance: reorder_point, metadata, identity. on_hand and reserved are dropped from the body — every stock change is a movement, and a body carrying nothing else is answered 422 with the route that was meant (POST /inventories/stock/{id}/adjust).
      *
@@ -621,10 +639,10 @@ declare class InventoriesStock {
      * @param {number} reorderPoint - The available quantity at or below which this row belongs on the replenishment worklist (GET /inventories/reorder-alerts). Null falls back to the `reorder_point_default` setting, so replenishment works without a threshold per SKU; 0 never alerts, which is how one row opts out.
      * @param {string} sku - The article number this row tracks when there is no product id, which is the normal case for an ERP-stocked catalogue. Exact match, and the identity every stock call may use instead of a uuid.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.StockLevel>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesStockUpdate(id: string, locationId?: string, metadata?: object, productId?: string, reorderPoint?: number, sku?: string): Promise<Models.Error>;
+    inventoriesStockUpdate(id: string, locationId?: string, metadata?: object, productId?: string, reorderPoint?: number, sku?: string): Promise<Models.StockLevel>;
     /**
      * Corrects the balance of ONE stock row, and only that one. It is the row-scoped twin of POST /inventories/adjust: the row already knows its location and item, so a caller owes nothing but a SIGNED delta on `on_hand` — positive to add, negative to take away — and a reason for it. The delta is not written onto the balance either; it is booked into the movements ledger as an `adjustment` and the balance follows, which is why the answer hands back the row at its new value instead of an acknowledgement. This is the route that replaced the Cockpit's editable on_hand field.
      *
@@ -632,13 +650,13 @@ declare class InventoriesStock {
      * @param {number} params.quantity - The SIGNED correction to this row's `on_hand`: −3 writes off three, +3 finds three. A delta, not the new balance. Zero is refused (400). A correction that would take `on_hand` below zero is a 422 the database insists on; one that would take it below this row's own `reserved` is a 422 the `allow_negative_stock` setting can permit.
      * @param {string} params.reason - Why this row is being corrected, written onto the ledger booking. Owed unless `movement_reason_required` is 'none'.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      */
     inventoriesStockAdjust(params: {
         id: string;
         quantity: number;
         reason?: string;
-    }): Promise<Models.Error>;
+    }): Promise<{}>;
     /**
      * Corrects the balance of ONE stock row, and only that one. It is the row-scoped twin of POST /inventories/adjust: the row already knows its location and item, so a caller owes nothing but a SIGNED delta on `on_hand` — positive to add, negative to take away — and a reason for it. The delta is not written onto the balance either; it is booked into the movements ledger as an `adjustment` and the balance follows, which is why the answer hands back the row at its new value instead of an acknowledgement. This is the route that replaced the Cockpit's editable on_hand field.
      *
@@ -646,10 +664,10 @@ declare class InventoriesStock {
      * @param {number} quantity - The SIGNED correction to this row's `on_hand`: −3 writes off three, +3 finds three. A delta, not the new balance. Zero is refused (400). A correction that would take `on_hand` below zero is a 422 the database insists on; one that would take it below this row's own `reserved` is a 422 the `allow_negative_stock` setting can permit.
      * @param {string} reason - Why this row is being corrected, written onto the ledger booking. Owed unless `movement_reason_required` is 'none'.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<{}>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesStockAdjust(id: string, quantity: number, reason?: string): Promise<Models.Error>;
+    inventoriesStockAdjust(id: string, quantity: number, reason?: string): Promise<{}>;
     /**
      * Discovery for the vocabulary routes: the enums this app publishes, each with its name, its title and its description and deliberately WITHOUT its values, so finding out what exists costs one small call and not one per vocabulary. Names: location-types, movement-types, reservation-statuses. Fetch one with GET /inventories/vocabularies/{name}; a client holding the qualified pair 'inventories.<name>' builds that URL from the pair alone.
      *
@@ -662,20 +680,20 @@ declare class InventoriesStock {
      *
      * @param {InventoriesVocabulariesGetName} params.name - The vocabulary name — the part after the dot in the qualified id. One of: location-types, movement-types, reservation-statuses. Anything else is a 404, so the enum is the complete set and not a suggestion.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.InventoryVocabulary>}
      */
     inventoriesVocabulariesGet(params: {
         name: InventoriesVocabulariesGetName;
-    }): Promise<Models.Error>;
+    }): Promise<Models.InventoryVocabulary>;
     /**
      * One vocabulary in full: every permitted value, each carrying the title and description a person reads for it and the badge tone a UI colours it with, so a client renders a status or a movement type without a hard-coded table of its own. The values are read out of the column's CHECK constraint, so the served set IS the enforced set and the two cannot drift — a value added to the constraint appears here even before anyone labels it, titled from its own key. Values come back in constraint order, which is lifecycle order for a status. 'closed' says the set is exhaustive, so a value outside it is stale data rather than a missing label. Names: location-types, movement-types, reservation-statuses.
      *
      * @param {InventoriesVocabulariesGetName} name - The vocabulary name — the part after the dot in the qualified id. One of: location-types, movement-types, reservation-statuses. Anything else is a 404, so the enum is the complete set and not a suggestion.
      * @throws {RevenexxException}
-     * @returns {Promise<Models.Error>}
+     * @returns {Promise<Models.InventoryVocabulary>}
      * @deprecated Use the object parameter style method for a better developer experience.
      */
-    inventoriesVocabulariesGet(name: InventoriesVocabulariesGetName): Promise<Models.Error>;
+    inventoriesVocabulariesGet(name: InventoriesVocabulariesGetName): Promise<Models.InventoryVocabulary>;
 }
 
 export { InventoriesStock };