Telecare price change, synced to Business Central without the three-week watch

Price Change and its product rows (step 1)

• When: as soon as the new prices are known, at least three weeks before go-live. Created by Finance from the Price Changes tab with New.
• Header (Price_Change__c): description, funder (MSD), go-live date and the price rule. Status starts at Draft.
• Product rows (Price_Change_Product__c, one per product):
  • Add MSD products finds every product with the Funder = MSD definition attribute, active or not. That's the lookup the June draft in QA already uses (ProductController.getProductsByDefinitionAttributes).
  • As a safety net, any product with live schedules whose name contains MSD but whose funder isn't MSD is reported as missing.
  • Each row copies the product's frequency, and today's price from its Standard Price Book entry.
• New prices, without typing 26 of them:
  • Fill new prices applies one uplift to each weekly price (rounded to the cent). It works out fortnightly as 2 × weekly and monthly as weekly × 52 ÷ 12 for the same service.
  • Finance can then type over any row, or paste a column of prices.
  • The price excluding GST is incl ÷ 1.15, kept to 4 decimals like today.
• Before approval the record won't submit while a product is missing, a new price equals the old one, or the weekly, fortnightly and monthly prices disagree.

Updating the pricebook from the Price Change (step 2)

• Update Pricebook is available once the Price Change is Approved. For each product row it updates that product's active Standard Price Book entry:
  • UnitPrice_GST_Inclusive__c = the new price incl GST;
  • UnitPrice = the new price excl GST;
  • Price_Excl_GST__c is a formula and follows.
• All or nothing: all 26 entries are updated in one transaction. It then sets Pricebook_Update_Date__c and Status = Pricebook Updated.
• Restore Old Prices (until Apply): writes the old prices back from the product rows, if the change is cancelled or postponed.
• Edits outside the price change: if someone changes an in-scope pricebook price by hand afterwards, Apply sees that the pricebook no longer matches the product row and stops that product's lines.

Price Change Lines (step 3, Preview)

A batch reads the billing schedules, not the bills. That's why every subscription is found at once, whatever its frequency and wherever it is in its cycle. There's one line per live billing schedule: an order may have several schedules, and only the one with a blank End Date is picked.

SELECT Id, Order_Product__c, Order_Product__r.OrderId, Order_Product__r.Product2Id, Account__c,
       Amount_to_be_billed__c, Billing_Start_Date__c, Billing_Frequency__c, Billing_Type__c,
       Quantity__c, Next_Billing_Date_Calculated__c, Order_Product__r.LineDiscountAmount__c
FROM   Billing_Schedule__c
WHERE  Order_Product__r.OrderId IN :activatedOrdersWithAnInScopeProduct
AND    Charge_Type__c = 'Recurring'
AND    Billing_Start_Date__c != null
AND    Billing_End_Date__c = null

• Filled on each line: its product row (the schedule's own product), Order, the schedule's own OrderItem, Account and the schedule.
  • Old_Amount__c is the schedule's amount. New_Amount__c is the sum of the new prices of every in-scope order line the schedule bills: its own line, plus peripherals on the same order with no schedule of their own. Each order line's old and new price is kept in Item_Prices__c.
  • Also: discount, frequency, in advance or in arrears, next billing date and the forecast cutover date.
  • Apply Status = Pending, Sync Status = Not Sent.
• Already at the new price (orders placed since the pricebook update): the line is marked Skipped, so the counts still add up.
• Rerun-safe: lines are upserted on Idempotency_Key__c (Price Change + Billing Schedule), so a second preview updates lines instead of duplicating them.
• Counted twice: every in-scope order line on an Activated order is counted straight from OrderItem into Live_Order_Lines__c and compared with Order_Lines_Covered__c. A peripheral that no schedule bills therefore shows up as uncovered.
• Exceptions for Finance: a schedule with a future End Date (not picked, so not re-priced), and a schedule whose amount doesn't equal the sum of its order lines' old prices.
• Billing holidays: a holiday is its own schedule record (Charge Type = Billing Holiday). The customer's recurring schedule stays live, so it's included.
• Apply date: each line stores the day it will be applied (see the next panel).

How Apply finds the orders (daily from go-live, until the price change is closed)

Apply doesn't search for orders. The lines created at preview are its work list, and each morning it takes the lines that are due:

SELECT Id, Order__c, Order_Product__c, Old_Billing_Schedule__c, Price_Change_Product__c,
       New_Amount__c, Cutover_Date__c, Apply_Date__c
FROM   Price_Change_Line__c
WHERE  Price_Change__c = :priceChangeId
AND    Apply_Status__c = 'Pending'
AND    Apply_Date__c <= TODAY
ORDER BY Order__c

• Apply date (worked out at preview, stored on the line):
  • normally the subscription's cutover date;
  • for in-advance billing, the day before its first new-price bill is invoiced, if that's earlier;
  • go-live day for a subscription that hasn't billed yet.
  The job runs early each morning, before the billing run.
• One current schedule per subscription. Because each line is applied on its own date, a subscription never has a future-dated schedule waiting while the old one is still billing. So the existing processes that find "the schedule with a blank end date" keep working unchanged: service cancellation (BillingScheduleController), ChangeProductProcessing and ChangeAccountProcessing. In-advance subscriptions have a short overlap of a few days, because their bill is invoiced before the cutover.
• One schedule, several order lines: the line covers the schedule's own order line and any peripherals it bills. Apply re-prices all of those order lines, then the schedule, then the order totals. An order with more than one live schedule has a line for each, and they're processed together (hence ORDER BY Order__c).

• The sweep, every run until the price change is closed: Apply also reruns the preview query. Any live schedule on these products that has no line yet gets a late line. That covers an order activated after the preview or after go-live, or one that came in from a channel at the old price. A late line already at the new price is Skipped; otherwise it's applied the same way. After close, the pricebook is the only safeguard, so any old-price order goes to Finance on an exceptions report.

• Manual pricebook edits for price changes stop: the Price Change writes the Standard Price Book entries (and can restore them).
• Retire TelecareMSDPriceChangeUpdateBatch, its schedule class and the MSDPriceDateChange label after the first run on the new design. Keep its one good rule: the new schedule starts at a period start.
• June draft in QA (TelecarePriceChangeBatch, PriceChangeService; not in UAT or Prod): reuse its product lookup by funder attribute, then retire it. As written, it sets every schedule on an order to the whole order total, and adds bills with no dates or status.
• AIS patch batches (OrderPatchHourlyBatch, OrderLinePatchHourlyBatch, BillingScheduleHourlyBatch) pick records changed in the last hour, so a failed run can miss changes. For price changes they send from the lines instead; the same outbox pattern would make the general sync safer.
• No whole-order resend (Order V2) for price changes.
• No change to service cancellation (BillingScheduleController), ChangeProductProcessing or ChangeAccountProcessing. They find "the schedule with a blank end date", and applying each line on its own date keeps exactly one such schedule per subscription.

• A wrong price reaching new orders: prices are checked across frequencies and approved before Update Pricebook can run. If one is still wrong, Restore Old Prices puts the pricebook back until go-live.
• Pricebook edited by hand after the update: Apply compares the pricebook with each product row and stops that product's lines until they match.
• Billing day moves if a new schedule starts on go-live day. Apply starts it on the subscription's own cycle boundary, and check 4 proves it.
• Volume: a price change touches every live MSD subscription, tens of thousands of lines. Apply and the sync run in batches. AIS returns acknowledgements in groups (an upsert of up to 200 lines per call on Idempotency_Key__c), so header roll-ups don't hit UNABLE_TO_LOCK_ROW.
• Old bills show new prices in three formula fields. Reports and the AIS payload use the stored …_Value__c fields.
• Orders that change between preview and their apply date (cancel, downgrade, swap): Apply re-checks each line and skips with a reason.
• Old-price orders after the pricebook update: order prices come from the order payload, not the pricebook (OrderItemController, BillingScheduleController). The daily sweep catches them until close (re-priced in place if not billed yet); after close they appear on an exceptions report.
• Daily Apply must run before the billing run, so a due line is re-priced before its bill is invoiced. In-advance subscriptions have a few days' overlap between the new schedule's creation and its start.
• Custom amounts and discounts: the preview lists subscriptions not on the list price for Finance to confirm. Line discounts carry across as today.
• GST: excl-GST prices are worked out from incl-GST at 15% and kept to 4 decimals, matching today's pricebook.
• First use: a full rehearsal in UAT against the Business Central test environment, with the five checks signed off, before the first production price change.