Skip to content

CAP-COM-FUL-007Complete the financial work requested by a post-sale document

Markdown

CAP-COM-FUL-007

Complete the financial work requested by a post-sale document

Markdown
  • DocumentDraft
  • Product intentProposed
  • ImplementationObserved

KindCapabilityProduct areaCommerceModuleFulfillment, Shipping and InventoryRevision1

Read atservices-commerce c8b66a98react-console baf6dae3

Complete the financial work requested by a post-sale document ​

Purpose ​

Post-sale financial changes progress through recoverable steps.

How It Works ​

A cancellation, return, amendment or void requests its financial work at the appropriate point. Commerce records a plan of Accounting commands for that document. The worker advances through the plan and retains each returned financial reference. Interrupted work resumes from its recorded progress. Processor-pending refunds remain waiting for their later outcome. Staff can retry failed work or record an external settlement through the service. The product should explain which financial step is waiting and who can resolve it.

Relationships ​

  • Review and resolve operations findings supplies or consumes related delivery records.
  • Detect stalled and inconsistent order work supplies or consumes related delivery records.
  • Process returned goods through inspection and disposition supplies or consumes related delivery records.

The Formal Contract

The narrative above explains; the sections below are authoritative — the rules, scenarios and tests this document binds.

Outcomes
Document-directed financial settlement avoids duplicate payment execution.Finance can identify and recover a failed financial step.
Surfaces
jobapiconsole

Controls

34 controls apply, from the corpus control catalogue.

TC-IAM-006 TC-AZ-001 TC-AZ-002 TC-AZ-003 TC-AZ-004 TC-AZ-005 TC-AZ-006 TC-TEN-001 TC-TEN-002 TC-TEN-003 TC-CRY-001 TC-DAT-001 TC-DAT-002 TC-DAT-003 TC-DAT-004 TC-LOG-001 TC-LOG-002 TC-LOG-003 TC-LOG-004 TC-LOG-005 TC-AVL-004 TC-MON-001 TC-MON-002 TC-MON-004 TC-PI-001 TC-PI-002 TC-PI-003 TC-PI-004 TC-PI-005 TC-VEN-001 TC-VEN-002 TC-VEN-003 TC-PRV-001 TC-PRV-002

Permissions

KeyChecked atScope
commerce.adjustments.readapitenant
commerce.adjustments.retryapitenant
commerce.adjustments.resolveapitenant

Business Rules

12 rules, 10 to be proved before approval. A rule's product intent is derived from its origin: 0 confirmed by a product decision, the rest inheriting this capability's proposed.

IdRuleKindEnforced atProvenance
01must prove
Proposed
A cancellation, return, amendment or void document has at most one financial adjustment, and repeated requests return that adjustment.
no proof recorded yet
invariantservice, databasetest
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
02must prove
Proposed
Adjustment planning fixes the sequence as original-invoice credit memo, any fee invoice, freed-money credit and fee application, then refund or credit of the remainder; unpaid lines need only a memo and zero fees create no fee invoice.
no proof recorded yet
calculationservicetest
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
03must prove
Proposed
An amendment applies freed money to its new invoice before crediting any remainder.
no proof recorded yet
calculationservicetest
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
04must prove
Proposed
Each financial step uses its own document-derived key, is marked submitted before sending and stores Accounting's reference before advancing, so recovery resends an interrupted step under the same key.
origin: D-P5-06 (build decision, not a product ruling): services-commerce:docs/migrations/operations/README.md#D-P5-06
no proof recorded yet
invariantservicetest
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
05must prove
Proposed
Permanent refusal fails the adjustment with an exception; retryable refusal retains pending work and counts attempts, raising no exception until five attempts are exhausted.
no proof recorded yet
lifecycleservicetest
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
06must prove
Proposed
A processor-pending refund does not consume failure attempts, completes on its refund event and fails with a Finance exception if the processor reports failure.
origin: COMM-M1 R7-2 (repair report, not a product ruling): services-commerce:docs/milestones/COMM-M1-repairs-7-report.md#R7-2
no proof recorded yet
lifecycleservicetest
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
07
Proposed
The originating document controls when its financial adjustment is requested, and the worker moves money only after that request.
policyserviceobserved
08must prove
Proposed
Sensitive retry authority lets staff resume a failed adjustment from its failed step with a reason and close its exception on completion; completed adjustments reject retry.
no proof recorded yet
permissionapi, servicetest
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
09must prove
Proposed
Staff can resolve an externally settled failed adjustment with a reason and resolution, closing its exception and rejecting another resolution.
no proof recorded yet
lifecycleapi, servicetest
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
10must prove
Proposed
Adjustment lists require an order or state filter, while an individual adjustment includes its full step list.
no proof recorded yet
validationapitest
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
11must prove
Proposed
Accounting commands retain step keys, decimal-text memo quantities and immediately issued Commerce fee invoices, classify refusals for retry, and leave server errors or missing document identities for recovery.
no proof recorded yet
policyservicetest
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
12
Proposed
A financial event resumes active adjustments for the affected orders, allowing a later refund confirmation to finish the originating document.
origin: COMM-M1 R6-2 (repair report, not a product ruling): services-commerce:docs/milestones/COMM-M1-repairs-6-report.md#R6-2
lifecycleservicetest

Scenarios

IdGivenWhenThenProvenance
01A cancellation fee was processed before its refund was declined.Retry the failed adjustment as staff.Only the remaining refund step is resent and the adjustment completes.test
services-commerce:modules/fulfillment/tests/integration/services/adjustments/adjustment-worker.integration.spec.js#resumes from the failed step alone on the retry: only the refund is sent again, and completes

Edge Cases

IdGivenWhenThenProvenance
02The processor says a refund is still pending.Resume the adjustment repeatedly.Processing remains pending without consuming failure attempts or raising an exception.test
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

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.