-
Approval of discount by manager
It is possible to setup different limit for discounts for cashier and for manager. But there is no easy way how the manager can approve a discount that is bigger than cashier limit, but within manager limit. In case the employee discount limit is exceeded, it should be possible to input credentials of another employee and if his limit is sufficient, the discount should be granted. -
D365 invoice number respects receipt number from POS
It should be able to use receipt number from POS as invoice number during statement posting in D365 for identified customer. Reason: Some EU countries have additional regulations for invoice printout in stores, for example VAT control report. If a company customer comes to the store, he needs to: 1) Receive an invoice as a fiscal document instead of simplified POS receipt (under some conditions, for example amount > 10.000CZK and customer registered for VAT) 2) The number on the document must match the number of invoice in system, because it is part of VAT reporting and the government must be able to cross-check the invoices (what customer A reports as an issued invoice to customer B must be found by customer B as received invoice from customer A). Ideal solution would include additional setups, like limit from which the invoice is mandatory and if it applies to company customers only or to all customers. -
Retail discount based on brand
We often see a requirement to define retail discounts based on item property, most typically Brand, eventually other attribute / field on item. Example: provide discount 20% on all bags from Mammut. Today this is not possible, the only item relation possible is item or item category (eventually category with exceptions), based on the main retail category hierarchy. -
Customer claims in retail
Almost all retailers need to deal with customer claims. The perfect solution should consist of: 1) Warranty setup in HQ - this is announced for future release 2) Possibility to create claim case in POS or in CallCenter - search for original receipt, pick product - describe defects, eventually use defect dictionary - evaluate if the product is in warranty or not - identify customer (even if the original sale was anonymous) 3) Synchronize with HQ - case management or new entity? 4) Support the process of decision making on POS or in HQ (or PowerApp, ...) 5) Finalize the case in POS or in CallCenter - return money - exchange product - provide discount - repair product - reject the claim Nice to have: inventory tracking, validation of serial number, parcell tracking or interface -
Automatic retail transactions settlement in EEU countries
If we use mixed payments (for example Cash + Card) and automatic settlement, the statement posting ends with an error (in Eastern Europe localization). The reason is that the EEU localization does not properly map the (multiple) payments with (one) invoice in customer balance settlement and sometimes even uses some old open customer transaction for settlement that does not originate from the statement. In code (class RetailEodStatementPaymentJournal method setPaymentLineMark): only the first payment transaction is marked for settlement, the others are not as there is already the first one marked. Then the amounts do not match and this results in journal posting error. Alternatively if there are any open customer transactions on the same customer, the same error can occur even by normal payment. Has been reported as a bug, issue https://fix.lcs.dynamics.com/issue/results/?q=450485 , but the correction will only ensure mapping of the first payment with the invoice, not full settlement. In my opinion, full settlement is a must-have for most retailers in EEU. -
Intrastat list code based on store address
Today invoice posted for identified customer uses the primary customer address as invoice address even for cash&carry sales. The problem is that the address is used as a criteria for selecting the list code on the invoice that is used as a base for Intrastat reporting.
If a customer with primary address in Germany buys product in my Czech store, the sale is now reported as EU sale and it should be local sale.
-
Tender declaration transaction entity
We try to integrate 3rd party POS through standard entities. We have an entity for most of what we need, but one thing is missing - the tender declaration transactions (=counting of money in till at the end of the day).
The entity RetailTransactionTenderDeclarationTrans does exist, but cannot be used for data import. It looks like it can only be used for updating existing transactions, as part of the Retail auditable transaction composite entity (https://learn.microsoft.com/en-us/dynamics365/commerce/edit-cash-trans).
It should be possible to import the whole dataset from a store using standard entities and there should be an entity for the tender declaration. I have heard that it might have been possible before, but was later deprecated.
You’re offline. This is a read only version of the page.
