When I am demonstrating the functionality around cash and bank management this is always a place where the solution falls down.
Customers like the idea of blind closing shifts. But a key part of the 'cashing up' process is to complete a bank drop.
At present you cannot complete a bank or safe drop from the blind closed shifts (soon to be Manage shifts) screen. So this results in customers not implementing blind closed shifts at all, at risk of confusing store staff.
Please add buttons to complete both bank and safe drops from the blind closed shifts screen - In fact, all cash/shift operations should be available!
In Dynamics 365 it is difficult to see if all retail transactions have been financially posted. Issues, errors and bugs sometimes results in that transactions are not included in the statements. In most companies it is common practice to perform financial period closing, and then closing the period. But to be sure that no more transactions will be posted, it would make sense to have some functionality to see transactions that have not been posted/financially updated. Also, a financial reconciliation would make sense to have, making sure that all statements have been calculated and posted. Also including steps in the financial period closing would help. Can we have more reconciliation functionality in the retail/Finance domain ?
Make the VAT group code on the address mandatory in case destination based tax is enabled on the channel
Setting destination based tax on the retail channel enables you to use the VAT group on address for tax calculation. However, this field is not mandatory and can be kept empty. This leads to wrong VAT calculation and cannot be corrected.
Please make the VAT group on the address a mandatory field when destination based sales tax is enabled for the retail channel.
I have communicated with the product team via e-mail (please refer to communication with Ruben Delgado). Don't hesitate to contact for more information and/or validation with our customers' case.
For a retailer there will always be some cash deviations, and for a retailer it is important to document the reason why there is a cash deviation in the tender declarations. This is often user errors or misunderstandings. The ability to document the reasons behind the issues are important, and the ability to attach documents/notes/pictures to the deviations are essential. On unposted statements it is possible to attach documents, but this is not transfered to the posted statements. Also it is not possible to attach documents to shifts or posted statements. For audit purposes it is a requirement to document theese deviations.
1. Create a retail statement, and attach a note/document to the statement header
2. Post the statement, and then check if the document is related to the posted statement.
3. Try adding a document/note to a shift
4. Try adding a document/note to a posted retail statement.
If Payment amount for Deposit for Customer order registered in POS is smaller then Max penny difference then this Payment amount is posted to Penny difference voucher.
1. In Account receivable Parameters in Settlement tab enter Mx penny difference = 1$
2. Login to POS and register new Customer order for small amount
3. Pay Deposit amount which is not bigger then 1$. Pay 1$ deposit amount.
4. Go to AX and verify transactions for Customer
In effect there are registered 2 Vouchers:
- Payment journal for Amount = 1$
- Penny difference voucher = 1$
There should not be posted Penny difference voucher.
Retail Post Statements in Batch will not be picked up Statements in the batch task if transactions older than 30 daysWhen the store statement closing method is set to Date\Time and statements with Transaction date older than 30 days are scheduled to post statements in batch, the statements will not be added to the batch task.
There is a limitation in the RetailStatementPostChecker class to check for Transaction dates older than 30 days.
Customers who import retail transactions from legacy systems or statements with errors than need to be fixed, may need longer than 30 days to processes statements in batch. Imported statements may be too large to post manually so batch posting is needed.
We would like to see a parameter that allows customer to set their own days to check when transactions should be selected to post statements in batch.