Flow of SAP MM and SUS Portal

Introduction

The below article is a short description on Flow of Data between

SAP Material Management (MM) and SAP Supplier Self Service (SUS) and some customizable features of SAP SUS.

In the Plan-Driven Procurement with Supplier Integration scenario the SAP SUS is installed and configured with SAP MM/SRM. Technically, in a classic scenario SAP SUS maybe connected with one or more MM and/or SRM back-end systems.

PO is sent to SAP SUS system, in which supplier can perform the follow-on procurement process, i.e. PO response, ASN, GR response and invoice response.

SAP Supplier Self-Services provides the following processes and functions:

◉ Vendor Maintenance in SAP Supplier Self-Services
◉ User Management
◉ Processing Purchase Orders
◉ Processing Confirmations
◉ Processing Shipping Notifications
◉ Processing Invoices
◉ Processing ERS Invoices
◉ Bid Invitations
◉ Analyses
◉ Integration of Internet Pricing and Configurator (IPC)

Two scenarios for SAP SUS:  SRM-XI-SUS and MM-XI-SUS.

In SRM-XI-SUS the PO is created in an SRM system locally and sent to SAP SUS. All communication will take place between these two systems via XML messages on both sides with a PI/XI system in between as a mandatory system.

In the MM-XI-SUS scenario the PO will be created in ECC and transferred to SAP SUS. Depending on ECC release there are two different possibilities for this, either the ECC system sends IDOCs or sends XML messages directly. IDOCs will be mapped to XML by PI/XI in all cases, as the SAP SUS system only receives and sends XML messages.

Below is the detailed description on SAP MM ECC sending PO as an IDOC to SUS.

SAP MM ECC sending PO as an IDOC to SUS

SRMSUS BSP Application

SRM SUS Portal or the Vendor Portal is a BSP Application.

The standard BSP application name is SRMSUS, which contains all the standard views provided by SAP.

This BSP Application can be viewed in the Object Navigator (SE80) of the SRM SUS system.

For implementing a customized SRM SUS Portal, this BSP Application is copied and enhanced.

The views are modified as per requirements in the Model View Controller. 

The view changes in ABAP code are done in these controllers.

To understand the flow of data from SAP MM to SAP SUS we shall follow the below mentioned steps:

Sending PO to SAP SUS

◉ Configuring Message Output type

◉ Create a custom output type for PO to be transferred to SRM SUS.

Steps to configure output control messages:

1. Condition Table

SPRO/ Material Management/Purchasing/Message/ Output Control/Condition Tables/Define Condition Table for Purchase Order

Select: Purchasing Doc. Type, Purchasing Organization, Vendor

2. Access Sequences

SPRO/ Material Management/Purchasing/ Message/Output Control/Access Sequences/Define Condition Table for Purchase Order

3. Message Type

SPRO /Material Management/ Purchasing/ Message/ Output Control/Message Types/Define Message Type for Purchase Order {NEU}

4. Message Determination Schemas

     4.1. Message Determination Schemas

SPRO/ Material Management/Purchasing/ Message/ Output Control/Message Schema/Define Message Schema for Purchase Order/ Maintain Message Determination Schema

     4.2. Assign Schema to Purchase Order

SPRO/ Material Management/Purchasing/Message/Output Control/Message ne Message Schema for Purchase Order/Assign Schema to Purchase Order

5. Partner Roles per Message Type

SPRO/Material Management/Purchasing/ Message /Output Control/Partner Roles per Message Type/Define Partner Role for Purchase Order

6. Condition Record

SAP Menu/Logistics/Material Management/Purchasing/Master data/Messages/Purchase Order/ MN04 (Create using medium EID Electronic Data Interchange ‘6’)

Significance of Message Output Type

In the created EDI (Electronic Data Interchange) output type of the purchase order, the processing routine contains the program RSNASTED which is responsible for sending the document to the Partner as an IDOC.

The Program RSNASTED is the processing program for each output type, which depending on the definitions for the output mode maintained in the EDI partner profile, will generate and write only one Intermediate Document to a file.

RSNASTED processes entries in the NAST table, which stores an entry for each output record created from application document.

For the created PO, the IDOC created can be checked in IDOC List (WE02).

In case of issues in document transfer, this is the first place to be checked. Green status indicates successful transfer of data from the ECC system.

Creating PO in MM

◉ Purchase Order is created in SAP MM system and released.

◉ This is for the professional buying scenario. PO can also be created automatically with reference to shopping carts in the system.

◉ Assign the created Message Output type with the target system as Partner.

◉ It is crucial that the created EDI output message is assigned as it is responsible for transferring the PO details to the SUS system.

◉ Once the PO has been released, this output message type triggers the IDoc which takes the PO details to the SUS system.

SUS Portal

The vendor logs onto the SUS Portal using the User Id provided to them, to check the PO, GR, Invoice notifications, to create ASN, Invoice uploading and to see Payment details.

◉ New PO notification in Supplier portal

As soon as the PO is created against a Vendor in the ECC system and assigned the EID Output message type, the PO details should be available to the Vendor on his SUS Portal.

The PO details are sent as an outbound IDoc from the ECC system onto the XI/PI system.

In the XI/PI system, this IDoc is mapped into an xml file and sent to the SUS system. Thus, the PO details are visible to the Vendor in his SUS portal id.

◉ List of POs in SUS Portal

The Vendor will be able to see all the Purchase Orders made against him by the organization in this menu.

Here he can individually go and accept and view details of each of the purchase orders.

Current PO Status displays if it is a new PO or an already accepted/confirmed PO.

◉ Accepting a PO in Supplier Portal

New POs are to be accepted by the Vendor, confirming that the terms of the PO document are acceptable.

As seen in the screen shot below the Vendor is able to see the PO number, date, company code, Company name and Terms of Payment in the General information layer.

The item code, details, quantity, rate, gross value and delivery date are visible in the item Overview tab.

The fields in these tabs are customizable and the layout is modified as per business requirement.

After accepting the PO the Vendor can then view and update the progress with respect to this PO from the menu screen.

The acceptance of PO by the Vendor can be sent as a PO response to the ECC system via XI/PI.

This is reflected in the PO Confirmations tab in Item detail in ECC.

Advanced Shipping Notice in Supplier Portal

◉ Creating an ASN in Supplier Portal

Advanced Shipping Notification (ASN) is a notification that is sent by the vendor to the organization when the goods are dispatched.

It generally includes information about the means of transport of the goods and document reference against which it is created.

Here is an ASN screen in the SUS portal.

ASN is sent from the SUS to ECC system via the XI/PI system.

The ASN no. should be displayed in PO conformation control as displayed below.

GR can be done in the system with reference to an ASN.

ASN should also be visible in transaction VL33N.

◉ Document Flow in Supplier Portal.

Sending GR to SAP SUS

◉ Goods Receipt is created against the PO in SAP MM

Once the goods are physically received at the storage location, Goods Reciept is done. The details of the GR are required for the vendor to get a confirmation of delivery.

◉ This Goods Receipt is reflected in SRM SUS Portal

Similar to PO, the GR details are visible

Program that sends GR to SAP SUS

RPODDELVRY is the program that sends the GR document to SRM SUS as an IDOC.

This report allows a synchronization of goods movements for PO and scheduling agreements. It selects all GRs corresponding to POs for vendors in SAP SRM SUS according to the selected vendor classes, including associated cancelations and return deliveries that have not been synchronized with SRM SUS.

The selected goods movements are transferred to the respective target system in SRM SUS using STPPOD.Delvry03-IDocs. 

If you start the report as a background job, information can be written to a spool while the report is running. 

You can only use this report if the summarization function of the PO history records is not active. 

Note that this report is not suitable for the processing of mass movements. The report is suitable for periodic background processing. The system ensures that only one instance of the report is active in the background. The report is not designed to be carried out via batch input. 

Synchronization is only possible when table EKBE (procurement document history) is NOT summarized. Batch input synchronization is not possible.

Customizations

Apart from these standard functionalities, Invoice uploading and Payment details can also be added.

Custom BSP pages need to be created for these in the invoice module, which is done in the controller view mentioned earlier.

Supplier can upload scanned copies of the physical invoice in the Invoice screen.

The Payment details of the payment made can be viewed in the Payment details screen.

Uploading Invoice to SAP SUS

The following is a customization, to illustrate the additional uses of the SUS system.

The Vendor can upload the invoice as a scanned copy on the SUS portal, against the PO raised to him. The Invoice amount and date is also entered and submitted as shown below.

Vendor also has the option to upload supporting documents.

Preview of the Invoice uploaded. The Invoice details have to be entered manually at the SAP ECC system in transaction MIRO. The uploaded Invoice is matched against MIGO for invoice verification.

View Payment Details from ECC

The payment details come to SUS sytem from ECC via RFC.

The vendor is able to view the payments made against an invoice raised by him.

The Vendor can view Payments made to him in the SUS portal as shown below.

There can be multiple payments made to the Vendor against the same invoice or have a single payment. This is based on the payment terms maintained against the vendor.