R2: When assigning assets to a product line in an order, the Assign Asset window incorrectly listed retired assets even when the Retired checkbox was unticked. (SR-28782)
Fix: The system now correctly excludes retired, sold, lost, or inactive assets when opening the Assign Asset screen across all order types (Reservation, Sales, and Intercompany). Additionally, the Retired, Sold, and Lost checkboxes are now disabled and excluded from saved user views.
R2: When tagging a vendor in a voucher, the system did not default the vendor’s payable terms, resulting in missing or outdated payment terms. Tagging a purchase order, however, continued to pull terms correctly. (SR-28961)
Fix: The voucher now follows a defined hierarchy for defaulting payment terms — when a vendor is tagged or changed, the vendor’s payable terms are applied; when a purchase order is tagged or changed, the PO’s payable terms override any existing ones. If terms differ, the system overwrites the old value and displays a message: “The Payment Terms has been changed from <old-PT> to <new-PT>.”
Labor: When opening the Comments dropdown in the Resource Edit screen, the system showed a continuous “Loading” spinner even when no comment templates existed, giving the impression that data was still being fetched. (SR-29082)
Fix: The component now correctly displays “Loading” only while templates are being fetched. If no templates are available, a non-selectable message “No templates available” is shown. Applicable across all comment editor screens including Crew Edit, Planning Order, and Whiteboard.
R2: Users without authorization could still enter Screen Level Security mode on the Fill Items screen by pressing F6, even though runtime security was disabled in configuration. (SR-29058)
Fix: Implemented configuration-based security checks for Scan Dialogs to prevent unauthorized users from triggering runtime security. Verified across Fill, Ship, Pickup, and Return dialogs — users without access can no longer enter Screen Level Security mode.
R2: When modifying or deleting a task description in an R2 order, no history was recorded on the R2 side, leaving changes untracked in Change History. (SR-28452)
Fix: Enhanced the system to capture Labor Line Change History for free-form task descriptions, ensuring updates—such as blank ↔ free-form ↔ defined transitions—are logged accurately in Order Change History.
BRE: PO approval alert emails were not delivered when the Profit Center hashtag was included in the email template, preventing approvers from receiving notifications. (SR-28937)
Fix: The system now correctly sends PO approval emails even when the Profit Center tag is used in the template.
R2: Transfer Orders could not be printed, and the system became unresponsive when attempting to print using an incorrect form setup. (SR-28861)
Fix: The system now displays an appropriate error message when invalid form configurations are used and continues to print successfully when valid settings are applied.
R2-Web: When users left an order open and the session timed out due to inactivity, the order remained locked after re-login, blocking further edits and schedule creation. (SR-28697)
Fix: The system now automatically closes any open orders when the session times out, ensuring they are safely released, and corresponding warehouse schedules are created as expected.
R2: After copying and pasting sections in the Order Labor Grid, the section headers appeared in the wrong font style and size, showing regular font instead of bold. (SR-25473)
Fix: Copied sections in the Order Labor Grid now retain the original formatting — section headers remain bold with the correct font size, and labor lines preserve their original font settings regardless of printable status.
R2-Web: When SSO was enabled, admins could not unlock orders using their R2 credentials — the system displayed an incorrect error message (“No profile exist with ID”) instead of validating the credentials. (SR-28559)
Fix: Admins can now unlock orders and perform other approval actions (e.g., PO or discount approvals) using their R2 credentials even when SSO is enabled. The system correctly validates login attempts and shows standard authentication messages.
R2: When using the Update Replacement Cost action, the asset’s Status Date did not update to reflect the sold date, even though the status changed to “Sold.” (SR-28511)
Fix: The system now updates the Status Date correctly to match the sold date whenever an asset is marked as sold through the Update Replacement Cost action.
R2: Reports and queries using REP_OrderHeaderView were experiencing performance delays when retrieving data. (SR-28042)
Fix: The view logic has been optimized to eliminate redundant processing and improve query performance, ensuring faster data retrieval with no impact on data accuracy.
R2: When processing a service ticket for a kit, the locked (child) assets within the kit remained marked as Damaged and their Service Status stayed as Needs Service, even after the kit’s service ticket was completed. (SR-23857)
Fix: Marking a kit asset as damaged or processing its service ticket no longer alters the service status, damaged flag, or availability of its child assets. The kit’s updates now remain isolated, ensuring the child assets retain their correct status unless serviced individually.
R2: Unauthorized users were able to modify discounts on orders that already had posted invoices, leading to mismatches between order totals and financial records. (SR-28087)
Fix: The system now restricts discount edits at the order header, line, and flat discount levels once an invoice has been posted. Authorized users, as defined under Posted Order Line Security in R2 Configuration, can continue to make changes as long as the Net Amount and Net Discount do not fall below the posted values. If either value goes below the posted amount, the Amount column in the item line grid is highlighted in yellow, and the system blocks further invoicing until the discrepancy is corrected. Unauthorized users will see the message “You are not authorized to make changes after posting.”
For more details about posted amount validations refer to (LOC Billing Orders – Posted Amount validation)
R2: Invoices were being generated with inflated amounts for split item lines when order discounts were reduced or set to zero under Length of Contract (LOC) billing. (SR-25776)
Fix:
The LOC billing logic now validates order line values during invoicing to ensure the net amount and discount do not fall below the values already posted. If a discrepancy is detected, the Amount field in the item line grid is visually highlighted in yellow, preventing further invoicing until corrected.
These safeguards maintain consistency between order and posted invoice values, ensuring accurate revenue recognition and preventing overbilling.
For more details about posted amount validations refer to (LOC Billing Orders – Posted Amount validation)
R2: With LOC (Length of Contract) billing, marking a line Non-Discountable after a posted invoice could make the order total differ from the invoice total, and the system allowed invoicing to proceed. (SR-24058)
Fix: During invoicing, the system now enforces that each item line’s Net Amount and Discount Amount cannot drop below their posted values. If a line violates this, the Amount column in the item line grid is highlighted yellow, and invoicing is blocked until corrected. This keeps order and invoice totals consistent and prevents unintended additional billing.
For more details about posted amount validations refer to (LOC Billing Orders – Posted Amount validation)
