-
Process Credit Card Payment from Payment Journals and Free Text Invoices
We would like to be able to take credit card payments for customer's open AR, and to process them directly in D365 using a process similar to how credit card payments are taken in MCR/Call Center, rather than having to process the payment externally and then record the details. -
Support Adyen Pay-by-Link feature for Call Center and POS card-not-present scenarios
https://docs.adyen.com/checkout/pay-by-link To support scenarios where we would sell to a customer via an email or phone interaction, selling either out of Call Center or in some cases POS, we would like to be able to leverage the Adyen Pay-by-Link feature via direct integration from F&O. The idea being that we stage the order with payment to be make via payment link, F&O interacts with the Adyen API to generate the link, F&O emails the customer (via an email template), and when the customer completes the payment, the order is updated to show payments satisfied. (or something along those lines). -
Allow Date (DateTime) attributes for Customer Attribute Groups
Currently, only attributes of type Decimal, Integer, Text, and TrueFalse are allowed to be added to Customer Attribute groups. This prevents having a properly structured date field for capturing things such as birthday using the attributes mechanism. -
Reuse existing auth on Call Center order credit card payments when order total changes
Currently, when a Call Center order that has previously gone through Completion is subsequently modified (so, an order amendment), if the order total changes, the Call Center Credit Card Payments mechanism will void the existing auth, and then try to get a new auth. In the case where the existing auth would have been sufficient to cover the new order total, the current logic is voiding the existing auth and getting new one for the lesser amount. Example: say the original order and payment total was $2000, and the new order total after amendment is $1900 -- the 2000 auth is voided, and a new one is attempted (and which may be declined) for 1900. This seems unnecessary as we would be able to capture the entire new total of 1900 off an auth for 2000 without issue. Further, in our case with high order values, it happens very often that the void auth is not honored by the bank, and the new auth(s) are declined due to insufficient open-to-buy on the customers' payment cards. Similarly, in the case where the order total increases, it would also be very nice to again use the existing auth and get an incremental auth for the remainder. Again, in the case where a $2000 order goes to $2200, rather than authorizing a customer's account for a total of $4200 that may take time to fall off their open-to-buy when their bank doesn't support void auth, it would be a much better customer (and commercial) experience to auth for 2000, and then auth for 200. The ultimate impact here is that in our use case with rather high average order values, more often than not, literally any change to a Call Center order ends up in us losing the sale when the new auth declines and the customer backs out of the transaction. -
Update ADLS Export to use the CDM Manifest model to align with F&O and CDMUtil
To simplify (and automate) the uptake of exported data to Azure Data Lake, it would be helpful if the CDM metadata could be generated in the newer Manifest format (https://docs.microsoft.com/en-us/common-data-model/cdm-manifest), consistent with how F&O's upcoming Export to Data Lake feature and the tooling being generated by the product teams for automating the mounting of this data onto Synapse (https://github.com/microsoft/Dynamics-365-FastTrack-Implementation-Assets/tree/master/Analytics/CDMUtilSolution). -
Allow Commerce Scale Unit to be installed under a user with period in the username
This may not be the best category for this, but it's a category.
Update the CommerceStoreScaleUnitSetup.exe installer to either allow the "." in usernames, or more broadly to follow Windows rules for allowed usernames.
The CommerceStoreScaleUnitSetup.exe installer (the Commerce Scale Unit sealed installer) does not allow installation under a username that contains the "." character. The "firstname.lastname" username convention is standard for my org (and many others), and having this constraint in the installer framework prohibits such users from installing locally for development and thus prevents from using the "F5 experience" for development, among other things.
This request is to relax the constraint on the "." character appearing in usernames since it is valid for windows usernames?
(Note: the ideas site is not allowing me to post the patterns as it detects them as malicious input, but I've listed them out in the links below)
Also raised a few other places: https://github.com/microsoft/Dynamics365Commerce.ScaleUnit/issues/17 and https://github.com/MicrosoftDocs/dynamics-365-unified-operations-public/issues/4063
-
Add support for camera-based barcode scanning to Store Commerce for iOS/Android
To make the Store Commerce experience on mobile more seamless, we'd like to see a native, camera-based barcode scanner embedded in the app (something along he lines of https://github.com/Redth/ZXing.Net.Maui since Store Commerce is MAUI-based) added to input controls (primarily the NumPad, and secondarily the search box).
While we could use external bluetooth devices, we would like the experience to be and feel native to the device app, and moreso to keep deployment and operation simple (we are concerned that at chain-wide scale, bluetooth free-floating scanners that are supposed to be paired with their corresponding iphone/ipad will get lost more than they are used).
-
Allow Customer Attributes to be made non-editable (but not "Hidden") in POS
There was a relatively recent feature add to make attributes able to be hidden in POS. We have a use case where we want certain information to be displayed on customer profiles via attributes, but where those attributes should not be able to be changed by retail users (in this case, the attributes are maintained via a feed from Customer Insights).
So the ask here is (something along the lines of):
- add a flag to the Attribute setup to allow it to be marked as read-only in POS
- have POS respect the read only behavior such that it will not present attributes marked as such in the customer edit screen (knowing how customer edit works, this would probably mean simply hiding them from display on the edit screen but keeping them in the model).
-
Configure payment service per Call Center channel (within the same legal entity)
Allow multiple payment services to coexist in the same legal entity and/or move the configuration of Call Center payment services to the Channel level (similar to how retail/POS payment service is defined at the Hardware Profile level).
For larger enterprises with multiple brands or lines of business coexisting in the same legal entity (both system and on-paper LE), it can be necessary to segment payment acceptance along the natural segmentation lines of the business. In the current state, only one Payment service can be defined at the legal entity level, and then all call centers within that legal entity utilize the same service.
-
Ability to print (or reprint) transaction receipt from Headquarters
In support of audit, review, and centralized service, we would like to be able to view the receipt for in-store transactions (as they would look if generated in-store) from above the store.
This comes up frequently in audit, regulatory compliance, and chargeback defense scenarios, and the only means of obtaining a copy of a receipt is to either physically centrally warehouse them, or to have an in-store team generate, digitize, and remit. This is both inefficient and potentially problematic (if you're auditing the in-store team).
You’re offline. This is a read only version of the page.
