Skip to main content
Skip table of contents

06.26.01-00

Your paragraph text.gif
R2
  1. Prints in DOCX format (R2-24740)
    This enhancement extends DOCS support for prints.

    • Form Setup–based prints can now be generated in DOCX format.

    • Ensures compatibility when opening documents in Microsoft Office 365.

    • Eliminates dependency on legacy document formats for Form Setup outputs.

  • RTF and PDF format prints continue to exist.

  • DOCX format for hardcoded prints and reports will be available in upcoming releases.

  1. Validation for PO-linked Order Line Changes (SR-29511)

    • Securable prompts displays while deleting or changing quantity of order lines associated with Purchase Orders (PO) which are not Pending for Approval.

    • Users can no longer delete order lines when the associated Purchase Order is in Pending for Approval status.

    • This change prevents unintended cancellation of linked purchase order lines and aligns deletion behavior with existing quantity change restrictions.

  2. Additional Invoice for Posted Labor Lines (SR-25073)
    This update improves additional invoice generation for orders using Pay At – Periodic Billing, Rent or Return, or LOC, specifically addressing changes made to posted labor lines.

    • Changes to posted labor line amounts are now reflected in invoices.

    • Regenerating an invoice after modifying amount-related fields on posted labor lines includes the updated labor charges.

    • Invoice generation is restricted if the labor Amount or Discount Amount is less than the corresponding posted values.

    • Visual indicators highlight discrepancies and block invoice generation until values are corrected.

    • Ensures invoice and order values remain consistent and prevents accounting discrepancies.

CRM
  1. CRM - Platform Upgrade to .NET 10 (R2-24594)
    The backend service platforms supporting CRM are upgraded from .NET Core 3.0 to .NET 10 as part of ongoing platform modernization and support alignment. This upgrade:

    • Addresses end-of-support risks associated with .NET Core 3.0.

    • Ensures continued security updates and vendor support.

    • Improves overall platform stability and long-term maintainability.

    • This is a technical upgrade only, with no changes to application functionality or user-facing behavior.

Bugs
  1. R2: When the “Allow to Edit Kit Weight” configuration flag is enabled, the Weight field for a Non-Serial Kit appears blank on the Kit edit screen, even when child items have valid weights. This made the kit weight unclear and inconsistent across screens. (SR-30715)

    Fix: The Kit edit screen now automatically calculates and displays the Non-Serial Kit Weight as the sum of its child item weights, even when manual weight editing is enabled. The configuration flag is renamed to “Allow to Edit Serial Kit Weight” to clarify that manual override applies only to Serial Kits.

  2. R2 / R2 Labor: When a Labor Line’s Task or Task Description was manually modified from an Order in the R2 core module, the corresponding Planning Order in R2 Labor did not reflect a conflict. As a result, the Conflicts indicator was missing for the affected booking line and planning order, even though a planning-impacting change had occurred. (SR-28452)

    Fix: Manual updates to a Labor Line’s Task or Task Description from an R2 Order now correctly trigger a conflict in R2 Labor. The conflict is displayed on the affected Booking Line within the Planning Order and is also reflected in the Planning Order Search, ensuring planners are aware of changes that require review.

  3. R2: For orders using Pay At - Periodic Billing or Rent or Return or LOC, additional invoices did not include updated labor charges when users modified posted labor lines. As a result, newly generated (unposted) invoices excluded the revised labor amounts, causing additional invoice totals to differ from the order totals. (SR-25073)

    Fix: The system now includes updated labor charges when generating additional invoices. When users modify amount-related attributes on a posted labor line and regenerate an invoice, the corresponding additional labor amount is correctly included in the next unposted invoice.

    The system however enforces safeguards to maintain consistency between order and invoice values. Invoice generation is restricted if:

    • The labor line Amount is less than the labor line Posted Amount, or

    • The labor line Discount Amount is less than the labor line Posted Discount Amount.

    In these cases, the affected labor line’s Amount column is highlighted in yellow, and a bulb indicator appears next to the Order Total. Selecting the indicator provides additional details. Invoice generation is blocked until the values are corrected, preventing accounting discrepancies. For more details click here.

  4. R2: The system allowed users to delete PO-linked order lines even when the linked sub-rental PO is in Pending for Approval status. This resulted in PO lines being cancelled while the PO remained pending approval, creating inconsistent order and PO behavior. (SR-29511)

    Fix: The system now prevents the deletion of order lines linked to a PO that is Pending for Approval. In the cases when deletion is allowed, the system displays separate secured confirmation prompts for PO-linked lines and TO-linked lines so that security controls can be applied correctly. Securing Yes button on these prompts would prevent the users from changing the quantity on the lines linked to PO or TO on an Order. We have also introduced securable prompts while changing quantity on the PO linked order lines. For more details click here.  

  5. R2: When users marked an order as Lost, the Order Change History incorrectly recorded the action as Cancel Contract, and the Accounts → Project tab displayed the order status as Expired instead of Lost. This created inconsistent status history and reporting across screens. (SR-30472)

    Fix: Orders marked as Lost are now recorded as Lost Contract in the Order Change History, and the Accounts → Project tab now displays the correct Lost status instead of Expired. The Cancel case continues to display the correct Cancel status.

  6. R2: When users created a Quote/Order with Suggested Items, the system sometimes saved the order using a CO number instead of the configured Define IDs order number format. This caused orders to be created with unexpected numbering. (SR-30130)

    Fix: Orders that include Suggested Items now consistently use the configured Define IDs numbering when saved.

  7. R2: When users cleared optional order line dates such as Load In, Rehearsal, Show Start, Show End, Strike, or Pickup using the Update Line Details option, the system did not save the changes. As a result, cleared dates remained unchanged, preventing users from successfully removing previously set line dates. (SR-29184)

    Fix: The system now correctly saves cleared values for optional order line date fields when updated through Update Line Details. Users can successfully remove Load In, Rehearsal, Show Start, Show End, Strike, and Pickup dates, ensuring accurate and intentional date management on order lines.

  8. R2: In R2 Labor, users were sometimes unable to save changes in the Crew Edit screen and received an “Update failed” error. This occurred since the date format displayed in crew UDF date fields followed the server's culture/language settings instead of the employee’s configured date format, causing a mismatch and save failure. (SR-30697)

    Fix: Crew UDF date, time, and date-time fields now display and process values using the employee-configured date format rather than the server's culture/language settings. Crew details can now be edited and saved successfully regardless of system or server date settings.

  9. R2: When users updated a customer’s billing address and then re-tagged the same customer on an existing order, the system didn’t prompt to update the Billing Customer, and the Billing Address remained unchanged. (SR-30874)

    Fix: The system now always prompts users to update the Billing Customer when a customer or contact is re-tagged on an order, even if the customer has not changed. When confirmed, the Billing Address is updated accordingly. This behavior applies across all order types.

  10. R2: The Daily Stats program generated incorrect data in REP_PRODDAILYSTATSDETAILVIEW during weekends. In some cases, the Saturday stats record was missing, and the Sunday stats record was duplicated, resulting in inaccurate daily statistics and reporting. (SR-30313)

    Fix: The Daily Stats program now generates records based on the intended execution date, even if processing is delayed past midnight. This ensures one correct stats record is created per day and prevents missing or duplicate entries in REP_PRODDAILYSTATSDETAILVIEW, including during weekend processing.

  11. R2: When generating a Delivery Note prints via the R2 API, the date on the document was always printed in US date format, regardless of the employee’s configured date format. This caused delivery notes generated through the API to display dates inconsistent with R2 UI and customer expectations. (SR-29110)

    Fix: Delivery Notes generated through the R2 API now use the employee’s configured date format. If the employee date format is set to NONE, the system uses the date format defined in r2ini. When no User Context is provided, the API defaults to the employee configured in r2ini. However, when Date Format is provided in Form UI used by the API for generating the print, it will be given highest priority. This ensures Delivery Note dates are consistent across API and UI outputs. Additionally note that the same is applicable for the other prints that can be generated through API like:

    • Transfer Picklist

    • Return Receipt

    • Picklist

    • Transfer Print.

  12. R2: When a planner had an active R2 Labor Planning session open, changes made to a labor line’s Start Date or End Date in R2 did not immediately update the BS (Booking Status) column in the Planning Order. The BS column continued to show a Confirmed (green thumbs-up) status instead of indicating that Re-confirmation (purple thumps up) was required, even though the labor line had been modified. (SR-30494, SR-31258)

    Fix: Labor line date changes made in R2 now immediately update the BS and Confirm Status in the active R2 Labor Planning session. The booking line correctly switches to Re-Confirm with a purple thumbs-up icon without requiring the planner to close and reopen the Planning Order.

  13. R2: When the same order was opened simultaneously in R2 and R2 Labor, changes made to labor line dates in R2 sometimes failed to synchronize to R2 Labor. In some cases, users saw a “Database operation failed” error in R2 Labor, and booking lines did not update or show the expected conflict or re-confirmation status. This caused labor planning data to become out of sync across sessions. (SR-30494, SR-31258)

    Fix: Synchronization between R2 and R2 Labor is corrected when orders are edited in parallel sessions. Labor line changes made in R2 now sync reliably to R2 Labor:

    • Non-planned lines update automatically

    • Planned lines correctly display a conflict and update the Booking Status (BS) as required

    Users no longer encounter unexpected database errors, and labor booking data remains consistent across active sessions.

  14. R2: When a serial kit asset was untagged or removed from a Service Work Order (SWO), the asset continued to show a Service Status of “Needs Service” even when there were no remaining active SWOs or pending service schedules. This caused the service status of the asset to remain incorrect. (SR-30120)

    Fix: When a serial kit asset is removed from an SWO, the system now evaluates whether any other active SWOs or pending service schedules exist for that asset.

    • If no other service activity exists, the user is prompted to confirm whether the Service Status should be updated to “Normal.” Based on the user’s choice, the status is either updated or retained.

    • If there are remaining active SWOs or pending service schedules, the Service Status is updated accordingly without prompting the user.

    Additionally, the Service Status field is now available on the Kit Asset Edit screen, allowing users to view and manually update the service status as needed—consistent with the behavior for serial item assets.

  15. R2: When a serial item asset was untagged or removed from a Service Work Order (SWO), the asset continued to show a Service Status of “Needs Service” even when there were no remaining active SWOs or pending service schedules. This caused the service status of the asset to remain incorrect. (SR-30120)

    Fix: When a serial item asset is removed from an SWO, the system now evaluates whether any other active SWOs or pending service schedules exist for that asset.

    • If no other service activity exists, the user is prompted to confirm whether the Service Status should be updated to “Normal.” Based on the user’s choice, the status is either updated or retained.

    • If there are remaining active SWOs or pending service schedules, the Service Status is updated accordingly without prompting the user.

  16. R2: In multi-currency environments, labor total cost values on Orders did not always match the corresponding Purchase Order (PO) costs. When a labor PO used a different currency conversion rate than the Order, the Order continued to calculate labor Total Cost using the Order’s conversion rate instead of the PO’s rate, resulting in incorrect labor cost totals. (R2-24652)

    Fix: Labor cost calculations now consistently use the PO’s currency conversion rate when a labor line is linked to a PO. This ensures labor Site Total Cost and Total Cost values on the Order match the PO and remain accurate across all supported currency and labor scenarios.

  17. R2: When a Purchase Order (PO) linked to an order line is marked as Void, the order cost is not restored correctly. In some cases, the order continued to reflect the PO cost or showed incorrect unit and total cost values, resulting in inaccurate order costs after the PO was voided. (R2-24646)

    Fix: When a linked PO is voided, the order line cost is now correctly restored to the previously applied order cost (such as the original pricing or manually updated cost). Order Unit Cost, Total Cost, and related cost fields are now recalculated consistently for inventory items, kits, and packages, ensuring accurate order costs after a PO is voided.

  18. R2: In the IR (Intelligent Return/Multi-order Return) screen, the Scan Items option was available in the right-click menu which was opening Scan Items modal dialog unintentionally, even though scanning is supported through the embedded Scan Items control in the IR header. This created inconsistent behavior and could trigger unintended actions. (R2-24760)

    Fix: The Scan Items option has been removed from the right-click menu in the IR screen. Users can continue use the Scan Items control in the screen header.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.