• Defining Date type on Customer in addition to AR parameter

    When retrieving trade agreements (+ discounts and charges) for sales orders, it would be beneficial if the Date type used could be defined not only in the AR parameters, but also on Customer level. 

    That way, customers with contractual price calculation exceptions can be addressed by configuring specific date types on the customer master. If no date type is configured on the customer, then the AR parameter is applied.  


    This idea comes from a discussion regarding the new Pricing management functionality for SCM. 

  • Log file to Recalculate prices batch job (SCM Pricing management - Public preview feature)

    In the new Pricing management, it is possible to Recalculate prices (etc.) on open sales orders, but job does not appear to have any log file to review the updates that have been performed.  


    The Recalculate prices batch job should be updated with a log file containing

    - What has been updated (i.e., which lines on which sales order have been updated)

    - Any errors from update (e.g., no active prices found)


    That way it is possible for users to follow-up on the updated sales orders to verify if update is as expected or to understand why an update has been performed. 

  • Add "From date" and "To date" on Auto charges (for Purchase orders)

    Add "From date" and "To date" fields to auto charges on charges applicable to Purchase orders.


    With the new Pricing management feature, From date and To date will be available on Auto charges applied to sales orders. These two fields would greatly benefit users working with Purchase orders, in order to define a date interval in which the charge(s) should be applied.

  • Make price attribute enabled sales trade agreements compatible with price unit !=1

    When using sales trade agreements (without enabling pricing management features) it is possible to define a price unit !=1, to manage decimals beyond two digits. 

    E.g., if a price unit is 1000 and the price is 1234,56, unit prices on the sales order line will be calculated as 1,23456 for a single unit (even if it will only be shown with rounded values and two decimals). 


    After enabling Pricing management features, this option to control the decimals no longer works. It is still possible to define the price unit !=1, but this is not recognized in the price calculation nor the unit price applied on the sales order line. 


    Making Pricing management (and Unified pricing) compatible with price unit !=1 is needed for low value items. Also, it is a functionality which is highly used in SCM pricing.

    As the price engine already calculates with more than 2 decimals (for discounts etc.), it should be an option to also consider more than 2 decimals for sales trade agreements as well.


    If this is not updated, it could be a significant regression in pricing functionality and may deter customers from selecting the new pricing management/unified pricing features.