[Master]-Act Consumption Qty field in Component of a Firm Planned Order has amounts that point to a Released Production Order that has the same Document No if the component is the same#9630
Conversation
…Prod. Order Components
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…patibility GreaterThanRuleBelowThresholdCreatesWHTEntryOnPurchaseInvoice and GreaterThanRuleAboveThresholdDoesNotCreateWHTEntryOnPurchaseInvoice were failing in non-AU localizations (SE, FR, NL, FI, BE, CH) with "The General Posting Setup does not exist" for DOMESTIC/FREIGHT. Replace CreateVendorWithPostingGroup + CreateGLAccount (which picks a random Gen. Prod. Posting Group not guaranteed to have a matching General Posting Setup entry) with CreateVendorNoWithoutABN + CreateGLAccountWithPostingSetup, using LibraryERM.CreateGeneralPostingSetupInvt to create a properly-paired posting setup. Matches the pattern used in UnapplyVendorLedgerEntryAmount.
…ures The AU CI job failed due to a transient network timeout when fetching the platform version index from the bcinsider CDN endpoint. Added retry logic (3 attempts, 30s delay) to Get-PlatformVersions in PlatformHelper.psm1 to make container creation resilient to temporary CDN connectivity issues. Updated tests to cover retry behavior.
github-actions
Bot
added
the
Build: scripts & configs
…e in Test-TransientTestFailure
|
The new "Act. Consumption (Qty) is 0 unless Released/Finished" behavior is duplicated across four page files (W1 and IT layers of both ProdOrderComponents.Page.al and ProdOrderCompLineList.Page.al), but the only new automated test, ActConsumptionQtyHiddenOnFirmPlannedProdOrderComponentsPage, exercises just the W1 "Prod. Order Components" page. Neither the "Prod. Order Comp. Line List" page (either layer) nor the IT-layer "Prod. Order Components" page is covered. A test against the List page would likely have caught the missing Editable/BlankZero properties there. Add an equivalent test (or extend the existing one) covering the List page variant, since its field binding and trigger logic are identical. Agent judgement — not directly backed by a BCQuality knowledge article. Line mapping was unavailable, so this was posted as an issue comment. 👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.12.4 |
| AutoFormatType = 0; | ||
| Caption = 'Consumed Quantity (Base)'; | ||
| ToolTip = 'Specifies the quantity of the component that has been posted as consumed by the production order.'; | ||
| DecimalPlaces = 0 : 5; |
There was a problem hiding this comment.
In ProdOrderCompLineList.Page.al (W1 layer), the "Act. Consumption (Qty)" field was rebound from the FlowField Rec."Act. Consumption (Qty)" to a plain Decimal variable (ActConsumptionQtyValue) and gained an OnDrillDown trigger, but Editable = false was not added. A directly-bound FlowField is implicitly read-only, so this rebind makes the field user-editable for the first time, even though any edit is silently discarded on the next OnAfterGetRecord. The sibling page ProdOrderComponents.Page.al applies the identical rebind and correctly adds "Editable = false; BlankZero = true;" to preserve the documented Editable=false + OnDrillDown pattern this knowledge file describes as the standard BC pairing for navigable value cells. Add the same two properties here to match ProdOrderComponents.Page.al and avoid an editable field that silently discards user input.
Suggested fix (apply manually — could not be anchored as a one-click suggestion):
DecimalPlaces = 0 : 5;
Editable = false;
BlankZero = true;Knowledge:
👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.12.4
The FI LegacyTestsBucket2 job failed with 'Internal CLR error (0x80131506)' during the app-cleanup phase of NewBcContainer.ps1 (UnInstall-BcContainerApp line 36). This is a transient BC server crash under memory pressure. Add a while-loop retry wrapper (max 2 attempts) around the uninstall loop: - On CLR crash detection (Internal CLR error / Fatal error / 0x80131506) restart the container and re-iterate from the remaining installed apps. - On the second attempt a CLR crash is re-thrown so the job still fails loudly if the container is consistently unhealthy. - Any non-CLR error is always re-thrown immediately.
…ta generation The Unit Tests (MX) (UncategorizedTests) job was failing because Invoke-NavContainerCodeunit for codeunit 5193 CreateAllDemoData hit the 600-second HttpClient.Timeout inside BcContainerHelper's container script. MX has many localization apps and demo data generation takes >600 seconds. Fix: replace the timed-out Invoke-NavContainerCodeunit calls for codeunit 5193 (CreateSetupDemoData/CreateAllDemoData) with Invoke-ScriptInBcContainer + Invoke-NAVCodeunit (management module). Invoke-NAVCodeunit communicates directly with the service tier without any client-side HTTP timeout, matching the pattern used by Stop-NAVServerInstance, Sync-NAVApp, etc. in the same file.
|
Superseded by #9660 (recreated as a single clean commit with only my changes). |
AB#636784