Product Information
Issues related to Sales Scheduling Agreement – API
In this blog post you will get to know about Issues related to Sales Scheduling Agreement – API
Usually in sales process scheduling agreement is used to maintain schedule line details in scheduling agreement, the same can be update via API also, with the new release 2005 some checks are updated, it is observed that below are the common issues faced by many customers
Ø New validation in 2005 which verifies that the supplier code updated in ‘Assign sold to party’, updated in the BP field ‘Account at customer’, creates issue.
Ø How to update cumulative delivered/issued quantity though API
Blog Applicability
SAP S/4HANA Cloud Release |
2005 |
Target Audience
Business Users, Key Users, Consultants
Target Industry
Any
Business benefit
· Faster resolution of validation with upgrade of Sales Scheduling Agreement – API check
· How to update cumulative delivered/issued quantity
What is use of Sales Scheduling Agreement API ?
In The service contains header, item, delivery schedule, and schedule line entities, as well as header and item sub-entities for partners and pricing elements. Once the sales scheduling agreement has been created, the sales scheduling agreement number is sent in the response with the data included in the sales scheduling agreement. If there are any issues when creating, retrieving, updating, or deleting the sales scheduling agreement, the system displays error messages in the response.
Issue details
Ø New validation in 2005 which verifies that the supplier code updated in ‘Assign sold to party’, updated in the BP field ‘Account at customer’, creates issue.
Usually in an automotive supplier that works with sales scheduling agreements updated with the following API: Delivery Schedule of Sales Scheduling Agreement – Receive, Update (B2B)
Communication arrangement: ZSAP_COM_0444
Configured all steps like
– Account at customer
– Partner Description
– Assign Sold-to Parties
– Delivery Scheduling Processing
– Customer Material
Customers use different supplier codes in the communication in order to identify the source i.e. delivering plant (if more material is coming from more than 1 plant example xxxx and yyyy plant ).
Customers define their own supplier codes as per requirement or to trace source etc. and this cannot be controlled on the OEM supplier side
Example: customer uses two different supplier codes in its XML files in order to identify the delivering plant.
Maintain the following sold to party assignments
However, only one account at customer can be maintained at BP master data level.
Validation that the system is currently doing is new and it’s causing error , not able to determine the corresponding sold to party, because the supplier code that the customer identifies in the XML file(example xxxx) is different from the supplier that is maintained in the account at customer in BP (example yyyy)master data.
But if the codes are matching it will update
Solution
Since this requirement is in sync with validation of Idoc , but since in automotive or many other industry where supplier codes are different and cant to be controlled / varies – example to trace the original plant etc. They cannot control what supplier code customers are using; however, this is not always the same case.
SAP recover the logic to the previous version. The validation about account on customer should be removed. Provided a hotfix to fix this issue, by which check is removed.
Issue details
Ø How to update cumulative delivered/issued quantity though API
Usually at the time of initial data transfer, Customer is using APIs SAP_COM_0360 and SAP_COM_0444 to migrate data of sales scheduling agreements.
The question is: Is there a way to update cumulative issued quantity and cumulative delivered quantity in an initial data transfer?
In case of on-premise systems with two fields, designed specifically for scheduling agreements, which were added to communication structures VBAPKOM and BVBAPKOM to allow the transfer of an external cumulative quantity and date.
Solution
Till the cloud version 2002 , scheduling agreements cannot be transferred to S4HC system by migration cockpit object – it can only be newly created on S4HC.
As for the cumulative quantity, it’s not opened as an available field with API API_SALES_SCHEDULING_AGREEMENT & SCHEDGAGRMTDLIVSCHEDULE_IN.
Since there is no field for cumulative delivered/issued quantity within this API, the scheduling agreement will be generated without those fields or with initial.
After the scheduling agreement is created, you can update the cumulative delivered/issued quantity manually by creating a correction delivery through the change mode i.e.
– Create SA through API or VA31.
– Create a correction delivery manually or VA32.