--- id: ATS-ACC-TRX-017 scope: CAP-ACC-TRX-017 product_area: accounting module: transactions revision: 2 status: proposed approved_by: null approved_at: null source_sha: services-accounting: f47cb263875bbc0c5640fba7dae6785ec32695f8 scenarios: - id: ATS-ACC-TRX-017-01 title: Summary currency groups reconcile with open items level: api proves: - BR-CAP-ACC-TRX-017-01 - INV-DOM-ACC-TRX-005-06 preconditions: USD and EUR bills coexist with held receipts and credit. steps: - do: Request current standing. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500 expected: >- Currency groups separately explain debt, overdue value, money and net position consistent with as-of items. negative: false data_needs: Two supported currencies. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500 - >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it agrees with the aging’s as-of read for the customer: the same open items, the same amounts - >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers one row per currency, the EUR invoice as its own row where 1.0 threw, in code order - TST-ACC-TRX-038 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500 category: invariant test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js assertion: >- it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500 - file: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js assertion: >- it agrees with the aging’s as-of read for the customer: the same open items, the same amounts provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it agrees with the aging’s as-of read for the customer: the same open items, the same amounts - file: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js assertion: >- it answers one row per currency, the EUR invoice as its own row where 1.0 threw, in code order provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers one row per currency, the EUR invoice as its own row where 1.0 threw, in code order binding_review: [] - id: ATS-ACC-TRX-017-02 title: Due today remains current level: unit proves: - BR-CAP-ACC-TRX-017-02 - INV-DOM-ACC-TRX-005-07 preconditions: Invoices are due today and yesterday. steps: - do: Calculate the customer summary. provenance: test source: >- services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue expected: Only the earlier date contributes to overdue debt. negative: false data_needs: Two due-date boundary examples. bound_to: - >- services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue - TST-ACC-TRX-143 provenance: test source: >- services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue category: boundary test_bindings: - file: >- services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js assertion: >- it counts an invoice due today as not yet overdue, and one due yesterday as overdue provenance: test source: >- services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue binding_review: [] - id: ATS-ACC-TRX-017-03 title: Primary-organization payables differ from own summary level: api proves: - BR-CAP-ACC-TRX-017-03 - INV-DOM-ACC-TRX-005-08 preconditions: >- One contact has primary affiliation and another only secondary affiliation. steps: - do: Read summaries and payable populations. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it keeps the contact’s figures its own: Acme’s invoices are not counted in Ivy’s summary (1.0’s balances.js) expected: >- Own summary excludes organization debt; primary payables include it and secondary payables do not. negative: false data_needs: Primary and secondary CRM ties. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it keeps the contact’s figures its own: Acme’s invoices are not counted in Ivy’s summary (1.0’s balances.js) - >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it describes the primary affiliate’s own open invoices, oldest first, then its organization’s, the totals summed - >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it describes only a secondary affiliate’s own invoices: only the primary affiliation is the contact’s organization - TST-ACC-TRX-038 - TST-ACC-TRX-059 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it keeps the contact’s figures its own: Acme’s invoices are not counted in Ivy’s summary (1.0’s balances.js) category: interaction test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js assertion: >- it keeps the contact’s figures its own: Acme’s invoices are not counted in Ivy’s summary (1.0’s balances.js) provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it keeps the contact’s figures its own: Acme’s invoices are not counted in Ivy’s summary (1.0’s balances.js) - file: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js assertion: >- it describes the primary affiliate’s own open invoices, oldest first, then its organization’s, the totals summed provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it describes the primary affiliate’s own open invoices, oldest first, then its organization’s, the totals summed - file: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js assertion: >- it describes only a secondary affiliate’s own invoices: only the primary affiliation is the contact’s organization provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it describes only a secondary affiliate’s own invoices: only the primary affiliation is the contact’s organization binding_review: [] - id: ATS-ACC-TRX-017-04 title: Payable description excludes inactive billing level: api proves: - BR-CAP-ACC-TRX-017-05 preconditions: 'Draft, void and outstanding real bills belong to one contact.' steps: - do: Describe eligible payment targets. provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it leaves out the contact’s draft and its void invoice expected: Only real outstanding debt appears with card and bank choices. negative: false data_needs: Invoices of each standing. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it leaves out the contact’s draft and its void invoice - >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it allows cards and e-checks for an invoice with no order, with no Commerce settings and no fee under a policy of none (the unit’s rule shown), the invoice as the API answers it - TST-ACC-TRX-059 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it leaves out the contact’s draft and its void invoice category: validation test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js assertion: it leaves out the contact’s draft and its void invoice provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it leaves out the contact’s draft and its void invoice - file: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js assertion: >- it allows cards and e-checks for an invoice with no order, with no Commerce settings and no fee under a policy of none (the unit’s rule shown), the invoice as the API answers it provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it allows cards and e-checks for an invoice with no order, with no Commerce settings and no fee under a policy of none (the unit’s rule shown), the invoice as the API answers it binding_review: [] - id: ATS-ACC-TRX-017-05 title: Fee quote uses eligible tender value once level: api proves: - BR-CAP-ACC-TRX-017-06 preconditions: Required-fee billing includes a single bill and two customer bills. steps: - do: 'Quote card, check and combined customer tender.' provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it quotes the card fee of a required invoice by its unit’s rule, on the balance or on the amount tendered, and none for a check expected: >- Balance or requested tender determines the card fee, check adds none and combined value pays one fee. negative: false data_needs: A unit fee rule. bound_to: - >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it quotes the card fee of a required invoice by its unit’s rule, on the balance or on the amount tendered, and none for a check - >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it quotes the totals’ card fee for a customer whose invoices bear the fee: the rule once over the card amount - TST-ACC-TRX-059 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it quotes the card fee of a required invoice by its unit’s rule, on the balance or on the amount tendered, and none for a check category: rule test_bindings: - file: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js assertion: >- it quotes the card fee of a required invoice by its unit’s rule, on the balance or on the amount tendered, and none for a check provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it quotes the card fee of a required invoice by its unit’s rule, on the balance or on the amount tendered, and none for a check - file: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js assertion: >- it quotes the totals’ card fee for a customer whose invoices bear the fee: the rule once over the card amount provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it quotes the totals’ card fee for a customer whose invoices bear the fee: the rule once over the card amount binding_review: [] - id: ATS-ACC-TRX-017-06 title: Summary access and empty standing are distinct level: api proves: - BR-CAP-ACC-TRX-017-07 preconditions: One identity lacks read authority and a customer has no open items. steps: - do: Request each summary. provenance: test source: >- services-accounting:modules/transactions/tests/e2e/customer-summary.e2e.spec.js#it reads with accounting.invoices.read alone and refuses a principal without it (403 permission_missing) expected: >- Unauthorized request fails and authorized empty standing returns no currency groups. negative: false data_needs: Permission and empty-customer examples. bound_to: - >- services-accounting:modules/transactions/tests/e2e/customer-summary.e2e.spec.js#it reads with accounting.invoices.read alone and refuses a principal without it (403 permission_missing) - >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers no currencies and no activity date for a customer with nothing open (1.0’s zero balance), and for a customer CRM does not know - TST-ACC-TRX-005 - TST-ACC-TRX-038 provenance: test source: >- services-accounting:modules/transactions/tests/e2e/customer-summary.e2e.spec.js#it reads with accounting.invoices.read alone and refuses a principal without it (403 permission_missing) category: permission test_bindings: - file: >- services-accounting:modules/transactions/tests/e2e/customer-summary.e2e.spec.js assertion: >- it reads with accounting.invoices.read alone and refuses a principal without it (403 permission_missing) provenance: test source: >- services-accounting:modules/transactions/tests/e2e/customer-summary.e2e.spec.js#it reads with accounting.invoices.read alone and refuses a principal without it (403 permission_missing) - file: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js assertion: >- it answers no currencies and no activity date for a customer with nothing open (1.0’s zero balance), and for a customer CRM does not know provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers no currencies and no activity date for a customer with nothing open (1.0’s zero balance), and for a customer CRM does not know binding_review: [] - id: ATS-ACC-TRX-017-07 title: Payment-plan hold should preserve aging level: api proves: - BR-CAP-ACC-TRX-017-08 preconditions: Billing places an outstanding invoice on a plan. steps: - do: 'Set hold, inspect standing and clear hold.' provenance: proposed source: >- services-accounting:docs/architecture/accounting-2.0/02-decisions.md#C-9 expected: >- The proposed summary identifies the plan without changing dates or aging, then restores collections eligibility. negative: false data_needs: A Billing service caller. bound_to: [] provenance: proposed source: 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#C-9' category: interaction test_bindings: [] binding_review: [] - id: ATS-ACC-TRX-017-08 title: Current standing and captured aging keep distinct cutoffs category: interaction level: api proves: - BR-CAP-ACC-TRX-017-01 - BR-CAP-ACC-TRX-017-02 - BR-CAP-ACC-TRX-016-06 - BR-CAP-ACC-TRX-018-02 - BR-CAP-ACC-TRX-018-05 - BR-CAP-ACC-TRX-019-01 - BR-CAP-ACC-TRX-019-03 exercises: - CAP-ACC-TRX-017 - CAP-ACC-TRX-016 - CAP-ACC-TRX-018 - CAP-ACC-TRX-019 preconditions: >- An isolated workspace has eligible customers, products, matching accounts, an open period and two open batches. Each branch owns separate financial records. steps: - do: >- Set customer-default terms, create an 80.00 bill, inspect its transaction row and current summary, then capture month-end aging. Record a backdated 20.00 reduction after the cutoff and read both surfaces again. provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500; services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-016-find-transactions-and-see-what-can-be-done-next.md#BR-CAP-ACC-TRX-016-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-018-report-receivables-at-a-past-month-end.md#BR-CAP-ACC-TRX-018-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-018-report-receivables-at-a-past-month-end.md#BR-CAP-ACC-TRX-018-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-019-record-a-customer-s-collection-terms.md#BR-CAP-ACC-TRX-019-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-019-record-a-customer-s-collection-terms.md#BR-CAP-ACC-TRX-019-03 expected: >- Terms establish the due date used for overdue classification; current debt becomes 60.00 while the earlier capture remains 80.00; current transaction rows agree with the summary. negative: false data_needs: >- Separate command keys, two customers, invoice lines, receipts and credit; controlled processor outcomes and a fixed calendar where the branch requires them. bound_to: [] provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500; services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-016-find-transactions-and-see-what-can-be-done-next.md#BR-CAP-ACC-TRX-016-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-018-report-receivables-at-a-past-month-end.md#BR-CAP-ACC-TRX-018-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-018-report-receivables-at-a-past-month-end.md#BR-CAP-ACC-TRX-018-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-019-record-a-customer-s-collection-terms.md#BR-CAP-ACC-TRX-019-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-019-record-a-customer-s-collection-terms.md#BR-CAP-ACC-TRX-019-03 test_bindings: [] binding_review: [] evidence: - >- services-accounting at f47cb263875bbc0c5640fba7dae6785ec32695f8: the test files named in bound_to. - >- rhythm-v2-docs:specs/accounting/transactions/design: related workflows, domain invariants and state transitions examined for the back-fill. coverage: rule: covered transition: not-applicable validation: covered permission: covered edge: 'gap: FND-ACC-TRX-082' failure: 'gap: FND-ACC-TRX-082' boundary: covered concurrency: 'gap: FND-ACC-TRX-082' invariant: covered interaction: covered coverage_notes: transition: >- The current financial summary and payable description are derived reads; changes to their inputs belong to the owning financial capabilities. edge: >- No dedicated edge scenario covers the applicable conditions; the finding identifies the remaining specification work. failure: >- No dedicated failure scenario covers the applicable conditions; the finding identifies the remaining specification work. concurrency: >- No dedicated concurrency scenario covers the applicable conditions; the finding identifies the remaining specification work. interaction_coverage: - to: CAP-ACC-TRX-016 scenarios: - ATS-ACC-TRX-017-08 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500; services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-016-find-transactions-and-see-what-can-be-done-next.md#BR-CAP-ACC-TRX-016-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-018-report-receivables-at-a-past-month-end.md#BR-CAP-ACC-TRX-018-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-018-report-receivables-at-a-past-month-end.md#BR-CAP-ACC-TRX-018-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-019-record-a-customer-s-collection-terms.md#BR-CAP-ACC-TRX-019-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-019-record-a-customer-s-collection-terms.md#BR-CAP-ACC-TRX-019-03 - to: CAP-ACC-TRX-018 scenarios: - ATS-ACC-TRX-017-08 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500; services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#BR-CAP-ACC-TRX-017-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-016-find-transactions-and-see-what-can-be-done-next.md#BR-CAP-ACC-TRX-016-06; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-018-report-receivables-at-a-past-month-end.md#BR-CAP-ACC-TRX-018-02; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-018-report-receivables-at-a-past-month-end.md#BR-CAP-ACC-TRX-018-05; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-019-record-a-customer-s-collection-terms.md#BR-CAP-ACC-TRX-019-01; rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-019-record-a-customer-s-collection-terms.md#BR-CAP-ACC-TRX-019-03 transition_coverage: [] permission_coverage: - key: accounting.invoices.read where_checked: api gap: FND-ACC-TRX-082 provenance: unknown source: FND-ACC-TRX-082 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#CAP-ACC-TRX-017 - key: accounting.payments.read where_checked: api gap: FND-ACC-TRX-082 provenance: unknown source: FND-ACC-TRX-082 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#CAP-ACC-TRX-017 - key: accounting.credits.read where_checked: api gap: FND-ACC-TRX-082 provenance: unknown source: FND-ACC-TRX-082 note: >- Existing permission scenarios are retained; assertion-level coverage of this grant at every declared surface remains unverified. evidence: - >- rhythm-v2-docs:specs/accounting/transactions/planning/capabilities/CAP-ACC-TRX-017-know-where-a-customer-stands.md#CAP-ACC-TRX-017 rule_coverage: - rule: BR-CAP-ACC-TRX-017-01 scenarios: - ATS-ACC-TRX-017-01 - ATS-ACC-TRX-017-08 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500 - rule: BR-CAP-ACC-TRX-017-02 scenarios: - ATS-ACC-TRX-017-02 - ATS-ACC-TRX-017-08 provenance: proposed source: >- services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue - rule: BR-CAP-ACC-TRX-017-03 scenarios: - ATS-ACC-TRX-017-03 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it keeps the contact’s figures its own: Acme’s invoices are not counted in Ivy’s summary (1.0’s balances.js) - rule: BR-CAP-ACC-TRX-017-05 scenarios: - ATS-ACC-TRX-017-04 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it leaves out the contact’s draft and its void invoice - rule: BR-CAP-ACC-TRX-017-06 scenarios: - ATS-ACC-TRX-017-05 provenance: proposed source: >- services-accounting:modules/transactions/tests/integration/services/invoices/payable-invoices.integration.spec.js#it quotes the card fee of a required invoice by its unit’s rule, on the balance or on the amount tendered, and none for a check - rule: BR-CAP-ACC-TRX-017-07 scenarios: - ATS-ACC-TRX-017-06 provenance: proposed source: >- services-accounting:modules/transactions/tests/e2e/customer-summary.e2e.spec.js#it reads with accounting.invoices.read alone and refuses a principal without it (403 permission_missing) - rule: BR-CAP-ACC-TRX-017-08 scenarios: - ATS-ACC-TRX-017-07 provenance: proposed source: FND-ACC-TRX-005 executable_gaps: - scenario: ATS-ACC-TRX-017-07 gap: FND-ACC-TRX-082 provenance: unknown source: FND-ACC-TRX-082 evidence: - 'services-accounting:docs/architecture/accounting-2.0/02-decisions.md#C-9' - scenario: ATS-ACC-TRX-017-08 gap: FND-ACC-TRX-082 provenance: unknown source: FND-ACC-TRX-082 evidence: - >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it answers, as of today, its two open invoices (owing 9000), the overdue one (4000), the check’s 1000 unapplied, the 1500 credit, a net position of 6500; services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue invariant_coverage: - invariant: INV-DOM-ACC-TRX-005-06 scenarios: - ATS-ACC-TRX-017-01 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it agrees with the aging’s as-of read for the customer: the same open items, the same amounts note: >- The cited scenario and its constituent test assertions are the proof boundary. - invariant: INV-DOM-ACC-TRX-005-07 scenarios: - ATS-ACC-TRX-017-02 provenance: test source: >- services-accounting:modules/transactions/tests/unit/rules/customer-summary.spec.js#it counts an invoice due today as not yet overdue, and one due yesterday as overdue note: >- The cited scenario and its constituent test assertions are the proof boundary. - invariant: INV-DOM-ACC-TRX-005-08 scenarios: - ATS-ACC-TRX-017-03 provenance: test source: >- services-accounting:modules/transactions/tests/integration/services/customers/customer-summary.integration.spec.js#it keeps the contact’s figures its own: Acme’s invoices are not counted in Ivy’s summary (1.0’s balances.js) note: >- The cited scenario and its constituent test assertions are the proof boundary. --- # Explain a customer’s current financial position: Capability Test Specification ## Coverage The structured coverage map distinguishes specified examples from missing category coverage. Every required rule names its proving scenarios in the structured rule coverage register. A scenario’s executable binding applies only to the cited assertions; the transition and permission registers retain the combinations that still need explicit proof. ## Interactions With Related Capabilities Set customer-default terms, create an 80.00 bill, inspect its transaction row and current summary, then capture month-end aging. Record a backdated 20.00 reduction after the cutoff and read both surfaces again. Terms establish the due date used for overdue classification; current debt becomes 60.00 while the earlier capture remains 80.00; current transaction rows agree with the summary. The complete chain remains proposed until one executable run proves its combined outcomes.