DYNAMICS 365 COMMERCE - Cash traceability feature
In addition to the official Microsoft Docs for Cash management https://docs.microsoft.com/en-us/dynamics365/commerce/cash-mgmt , there are some more details about this feature.
Why is Cash traceability feature needed?
- One-sided cash management transactions
- Does not enable tracking of cash
- Difficult to pinpoint accountability of cash
- No reconciliation of cash transactions
How does it work?
- Introduction of Safe entity
- Management of Safe & Safe specific transactions
- Double sided cash management transactions with ability to create one-sided transaction as an exception
- Reconcile & approve cash management transactions
- Tag reason for exceptions during the reconciliation process
- Validation at the time of closing the shift that all transactions are reconciled or approved for exceptions
Safe entity:
- Definition of Safes for the channels
- Introduced new POS operation – “Manage safes”
- Perform Safe specific cash management transactions:
- Declare start amount
- Float entry
- Remove tender
Cash mgmt. Transactions:
- Ability to create linked cash management transactions
- Declare start amount
- Float entry
- Tender removal
- Safe drop
- Bank drop
- Flexibility on sequencing of entry
- Float entry can be entered before Tender removal
Reconcile:
- Reconcile cash management transactions
- Approve & tag reasons for unreconciled transactions
- Undo reconciliation till the shift is closed
- Shift can be closed only after all transactions are reconciled
Things to consider…
- Cash reconciliation is always for a ‘Shift’. It is not for a Terminal / Register / Safe. With ‘shared shift’, a shift can be across multiple Terminal / Register / Safe
- The Safe entity can be managed with a regular terminal / register or it can also be managed with a dedicated terminal / register. If the intent is to reconcile a Safe independent of a regular terminal / register, then the recommendation is to create a dedicated terminal / register to manage a Safe
- Cash traceability should not have any impact on statement posting process (Enhanced / Trickle feed). Any time you see statement posting process having issues with cash traceability feature, try to repro the issue without enabling cash traceability
- System never had a mechanism to carry forward balances at Terminal / Register / Shift level. Cash traceability feature does not enable to carry forward balances
- Before we introduced ‘Cash traceability’ feature, we had the setting on Payment method/Safe transactions/Safe account that allowed for GL posting for ‘Safe drop’ transactions. With ‘Cash traceability’ turned on as well, the GL postings for this will continue the same way. ‘Cash traceability’ feature by itself has not introduced any new GL postings and as such - like all safe transactions to post to the general ledger when money moves in or out of the safe - are not supported. Please do keep in mind that this parameter only supports GL postings for Safe drop transaction. Statement posting is the only way to get financial transactions for retail transactions created/posted in the store.
E.g. in our solution, the flow of cash can happen between the Safe (Shift) to Register (Shift) and then back from Register (Shift) to the Safe (Shift). With that:
a. At the end of any given day or shift, with Tender declaration we are closing the Register (Shift) and before that the cashier performs the Safe drop operation which takes the cash from the Register (Shift) and moves it to the Safe (Shift) .This transaction does create a GL entry which increases the balance in the GL account linked to the Safe drop transaction. NOTE: Customers have some money in Safe which they use every day to move to Register - e.g. from Safe to Register operation is happening every morning for many of customers and they do not move money from Safe to Bank every day. This is like money circulating inside the store. And this move is not posted to GL. We will post entries to GL only when we use Bank drop operation. See the 2nd point.
b. When the balance in the Safe (Shift) goes above a particular limit by which it is no longer a good practice to keep that much cash in the Safe, retailers typically transfers the cash from the safe to the bank and in the system they perform a Bank drop operation for the same. This also creates a GL posting where in the balance in the GL account linked to the Safe is reduced and the balance in the GL account linked to the Bank is increased. (essentially cash is deposited in the bank account).
c. We do not support GL voucher posting for Float entry. The GL posting is only supported for Bank drop and Safe drop actions. The system allows the user to specify different GL posting accounts for Bank drop and Safe drop depending on the tender type. The confusion is caused because the name of the tender type 9 i.e. “Tender remove/float” contains the keyword “float” so the customer assumes that the GL account of this tender type should be used for Float entry. However, this tender type is used only for internal accounting purposes i.e. for each cash transaction i.e. Float, Tender remove, Start amount etc. we record a positive amount using the appropriate tender type e.g. Cash and then we create a negative entry of same amount using the tender type 9 (on standard Contoso). In other words, if the user did a float entry with cash, then the Cash payment method would be used to record that entry and the same amount with negative sign will be recorded using the tender type 9. In both tender types, there is no way to specify a GL account for Float action.
-
Statement method – Closing method:
- Statement method denotes how will I see the lines on the statement (Payment method + Operator id, Payment method + POS terminal + Payment method + Total, Payment method + Shift)*
- Closing method denotes what transactions will be picked in the statement (Shift, Date and time)*
- Closing method of Date and time is prone to differences cos:
- Tender declaration is always for a Shift cos Cash reconciliation is always at a Shift (it is not up to a date and time) however
- Transactions only up to a user defined Date and time will be pulled into a Statement, but the Tender declaration amount is for the entire shift. When these are brought on the statement line, there is bound to be differences based if the Date and time is defined such that not all transactions of a shift is pulled in
- Combination of Statement method – Closing method can also cause differences. e.g.: If Statement method is Operator ID, the statement lines will be by Payment + Operator ID but the Tender Declaration is not by Operator ID
* Recommended configuration is Statement method – Shift & Closing method – Shift.
There is video recording showing Advanced Cash Management Business Scenario with excel file, find attached attached. Video shows how Safe Management is designed to be working and explain to the customer how to proceed with daily operations.
Some useful information to know about Advanced Cash Management feature:
IMPORTANT:
- To make this feature work well, make sure that you perform the Safe operation (not Safe drop) on a different Shift by opening up a new Shift on a terminal dedicated to the Safe only. Feature of Advanced Cash Management is created to be working only at Shift level, not Register or Safe level.
- We have “Manage Safe” operation that is to be used to manage the Safe.
- There is no option to select foreign currency in safe drop / float entries / bank drops in standard Advanced cash management feature. The system is always assuming the Store currency. This is how it worked before 10.0.25 version. Currently, after version 10.0.25) the safe drop and bank drop for currencies is supported with the advanced cash management feature. There was an issue with the safe drop of currencies which was fixed with the bug 667997 (https://fix.lcs.dynamics.com/issue/results/?q=667997).
- Statement: In order to take out Cash from the Safe to any given POS Shift, the Shift will have to be open:
This is the current design. We have an item in our backlog, where the Store Manager can remotely open the Shift for the Cashiers and do a Tender removal from the Safe Shift. The Cashier would then be expected to only do the Declare Start amount in their Shift. This backlog item is not currently slotted for any release. Otherwise, it is a relatively simple extension to achieve this.
- Statement: In the presentation shown both - a Start amount and a Tender declaration in the Safe Shift. The day after we will have a balance in the Safe some amount. Therefore we will not need to declare Start amount for the next Safe Shift:
These are business processes that might vary organization to organization. The intended design for this was just like how one would reconcile the normal sales Shift, there would be a reconciliation of the Safe Shift as well. At the end of the day, the Manager would count the money in the Safe and do a Tender Declaration to record any / gain loss in the Safe. The next day / Shift, the Manager would do a Declare Start amount to specify what is the Starting amount for the day / Shift (Start amount will not come automatically from the previous day). Please bear in mind that there could be multiple Managers who are manning the store / Shift and as such it is imperative that the Safe Shift gets reconciled just like any other Shift.
- Statement: The Safe Shift includes only Tender activities that happens in the actually Shift:
The Safe Shift is not different than any other regular sales Shift. All Shifts include Start amount + Tender activities. Let’s fundamentally agree that reconciliation of a Safe Shift is important. If so, any reconciliation should always include Start amount + Tender activities in the day compared to the Tender Declaration. One cannot say, I need reconciliation and I do not want to do Start amount or Tender Declaration for the Shift.
- Statement: What happens if we leave the Safe Shift open day after day… week, months, years?
The intended design - it is not recommended to leave the Safe Shift open for ever.
The Cashiers can do a Safe Drop and do a blind close Shift. The Store Manager can then do a Float entry for the Safe drops in the blind closed Shift and can then close the Shift from his console.
- Statement: It is demonstrated how many processes, how many clicks and how accurate you have to be, in this one flow, for this functionality ever to work:
In real world, these processes are executed by different personas over a period of time in the store.
The capability was build based on customer feedback and was vetted by customers in the preview program and is used by a fair number of them. We understand that while this will apply broadly, it might not be so in every case. Hence an extension can be done by customer/partner.
-------------------------------------------------------------------------------------------------------------------
At this point, there is no intended change / development to what is already shipped as a part of the Cash Traceability feature.
We have quite a few large brand customers already using the feature as it is or by extending it beyond what is already shipped to handle specific cases.
These are standard procedures in the Dynamics world. The features that we ship in the product will broadly apply to a large no. of customers, but it may not work for every customer out there. In such, situations, the customer / partner either leverages an ISV or extends the solution.
