Commissions and Rebates
Release: Commission and Rebates – 27.2.9666.52256
Description
This release introduces the ability to control the Situation Date during payment document creation, allowing deferred rebates to be calculated and allocated based on the correct business period rather than the system posting date. It also fixes incorrect payment entry signs on credit memos and invoices, adds the Base Value FlowField to agreement lines, corrects period comment insertion in payment documents when “Payment Period Details” is active, and aligns French translations across the application.
User Stories
| Title | Description | Setup Instructions | Impact on previous version |
|---|---|---|---|
| [24104] – Base amount visible in agreement lines | A new calculated Base Value FlowField has been added to the Agreement Line Subform. It aggregates isaREB_Detailed Value.Base Value filtered by Agreement No. and Agreement Line No. The field is hidden by default and can be displayed through personalization. |
No setup required. Field is available via personalization on Agreement Lines page (8004403). Impacted objects: Table 8004402 (isaREB_Agreement Line), Page 8004403 (isaREB_Agreement Lines). | No breaking change. Additive field only. |
| [24106] – Period comment in payment documents with Payment Period Details | When “Payment Period Details” is active, the agreement description comment was not inserted in the generated sales/purchase credit memo or invoice lines. A HasInsertedAgreementComment guard now ensures one comment line (with Agreement Line Description) is inserted before the first non-zero period line. The period date range is now displayed on the Description field, and the agreement description moves to Description 2. |
No setup required. Behavior is automatic when Payment Period Details is enabled on agreements. Impacted objects: Codeunit 8004413 (isaREB_PaymentType_Customer), Codeunit 8004412 (isaREB_PaymentType_Vendor). | The layout of generated document lines changes: agreement description now appears as a separate comment line, and period date range is shown on the Description field instead. Users relying on the previous Description layout should review their reports. |
| [24107] – Manage Situation Date in Payment Document Creation | The Create Payment report (8004400) now includes a mandatory Situation Date field on the request page. Payment period resolution and balance calculations use this Situation Date instead of Posting Date, allowing business period and accounting date to differ independently. A new open-ended trailing entry is created per agreement line (Starting Date = Agreement Ending Date + 1, Ending Date = 0D) to capture post-agreement deferred amounts. Entry period filters across all payment type codeunits (Customer, Vendor, Employee) now explicitly exclude open-ended entries using >0D & <=SituationDate. A new Reference Date field is stored on Payment Entries and propagated from document lines through posting. New FlowFields Payment Amt. (Ref. Date) and Cum. Paym Amt. (Ref. Date) are added to the Entry table. The Entry page now shows Reference Date-based payment amounts and balance (hidden by default, available via personalization). The Payment page displays the Reference Date column. The PowerBI Period API v1.0 exposes a new paymentAmountReferenceDate field. |
On the Create Payment request page, the Situation Date field is now mandatory (defaults to WorkDate). Posting Date must not be earlier than Situation Date. Impacted objects: Report 8004400 (isaREB_Create Payment), Codeunit 8004408 (isaREB_Agreement Management), Table 8004408 (isaREB_Entry), Table 8004407 (isaREB_Payment Entry), Page 8004408 (isaREB_Payment), Page 8004409 (isaREB_Entry), Page 8004414 (isaREB_Period API v1.0), Table 8004410 (isaREB_Period Buffer), Codeunit 8004413 (isaREB_PaymentType_Customer), Codeunit 8004412 (isaREB_PaymentType_Vendor), Codeunit 8004414 (isaREB_PaymentType_Employee). New field isaREB_Reference Date added to: Sales Line, Sales Invoice Line, Sales Cr.Memo Line, Sales Shipment Line, Purchase Line, Purch. Inv. Line, Purch. Cr. Memo Line, Purch. Rcpt. Line and their corresponding page extensions. |
Breaking changes: (1) Entry period filters changed from SetRange(0D, Date) to SetFilter('>%1&<=% 2', 0D, Date) — extensions relying on the old filter behavior must be updated. (2) CalculatePaidAmount procedure in Period API v1.0 page renamed to CalculatePaidAmounts with an additional parameter — extensions overriding or referencing the old procedure will break. (3) The trailing open-ended entry (Ending Date = 0D) is now created for each agreement line — custom logic filtering on Ending Date must account for this. (4) Existing agreements must be re-evaluated to generate the new trailing entries. |
| [24177] – Align French Translations | French translations for “Commission & Rebates Agreement” are now consistently translated as “Contrat de Commission et Différés” across all supported French locales (fr-FR, fr-BE, fr-CA, fr-CH). Additional translations updated across all 16 supported languages. | No setup required. Translation files (.xlf) are updated automatically. | No breaking change. Translation-only update. |
Bugs
| Title | Description | Impact on previous version |
|---|---|---|
| [24105] – Payment documents with incorrect sign | When a credit memo was created and then canceled via an invoice (copy document), both entries appeared with the same sign in the agreement card, causing the cumulative balance to be doubled instead of zeroed. Root cause: No sign inversion was applied to Payment Entry amounts based on Agreement Type. Fix: In RunAfterPostSalesDoc (Codeunit 8004413) and RunAfterPostPurchaseDoc (Codeunit 8004412), amount sign is now negated based on Agreement Type (Sales vs Purchase) for both invoice and credit memo branches. Additionally, in GetPaymentDetails (Vendor codeunit), the Source No. for purchase invoices was incorrectly read from the Credit Memo header variable — this is now corrected. In the purchase credit memo branch, the Document Type was incorrectly set to Invoice — now correctly set to Credit Memo. |
Breaking change: Payment entries created after this update will have corrected signs. Historical payment entries created before this fix will retain their incorrect signs and may need manual correction or re-evaluation of affected agreements. Extensions subscribing to RunAfterPostSalesDoc or RunAfterPostPurchaseDoc that depend on the previous unsigned behavior should be reviewed. |
Events
No event added or updated in this release.