Lest start with the 2672554 2672554 UI Harmonization in the Preference Processing Area Menu
All of us have still in mind the 3 main areas of preference process
- LTVD Request
- LTVD Issue
- Preference determination
Most consultants and users are used to collapse the LTVD request part once the majority of LTVD’s have already been maintained. Afterwards there comes the time of the year, where all the preference determinations are executed, in order for us to be able to issue 1st LTVD’s for the customers. So you do not need the LTVD request, right?
In the below picture you can still observe the “classic” Preference Processing screen.
The new Risk Management UI is adjusted in a way that the “main” screen is focused on the LTVD’s – both inbound and outbound, vendors and customers. The Preference Calculation itself is pinned to the top with its Master Data neighbor.
Of course, each customer has its own rhythm for the preference process, but there is a need and desire for the “classic” screen. No problem – the “classic” screen can be activated with the below parameter in the user details and we are back in the old days.
There is another note 2571517 – Incompleteness check for vendor declaration: Functional enhancements
We all know it, we have all been there – busy days, tons of customer request for declarations, it might happen that a commodity code in the LTVD goes missing here and there, or a customer cannot find the reference for their product number as your product XYZ123456789 does not have any reference in the customer product portfolio.
Nice new features have been introduced which prevent LTVDs with missing details to be issued. There is a dedicated customizing under Vendor Declarations, where the most important LTVD information can be verified before the Customer LTVD is issued. You can choose from the following fields and it is up to you, how you define and design the incompleteness check
- Product description:
- Customer product number
- Customer product description:
- Preferential country of origin
- Commodity code
- Producer:
- Qualified origin statement:
There are so many incompleteness checks already – foreign trade data in ECC, customs message in declarations, so why should the LTVD incompleteness check be an exception?
The icing on the top. 2675796 – Optimized display of preference rules in log
In my own humble opinion, this is quite a massive and progressive change which will impact mostly the preference determination users. The log is now more user friendly, it is easier to identify which rule was applied and you can jump directly to the rule set.
From here, with a simple double click, you can enter the rule itself.
It was sometimes hard to explain the preferential results for complex cases, but this adjustment will help the users to understand it.
During our 1st tests my colleagues have already noticed something which could be improved. If you look at the screenshots once again and more carefully, I am sure you will find it for yourself. If you like to share you experience, please contact us.
Pridaj komentár