Skip to Content
Author's profile photo Deepak Phopase

Unique identifications of SAP orders in Supplier Portal and consideration of In-transit ASN quantity while releasing orders from SAP

This document is relevant for Procurement Process spanning across all industries related to the unique identification of SAP orders sent by means of Scheduling Agreements in for of schedule lines and also covers the requirement of considering In-Transit ASN (Advance Shipping Notifications) quantity for SAP Releases.

A Scheduling Agreement is a long term outline agreement used for procurement purpose. The purchaser can place multiple orders to the supplier/vendor against a single scheduling agreement. These orders are generated in form of schedule lines with details of delivery schedule (Date & Time) and quantities.  All requirements in the Delivery Schedule are transmitted to the supplier systems via a JIT Release (Just In Time – Immediate Requirement) and a Forecast Release (Long term requirements).

In case of Scheduling Agreements with Release Documentation (LPA document type) we use standard message types LPJ1 & LPH1 for transmitting JIT & FRC releases respectively to the suppliers in form of EDI/Print data. These message types transmit all the data created in the form of releases at item level to the supplier.

Once supplier receives the respective orders and schedules, they send the Advance Shipping Notification to SAP system. These ASN’s are converted into Inbound Deliveries posted against respective scheduling agreements in SAP.

The Scheduling Agreement order quantities are fulfilled when deliveries are received in the system against them and posted with a Goods Receipt. The Deliveries remain in OPEN state in the system based on the planned delivery time maintained in the Material Master & the Scheduling Agreement after which goods are physically received in the plant.

Current Scenario:

One of the Auto OEM uses a Java based supplier portal to co-ordinate orders and receive ASNs. This portal displays both JIT and FRC orders to the suppliers. The supplier portal is majorly used for Firm Order visibility, ASN creation and Reporting purpose. The supplier portal makes use of statuses like OPEN, PARTIAL, SHIPPED to differentiate between un- processed, partially processed and completely processed orders respectively. The ASN created is linked to the corresponding order for identification. The supplier portal data is completely dependent on data sent from SAP.  Since there are multiple orders (date-wise schedules) created against one scheduling agreement, there is no means to establish a base line between data transferred from SAP and data visible in supplier portal. Thus, after every release the previously updated data is deleted to make way for the new release data from SAP so as to avoid duplication and redundancy. Thus, all the old data was replenished with new orders but the old data such as Order History, ASN links along with their statuses were completely deleted.

Any ASN created from the supplier portal would change the order status to Shipped/Partial and interface into SAP as EDI data to create Inbound Deliveries. However all inbound deliveries are considered as In-transit quantities until GR is posted. SAP Release creation program does not consider In-Transit Quantity ASN’s as firm receipts thus, if orders are transmitted from SAP in this scenario the order for which ASN was already created would again be sent into the supplier portal thus appearing as a new demand and leading to duplication.


The requirement from business was to identify a “unique identifier” field in SAP which relates to only a single delivery schedule line for a specific scheduling agreement. The same should be sent across to the supplier portal along with the other EDI data so that all transaction in supplier portal database will be mapped to this unique identifier thus maintaining consistency and tracking of order data and ASN transactions.

In order to ensure that orders for which ASN is already created and fulfilled, it was required to not to send the orders again before the GR posted.  Since the release creation program RM06EFLB does not consider In-Transit quantities, a user exit was to be used for program RM06ENDR_ALV that is used for transmitting releases to supplier portal so that In-Transit quantities are not at all sent from SAP and thus avoid duplication.

Master Data:

The above changes were done only for JIT releases thus the following master data set up was required:

  • JIT indicator active in “Purchasing View of the Material Master” and “Additional Data of Scheduling Agreement”



  • Output Type LPJ1 set up with condition records for scheduling agreement data.


Detailed Solution Design and Process Flow:

A.      Unique Identifier Solution –

The unique identifier value that was considered to uniquely identify any schedule line in SAP  was designed as a combination of following  three fields:

  • Scheduling Agreement No.
  • Line Item No.
  • Schedule Line No.

Concatenation of the values for the above fields in the above mentioned sequence helped to generate the unique identifier. The unique identifier was sent across to supplier portal as 3 separate fields which were concatenated to uniquely identify and trace scheduling agreement data. There was no need to delete historic data and only Insert/Update of orders was performed in supplier portal as schedule lines could be uniquely identified in case of an update and insert in case the unique identifier was not present in supplier portal.

Following scenarios were handled to maintain data integrity in supplier portal:

  • Aggregation – If quantities for two or more schedule lines were aggregated in the scheduling agreement releases then the highest schedule line no. amongst the aggregated schedule lines was sent to the supplier portal.
  • Backlog Aggregation – If backlog quantities were aggregated to the current schedule line then the schedule lines no for the current schedule line was sent to the supplier portal.
  • Order Cancellation – If any schedule line no. was marked cancelled in the delivery schedule (Quantity updates as “0”) then Zero quantity was sent to supplier portal for the unique identifier combination to mark the order as cancelled.
  • Delivery Date/Quantity Change – If the delivery date or quantity for a schedule line in the delivery schedule was changed the supplier portal was updated with the same date and quantity referencing the unique identifier in the supplier portal.

NOTE: In case of aggregated orders logic was placed outside SAP in supplier portal to update the schedule line with correct statuses where schedule line orders were aggregated.

B.      In-Transit Quantity Solution –

The summation of all the in-transit quantities for the concerned SA were subtracted from the Schedule Agreement release and the balance order quantities were sent across to the supplier portal. The In-Transit quantities are identified based on open Inbound Deliveries which are yet to be GR posted from EKES table in SAP. A user exit for message output program RM06ENDR_ALV was used to identify such in- transit quantities and send updated quantities to supplier portal.

Following scenarios were handled to send to correct and updated quantities to the supplier portal:


Existing Process

Proposed Solution

No ASN for the Schedule Agreement

All schedule lines sent to supplier portal

All schedule lines will be resend with unique identifier

Single or multiple ASN with complete quantity for a delivery Schedule line coming into SAP

Schedule Line Sent to Supplier Portal. Single or multiple ASN for full quantity coming into SAP to create Inbound Delivery. After subsequent release, Schedule line is sent to supplier portal irrespective of the In-Transit quantity

Message Output program checks for one or more open Inbound Deliveries against the schedule agreement. If yes then the sum of In-transit quantities will be subtracted from the oldest Schedule Line quantity from the scheduling agreement release. If result is “0” then schedule line will not be sent. No change to other schedule lines

Single or multiple ASN with partial quantity for the delivery schedule line  coming into SAP

Schedule Line Sent to Supplier Portal. Single or multiple ASN’s for partial quantity coming into SAP to create Inbound Delivery. After  subsequent release Schedule line for complete quantity again sent to supplier portal

Message Output program checks for one or more Inbound Deliveries against the schedule agreement. If yes then the sum of the In-transit quantities will be subtracted from the oldest Schedule Line quantity from the scheduling agreement release. If result is positive “X” then oldest schedule line with quantity “X” to be sent to supplier portal. No change to other schedule lines

Single or multiple ASN with complete quantity for oldest schedule line & partial quantity for consecutive schedule lines in the delivery schedule coming into SAP

Schedule Line A & B sent to supplier portal. ASN with complete quantity for schedule line A & partial quantity for schedule line B coming into SAP to create Inbound Deliveries. After Release both schedule lines A & B are sent to supplier portal irrespective of the In-transit quantity

Message Output program checks one or more Inbound Deliveries against the schedule. If yes & more than 1 then sum of all the In-Transit quantities is subtracted from the oldest schedule line “A” quantity. If result is negative “X” then the schedule line “A” is considered as consumed and is not sent. The value “X” is to be subtracted from next schedule line “B” quantity. If result is a new value positive “Y” for schedule line “B” then it will be sent to supplier portal with value “Y”.

Benefits derived out of supplier portal uniqueness and In-transit quantity solution:

  • All orders retain visibility in terms of order data and status in supplier portal after successive scheduling agreement release & updates.
  • Uniformity as all the changes to order data(Quantity/Delivery Date) are updated correctly to the equivalent order is supplier portal
  • The unique identifier serves as a useful tool for supplier portal administrator to match the SAP and Portal data for every order and any mismatches can be easily identified.
  • All the In-transit quantities considered for all SAP releases thus avoiding duplication and redundancy of data
  • Supplier Performance can be gauged accurately as ASN to order data synchronized with SAP.
  • Transparency with respect to orders transmitted and ASN’s posted for both purchasers and suppliers.
  • Business process efficiency leading to eliminating process related errors and in turn costly manual work-around.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Arvind Pereira
      Arvind Pereira

      Hi Deepak Phopase,

      Well written.


      Arvind Pereira

      Author's profile photo Saurabh Srivastava
      Saurabh Srivastava

      Very good explanation of the scenario. Thanks for sharing this. 🙂

      Author's profile photo Maruti Shingade
      Maruti Shingade

      nice documentation ...thanks for sharing

      Author's profile photo Former Member
      Former Member

      very useful information & nice doc....thanks.