Latest Release

1. Copy and Paste Item and Labor Lines from Previous Order Versions (R2-24864)
   You can now copy Item and Labor lines from any previous version of an order and reuse them across R2 or external applications.

   • Copied lines can be pasted into:

     • The latest version of the same order.

     • A different order within R2.

     • External applications such as Microsoft Excel, Notepad, or Notepad++.

This update provides more flexibility when working with order versions by allowing you to reuse specific items and labor. It eliminates the need to manually recreate lines or replace entire versions, streamlining your workflow when creating or modifying orders.

1. Improved Configuration Parameters Settings (R2-21239)

   • Reorganized the Web Labor Settings screen by removing obsolete and unused configuration options.

   • Grouped and ordered settings logically to display only relevant items for easier management.

   • Improved usability and reduced the risk of configuration errors with no change to existing functionality.

2. Audit Logging Configuration Changes (R2-24957)

   • Audit logging implemented for R2 Labor configuration settings to track what was changed, by whom, and when

   • All configuration changes (Create / Update / Delete) are automatically logged with previous and new values

   • Configuration change history can be retrieved using Rep_ConfigurationChangeHistoryView

   • Improves traceability, troubleshooting, compliance, and overall system transparency

   • Limited to Config Parameters and Miscellaneous settings on the R2 Labor Settings page.

   • Audit logging for additional configuration areas will be included in future phases.

1. PackNShip - Item/Asset Descriptions in Remediation Screen and Updated “Today” Filter with Configurable Date Range (R2-24111 / R2-25076)

   • Added item and asset descriptions to the Remediation screen to improve identification during Fill, Ship, Return, and Asset Update.

   • Enhanced the “Today” filter to limit tasks displayed in Prep, Ship, and Return/Receive lists

     • Added an Include up to [X] days old setting to control the date range (default 14 days; configurable from 0 to 365 days).

     • Improved performance by reducing the retrieval of older data.

     • No impact to existing Yesterday and Tomorrow filters.

2. PackNShip and Asset Manager - RFID Hub Service Updates (R2-24948)

   • RFID Hub web service upgraded from .NET Core 3.1 to .NET 10

   • Improved overall platform stability and long-term maintainability

   • Both apps will continue to function as before

   • No changes to existing functionality

3. PackNShip app - React Native Updates (R2-24371)

   • React Native upgraded from 0.75.2 to 0.82.1 version

   • Improved overall platform stability and long-term maintainability

   • No changes to existing functionality

1. R2: In the Asset NBV History screen, posting a full or partial credit memo for returned items sometimes creates duplicate credit entries for the same asset. This resulted in incorrect NBV history, where a single credit transaction appeared multiple times for an asset. (SR-31812)

   Fix: NBV history generation is corrected to prevent duplicate entries during credit memo posting. Each credit memo transaction for an asset is now recorded only once, ensuring accurate and consistent NBV history for both full and partial credit scenarios across rental and sale orders.

2. R2: In the Transportation Logistics module, when an order is assigned to a schedule, and the Ship Date is modified later on order, the Ship Task remains assigned to the existing schedule even when no items have been dispatched. This resulted in incorrect scheduling, as the task is not available for reassignment based on the updated ship date. (SR-31539)

   Fix: Ship Task handling is updated based on dispatch status. When no items are dispatched, changing the Ship Date now removes the Ship Task from the existing Transportation Logistics schedule and returns it to the unassigned task pool for reassignment. If any items are already dispatched, the existing behavior is retained, and the Ship Task remains linked to the schedule. This ensures accurate logistics scheduling and visibility when order dates are modified.

3. R2: When performing an Inventory Transfer with Auto Ship/Receive enabled for non-serial items, the Receiving Log was not displayed in certain scenarios, particularly when items were added during the Add & Prep flow. This made it difficult for users to verify received quantities and track inventory movements after transfer completion. (SR-31266)

   Fix: The receive processing is updated to ensure a Receiving Log entry is created even when transfer lines are generated after the receive action in the Add & Prep flow. The Receiving Log now displays correctly for all Auto Ship/Receive inventory transfers, providing consistent visibility of received quantities across both sending and receiving sites.

4. R2: In the Order Cost tab, the Labor Cost sometimes displayed an incorrect (inflated) value after saving and reopening an order. The value appeared correct initially and after a manual refresh, but reverted to an incorrect total on reopening, leading to inconsistent cost visibility for orders with multiple labor lines. (SR-32439)

   Fix: The labor cost calculation is corrected to prevent duplicate accumulation during cost processing. Each labor line cost is now added only once to the total, ensuring the Labor Cost value remains accurate and consistent across save, reopen, and refresh actions in the Cost tab.

5. R2: When changing the Order-level Price Group to a group with no pricing defined, Items and Labor behaved inconsistently. Item pricing correctly fell back to the Site-level Price Group, while Labor pricing incorrectly skipped the Site-level and used the Blank/Default Price Group, resulting in incorrect labor rates. (SR-32071)

   Fix: The pricing for Labor is corrected to follow the same 3-step fallback sequence as Items: Order-level Price Group → Site-level Price Group → Blank/Default Price Group. Labor pricing now correctly uses the Site-level Price Group when no pricing is defined at the order level, ensuring consistent and predictable pricing behavior across both Items and Labor.

6. R2: In REP_ORDERPRODUCTDETAILVIEW, invoiced Quote/Billing Orders incorrectly displayed line status as “Purchase Assigned”, even when no Purchase Order (PO) was linked. This caused confusion, as the items could not be found in order or associated with any PO. (SR-32073)

   Root Cause: During Quote-to-Invoice conversion and Order close processes, the system incorrectly set all contract line statuses to (Purchase Assigned)—a status meant only for PO-linked lines. This overloaded status was being used to represent the status of lines on an “Invoiced Quote,” leading to misleading reporting.

   Fix:

   • Updated R2 logic to stop assigning status Purchase Assigned for Quote/Billing Orders during invoicing, and the order is marked as Done.

   • Line status now reflects the actual business condition:

     • PO-linked lines → “Purchase Assigned”

     • Non-PO lines → “Not Available”

   • Ensured consistent behavior across Quote-to-Invoice, Close Order, and Reopen Order scenarios.

   Result: The report now shows accurate, business-relevant line statuses, eliminating false “Purchase Assigned” entries and aligning report data with actual order and PO linkage.
   Note: Given application fix only so that incorret data does not get created going forward in the stated scenario. Existing data continues to show as Purchase Assigned on upgrade. Please reach out to UBS Customer care for having the existing data fixed.

7. R2: The system allowed the line-level Ship Date to be earlier than the Prep Date when dates were updated from the order header or through bulk date update actions. This resulted in invalid date sequences, impacting scheduling and downstream processes such as warehouse planning and invoicing. (SR-32051)
   Fix: Validation is added to ensure the Ship Date is always greater than or equal to the Prep Date. When updating dates, the system now verifies the new Ship Date against the existing Prep Date and only applies the update if the condition is satisfied. This validation applies consistently across header-level updates, bulk date changes, and line-level edits, ensuring valid and consistent date sequencing.
   Note: This release includes an application fix only. Existing data discrepancies are not automatically corrected and must be updated manually if required.

8. R2: After purging rental order data, item availability was calculated incorrectly, showing all assets as available even when some were in Repair status through Service Work Orders (SWO). This resulted in inaccurate availability counts, as repair assets were not considered after the purge process. (SR-32163)

   Fix: Updated to remove stale references between Service Work Orders (SWO) and purged order lines. Availability calculation now correctly considers assets in Repair status even after order data is purged, ensuring accurate availability values (for example, Available = 4 and Repair = 1) are maintained.
   Steps to reproduce

   • Create a serialized item and receive 5 quantities into inventory.

   • Create a Rental Order (Reservation).

     1. Add the item with quantity = 1.

   • Fill and Ship the rental order.

     1. System assigns Asset #1.

   • Save and exit the rental order.

   • Create a Service Work Order (SWO) for Asset #1.

     1. Change status to Open.

     2. Save and exit.

   • Go back to the Rental Order and initiate Return for the asset.

     1. System prompts to Close or Keep the Work Order Open.

     2. Select Keep Work Order Open.

   • Check Item Availability:

     1. Available = 4

     2. Repair = 1

   • Run the Purge Script on the rental order.

   • Check Item Availability again.

   • Actual Result

     1. System shows: Available = 5

   • Expected Result

     1. System should show:

        1. Available = 4

        2. Repair = 1

9. R2 API: A deadlock could occur in the R2 API under high concurrent access scenarios. This scenario is extremely rare and requires a very specific and uncommon combination of timing conditions. (SR-32394)

   Fix: Resolved the underlying contention causing the deadlock by optimizing concurrency handling, ensuring improved stability and reliable API performance under heavy load.

10. R2: Subrent purchase order lines were not marked as received after S-Out, even though items were shipped, when “Prompt for Serial ID for S-Assigned Items” is enabled in Configuration, leading to incorrect PO status. (SR-32424)

    Fix: Updated the subrent processing to ensure PO received quantity is correctly updated during direct S-Out (S-Assigned -> S-Out) with “Prompt for Serial ID for S-Assigned Items” enabled in the Configuration.

11. R2: Pricing Analysis incorrectly included the replacement cost of lines, which was marked as “Deleted”, resulting in inflated Total Rental Replacement Cost and inaccurate ROI representation. (SR-31717)

    Fix:

    • Updated Pricing Analysis logic to exclude deleted lines from replacement cost calculations shown on the Pricing Analysis screen.

    • Deleted lines are no longer displayed in the Pricing Analysis grid.

    • Ensured package/header replacement cost excludes deleted child items, providing accurate cost aggregation.

    Result: Pricing Analysis now reflects true cost exposure and ROI by considering only active (dispatchable) items.

12. R2: In the Equipment Usage View (EUV), the system displayed incorrect pooled stock values when the viewing period start date was set after the return date of Moving In/Out records. This resulted in reduced stock (for example, showing 1 instead of 2), even though the total pooled stock across sites remained unchanged. (SR-30825)

    Fix: The EUV calculation is updated to correctly handle Moving In/Out scenarios when evaluating stock and availability. The system now ensures that sites are not excluded when stock exists, but available quantity is zero, and correctly includes all relevant sites in pooled stock calculations. This ensures accurate stock and availability values across different date ranges and configuration scenarios.
    Steps to reproduce

    1. Pre-requisite:

       • Enable Equipment Pooling → Configuration → Warehouse → Enable “Equipment Pooling”

    2. Scenario:

       1. Create three sites and assign them to the same Sub Region.

       2. Create a serial item and receive stock across two different sites (e.g., 1 quantity each).

       3. Create a Rental Order with defined Prep and Return dates.

       4. Add the item to the order and set different Shipping and Return sites.

       5. Open Equipment Usage View (EUV) for the order line.

       6. Apply the following filters:

          1. Group By: None

          2. Sub Region: Applicable Sub Region

          3. Uncheck “Moving In & Out”

       7. Observe that pooled stock is displayed correctly for the original date range.

       8. Change the EUV viewing period start date to a date after the order return date.

       9. Refresh the view and observe the pooled stock value.

       10. Actual Result:

           1. Pooled stock is reduced (e.g., shown as 1 instead of 2).

       11. Expected Result:

           1. Pooled stock should remain unchanged and reflect total stock across sites.

13. R2: In the Warehouse return process, when using the Read File option, items were sometimes returned to a different site even when users selected “Return to Current Site” in the prompt. This caused an incorrect inventory movement, with returned items being recorded in the wrong site instead of the user-selected location. (R2-25029)

    Fix: The return logic has been corrected to respect the user’s selection in the Read File prompt. Items are now returned to the selected site (current site or order site) as chosen by the user, ensuring accurate inventory updates and correct site-level stock tracking.

14. R2: When marking a serial kit asset as lost from a different site, the Total and Locked Qty values for the kit child items were updated incorrectly across sites. This resulted in inconsistent inventory quantities, with child items showing incorrect totals and locked quantities in both the shipping and return sites. (R2-25028)

    Fix: Inventory update logic has been corrected for serial kit child items when assets are marked as lost. The Total and Locked Qty values are now updated accurately based on the allocated kit quantities, ensuring consistent and correct inventory values across all sites.

15. R2: When marking a kit asset as lost from a different site, the Total and Locked Qty values for the kit child items were not updated correctly. While the kit itself reflected the change, the child items did not reduce as expected, resulting in inconsistent inventory quantities. (R2-25027)

    Fix: Inventory update logic has been corrected so that when a kit asset is marked as lost, the corresponding kit child item quantities are updated accurately. The Total and Locked Qty values for child items are now reduced based on the allocated kit quantities, ensuring consistent inventory across sites.

16. R2: In the Search Inventory screen, the application sometimes became unresponsive when users toggled the Owned Qty or Show Avail checkboxes after performing a search. This caused the screen to freeze, preventing further interaction and requiring users to restart the screen. (R2-24971)

    Fix: The Search Inventory screen now remains responsive when toggling the Owned Qty and Show Avail checkboxes. Users can update checkbox selections and perform searches without the screen freezing, ensuring smooth and consistent interaction with inventory search results.

17. R2: While creating the Service Work Order (SWO) for non-serial items, the Damage History selection list (opened through pencil icon beside Qty field) displayed records based on the Service Site instead of the Availability Site defined on the SWO. As a result, users could not see damage records associated with the selected Availability Site when choosing damage history entries. (R2-24887)
    Fix: The damage history lookup in the SWO screen now retrieves records based on the Availability Site defined on the Service Work Order. Damage entries associated with the selected Availability Site are now displayed correctly, allowing users to select the appropriate records during SWO processing.
    From 06.25.04-00 onwards, the system displays damage history based on the SWO Availability Site instead of the Service Site. This behavior applies only to SWOs created after upgrading to version 06.25.04-00 or higher. SWOs created in earlier versions continue to follow the previous behavior.

18. R2: In the application grid, columns configured as hidden in the UI definition file were still available in the Screen Customization (Grid Designer) and could be made visible by users, although they are not meant to be visible. This allowed restricted columns (such as Long Description, Keywords, Type and other hidden fields) to appear in the grid, leading to inconsistent UI behavior and unintended data visibility. (R2-15587)

    Fix: Grid customization is updated to exclude columns that are configured as not visible in the UI definition file. These columns are no longer displayed in the application grid or in the Screen Customization options, ensuring they cannot be made visible through customization. Hidden columns remain available only for search criteria where applicable, maintaining consistent and controlled UI behavior.

19. R2 API: In the R2 API, error responses sometimes returned technical or unclear messages (for example, generic “Invalid Group ID” errors or messages with internal connection details). This made it difficult for client applications and end users to identify the exact cause of the issue or the field that failed validation. (R2-25083)

    Fix: API error handling is improved to return clear and user-friendly error messages. Validation errors now include meaningful descriptions (for example, “Invalid Shelf Id <value>” or “Invalid <Group Name> Id <value>”), and a faultDetails parameter is introduced to identify the specific field that failed validation. Technical details and unnecessary prefixes have been removed from the response, ensuring errors can be directly understood and displayed by client applications.