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. One line per schedule:

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.Product2Id IN :productsOnThisPriceChange
AND    Order_Product__r.Order.Status = 'Activated'
AND    Charge_Type__c = 'Recurring'
AND    Billing_Start_Date__c != null
AND    (Billing_End_Date__c = null OR Billing_End_Date__c >= :goLiveDate)

• Filled on each line: its product row, Order, OrderItem, Account and old schedule.
  • Old_Amount__c is the schedule's amount; New_Amount__c is the product row's new price.
  • 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 + OrderItem), so a second preview updates lines instead of duplicating them.
• Counted twice: live schedules per product are counted straight from Billing_Schedule__c into Live_Schedules__c and compared with Lines_Created__c.
• Billing holidays: a holiday is its own schedule record (Charge Type = Billing Holiday). The customer's recurring schedule stays live, so it's included.
• At Apply: the same query runs again, and any subscription activated since the preview gets a late line. The pricebook is checked against the product rows first.

• 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.

• 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 go-live (cancel, downgrade, swap): Apply re-checks each line and skips with a reason; new subscriptions get late lines.
• 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.