Examination findings and product questions
Findings
| id | severity | statement | affects | evidence | kind |
|---|---|---|---|---|---|
FND-COM-ORD-001 | medium | The staff-order plan retains a pending approval label, but the milestone index, milestone record and handoff record Andrew’s approval and instruction to build on the recommended choices. Confirmed intent here follows those approval records. The product should reconcile the plan’s stale approval text. | MOD-COM-ORD, FEAT-COM-ORD-01, FEAT-COM-ORD-02, FEAT-COM-ORD-03, FEAT-COM-ORD-04 | See finding_evidence | inconsistency |
FND-COM-ORD-002 | low | The milestone index and individual milestone record disagree about progress: the index retains an in-progress catalog entry and omits the staff-order record, while the individual record reports catalog acceptance. The product should update the index to match the authoritative records. | MOD-COM-ORD | See finding_evidence | inconsistency |
FND-COM-ORD-003 | medium | The pinned console revision contains component tests but lacks the draft’s referenced acceptance inventory and browser journey specifications. Earlier identifiers remain in supersedes as historical seeds. Browser acceptance remains proposed because the named browser proof cannot be bound at this revision. | MOD-COM-ORD, JNY-COM-ORD-001, JNY-COM-ORD-002, JNY-COM-ORD-003, JNY-COM-ORD-004, JNY-COM-ORD-005, JNY-COM-ORD-006 | See finding_evidence | inconsistency |
FND-COM-ORD-004 | medium | The installment engine currently coordinates with Accounting, while the realignment record assigns future installment ownership to Billing. Approval of the full revised milestone sequence is still pending. The product should define the handover before promising a customer-facing plan workflow. | CAP-COM-ORD-009, BR-CAP-COM-ORD-009-07 | See finding_evidence | debt |
FND-COM-ORD-005 | medium | Tax ownership differs across the staff-order plan and the later realignment. The records describe an interim Commerce zone provider and an Accounting provider that is not enabled. The settled no-tax-address refusal does not confirm every provider, zone or address-selection choice; those choices remain proposed. | BR-CAP-COM-ORD-003-06, BR-CAP-COM-ORD-006-08, CAP-COM-ORD-003 | See finding_evidence | inconsistency |
FND-COM-ORD-006 | medium | The Accounting tax refusal test expects a bad-request response at placement, unlike the conflict response used by other placement refusals. The recorded review leaves that difference in place. The product should decide whether callers should handle one consistent refusal shape. | CAP-COM-ORD-005, CAP-COM-ORD-003 | See finding_evidence | inconsistency |
FND-COM-ORD-007 | low | The staff-order narrative retains an earlier statement that eligibility service publication is unavailable. The pinned service-call declaration and later milestone entry show publication and switch-on. The product should remove the stale dependency statement. | BR-CAP-COM-ORD-003-04, BR-CAP-COM-ORD-005-07, BR-CAP-COM-ORD-004-07 | See finding_evidence | inconsistency |
FND-COM-ORD-008 | medium | The no-address ship-to refusal extends the recorded deleted-contact decision, but its test describes the message as Andrew’s decision. Shipping’s refusal also differs from the tax path’s buyer-address fallback. The product should resolve the intended shared address behavior. | BR-CAP-COM-ORD-003-08, BR-CAP-COM-ORD-003-06, OQ-COM-ORD-002 | See finding_evidence | inconsistency |
FND-COM-ORD-009 | medium | Pure helper tests exercise the two ship-to checks. They do not establish preview and placement behavior through the complete API paths, and the draft declares no compliance control for the checks. The product should add route-level proof before relying on their complete purchase coverage. | BR-CAP-COM-ORD-003-07, BR-CAP-COM-ORD-003-08 | See finding_evidence | debt |
FND-COM-ORD-010 | low | The documented prepayment delivery exception applies to console terms purchases; the portal terms path still waits for payment. The milestone record identifies that distinction as unresolved product behavior. | BR-CAP-COM-ORD-006-10 | See finding_evidence | inconsistency |
FND-COM-ORD-011 | medium | The repair record reports that a failed promotion-sum invariant reaches the caller as an unexplained server outcome. The product should specify a usable refusal and retain a scenario for the invariant failure. | CAP-COM-ORD-005 | See finding_evidence | debt |
FND-COM-ORD-012 | medium | The partial-payment void evidence uses an Accounting stand-in that does not model real Accounting’s over-application rejection. It therefore does not establish that the production contract accepts credit after refund. The product should validate the settlement ordering against the actual Accounting contract. | BR-CAP-COM-ORD-008-06 | See finding_evidence | debt |
FND-COM-ORD-013 | low | The order-list report describes full order reads for each row, including lines, tenders and invoices. It identifies a smaller list response as future work. The product should assess that work using realistic list volume rather than infer scalability from the current page size. | CAP-COM-ORD-010 | See finding_evidence | debt |
FND-COM-ORD-014 | medium | The repair record identifies different process-reference length limits in checkout and the shared participant contract. Long references can be omitted when passed to an application. The product should align the limits and prove the full reference survives the call. | BR-CAP-COM-ORD-001-12, CAP-COM-ORD-012 | See finding_evidence | debt |
FND-COM-ORD-015 | medium | The staff-order plan expects prompt financial updates after Accounting payments, while its dependency record reports missing receivable events in development. Sweep-based refresh remains the documented fallback; this examination does not establish that live event delivery has since recovered. | BR-CAP-COM-ORD-010-06, JNY-COM-ORD-002 | See finding_evidence | inconsistency |
FND-COM-ORD-016 | low | The shipping repair record describes placement rejecting a shipping charge whose policy has no shipping product, although preview does not surface the configuration problem. The product should expose that blocker before staff attempt placement. | BR-CAP-COM-ORD-005-11 | See finding_evidence | defect |
FND-COM-ORD-017 | low | The list report describes organization order detail as contact-route-only. The pinned console also provides the workspace Orders detail route. The product should reconcile the report with the available route. | CAP-COM-ORD-010 | See finding_evidence | inconsistency |
FND-COM-ORD-018 | low | Twelve published permission keys have no corresponding operation in this scope: checkout delete and bulk; order update, delete and bulk; return-policy update and bulk; purchasing bulk; and inventory-costing create, delete and bulk. Return-policy replacement uses deletion and creation because no edit operation exists. | CAP-COM-ORD-011, CAP-COM-ORD-016, CAP-COM-ORD-017, CAP-COM-ORD-018, BR-CAP-COM-ORD-011-08, BR-CAP-COM-ORD-016-12 | See finding_evidence | debt |
FND-COM-ORD-019 | medium | The inherited scope description overlooks contact-based order pages, the list and detail components, and their supporting composer and list layers. Operations shares the Orders area but belongs to fulfilment. The module’s source and coverage declarations distinguish these boundaries; this examination changes only the authorized registry status. | MOD-COM-ORD | See finding_evidence | inconsistency |
FND-COM-ORD-020 | medium | The post-sale promotion report describes audience-restricted promotions being refused without an eligibility verdict, even for a qualifying buyer. The product should establish and prove the intended eligibility evaluation for this amendment path. | BR-CAP-COM-ORD-015-10 | See finding_evidence | defect |
FND-COM-ORD-021 | low | The promotion report records a generic eligibility refusal where the plan proposes a more specific message for a nonmember-only offer. The product should choose the customer explanation and align the scenario with that choice. | BR-CAP-COM-ORD-004-07 | See finding_evidence | inconsistency |
FND-COM-ORD-022 | low | The earlier staff-order walkthrough includes Membership purchases, but a later recorded decision hides Membership in the live composer until its commerce milestone. The product should align the walkthrough with that restriction; same-purchase member pricing is not a complete live staff journey at this stage. | BR-CAP-COM-ORD-003-11, BR-CAP-COM-ORD-003-12, JNY-COM-ORD-001 | See finding_evidence | inconsistency |
FND-COM-ORD-023 | medium | The milestone record distinguishes purchase-eligibility checks in cart preview and placement from quotes and staff promotion preview that do not apply them. A quoted amount consequently does not establish permission to buy. The product should resolve that catalog boundary with its owning module. | BR-CAP-COM-ORD-003-04 | See finding_evidence | debt |
FND-COM-ORD-024 | low | The same-purchase member-price evidence uses a stand-in participant. Membership’s actual declaration of package-granted audiences remains a dependency. The product should obtain proof from that application before treating the integration as complete. | BR-CAP-COM-ORD-003-11 | See finding_evidence | debt |
FND-COM-ORD-025 | low | The plain-product participant declares the Accounting product type, while the recorded donation decision is conditional on donations using orders. No donation type is declared here. The product should decide that route before adding the type. | BR-CAP-COM-ORD-012-08, OQ-COM-ORD-003 | See finding_evidence | debt |
FND-COM-ORD-026 | medium | The draft identifies no console configuration screen for product grants and records removal of the Accounting product entitlement section. Grant declaration is available through the API, while the later entitlement milestone remains proposed. The product should define the configuration experience before claiming a staff workflow. | CAP-COM-ORD-013, BR-CAP-COM-ORD-013-13 | See finding_evidence | debt |
FND-COM-ORD-027 | medium | The after-sale record leaves live console integration, execution of future-dated amendments, automatic return-authorization expiry and fee waiver work outstanding. Existing sample-data dialogs do not prove those operational outcomes. The product should resolve the remaining scope before designing self-service changes. | CAP-COM-ORD-014, CAP-COM-ORD-015, CAP-COM-ORD-016 | See finding_evidence | debt |
FND-COM-ORD-028 | low | The order-list report notes that a cancelled purchase refunded to zero meets the money-based Paid filter. It asks whether that grouping serves managers. The product should confirm whether financial position alone determines the filter. | BR-CAP-COM-ORD-010-03 | See finding_evidence | inconsistency |
FND-COM-ORD-029 | low | The support-attribution report relies on a stand-in identity and does not verify Platform’s actual support actor identifier. The product should verify that identity before treating the attribution as an integrated support workflow. | BR-CAP-COM-ORD-011-05 | See finding_evidence | undocumented |
FND-COM-ORD-030 | low | The milestone index and proposed realignment assign different numbers to after-sale and merchandise work after inserting tax work. Earlier journey seeds retain their historical numbering. The product should select a single approved sequence for future planning. | CAP-COM-ORD-014, CAP-COM-ORD-017 | See finding_evidence | inconsistency |
FND-COM-ORD-031 | low | The purchasing record leaves vendor, purchase-order and costing screens for later work, and the merchandise milestone remains proposed. This layer describes the API implementation without establishing a completed console purchasing experience. | CAP-COM-ORD-017, CAP-COM-ORD-018, OQ-COM-ORD-004 | See finding_evidence | debt |
FND-COM-ORD-032 | medium | Some illustrative examples and three browser proposals refer to a console run branch unavailable at the pinned revision. Historical seed identifiers are retained, while unsupported example details point to this finding and carry unknown provenance. The browser scenarios remain unbound proposed work. | MOD-COM-ORD | See finding_evidence | inconsistency |
FND-COM-ORD-033 | high | Existing bindings leave specific clauses unproven: fixture settlement does not validate the live Accounting contract, rendered components do not establish browser handoffs, and helper checks do not prove their complete API callers. Mandatory rules with no scenario are named in affects. The complete transfer proposal also needs proof of uncovered quantities and absence of posting facts; its arithmetic test establishes rounding only. The product should close those rule-specific proof gaps before treating the layer as acceptance-ready. | MOD-COM-ORD, BR-CAP-COM-ORD-001-10, BR-CAP-COM-ORD-001-11, BR-CAP-COM-ORD-001-12, BR-CAP-COM-ORD-001-13, BR-CAP-COM-ORD-002-03, BR-CAP-COM-ORD-002-05, BR-CAP-COM-ORD-003-11, BR-CAP-COM-ORD-004-09, BR-CAP-COM-ORD-004-10, BR-CAP-COM-ORD-004-11, BR-CAP-COM-ORD-005-13, BR-CAP-COM-ORD-006-11, BR-CAP-COM-ORD-006-12, BR-CAP-COM-ORD-007-12, BR-CAP-COM-ORD-008-09, BR-CAP-COM-ORD-008-10, BR-CAP-COM-ORD-009-07, BR-CAP-COM-ORD-010-05, BR-CAP-COM-ORD-011-04, BR-CAP-COM-ORD-012-04, BR-CAP-COM-ORD-012-09, BR-CAP-COM-ORD-012-10, BR-CAP-COM-ORD-012-11, BR-CAP-COM-ORD-012-13, BR-CAP-COM-ORD-013-12, BR-CAP-COM-ORD-014-11, BR-CAP-COM-ORD-014-12, BR-CAP-COM-ORD-014-13, BR-CAP-COM-ORD-014-14, BR-CAP-COM-ORD-015-10, BR-CAP-COM-ORD-015-11, BR-CAP-COM-ORD-015-12, BR-CAP-COM-ORD-016-10, BR-CAP-COM-ORD-016-11, BR-CAP-COM-ORD-018-13, BR-CAP-COM-ORD-018-14 | See finding_evidence | debt |
FND-COM-ORD-034 | low | The supplied documentation revision lacks the requested authoring brief. Its intended exclusions cannot be independently examined. The module registry and this job’s instructions establish the scope used here. | MOD-COM-ORD | See finding_evidence | undocumented |
FND-COM-ORD-035 | medium | Reading an accepted installment purchase can create a missing Accounting schedule, link its invoices and refresh the money mirror while authorized only for order reading. The product should review the permission boundary and retry behavior of this write-performing read before design approval. | CAP-COM-ORD-009 | See finding_evidence | undocumented |
FND-COM-ORD-036 | high | One scheduled function runs every background pass of the module in a fixed order each minute, and the cart-expiry, hold, tender-window and entitlement-expiry passes rethrow any failure other than a refused transition. One record that fails unexpectedly therefore ends the run before the later passes (billing retry, uncertain payments, money mirrors, entitlement expiry, idempotency purge), and because each pass reads oldest first the same record can stop them again every minute. The product should isolate each pass and each record, as the financial passes already do, and alarm on a record that keeps failing. | WF-COM-ORD-006, ADR-COM-ORD-008, CAP-COM-ORD-001, CAP-COM-ORD-006, CAP-COM-ORD-007, CAP-COM-ORD-008, CAP-COM-ORD-013 | See finding_evidence | defect |
FND-COM-ORD-037 | medium | When a void asks Accounting to delete the provisional invoice and gets no answer, the outcome is recorded on the order as deferred, but no sweep or reconciler check retries the deletion, although the void's own description says a reconciler does. The voided sale's provisional invoice can stay in Accounting indefinitely. The product should add a keyed retry of deferred deletions or raise an exception for a person. | WF-COM-ORD-005, BR-CAP-COM-ORD-008-05 | See finding_evidence | defect |
FND-COM-ORD-038 | medium | Three declared lifecycle states are never entered: an order can move from accepted to closed but nothing closes an order (while returns and installment reads already accept a closed order); a cart can be cancelled but nothing cancels one; and a cart enters preparing only inside the placement transaction, so the declared return from preparing to open is never committed. The state models record these as declared but unreached. The product should decide what a closed order means (see the open question) and remove or implement the others. | STATE-COM-ORD-001, STATE-COM-ORD-004, OQ-COM-ORD-007, BR-CAP-COM-ORD-001-14 | See finding_evidence | inconsistency |
FND-COM-ORD-039 | medium | The reconciler's daily checks for scheduled amendments and overdue return authorizations are still skipped as waiting for the after-sale phase, although amendments with a future effective date and return authorizations with deadlines now exist. A future-dated amendment is never executed by the system and an authorization past its deadline never expires on its own. | WF-COM-ORD-011, WF-COM-ORD-013, STATE-COM-ORD-010, STATE-COM-ORD-012, FND-COM-ORD-027 | See finding_evidence | debt |
FND-COM-ORD-040 | medium | When a change order is accepted, its amendment is moved from awaiting payment to executing by a best-effort call whose failure is only logged. The later settlement ignores an amendment that is not executing, and no sweep moves it on, so an amendment can stay awaiting payment after its change order is paid and delivered. | WF-COM-ORD-011, STATE-COM-ORD-010 | See finding_evidence | defect |
FND-COM-ORD-041 | high | Every staff intervention (a void, an approval or rejection, a manual grant, revocation or restored use) writes Commerce's own intervention log and then sends the Platform audit event through a provider that defaults to an in-memory stand-in; the Platform writer does not exist yet, and the Platform provider only logs at error level. Interventions therefore reach no Platform audit store. The product should treat this as an open audit control and record it in the exception register until Platform's writer exists. | ADR-COM-ORD-014, WF-COM-ORD-005, WF-COM-ORD-009, WF-COM-ORD-010, SVC-COM-ORD-orders, SVC-COM-ORD-entitlements | See finding_evidence | debt |
FND-COM-ORD-042 | medium | Whether Commerce reaches Accounting depends on deployment variables: with none set, billing leaves every order pending, a payment is refused as unavailable, and the billing, uncertain-payment and mirror sweeps report "not configured" and do nothing. Nothing alarms on that state, so a function deployed without the variables looks idle rather than broken. The product should alarm when orders stay pending billing with no transport configured. | WF-COM-ORD-003, WF-COM-ORD-006, ADR-COM-ORD-005 | See finding_evidence | debt |
FND-COM-ORD-043 | medium | Order 360 previews a cancellation by creating a real cancellation request, which is evaluated, approved automatically when no approval is needed, and holds its lines against any other cancellation. Closing the dialog without confirming leaves that request standing; only a later preview in the same browser session withdraws it. A preview is therefore a write, and an abandoned one blocks the lines until someone withdraws it. The product should either withdraw the preview when the dialog closes or offer a plan read that writes nothing. | SCR-COM-ORD-006, WF-COM-ORD-010, BR-CAP-COM-ORD-014-07, BR-CAP-COM-ORD-014-11 | See finding_evidence | defect |
FND-COM-ORD-044 | low | Approving a cancellation, amendment or return from an Order 360 card sends a fixed sentence as the required reason, so the intervention log records that the approval happened on Order 360 but not why the person approved it. | SCR-COM-ORD-002, ADR-COM-ORD-014, OQ-COM-ORD-008 | See finding_evidence | inconsistency |
FND-COM-ORD-045 | medium | The live Order 360 read supplies no entitlements, so its Entitlements tab is always empty for a live order, which falls short of the planning statement that Order 360 can display a purchase's grants. The live screen also hides the Amend action because the live adapter declares no amendment options. | SCR-COM-ORD-002, SCR-COM-ORD-008, BR-CAP-COM-ORD-013-13 | See finding_evidence | defect |
FND-COM-ORD-046 | low | Cancelling every open quantity of an issued purchase order that has received nothing marks it received rather than cancelled or closed, because the status follows only whether any quantity is still open. | STATE-COM-ORD-013, BR-CAP-COM-ORD-017-04 | See finding_evidence | defect |
FND-COM-ORD-047 | low | The two Order 360 routes check no console permission before rendering, while the Orders list and New Order pages do. The service still refuses a read without order-read authority and the screen shows its access message, so nothing leaks, but the screens are inconsistent. | SCR-COM-ORD-002 | See finding_evidence | inconsistency |
FND-COM-ORD-048 | medium | The code names the Commerce architecture package and the Platform standards (persistence, queued work, indexing, row-level security, number seeds) as the records it implements, but they live in a repository this job could not read. Design statements that rest on those records cite the code's own references and the milestone records, and their design intent stays proposed until the architecture records are examined. | ADR-COM-ORD-003, ADR-COM-ORD-005, ADR-COM-ORD-007, ADR-COM-ORD-008, ADR-COM-ORD-009, RESP-COM | See finding_evidence | undocumented |
FND-COM-ORD-049 | low | No service module, workflow or screen of this module asks a model, so every design artifact carries an empty inference list and no inference directory exists. The conventions ask the module charter to say so in one sentence; the charter is a planning artifact this design pass does not edit. | MOD-COM-ORD | See finding_evidence | undocumented |
FND-COM-ORD-050 | medium | Orders keep their history in Commerce's own append-only order trail and publish no business events, change events or Quick Search entries; the Platform record-history and change-event capabilities are not adopted, although the service's instructions say Commerce follows Platform's rule when it gains them. Other applications learn of a sale only through the selling-application calls. The product should decide when orders adopt Platform history and events. | ADR-COM-ORD-013, SVC-COM-ORD-orders, RESP-COM | See finding_evidence | debt |
FND-COM-ORD-051 | low | Vendor and draft purchase-order replacements require the version read but leave contact, address and line detail optional, so a replacement that omits a stored value may clear it. That differs from the complete-payload rule Andrew adopted for CRM records; the omission behaviour is not proven by a test. | ADR-COM-ORD-015, SVC-COM-ORD-purchasing, BR-CAP-COM-ORD-017-01, BR-CAP-COM-ORD-017-03 | See finding_evidence | inconsistency |
FND-COM-ORD-052 | medium | Carts that are abandoned, placed or cancelled are meant to be deleted thirty days on, with their items and trail, but the retention sweep is not built; a deletion function exists with no caller. Finished carts therefore accumulate, including buyer and recipient references. | DOM-COM-ORD-001, WF-COM-ORD-006 | See finding_evidence | debt |
FND-COM-ORD-053 | medium | After a cancellation commits, the reduction or cancellation of the order's installment schedule is asked of Accounting and a deferred or refused answer is only recorded on the order's history and logged. No exception is raised, so the buyer's future installments can stay unreduced until someone happens to read the history. The product should raise an exception for a refused or deferred reduction and retry a deferred one. | WF-COM-ORD-007, WF-COM-ORD-010, BR-CAP-COM-ORD-009-06 | See finding_evidence | defect |
| FND-COM-ORD-054 | medium | Money-mirror reads and writes run in separate transactions, with no comparison against the age of the stored result. A slower refresh can replace newer Accounting figures with an older derivation. The product should require an age check or serialize the complete refresh. | WF-COM-ORD-008 | See finding_evidence | defect |
| FND-COM-ORD-055 | medium | The normal return workflow closes authorizations, but the authorization persistence update accepts any declared state without checking the prior state or locking the return. The design therefore cannot promise that a closed authorization is impossible to reopen. The product should decide whether this boundary needs an enforced lifecycle. | STATE-COM-ORD-012 | See finding_evidence | debt |
| FND-COM-ORD-056 | low | The draft treats acceptance as a uniform prerequisite for after-sale changes. Returns also admit closed orders, and after-sale promotions admit placed orders; these exceptions are now explicit. The declared closed state still has no producer, leaving its intended meaning open. | DOM-COM-ORD-005, STATE-COM-ORD-011, WF-COM-ORD-013, OQ-COM-ORD-007 | See finding_evidence | inconsistency |
| FND-COM-ORD-057 | medium | Several invariant rows cite one example test for a wider guarantee, including all cart mutations, all three after-sale document locks and concurrent one-order placement. Those tests support their examples; broader guarantees also depend on persistence and database constraints. The design records those supporting sources without treating the examples as complete acceptance proof. | DOM-COM-ORD-001, DOM-COM-ORD-002, DOM-COM-ORD-005 | See finding_evidence | debt |
| FND-COM-ORD-058 | medium | Finished carts retain purchasing-party and recipient references because the planned retention deletion has no sweep caller; abandonment alone does not remove their retained data. | CAP-COM-ORD-001, CAP-COM-ORD-011, WF-COM-ORD-006, SVC-COM-ORD-checkout | See control_backfill_evidence | control-gap | | FND-COM-ORD-059 | medium | Financial summary refresh writes without comparing the age of the stored result; a slower refresh can overwrite a newer derivation without a visible concurrency refusal. | WF-COM-ORD-008, SVC-COM-ORD-orders, CAP-COM-ORD-010 | See control_backfill_evidence | control-gap | | FND-COM-ORD-060 | medium | Order interventions retain local history, but the selected shared audit provider only logs the event and cannot publish it to the shared audit store; local evidence does not establish the complete privileged audit path. | CAP-COM-ORD-008, CAP-COM-ORD-013, CAP-COM-ORD-014, CAP-COM-ORD-015, CAP-COM-ORD-016, SVC-COM-ORD-orders, SVC-COM-ORD-entitlements, WF-COM-ORD-005, WF-COM-ORD-009, WF-COM-ORD-010, WF-COM-ORD-011, WF-COM-ORD-012, WF-COM-ORD-013 | See control_backfill_evidence | control-gap | | FND-COM-ORD-061 | medium | A deferred or refused installment reduction is recorded without an operational exception or an automatic continuation; the retained schedule can remain inconsistent with the cancelled purchase. | CAP-COM-ORD-009, CAP-COM-ORD-014, WF-COM-ORD-007, WF-COM-ORD-010, SVC-COM-ORD-orders | See control_backfill_evidence | control-gap | | FND-COM-ORD-062 | low | Some service permission fields combine keys with explanatory access text, while the authorization checker compares the entire field literally. The authorization catalogue preserves those descriptions as non-grantable annotations; normalized permission references need a separate corpus change. | AUTH-COM, SVC-COM-ORD-checkout, SVC-COM-ORD-orders, SVC-COM-FUL-data-operations | See control_backfill_evidence | undocumented |
Open Questions
| id | question | why_it_matters | options | recommendation | affects |
|---|---|---|---|---|---|
OQ-COM-ORD-001 | Should the existing installment engine remain available until Billing owns the arrangement? | New plans would create schedules that a later ownership transition must handle. | Retain the engine pending handover; hide plan selection now; retain Commerce ownership. | The product should retain the engine pending a defined Billing handover, while keeping staff-facing plan selection outside this milestone. | CAP-COM-ORD-009 |
OQ-COM-ORD-002 | Which address governs tax when a separate shipping contact is selected? | Shipping rejects a selected contact without an address while tax can use the buyer address. | Require the selected shipping address for both; keep different fallbacks; use the buyer fallback for both. | The product should use the selected shipping address for shipped goods and refuse when that address is absent. | BR-CAP-COM-ORD-003-06, BR-CAP-COM-ORD-003-08 |
OQ-COM-ORD-003 | Should plain-product sales include donations? | The donation decision is conditional and the participant does not declare that product type. | Declare donations in the plain-product participant; leave donation selling to a fundraising application. | The product should include donations in the plain-product contract unless a planned fundraising application owns that sale. | CAP-COM-ORD-012 |
OQ-COM-ORD-004 | Which module should own vendor purchasing and stock acquisition cost? | Acquisition and inventory movement currently cross the registered orders and fulfilment boundaries. | Move purchasing to inventory and fulfilment; retain its current orders home. | The product should move purchasing to the inventory and fulfilment module and update both scope records together. | FEAT-COM-ORD-07, CAP-COM-ORD-017, CAP-COM-ORD-018 |
OQ-COM-ORD-005 | How should cancellation affect the original order fee? | The fee decision does not establish a cancellation refund policy. | Refund on full cancellation only; retain the fee in every cancellation; configure the choice in checkout policy. | The product should refund the fee when all item lines are cancelled and retain it for a partial cancellation. | CAP-COM-ORD-014 |
OQ-COM-ORD-006 | Should Commerce publish a purchase operation to Submissions so a submission's purchase or entitlement stage can be satisfied? | Every Orders operation is unpublished today, while Submissions plans purchase and entitlement requirement stages that wait for a Commerce participant. | Publish a system-access checkout and placement contract for Submissions; let Submissions draw an existing entitlement only; keep purchases outside Submissions. | The product should let Submissions draw existing rights through the published consumption function now and decide a published checkout contract with the Submissions milestone that needs it. | ADR-COM-ORD-011, SVC-COM-ORD-checkout, SVC-COM-ORD-entitlements, CAP-COM-ORD-013 |
OQ-COM-ORD-007 | What does a closed order mean, and what closes it? | The lifecycle admits closed after acceptance and returns already accept a closed order, but nothing closes one, so reports and filters cannot rely on it. | Close an order when every line is delivered and its return window has passed; close it on staff request; drop the state. | The product should close an order automatically once every line is delivered or cancelled and no return window remains, keeping after-sale requests available to administrators. | STATE-COM-ORD-004, FND-COM-ORD-038, CAP-COM-ORD-010 |
OQ-COM-ORD-008 | Must a staff approval of a cancellation, amendment or return carry the approver's own reason? | Approvals are interventions whose reason is the audit record, but Order 360's cards send a fixed sentence. | Require a typed reason on every approval; accept a fixed sentence for an approval and require a reason for a rejection; let the policy decide. | The product should require the approver's own reason for every approval and rejection, as the void and the manual grant already do. | SCR-COM-ORD-002, FND-COM-ORD-044, ADR-COM-ORD-014 |