> ## Documentation Index > Fetch the complete documentation index at: https://docs.joinluminous.com/llms.txt > Use this file to discover all available pages before exploring further. # Correct a posted quantity > Rewrites the posted finished-good quantity of one completed historical transaction in place, scales the order's planned quantity by the same ratio, and **by default posts a balancing adjustment so today's on-hand does not move** (a historical fix). The rewritten quantity log is rematerialized into Core inventory immediately; no full Core rebuild is needed. Supported `transaction_type` values: | `transaction_type` | `transaction_id` | | --- | --- | | `assembly_order` | Assembly order ID | | `disassembly_order` | Disassembly order ID | What changes: - The order's planned and actual quantities are scaled to the new quantity. - The finished-good on-hand quantity log is rewritten, and running balances of later on-hand logs for that stock are shifted by `onhand_delta`. - Finished-good on-hand (and the matching stock location / lot, if any) moves by `onhand_delta`, then (by default) a balancing adjustment entry with the opposite quantity is posted so today's on-hand ends where it started. Its ID is returned as `adjustment_id` and its lines as `balancing_entry`. - Component lines and their quantity logs stay as posted. Use `POST /assembly-orders/{assemblyOrderId}/ledger-correction` to change consumed quantities. - A correction record (with `reason`) is stored and its ID returned as `correction_id`. **Balancing entry** - **Default** (no `balancing_entry.date`, `allow_shelf_change` not true): the balancing adjustment is posted **today**, so today's on-hand does not move. - **With `balancing_entry.date`**: the balancing adjustment is posted on that date (not in the future; a back-dated entry is dated at the start of that day). - **`allow_shelf_change: true`**: no balancing adjustment is posted and today's on-hand moves by `onhand_delta`. Rejected (422) when a later shipment, transfer, cycle count, adjustment or stock pull already exists on the finished-good stock. Allowed only when the order is completed, has exactly one finished-good on-hand log, the new quantity differs from the posted quantity, and `transaction_type` matches the order's actual type. Use `GET /posted-quantity-corrections/preview` to check the result first. ## OpenAPI ````yaml /api-reference/build.yaml post /posted-quantity-corrections openapi: 3.0.0 info: title: Luminous API version: 1.0.0 description: API documentation for Luminous servers: - url: https://{companyName}.api.joinluminous.com/external/api/v1 variables: companyName: default: companyName description: Your company-specific subdomain security: [] tags: - name: Products description: Get and manage products - name: Pricing description: Manage price schedules, levels, and customizations - name: BOMs description: Manage Bills of Materials (BOMs) - name: Labels description: Label rendering via Labelary ZPL service - name: Companies description: Manage business accounts and their associated data - name: Contacts description: Manage contact information for individuals - name: Suppliers description: Manage suppliers (factories) — vendors used on purchase orders - name: Supplier SKUs description: Manage per-supplier SKU and unit-cost overrides for products - name: Locations description: Manage warehouses and locations - name: Inventory description: Get and adjust product stock levels - name: Lots description: Create, update, and delete product lots (batches) - name: Transfer Orders description: Manage transfer orders - name: Fulfillment Orders description: Manage fulfillment orders and picklists - name: Freight description: >- Freightview LTL freight — quotes, booking and documents for fulfillment orders - name: Fulfillment Priority Lists description: Configure fulfillment routing priority lists - name: Purchase Orders description: Get and modify purchase orders - name: Supplier Portal description: >- Read a supplier's response to a purchase order and control the one-click portal link - name: Receiving Reports description: Manage receiving reports - name: Payment Obligations description: Manage payment obligations for purchase orders - name: Sales Orders description: Manage sales orders and sales order shipments - name: Purgatory description: >- Inspect and resolve non-posted sales orders in the purgatory staging workflow - name: PickFlow Warehouse description: >- Warehouse-floor lookups for PickFlow — barcode resolution, bin and product stock, bin search, and receivables - name: PickFlow Shipping description: >- Provider-agnostic shipping rates, services, packages, and label purchase for PickFlow - name: Cycle Counts description: >- Create, drive, and post PickFlow cycle counts — batches, per-warehouse sessions, and CSV import/export - name: Print Stations description: List paired print stations and enqueue print jobs to them - name: Invoices description: Get and manage invoices - name: Work Orders description: >- Manage work orders — production lifecycle, steps, materials, links, shipments, and comments - name: Production Batches description: Group and manage work orders as production batches - name: Bills description: >- Accounts payable bill management, payments, attachments, allocations, and variance - name: Prepayments description: Manage vendor prepayments and applications - name: Vendor Credits description: Manage vendor credits and applications - name: Vendor Returns description: Manage vendor returns and credit generation - name: Customer Returns description: Manage customer returns (sales returns), receiving, and restock behavior - name: Stock Snapshot description: Point-in-time stock snapshots with export support - name: Consumption description: Consumption reports and exports - name: Inventory Aging description: Cost-layer-based inventory aging reports - name: Bills Reports description: Accounts payable bills aging reports - name: Forecast description: Materialized forecast data - name: Reports description: Close the books, inventory discrepancy, transaction COGS, and EDI reports - name: Tags description: Add/remove tags across various resources - name: Custom Fields description: Get and set custom fields across various resources - name: Currency description: Currency configuration, exchange rates, and conversion - name: Drive description: > Browse, upload, tag and manage files in your Luminous Drive. An API token sees the shared drive only, never My Files or restricted folders and files. Every write and download made through the API is recorded in the file's activity log (`GET /file-cabinet/files/{id}/activity`) with `actor_kind: api_token`. - name: Integration Mappings description: Manage integration mappings for external systems - name: Integration Field Mappings description: Manage field-level mappings between Luminous and external systems - name: Automations description: Create, test, and inspect automation rules and their runs paths: /posted-quantity-corrections: post: tags: - Assembly Orders summary: Correct a posted quantity description: > Rewrites the posted finished-good quantity of one completed historical transaction in place, scales the order's planned quantity by the same ratio, and **by default posts a balancing adjustment so today's on-hand does not move** (a historical fix). The rewritten quantity log is rematerialized into Core inventory immediately; no full Core rebuild is needed. Supported `transaction_type` values: | `transaction_type` | `transaction_id` | | --- | --- | | `assembly_order` | Assembly order ID | | `disassembly_order` | Disassembly order ID | What changes: - The order's planned and actual quantities are scaled to the new quantity. - The finished-good on-hand quantity log is rewritten, and running balances of later on-hand logs for that stock are shifted by `onhand_delta`. - Finished-good on-hand (and the matching stock location / lot, if any) moves by `onhand_delta`, then (by default) a balancing adjustment entry with the opposite quantity is posted so today's on-hand ends where it started. Its ID is returned as `adjustment_id` and its lines as `balancing_entry`. - Component lines and their quantity logs stay as posted. Use `POST /assembly-orders/{assemblyOrderId}/ledger-correction` to change consumed quantities. - A correction record (with `reason`) is stored and its ID returned as `correction_id`. **Balancing entry** - **Default** (no `balancing_entry.date`, `allow_shelf_change` not true): the balancing adjustment is posted **today**, so today's on-hand does not move. - **With `balancing_entry.date`**: the balancing adjustment is posted on that date (not in the future; a back-dated entry is dated at the start of that day). - **`allow_shelf_change: true`**: no balancing adjustment is posted and today's on-hand moves by `onhand_delta`. Rejected (422) when a later shipment, transfer, cycle count, adjustment or stock pull already exists on the finished-good stock. Allowed only when the order is completed, has exactly one finished-good on-hand log, the new quantity differs from the posted quantity, and `transaction_type` matches the order's actual type. Use `GET /posted-quantity-corrections/preview` to check the result first. operationId: createPostedQuantityCorrection requestBody: required: true content: application/json: schema: type: object required: - transaction_type - transaction_id - quantity - reason properties: transaction_type: type: string enum: - assembly_order - disassembly_order description: Type of transaction to correct. transaction_id: type: integer minimum: 1 description: ID of the transaction (assembly or disassembly order ID). quantity: type: number exclusiveMinimum: true minimum: 0 description: New finished-good quantity. Must be greater than zero. reason: type: string maxLength: 500 description: >- Why the posted quantity is being corrected. Stored with the correction record. balancing_entry: type: object nullable: true properties: date: type: string format: date nullable: true description: > Date of the balancing adjustment. Not in the future. When omitted (and `allow_shelf_change` is not true) the balancing entry is dated today. example: '2026-10-19' allow_shelf_change: type: boolean default: false description: > `true` skips the balancing adjustment so today's on-hand moves by `onhand_delta`. Rejected (422) when a later shipment, transfer, count or adjustment already exists on the finished-good stock. example: transaction_type: assembly_order transaction_id: 1616 quantity: 75.2 reason: Finished good was posted at the component quantity. balancing_entry: date: '2026-10-19' responses: '200': description: Correction saved content: application/json: schema: type: object properties: message: type: string example: >- Posted quantity corrected. Rewritten quantity logs were rematerialized into Core where Core tables exist. data: type: object description: Result of a posted-quantity correction (or its preview). properties: transaction_type: type: string enum: - assembly_order - disassembly_order description: The transaction type that was corrected. transaction_id: type: integer description: >- ID of the corrected transaction (assembly or disassembly order ID). sku: type: string description: Internal SKU of the finished good. old_quantity: type: number description: Finished-good quantity as originally posted. new_quantity: type: number description: Corrected finished-good quantity. onhand_delta: type: number description: > Signed change to on-hand quantity (in base units). For an assembly order (adds stock) this is new minus old; for a disassembly order (removes stock) it is old minus new, so reducing a removal puts quantity back on hand. message: type: string example: >- Rewritten quantity logs were rematerialized into Core where Core tables exist. correction_id: type: integer nullable: true description: >- ID of the stored correction record. `null` on the preview. adjustment_id: type: integer nullable: true description: > ID of the balancing adjustment entry posted with the correction. `null` on the preview, and `null` when `allow_shelf_change` was true. balancing_entry: type: object nullable: true description: > The balancing adjustment (posted, or on the preview, to be posted) that keeps today's on-hand unchanged. `null` only when `allow_shelf_change` was true. properties: date: type: string format: date example: '2026-10-19' lines: type: array items: type: object properties: sku: type: string quantity: type: number description: >- Adjustment quantity (the opposite of `onhand_delta`). onhand_after: type: number description: >- Today's on-hand after the correction and the balancing entry. requires_full_core_rebuild: type: boolean description: >- Always `false`; the rewritten quantity log is rematerialized into Core immediately. example: false example: message: >- Posted quantity corrected. Rewritten quantity logs were rematerialized into Core where Core tables exist. data: transaction_type: assembly_order transaction_id: 1616 sku: SKU old_quantity: 1184 new_quantity: 75.2 onhand_delta: -1108.8 message: >- Rewritten quantity logs were rematerialized into Core where Core tables exist. correction_id: 1 adjustment_id: 9001 balancing_entry: date: '2026-10-19' lines: - sku: SKU quantity: 1108.8 onhand_after: 2000 requires_full_core_rebuild: false '400': description: > Validation failure (`{ "error": "..." }`, e.g. missing `reason` or unknown `transaction_type`), or the order was not found / `transaction_type` does not match the order / the posted actual quantity is zero (`{ "message": "..." }`). content: application/json: schema: type: object properties: message: type: string error: type: string '401': description: Unauthorized content: application/json: schema: type: object properties: message: type: string '422': description: > The order cannot be corrected (`{ "message": "..." }`): not completed, quantity unchanged, not exactly one finished-good on-hand log, balancing date in the future, `allow_shelf_change` with later movements on the stock, or the completion/balancing date is in a closed period. content: application/json: schema: type: object properties: message: type: string security: - BearerAuth: [] components: securitySchemes: BearerAuth: type: http scheme: bearer description: >- Authenticate using a bearer token. To create a token, navigate to /settings/api-tokens and click Create API Token. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.