> ## Documentation Index > Fetch the complete documentation index at: https://docs.arcuserp.com/llms.txt > Use this file to discover all available pages before exploring further. # Restate a purchase order loaded from the previous system as fulfilled > Restates an open purchase order that was loaded from the previous system, whose own records show every unit arrived, as fulfilled. Three fields move together in one transaction or not at all: the order status, the fulfillment status and each line's received quantity (the quantity named for the line in `received_quantities`, or the line's ordered quantity). No receipt is created, and no stock, cost layer, accrual or journal entry moves, because the previous system already booked the goods. Refused by name when the order was created in this system, is not open, is a drop-ship order, is waiting for approval, or has any receipt recorded in this system (finish that order by receiving it or closing it short instead); a refusal changes nothing. Requires `purchasing:write` scope, and the API key's owning user must also hold the `purchasing.create` permission. A repeat sent with the same `Idempotency-Key` replays the first answer; a repeat without one, or with a new one, answers 409 `po_restate_not_open`. ## OpenAPI ````yaml /openapi.yaml post /purchase-orders/{id}/restate-fulfilled openapi: 3.1.0 info: title: Arcus ERP Public API version: 1.0.0 description: > Arcus ERP public REST API. Designed for external integrations and data migration. **Authentication.** Bearer token (API key) via the `Authorization` header. Format: `Authorization: Bearer ark_live_ent__` (or `ark_test_*` for sandbox). API keys are issued per-entity in **Settings > Developers > API Keys**. **Entity scoping.** The entity is encoded in the API key prefix; routes are flat (e.g. `/v1/accounts`, `/v1/orders`, `/v1/products`). A small set of platform endpoints (migration, reconciliation, events, webhook endpoints, API keys) use the `/v1/entities/{entity_id}/...` form -- those are noted in their tags. **Key capabilities.** - Related-resource hydration via `?expand[]=` (see `x-arcus-expand` on each resource). - Cursor-based pagination (`starting_after` / `ending_before` / `limit`). - Idempotency via the `Idempotency-Key` header. - Webhook events for asynchronous notification. - Conditional requests / ETag for cache validation. **Changelog.** Entries are dated and name every published contract whose MEANING moved, not only the ones whose field names changed. The narrative version of the same entries, written for integrators, is published at https://arcuserp.mintlify.app/changelog. **October 2026: the order status values are the ones the API sends.** The `Order` schema's `order_status`, `payment_status`, `fulfillment_status` and `document_type` now list the values the order endpoints actually return (`order_status`: draft, open, processing, fulfilled, cancelled, archived, expired, awaiting_ach_clearance; `payment_status`: unpaid, partial, processing, paid, refunded, terms, overdue, overpaid, partially_refunded; `fulfillment_status`: unfulfilled, partial, fulfilled, backordered, awaiting_pickup; `document_type` adds late_fee_invoice). The values themselves did not change; the schema had listed names the API never sends (`confirmed`, `partially_paid`, `partially_fulfilled`, `voided`, `on_hold`), so a client generated from it could reject a real order. On `POST /v1/orders`, `order_status` is limited to `draft` only for a `sales_order` or `invoice`. The refusals of the order, refund, settings and deposit endpoints are now listed with their `code` values on each response. **October 2026: a pair of bank lines in transit at a month end is an open item there.** `GET /v1/entities/{entity_id}/reconciliation/account-audit`, `answers.books_against_bank`, each `month_ends` row: when the two bank lines of a pair matched together to one bill payment (a wire and its return) fall on either side of that date, `bank_unbooked_amount` and `bank_unbooked_count` now include the line already in the bank, and `gl_uncleared_amount` and `gl_uncleared_count` include the payment's bank leg; `explained_by_open_items` therefore explains that date instead of leaving the part in transit unexplained. No field is renamed and no other date moves; once both lines are in the bank the pair counts nowhere, as every other match. **2026-09-22 (planned 2026-09-21), REORDER-BUYER-TRUTH: demand changed what it MEANS on three published contracts, with no field renamed.** An integrator that pins field names sees no breakage and different numbers, which is why this entry exists. - **Demand now counts build consumption.** `demand_avg_per_day` on the public product, kit and inventory-balance objects, and `daily_demand` / `demand_basis` / `net_suggested_qty` on `GET /v1/purchasing/reorder-report`, are composed from fulfilled sales lines PLUS posted `build_consume` inventory draws: each physical decrement of a product counts exactly once. The previous rule adopted an internal-consumption basis only when the sales blend was exactly zero, so a product both sold AND consumed into work orders planned as if the build draws did not exist. Products drawn into work orders move; on one production-shaped dataset five did, the largest from 0.05/day to 14.95/day. - **`demand_basis` now carries four values, not two:** `sales`, `sales_and_builds`, `builds` and `consumption`. A consumer with a two-branch reader (anything that is not `consumption` is `sales`) silently hides the two new ones. - **`current_demand_units` on `GET /v1/inventory/balances/:id` moved, by a second rule.** It counts committed-but-unshipped CUSTOMER demand, and it now counts a kit component's own line rather than its parent kit line, and excludes non-sales documents. On one production dataset 269 of 1,043 balance rows changed, 227 of them downward; the largest single move was 1,941 to 25, on a product whose open PURCHASE order line had been reported as customer demand. Re-baseline anything that alerts or reorders off this field. - `run_rate_30/90/180/365` and `blended_daily` on the same balance object move for the first reason above. - **Added, not changed:** `GET /v1/purchasing/reorder-report` accepts `demand_window` and returns the unit, cover-through and reorder-point-provenance fields documented on that operation; `order_multiple` is accepted and returned on the product-vendor doors. - **Volume note.** The `inventory.low_stock`, `inventory.out_of_stock` and `inventory.back_in_stock` webhook events are population-gated on `on_hand <= reorder_point`, and reorder points move with the demand above, so subscribers should expect a one-time step change in event volume around the release. servers: - url: https://api.arcuserp.com/v1 description: Arcus ERP API (accepts both live `ark_live_*` and test `ark_test_*` keys) - url: https://dev-api.arcuserp.com/v1 description: >- Dev sandbox API (test-only data, accepts `ark_test_*` keys against dev RDS) security: [] paths: /purchase-orders/{id}/restate-fulfilled: parameters: - name: id in: path required: true schema: type: string format: uuid post: tags: - Purchasing summary: Restate a purchase order loaded from the previous system as fulfilled description: >- Restates an open purchase order that was loaded from the previous system, whose own records show every unit arrived, as fulfilled. Three fields move together in one transaction or not at all: the order status, the fulfillment status and each line's received quantity (the quantity named for the line in `received_quantities`, or the line's ordered quantity). No receipt is created, and no stock, cost layer, accrual or journal entry moves, because the previous system already booked the goods. Refused by name when the order was created in this system, is not open, is a drop-ship order, is waiting for approval, or has any receipt recorded in this system (finish that order by receiving it or closing it short instead); a refusal changes nothing. Requires `purchasing:write` scope, and the API key's owning user must also hold the `purchasing.create` permission. A repeat sent with the same `Idempotency-Key` replays the first answer; a repeat without one, or with a new one, answers 409 `po_restate_not_open`. operationId: restatePurchaseOrderFulfilledV1 requestBody: required: true content: application/json: schema: type: object required: - reason properties: reason: type: string minLength: 3 maxLength: 500 description: >- Why the purchase order is being restated (3 to 500 characters), recorded on its status history and its activity. received_quantities: type: array description: >- Optional. The received quantity per line; a line not named here takes its ordered quantity. Each quantity must be at least what the line already reads received and at most what was ordered. items: type: object required: - line_id - quantity properties: line_id: type: string format: uuid description: >- The purchase order line's id, in any spelling of it (upper or lower case, with or without hyphens). quantity: type: integer minimum: 0 description: The units received on that line. responses: '200': description: >- The restated purchase order, as GET /purchase-orders/{id} returns it. content: application/json: schema: $ref: '#/components/schemas/PurchaseOrder' '400': description: > `reason_required` (the reason is missing, blank, or outside 3 to 500 characters); `invalid_received_quantities` (not a list, an entry without a line id or a whole quantity of zero or more, or a line named twice, in any spelling of its id); `invalid_id_format` (the id in the path is not a valid id; `invalid_purchase_order_id` is the same refusal from the in-app route and is not returned here); `entity_id_required` (no company resolved). '401': $ref: '#/components/responses/Error' '403': description: > `insufficient_scope`: the API key lacks `purchasing:write`. `permission_denied`: the key's owning user lacks the `purchasing.create` permission key. '404': description: '`purchase_order_not_found`: no such purchase order in this company.' '409': description: > The order cannot be restated; nothing was changed. `po_restate_not_migrated` (the order was created in this system); `po_restate_not_open` (the order is not open, named in `order_status`, which is also what a repeat without the first request's `Idempotency-Key` receives); `po_restate_drop_ship` (a drop-ship purchase order); `po_restate_pending_approval` (the order is waiting for approval); `po_restate_has_native_receipts` (a receipt recorded in this system exists, listed in `receipts`). '422': description: > `not_a_purchase_order` (the id names another kind of document); `po_restate_unknown_line` (a line named in `received_quantities` is not on the order, listed in `line_ids`); `po_restate_quantity_out_of_range` (a quantity below what the line already reads received or above what was ordered, each listed in `lines` with its `minimum` and `maximum`; a line that already reads more received than was ordered fits no quantity); `po_restate_failed` (the restate could not be completed and nothing was changed). security: - ApiKeyAuth: [] components: schemas: PurchaseOrder: type: object description: A purchase order issued to a vendor. properties: id: type: string format: uuid object: type: string enum: - purchase_order entity_id: type: string format: uuid readOnly: true po_number: type: string readOnly: true vendor_id: type: string format: uuid location_id: type: string format: uuid nullable: true status: type: string enum: - draft - approved - sent - partially_received - received - closed - cancelled readOnly: true po_date: type: string format: date-time expected_date: type: string format: date-time nullable: true subtotal: type: number tax_total: type: number shipping_total: type: number po_total: type: number currency: type: string default: USD notes: type: string nullable: true internal_notes: type: string nullable: true metadata: type: object nullable: true created_at: type: string format: date-time readOnly: true updated_at: type: string format: date-time readOnly: true approved_total: type: number nullable: true readOnly: true description: > The order total as it stood when an approver approved this purchase order -- the basis they actually saw. NULL on every approval predating 2026-08-17 (no backfill) and NULL means "basis unknown", which is treated as fail-safe. approval_stale: type: boolean readOnly: true description: > DERIVED, not stored. True when the order is `approved` AND its total has since risen above `approved_total`. The purchase order still receives normally; this is a non-blocking prompt to re-approve. header_editability: type: object readOnly: true description: > Per-field verdicts for the header fields, from the same predicate the write handlers enforce. Keys: `notes`, `internal_notes`, `due_date`, `expected_date`, `location_id`, `po_tracking_reference`. Each is `{ allowed: boolean, reason: string|null }` where `reason` is a token from the PoLineEditReason vocabulary. additionalProperties: $ref: '#/components/schemas/PoFieldVerdict' billed_total: type: number readOnly: true description: > How much of this purchase order's GOODS a vendor bill has already taken over: the sum of the goods lines that count toward this purchase order on every bill in `open`, `partial`, `paid` or `written_off`, never a bill's header total and never a landed, freight or expense line on it. A line counts toward this purchase order when its `po_item_id` names one of its lines, or when it names none and the bill's `po_id` is this purchase order (one bill may bill several purchase orders, and each is billed only its own lines). 0 when no bill has been raised, never null. unbilled_balance: type: number readOnly: true description: > What the purchase order STILL commits the buyer to, compared like with like: 0 once every ordered goods unit is billed (where the units can be seen; goods money otherwise), else `max(order_total - billed_total, 0)`, cents-quantized. A bill line's units count under the product of the purchase-order line its `po_item_id` names, and under the bill line's own product only when it names none, so a keyed line with no product of its own still counts. Read this rather than `balance_due`, which on a purchase order is the ORIGINAL COMMITMENT the header was raised for and is never decremented when a bill is raised (the payable is the bill). billed_by_bill: type: array readOnly: true description: > Per bill whose goods lines count toward this purchase order (the lines `billed_total` sums, here for every bill status): `goods_on_po`, the goods it bills on this purchase order, and `goods_total`, the goods it carries in all. A bill that also bills another purchase order shows `goods_on_po` below `goods_total`; on a bill of this purchase order alone the two are equal. Each entry carries the bill's `status`, so a reader that names the bills that billed these goods can leave a voided bill out. An empty array when no bill bills it, never null. items: type: object properties: bill_id: type: string format: uuid bill_number: type: string nullable: true goods_on_po: type: number description: The goods this bill bills on this purchase order. goods_total: type: number description: >- The goods this bill carries across every purchase order it bills. status: type: string nullable: true description: >- The bill's own status, the same value the vendor bill carries (a voided bill billed nothing). landed_bills: type: array readOnly: true description: >- The landed bills that reach this purchase order (the Linked Documents card): a Case-A bill, a landed-only bill naming the PO, or a receipt-set bill on its receipts. Identity only (no amounts); the allocations are getPurchaseOrderLandedCostsV1's. items: $ref: '#/components/schemas/PurchaseOrderLandedBill' PoFieldVerdict: type: object description: A single per-field editability verdict. properties: allowed: type: boolean reason: type: string nullable: true enum: - po_pending_approval_edit_locked - po_pending_approval_and_terminal - po_status_locked - po_status_unknown_locked - line_has_receipts - delete_blocked_on_processing - qty_below_received - notes_only_on_terminal description: > NULL when allowed. Otherwise a stable token; the client renders the prose. `po_status_unknown_locked` is the fail-closed answer for an order in a status the predicate has not ruled on, and is deliberately DISTINCT from `po_status_locked` so "we lock this on purpose" and "nobody has ruled on this" are never indistinguishable. PurchaseOrderLandedBill: type: object description: >- A landed bill that reaches a purchase order. Identity only on the purchase order itself; allocated_on_this_po only inside PurchaseOrderLandedCosts. properties: bill_id: type: string format: uuid bill_number: type: string vendor_id: type: string format: uuid vendor_name: type: string nullable: true bill_date: type: string format: date status: type: string mode: type: string enum: - case_a - po_landed - receipt_set description: >- case_a (goods and landed lines on a bill naming the PO), po_landed (a landed-only bill naming the PO) or receipt_set (a Case-B bill on this PO's receipts). categories: type: array items: type: string allocated_on_this_po: type: number description: Inside PurchaseOrderLandedCosts only. ErrorEnvelope: type: object description: | Canonical error response envelope. All API errors use this shape. required: - error - code properties: error: type: string description: Machine-readable error key example: not_found code: type: string description: Machine-readable error code (often same as error) example: not_found type: type: string enum: - validation_error - permission_error - not_found - conflict - rate_limit - internal - expand_error - not_implemented example: not_found hint: type: string description: Human-readable one-sentence explanation (English) example: >- The requested order does not exist or does not belong to this entity. param: type: string description: The parameter that caused the error, if applicable example: expand[0] required: type: string description: The scope required (only on insufficient_scope errors) example: accounts:read request_id: type: string description: >- Unique request ID for support tracing (maps to CloudWatch log stream) example: req_abc123 responses: Error: description: Error response (400/401/403/404/409/422/429/500) content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' securitySchemes: ApiKeyAuth: type: http scheme: bearer description: | API key issued per entity via Settings > Developers > API Keys. Each key carries scopes (e.g. orders:read, products:write). Bearer token format: Authorization: Bearer ark_live_ent__ Test keys use ark_test_ent__. Both are issued per entity via Settings > Developers > API Keys. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.