web
You’re offline. This is a read only version of the page.
close
  • Throw warning or "Autoreservation" form in InterCompany sales company when no stock is available for reservation in stock company

    Given there are two companies where one is a sales only company and the other one holds all the items in stock. This implies that all sales orders will result in the creation of the intercompany chain and intercompany sales orders. If the reservation is manual for the sales company and automatic in the stock company and the sales quantity that is synced to the intercompany sales order exceeds the quantity that can be reserved in the stock company, there is no warning shown or "Autoreservation" form triggered in the sales order within the sales company.


    For regular sales orders inside the stock company there is such a function available to tells the user to either change the product/quantity or acknowledge the lack of items in stock. This should be available within the sales company as well, since the order management and completion is always done within the original sales order.


    Autoreservation form: https://imgur.com/a/QEAQsH3


  • New DirPartyLocationPostalAddressV2Entity record duplicate check should include the BuildingComplement

    The data entity DirPartyLocationPostalAddressV2Entity can be used to import a location for a party. Upon a POST request through the OData endpoint there is a function that will eventually call the static method "resolveRemittanceAddressLocationId" of the "LogisticsPostalAddressBaseEntity" class. It is used to see if the same address already exists for that party and if it does, it will proceed with an update on that record, rather than inserting a duplicate. This method, however, does not keep into account the BuildingComplement value. This results in an issue where an address is found, where all other fields might be equal to the new address (to be imported), but the BuildingComplement is different, and update that record rather than inserting a new address. Basically, a different address is considered a duplicate and then updated instead of imported, even though the request is a POST request without a LocationId, therefore the request specifically would like to INSERT a new record.


    This can be fixed, if one line is added to the a.m. method. Extending the method is not possible as it is called inside the DirPartyLocationPostalAddressV2Entity and the changes would be overwritten. Also, duplicating the whole DirPartyLocationPostalAddressV2Entity and editing some methods there does not work because the model, which has been used to create that entity, is flagged as internal and does not allow any references in duplicated entities. Therefore, Microsoft has to fix this issue.


  • Price Change Tracking should track all Trade Agreement party types (All, Group, Customer)

    According to the official documentation: https://learn.microsoft.com/en-us/dynamics365/commerce/price-change-tracking#how-price-change-tracking-works


    Retail Price Change Tracking should already support tracking the changes made to trade agreements in general. Unfortunately, MS pleads to "design limitation" or "reduced performance" and only tracks trade agreements that are posted for "ALL" (party code relation). As in many cases, prices are specific to a customer or maybe even just a group (e.g. B2C prices vs. B2B prices) and therefore, the standard price tracking feature becomes useless and there is no other way in a standard environment to track price changes for those use cases without interfering in MS code with a customization.


    This idea is not about tracking actual price changes on the PriceDiscTable but only require MS to run existing methods to update the UpdatedDateTime field in the RetailPriceChangeTracking table for all items in the currently posted trade agreement. I'd understand if they fear a performance risk, if there was a line with party code type = Group and item code type = Group as well (or even ALL). But a party code type = group and a specific item number should be tracked in my opinion.


    There's already other cases, where multiple products will receive an update on the table, like when publishing a discount for a number of products or even a product hierarchy node which can hold plenty of products itself. Therefore, I don't see any issue with implementing the price change tracking for party code type = Group and party code type = Table.


    I'd appreciate your vote on this idea.