Overview

Problem

• After a MACD change in Solution Management, the first Calculate Totals shows correct pricing and charges in the UI, but ps_contributions__c stores the previous commercial-product contribution payload. Deal Management then aggregates discounts from this stale data until a second Calculate Totals is run.

Symptoms/impact

• First Calculate Totals:
  • UI Name/Commercial Product reflect the new value.
  • ps_contributions__c still contains the prior bandwidth’s contribution entries.
  • Browser console logs show: Error calculating prices : TypeError: Cannot read properties of undefined (reading 'id')
• Immediate second Calculate Totals:
  • ps_contributions__c is refreshed with the current contribution payload.
• Business impact:
  • Incorrect discount aggregation in Deal Management after the first pass.
  • High risk in UAT and MACD production flows until fixed.

Scope and example environment

• Observed in StarHub ITXUAT Full Sandbox (R36-MR1: Solution Management 36.14.8).
• Trigger scenario includes Order Type = Modify with After Office Hours Charges (creates a pending Order Enrichment).
• Verified by paired HAR and Apex logs:
  • First pass: Pricing Service response had current 400Gbps contributions, while the custom persistence call submitted 100Gbps (prior) contributions.
    • First HAR: HAR #1
    • First Apex log: Apex log #1
  • Second pass: Both Pricing Service and persistence submitted current 400Gbps contributions.
    • Second HAR: HAR #2
    • Second Apex log: Apex log #2

Root cause

• In Solution Management, getAllConfigurationRecords() merges Order Enrichment GUIDs into the caller’s configurationGuids array in place (mutates the caller’s list).
• That polluted GUID list is then passed into recalculation, which tries to resolve non-configuration GUIDs (Order Enrichments) in the solution’s configuration map. Since Order Enrichments are not Product Configurations, the lookup fails, a TypeError is thrown in the UI, and the recalculation is silently skipped.
• The after-save path then persists the pre-change contributions already on the loaded configuration (stale ps_contributions__c).
• On a second run, no pending Order Enrichment remains, the list is clean, recalculation completes, and ps_contributions__c updates correctly.

Fix availability

• Fixed on mainline in 36.15 under “Fix the configurationGuids from getting mutated in getAllConfigurationRecords method.”
• R36-MR1 branched at 36.14, before the fix, and all patches through 36.14.19 still contain the defect.
• Fixed builds:
  • R38 38.0.7: release notes (install in target org using /packaging/installPackage.apexp?p0=04tWV00000052Qz)
  • R37 37.4.21: release notes (install in target org using /packaging/installPackage.apexp?p0=04tWV00000052cHI)
• Recommendation for R36-MR1 customers: Request a backport to 36.14.20 rather than forcing a major-line upgrade close to go-live.

Definitions (plain language)

• MACD: Move, Add, Change, Delete flow on an existing solution.
• Order Enrichment: A non-configuration record created as part of solution processing (e.g., After Office Hours Charges) that should not be included in Product Configuration GUID lists.
• ps_contributions__c: A solution-level JSON field used by Pricing Service/aggregators; Deal Management consumes it for discount aggregation.

Solution

Step 1: Confirm the symptom and capture evidence

1. Run Calculate Totals immediately after a MACD change (e.g., bandwidth).
2. Check the UI: Name/Commercial Product shows the new value; pricing and charges appear correct.
3. Query or view ps_contributions__c for the affected Product Configuration; expect it to still reference the previous commercial product on the first pass.
4. Open the browser console (F12 → Console) and look for:
   • Error calculating prices : TypeError: Cannot read properties of undefined (reading 'id')
5. If available, review the customer-provided artifacts that show current Pricing Service output but a stale persistence handoff:
   • First HAR (current pricing, stale persistence): HAR #1
   • First Apex log: Apex log #1
   • Second HAR: HAR #2
   • Second Apex log: Apex log #2
6. If a screen recording is provided, verify that the first pass persists the prior contributions and the second pass persists the current contributions.
   • Alt text suggestion for any attached video: “Screen recording showing a MACD bandwidth change followed by two Calculate Totals executions; the browser console logs a TypeError on the first pass, ps_contributions__c remains at the prior bandwidth, and updates correctly on the second pass.”

Step 2: Reproduce conditions that trigger the issue

1. Create a MACD from an existing active solution.
2. Set Order Type to Modify and include After Office Hours Charges (creates a pending Order Enrichment).
3. Change a key attribute (e.g., bandwidth from 100Gbps to 400Gbps).
4. Click Calculate Totals once.
5. Observe:
   • UI shows the new bandwidth.
   • ps_contributions__c retains entries referencing the prior bandwidth.
   • Browser console shows the TypeError noted above.

Step 3: Apply the immediate workaround

1. Click Calculate Totals a second time.
2. Confirm ps_contributions__c now contains the current contribution payload and Deal Management discount aggregation aligns with the change.

Step 4: Implement the permanent fix (upgrade or backport)

1. Preferred: Upgrade Solution Console to a version that contains the fix:
   • R38 38.0.7: release notes (install in target org using: /packaging/installPackage.apexp?p0=04tWV00000052Qz)
   • R37 37.4.21: release notes (install in target org using: /packaging/installPackage.apexp?p0=04tWV00000052cHI)
2. If you must remain on R36-MR1 immediately before go-live:
   • Request a backport to 36.14.20 that includes the “Fix the configurationGuids from getting mutated in getAllConfigurationRecords method” change introduced in 36.15.
   • Provide approval and scheduling constraints for patch deployment to UAT/Production.

Step 5: Validate after the fix/backport

1. Repeat the MACD scenario with Order Type = Modify and After Office Hours Charges enabled.
2. Run a single Calculate Totals and verify:
   • No TypeError appears in the browser console.
   • ps_contributions__c reflects the new commercial product on the first pass.
   • Deal Management discount aggregation uses the current contribution payload.
3. Optionally query via SOQL to confirm stored values.

Step 6: If the issue still appears after upgrading

1. Reconfirm the browser console output and collect:
   • HAR of the Calculate Totals request/response.
   • Salesforce debug log (ApexCode=FINEST) for the same run.
   • Affected Solution/MACD IDs and config GUID(s).
   • Exact timestamps of the reproduction.
2. Compare the Pricing Service response to the persistence payload. If they now match and are current on the first pass, the issue is resolved. If they diverge, reopen with evidence.

Summary

• Cause: In R36-MR1 (36.14.x), getAllConfigurationRecords() mutates the caller’s configurationGuids when merging Order Enrichment GUIDs. This pollutes recalculation input and causes a silent client-side error, skipping contribution refresh. After-save then persists stale ps_contributions__c.
• Workaround: Run Calculate Totals twice.
• Fix: Upgrade to a build with the fix (36.15+/R37/R38) or request a 36.14.20 backport. Validate that the first pass updates ps_contributions__c and no console error appears.

FAQ

Q1: Why does running Calculate Totals twice fix the issue?
A1: The first pass fails when Order Enrichment GUIDs pollute the recalculation list, causing a client-side error and skipping contribution refresh. On the second pass, no pending Order Enrichment remains, the list is clean, and the refresh succeeds.

Q2: Which versions are affected, and where is the fix available?
A2: R36-MR1 36.14.x up to 36.14.19 are affected. The fix is included from 36.15 onward and also in R37 37.4.21 and R38 38.0.7.

Q3: Is this caused by custom code or Deal Management observers?
A3: No. The root cause is in Solution Management’s handling of configuration GUIDs during recalculation. Custom components and the Deal Management after-save observer were not responsible for writing stale data.