Integration Point of MM-FI-SD in SAP ERP

As we know about the module MM, FI and SD in SAP ERP.

MM stands for Material Management, FI standard for Financial Accounting, SD stands for Sales and Distribution.

These two modules FI and SD is very much integrated with MM modules. As we are in MM module, we should know about the integration point.

Here in my blog you can get the knowledge for integration between MM-FI, MM-SD and SD-FI.

We know MM modules means procure to pay process, FI module means financial statement and payment process, SD module means sale to customer process.

Most of the manufacturing business logic is stands for 3 things BUY-MAKE-SALE

It means an organization buy a raw material/product from a vendor, then he makes from this raw material/product to finished material/product, then he sale the finished material/product to a customer.

In that 3 part the 3 module are integrate each other.

⟾ When the organization buy a raw material/product then its coming into warehouse stock, which is goes to MM modules. And because of the organization has buy something from a vendor, he has to pay for this to the vendor, which id goes to FI modules.

⟾ When the organization make the raw material to finished material, at that time the organization needs a subcontractor vendor, who will make the subcontracting process. Then process from raw material to finished material, it goes to MM module. And the organization has to pay the subcontracting vendor, this will goes to FI module.

⟾ When the organization sale the finished material to customer, They have to proceed the sales process (Like as sales order, delivery, billing etc), its goes to SD modules. At the time finish goods stock is decreased from warehouse, which is goes to MM module. We sale the finished material to customer, so customer will pay for this finish material, the payment terms goes to FI modules.

MM-FI Integration

In this part, we learn about MM-FI integration points. When we do a movement for a material, if the movement is account effect-able, then it will post a account entry in FI.

Lets discuss about how the accounting entry are posted and how you can do the configuration.

We have a material master data in our procurement process.

In material master, we stored all information for a certain material. Like as material type, material group, purchasing information, sale and distribution information etc etc.

The valuation class (in accounting 1 view) is most important for automatic account posting purpose.

We can see the valuation class for individual material from t-code MM03.

Valuation class is used to group together several material with their same attributes, so that we can carry the same account determination for various material.

Every material has a valuation class, many materials can contain same valuation class.

As we know the valuation class is link with material type via account category reference.

You can see the blog to understand about material type, account category reference and valuation class.

Account Category Reference (ACR) – Grandfather of Automatic Account Determination Process

The valuation class will be for Raw material, Semi-finished, finished goods. We can differentiate valuation class as per our business requirement.

Valuation class and Movement type is used for the G/L determination.

Movement type is used for all types of material movement. Suppose if you receive a material from a vendor, a movement is happens for the movement.

If we transfer a material from one location to another, a movement type is happens for the movement.

It means, whenever we do a off-setting entry, a movement type will be created for that.

For various movement type SAP defines a G/L account for the material movement.

Lets discuss about an account entry for a movement type.

When we do a goods receipt, the movement type happens is 101. And SAP designed as per business process the account entry will

Inventory A/C debit

GR/IR A/C credit.

We know about these account, Inventory a/c for material master and GR/IR account is a provision account for vendor.

The all account entry is done via automatic account posting.

SPRO-IMG-MM-Valuation and Account Assignment-Account Determination-Account Determination Without Wizard-Configure Automatic Postings (t-code OMWB)

Direct t-code OBYC.

You can find the all details of automatic account determination with this document Automatic Account Determination.

For different different movement type, the account entry is done via different transaction event key.

For example

If any movement type hits the inventory entry then it will hit the BSX transaction event key..

If any movement type hits the off-settings entry then its hit the GBB transaction event key.

If any movement type hits the provision entry then its hit the WRX transaction event key.

If you noticed the transaction key GBB, then you can find the a lots of account modifier are used for various movement type.

We can’t remember the all account modifier at all, for this purpose SAP introduce Simulation Mode. Using simulation mode, you can easily identify the account modifier which is used for GBB.

Path = SPRO-IMG-Materials Management-Valuation and Account Assignment-Account Determination-Account Determination Without Wizard-Configure Automatic Postings

T-code OMWB

Set up the simulation criteria as per your requirement.

Set up the Application Area, Input Mode, Account Check. Then press simulation

You can see the all G/L account uses with all transaction event key and account modifier for this particular movement type.

In this way when we post a movement type in MM module, its also update in FI module.

In short, we can say the main point of MM-FI integration is OBYC

From MM side its Valuation class and for FI side its G/L account. When we do a movement type, the movement type finds the valuation class for the material, and post the amount to this G/L account which is assigned to this particular valuation class.

SD-FI Integration

In this part, we learn about SD and FI integration point.

Whenever we sale a finish material to customer, then the customer have to pay for that. We send a bill to customer.

In that position all billing document which is happens to sales and distribution module will be posted into FI module.

The account entry of respect to the billing always have two sides

One side is Customer account and other side will be revenue account.

For example:

Customer A/c Debit

Revenue A/c Credit.

AS per SD module, the customer account will be picked from customer master data, which is maintained from SD module.

We just need to configure the revenue account and if there any discount and surcharges account.

We have to do that via access sequence, access sequence is just a SAP terminology to determine the G/L accounts.

SAP provides 5 ways to determine G/L account in SD modules.

These are

1. Cust.Grp/MaterialGrp/AcctKey

2. Cust.Grp/Account Key

3. Material Grp/Acct Key

4. General

5. Acct Key

The assigned G/L accounts are used to post the discount and revenue and any kind of surcharges.

To configure this

Go to Path = SPRO-IMG-Sales and Distribution-Basic Functions-Account Assignment/Costing-Revenue Account Determination-Assign G/L Accounts

T-code = VKOA

You can see the below screen and you can also see the default table and description for above 5 ways.

First system checks the first table entry Cust.Grp/MaterialGrp/AcctKey. If any G/L maintained here then system will go to the transaction and the particular billing document, then system search the combination of customer group and material group. If system will find any G/L, then system will go through the G/L, if system doesn’t find the G/L, then it will search the next table.

Customer group is maintained in Customer master Data, Material Group is maintained in Material Master Data, Account key is maintained for condition type in pricing procedure.

Lets maintain One G/L account for material group and account key combination.

Double click on the Material Grp/Acct Key

I have maintained the G/L for this combination. here AAG is the material grp.

Whenever system search the table and find the combination for transaction, then system will debit customer account and credit to this account (180033)

The account key determine that it is a revenue or discount or surcharges.

Press F4 on the Account Key field, you can see the all account keys.

The account keys are also maintained in calculation schema in Pricing procedure.

Path = SPRO-IMG-Sales and Distribution-Basic Functions-Pricing-Pricing Control-Define And Assign Pricing Procedures-Maintain pricing procedures

In this way SD and FI are integrated each other.

Continue reading

SAP UI5 Automation

I am writing this article to explain a unique-out-of-the-box  concept of automating UI5 applications which addresses most of the  challenges faced in automating  UI5 applications

Some of the most common challenges in automating UI5 applications are:

◉ Ids not stable

In UI5 applications IDs are unique in a given page, but there is no guarantee that these IDs will remain stable across multiple iterations of the business flow, which makes it unfeasible to use it as a identifying locator for entire business flow.

◉ No standard way of identifying UI5 element

There are multiple ways (locators) to identify a UI5 element , some of them are   XPath,css,HTML tags,Ids (not stable over iterations as discussed above) etc. Stability of the automation scripts largely depends on how well these locators are used and how unique they are in identifying the UI5 element.

◉ Sync issues

Script failure due to syncing of UI5 elements is one of the biggest concern which is causing a lot of discomfort for the automation developers

◉ Ease of use

All of the points mentioned above makes it really difficult for automation developers to write stable scripts easily

◉ Customization and Maintenance

Again for the points mentioned above a lot of effort is required in maintaining the script stability whenever the properties of the locators change over       period of time

◉ Solution

This UI5 Automation framework is a JavaScript based solution with two components

Browser extension – Displays the DoM structure of the UI5 page in UI5-elements-format, and a context menu  to capture the properties/events of selected UI5 element as shown in the figure below

Extension of Protractor – A JavaScript based tool, handles sync between UI5 elements exceptionally well. The data captured through browser extension context menu is used to create the business flow and run via this tool against any browser (perhaps mobile too…not yet tested)

The uniqueness of this framework is that the automation is based on the UI5 element structure and not normal HTML DoM, which makes it very stable in identification and maintainable.

If this concept interests you, let me know if you want to understand the framework in depth and I can share more details. I will be modifying this blog to make it more elaborate and more clearer in coming days.

Continue reading

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.

Continue reading