You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Bug][SubscriptionBilling]: "Prices Including VAT" handling is incomplete — contract billing invoice treats VAT‑exclusive Subscription Line amounts as VAT‑inclusive #8642
This is a follow-up to issue #7399 / PR #8066 (PDD-366). That PR fixed the initial sales-document side of the "Prices Including VAT" handling:
Subscription Line."Calculation Base Amount" is stripped of VAT when the originating Sales Header has Prices Including VAT = YES (SubscriptionLine.EnsureCalculationBaseAmountExcludesVAT in SubscriptionLine.Table.al).
Toggling Prices Including VAT on the Sales Header recalculates the Sales Subscription Line amounts via a new event subscriber in SalesSubscriptionLineMgmt.Codeunit.al.
The intended end state is:
Subscription Lines should always contain VAT-exclusive values. ✅
Contract Lines should also contain VAT-exclusive values. ✅
Creating an invoice from a contract for the customer with prices that include VAT should contain VAT-inclusive values in the sales lines. ❌
The remaining defect: the in-document toggle works for the initial sales document, but once a Sales Order created with Prices Including VAT = YES is processed further (posted → contract created → contract billed), the resulting contract invoice is inconsistent: it uses the net (VAT-exclusive) amounts as if they were VAT-inclusive amounts.
Expected behavior
When the contract billing invoice is generated for a customer whose prices include VAT, the sales lines must contain VAT-inclusive values, so that: The VAT amount is calculated on top of the net base.
Steps to reproduce
Set up a customer whose default Prices Including VAT = YES, and an item with a non-zero VAT rate (Normal VAT).
Create a Sales Order for a subscription item for that customer and set Prices Including VAT = YES on the header.
Post the Sales Order so a Customer Subscription Contract is created.
Run contract billing to create the contract invoice.
Open the generated contract invoice and inspect the sales line amounts, VAT base and VAT amount, plus the header Prices Including VAT flag.
Observed: although the invoice header has Prices Including VAT = YES, the sales lines carry the net (VAT-exclusive) amounts, which are then treated as VAT-inclusive — the VAT base/VAT amount do not reconcile with the original order.
Expected: the contract invoice's sales lines contain VAT-inclusive values, and the net base, VAT amount and total match the original order's intended values, consistently.
Describe the issue
This is a follow-up to issue #7399 / PR #8066 (PDD-366). That PR fixed the initial sales-document side of the "Prices Including VAT" handling:
Subscription Line."Calculation Base Amount"is stripped of VAT when the originating Sales Header has Prices Including VAT = YES (SubscriptionLine.EnsureCalculationBaseAmountExcludesVATinSubscriptionLine.Table.al).SalesSubscriptionLineMgmt.Codeunit.al.The intended end state is:
The remaining defect: the in-document toggle works for the initial sales document, but once a Sales Order created with Prices Including VAT = YES is processed further (posted → contract created → contract billed), the resulting contract invoice is inconsistent: it uses the net (VAT-exclusive) amounts as if they were VAT-inclusive amounts.
Expected behavior
When the contract billing invoice is generated for a customer whose prices include VAT, the sales lines must contain VAT-inclusive values, so that: The VAT amount is calculated on top of the net base.
Steps to reproduce
Observed: although the invoice header has Prices Including VAT = YES, the sales lines carry the net (VAT-exclusive) amounts, which are then treated as VAT-inclusive — the VAT base/VAT amount do not reconcile with the original order.
Expected: the contract invoice's sales lines contain VAT-inclusive values, and the net base, VAT amount and total match the original order's intended values, consistently.
Additional context
No response
I will provide a fix for a bug