End users (Operations team and Purchase) started reporting that the Purchase Order status is changing automatically without them changing anything. The environment on which this issue was reported is Platform Update 32 – 10.0.08.
The purchase order status was changing from Confirmed to Approved and when Operations tried to GRN the order it caused an error –
“Purchase order is no longer confirmed. Posting of the order has been cancelled”.
I was trying to backtrack and check what was the code deployed in the last few packages that could have caused it, but found no code that could have caused this issue.
Finally I suspected that its a bug in the standard itself. I searched LCS and found the following issue-
If you are facing the same issue, do visit the above link and subscribe to be notified for the fix
Been a while since I last posted as I was busy with upgrading our implementation from v7.1 to v10. During our upgrade from Dynamics 365 for Retail v7.1 to v10.0, one of the main issue we faced is that of Backward compatibility.
The issue occurs when trying to run v7.1 MPOS with v10.0 Retail Server, basically “Declare Start Amount”feature does not work.
On trying to declare the start amount the cashier gets the following prompt.
On trying to key in any value, the start amount results as NAN.
Reattempting to declare the start amount simply repeats the above prompts. Now this issue is serious since it prevents the closing of shift as shown in the screenshot below.
My investigation started with debugging the MPOS code and eventually the CRT code, and I found that one of the fields “StartingAmount” had been removed from crt.ShiftsView. This was causing its value to stay as undefined.
The good news is that issue is reported to Microsoft, and we are currently awaiting the fix (currently expected in v10.0.4)
When trying to build the MPOS solution on my laptop, I got the below error.
Error APPX0501 Validation error. error C00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 10, Column 50, Reason: —————‘ violates pattern constraint of ‘(CN|L|O|OU|E|C|S|STREET|T|G|I|SN|DC|SERIALNUMBER|Description|PostalCode|POBox|Phone|X21Address|dnQualifier|(OID\.(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))+))=(([^,+=”<>#;])+|”.*”)(, ((CN|L|O|OU|E|C|S|STREET|T|G|I|SN|DC|SERIALNUMBER|Description|PostalCode|POBox|Phone|X21Address|dnQualifier|(OID\.(0|[1-9][0-9]*)(\.(0|[1-9][0-9]*))+))=(([^,+=”<>#;])+|”.*”)))*’. The attribute ‘Publisher’ with value ————- failed to parse. Pos.App ” 1
App manifest validation error: The app manifest must be valid as per schema: Line 10, Column SO, Reason: ‘xxxx’ violates pattern constraint of ‘(CNILIOIOUIEICISISTREETITIGIIISNIDCI
PhoneIX21 . The attribute ‘Publisher’ with value ‘xxx’ failed to parse.
It took me a while to figure it out but this was happening because certain features in Visual Studio were not installed, the Retail SDK Handbook helped me to confirm which features were needed to be installed. After installing the highlighted features, I restarted the machine and the solution built successfully.
So here is an interesting tidbit from a recent incident in which I was supporting the customer on Dynamics 365 for Operations – Retail.
Few transactions were suddenly reported as “Missing” by the customer. The customer provided transaction details including CCTV grab along with Credit Card Slip. I started my investigation the server logs and found that the transaction id seemed be used across two transactions. This meant that the cart was not got getting cleared. In my customization I needed to access the cart information post the cart checkout and my cart clearing code was written in the PostEndTransactionTrigger.
We also logged a support ticket with MS and over time understood from MS that the MPOS is being exited by the cashier without closing the Change Due Dialog, which resulted in the PostEndTransactionTrigger not executing.
Long story short, if you are using this Trigger, make sure it contains non -critical code as it may not trigger if user exits MPOS without closing the above change due dialog.
This article is based on 7.1 Retail SDK but should be applicable to later releases too unless a fix for this has been released.
In this post, I would like to draw your attention to RetailCdxSeedData class.
The RetailCdxSeedData class is called when you trigger the following option in Dynamics 365 for Operations
Retail and commerce->Headquarters setup -> Retail scheduler ->Initialise retail scheduler
If you have added some custom tables that need to be synced between your HQ and Channel Database using CDX (Commerce Data eXchange), then you should customize the RetailCdxSeedData class to include the custom tables. If you do not not customize the RetailCdxSeedData class, you will need to do the CDX table mapping manually in all the environments and in every DB refresh and increasing the chances of missing out some fields if you have a lot of tables.
Please refer the following link from Microsoft on how you can customise this class with an extension.
If you decide to refactor or rename a Commerce Runtime (CRT) entity (lets say OldEntityName to NewEntityName) inheriting from CommerceEntity, one issue that I have faced is in Retail Server extension assembly the build fails with errors due to the RetailProxy classes relying on the definition of your old entity name.
Example of the error messages that you would see in this scenario are as follows-
Could not load type OldEntityName from assembly… and the command ‘bin\CommerceProxyGenerator.exe’ ..
The solution to this issue is a little tricky one. You need to compile the CRT data dlls keeping the OldEntityName in the References folder.
You need to then comment any reference to NewEntityName in the Retail Server Extension assembly. Then do a clean and a build of the solution.
If this succeeds with no errors, you can now go ahead to uncomment all references to NewEntityName in the Retail Server Extension assembly.
<Update>This article is based on 7.1 Retail SDK </Update>