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

Price Change (step 2)

• When: once the pricebook has the new prices, and before the preview. Finance creates it from the Price Changes tab with New.
• What's on it: description, funder (MSD), go-live date and the price rule. Status starts at Draft.
• What isn't: products or prices. The funder attribute decides the products and the pricebook holds the prices, so the two can't disagree.
• Approval comes after the preview (step 4), so Finance approves the real prices and the real number of subscriptions.

Price Change Lines (step 3, Preview)

A batch first finds the products: every product with Funder = MSD, active or not. It uses ProductController.getProductsByDefinitionAttributes, the lookup the June draft in QA already uses. As a safety net, any product with live schedules whose name contains MSD but whose funder isn't MSD is counted as a missing product. Then it reads the billing schedules, not the bills, so 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 :productsWithFunderMSD
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: Product, Order, OrderItem, Account and old schedule.
  • Old_Amount__c is the schedule's Amount_to_be_billed__c.
  • New_Amount__c is the product's active Standard Price Book price incl GST.
  • 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 (old = new, for orders placed since the pricebook changed): 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 are also counted straight from Billing_Schedule__c, into Live_Schedules__c on the header and per product on the preview screen.
• 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 read again too. If a product's price no longer matches its lines' New_Amount__c, those lines stop with an error ("pricebook changed since approval"): rerun the preview and approve again.

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

• New orders get the new price before approval. The pricebook changes first, by hand, as today, and a wrong price is caught only at the step 4 check. Run the preview the same day the pricebook changes; Apply still waits for go-live.
• Pricebook edited after approval: Apply compares the pricebook with each line's New_Amount__c and stops that product's lines. Rerun the preview and approve again.
• 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: incl and excl GST prices come from the pricebook entry, as today.
• 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.