Skip to content

ATS-COM-FUL-007Complete the financial work requested by a post-sale document: Capability Test Specification

Markdown

ATS-COM-FUL-007

Complete the financial work requested by a post-sale document: Capability Test Specification

Markdown
  • DocumentProposed

KindAcceptance test setProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision2

Read atservices-commerce c8b66a98react-console baf6dae3

Complete the financial work requested by a post-sale document: Capability Test Specification ​

Coverage ​

The category map distinguishes available cases from missing proof. A covered category has a scenario; the lifecycle and permission audits retain gaps in exhaustive coverage. Proposed cases describe the intended verification and carry no execution result.

The interaction cases exercise review and resolve operations findings; detect stalled and inconsistent order work; process returned goods through inspection and disposition. They vary the upstream record or outcome and inspect the resulting work across the capability boundary. Workflow crossings also include stock, financial or application records when the flow depends on them. Existing test bindings retain their source anchors so a reviewer can distinguish supporting assertions from a complete workflow run.

Coverage

  • Rule covered
  • Transition covered
  • Validation covered
  • Permission covered
  • Edge gap: FND-COM-FUL-062
  • Failure covered
  • Boundary gap: FND-COM-FUL-062
  • Concurrency gap: FND-COM-FUL-062
  • Invariant covered
  • Interaction covered

Test Scenarios

9 scenarios proving CAP-COM-FUL-007; 8 bound to an existing test.

01 Repeated document requests share one adjustmentinvariantapitest
Proves
BR-CAP-COM-FUL-007-01 INV-DOM-COM-FUL-003-05
Preconditions
A cancellation document needs financial execution.
Steps
Ask twice for financial execution of the same cancellation.
Expected
Both requests identify the same adjustment and pending plan.
Data
Fixtures for repeated document requests share one adjustment.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#creates the adjustment once (the second request answers the first) with its steps pending
services-commerce:modules/fulfillment/tests/integration/db/register-tables.table.integration.spec.js#hold an enforcement once per obligation and cause (enforcements_cause_uq) and an adjustment once per document (financial_adjustments_document_uq)
Source
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#creates the adjustment once (the second request answers the first) with its steps pending
02 Planning preserves financial-step orderruleunittest
Proves
BR-CAP-COM-FUL-007-02 BR-CAP-COM-FUL-007-03 INV-DOM-COM-FUL-003-06
Preconditions
Documents vary payment, fees and amendment replacement invoices.
Steps
Build the adjustment plan for each fixture.
Expected
Steps retain their fixed order and keys, unpaid work uses only the memo and amendments apply freed funds to the replacement invoice first.
Data
Fixtures for planning preserves financial-step order.
Bound to
services-commerce:modules/fulfillment/tests/unit/adjustments/adjustment-planning.spec.js#plans the memo, the fee, the credit from the freed money, its application to the fee and the refund of the remainder, in that order, each under its key
services-commerce:modules/fulfillment/tests/unit/adjustments/adjustment-planning.spec.js#plans the memo alone for a line never paid, the fee invoice beside it when the terms charge one, and nothing without an invoice
services-commerce:modules/fulfillment/tests/unit/adjustments/adjustment-planning.spec.js#applies the freed money to an amendment’s new invoice before the remainder (11 §7.1, P7): a credit and its application by invoice id, then the credit of what is left
services-commerce:modules/fulfillment/tests/unit/adjustments/adjustment-planning.spec.js#spells every key commerce:{document_kind}:{document_id}:{step}
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#plans the five steps of 04 §6 in order with their keys: the memo, the fee, the credit from the freed money, its application, the refund of the remainder
Source
services-commerce:modules/fulfillment/tests/unit/adjustments/adjustment-planning.spec.js#plans the memo, the fee, the credit from the freed money, its application to the fee and the refund of the remainder, in that order, each under its key
03 Interrupted financial commands retain their retry keysfailureapitest
Proves
BR-CAP-COM-FUL-007-04 BR-CAP-COM-FUL-007-05 INV-DOM-COM-FUL-003-08
Preconditions
An adjustment command throws and later gives a temporary refusal.
Steps
Execute, interrupt, resume and exercise retryable refusal.
Expected
Recovery resends the same command key and temporary refusal leaves pending work without an exception.
Data
Fixtures for interrupted financial commands retain their retry keys.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#leaves the step submitted when the command throws, and the resume re-sends the same key
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#leaves a retryable refusal pending for the next run, with the attempt counted and no exception
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#stops at the refund: the four steps before it succeeded, the refund failed, the adjustment failed with adjustment_failed raised
Source
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#leaves the step submitted when the command throws, and the resume re-sends the same key
04 Processor-pending refunds wait for the final eventtransitionapitest
Proves
BR-CAP-COM-FUL-007-06
Preconditions
A refund remains pending at its processor.
Steps
Resume repeatedly, then exercise successful and failed refund events.
Expected
Pending processing consumes no failure attempts; the final event completes or fails the work appropriately.
Data
Fixtures for processor-pending refunds wait for the final event.
Bound to
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#is held pending at the processor, never failed, however many times it is asked again, with no exception
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#fails for Finance, with its exception, when the refund then fails at the processor
services-commerce:modules/fulfillment/tests/integration/services/facts/financial-facts-handler.integration.spec.js#holds the refund pending at the processor, not failed, and counts no failed attempt (COMM-M1 R7-2)
services-commerce:modules/fulfillment/tests/unit/adjustments/adjustment-pending-at-processor.spec.js#is true when the books are done and only the refund is pending at the processor
Source
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#is held pending at the processor, never failed, however many times it is asked again, with no exception
05 Staff can retry failure or record external settlementpermissionapinegativetest
Proves
BR-CAP-COM-FUL-007-08 BR-CAP-COM-FUL-007-09 BR-CAP-COM-FUL-007-10
Preconditions
Two adjustments have failed and a reader identity is available.
Steps
List with and without scope, retry one, resolve another, repeat and try reader actions.
Expected
Unscoped reads and unauthorized actions fail; retry sends only failed work and external resolution closes its finding without repetition.
Data
Fixtures for staff can retry failure or record external settlement.
Bound to
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#lists the order’s adjustments and the failed ones, answers one with its steps, and refuses a query naming neither an order nor a state
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#retries the failed adjustment on its route: the refund alone re-sent, completed; a reader is refused
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#resolves the other failed adjustment offline on its route, with its exception, and refuses a repeat
services-commerce:modules/operations/tests/integration/services/interventions/operations-interventions.integration.spec.js#retries the failed adjustment: resumed from the refund alone, completed, its exception resolved; a completed one is refused
services-commerce:modules/operations/tests/integration/services/interventions/operations-interventions.integration.spec.js#resolves the other failed adjustment offline, with its exception; a resolved one is refused
Source
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#lists the order’s adjustments and the failed ones, answers one with its steps, and refuses a query naming neither an order nor a state
06 Accounting commands preserve their required request shapesvalidationunittest
Proves
BR-CAP-COM-FUL-007-11
Preconditions
Fixtures represent every financial step.
Steps
Send commands against successful, refusal and server-error answers.
Expected
Requests retain the expected keys and quantities, refusals are classified and interrupted work remains recoverable.
Data
Fixtures for accounting commands preserve their required request shapes.
Bound to
services-commerce:modules/fulfillment/tests/unit/adjustments/accounting-adjustment-commands.spec.js#sends the credit memo to POST /credit_memos/{tenantId} with the key twice, the lines as money, and answers the memo’s id
services-commerce:modules/fulfillment/tests/unit/adjustments/accounting-adjustment-commands.spec.js#sends every memo line’s quantity as Accounting’s contract has it, a decimal string (0230: a number was refused 400)
services-commerce:modules/fulfillment/tests/unit/adjustments/accounting-adjustment-commands.spec.js#sends the fee invoice issued at once under the commerce source, the credit from the payment, its application and the refund executed, each to its route
services-commerce:modules/fulfillment/tests/unit/adjustments/accounting-adjustment-commands.spec.js#answers a refusal as failed with Accounting’s code, retryable for the refusals a later attempt may change and permanent for a decline
services-commerce:modules/fulfillment/tests/unit/adjustments/accounting-adjustment-commands.spec.js#throws when Accounting answers a server error or a document without an id, so the step stays submitted for the resume
Source
services-commerce:modules/fulfillment/tests/unit/adjustments/accounting-adjustment-commands.spec.js#sends the credit memo to POST /credit_memos/{tenantId} with the key twice, the lines as money, and answers the memo’s id
07 Adjustment retry closes the retained Finance findinginteractionapitest
Proves
BR-CAP-COM-FUL-007-08 BR-CAP-COM-FUL-008-03
Preconditions
A cancellation adjustment failed only at its refund step and has an open finding.
Steps
Retry with authorized staff credentials, then inspect the adjustment, steps and exception.
Expected
Only the refund is sent again; the adjustment completes and its failure finding closes.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#lists the order’s adjustments and the failed ones, answers one with its steps, and refuses a query naming neither an order nor a state
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#retries the failed adjustment on its route: the refund alone re-sent, completed; a reader is refused
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#resolves the other failed adjustment offline on its route, with its exception, and refuses a repeat
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#acknowledges then resolves the finding, with the interventions logged, the order’s history and the audit events recorded
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#refuses the queue to a portal member and the interventions to a reader (403), and a body without a reason (400)
Source
services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#lists the order’s adjustments and the failed ones, answers one with its steps, and refuses a query naming neither an order nor a state,services-commerce:modules/operations/tests/e2e/operations.e2e.spec.js#acknowledges then resolves the finding, with the interventions logged, the order’s history and the audit events recorded
08 Scheduled recovery resumes the keyed money processinteractionapitest
Proves
BR-CAP-COM-FUL-007-04 BR-CAP-COM-FUL-009-04
Preconditions
An active adjustment is older than fifteen minutes and its Accounting command can succeed.
Steps
Run the due adjustment check and inspect its steps, keys and final state.
Expected
The owning worker completes the adjustment under its retained keys.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Bound to
services-commerce:modules/operations/tests/integration/services/reconciler/reconciler.integration.spec.js#raises refund_without_cancellation once for the reversal the handler never saw, and resumes the stale adjustment to completion
Source
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#leaves the step submitted when the command throws, and the resume re-sends the same key,services-commerce:modules/operations/tests/integration/services/reconciler/reconciler.integration.spec.js#raises refund_without_cancellation once for the reversal the handler never saw, and resumes the stale adjustment to completion
09 Physical return disposition permits the requested money workinteractionapiproposed
Proves
BR-CAP-COM-FUL-007-06 BR-CAP-COM-FUL-015-08
Preconditions
A return authorizes two shipped shirts and refunds after disposition.
Steps
Receive and inspect both shirts, restock them, then process the requested refund confirmation.
Expected
Stock restoration precedes financial completion; processor-pending money remains unfinished until confirmation.
Data
An isolated workspace with the products, records, authority and quantities described in the preconditions.
Source
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#is held pending at the processor, never failed, however many times it is asked again, with no exception,services-commerce:modules/shipping/tests/integration/services/returns/return-receiving.integration.spec.js#restocks the two units at the bin they shipped from: the return_restock movement naming the disposition, on hand up two, the two reliefs reversed at 1500 with the restore_cogs fact of 3000

The Markdown files under specs/ in rhythmsoftware/rhythm-v2-docs are the canonical source of truth. This reader is a generated, read-only projection of them.