When splitting checks, if the check is named it would be a major improvement if the subsequent checks caused by the split would have something other than the default Walkin name.  For example, if a check is named Jason and you split it 3 ways, have it name the others "Jason (2)" and "Jason (3)".  Currently if there are any other tabs not named, its a pain to sift through and try to find your checks based on the items they ordered.

Plenty of requests asking for this, but all marked as completed because KDS can handle.    This functionality needs to be offered as a manual operation, as well.    Not sure if Toast has this functionality, but Heartland Restaurant sure does, and it's a necessary feature enhancement to keep up with competitors. 

Currently, if you are setting the price on the modifier with "Set Price," you have to set a price for all sizes that modifier may be used for.     Would be nice to be able to choose ALL SIZES to set the price on.

With covid you need online gift card sales integrated with POS system

Would like to be able to print a chit when you check Gift Card balance.  Potentially also when you sell a gift card as sometimes you may want to sell multiple gift cards in one transaction.

This can be under the employees tab on the dashboard. This way accounting will not need to reference other sources. This will save us a lot of time and effort if we are able to see that the reason we are over labor is because a trainee is clocked in rather than being overstaffed. It would also be nice to display their employment status(ie. Trainee, Barista, Manager) so that Accounting can factor that as well.

When selecting mods under the mod ribbon it’s nice to go back to a previous mod group and make a change. 

Ideally we would be able to return to the mod heading, touch the previously selected mod to “unselect” and then select the desired mod.

1. Objective

To address and resolve the issue of insufficient decimal precision (currently limited to 4 decimals) in the exchange rate configuration between the FCFA and the US Dollar (USD). The goal is to allow for at least 8 decimal places to ensure accuracy in financial transactions and reporting.

2. Background

The FCFA (Central African Franc) has a relatively low value against the USD, resulting in exchange rates that are often represented as small decimal fractions. Due to this, even minor rounding or lack of decimal precision can lead to significant discrepancies in converted values.

Currently:

• The system restricts the exchange rate display and calculations to 4 decimal places.

• For example, the actual rate of 0.00171141 USD per 1 FCFA is rounded to 0.0017, which introduces errors.

• A change of 30 FCFA (from 585 to 625) results in only a 0.0001 shift in the displayed exchange rate (from 0.0017 to 0.0016), which is not granular enough for accurate representation.

3. Problem Statement

Limiting exchange rate precision to 4 decimal places causes:

• Inaccurate currency conversions.

• Misleading financial values in reports and transactions.

• Large jumps in apparent exchange rates due to rounding.

• Decreased reliability in systems handling multi-currency transactions.

4. Requirements

Functional Requirements

• FR1: The exchange rate system must support a minimum of 8 decimal places for rate entries and calculations.

• FR2: All interfaces displaying exchange rates (UI, reports, APIs) must reflect the enhanced precision.

• FR3: Rounding logic, if any, should only apply at the display level, not at the storage or calculation level.

Non-Functional Requirements

• NFR1: The change should not degrade system performance during exchange rate calculations.

• NFR2: Historical data must remain valid and accurate post-update.

• NFR3: Adequate testing should be done to ensure backward compatibility.

5. Priority

High – Required to ensure the financial accuracy of transactions involving African currencies, especially FCFA.

6. Stakeholders

• Finance & Accounting Team

• IT Systems/Development Team

• Product Managers

• External Partners (if APIs are affected)

7. Proposed Solution

Update the exchange rate module and database schema (if required) to:

• Store and process exchange rates with at least 8 decimal precisions.

• Ensure all modules consuming exchange rates (including 3rd party integrations) respect the updated format.

8. Timeline

To be determined based on development capacity, with a recommendation to prioritize the change in the next update cycle or patch release.

9. Risks

• Potential data inconsistency if decimal support is added inconsistently across subsystems.

• Possible need for UI redesigns where space or formatting was based on 4 decimals.

We would like to request an enhancement to the inventory count sheets. Kindly review the possibility of adding the following columns:

• Category
• Sub-Category
• SKU Code
• Brand Name

Employees having the ability to easily check their hours from the POS.