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

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.