GTIN - GLOBAL TRADE ITEM NUMBER

Introduction :

Global Trade Item Number (GTIN) is a 14 digit number which is used as an identifier for trade items developed by GS1 .  GTIN accommodates various EAN/UCC numbering structures and is used to uniquely identify a product worldwide. The uniqueness and universality of the identifier is useful in establishing which product in one database corresponds to which product in another database, especially across organizational boundaries.

EAN/UCC product identification numbers allow a unique identifying GTIN number to be derived in the system. All EAN/UCC numbers are considered as 14-digit numbers. They are right-aligned and have leading zeroes where necessary. The uniqueness and universality of the identifier is useful in establishing which product in one database corresponds to which product in another database, especially across organizational boundaries.         

GS1 is an international non-profit association dedicated to the development and implementation of global specifications to management of supply and demand chains across multiple

GTIN number usage and significance in SAP:

GTIN Mapping Function:

GTIN Mapping functionality enables the programmed replacement of a Global Trade Item Number (GTIN) by a material number.

For instance: During festive season the consumer product may have a promotional packaging. In such a case, the system can automatically replace the material number of the specific consumer product with the relevant GTIN.

GTIN Mapping in SAP:

T code EAN1 is used for GTIN Mapping in SAP.

GTIN Mapping -  SPRO customization path:

Condition technique is used for GTIN Mapping like any other determination procedures in SAP, viz., pricing, text determination.

Selecting the fields and stating their combinations

Specifying the sequence of the numerous key combinations

Generic condition records can be maintained by using free selection fields

If an access sequence consists of various key combinations (using condition tables) or if different condition types are used in the GTIN determination procedure. The GTIN mapping standstills the moment when of the accesses is positive or successful.

The system practices the usage of condition record with highest priority if numerous condition records are found for the same access sequence.

Pre-requisites :

All the above required condition technique elements viz.

Condition tables,

Access sequences and

Condition types should be customized in SPRO

Functionality:

In scenarios of inbound sales order process SAP system executes this function and checks whether GTIN mapping is active. If so, then the system determines the material number that counterparts the specified GTIN.

GTIN Mapping Example:

The below portrayed example defines the condition technique elements, and then provides the possible mapping for various settings.

Condition Table: comprises the key fields GTIN, GTIN Variant Type, Sales Organization, Distribution Channel, Division, Destination Country and Customer.

Access sequence : Access Sequence G001 accesses table 20

Customer is setup with a higher priority.

GTIN Variant Types:

P001 - Promotion has the sequence G001

S001 - Standard has the sequence G002

GTIN condition records can be created as listed below :

The empty key fields for free selection fields indicate that a record is valid for any value.

The system uses the above condition technique settings and processes the following events and determines their results accordingly:

Event 1: Customer US001 places an order on 25/05/2012.

Outcome : The system determines the standard material  STD_MAT

Event 2: Customer US001 places an order on 15/05/2012.

Outcome: The system determines the promotional material PRM_MAT. This is because the GTIN Variant Type P001 has a higher priority and is therefore considered before S001 variant type.

Event 3: Customer US002 places an order on 15/05/2012.

Outcome: The system determines the standard material STD_MAT. This is because, albeit the matching record exists for theGTIN Variant Type P001, the Customer field has identical data and a greater relevance as compared to the GTIN Variant Type S001.

Event 4: Customer US002 places an order on 15/10/2012 in Sales Organization CC01.

Outcome: The system determines the standard material STD_MAT, although a matching record exists for Sales Organization CC01. This is because the Customer field has a higher priority as well as matching data.

For below Materials GTIN numbers are created and assigned in the Material Master:

Vital GTIN T codes in SAP:

EAN1 - Create GTIN Mapping SD - Conditions

EAN3 - Display GTIN Mapping SD - Conditions

EAN2 - Change GTIN Mapping SD - Conditions

EANVENDOR - Maintain Vendor EANs Logistics - Material Master

SPRO - Customizing - Edit Project Basis - Customizing Project Management (IMG)

SM30 - Call View Maintenance Basis - Table Maintenance Tool

SUCH - Translatability CHECKs Basis - Documentation Tools

VB13 - Display Material Substitution SD - Conditions

PROF - Profit Center Accounting Enterprise Controlling - Basic Settings

EANGLN - Maintain: Global Location Number Logistics - Material Master

XD03 - Display Customer (Centrally) FI - Basic Functions

SOLE - OLE Applications Basis - SAP Automation Controller (OLE Automation Interface)

MB0A - Post Goods Receipt for PO MM - Inventory Management

Glossary:

European Article Number - EAN

Japanese Article Number  - JAN

Universal Product Code - UPC

GTIN with 12 digit - UPC

GTIN with 13 digit - EAN-13

GTIN with 14 digit - EAN/UCC

GTIN with 8 digit -  EAN-8

"Learning is the only thing the mind never exhausts, never fears and never regrets" - LEONARDO DA VINCI

Regards

Chirag Chandramohan Gowda

Problem:

Open requirements in scheduling agreements maintainunderdelivery tolerance in case of underdelivery.

If the open requirement in the scheduling agreement is fewer as the tolerance, the open requirement can't be disposition relevant anymore.

However planned orders will be created for the remaining requirement.

Therefore there are many little requirements in the planning, which shouldn't be produced.

Solution:

The requirements will be reduced in the scheduling agreement based on the open quantity.

The open quantity will be calculated based on the delivered quantity in the S073.
S073 will always be updated with the actually delivered quantity from the delivery

The requirements from the scheudling agreement will be reduced in the scheduling agreement based on the open quantity.

F1 help of the field:

open quantity to be delivered, confirmed in the sales quantity unit and a quantity to be delivered of a schedule line

Usage

The system determinates the delivery quantity with the consideration of the following parameters:

confirmed quantity

already delivered quantity

whether the item has been canceled in the meantime

whether the schedule line is still delivery relevant

Example

A schedule line contains an order quantity of 100 pieces.

The availability check shows, that only 80 pieces are available.

A partial delievery of 50 pieces happened already.

The delivery quantity which has been made from it, conducts 30 pieces.

If the item would be identified as cancelled, the delivery quantity would come to zero.

The open quantity doesn't consider the underdelivery tolerance, only those qunatities will be considered which has been delivered actually.

in contrast of a normal sales order where the sales order has the 'completed' status in case of an appropriate underdelivery tolerance and the remaining quantity is no more requirement relevant.

In the scheduling agreement you can reach it via the setting of the 'reason for rejection'.

As SAP users, we might need to periodically update prices for materials or goods sold. In the case of sales pricing conditions, there might be a fairly good churn. As is known, LSMW is a quick and efficient way to update price conditions in bulk in SAP.

However, when it comes to updating price condition types in SD, which have scales, it becomes a bit tricky to use LSMW. However, it is not complex and the document below will show you the steps to be followed in such a scenario.

Please note that this activity has been done for a sales pricing condition type.

LSMW to update scale based price condition types:

Steps to be followed:

Step 1: Enter SAP Tcode: LSMW

Click on the tick mark in the subsequent pop-up.

Step 2: Create project, subproject and object and name as per your requirement.

Step 3: Click on the menu option -> Goto->Recordings.

The resultant screen will show the recordings available under this project.

Step 4: We will create a new recording for our requirement of price update using VK15. Click on “Create recording,” icon, and enter the relevant details in the resultant pop-up.

Enter the relevant transaction code and table number as required.

Record a single entry of the transaction to be executed using LSMW.  Make sure you follow the steps as you would do in a real-time transaction and avoid copying, and correcting entries, as all this would be recorded in your recording.

Click on the scales button underneath the title.

Step 5: Enter the relevant scale pricing details

Step 6: Click on save. This would take you back to the previous screen, which will now be populated with all the fields recorded during our recording.

Step 7: Click on the menu option, Edit -> Default all.  This will default the names of the fields against each the technical name of each field.

Click on Save. You will now be able to view your recording in the recordings screen.

Step 8: Return to the home screen of LSMW by pressing F3 and click on Execute.

Step 9: Select the first radio button and execute.

Please remember that you have to follow all steps in the LSMW for your update to work correctly.

Click on “Display->Change” button under the title to enter edit mode in the object attributes.

Select the option,”Batch Input Recording,” and select the recording you have made for this data update.

In our current case, it would be VK15.

Step 10: Click on Save. This will take you back to the initial screen of the LSMW and the control will shift to the second radio button – “Maintain Source Structures.”

Step 11: If there is no source structure chosen by default, create a source structure for your current project, and save and move to the next step in the LSMW.

Step 12: The next step is “Maintain Source Fields.” Since you need to maintain all relevant fields needed for your documentation, it would be easier if you could copy all the required fields.

Click on object overview to download a list of the fields.

Select Table

These fields can be copied into a .xls and from there can be copied into the maintain source fields step.

In the maintain source fields step, click on Edit mode and then click on the 

  button. The control will then shift to a screen, where the entries can be copied from the .xls file.

After entering the source fields, you can return to the previous screen and find that all source fields have been updated.

Important: It would be easier to maintain all the fields with the data type as “C”, - alphanumeric.
This would be easier for us to upload data.

Step 13: Click on “Maintain Structure Relations.” This should automatically default to your source structure. If not, maintain accordingly in change mode.

"Unable to post the rest as one document and as per the moderators of the SD forum, I am not allowed to post it in 3 parts."

Different Brazilian tax condition types in SAP SD pricing

In the world of SAP SD, one of the most exciting areas to work in is pricing. Pricing for businesses is different for the different geographical areas in the world. It also depends on individual businesses and corporate strategy, not to consider the different tax regimes in place all over the world.

SAP as an ERP product has to tackle and propose solutions for these scenarios, as this is one of the primary requirements of any ERP package.

We have a number of unique, interesting pricing scenarios all over the world for different countries, some of which are for the Latin American countries, which include Mexico, Brazil, Argentina, etc.,

This document attempts to explain the different types of tax condition types in use in SAP SD for Brazil.

The example used here is the standard pricing procedure available for Brazil in SAP – RVABRA

We can classify the different Brazil relevant tax condition types used in the pricing procedure into one of the following types of taxes:

1. ICMS
2. IPI
3. COFINS
4. ISS
5. PIS

** Most of these abbreviations are for Portuguese words, hence the different nomenclature.

a) ICMS (Imposto sobre Circulação de Mercadorias e Serviços) / (State value-added tax)
 

• In Brazil, a value-added tax levied at state level on the circulation of goods and services.  

• It is applied to the purchase and sale of domestic and imported goods, interstate and inter municipal transportation, and communications.
  
• ICMS is a percentage-included tax, meaning that it is embedded in the price of the goods.
  
• ICMS is paid by private or legal entities who commercialize any goods.
  
• Rate is anywhere between 7% to 25%
  
  

b) IPI (Imposto Sobre Produtos Industrializados.) / (Industrial products tax)

• In Brazil, an excise tax levied at federal level on most domestic and imported manufactured goods. 
  
• IPI is assessed per product and is applied to the gross price, inclusive of ICMS
  
• IPI is a federal tax paid by the industry owner / by the importer of the goods.
  
• Rate is anywhere between 0% to 300 %
  

c) COFINS (Contribuição Social para o Financiamento da Seguridade Social) / (Contribution for the Financing of Social Security.)

• It is a tax for Social Security Financing applied to the monthly invoicing.
  
• COFINS is a state tax paid by the companies who collect taxes based on added value.
  
• Rate can be 3 % or 7.6%
  
  

d) ISS (Imposto sobre Serviços) / ( Municipal Service tax)

• ISS is a municipal tax levied on services, and is paid by the service provider.
  
• Calculation of ISS depends on many factors, such as type of service or location.
  
• In most cases, ISS is charged to the entity that provides the service, but it can also be withheld by the recipient of the service.
  
• Its rate can be based on the service provider's location, the location where the service is provided, or both.
  
• The calculation basis comprises the monthly income of the taxpayer and the price of the service.
  
• Rate is around 5%

e) PIS (Programa de integração social) / (Social integration program) 

• PIS is a federal tax directly paid to the government by legal entities.
  
• It applies to gross revenues earned by all types of legal entities including non-profit makers and organizations held by the government.
  
• Rate can be from 0.65% to 1.65%
  
  

Sources:

1) help.sap.com
2) thebrazilbusiness.com

Screenshots from SAP ECC 6.0

Problem:

Open requirements in scheduling agreements maintainunderdelivery tolerance in case of underdelivery.

If the open requirement in the scheduling agreement is fewer as the tolerance, the open requirement can't be disposition relevant anymore.

However planned orders will be created for the remaining requirement.

Therefore there are many little requirements in the planning, which shouldn't be produced.

Solution:

The requirements will be reduced in the scheduling agreement based on the open quantity.

The open quantity will be calculated based on the delivered quantity in the S073.
S073 will always be updated with the actually delivered quantity from the delivery

The requirements from the scheudling agreement will be reduced in the scheduling agreement based on the open quantity.

F1 help of the field:

open quantity to be delivered, confirmed in the sales quantity unit and a quantity to be delivered of a schedule line

Usage

The system determinates the delivery quantity with the consideration of the following parameters:

confirmed quantity

already delivered quantity

whether the item has been canceled in the meantime

whether the schedule line is still delivery relevant

Example

A schedule line contains an order quantity of 100 pieces.

The availability check shows, that only 80 pieces are available.

A partial delievery of 50 pieces happened already.

The delivery quantity which has been made from it, conducts 30 pieces.

If the item would be identified as cancelled, the delivery quantity would come to zero.

The open quantity doesn't consider the underdelivery tolerance, only those qunatities will be considered which has been delivered actually.

in contrast of a normal sales order where the sales order has the 'completed' status in case of an appropriate underdelivery tolerance and the remaining quantity is no more requirement relevant.

In the scheduling agreement you can reach it via the setting of the 'reason for rejection'.

Business requirement:

• Creation of Production Order only after the approval / release of Sale Order.
• (Cost of goods sold) COGS should not post until proof of delivery is not completed.

Process Flow:                                                       

• Activate business function first LOG_MM_SIT functionality.
• Create Quotation (in my scenario I am using pro forma invoice as quotation) then create sales order with reference to quotation and in sales order credit check is activate.
• Due to credit limit sales order is blocked, as sales order is released from credit check then production orders will create automatically and while creating delivery order system determine batches automatically or manual.
• COGS will post when proof of delivery is done. For more about Stock in Transit review LOG_MM_SIT functionality.http://scn.sap.com/docs/DOC-48809

Configuration:I am supposing that you know about the basic SD Configuration. I am using strategy 82 in material master and marked POD check box in customer master under shipping tab and assigned valuation class in material master as shown in screen shot.

Copy sales order from OR to ZXLX and Copy item category TAK to ZSIT and ZSIT item category is marked as credit active as in screen shot.

Using simple credit limit check and delivery block as in screen shot.

Copy schedule line category CP to ZS screen shot. Maintain copy control settings from order to delivery.

Assign schedule line category with MRP type PD as shown in screen shot.

Using requirement type KMFA and requirement class 201 for automatic production order creation as showing in screen shot.  

Front End Process Flow

Creating sales order with reference to quotation (pro forma invoice in my scenario) and system will execute simple credit check as shown in screen shot.

System creates sales order and will not create production order until someone approves it. As you can see in screen shots of COOIS report there is no production order created against that sales order before approval of sales order.

Sales order will release by using Tcode VA14L as in screen shot.

Now again execute COOIS then you will see that production order has been created automatically with reference to sales order as shown in screen shot.

Now PP person will release production order and do confirmation and post inventory in warehouse and stock will update with reference to sales order as shown in screen shot of MMBE report.

Now create delivery order with reference to sales order and put manual batch or for auto batch determination (see auto batch determination). While creation of delivery order you will see Post Goods Issue tab is in display mode only. Put batch and other information and save delivery order. Now execute stock movement report MB5SIT as shown in screen shot, stock is in Stock TB delivered.

Again go back to delivery order and do the Post Goods Issue then system will generate one material document here and then execute MB5SIT report again, you will see stock is now shifted from Stock TB delivered to Issuing Valuated SIT as shown in screen shot, but it will not post COGS entry until we did not do Proof of Delivery (POD) as per LOG_MM_SIT functionality.

Now do the POD and then you will find that one material document is also created at this stage and also stock will transfer from Issuing Valuated SIT to Delivered Stock in report MB5SIT as shown in screen shot.

Now for complete document process flow see the document flow on screen shot.

Summary and Achievements:

• Credit control on sales order.
• Production order only created after approval / release of sales order by some authorized person.
• Production with reference to sales order.
• Inventory is according to sales order in stock report.
• COGS entry post on Proof of Delivery (POD).
• Tracking of stock while in transit.

Hoping it will help you.

Business requirement:

• Different COGS GL account for Sample / FOC order.
• Automatically assignment of different cost centers to sales order.
• One GL but report according to cost center.

Process Flow:

• Creation of FOC order and assign order reason in it.
• System will automatically assign cost center according to assignment of sales order reason with cost center in backend configuration.
• Create delivery and Post Goods Issues.
• Cost transfer to Cost center.

Configuration Steps:

• SD Document category should be “I” (Order w/o charge) in VOV8.

• Define order reasons.

• Assign order reason with cost center in OVF3.

• Maintain GL assignment in OBYC with General Modification key VAY with respect to valuation class. For more about VAY review

http://www.stechno.net/sap-notes.html?view=sapnote&id=616097

Front End Process Flow:

• Create sales order with and assign order reason as highlighted in screen shot.

• System will take automatically Cost center with respect to assigned order reason.

• Save sales order and create delivery order with reference to sales order and do the Post Goods Issue then you will find that system will take GL that has been defined in OBYC against VAY key. Following is the accounting document against that delivery order.

• Execute report S_ALR_87013611 for cost center values.

Summary / Achievements:

• COGS booked to other GL for FOC scenario.
• Cost center auto assignment.
• Report according to cost center for controlling and decision making purpose.

Hoping this process and document will help you.

Checked the issue with two scheduling agreements of the same Customer.
In case A, customer doesn't receive the warning message if they choose a Weekend day as delivery time, in case B Customer receives it.
Debugged the problem the following way:

First of all I called up Scheduling Agreement 'A'.
On the item level I chose 'Forecast delivery schedule', started debbuger with /h and gave in a Sunday as delivery date ---> enter.
-

After that I set the breakpoint at statement 'message'.

With F8 I found the proper place where the debugger stopped.

I clicked on DA_EXTDATUM1 and I saw that this is the date I was searching for (the Sunday I entered in the beginning).
After that I deleted the breakproints from messages, so that it won't stop at every message in the future.
I check the call stack which program this is called from and set breakpoints to every program.

I set a breakpoint to SD_DELIVERY_DATE_CHECK as well, called up again and started to debug

When I reached field 'wempf-knak' I checked the values in both cases (Scheduling agreement A and B)
In case A the field was empty (had no value), that means that there was no calendar assigned

in case B it had value 01.

This calendar belongs to the ship-to-party's unloading point.

I checked in SPRO what value 01 means:

And I saw there, that the working and non-working days are marked properly.

The proper problem in this case was, that there was no unloading point created, and if it doesn't exist we can't assign a calendar.

Article: Approach for system and business process integration with EDI business partner along with the case study.

Summary: Article includes the case study for EDI integration helping companies to create system-to-system integration and seamless business processes.

Author: Kamal Dial

Created on: 18^st September 2014.

Author Bio: Kamal is a Consultant at Infosys and has over 4.5 years of professional work experience as business process and domain consultant. He is engineering graduate from PEC Chandigarh and post graduate in Management from Symbiosis Pune. He would like to thank his team member Amerjit Singh Mann for his valuable contribution and guidance towards this implementation.

Introduction- EDI integration for seamless business process continuity.

Integration between different business processes within an organization and across organizations is very important for a successful SAP implementation. Integration includes interfacing with legacy systems, communicating with third party partners, and integrating business processes across different systems. EDI (Electronic Data Interchange) technology is used for integration which uses IDOC (Intermediate Document) interface for exchanging data between different systems. EDI provides business process integration across companies by exchanging business documents such as sales order, order confirmation, delivery notes, shipment notices, invoices in electronic form using industry standard formats such as ANSI X12 and EDIFACT.

Purpose: Purpose of this integration with EDI partner is to optimize the business process and improve overall efficiency by eradicating manual intervention in the current process.

Case study: This case study is about major agribusiness client having high volume business with third party EDI partner which involves  exchanging information related to order management, order acknowledgment, availability, delivery, invoice. It required a B2B system integration using standardized communication process considering high transactional volume and inefficiencies in the current process.

As Is Business process

This B2B scenario involves exchange of various documents and information between business partners at different point of time. Usual steps involved as followed:

• Sales Order is placed by EDI business partner with sales representative executive of Agribusiness company using email as mode of communication.
• Data provided by EDI partner involves parameters like EAN code, Quantity required, sold to partner details, ship to address.
• Sales representative maps above provided information to SAP customer, material master data and proceeds with manual order creation in SAP system.
• Once order is saved, information related to availability, delivery date, order reference number and other parameters are sent back to EDI partner for confirmation.
• Similarly any change required in the order management is being handled via mail communication.
• Subsequent flow and information related to Delivery, invoice, and return process is also exchanged via mail.

Problem statement: This process has various drawbacks as below:

• Long processing cycle time due to human intervention and other dependencies involved.
• Error prone process.
• Highly inefficient and laborious due to manual effort involved.
• Cannot be tracked easily and lack of clear visibility in the process.
• Poor customer satisfaction due to delays and errors.
• Cost involved is high considering the manual work and human involvement at various steps.
• Involves redundant data entries and tasks

Approach adopted:

Usage of SAP Process Integration which is a platform to provide a single point of integration without changing existing complex network of legacy systems. It’s a powerful middleware by SAP to provide seamless end to end integration between SAP and non-SAP applications inside and outside the corporate boundary.

TO BE Business process:

Automate process of order creation: Orders will be initiated by EDI partner directly which would flow to SAP system (of agribusiness company) via IDOCS.

Interface: Net weaver Process Orchestration provides process integration and business rules management to help companies create system-to-system integration and seamless business processes.

Order responses: The order confirmation will happen in SAP depending upon the availability of material and order response will send the information to EDI partner via IDOC after validation

Delivery, invoice- Other information and documents related to order changes, delivery, invoice will be also exchanged via IDOCS.

Solution implemented:

1. Order creation/ change order: For order creation/change setup partner details in SAP using transaction WE20-

• Creation of new partner profile under partner type (KU) i.e. customer.
• It involves configuring of inbound parameters like Message type, process code and mapping it with function module as per business requirement.

Technical changes involved in include - LVEDAF2U using enhancement spot in program SAPLVEDA to populate values in inbound IDOC using below mapping

• Mapping order type with SAP order types, partner number mapped using EDPAR table in SAP, material mapping using EAN code from IDOC and other parameters mapping like sales division, order reason and delivery block etc.

By default, order is created with predefined delivery block since it needs to be validated by sales representative before confirming back to EDI business partner. New customized order reason can be used to distinguish a normal order from an EDI order.

2. Order response used for sending order confirmation, outbound parameters are maintained for EDI partner in transaction code WE20.

Prerequisites before configuration outbound parameters are:

• Output type with V1 application needs to be created with required access sequence and assigned to output procedure in NACE transaction.
• Port creation (receiver port) in WE21 transaction code which is used transferring data needs to be created and configured.
• Creation of new directory in AL11 transaction code where IDOC will be placed.

Outbound parameter setup require below steps:

• Configuring outbound parameters like Message type, Message code, output mode.
• Receiver port created above needs to be configured here.
• Standard or customized IDOC basic type and extension to be used.
• Application (V1) is mapped with output type, process code and corresponding function module.

Technical changes: Requirement routine created to trigger the output only when delivery block is removed by sales representative executive after order validation. This routine is configured in output procedure itself

3.Delivery and invoice related information is being sent to EDI partner, for that outbound delivery/invoice based parameters needs to be configured in outbound parameters.

• Message type, message code
• IDOC basic type and extension needs to be configured.
• Creation of new output types for V2 /V3 application for mapping it with process code and function module.
• Receiving ports and directory creation.

4.Notification updates: Customized report is created to  provide below information to sales service officers

• The list of the IDOCS (inbound/outbound) failed with the list of errors within this IDOC (unknown partner, unknown material, Division etc.).This enables them to take corrective actions.
• The list of the Sales orders successfully created – using this CS officers are able to confirm the sales order and release it for further processing.
• This program runs via batch job and sends output after every 15 minutes to key users/customer service officers.

Process and system Integration after implementation:

Automation and seamless integration of business processes achieved. Orders are triggered by EDI partner directly which would flow to SAP system (of agribusiness client) through IDOCS via SAP PI interface. Once confirmed and checked by sales representative executive, order response is being sent back to EDI business partner automatically. Delivery and invoice related information is also being sent to partner automatically using outbound IDOCS. 

Key challenges involved:

1. PI interface should be able to handle high volume due peak season to ensure stability and sustainability of the interface. 
2. Consistent and error free master data at the source. The goal is to avoid misaligned, erroneous data at the point of creation.
3. Complete and accurate customer, material master data mapping and maintenance in SAP is required.
4. To deliver the expected business result without any adverse impact on the system or any other existing order management process. This involves continuous program management between the business organizations.
5. Continuous monitoring of the interface after go-live to ensure seamless business process and system integration.
6. Failure Notifications and success updates should be sent instantly to end users without any delay so appropriate action can be taken up immediately.
7. Error handling process to reprocess failed updates and IDOCS to resolve issues.
8. User training and guidelines to be provided to adapt new ways of working and business process.

  Conclusion:

• Automation in order management, Delivery, invoice information exchange with third party EDI partner.
• Enhanced visibility and transparency in the overall process.
• Reduced overall cycle time with system and business process integration.
• Increasing efficiency of the business process and customer satisfaction with decreased overall lead
  time.

  Business Benefits:

1. Cost effective solution and process automation.
2. Enhanced business process with reduction in the processing time.
3. Reliable and better- delivery plans with correct scheduling arrangements due to automation.
4. Reduction in manual work and effort savings.
5. Customer satisfaction leading to repeat customer sales.
6. Increase in overall sales and cost optimization.

Recommendations:

• Post implementation it is required to maintain complete and error free master data, appropriate mapping is also required in production environment.
• Implementation of new Z program to provide list of the failed IDOCS with the list of errors (unknown partner, wrong material, missing data etc.).Report also provides list of sales orders which are successfully created via inbound IDOCS. Using SAP batch job, this information is provided to relevant business stakeholders and functional support team.
• Adequate training for the end key users to adapt new ways of working and business process.

Abbreviations

• EDI -Electronic Data Interchange.
• IDOC- Intermediate Document.
• ANSI X12 -American National Standards Institute.
• EDIFACT- Electronic Data Interchange for Administration, Commerce, and Transport.

Business requirement:

• Creation of Production Order only after the approval / release of Sale Order.
• (Cost of goods sold) COGS should not post until proof of delivery is not completed.

Process Flow:                                                       

• Activate business function first LOG_MM_SIT functionality.
• Create Quotation (in my scenario I am using pro forma invoice as quotation) then create sales order with reference to quotation and in sales order credit check is activate.
• Due to credit limit sales order is blocked, as sales order is released from credit check then production orders will create automatically and while creating delivery order system determine batches automatically or manual.
• COGS will post when proof of delivery is done. For more about Stock in Transit review LOG_MM_SIT functionality.http://scn.sap.com/docs/DOC-48809

Configuration:I am supposing that you know about the basic SD Configuration. I am using strategy 82 in material master and marked POD check box in customer master under shipping tab and assigned valuation class in material master as shown in screen shot.

Copy sales order from OR to ZXLX and Copy item category TAK to ZSIT and ZSIT item category is marked as credit active as in screen shot.

Using simple credit limit check and delivery block as in screen shot.

Copy schedule line category CP to ZS screen shot. Maintain copy control settings from order to delivery.

Assign schedule line category with MRP type PD as shown in screen shot.

Using requirement type KMFA and requirement class 201 for automatic production order creation as showing in screen shot.  

Front End Process Flow

Creating sales order with reference to quotation (pro forma invoice in my scenario) and system will execute simple credit check as shown in screen shot.

System creates sales order and will not create production order until someone approves it. As you can see in screen shots of COOIS report there is no production order created against that sales order before approval of sales order.

Sales order will release by using Tcode VA14L as in screen shot.

Now again execute COOIS then you will see that production order has been created automatically with reference to sales order as shown in screen shot.

Now PP person will release production order and do confirmation and post inventory in warehouse and stock will update with reference to sales order as shown in screen shot of MMBE report.

Now create delivery order with reference to sales order and put manual batch or for auto batch determination (see auto batch determination). While creation of delivery order you will see Post Goods Issue tab is in display mode only. Put batch and other information and save delivery order. Now execute stock movement report MB5SIT as shown in screen shot, stock is in Stock TB delivered.

Again go back to delivery order and do the Post Goods Issue then system will generate one material document here and then execute MB5SIT report again, you will see stock is now shifted from Stock TB delivered to Issuing Valuated SIT as shown in screen shot, but it will not post COGS entry until we did not do Proof of Delivery (POD) as per LOG_MM_SIT functionality.

Now do the POD and then you will find that one material document is also created at this stage and also stock will transfer from Issuing Valuated SIT to Delivered Stock in report MB5SIT as shown in screen shot.

Now for complete document process flow see the document flow on screen shot.

Summary and Achievements:

• Credit control on sales order.
• Production order only created after approval / release of sales order by some authorized person.
• Production with reference to sales order.
• Inventory is according to sales order in stock report.
• COGS entry post on Proof of Delivery (POD).
• Tracking of stock while in transit.

Hoping it will help you.

Business requirement:

• Different COGS GL account for Sample / FOC order.
• Automatically assignment of different cost centers to sales order.
• One GL but report according to cost center.

Process Flow:

• Creation of FOC order and assign order reason in it.
• System will automatically assign cost center according to assignment of sales order reason with cost center in backend configuration.
• Create delivery and Post Goods Issues.
• Cost transfer to Cost center.

Configuration Steps:

• SD Document category should be “I” (Order w/o charge) in VOV8.

• Define order reasons.

• Assign order reason with cost center in OVF3.

• Maintain GL assignment in OBYC with General Modification key VAY with respect to valuation class. For more about VAY review

http://www.stechno.net/sap-notes.html?view=sapnote&id=616097

Front End Process Flow:

• Create sales order with and assign order reason as highlighted in screen shot.

• System will take automatically Cost center with respect to assigned order reason.

• Save sales order and create delivery order with reference to sales order and do the Post Goods Issue then you will find that system will take GL that has been defined in OBYC against VAY key. Following is the accounting document against that delivery order.

• Execute report S_ALR_87013611 for cost center values.

Summary / Achievements:

• COGS booked to other GL for FOC scenario.
• Cost center auto assignment.
• Report according to cost center for controlling and decision making purpose.

Hoping this process and document will help you.

Checked the issue with two scheduling agreements of the same Customer.
In case A, customer doesn't receive the warning message if they choose a Weekend day as delivery time, in case B Customer receives it.
Debugged the problem the following way:

First of all I called up Scheduling Agreement 'A'.
On the item level I chose 'Forecast delivery schedule', started debbuger with /h and gave in a Sunday as delivery date ---> enter.
-

After that I set the breakpoint at statement 'message'.

With F8 I found the proper place where the debugger stopped.

I clicked on DA_EXTDATUM1 and I saw that this is the date I was searching for (the Sunday I entered in the beginning).
After that I deleted the breakproints from messages, so that it won't stop at every message in the future.
I check the call stack which program this is called from and set breakpoints to every program.

I set a breakpoint to SD_DELIVERY_DATE_CHECK as well, called up again and started to debug

When I reached field 'wempf-knak' I checked the values in both cases (Scheduling agreement A and B)
In case A the field was empty (had no value), that means that there was no calendar assigned

in case B it had value 01.

This calendar belongs to the ship-to-party's unloading point.

I checked in SPRO what value 01 means:

And I saw there, that the working and non-working days are marked properly.

The proper problem in this case was, that there was no unloading point created, and if it doesn't exist we can't assign a calendar.

Article: Approach for system and business process integration with EDI business partner along with the case study.

Summary: Article includes the case study for EDI integration helping companies to create system-to-system integration and seamless business processes.

Author: Kamal Dial

Created on: 18^st September 2014.

Author Bio: Kamal is a Consultant at Infosys and has over 4.5 years of professional work experience as business process and domain consultant. He is engineering graduate from PEC Chandigarh and post graduate in Management from Symbiosis Pune. He would like to thank his team member Amerjit Singh Mann for his valuable contribution and guidance towards this implementation.

Introduction- EDI integration for seamless business process continuity.

Integration between different business processes within an organization and across organizations is very important for a successful SAP implementation. Integration includes interfacing with legacy systems, communicating with third party partners, and integrating business processes across different systems. EDI (Electronic Data Interchange) technology is used for integration which uses IDOC (Intermediate Document) interface for exchanging data between different systems. EDI provides business process integration across companies by exchanging business documents such as sales order, order confirmation, delivery notes, shipment notices, invoices in electronic form using industry standard formats such as ANSI X12 and EDIFACT.

Purpose: Purpose of this integration with EDI partner is to optimize the business process and improve overall efficiency by eradicating manual intervention in the current process.

Case study: This case study is about major agribusiness client having high volume business with third party EDI partner which involves  exchanging information related to order management, order acknowledgment, availability, delivery, invoice. It required a B2B system integration using standardized communication process considering high transactional volume and inefficiencies in the current process.

As Is Business process

This B2B scenario involves exchange of various documents and information between business partners at different point of time. Usual steps involved as followed:

• Sales Order is placed by EDI business partner with sales representative executive of Agribusiness company using email as mode of communication.
• Data provided by EDI partner involves parameters like EAN code, Quantity required, sold to partner details, ship to address.
• Sales representative maps above provided information to SAP customer, material master data and proceeds with manual order creation in SAP system.
• Once order is saved, information related to availability, delivery date, order reference number and other parameters are sent back to EDI partner for confirmation.
• Similarly any change required in the order management is being handled via mail communication.
• Subsequent flow and information related to Delivery, invoice, and return process is also exchanged via mail.

Problem statement: This process has various drawbacks as below:

• Long processing cycle time due to human intervention and other dependencies involved.
• Error prone process.
• Highly inefficient and laborious due to manual effort involved.
• Cannot be tracked easily and lack of clear visibility in the process.
• Poor customer satisfaction due to delays and errors.
• Cost involved is high considering the manual work and human involvement at various steps.
• Involves redundant data entries and tasks

Approach adopted:

Usage of SAP Process Integration which is a platform to provide a single point of integration without changing existing complex network of legacy systems. It’s a powerful middleware by SAP to provide seamless end to end integration between SAP and non-SAP applications inside and outside the corporate boundary.

TO BE Business process:

Automate process of order creation: Orders will be initiated by EDI partner directly which would flow to SAP system (of agribusiness company) via IDOCS.

Interface: Net weaver Process Orchestration provides process integration and business rules management to help companies create system-to-system integration and seamless business processes.

Order responses: The order confirmation will happen in SAP depending upon the availability of material and order response will send the information to EDI partner via IDOC after validation

Delivery, invoice- Other information and documents related to order changes, delivery, invoice will be also exchanged via IDOCS.

Solution implemented:

1. Order creation/ change order: For order creation/change setup partner details in SAP using transaction WE20-

• Creation of new partner profile under partner type (KU) i.e. customer.
• It involves configuring of inbound parameters like Message type, process code and mapping it with function module as per business requirement.

Technical changes involved in include - LVEDAF2U using enhancement spot in program SAPLVEDA to populate values in inbound IDOC using below mapping

• Mapping order type with SAP order types, partner number mapped using EDPAR table in SAP, material mapping using EAN code from IDOC and other parameters mapping like sales division, order reason and delivery block etc.

By default, order is created with predefined delivery block since it needs to be validated by sales representative before confirming back to EDI business partner. New customized order reason can be used to distinguish a normal order from an EDI order.

2. Order response used for sending order confirmation, outbound parameters are maintained for EDI partner in transaction code WE20.

Prerequisites before configuration outbound parameters are:

• Output type with V1 application needs to be created with required access sequence and assigned to output procedure in NACE transaction.
• Port creation (receiver port) in WE21 transaction code which is used transferring data needs to be created and configured.
• Creation of new directory in AL11 transaction code where IDOC will be placed.

Outbound parameter setup require below steps:

• Configuring outbound parameters like Message type, Message code, output mode.
• Receiver port created above needs to be configured here.
• Standard or customized IDOC basic type and extension to be used.
• Application (V1) is mapped with output type, process code and corresponding function module.

Technical changes: Requirement routine created to trigger the output only when delivery block is removed by sales representative executive after order validation. This routine is configured in output procedure itself

3.Delivery and invoice related information is being sent to EDI partner, for that outbound delivery/invoice based parameters needs to be configured in outbound parameters.

• Message type, message code
• IDOC basic type and extension needs to be configured.
• Creation of new output types for V2 /V3 application for mapping it with process code and function module.
• Receiving ports and directory creation.

4.Notification updates: Customized report is created to  provide below information to sales service officers

• The list of the IDOCS (inbound/outbound) failed with the list of errors within this IDOC (unknown partner, unknown material, Division etc.).This enables them to take corrective actions.
• The list of the Sales orders successfully created – using this CS officers are able to confirm the sales order and release it for further processing.
• This program runs via batch job and sends output after every 15 minutes to key users/customer service officers.

Process and system Integration after implementation:

Automation and seamless integration of business processes achieved. Orders are triggered by EDI partner directly which would flow to SAP system (of agribusiness client) through IDOCS via SAP PI interface. Once confirmed and checked by sales representative executive, order response is being sent back to EDI business partner automatically. Delivery and invoice related information is also being sent to partner automatically using outbound IDOCS. 

Key challenges involved:

1. PI interface should be able to handle high volume due peak season to ensure stability and sustainability of the interface. 
2. Consistent and error free master data at the source. The goal is to avoid misaligned, erroneous data at the point of creation.
3. Complete and accurate customer, material master data mapping and maintenance in SAP is required.
4. To deliver the expected business result without any adverse impact on the system or any other existing order management process. This involves continuous program management between the business organizations.
5. Continuous monitoring of the interface after go-live to ensure seamless business process and system integration.
6. Failure Notifications and success updates should be sent instantly to end users without any delay so appropriate action can be taken up immediately.
7. Error handling process to reprocess failed updates and IDOCS to resolve issues.
8. User training and guidelines to be provided to adapt new ways of working and business process.

  Conclusion:

• Automation in order management, Delivery, invoice information exchange with third party EDI partner.
• Enhanced visibility and transparency in the overall process.
• Reduced overall cycle time with system and business process integration.
• Increasing efficiency of the business process and customer satisfaction with decreased overall lead
  time.

  Business Benefits:

1. Cost effective solution and process automation.
2. Enhanced business process with reduction in the processing time.
3. Reliable and better- delivery plans with correct scheduling arrangements due to automation.
4. Reduction in manual work and effort savings.
5. Customer satisfaction leading to repeat customer sales.
6. Increase in overall sales and cost optimization.

Recommendations:

• Post implementation it is required to maintain complete and error free master data, appropriate mapping is also required in production environment.
• Implementation of new Z program to provide list of the failed IDOCS with the list of errors (unknown partner, wrong material, missing data etc.).Report also provides list of sales orders which are successfully created via inbound IDOCS. Using SAP batch job, this information is provided to relevant business stakeholders and functional support team.
• Adequate training for the end key users to adapt new ways of working and business process.

Abbreviations

• EDI -Electronic Data Interchange.
• IDOC- Intermediate Document.
• ANSI X12 -American National Standards Institute.
• EDIFACT- Electronic Data Interchange for Administration, Commerce, and Transport.

*** Update from 23/03/2014: Note 1992885was created based on the information from this document ***

Issues related to sales orders are very frequently observed on transaction MD04. This document provides a brief explanation and the solution for the most common

of these issues:

1 - A sales order/delivery is already completed or deleted but it still appears on MD04.

This is usually an inconsistency and the report SDRQCR21 should be already available on your system to clear inconsistent records. See note 25444 for more details. Notes 2063668 and 1909466corrects a program error that generates this kind of inconsistency.

2 - A MTO sales order is completed/delivered, but the sales order special stock is still displayed on MD04.

Usually, this kind of issue happens because there is a quantity of material still linked to the sales order special stock.

Note 1723507provides a solution to this issue.

3 - The sales order/delivery number is not displayed.

This is not an error. It happens when “daily requirement” or “weekly requirement” is selected for the availability check in the material master.

See notes 70408 and1649669 for more details.

4 - The sales order is displayed on MD04, but it does not affect the "available quantity".

This is usually related to the sales order requirement class/type settings. See note 1825187.

5 - The sales order is not displayed on MD04.

Transaction MD04 reads the sales order requirements from tables VBBE or VBBS. If there is no requirements for the sales order on those tables, nothing will be displayed and this is very often related to the sales order requirement class/type settings. See note 207942 for more details.

See also the following document for more frequent issues on MD04:

http://scn.sap.com/docs/DOC-49467

Problem:

Open requirements in scheduling agreements maintainunderdelivery tolerance in case of underdelivery.

If the open requirement in the scheduling agreement is fewer as the tolerance, the open requirement can't be disposition relevant anymore.

However planned orders will be created for the remaining requirement.

Therefore there are many little requirements in the planning, which shouldn't be produced.

Solution:

The requirements will be reduced in the scheduling agreement based on the open quantity.

The open quantity will be calculated based on the delivered quantity in the S073.
S073 will always be updated with the actually delivered quantity from the delivery

The requirements from the scheudling agreement will be reduced in the scheduling agreement based on the open quantity.

F1 help of the field:

open quantity to be delivered, confirmed in the sales quantity unit and a quantity to be delivered of a schedule line

Usage

The system determinates the delivery quantity with the consideration of the following parameters:

confirmed quantity

already delivered quantity

whether the item has been canceled in the meantime

whether the schedule line is still delivery relevant

Example

A schedule line contains an order quantity of 100 pieces.

The availability check shows, that only 80 pieces are available.

A partial delievery of 50 pieces happened already.

The delivery quantity which has been made from it, conducts 30 pieces.

If the item would be identified as cancelled, the delivery quantity would come to zero.

The open quantity doesn't consider the underdelivery tolerance, only those qunatities will be considered which has been delivered actually.

in contrast of a normal sales order where the sales order has the 'completed' status in case of an appropriate underdelivery tolerance and the remaining quantity is no more requirement relevant.

In the scheduling agreement you can reach it via the setting of the 'reason for rejection'.

Business requirement:

• Creation of Production Order only after the approval / release of Sale Order.
• (Cost of goods sold) COGS should not post until proof of delivery is not completed.

Process Flow:                                                       

• Activate business function first LOG_MM_SIT functionality.
• Create Quotation (in my scenario I am using pro forma invoice as quotation) then create sales order with reference to quotation and in sales order credit check is activate.
• Due to credit limit sales order is blocked, as sales order is released from credit check then production orders will create automatically and while creating delivery order system determine batches automatically or manual.
• COGS will post when proof of delivery is done. For more about Stock in Transit review LOG_MM_SIT functionality.http://scn.sap.com/docs/DOC-48809

Configuration:I am supposing that you know about the basic SD Configuration. I am using strategy 82 in material master and marked POD check box in customer master under shipping tab and assigned valuation class in material master as shown in screen shot.

Copy sales order from OR to ZXLX and Copy item category TAK to ZSIT and ZSIT item category is marked as credit active as in screen shot.

Using simple credit limit check and delivery block as in screen shot.

Copy schedule line category CP to ZS screen shot. Maintain copy control settings from order to delivery.

Assign schedule line category with MRP type PD as shown in screen shot.

Using requirement type KMFA and requirement class 201 for automatic production order creation as showing in screen shot.  

Front End Process Flow

Creating sales order with reference to quotation (pro forma invoice in my scenario) and system will execute simple credit check as shown in screen shot.

System creates sales order and will not create production order until someone approves it. As you can see in screen shots of COOIS report there is no production order created against that sales order before approval of sales order.

Sales order will release by using Tcode VA14L as in screen shot.

Now again execute COOIS then you will see that production order has been created automatically with reference to sales order as shown in screen shot.

Now PP person will release production order and do confirmation and post inventory in warehouse and stock will update with reference to sales order as shown in screen shot of MMBE report.

Now create delivery order with reference to sales order and put manual batch or for auto batch determination (see auto batch determination). While creation of delivery order you will see Post Goods Issue tab is in display mode only. Put batch and other information and save delivery order. Now execute stock movement report MB5SIT as shown in screen shot, stock is in Stock TB delivered.

Again go back to delivery order and do the Post Goods Issue then system will generate one material document here and then execute MB5SIT report again, you will see stock is now shifted from Stock TB delivered to Issuing Valuated SIT as shown in screen shot, but it will not post COGS entry until we did not do Proof of Delivery (POD) as per LOG_MM_SIT functionality.

Now do the POD and then you will find that one material document is also created at this stage and also stock will transfer from Issuing Valuated SIT to Delivered Stock in report MB5SIT as shown in screen shot.

Now for complete document process flow see the document flow on screen shot.

Summary and Achievements:

• Credit control on sales order.
• Production order only created after approval / release of sales order by some authorized person.
• Production with reference to sales order.
• Inventory is according to sales order in stock report.
• COGS entry post on Proof of Delivery (POD).
• Tracking of stock while in transit.

Hoping it will help you.

Business requirement:

• Different COGS GL account for Sample / FOC order.
• Automatically assignment of different cost centers to sales order.
• One GL but report according to cost center.

Process Flow:

• Creation of FOC order and assign order reason in it.
• System will automatically assign cost center according to assignment of sales order reason with cost center in backend configuration.
• Create delivery and Post Goods Issues.
• Cost transfer to Cost center.

Configuration Steps:

• SD Document category should be “I” (Order w/o charge) in VOV8.

• Define order reasons.

• Assign order reason with cost center in OVF3.

• Maintain GL assignment in OBYC with General Modification key VAY with respect to valuation class. For more about VAY review

http://www.stechno.net/sap-notes.html?view=sapnote&id=616097

Front End Process Flow:

• Create sales order with and assign order reason as highlighted in screen shot.

• System will take automatically Cost center with respect to assigned order reason.

• Save sales order and create delivery order with reference to sales order and do the Post Goods Issue then you will find that system will take GL that has been defined in OBYC against VAY key. Following is the accounting document against that delivery order.

• Execute report S_ALR_87013611 for cost center values.

Summary / Achievements:

• COGS booked to other GL for FOC scenario.
• Cost center auto assignment.
• Report according to cost center for controlling and decision making purpose.

Hoping this process and document will help you.

SAP Vistex is an embedded SAP R/3 add-on that calculates and settles all types of incentives and paybacks related to Logistics business processes like Sales and Distribution and Material Management etc. It is designed to address all possible scenarios of business during its sales and purchases.

Vistex is also know as the IP (Incentive and Payback) module.

Incentive or Payback is the amount paid to the customer or distributor in the form of a refund or return on what is already paid for. It is a common business tactic that companies employ to boost their net sales, generate customer loyalty, product recognition and increase market share.

The following business scenarios are supported by the IP module:

1. Chargeback (CB)

2. Sales Commission and Incentive Compensation (SI)

3. Billbacks (BB)

4. Customer Rebates (CR)

5. Purchasing Volume Rebates (PR)

Chargeback & Billback is defined as the amount claimed by a distributor from the manufacturer or vendor against the difference between their initial acquisition price and the actual agreed upon price for products and services sold to end customer or partner. This business process takes place based on a mutual agreement between a distributor and the manufacturer/vendor

Sales & Purchase Rebate is a discount granted by a company to its customers on the basis of sales volume over a specific period of time (which is known as the validity period of the rebate agreement). It has been a very successful technique to in promoting a company’s products and services

Incentive Compensation is a business technique aimed to encourage the bottom line of any company which is to perform to its best potential. This is done by Communicating Company’s expectations, Supporting changes, Managing Talent (for e.g. identifying top performers and rewarding them appropriately (whichhelps in retaining the experienced staffs)), Managing and sharing risk (Providing additional upside when an individual has a very good year and vice-versa)

Steps in Vistex Process

1. Plan creation

2. Participant Creation and Target settings

3. Sales Order Creation

4. Delivery creation

5. Invoicing customer

6. Document creation

7. Adjustment based on rules

8. Accruals and Tracking

9. Payment to Participant

There are two different processing which are present in SAP Vistex.

Transaction Processing

The IP Module of Vistex manages processing based on transactions.

There are no quota or targets used.

The amount is calculated on document by document basis.

Process starts with defining agreements where rules and conditions are defined.

Settlement rules are also defined in the agreements.

After billing is created in standard SAP, incentive and payback document called as IP document is created.

The amount calculated in the IP document can be adjusted manually.

IP document forms the basis of calculation based on rules defined in agreements.

The information is transferred to SAP for payment to customer followed by financial postings in FI.

Composite Processing

The IP Module of Vistex manages processing based on transactions of any complexity.

The actual performance data is compared against quotas for calculation of rebates.

In composite processing amounts aggregated into matrices as actual performance data.

Process starts with defining deployment code and components/agreements types/matrices/participant.

Settlement rules are also defined in the agreements - daily or on predefined dates.

After billing is created in standard SAP, incentive and payback document called as IP document is created.

All the IP documents gets aggregated in Participant Performance & Tracking module of Vistex where Rebates are calculated based on comparing performance with defined quotas and rules.

Participant can track his performance at any time of time during the validity of agreement type.

After calculation and adjustment, the data is transferred from Vistex to SAP for actual payment followed by financial postings in FI.

Article: Approach for system and business process integration with EDI business partner along with the case study.

Summary: Article includes the case study for EDI integration helping companies to create system-to-system integration and seamless business processes.

Author: Kamal Dial

Created on: 18^st September 2014.

Author Bio: Kamal is a Consultant at Infosys and has over 4.5 years of professional work experience as business process and domain consultant. He is engineering graduate from PEC Chandigarh and post graduate in Management from Symbiosis Pune. He would like to thank his team member Amerjit Singh Mann for his valuable contribution and guidance towards this implementation.

Introduction- EDI integration for seamless business process continuity.

Integration between different business processes within an organization and across organizations is very important for a successful SAP implementation. Integration includes interfacing with legacy systems, communicating with third party partners, and integrating business processes across different systems. EDI (Electronic Data Interchange) technology is used for integration which uses IDOC (Intermediate Document) interface for exchanging data between different systems. EDI provides business process integration across companies by exchanging business documents such as sales order, order confirmation, delivery notes, shipment notices, invoices in electronic form using industry standard formats such as ANSI X12 and EDIFACT.

Purpose: Purpose of this integration with EDI partner is to optimize the business process and improve overall efficiency by eradicating manual intervention in the current process.

Case study: This case study is about major agribusiness client having high volume business with third party EDI partner which involves  exchanging information related to order management, order acknowledgment, availability, delivery, invoice. It required a B2B system integration using standardized communication process considering high transactional volume and inefficiencies in the current process.

As Is Business process

This B2B scenario involves exchange of various documents and information between business partners at different point of time. Usual steps involved as followed:

• Sales Order is placed by EDI business partner with sales representative executive of Agribusiness company using email as mode of communication.
• Data provided by EDI partner involves parameters like EAN code, Quantity required, sold to partner details, ship to address.
• Sales representative maps above provided information to SAP customer, material master data and proceeds with manual order creation in SAP system.
• Once order is saved, information related to availability, delivery date, order reference number and other parameters are sent back to EDI partner for confirmation.
• Similarly any change required in the order management is being handled via mail communication.
• Subsequent flow and information related to Delivery, invoice, and return process is also exchanged via mail.

Problem statement: This process has various drawbacks as below:

• Long processing cycle time due to human intervention and other dependencies involved.
• Error prone process.
• Highly inefficient and laborious due to manual effort involved.
• Cannot be tracked easily and lack of clear visibility in the process.
• Poor customer satisfaction due to delays and errors.
• Cost involved is high considering the manual work and human involvement at various steps.
• Involves redundant data entries and tasks

Approach adopted:

Usage of SAP Process Integration which is a platform to provide a single point of integration without changing existing complex network of legacy systems. It’s a powerful middleware by SAP to provide seamless end to end integration between SAP and non-SAP applications inside and outside the corporate boundary.

TO BE Business process:

Automate process of order creation: Orders will be initiated by EDI partner directly which would flow to SAP system (of agribusiness company) via IDOCS.

Interface: Net weaver Process Orchestration provides process integration and business rules management to help companies create system-to-system integration and seamless business processes.

Order responses: The order confirmation will happen in SAP depending upon the availability of material and order response will send the information to EDI partner via IDOC after validation

Delivery, invoice- Other information and documents related to order changes, delivery, invoice will be also exchanged via IDOCS.

Solution implemented:

1. Order creation/ change order: For order creation/change setup partner details in SAP using transaction WE20-

• Creation of new partner profile under partner type (KU) i.e. customer.
• It involves configuring of inbound parameters like Message type, process code and mapping it with function module as per business requirement.

Technical changes involved in include - LVEDAF2U using enhancement spot in program SAPLVEDA to populate values in inbound IDOC using below mapping

• Mapping order type with SAP order types, partner number mapped using EDPAR table in SAP, material mapping using EAN code from IDOC and other parameters mapping like sales division, order reason and delivery block etc.

By default, order is created with predefined delivery block since it needs to be validated by sales representative before confirming back to EDI business partner. New customized order reason can be used to distinguish a normal order from an EDI order.

2. Order response used for sending order confirmation, outbound parameters are maintained for EDI partner in transaction code WE20.

Prerequisites before configuration outbound parameters are:

• Output type with V1 application needs to be created with required access sequence and assigned to output procedure in NACE transaction.
• Port creation (receiver port) in WE21 transaction code which is used transferring data needs to be created and configured.
• Creation of new directory in AL11 transaction code where IDOC will be placed.

Outbound parameter setup require below steps:

• Configuring outbound parameters like Message type, Message code, output mode.
• Receiver port created above needs to be configured here.
• Standard or customized IDOC basic type and extension to be used.
• Application (V1) is mapped with output type, process code and corresponding function module.

Technical changes: Requirement routine created to trigger the output only when delivery block is removed by sales representative executive after order validation. This routine is configured in output procedure itself

3.Delivery and invoice related information is being sent to EDI partner, for that outbound delivery/invoice based parameters needs to be configured in outbound parameters.

• Message type, message code
• IDOC basic type and extension needs to be configured.
• Creation of new output types for V2 /V3 application for mapping it with process code and function module.
• Receiving ports and directory creation.

4.Notification updates: Customized report is created to  provide below information to sales service officers

• The list of the IDOCS (inbound/outbound) failed with the list of errors within this IDOC (unknown partner, unknown material, Division etc.).This enables them to take corrective actions.
• The list of the Sales orders successfully created – using this CS officers are able to confirm the sales order and release it for further processing.
• This program runs via batch job and sends output after every 15 minutes to key users/customer service officers.

Process and system Integration after implementation:

Automation and seamless integration of business processes achieved. Orders are triggered by EDI partner directly which would flow to SAP system (of agribusiness client) through IDOCS via SAP PI interface. Once confirmed and checked by sales representative executive, order response is being sent back to EDI business partner automatically. Delivery and invoice related information is also being sent to partner automatically using outbound IDOCS. 

Key challenges involved:

1. PI interface should be able to handle high volume due peak season to ensure stability and sustainability of the interface. 
2. Consistent and error free master data at the source. The goal is to avoid misaligned, erroneous data at the point of creation.
3. Complete and accurate customer, material master data mapping and maintenance in SAP is required.
4. To deliver the expected business result without any adverse impact on the system or any other existing order management process. This involves continuous program management between the business organizations.
5. Continuous monitoring of the interface after go-live to ensure seamless business process and system integration.
6. Failure Notifications and success updates should be sent instantly to end users without any delay so appropriate action can be taken up immediately.
7. Error handling process to reprocess failed updates and IDOCS to resolve issues.
8. User training and guidelines to be provided to adapt new ways of working and business process.

  Conclusion:

• Automation in order management, Delivery, invoice information exchange with third party EDI partner.
• Enhanced visibility and transparency in the overall process.
• Reduced overall cycle time with system and business process integration.
• Increasing efficiency of the business process and customer satisfaction with decreased overall lead
  time.

  Business Benefits:

1. Cost effective solution and process automation.
2. Enhanced business process with reduction in the processing time.
3. Reliable and better- delivery plans with correct scheduling arrangements due to automation.
4. Reduction in manual work and effort savings.
5. Customer satisfaction leading to repeat customer sales.
6. Increase in overall sales and cost optimization.

Recommendations:

• Post implementation it is required to maintain complete and error free master data, appropriate mapping is also required in production environment.
• Implementation of new Z program to provide list of the failed IDOCS with the list of errors (unknown partner, wrong material, missing data etc.).Report also provides list of sales orders which are successfully created via inbound IDOCS. Using SAP batch job, this information is provided to relevant business stakeholders and functional support team.
• Adequate training for the end key users to adapt new ways of working and business process.

Abbreviations

• EDI -Electronic Data Interchange.
• IDOC- Intermediate Document.
• ANSI X12 -American National Standards Institute.
• EDIFACT- Electronic Data Interchange for Administration, Commerce, and Transport.

*** Update from 23/03/2014: Note 1992885was created based on the information from this document ***

Issues related to sales orders are very frequently observed on transaction MD04. This document provides a brief explanation and the solution for the most common

of these issues:

1 - A sales order/delivery is already completed or deleted but it still appears on MD04.

This is usually an inconsistency and the report SDRQCR21 should be already available on your system to clear inconsistent records. See note 25444 for more details. Notes 2063668 and 1909466corrects a program error that generates this kind of inconsistency.

2 - A MTO sales order is completed/delivered, but the sales order special stock is still displayed on MD04.

Usually, this kind of issue happens because there is a quantity of material still linked to the sales order special stock.

Note 1723507provides a solution to this issue.

3 - The sales order/delivery number is not displayed.

This is not an error. It happens when “daily requirement” or “weekly requirement” is selected for the availability check in the material master.

See notes 70408 and1649669 for more details.

4 - The sales order is displayed on MD04, but it does not affect the "available quantity".

This is usually related to the sales order requirement class/type settings. See note 1825187.

5 - The sales order is not displayed on MD04.

Transaction MD04 reads the sales order requirements from tables VBBE or VBBS. If there is no requirements for the sales order on those tables, nothing will be displayed and this is very often related to the sales order requirement class/type settings. See note 207942 for more details.

See also the following document for more frequent issues on MD04:

http://scn.sap.com/docs/DOC-49467