PAR POS™ Monthly Maintenance

June 2026

Rev 1.0

June 2026 Maintenance

5.15r2 Release Patches (build 5.0.15250.131)

Expose Order Edit Information to Chit Configurator for Revised Order Print [ASI-3488]

Issue:

Previously, the Chit Configurator tool was unable to distinguish between original and revised orders.

Resolution:

Now, JavaScript scripting logic for chit orders can read the EditCount value, which tracks how many times an order has been edited.

Order Service Changes for New CloseOrder API EndPoint for REST API [ASI-3481]

Issue:

Previously, orders could only be closed directly at the register, requiring an employee to log in and manually complete the process. This created additional overhead projections for store personnel -- particularly for delivery orders fulfilled by store employees.

Resolution:

Now, a new endpoint has been added to the REST API that allows external systems and integrators to close an order when delivery has been fulfilled. This enables automated order lifecycle management without manual intervention.

In-Store Changes for New CloseOrder API EndPoint for REST API [ASI-3482]

Issue:

Previously, orders could only be closed directly at the register, requiring an employee to log in and manually complete the process. This created additional overhead projections for store personnel -- particularly for delivery orders fulfilled by store employees.

Resolution:

Now, a new endpoint has been added to the REST API that allows external systems and integrators to close an order when delivery has been fulfilled. This enables automated order lifecycle management without manual intervention.

Diagnostic Tools Used to Investigate an Issue with ParPay [BRNK-66274]

Issue:

Credit Card transactions fail to apply to in-store orders when an online order is taken at the same time. The customer is charged the amount from their bank, but the transaction does not appear anywhere in PAR POS.

Resolution:

We have included the following temporary diagnostic tools that can be enabled/disabled using a feature flag:

• Enhanced payment flow logging: Detailed audit trail logging added across the payment processing pipeline, covering transaction creation, payment decisions, order state, tender amounts, and task execution.
• Window lifecycle logging: Additional logging captures the payment progress window's creation, display, hiding, and closing events, along with threading context at each stage.
• Payment routing logging: Entry points and decision paths within the payment routing layer are now logged, including call context and outcomes.
• Error handling improvements: Protective error-handling blocks added around critical payment operations to improve resilience and ensure failures are captured in logs.

Added Additional Logging to Assist with End of Day Publishing Issues [BRNK-66630]

Issue:

Customers have reported issues when publishes are scheduled to be sent during the End of Day process.

Resolution:

We have added additional logging during EOD processing to help diagnose the root cause that can be enabled/disabled using a feature flag.

Integration Settings Refresh [BRNK-64516]

Issue:

Previously, the Register currently only updates Integration Settings when a message is posted to the In-Store queue. This can cause terminals to have outdated settings, particularly when the queue is inactive, such as for locations that are staged, store transfers, or have been offline for a long period of time.

Resolution:

We have added the following processes to ensure the settings are refreshed:

• Automatic settings refresh: Integration settings are now automatically checked and refreshed every 3 days when the Register initializes.
• Staleness detection: The system now tracks when settings were last fetched. On startup, if the stored settings are older than 3 days -- or have no recorded fetch time -- the Register will automatically retrieve the latest settings from the Integration Settings Service.
• Removed manual refresh logic: The previous feature-flag-based mechanism for triggering settings refreshes has been removed in favor of the new automatic time-based approach.

Ability to Manually Adjust or Override Prep Time for Future Orders [BRNK-67073]

Issue:

Previously, there was no way to manually adjust or override the prep time for future orders at the register to handle operational load. Operators need per-order flexibility for staffing, load, and one-offs without changing global future-order prep settings.

Resolution:

Now, staff can manually set a custom preparation time (between 1 and 1,440 minutes) on any future order, overriding the system default. The override is saved with the order, respected by the automatic send scheduler, and clearly indicated in the Manage Future Orders list.

New User-Facing Controls

• Override Prep Time button added to the Future Order window, displaying the currently selected prep duration.
• Input dialog for entering a custom prep time, featuring:
  • A numeric entry field (accepts 1-1,440 minutes)
  • Increment/decrement buttons for fine-tuning
  • Quick-select preset buttons (5, 10, 15, 30, 45, and 60 minutes)
  • A live preview showing the duration in a readable format (e.g., "2 hrs 30 min")

Visual Indicator

• An orange clock icon with a descriptive tooltip now appears next to any future order in the Manage Future Orders list when a prep time override is active.
• The indicator updates in real time as order data changes.

Adding Type to Confirm Dialog to Changeset Publisher [BRNK-65577]

Issue:

Previously, customers were experiencing problems due to changesets being sent to the wrong store by accident.

Resolution:

Now, when submitting changesets to multiple locations, a confirmation prompt will appear before any changes are sent. Note that this prompt will only appear when more than one location is selected -- no additional confirmation is required when sending to a single location. To proceed, enter the number of stores you are sending the changes to -- this step helps ensure accuracy and prevents changes from being sent to unintended locations. Once confirmed, select Publish to apply the changes to all selected stores.

Changeset Publisher and Changeset Packages Improvements [BRNK-65735]

Issue:

Previously, several customers have been reporting issues with publishing.

Resolution:

Now, we have made many changes to improve publishing issues:

Reliability & Stability

• Changeset packages now apply atomically (all-or-nothing), consistent with how registers handle them, reducing partial-apply failures.
• Status update operations are now safe to retry -- running them multiple times will no longer cause duplicate side effects.
• The system no longer triggers unnecessary downstream actions when a publishing status hasn't changed.
• Downstream events and settings updates are now only triggered when a status change is confirmed successful, preventing incorrect behavior after database failures.
• Cache failures are now handled gracefully -- if the cache is unavailable or overloaded, the system continues operating normally instead of throwing errors.
• EOD processing now deduplicates employee records (including jobs, permissions, and security levels) before snapshotting, resulting in cleaner data.

Bug Fixes

• Changeset Apply Errors now display the correct Package ID instead of an incorrect value.
• Changeset Confirmation Dialog no longer shows incorrect location counts.
• Data integrity hotfix: A bad merge had caused unintended updates to message data during schema upgrades; this has been corrected so only the intended field is updated.
• Location information is now correctly included in failed changeset applying log entries, improving diagnostic visibility.

Changeset Management UI

• The Changeset Packages page filter controls have been reorganized -- column header filters have been moved into the dedicated Filter Section for a cleaner layout.
• Status and source dropdown filters are now available on the Changeset Packages page.
• Search now supports filtering by field type and by the user who created the changeset.
• If a search times out, a clear error message is now displayed on the page rather than failing silently.
• A "Type to Confirm" prompt has been added to the Changeset Package dialog to prevent accidental actions. (see BRNK-65577 for more information on this prompt)

Performance Improvements

• Changeset and package search queries are significantly faster, with results now paginated (up to 200 rows at a time) to prevent slow or runaway queries.
• Database indexes updated to speed up location group and user lookups.
• Backend processing optimized to reduce CPU usage during changeset operations.

Include Taxable Non-Revenue Item Sales in Taxable Item Sales in Sales Summary Report [BRNK-66084]

Issue:

Previously, customers had a reconciliation issue where non-revenue item sales (taxable and non-taxable) were not tracked separately in daily sales reporting, causing discrepancies during cash reconciliation.

Resolution:

Now, three new data points have been added to the Sales Summary report:

• Taxable Non-Revenue Item Sales
• Non-Taxable Non-Revenue Item Sales
• External Remittance Non-Revenue Item Sales

This feature is off by default, but can be enabled by enabling the following feature flag:

• IncludeTaxableNonRevenueInTaxableItemSales

Remove Stale Integration Settings During End of Day Processing [BRNK-68181]

Issue:

Registers were losing Integration Settings during high system load, which could disrupt transactions (payment devices, gift cards, Integrations Portal config, etc.).

Resolution:

Two behaviors were changed. When the register starts, there is no longer a refresh check. If settings already exist locally, do not re-fetch. Only fetch when missing. When the End of Day runs, if the business date gap is greater than or equal to 5 days, delete local integrations settings so a fresh copy loads on the next startup.

Serialize headless changeset publishing per location to enable safe concurrency and reduce bulkhead rejections [BRNK-69189]

Issue:

Previously, the publish pipeline was limited to one job at a time; the queue would back up during busy periods, retries would give up before the backlog cleared, and changesets would get stuck and never publish. Locations were left waiting on configuration updates (menus, settings, etc.) that were submitted but never successfully published to headless (register-less) locations.

Resolution:

Now, the solution adds a per-location lock so multiple locations can publish in parallel safely, while packages for the same location still run one at a time -- preventing silent lost updates when concurrency is increased.

Labor Reporting Fix [POG-3154]

Issue:

Previously, labor was reporting incorrectly for a specific customer and location. Attempting to delete a shift from Historical Data that was absent from Historical Data would throw an error and fail.

Resolution:

Now, users can successfully delete a shift from Historical Data even when that shift no longer exists in the Historical Data Master.

Settings Service Update Query Cause Locking [POG-3210]

Issue:

Previously, the Settings Service was causing excessive database lock contention during update operations. Under load, this could degrade system performance or cause update failures.

Resolution:

Now, we have made the following improvements to streamline the Settings Service:

• Removed a redundant database lookup that was occurring before each settings update, reducing unnecessary load and lock contention on the database.
• Replaced fixed interval retry behavior with an exponential backoff strategy that includes randomized delays. This spreads out retry attempts more intelligently, preventing multiple processes from hammering the database simultaneously after a failure.
• Improved logging now captures retry delay durations, making it easier to diagnose issues when retries occur.

May 2026 Maintenance

5.15r2 Release Patches (build 5.0.15250)

Added/Exposed Address, Pick Up Time, External Loyalty Account Information, and AA Surcharge to Order Submission for Instore API [BRNK-65566]

Issue:

Previously, Address, Pick Up Time, External Loyalty Account Information and AA Surcharge were not added to the order submission for the Instore API.

Resolution:

Now, Address, Pick Up Time, External Loyalty Account Information, and AA Surcharge have been added to the Instore API to ensure parity with the External API.

Issues with Enhanced Refunds [BBS-13697]

Issue:

Previously, incorrect prior refund calculations were occurring, and the credit card refund limit was not properly enforced.

Resolution:

Now, several improvements have been made to the refund process. Prior refunds are now correctly calculated by aggregating them using linked order IDs. Refund limits are validated before a tender is selected, and refund amounts are now constrained to the remaining refundable balances across all tenders. Additionally, validation behavior has been standardized to ensure consistent processing across all payment methods.

Enhance Order Event Support and Add New Event Types [BNZ-1629]

Issue:

Previously, the order status webhook event service was missing certain event types, preventing some customers from retrieving the data they needed from BDF.

Resolution:

Now, several enhancements have been made to the order status webhook event service to broaden its supported event types. Close Order Event handling has been updated to allow customers to insert an event into the outbox. The Item Sent Event has been improved to generate Order Items Sent to the Kitchen events. Support for Void Item Events has been added, translating them into BDF Order Items Voided Events. Additionally, the way additional event dates are stored has been improved for greater accuracy.

Increase in Synchronization Failures in Logs [BBS-13759]

Issue:

Previously, some customers were experiencing an increase in synchronization failures that were occurring unexpectedly.

Resolution:

Now, we have added a group settings check that ensures the system accurately determines the status of a synchronization, preventing it from being incorrectly flagged as failed.

When a Shift or Break was Edited after End-of-Day, the Register Application Would Close [BBS-65893]

Issue:

Previously, when a shift or break was edited on the register after End of Day, the register application would close unexpectedly with no error message and would not automatically restart.

Resolution:

Now, the process for checking overlapping shifts has been optimized to ensure existing shifts are properly accounted for before incorporating shifts from the previous day. Customers should no longer experience unexpected register application closures when editing a shift or break after End of Day.

Tender Retail Issue/Activate – Partial Gift Card [BBS-65280]

Issue:

Previously, a recent change to Tender Retail gift cards introduced a bug affecting partial redemptions. For some customers, partial redemptions were not supported correctly, causing gift cards to be over-redeemed.

Resolution:

Now, gift-card partial redemption has been fixed. The NBA and AMT fields in the sales (redemption) response now reflect the correct expected amounts, and the AMD field is also populated correctly.

Punchh 2.0 Updates [BBS-65282]

Issue:

Previously, a specific customer, the Punchh 2.0 flow required updates to basket locking logic. Without these changes, there was a risk that earning and redeeming actions could interfere with guest offers.

Resolution:

Now, the Punchh 2.0 flow has been updated with improved basket locking to ensure a reliable end-to-end experience. Earning and redeeming now occur safely, without any risk of disrupting guest offers.

Overlapping Shifts Prevented Employees from Clocking In/Out [BBS-65563]

Issue:

Previously, the system was allowing shift edits that resulted in overlapping shifts and duplicate punches. This caused errors when importing punch data into Restaurant 365.

Resolution:

Now, when a shift is edited, the system correctly overwrites the affected clock-in or clock-out entry instead of creating duplicate records. This ensures punch data syncs cleanly to back-of-house software such as Restaurant 365 without errors.

Optimized Soft Lock on Editing Time Punches that Cross Midnight UTC [BBS-65565]

Issue:

Previously, when editing shifts from the POS, users could easily get soft-locked by a "Shift start time should be earlier than end time" error. This occurred when a shift crossed midnight in UTC, even if the times were valid in the local time zone.

Resolution:

Now, shift editing on the POS correctly handles shifts that cross midnight in UTC. Users can edit shift times without encountering the "Shift start time should be earlier than end time" error.

Editing or Deleting Older Shifts Caused Admin Portal to Crash [POG-3154]

Issue:

Previously, when trying to delete or edit older shifts, the Admin Portal would crash.

Resolution:

Now, the Shift Service has been updated to accommodate older shifts. The Admin Portal should no longer crash when attempting to make edits or deletions on shifts.

April 2026 Maintenance

Register Crash on Table Service [MH1-2141]

Issue:

Previously, in some Table Service environments, the Register application displayed an error and closed unexpectedly when one user initiated an order, and another user completed the payment. Causing confusion and additional steps to close orders.

Resolution:

Now, additional validation checks were added, including ParPay2 processing enhancements. The application now handles this workflow correctly without errors or causing the application to close. Orders can be paid out smoothly without the added confusion and additional steps.

Side Item Not Sent When a Combo Auto-Apply Sent at the Same Time to QSR Automations KDS [BRNK-64767]

Issue:

Previously, in some Table Service environments, when a side item was added concurrently with other items that triggered an automatic combo, the first side item wasn't sent to the QSR Automation Kitchen Display Screen (KDS). The QSR Capture Player showed the course number as -1. This created order accuracy issues.

Resolution:

Now, monitoring logs have been optimized to work more consistently with QSR Automations. The course numbering is now accurate and no longer shows -1. All items, including side items added with automatic combos, now correctly show on the QSR Automations Kitchen Display Screen (KDS).

Duplicate Item Displays a Second Time After Entrée is Converted to a Combo on QSR Automations KDS [BRNK-63373]

Issue:

Previously, in some Table Service environments, if a Kids Meal entrée was sent to the kitchen and later converted to a combo, the entrée showed up twice on the QSR Automations Kitchen Display Screen (KDS). This could confuse and lead to incorrect orders being prepared.

Resolution:

Now, course numbering in Table Service has been updated to handle this scenario correctly. When a Kids Meal entrée is converted to a combo, it now appears only once on the KDS -- eliminating the duplicate and helping ensure every order is prepared accurately.

MCM Tender Retail Gift Cards Approving on MCM Side, but Show $0 on POS [BBS-13616]

Issue:

Previously, in Canada, when issuing MCM Tender Retail Gift Cards, the POS showed a $0 balance on the Order Window, even though MCM approved higher value that was entered by the cashier.

Resolution:

Now, conflicting Tender Retail requirements have been removed from the POS. The POS now correctly displays the loaded amount, and logs reflect accurate amounts.

"Unexpected Message Received" Error on Freedom Pay Device [BBS-13614]

Issue:

Previously, for some customers, an error message appeared on the POS screen during credit card transactions, "PaymentWaitForCardResponse: Unexpected Message Received: FormEntryRequest" This could interrupt the payment process and cause confusion at the point of sale.

Resolution:

Now, the conflicting code causing this error has been corrected. Credit card transactions now process without displaying unexpected error messages.

Changesets Missing after End of Day Runs [BRNK-64746]

Issue:

Previously, in some cases, changes made in the Settings Editor on the Admin Portal were not consistently applied to registers after the End of Day (EOD) process completed. This caused items to disappear from the registers.

Resolution:

Now, the EOD process has been updated to include a record of all published changes, ensuring that settings updates are reliably captured and applied to registers going forward.

Process Implemented to Rollup Publishes [BRNK-64744]

Issue:

Previously there wasn't a mechanism to consolidate and track published changes.

Resolution:

Now, a rollup process has been implemented, aligning with BRNK-64746, to provide visibility and consistency in published update tracking.

Updated FreedomePay to Accommodate for Delays and Error Messages on Device Lane 3000 [BRNK-65109]

Issue:

Previously, differences in register behavior caused issues with session calls around Line-Item Display, and Tips, leading to device errors or delays.

Resolution:

Now, Lane 3000 has been optimized to work with different combinations of settings including Line-Item Display and Tips. Customers should no longer see the error message, or experience delays when tendering orders with the Lane 3000 device.

Fix for Code 1: Internal Error Responses from Sales2.svc [BRNK-65249]

Issue:

Previously, some customers experienced intermittent failures when retrieving historical order data for transactions that occurred between March 3–4, 2026. An internal error prevented those records from loading, while order retrieval for dates outside that range worked as expected.

Resolution:

Now, the business date settings have been corrected for the affected locations, and the order retrieval process has been improved to handle edge cases more reliably. Historical order data for the March 3–4, 2026 date range is now accessible as expected.

Updated Process to Handle Publishing Retries [BRNK-65158]

Issue:

Previously, when a publish was retried multiple times, the system occasionally attempted to mark the publish completed more than once. This could cause the publishing service to freeze, resulting in delays or unresponsive behavior.

Resolution:

Now, the publishing process has been updated to handle multiple retries reliably, preventing freezes and ensuring publishes complete smoothly without delays.

Replace Service to Reduce CPU Usage [BRNK-65318]

Issue:

Previously, customers were experiencing performance issues when publishing large changesets.

Resolution:

Now, we have upgraded the changeset service storage to a more optimized version, significantly reducing CPU usage and improving performance when publishing large changesets.

Log a New Message When Settings Versions Not Current [BRNK-62949]

Issue:

Previously, when non-current settings versions were requested from the register, a full restart of ServiceHost was required to recover.

Resolution:

Now, a new logging mechanism has been introduced that provides more accurate diagnostics for changeset issues, allowing these problems to be resolved without requiring a ServiceHost restart.

March 2026 Maintenance

5.15r2 Release Patches (build 5.0.15250)

Improved Cache Clearing and Logging for SH Location Settings [BRNK-62949]

Issue:

Previously, issues with mismatched or stale Service Hose (SH) location settings were harder to diagnose and fix. There was no specific warning logged when a register requested a settings version that didn't match the current version, and clearing problematic location settings caches typically required a full SH restart.

Resolution:

Now, the server logs a clear warning when a register requests a settings version that doesn't match the current version, improving troubleshooting for changeset issues. A new SQS message also allows the SH location settings cache to be purged without restarting SH. This enables faster, low-impact remediation while remaining a background process that does not require customer configuration.

Punchh Negative Modifier Display and Loyalty Sign-Up Compliance [BRNK-63393]

Issue:

Previously, negative and zero-priced modifiers from PAR POS were being sent to Punchh and displayed on the Punchh receipt, which could create confusion for guests about how their check total and rewards-eligible items were calculated. During loyalty-sign-up, the Punchh API call from PAR POS was not consistently passing terms_and_conditions = true, creating risk that new guest enrollments might not fully reflect acceptance of terms and conditions in Punchh.

Resolution:

Now, negative and zero-priced modifiers are no longer shown on the Punchh receipt, while they remain fully visible on the PAR POS receipt. This keeps the guest-facing Punchh receipt clear and focused on billable items, while preserving full detail for store staff at the register. Loyalty sign-up requests from PAR POS now correctly pass terms_and_conditions = true to Punchh. This ensures guests are accurately enrolled with their terms and conditions recorded, supporting a clean, compliant rollout of Punchh loyalty and helping ensure guests reliably earn points.

Future Orders Screen Scrolling and Button Usability Fix [BRNK-63876]

Issue:

Previously, the Future Orders screen snapped by full days when scrolling, so stores could only see a limited number of upcoming orders at once. The "Today" and "Future" options also had very small tap areas, causing missed clicks and extra effort for staff.

Resolution:

Now, scrolling on the Manage Future Orders screen is smooth, allowing stores to see all upcoming orders more easily. The "Today" and "Future" buttons now have larger tap areas, making it faster and more reliable for staff to switch views during busy shifts.

Customer Loyalty and Order Events [BBS-13499]

Issue:

Previously, order event data from the in-store registers did not fully match partner requirements, which blocked partners from completing their integration. Loyalty earning for missed visits could trigger validation errors, which in some cases prevented orders from closing and risked duplicate payment attempts.

Resolution:

Now, order events have been updated so partners receive the correct, complete data needed to finish and rely on their integrations. Loyalty processing for missed visits has been corrected so orders close as expected, reducing the risk of validation errors and duplicate payments at the register.

KDS Duplicate Item Fix [BRNK-63373]

Issue:

Previously, when combo orders were sent from PAR POS to the kitchen display system, some items could be sent more than once. This created confusion on the make line and increased food preparation waste as staff might prepare duplicate items.

Resolution:

Now, combo orders are sent to the KDS only once per item, with accurate add-on information. This reduces the risk of duplicate preparation, cuts down on food waste, and helps kitchens work more efficiently.

"No Current Order" Lock Screen Fix for Tablets [BRNK-63338]

Issue:

Previously, at some customer locations, in-store tablets would frequently display a "No current order" message and lock the screen a few minutes after the PAR POS app came online, disrupting order-taking and requiring staff to repeatedly clear the message.

Resolution:

Now, tablets remain available for normal use without randomly showing the "No current order" lock screen, so team members can take and manage orders without interruption.

Loyalty Adaptor Discount Handling [BRNK-63100]

Issue:

Previously, when some customer stores used the new loyalty adaptor, orders that combined local discounts with loyalty rewards could calculate item prices differently than the legacy integration. This caused loyalty errors at the register and a poor experience for both guests and cashiers.

Resolution:

Now, PAR POS sends additional item-level discount and promotion details in the loyalty adaptor payload and suppresses the reward window when a guest has no rewards. This aligns behavior with the prior integration, prevents discount-related loyalty errors, and allows customers to continue the loyalty adaptor rollout with a smoother checkout experience.

Allow EOD Scheduled Package Publishes when Backup Primary is Offline [BRNK-62940]

Issue:

During End-of-Day (EOD) processing, the Primary Register validated that the Backup Primary was online before publishing scheduled changesets (when EnableBackupPrimary was enabled). If the Backup Primary was offline at that moment, the package publish failed with a transient fault status and was not retried until the next EOD. This could delay configuration changes and create confusion when the Backup Primary came online shortly after the check but the package remained unapplied until the following day.

Resolution:

Now, during EOD, the system skips the Backup Primary online validation check when processing scheduled changesets. Packages will be published by the Primary Register even if the Backup Primary is temporarily offline, ensuring that scheduled changes apply as expected at EOD without waiting for the next day. This reduces disruption to configuration rollouts and avoids misleading transient fault statuses.

February 2026 Maintenance

5.15r2 Release Patches (build 5.0.15250)

Enable "Auto Numbering" for Combo Items and Components [ASI-3275]

Issue:

Previously, the Auto Numbering feature only applied to regular menu items. When customers began introducing combo meals, combo parents and their component items were not consistently included in the Auto Numbering group. This caused mismatched or missing numbers between receipts, chits, and order lists.

Resolution:

Now, the Auto Numbering feature correctly includes both combo items and their combo components in the same numbering sequence. Numbers are applied consistently across receipts, kitchen chits, orders lists, and summary chits, ensuring that staff can quickly match items and combos during ordering, prep, and fulfillment.

NOTE: No configuration changes are required to enable the behavior. Once the patch is applied, Auto Numbering will automatically handle combos and their components under the existing Auto Numbering settings.

Declared Tips Report Inconsistencies [BRNK-62604]

Issue:

Previously, some customers reported issues where the Declared Tips report displayed employee names inconsistently. They often showed multiple "Unknown" entries, even after a Back Office Bridge (BOB) regeneration and sync. This caused confusion and made it difficult for franchisees to reconcile payroll and tips accurately, contributing to payroll disruptions and additional administrative burden.

Resolution:

Now, the Declared Tips report consistently displays employee names in the correct First Name Last Name format and removes erroneous "Unknown" entries. Franchisees at the affected location can now rely on accurate tip reporting, supporting cleaner payroll processing and lowering the time spent manually correcting reports.

Add Auditing to EOD Process for Changeset Tracking [BRNK-61632]

Issue:

Previously, some changesets could fail to roll up into End-of-Day (EOD) settings, effectively going missing during EOD processing. It was difficult and time-consuming to identify which locations and changesets were affected when issues occurred thanks to the lack of dedicated auditing of which changesets were included in each EOD settings version.

Resolution:

Now, the EOD process writes detailed audit data for changesets into a new ChangeSetSettingsVersion table in the group database for each location/changeset. After this patch:

• Each changeset published and processed at EOD is recorded once with its corresponding settings version.
• Teams can quickly verify which changesets were included in a given EOD run and troubleshoot EOD-related changeset issues with far greater accuracy.

Gift Cards to be Shared Separately with Paymentree [MH1-2107]

Issue:

Previously, when more than one gift card was added to an order, the POS did not send them to Paymentree as separate line items. Paymentree could not correctly identify and activate multiple gift cards in a single order, limiting activation to a single card.

Resolution:

Now, each gift card in an order is sent to Paymentree as an individual item. This allows Paymentree to identify and activate multiple gift cards in the same transaction, enabling smooth activation of more than one gift card per order using the Paymentree device.

Loyalty Lookup Not Working with Unsent Items [BRNK-62735]

Issue:

Previously, if a cashier tried to look up a guest while an order contained items that had been added but not yet sent, the register would display a white screen and the application would freeze or crash. Staff had to restart the register program to recover, disrupting service and preventing reliable use of loyalty lookup during active orders.

Resolution:

Now, loyalty/guest lookup works as expected even when the current order has unsent items. The screen no longer goes white, the application does not freeze or crash, and staff can freely perform guest/loyalty lookup, assign/unassign guests, and redeem rewards without interrupting order flow.

Punchh Key Readability Fix for Non-Barcode Printers [BRNK-62656]

Issue:

Previously, when some customer locations using Punchh printed receipts on printers that do not support barcodes, the Punchh key/barcode line did not render correctly. The numeric Punchh value overlapped on the receipt and was not fully readable. This kept guests who had not identified at the register from seeing the number they needed to claim or earn loyalty points for that order.

Resolution:

Now, the Punchh key prints clearly on non-barcode printers with no overlapping digits. Guests can now easily read the full Punchh number from the receipt and use it to claim or earn loyalty points after the transaction, restoring the intended loyalty workflow.

Post-Upgrade Heartland Credit Batch Failures at EOD [BRNK-62755]

Issue:

Previously, after upgrading to PAR POS 5.15, locations using Heartland Credit experienced failures when closing their Heartland credit card batch at EOD. MSR credit payments were not successfully settled with the Heartland processor as a result, requiring an interim script to manually send the batch to Heartland.

Resolution:

Now, Heartland credit batches close successfully at EOD for relevant locations. Credit audits show successful batch closure, and MSR credit payments are properly settled with the processor, eliminating the need for interim manual scripting to send batches.

Auto-Close Orders After Payments are Applied [MH1-2108]

Issue:

Previously, pay-at-table orders paid via Paymentree were not auto-closed when the payment was completed on the device if the POS user who created the order was logged out. This left fully paid orders with zero balance still open, requiring manual intervention to close them.

Resolution:

Now, for locations using Paymentree, all pay-at-table orders are auto-closed once the balance due is zero, even if the originating POS user is logged out. This reduces manual clean-up of fully paid orders and lowers risk of open/stray checks after successful payment.

SetFutureOrder Crashing POS with ButtonPrimaryForeground Error [BRNK-62621]

Issue:

Previously, when cashiers selected the Phone In button configured with Set Future Order, the POS register crashed with a ButtonPrimaryForeground resource error. This prevented staff from creating future-dated phone orders and disrupted service at impacted locations, with no verified workaround available.

Resolution:

Now, the missing UI resource on the Phone In template has been fixed so the register no longer crashes when Phone In is used to create a future-dated order. Staff can reliably create, edit, and process future phone orders without impacting register stability.

Ensure All Active Terminals Appear in Bob TermInfo Report [BBS-13383]

Issue:

Previously, active terminals were missing from the Bob termInfo report, leading to us having an incomplete view of hardware used by PAR POS. Accurate terminal data is essential for customer communication regarding .NET upgrades and Windows compatibility.

Resolution:

Now, the Register refreshes and sends terminal hardware information on a regular 7-day interval, even when no hardware values have changed. This patch ensures all active terminals are consistently represented by keeping terminal information up to date.

Clear Terminal Status Messaging (Phase 1) [BRNK-61845]

Issue:

Previously, register terminal status labels used generic "Online" and "Offline" messaging, including "Online – Synchronization Failure" and "Offline – Synchronization Failure." These terms were unclear for users and did not offer any guidance on what to do when synchronization issues occurred, making it harder for store staff and support agents to quickly understand and respond to terminal connectivity problems.

Resolution:

Now, register terminal status messages have been updated to be clearer and more actionable:

• Online remains Online
• Online – Synchronization Failure is now Online – Sync Fail, Call Support
• Offline is now Limited
• Offline – Synchronization Failure is now Limited – Sync Fail, Call Support

These new labels better describe when a terminal has reduced functionality ("Limited") and clearly instruct users to contact support when sync failures occur.

Tablets Intermittently Showing "No Current Order" [BRNK-63338]

Issue:

At specific customer stores, all tablets (secondary registers) would repeatedly display a "No current order" lock screen shortly after the PAR POS app came online. Even if staff tapped through the message and resumed taking orders, the "No current order" screen would return after a few minutes and lock the tablet again. This behavior persisted even after reinstalling POS and BMS, disrupting normal order-taking workflows and causing repeated interruptions at the register.

Resolution:

Now, tablets no longer randomly show the "No current order" message every few minutes, and secondary registers remain usable during normal operations. Assigning a loyalty customer from any register no longer causes "No current order" to appear on secondaries, so staff can continue taking and managing orders without intermittent lockout.

UI/UX Enhancements for Future Orders Screen [BRNK-63876]

Issue:

Previously, the Future Orders scroll bar moved in full-day jumps, so staff could only see about 12 days of future orders and couldn't smoothly browse beyond that range. The "Today" and "Future" options on the Manage Future Orders screen had very small clickable areas as well. Team members had to tap exactly on the text label for the toggle to work, causing frequent missed taps and frustration at the register.

Resolution:

Now, scrolling behavior has been updated so all future orders can be viewed. Staff can smoothly scroll the full list of upcoming orders, not just the first 12 days. The tap/click area for the "Today" and "Future" options has also been widened, so team members can tap anywhere within the button area. This makes it much easier and more reliable to switch between Today and Future orders during busy service.

Preventing Duplicate KDS Orders and Food Waste [BRNK-63373]

Issue:

At some customer locations using QSR with Kitchen Display System (KDS), certain order flows (including combo scenarios) could cause the same items to be sent more than once to the KDS. This resulted in duplicate make tickets, unnecessary food preparation, and increased food waste.

Resolution:

Now, with this in-store register patch, items sent in QSR and combo workflows now appear only once on the KDS. Kitchen staff also receive a single, accurate order with correct add-on information. Food preparation waste caused by duplicate sends is eliminated, while existing functionality is preserved.

January 2026 Maintenance

5.15r2 Release Patches (build 5.0.15250)

Removal of Pop-Up Confirmation for Printer Routing [BRNK-61303]

Previously, users encountered a new pop-up confirmation after every printer re-route due to enhancements in printer routing. This additional confirmation felt counterintuitive, especially when used in macros that could trigger multiple pop-ups. This new pop-up confirmation has been removed. This change streamlines the user experience, allowing for smoother printer routing without unnecessary interruptions.

Hot Reload Feature Issue [BRNK-59197]

Previously, the Hot Reload feature was inconsistent. Published Active/Inactive items would not update on secondary registers until a manual restart or selection of another button was performed. This led to confusion and delays in item availability during operations.

Now, the Hot Reload functionality has been improved to ensure that published Active/Inactive items update automatically on the default screen without requiring a restart.

Add Auditing to EOD Process for Changeset Tracking [BRNK-61632]

Previously, changesets were failing to roll up into End of Day (EoD) settings, leading to missing data and complicating troubleshooting efforts. This issue was made worse because, without auditing data, identifying affected locations and changesets was challenging.

Now, we have implemented a new ChangeSetSettingsVersion table so that EoD processing will accurately log which changesets are rolled up into the EoD settings. This enhancement provides better tracking and troubleshooting for changeset EoD issues.

Version History

Version	Date	Updates
1.0	6/2/2026	Initial Release