Hi All,

I am going to share you the new functionality which is available from EHP4.

Business function: LOG_MM_MAA_1 – Multiple account assignment with valuated GR

Features of this function:

Prerequisite:

Business function: LOG_MM_MAA_1 must be activated.T-code: SFW5

Configuration:

No specific configuration required .Ensure Account assignment category has amount based distribution. Distribution by amount comes only if the basic function LOG_MM_MAA_1 activated in the system.

Transactional flow:

     1.     Creation of Purchase requisition with amount based distribution

GR non-valuatedmust be not flagged at valuation tab.

   2.     Create PO with reference to PR

If PO created without reference distribution can be allocated at PO level either quantity or percentage or amount based as per the requirement.

GR non-valuatedmust be not flagged at Delivery tab for PO without reference in order to post valuated Goods receipt.

     3.     Goods receipt with reference to PO

Accounting document created with multiple accounts

     4.     Invoice receipt with reference to PO

Accounting document created with multiple GR/IR accounts

Distributing delivery costs to multiple accounts:

     1. Create PO with planned delivery cost .Distribution required only for net price not for PDC

     2. GRN for the PO

Delivery costs distributed to relevant cost objects as per the distribution mentioned in the PO for the main item.

Constraints:

     1.    For delivery costs with multiple account assignment, you cannot run GR based invoice verification

     2.    You cannot use multiple account assignment in stock transport orders

     3.    Valuated goods receipts with multiple account assignments are not supported in the subcontracting process.

     4.    Valuated goods receipts with multiple account assignments are not supported into blocked stock (movement type 107) or from blocked stock (movement type 109).

Reference:

SAP EHP4 release notes.

Business Case :

We have various business procurement scenarios where the deliveries are done by the supplier not till the plant but at intermediate locations or ex-works or till port, for eg., there are various Inco-terms where the material is not delivered till the plant, like - EXW, FCA, CPT, DAT etc.  and the delivery from Inco term location till the warehouse or Plant is managed by the Customer himself.

So the business requirement is to manage the lead time at the point of Inco term location i.e., Planned Vs actual delivery at the Intermediate location as illustrated below in the picture -

Current SAP Functionality:

Current SAP functionality only allows to manage the total lead time from supplier till the Plant for planning purpose in PDT (Planned Delivery time) field in Purchasing Info Record and Material master.

GAP in current SAP Functionality:

There is nowhere in the system that the Planned and actual delivery date at Inco term location can be recorded in the system, hence the vendor is not informed about the Delivery date at the intermediate location, instead the delivery date at the Plant is communicated to the vendor which is calculated based on the PDT in Info Record, where as vendor is supplying material only till the intermediate location, hence there is always a state of confusion till the Planner informs the supplier manually.

Looking into the business case, it looks pretty standard requirement; however while checking in standard SAP functionality, we do not find any standard solution available around this requirement. 

We even tried to explore Event Management, a new functionality from SAP if this could be an alternative to meet the objective of managing the Lead time at Inco term location, however  we were made to understand that this is also not the standard functionality available in EM and it cannot be used for this requirement.

Proposed solution :

Since there is no standard solution available, so we have proposed the following customized solution to manage the Lead time at Inco term location and hence evaluate the Vendor performance more accurately.

A) Proposed Master data changes -

1)   In the current SAP set up we are managing the total lead time from supplier till the Plant in Material Master and Info Record, as this time is being used for planning purpose.

2)   Instead of total lead time maintained in PDT in Purchasing Info Record, maintain only the Lead time from Vendor till the point of Inco term location (SLT – Supplier Lead time).

B) Managing the Lead time from Inco term location till the Plant -

1)   We have an idea to maintain the lead time from Inco term location till the plant in the new customized field in Purchasing Info Record (PIR), however SAP has not provided any user exit to create a new field, so we had no choice but to build a Z-Table with respect to Plant/ Incoterms/ Location and manage Lead time from Inco term location till the Plant (CLT – Customer Lead Time)

C) How the Planning will be managed -

1)   During the Planning run the Purchase Requisition will be created with the delivery date calculated based on the PDT i.e, Supplier Lead time from Purchasing Info Record.

2)   During the conversion of this P.Req to Purchase order, the user exit need to be enabled to calculate the delivery date  = PO creation date + SLT (in PIR) + CLT (in Z-Table), so no impact on planning as MD04 continues to show the delivery date from PO.

3)   Even during manual creation of PO the above user exit shall be called to calculate the delivery date. The delivery date in PO shall be marked as greyed out since no change on this date is allowed.

4)   Create a new customized field in Purchase order at Item level to show the Planned delivery date at Inco term location = PO creation date + SLT.  In case there is a need to manually the change the delivery date in PO, planner is suppose to change only the SLT in PO and accordingly the delivery date shall be re-calculated.

5)   The planned delivery date at Inco term location shall be printed in the PO form which is send to supplier, so supplier is correctly informed of the delivery date at the required intermediate location so no confusion to the supplier.

6)   Successive Vendor confirmations can be entered in the PO manually by the Planner or may be automated via IDOC type - ORDRSP.

7)   Inbound delivery is created based on the final confirmed date of delivery from vendor and this date will be reflected in MD04, hence no impact on the planning.

D) Vendor Evaluation -

1)   Vendor evaluation shall be done comparing the planned delivery date in the PO (created as a new field in PO) with the actual GR date at Incoterm location in Inbound Delivery.

2)   This comparison of Planned Vs actual delivery date at Inco term location would give the accurate vendor evaluation having all the dates recorded in the system.

3)   In a further automated process, it can be attempted to create the Inbound delivery via IDOC type – DESADV to capture the actual delivery date based on the confirmation send by supplier.

Expectations from this document :

1)   This document is an intended approach to meet the specific business requirement which is not an available solution in standard SAP.  The proposed solution is still under development stage and the final solution is yet to be tested end to end.

2)   This document is also intended to help all other SAP community having the similar requirement can implement the similar solution.

3)   This document is also having an expected intention to SAP that they should look around developing the standard solution as this seems to be quite a standard requirement and the solution can be implemented as a more standard functionality rather than having a complex customized solution.

Business Case:

We have  a business requirement to have two payment term in external Procurement where same vendor is supplying regular materials as well as consignment Material.

Liability is raised as soon as Material is received by receiving site in case of regular procurement of Material but liability in case of consignment procurement is only booked when Material is consumed. So payment duration to vendor in both case will be different, demanding two different payment term for same vendor.

Payment term in Purchase Order is defaulted from vendor Master purchasing view where We can have only one payment term in vendor master purchasing view.

Business requirement is different payment term should default during payment without any development.

Proposed Solution:

As we know that consignment liability is booked via MRKO transaction where system does not refer to consignment PO but consumption Material Document and liability for normal procurement is booked via MIRO transaction where PO is generally referred as reference document. So Payment term in MIRO will flow from PO and Payment term in PO will come from vendor master Purchasing view so we will maintain payment term applicable to normal procurement in vendor master Purchasing view. But Payment term applicable to consignment procurement will not fetch from vendor master Purchasing view as system does not refer PO during MRKO and accounting document is created during settlement so payment term will be taken from accounting view of vendor master  so consignment related payment term will be maintained there.

Process Involved:

I will demonstrate one consignment procurement process as well as one normalprocurement process followed by booking of liabilities via MRKO and MIRO
transaction where payment term will play its role.

Pre-requisite: There should be all master data in well placed before we create external procurement document-Contract/Purchase Order. There are following master data needs to be maintained.

1. Material Master: All required views are to be maintained in Material master.
2. Vendor master: We need to maintain purchasing as well as Finance view. Payment term applicable to consignment
   procurement needs to be maintained under FI view and payment term applicable to all normal procurements will be maintained under purchasing view.
3. Purchase Info Record: We need to maintain standard as well as consignment PIR
4. Source List: We need to maintain condition record for source list if provision for source list has been maintained in configuration and material master

              We have maintained payment term N0 for consignment and N60 for Normal PO in vendor master in accounting and purchasing view respectively

Now we will create 2 PO- one for consignment and one for normal Procurement. We will see that Payment term in PO always
comes from vendor master purchasing view. Post PO, we will consume the material
for consignment process followed by MRKO and will run MIRO for normal PO. System should fetch payment term as N60 in MIRO and N0 in MRKO.

Creation of Consignment PO:

Settlement of consignment PO via MRKO:

Now run MRKO to book liability based on consumption for consignment procurement

So we can see that settlement has not been done. Now we shall run MRKO again and select settlement option to settle consignment liabilities.

So we can see that Payment term N0 has defaulted in accounting document which was expected.

Now we shall see process for Normal procurement.

Creation of PO:

Payment term N60 has defaulted from vendor master purchasing view in Purchase order. Now we shall book liabilities on company for material received from vendor. System should fetch payment term as N60 which has appeared in purchase order which is different from consignment payment Term.

So we can see that N60 payment term is appearing in MIRO document as well as accounting document which was requirement of business.

• The following discussion provides the steps for creating a custom field on table EKKO and populating the field using IDoc Message PURCONTRACT_CREATE.  The IDoc interface calls a BAPI (BAPI_CONTRACT_CREATE) to create the purchasing document.

This procedure includes steps for creating the custom field and populating it using the IDoc interface.  Assumption is that you are already familiar with creating IDocs.  The technique outlined below requires no custom programming using BAPI methods to populate the field; populating segment E1BPPAREX is sufficient. The instructions are based on an ECC 605 Support Pack 6 instance.

Extend structure BAPI_TE_MEOUTHEADER

• Execute transaction SE11, input Data type = BAPI_TE_MEOUTHEADER, click Display
• Double-click on CI_EKKODB, and confirm that you want to create the structure
• Provide a Short Description, such as "Include table CI_EKKODB - Header"
• Add fields as necessary.  There are restrictions on the allowed data types that are supported by function module BAPI_CONTRACT_CREATE.  For example, CHAR is allowed but packed fields are supported only with further development by BADI.  Consult the documentation for this BAPI as well as OSS notes on the function module
• Save and activate the structure

When you view BAPI_TE_MEOUTHEADER, result will be a structure where first 10 positions are reserved for Component = NUMBER, followed by the set of fields you defined

Extend structure BAPI_TE_MEOUTHEADERX

• Execute transaction SE11, input Data type = BAPI_TE_MEOUTHEADERX, click Display
• Double-click on CI_EKKODBX, and confirm that you want to create the structure
• Provide a Short Description, such as "Include table CI_EKKODBX - Header Change Parameter"
• Click Predefined Type button
• Add fields with the identical names, and in the identical sequence, as you did for BAPI_TE_MEOUTHEADER. For each field, choose Typing Method 1, Data Type CHAR, length 1
• Save and activate the structure

When you view BAPI_TE_MEOUTHEADERX, result will be a structure where first 10 positions are reserved for Component = NUMBER, followed by the set of fields you defined

Set up Partner

• Execute transaction WE20
• Create a partner per the particular requirements of your environment, and specifically with Message type = PURCONTRACT_CREATE and Process code = BAPI

Create Idoc

• Create an IDoc using an external application, or using transaction WE19
• Populate the control record per your system's requirements, in particular setting Message type = PURCONTRACT_CREATE
• Populate the other data records per your requirement sufficient to satisfy mandatory fields and optional fields used in your environment
• Populate two consecutive instances of segment E1BPPAREX
• First instance, set STRUCTURE = "BAPI_TE_MEOUTHEADER" (without the quotes). Set VALUEPART1 = concatenated set of data values.  For example, suppose you created three custom character fields of varying lengths: ZFIELD1 (10), ZFIELD2 (25), ZFIELD3 (1).  You would set the value of VALUEPART1 as ten characters of blank spaces, followed by 10 characters of data, followed by 25 characters, followed by 1 character.  You have to set the first 10 characters as blanks to accommodate the NUMBER field in the BAPI_TE_MEOUTHEADER structure
• Second instance, set STRUCTURE = "BAPI_TE_MEOUTHEADERX" (without the quotes).  For VALUEPART1, first ten characters are blank spaces, followed by as many character "X" values as you have custom fields.  If you have three custom fields, then VALUEPART1 will have ten spaces followed by "XXX" (without the quotes, of course)

Execute the interface

Post the IDoc.  Result should be a contract where table EKKO has data values in the custom fields you created in CI_EKKODB

The input help (F4 help) is a standard function. Users can display list of all possible values for a screen field with the input help.

This search help is designed using combination of collective and elementary search helps.

This attached document illustrates search help for material, by doing this Business can view the stock available in Quality as well as unrestricted while creating PR/PO.

Procedural Steps :

1. Decide fields required in search help.

2.Identify corresponding database tables from  where these fields  can  be retrieved.

3.Create  Database View using  above mentioned tables and fields.

4.Create Elementary Search help using above view.

5.Maintain Search Help and parameter Assignment.

6.Check   whether new Search   help appears in any transaction where material field is present.

Step : 1 Below are the fields considered for material search help with[Stock]

1.  LABST [Valuated Unrestricted- Stock]

2.  MATNR [Material Number]

3.  WERKS [Plant]

4.  INSME [Stock in Quality Inspection]

5.  MAKTX [Material Description (Short Text)]

6.  LVORM [Flag Material for Deletion at Storage Location Level]

7.  SPRAS [Language Key]

The  above mentioned  fields are available in MARD and MAKT.

Step : 2Create Data base view using above mentioned tables and fields.

Now go to T-Code SE11and specify a view name and click on create button as shown below.

Enter the name [Z_MAT_STOCK_VIEW]  and click the create icon.

Select the database view and click copy tab.

Now enter the short description for the view. In table/Join Conditions Tab, Specify the tables MARD and MAKT.  And also mention the table joins conditions as below.

Since the material description is not available in one of the table’s referred, it’s necessary to make a join condition. Common fields of the table are MATNR.

In view field tab specify the fields required.

In the selection conditions tab specify the following.

Here  in the above  screen  WERKS equal to plants[For Example : 0001,0002] as shown above.

In Maint. Status tab specify-Access Read  only  and “Display/Maintenance allowed with Restrictions” Save this view. Assign correct package.

Check and Activate.

Step  4: Create  elementary search  help using  the  above  view, now go  to transaction SE11 and specify  the
search  help  name [Z_MAT_STOCK_VIEW_1]and click on create icon.

Now click on the create icon.

Specify short description for this search help.  This description will appear as heading of the tab in collective
search for material. Specify view Z_MAT_STOCK_VIEW as Selection method. Specify “dialog with
value restriction “in Dialog type.

Specify   Search   help   parameters using   Z_MAT_STOCK_VIEW_1   view fields.

LVORM and SPARS default values are given as X [Deletion flag marked] and language EN.

Check all search help parameters with IMP (Import).

Check MATNR search help parameters with EXP (Export).

Specify  position in List and  Search areas.(for ex: give  1,2,3,4,5 in both  the columns).

Save and Activate.

Assign  the correct package.

Step 4: Maintain Search Help and parameter Assignment

SPRO    Logistics  
General   Material    Master     Tools    Maintain    Search Helps

Select maintain in Logon Lang

 

Now
select the included search helps
tab.

Now select the included search helps tab.

Now select a row and click on insert row icon, and specify the search help view we have created in
the previous step.

Now click on parameter assignment tab and click enter.

Finally save and activate.

Step 5: Check whether the new  material search  help  appears in transaction where material field is present.

Note: This material search  help will be applicable on all transactions where material search  field is there.

GO to Transaction MM03 to check the output.

Here  in the  above  screen  in unrestricted am giving 50, which will display all the material with stock level of 50 in unrestricted stock.

This document explains how integration between material management and funds management takes place in SAP, also includes SRM integration in a standalone. classic and extended classic scenarios.

1.    Introduction to Funds management.

Fund Management module related to creation and management of budgets. The goal of Fund Management is to budget all revenues and expenditures of cost and revenue elements, and to limit transactions for those elements withing the allocated budget.

The Fund Management module is integrated with other SAP modules. The basic requirement is to integration Funds Management with General Ledger Accounting component. Funds Management can also  be integrated withs Materials Management so that the procurement process of non-productive items can be controlled from creation of purchase requisition to creation of invoice. Integration ensures that the transactional data flows to Fund Management without the need for entering the data again in funds management.

The Organizational unit for Fund Management is the Financial Management Area (FM area).To be able to take advantage of the integration, FM area must be linked to other organizational units.  When a Financial Accounting document is assigned to Fund Management assignment objects such as Commitment item and Fund Center the system has to determine the FM area so that the data is recorded in the Fund Management.  For this reason we need to specify how the FM area is determined.

2.    Intergration with MM

Transactions carried out in Materials Management are updated in Funds Management.

The following activities are recorderd in Funds Management:

Assignment of FM area to Plant and Purchase Org

FM Areas are not directly assigned to any Plant or Purchase Org, FM areas are assigned to company codes and then the Plant or Purchase Org is assigned to the company code

SAP Customizing Implementation Guide > Enterprise Structure > Assignment > Financial Accounting > Assign company code to financial management area

SAP Customizing Implementation Guide > Enterprise Structure > Assignment  > Logistics – General > Assign plant to company code

OR

SAP Customizing Implementation Guide > Enterprise Structure > Assignment > Materials Management

> Assign purchasing organization to company code

When transactional data is posted in other modules, such as Materials Management and Financial Accounting , the system passes on the data to Funds Management (FM). The actual data is updated in FM and can be displayed in the information system.

In configuration it can be defined whether the goods receipt should be included in Funds Management, the process for display of tax, the currency type to be used for currency integration and whether sales orders are to be updated in FM ro not

GR/IR Updating

If  Goods Receipt is chosen, the actual data is displayed in Invoice column in the information system, per the goods receipt date.

If  Invoice Receipt is chosen, the actual data is displayed in the Invoice column in the information system, per the invoice receipt date.

Price differences while posting the GR or IR are also included.

Tax Display

If you choose Net, the information system on the commitment item shows no value added tax but only the net tax.

Funds are committed based on the delivery date of the item.  For example if the PRn is created in May, but the delivery date of the Goods or Services is in July, the funds will not be committed in the current fiscal year, but will be committed in the next fiscal year (assuming the fiscal year runs from April to March).

3.    Integration with SRM

Like MM SRM system can also be integrated with funds management. Commitment postings are done in real time. All changes that are made to the shopping cart data or the creation of follow-on documents lead to the direct adjustment of the commitment. For other purchasing documents, such as RFxs or auctions or contracts, no funds are committed in the system. Multiple account assignment is supported and leads to the commitments being split according to the percentage or value distribution among the different account assignment objects.

Supported scenarios:

·    SRM standalone scenario

·    SRM classic scenario

·    SRM extended classic scenario (ECS)

All of the shopping cart item types are supported:

• Standard items
• Limit items
• Service items
• Catolog items

Budget check in three types of setup of SRM –

Standalone scenario:

A commitment is only simulated in the shopping cart at the time of ordering it, with the amount in the PR the budget is checked with the backend using a RFC. No commitment is written to the system. After the purchase order is posted in the SRM system, the commitment is created in the backend system using an IDOC. If you change, delete or edit the PO in ways related to funds management, a new IDOC is sent back to the SRM system. This IDOC however only contains the difference from the old commitment.

Extended Classic scenario

In the extended classic scenario there is only a little difference from the Standalone scenario when you are creating the shopping cart. That is, with the SC amount the budget is checked online using a RFC to ECC system. No commitment is written to the system however. A copy of the local purchase order is first is transferred to the back end when you post a purchase order, this when the commitment posting takes place. This is done by calling the BAPI_PO_CREATE1 or BAPI_PO_CHANGE BAPI. If the invoice is entered in the ECC system,then the reduction of the commitment values is carried out within the ECC system.

Classic scenario

As the case with the Standalone scenario, a commitment is again only simulated in the SRM system, that is, the budget is checked using a RFC, but no commitment is written to the database. After the shopping cart is saved, the commitment is transferred to the back end (ECC system). A commitment is created depending on the setting in the back end, either as a purchase requisition commitment or a purchase order commitment. All further movement of the commitment occurs in the back end with the subsequent GR and IR.

4.    Flow of commitment in a MM cycle

Business transactions posted in Materials Management are updated in Funds Management (FM). The recording of the flow of funds depending on customizing and the following factors.

Irrelevant postings

If no budget-relevant update is wanted, it can be configured that the update only takes place statistically in Funds Management for purchase requisitions and purchase orders without account assignments (these are purchase requisitions and purchase orders in which no account assignment category was specified) and for the goods issue. This can be done in the settings in Customizing and by assigning a statistical commitment item for the warehouse stock account.

Value based or quantity bases commitments

The Value-based commitment indicator can be set in SAP NetWeaver > General Settings > Check Units of Measurement.

This indicator decides whether commitments for this unit of measurement are recorded on a quantity basis or a value basis. If this indicator is not set then then the commitments are recorder on a quantity basis but if it is set then they are managed on a value basis. For value-based updates, the transfer of purchase order commitments takes place on the value of goods receipt or invoice. For quantity-based updates, the transfer of purchase order commitments takes place on quanity of the goods receipt or invoice .

For example

• The PO is created with net value 500 Euros and 10 PC, i.e. each item of 50 Euros
• A valuated GR is posted with a value 450 Euros and 10 PC, valuing each item at 45 Euros only
• For value-based transfer, an amount of 450 Euros is tranferred from the commitment to actual.
• For quantity-based updates, the entire amount of  500  Euros is updated as the quantity delivered is still 10 PC.

(PR's commitment in Funds Management are always transferred by quantity from PR to PO).

Parked Documents

Parked documents are only updated if they have the status “Complete”. Parked documents having reference to a PO or funds reservation are not updated in the Funds management.

Sample Cycles

Whenever funds management is active budget is normally allocated to a cost center or real internal order for a fiscal year. In the MM cycle it moves through various stages for each material document created. Let us see the flow for a few typical scenarios, taking an example of an internal order IO00000111 with a total budget of 1000 Euros for a fiscal year, the value of the SC or PR is 500 Euros and quantity is 1 PC.

Note: These can be checked in the system with the T Code - S_ALR_87013019

Scenario A: PO, GR and IR created of the entire value, GR Valuated

1. When a    shopping cart or Purchase Requisition is created

The total value of the SC or PR is added against the commitment when the SC or PR is created and released. 

2. When the PO is created

The commitment is transferred from the PR to the PO but it is still shown as commitment, however a new PR can only be of the value of 500 Euros or less as the funds are still committed to this PO

Note that purchase orders for which the Return item indicator is set are not updated in Funds Management

3. When the GR is created

Now the GR is created the value is no longer fictional but becomes an actual expense so the value is transferred from Commitment to Actual (note that GR is valuated in this scenario)

4. When the IR is created

When the IR is done the commitment stays intact as the funds were already updated as part of the GR creation.

Scenario B: PO, GR and IR created for part of the entire value, GR Non-Valuated

1. When a    shopping cart or Purchase Requisition is created

The total value of the SC or PR is added against the commitment when the SC or PR is created and released.

2. When the PO is created

Let us assume the value of the PO is changed to 300 Euros but quantity is 1 PC, so the entire PR is consumed. The commitment is transferred from the PR to the PO but it is still shown as commitment, a new PR can now be of the value of 700 Euros or less as the funds committed to this PO have changed

Note that purchase orders for which the Return item indicator is set are not updated in Funds Management

3. When the GR is created

Now the GR is created but the GR is non-valuated so the funds are still committed and not consumed so no transfer takes place from Commitment to Actual

4. When the IR is created

When the IR is done the commitment moves from the commitment to the actual funds consumed. This is due the fact that the financial documents are only posted at the time of IR creation

Scenario C: PO, GR and IR created for part of the entire quantity, GR Valuated

1. When a    shopping cart or Purchase Requisition is created

The total value of the SC or PR is added against the commitment when the SC or PR is created and released.

2. When the PO is created

Let us assume the value of the PO is unchanged as 500 Euros but quantity is only 0.5 PC, so the entire PR is not consumed. The commitment is transferred from the PR partially to the PO but it is still shown as commitment, a new PR can only be of the value of 500 Euros or less as the total funds committed to this PO and PR are unchanged

Note that purchase orders for which the Return item indicator is set are not updated in Funds Management

3. When the GR is created

Now the GR is created of .25 PC and the GR is valuated so part of the funds are still committed and part of it are consumed, so a transfer takes place from Commitment to Actual

4. Delivery Completed indicator is ticked in the PO

When the final delivery is ticked the system now takes that no more deliveries are expected on the PO and the remaining quantity will not be consumed, so the system releases back that amount to the available funds, the funds released will be for ordered but not delivered quantity .25 PC so the funds released will equal 0.25 X 500 = 125 Euros. Checking the final delivery indicator in the SRM confirmation or delivery completed indicator in the GR at the time of posting has the same effect

5. When the PR is closed or deleted

Closing the PR by checking the closed indicator will also release the funds allocated to it, in our example the unordered quantity is 0.5 PC, so funds equal to 0.5 X 500 = 250 Euros will be released back to the available funds. Deleting the PR will also have the same effect in the commitments

6. When the IR is created

When the IR is done the commitment stays intact as the funds were already updated as part of the GR creation.

These three scenarios cover most of the possible situations in MM cycle.

Summary:

This document provides an overview of cost optimization through real time stock status update of raw materials from SAP to MES (Manufacturing Execution Systems), stock status in MES is referred by production floor personnel before consuming the stock in production.

Introduction:

Automationof production process and effective inventory management are two important factors in manufacturing industry. These two factors have high cost proportion in supply chain and this can be optimized in various ways. In a scenario where stock status of warehouse managed inventory is referred in MES before consumption in production, real time stock status information flow from SAP to MES leads to low cost and high quality of finished goods.   

To overcome this challenge SAP IDoc interface can be designed to send real time inventory and stock status report from SAP to MES. This interface would send records of relevant Transfer Order items to MES system at time of transfer order creation through IDocs. This will update the inventory and status of stock available in MES for production consumption.

Integrated Solution Approach:

IDoc triggering functionality is enabled through standard SAP configuration and it is further enhanced to control the field values passing to external system through ABAP development. Data between two systems is transferred through SAP IDocs. IDoc triggered through standard SAP configuration is having standard segments which store transfer order header and item data. You can add additional segment to pass field not available in standard segment.

            Any external system referred in production needs information of initial inventory created in SAP and any further change in stock status. Standard SAP configuration controls IDoc trigger functionality for relevant inventory movement types.

System Landscape:

SAP NetWeaver provides the seamless integration to support the communication between different systems through IDocs. Below diagram explains basic system integration model:

As explained above, there is unidirectional information flow between SAP and MES through standard SAP IDocs.

Below two business process flows depict IDoc interface design for inventory creation and stock status change with different filter criteria.

Inventory Creation:

Real time stock availability report provides better visibility of inventory in stock for consumption which leads to low stock level and high cost saving. Standard SAP provides option to control the data transfer with parameters like warehouse number, source storage type, destination storage type and movement type. For any additional control parameters enhancement needs to be done in existing program. Below business process flow explains the interface design for transmitting inventory creation information from SAP to MES with different control parameters:

ABAP enhancement is required to restrict IDoc transmission specific to warehouse and material type in scope  . For inventory creation, configuration can be maintained in OMKY to include storage type and movement type in scope. Once the GR document is posted IDoc gets triggered at the time of Transfer Order creation and same information is passed to MES system.

Stock Status Change:

As shop floor personnel refers the stock status in MES system without the visibility of current status of material inventory on shop floor there is risk of consuming rejected inventory in production.

            Transmission of real time stock status information enable the supervisor to use the inventory with correct stock status and reduce the number of defective products. Below business process flow explains the interface design for stock status change information transmission from SAP to MES with different control parameters:

Configuration to trigger IDoc would be done in OMKY where you can maintain source and destination storage types, relevant inventory movement types for stock status change and destination system. All other parameters can be controlled through ABAP enhancement.

On production floor organizations use MES system and initial stock status information is stored in SAP. In such a close integrated production scenario transferring real time data is always important and challenging. This interface helps to transfer the real time stock status information from SAP to MES that increase the quality and reduce the cost of manufactured goods.

Table of Content

1........... Preface

Definition

Prerequisites

2........... Purpose

3........... Graphic visualization

4........... Customizing

4.1......... Organizational Structure

4.1.1...... Define Company

4.1.2...... Create Company Code

4.1.3...... Create Controlling Area

4.1.4...... Create FM Area

4.1.5...... Assign Company Code to Company

4.1.6...... Assign Company Code to Controlling Area

4.1.7...... Assign Company Code to FM Area

4.1.8...... Activate FM

4.1.9...... Define Plant

4.1.10.... Assign Plant to Company Code

4.1.11.... Maintain Purchasing Organization

4.1.12.... Assign Purchasing Organization to Plant

4.2......... G/L Account Settings

4.2.1...... Copy Chart of Accounts

4.2.2...... Copy Company Code

4.3......... Field Settings

4.4......... Create Fund Center in FM Area

4.5......... Create Commitment Item

4.6......... Create Fund

4.7......... Set-up Workflow

4.2.3...... Activation of Triggering Events for Workflow

4.2.4...... Assigning Processor

5........... Master Data

6........... Function/Process/Scenario Description

Process Overview Table

Term Definitions

7........... Process Steps

7.1......... Create Purchase Requisition

7.2......... Check Workflow

7.3......... Change Purchase Requisition

7.4......... Create Purchase Order

7.5......... Check Workflow

7.6......... Change Purchase Order

1. Preface

Definition

The purpose of the Test Specification is to describe process Park and Hold in Purchasing Documents applicable from 605 releases onwards.

The Test Specification

• Based on a business scenario and, thus, covers processes and process steps across any number of R3 application components.
• Describes the configuration settings that need to be made during implementation in each of the components of the business scenario.
• Lists the order in which configuration steps need to be made, and their interdependencies.
• Covers the setup of master data required for the test
• Lists all process steps to be performed during test execution

Prerequisites

The Business Functions required are

• LOG_MM_CI_3 for MM

2. Purpose

The purpose of this document is to describe the general test steps required to run up the Park and Hold scenario within any system above 605 releases.

The different roles in a Company the Purchasing Clerk and Accounting Clerk one after another may complete the Procurement documents. The order of data they fill the status they set, the workflow items that get triggered are all in the purview of this test.

3. Graphic visualization

4. Customizing

4.1. Organizational Structure

4.1.1       Define Company

4.1.2       Create Company Code

Then edit the Company Code created by copying and make the necessary changes.

4.1.3       Create Controlling Area

Now maintain the details of the Controlling Area

4.1.4       Create FM Area

4.1.5       Assign Company Code to Company

4.1.6       Assign Company Code to Controlling Area

4.1.7       Assign Company Code to FM Area

4.1.8       Activate FM

4.1.9       Define Plant

4.1.10    Assign Plant to Company Code

4.1.11    Maintain Purchasing Organization

4.1.12    Assign Purchasing Organization to Plant

4.2. G/L Account Settings

4.2.1     Copy Chart of Accounts

4.2.2     Copy Company Code

4.3. Field Settings

4.4. Create Fund Center in FM Area

4.5. Create Commitment Item

4.6. Create Fund

4.7. Set-up Workflow

4.7.1     Activation of Triggering Events for Workflow

This has to be done one time per system and client

• Start transaction SWDD
• For PR: Enter Workflow WS31000014
  For PO: Enter Workflow WS31000013 in the corresponding entry-field
• Within the Menu bar choose GOTO->Basic Data
• Choose tab-strip “Start Events”

4.7.2     Assigning Processor

This has to be done for every tester

• Start Transaction SWDD
• For PR: Enter Workflow WS31000014
  For PO: Enter Workflow WS31000013 in the corresponding entry-field
• Within the navigation areas choose “Complete Purchase Requisition” for WS31000014 or “Complete Purchase Order” for WS31000013.
• Within the “Control” tab under header-line “task properties” click icon “Agent Assignment”

A new Transaction will be started.

• Press button “Create agent assignment”
• Choose “User” on the following popup
• Enter the testers user here

5. Master Data

The following Master Data will be required and created during this test case:

6. Function/Process/Scenario Description

Process Overview Table

Term Definitions

Holding:

A document on hold can contain a lot of errors from MM-side as well as from FM-side. This document is not intended to be available for any follow-up process.

Parking:

This document is free of errors from MM-side and intended to be available for follow up processes. Only some open points regarding funds management have to be solved. Afterwards this document can be completely saved.

MM-errors:

These kind of errors are all errors coming from the columns within the items of a purchase requisition or a purchase order.

FM-errors:

These errors are coming from the funds management. FM-errors are only triggered by the commitment availability checks.

• Fund
• Grant
• Commitment item

All other fields are only able to represent MM-errors.

7. Process Steps

7.1. Create Purchase Requisition

7.1.1         Create a Purchase Requisition with details like Account Assignment, Material, Material Group, Purchasing Group, Plant and Quantity.

7.1.2         Hold the document.

7.1.3         Check if any other errors are populating the item level. Resolve the errors

7.1.4         Park the document

7.2. Check Workflow

7.2.1         Go to transaction SBWP

7.2.2         Navigate from Inbox --> Workflow

7.2.3         Check the existence of the work-item for the above created Purchase Requisition

7.3. Change Purchase Requisition

7.3.1         Open the Purchase Requisition created above in change mode

7.3.2         Complete the FM related data as created from the Customizing above

7.3.3         Check the document – No errors would be found

7.3.4         You can now Save the document

7.3.5         Following which the work item would be deleted by the system from the SAP Business Workplace

7.4. Create Purchase Order

7.4.1           Create a Purchase Order with details like Vendor, Organization, Account Assignment, Material, Material Group, Purchasing Group, Plant, Quantity and Net Price.

7.4.2           Hold the document.

7.4.3           Check if any other errors are populating the item level. Resolve the errors

7.4.4           Park the document

7.5. Check Workflow

7.5.1           Go to transaction SBWP

7.5.2           Navigate from Inbox --> Workflow

7.5.3           Check the existence of the work-item for the above created Purchase Order

7.6. Change Purchase Order

7.6.1           Open the Purchase Order created above in change mode

7.6.2           Complete the FM related data as created from the Customizing above

7.6.3           Check the document – No errors would be found

7.6.4           You can now Save the document

7.6.5           Following which the work item would be deleted by the system from the SAP Business Workplace

Additional Tests– You can additionally check if the different status are possible and their effects with the Accounting Document

Hold, Park and Save are the 3 statuses from lowest to highest. A document can be kept in the same status despite the changes made to it or can progress to any of the upper statues. There is no option for a document to move lower in status once set.

Introduction

A Purchasing Info Record holds a very important place in the 'Procure to Pay' cycle. It contains information about a specific material and a vendor supplying that material. The various conditions maintained in a PIR enables one to store pricing stipulations agreed with the vendor. Whatever conditions are maintained in the PIR for a specific material - vendor combination, those flow into the PO and subsequently into the Invoices.

However, in some business scenarios, this main vendor might take the help of few other vendors as well to provide the finished product to the customer. Let us take an example of a typical automobile company.

Current Scenario

The factory (or the main vendor) produces the standard vehicle with chassis, engine etc. but for seats, music system etc., it gives the vehicle to other vendor. Now, during the invoicing, each of these two vendors need to get their individual invoices.

Challenge

How can we generate invoices for multiple vendors using one single PIR and one single PO?

Detailed Solution Design and Process Flow

The solution to solve this challenge lies in the Purchasing Info Record. While adding supplementary conditions in the PIR, some extra information can be added for each of them under the ‘Details’ button.

Let us go through this step by step:

Step 1. Create a PIR using tCode – ME11. The main vendor 112654 is entered in the screenshot shown below:

Step 2. Enter the Supplementary Conditions inside the Base Conditions

Under the base condition ZENP, supplementary conditions are inserted eg. ZMRF, ZKNO etc. as can be seen in the following screenshot.

Step 3. Enter the details for each of the Supplementary conditions (Cond. Category: Delivery Costs). Select the Supplementary Condition, say ZMRF in this case. Click F6 to get into ‘Details’ for this supplementary condition.

Step 4: The last ‘Control’ field under the ‘Details’ for each of the supplementary conditions is for ‘Vendor’. This field value uniquely identifies the vendor or creditor in the SAP system. In the shown example, a vendor 119157 , different from the main vendor 112654, is maintained for Supplementary condition ZMRF. Similarly, for condition ZINT, a vendor 113711 is chosen in the PIR.

Step 5: Now the PIR is ready to be used in the PO. These conditions will flow in to the PO as seen below (tCode: ME23N):

Step 6: This PO now consists of Conditions which have of prices from different vendors. There is one main vendor, 112654 in this case. And then, there are other vendors for supplementary conditions, eg. 119157 for ZMRF condition.

During invoicing (tCode MIRO), SAP would give an option and ask for the particular vendor for which we want to generate the invoice.

Enter the Invoice Date and Reference PO.

Select the Item Type as ‘2 Planned Delivery Costs’. Click on the arrow for ‘More Allocation Criteria’.

Step 7: Choose the appropriate vendor. For Condition ZMRF, we will select Vendor 119157 and click on ‘Continue’. Similarly, if we would have wanted to invoice for Condition ZINT, we would have selected Vendor 113711 in MIRO.

The vendor 119157 gets selected and the corresponding ZMRF condition flows into the Invoice Doc.

There are several other conditions shown in the above screenshot for vendor 119157. This is because for all of them, the vendor 119157 has been maintained in the PIR.

So this is how, invoices to multiple vendors can be generated from the same PO and the same PIR - by maintaining a vendor for the individual condition type in the PIR.

Introduction:  Vendor consignment process in SAP-MM is a special kind of external procurement process. Consignment order is placed to external vendor who delivers the materials at company premises on a given schedule but ownership will remain with vendor. In normal procurement, liabilities to company is booked as soon as good is received by company but liabilities to company is only booked in case of consignment process when actual goods are consumed.

In  normal consignment process, company has to keep on placing the order against any increase in demand or any future forecast which is very time consuming process to place the PO every time.

This document will explain about How we can set up a process where vendor can take care of  complete Management of consignment inventory. Vendor will have complete responsibility to ensure availability of stock. Company will place only one time PO for 1 year. Vendor will take care of all further requirement without any further PO even if demands are raised more than PO qty.

Company will place a consignment PO of lump-sum  qty for complete year based on historical consumption data. Vendor will plan for delivery based on requirement on daily basis unlike normal consignment process where complete lot is delivered at company process.

We will have to set up some configuration and master data to dispatch current stock and future demand information to vendor on daily basis so that vendor is updated about current stock and replenishment needed to meet the demand.

This process will have following benefit:

1) Lower Inventory level

2) Less over head

3) Lower Inventory handling cost

4) Vendor will have better information about customer demand which will help vendor in planning

5) Reduced replenishment duration

Below Process has been mapped without any development. This will set up automation between  Vendor and Customer.

Process Involved: We can Understand complete process flow chart from below picture:

We can seefromthe flow, there are following steps are involved in the cycle.

1) Manual Blanket PO creation: Blanket PO is created manually with some validity and item category K. Tolerance in PO is also defined to give flexibility to vendor to adjust the delivery in case any short fall or additional demand is ascertained through PROACT message type. Tolerance limit is defined as 99.9%.

2) Purchase Order output through EDI: PO is transmitted to vendor via message type ORDERS

3) Transferring stock and sales data via EDI: Message category PROACT is used to send current stock and historical/forecast sales data for a particular material to vendor

4) Planning replenishments at vendors end: Vendor can plan replenishment qty based on current stock and future demands.

5)Confirmation from vendor side: vendor will send confirmation against delivery. A IDOC will be created with message type ORDRSP and create a line item under confirmation tab in PO.

6) Despatch Advice: When material is ready to be despatched, vendor will send  advice to customer. Information will come in the form of an incoming IDOC with message type DESADV and will create inbound delivery number against PO placed to vendor. This IBD will be updated under confirmation tab

7)Good Receipt: When material arrives at company premises, GR is done against IBD and stock will be posted with movement type 101 K and stock will be appearing under consignment stock

Configuration Involved to set up Vendor managed Consignment process:

1)Creation of output message  for PO: As PO has to be transmitted to  vendor via EDI so an output type should be created followed by maintenance of condition record so that when PO is created, system should propose an output type for EDI. It is simple to set up output type for PO so I will not touch upon configuration process. Standard output type is NEU so we can create our own message type ZNEU copying from NEU followed by NACE set up for EDI with partner type LS.

2) Setting up partner profile for EDI for message type ORDERS: We need to set up partner profile for electronic transmission.

Menu Path: SPRO-->Material Management-->Purchasing-->Messages-->EDI-->Set up Partner Profile.

We can also access it via transaction code WE20

A new screen will open where we need to maintain  Partner no and partner type.

1) Partner no-Logical .System name

2) Partner Type-LS

Once it is done, we need to maintain information for Outbound Parameter which are given below

1)  Partner Role-LS

2) Message Type-ORDERS

3) Receiving port- As defined

4) Transfer IDOC-Immediately

5) Basic Type-ORDERS05

We also need to maintain message control as listed below:

1) Application-EF

2) Message type-ZNEU (As defined above for PO)

3)Process Code-ME10

3) Setting up partner profile for PROACT message type sending to vendor: Here we also define partner no, partner type as defined above.

We need to maintain following outbound parameter:

1)  Partner Role-LS

2) Message Type-PROACT

3) Receiving port- As defined

4) Transfer IDOC-Immediately

5) Basic Type-PROACT01

Once Partner profile is maintained, we also need to maintain profile for sending stock/sales data to vendor. We can access SPRO via following path

SPRO-->MM-->Purchasing-->Messages-->EDI-->Profile for sending stock/sales data

We need to maintain control profile on screen appeared. Say XYZ profile was maintained.

We also need to maintain controlling parameter

Transfer STOCK level

  Forecast of Qty sold

Once it is done, maintain Stock Type as shown below

Stock Type-INSME

Stock type-LABST

Now Maintain Sales data Access

Qualifier-004

Info Structure-S094

Version-XXX

Plant-WERKS

Qty-MNG02

4) Version Activation for Info Structure S094: Now we need to activate version created above A00.

Access following Configuration Path

SPRO-->Integration with other MySAP.com components-->Data transfer to the SAP Business information Warehouse -->Settings for Application specific data source (PI) -->Logistics-->Managing transferInformationstructures -->Setupof Statistical data -->Application specific set up of statistical data --> Perform Set Up - Inventory Controlling

5) Set up for Message type ORDRSP for confirmation from Vendor:  Here we need to set up for incoming IDOC  in partner profile. Run We20 transaction and set up inbound parameter

Partner no-XXXX

Partner type-LS

Inbound Parameter:

Message Type-ORDRSP

Process Code-ORDR

6) Set up for Message type DESADV for Delivery Advice from Vendor: Here we need to set up partner profile for incoming IDOC for IBD against PO.

Partner no-XXXX

Partner type-LS

Inbound Parameter:

Message Type-DESADV

Process Code-DELS

Now System is ready for consignment process.

Now Create  a blanket PO for full year

When PO is Released, System will send EDI to vendor for PO information.

Now Create PROACT message to send current stock and future demand information to Vendor

Run WVM2 transaction and enter all required details

When you execute the report, System will output all stocks details as shown below

Now Click on Send IDOC button to  trigger PROACT IDOC to vendor. We can see IDOC created via WE02 transaction as shown below:

Now When Vendor sends confirmation against PO, Incoming IDOC with message type ORDRSP is received as shown below

This Information is  updated in PO under confirmation Tab as shown below. System insert AB line

Now When Delivery is ready to get dispatched, vendor sends information via DESADV message type and system create IBD and update in PO as shown

below:

Now Receive the goods against IBD

PO will be updated with IBD qty

Table of contents

1.0 Introduction to SAP Fiori

2.0 Architecture

3.0 Approve Purchase Contracts

4.0 Configuration

4.1 Pre requisite

4.2 Activate OData & UI Service in Frontend

4.3 Configuration in Backend

5.0 Demo in Fiori launchpad

6.0 SAP Help & References

1.0  Introduction to SAP Fiori

SAP Fiori is a collection of apps with a simple and rich UI experience for frequently used SAP business functions (Ex: Approve Purchase order), these apps can be accessed via HTML5 supported clients like desktop browser, Ipad etc.

Apps can be controlled through SAP Fiori Launchpad which is the central entry hub to all SAP Fiori apps, which can be governed through authorization

Launchpad is flexible and can be adapted to your needs.

2.0  Architecture

Two deployment options are available, depending upon your landscape you can choose the method which suits better.

1. Central hub deployment of SAP NetWeaver gateway

In this deployment method a separate server will be used as gateway. We will be using this method for our example

     2. Embedded deployment of SAP NetWeaver gateway

        In this deployment method gateway is installed directly in backend server.

3.0  Approve Purchase Contracts

Using this app we can approve purchase contracts. For using this app we need to have contract release strategy setup along with workflow in Backend ERP server.

Currently Fiori supports following item categories:

• Service (internal item category: 9)
• Standard (internal item category: 0)
• Material Group (internal item category: 8)

4.0  Configuration

Before we start configuration make sure user id is present in both Backend (ECC) and Frontend (Gateway) server

4.1     Pre requisite

For the app, the following software components must be available in your system landscape

4.2 Activate OData & UI Service in Frontend

Take Basis help for getting below services activated

1) Check whether OData Services: sra001_pcapproval is active or not

2) Check whether UI5 Application: MM_PC_APV is active or not.

Run transaction SICF on the front-end server. Press F8.

Path > default_ host> sap>  bc > ui5_ui5> sap> MM_PC_APV 

3. Assign below role to user in Frontend server

          SAP_MM_BCR_Buyer_X1

4.3     Configuration in Backend

     1. Assign below role to user

           Role :SAP_MM_PC_APV_APP

     2. Configure Contract release strategy

     IMG Path> MM> Purchasing> Contract > Release procedure for contracts> Define Release Procedure> Release strategy

     I am not going to cover Configuration of release strategy part in detail. You can refer to below link for configuration help.

     http://wiki.scn.sap.com/wiki/display/ERPSCM/RELEASE+PROCEDURE

After Release strategy setup, we have to configure workflow.

     3. Assign Relcode to workflow

     IMG Path> MM> Purchasing> Contract > Release procedure for contracts> Define Release Procedure> Workflow

     Select the object type user (US) and enter the user id that can approve purchasing contracts

     4. Set up a connection between the release strategy and Workflow

        IMG Path> MM> Purchasing> Contract > Release procedure for contracts> Define Release Procedure> Release codes

     5. Go to Tcode PFTC

          Select Task type > Workflow template and Enter Task 20000079 (sap standard workflow template for contract release) & Click on maintain    

Go to triggering events Tab, select Line where object type is BUS2014 and activate binding

     6. Go to Tcode SWDD.

          Enter WS20000079 in Workflow and press enter

     From Navigation Area under steps  select Release Of Contract.

     (i)On right Side Pane , enter Task TS20000172(Release of contract) under control tab &Click on  define Binding Automatically.

     (ii) Under Agents, Enter 20000029(Person responsible for contract release) & Click on  define Binding Automatically.

     (iii) Under Task properties click   Agent assignment

           And Assign User id of Person who is going to release contract as shown below.

     7. Assign Task ID in customization

      IMG Path> MM> Purchasing> Contract > Release procedure for contracts> Approve Purchase contracts App> Specify workflow task id for Approve           Purchase contracts App

Now create contract in Backend.

Go to Tcode SBWP and check whether Contracts is displaying in user inbox for approval. With this step we can confirm that our all required backend settings were in place.

5.0  Demo in Fiori

Now all backend settings are completed. Lets go to Fiori Launchpad through Web Browser

Usually URL looks something like this, you need to replace Server and Port details with your server details

http://<yourserver>:<YourPort>/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html?sap-client=001&sap-language=EN

Select Approve Purchase Contracts Tile.

We can see our Contract  list in Fiori : Approve Purchase contracts tile

Click on   in Item(s) to see more details

Click On Approve Button

we have successfully approved contract from  Fiori 

6.0  SAP Help & References

App Implementation Guide

http://help.sap.com/fiori_bs2013/helpdata/en/39/763c52b74f1b13e10000000a44176d/content.htm?frameset=/en/ad/f955526735087de10000000a445394/frameset.htm&current_toc=/en/ba/954353a531e647e10000000a441470/plain.htm&node_id=228&show_children=true#jump245

Troubleshoot Guide

http://scn.sap.com/community/mobile/blog/2013/11/13/sap-fiori-ll11--consultants-should-know-about-odata-troubleshooting

Usefull Sap notes

1937863

2028544

This is my First SCN document. please suggest if any changes to be done.,Hope you find it useful.

Regards,

Satheesh Varma

Introduction: Two process is used to optimize the picking process. Suppose, one material is being used more frequently either in Sales order or in Production order or being transfer one SLOC to Another SLOC. If frequency of picking of material is more as it is being used in multiple outbound delivery, we can use 2 steps picking to optimize the performance.

Two Steps picking are broken in to 2 steps-1) Collective picking of materials linked to all Reference documents (OBDs or TR's) 2) Allocation of materials to respective OBD/TR's

All OBD or transfer requirements are clubbed in one group and picking happens for all materials mentioned in OBD or TR clubbed in Group. A transfer order is created to pick the materials and materials are being brought to Interim Storage type 200.  Another TO is created to allocate the materials to respective OBD/TR's and materials are moved from Storage Type 200 and process is complete.

Two Step process is very efficient and improves performance of system.

This Documents will discuss about required configuration for Two Step picking.

Process Involved: Two steps picking are broken in to 2 steps- 1) Picking with respect to group which are created to combine all OBDs/TR's

2) Allocation of materials to respective OBDs/TR's

Two Transfer order is created in this process- one for group picking and another TO for allocation. First TO brings the materials to interim storage Type 200 from a bins which was used for picking. Second TO is used to allocate the materials to respective OBD's/TR's.

We need to configure to make this happen. I will only touch upon configuration involved for Two step Picking. Will not discuss about Strategy for removed from Bins.

Configuration Involved: As We discussed above, TO can be created either from OBD or TR's so we need to set up configuration for 2 steps     picking for shipping used for OBD as well as Transfer requirements.

A) Activate Two step picking for Transfer requirement: We need to activate 2 step picking for Transfer Requirement. We can make 2 step picking material dependent or Independent.

Menu Path-

SPRO-->Logistic Execution-->Warehouse Management-->Activities-->Transfers-->Set up 2 step picking process for Transfer Requirement

When click  on Set up 2 step picking for Transfer Requirements, another screen opens where we have 2 activities need to be performed as shown below

Under Transfer requirement control, we have to make following setting

1) Assign 2 step picking under column 2stP for given Warehouse No

2) 2 Step is Material dependent or not. If check  column 2-stMatl, only those Materials  will be part of 2 steps picking where 2 step  provision is made  in Material  master under Warehouse view 1

3) Movement type 850 needs to be assigned as this is movement type will be used during first TO during collective picking to bring the materials to interim Storage Type 200

Once it is done, we need to set up 2 step picking for transfer type- Stock removal under transfer type control.

Same configuration is involved for outbound Delivery. Configuration path can be found under Interface-->Shipping-->2 step picking

Now once it is configured, We now need to set up Storage type search for 2 step picking. Here we need to assign operation 2 and give storage type as 200 as stock will be kept at storage type 200 before final allocation.

Configuration step will be same as we do for normal Put away and Stock removal Storage type search

SPRO-->Logistic Execution-->Warehouse Management-->Strategies

Now Configuration is complete. Now let's have a one  2 step picking example for better understanding.

We will take 2 step picking for transfer requirement document. We will create TR via SLOC to SLOC transfer. If both SLOC are warehouse Managed under same Warehouse no, Posting change notice is created but we need to have TR so I will transfer from WM managed SLOC 1000 to non WM managed SLOC 2000 in below example.

Following steps needs to be executed

1) Assigning 2 step indicator in Material Master:

2) Creation of TR via Transfer Posting in IM via MB1B with movement Type 311:

We have Generated 3 TR via 3 Transfer posting which we can see in LB11 report

3) Creation of  group : Now we need to create group combining all these 3 TR's  which will be reference documents for first TO for collective picking. Group is created via LT41 transaction

Screen is showing 3 TR's have been clubbed. Now Select Row and press Assign Group to create Group. Another Screen will appear where give Description of group as shown below

4) Run LX39report :

System will ask to enter Group no created above and Warehouse No. Execute the report. System will display 2 Row- Picking and allocation if group is 2 step relevant else System will give warning message

5) Creation of TO for collective Pick:Now put cursor at Pick row and click on Create TO to initiate picking process

Press Enter .

Select Stor type Srch Seq to see which Storage type is being proposed for Destination. It should Be 200. Once it is done, Generate TO

6) Confirm TO: Confirm TO to complete the picking step. Run LT12  and enter the TO generated above

7) Run LS26 report: We can see stock status. Stock will be lying under Storage type 200

Now Collective Picking process is done. We can see  Picking row will be green if we put cursor on pick row and press Data

8) Create TO for allocation: Put the Cursor on Allocation and select create TO button to create TO

Select Start multiple Proc. button to initiate TO

So we can see that Allocation to respective TR has occurred via TO#98,99 and 100. Now we can see that LX39 report shows allocation green as it is completed.

Now 2 Step picking process is completed.

This Document was created with Co-Author-Pankaj Agarwal who is very much enrich in SAP-MM/WM coming from very rick background of Procurement and Planning.

Order fulfillment for ship complete scenario

Overview:

There are many ways of order fulfillment and most of them are based on how the material is classified ie Make to stock, Make to order etc.

1. Make to Stock Order fulfillment
Here the stock is readily available based on the forecast and mostly stored in Centralized warehouse for quick response to customers demand.

2. Make to Order or Configure to order fulfillment

In make to order scenarios the product ordered by the customer is a customized one and hence is build only when the order is inducted in the system

These orders are not fulfilled from warehouse rather those order go to plant where these products are build as per customers requirement and then shipped out

3. There are certain scenarios where customer demand both Make to order and Make to Stock product in a single order and they want to have both the products delivered in single shipment

So here for the make to stock line item the plant defaulted is warehouse plant (MAR1), where as for the make to stock line item the plant defaulted is plant (MAR2) .So in order to ship both the products should have same delivering plant.

Thus below we have discussed one of the method to achieve the same and configuration setup required from SD, MM & APO end

Summary of outcome from the changes done

• In this scenario as soon as the complete delivery tab in SO is selected the plant for make to order based line item will be changed from MAR2 to warehouse plant MAR1 based on the multi item single location config maintained in APO
• Post this the schedule line of the order based line item will have a purchase requisition which when converted to PO is an STO to transfer the stock from MAR2 to MAR1 once the same has been build in MAR2 plant as per customers requirement.
• Once both the stock is available in warehouse plant MAR1 the DN is dropped and order is fulfilled

1. SD related Configuration Steps:

• Configure schedule line category to create STO PR in schedule lines

1.1Creating Schedule line catergory “MA”

1. Sales & Distribution-->Sales-->Sales Document-->Schedule Lines-->Define Schedule line Catergories

Key Changes:

• Item category used as ‘7’ ie Stock Tranfer

  Account Assgnt Cat as ‘M’ ie Individual Customer w/o KD-CO

1.2 Assign the Schedule line category to the respective Item cat

2. APO related Configuration steps:

(To default the warehouse plant on setting the Ship completed tab)

We can use APO Rule based ATP functionality to make “Complete delivery” Sales order to point to a single plant. For this we need to use the rule type MISL (Multi Item Single Location).

Rule based ATP check is an iterative, step-by-step availability check process driven by self defined rules. The results of one step determine whether the next condition type needs to be further processed and checked.

Configuration:

2.1 The Rule Based ATP check is enabled in the Check Instruction.

The Check instruction is the combination of Check mode and business Event.

So the Check instruction for this part must have the Rule based indicator set up so that Rules are called as required.

At this point assumption is that the Condition table, Access sequence, Strategy sequence is already setup.

2.2 The MISL rule also activated in SPRO >> Advanced planning and optimization >> Global Available to promise >> Rule based Availability check >> Activate Multi – Item single delivery location.

2.3 So the Rule type to be used is defined in the APO >> Mater data >> Rule Maintenance >> Integrated Rule maintenance

Further the condition type has to be specified showing when order is marked as “Ship complete” then it should call MISL rule.

3. MM related configuration steps and Master Data Setup

3.1 Master Data Setup:

• Auto PR to PO conversion
• STO Pur-Req should have the source of supply defaulted, the same will be fetched from Source list

  Tcode:ME01

Note: PPL ie Procurement plant maintianed is MAR2

• Autom.PO field set in Material-Master

• Material Requirement PLanning

MRP run on plant MAR2 will create purchase requsition

• Pur-Req will have source of supply defaulted from below source list

Note:

• Vendor 233 is used for external procurement
• MRP field is set as ”1” for MRP run

End to End Cycle of above process:

Sales Order:

Select line item 20 & click on “Item Details Configuration”

STO PR:10018013

Once the STO PO is created check the Stock requirement list of the delivering plant i.e MAR1, there will be entry for SO & the corresponding STO PO

MRP RUN on Plant MAR2

Tcode:MD02

Pur-Req created.

Stock/Requirement list for Plant MAR2

Pur-Req:10018105

PR to PO conversion:
Procurement PO :1002020006

• GR against the ZCON PO:

Stock is received in Plant MAR2, Sloc MAS3 and is mapped to the SO:16089

Stock to be transferred from plant MAR2 to warehouse MAR1
Outbound Delivery against STO 4500019858
Tcode:VL10B

Movement Type : 641
The quantity is transferred unrestricted-use stock of the issuing plant to 'stock in transit' of the receiving plant.

Hi all,

We know about purchase document text. This text can be maintain in header level and item level.

Text can be maintain on Info record, Material, PR, PO, SA, Contract etc..

It's stored into a table STXH and STXL, but its little difficult to find out with compare these two tables.

SAP has another way where we can get a report for these texts with all details.

Let's discuss details about it.

Suppose we have a lots of material, some material has a text and some material hasn't.

How can I found the material which has a text and what is the text for those particular materials.

Lets display one material for the tab Purchase Order text.

Here is the text for material master for this particular material.

Now just click on the Editor, You can find the option bottom of the screen in left side. Its look like

Now the screen will looks like as below screen shot.

Then in application bar, press Goto - Header

Now you can see a pop-up screen will appear. Which will contain some information.

Note the text id for Material.

Standard Text ID for material purchase order text is BEST.

Note that.

Now go to SE38 and give the program name RSTXTC3.

Now press execute.

Here enter the Text ID (which you have got from material master)

Then again press execute.

Here we can get a list of all material which has a purchase order text.

Now press the option Additional information

After pressing additional information, you can see all information including the purchase order text with respective to material..

Now you can also copy the all information into excel sheet for further process.

If your text contain more than one line item, then you can only see the first line item text in this report. You can see the more line item for this text by clicking the display text option as below:

You can also change the text from here (at the time of this change option, you can see the text for all line items)

Just select the line item and press Change Text .

The above information for Material master - purchase order text.

We can also get a list for all purchasing document.

Like for Purchase Order/ Contract/ Sch. Agree./RFQ- Header Text:

The selection field will be

Because of header text, we have to select object as EKKO and text ID as same as the way for material master - purchase order text.

You can also select the text as purchase order number+Line item number (Purchase order number will be 10 characters and line item number will be 5 characters)

For Purchase Order/ Contract/ Sch. Agree./RFQ- Item Text:

The selection field will be

For Purchase Requisition - Header Level : Use Object = EBANH and Text ID = B01.

For Purchase Requisition - Item Level : Use Object = EBAN and Text ID = B01.

For Purchase Info Record - Info Record Note : Use Object EINA and Text ID = AT.

For Purchase Info Record - Purchase Order Text : Use Object EINE and Text ID = BT.

For Vendor Master - Accounting note : Use Object LFA1 and Text ID = 0001.

For Vendor Master - Purchasing memo : Use Object LFA1 and Text ID = 0002.

For Sales Order - Header Level : Use Object = VBBK and Text ID = 0001

For Sales Order - Item Level : Use Object = VBBP and Text ID = 0001

For Service Entry Sheet - Long Text : Use Object = ESSR and Text ID = TX01

For Service Entry Sheet - Line Long Text : Use Object = ESLL and Text ID = LTXT

For Service Entry Sheet - Service Long Text : Use Object = ESLL and Text ID = LLTX

In this way we can get a report for all purchasing document's text and as well as master data's text.

Thanks and Regards

Dev Patra

Introduction:  This Document purviews various approaches to setup inbound delivery in SAP. Inbound delivery is delivery pertaining to incoming good. It’s Different from Outbound delivery in sense that outbound delivery encompasses scenario when goods move out of a plant, whereas inbound delivery is about receipt of goods. Thus inbound delivery is created at receiving entity.

Problem Statement:  If Purchase order is created by receiving party, then for that corresponding outbound delivery is created by supplying party. But receiving party doesn’t get much visibility of shipment of goods till they actually receive it. This Situation becomes more difficult when there is long distance shipment involve across countries or continents. In such long journey, there can be delays/issues due to any reasons. Receiving party remains oblivious of up to date situation of goods transit. Receiving party would like to ensure that they always have real time updates of goods movement.

Solution: To overcome this requirement a concept of inbound delivery can be used. An inbound delivery can be triggered automatically once post goods issue is done for outbound delivery. Thus outbound delivery serves as a reference document for inbound delivery and details can be seen in Purchase order through confirmation controls. Also any update in outbound delivery, would be updated in inbound delivery.

Solution Approach:

There could be two approaches to create inbound delivery from outbound delivery automatically, once Post Goods Issue is done.

1) Use standard SAP output type – SPED.

2) Use iDOC through EDI medium

Approach 1: – SPED

Step 1)If your system doesn’t contains output type SPED, then manually create it.

SPRO > Logistic Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output              Determination for Outbound Deliveries > Maintain Output Types

T.Code – V/34

Step 2)Assign SPED to Output Determination Procedure

SPRO > Logistic Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output Determination for Outbound Deliveries -> Maintain Output Determination Procedure

Step 3) Create Condition Record for SPED

Logistics > Logistics Execution > Master Data > Output > Shipping > Outbound Deliveries > Create

T.Code – VV21/22/23

Step 4) Confirmation Control

SPRO > Material Management > Purchasing > Confirmations > Set up confirmation control

Confirmation Control key must be selected on the confirmation control tab at item level in Purchase Order. Make sure to check GR-Relevant and GR Assignment key for control key.

To ensure automatic selection of confirmation control in Purchase order, maintain relevant entry in purchase info record, otherwise manually select it in Purchase Order.

Logistics > Materials Management > Purchasing > Master Data > Info Record > Create

T.Code – ME11/12/13

Step 5) Assign Goods Receiving Points for Inbound Deliveries

SPRO -> Logistics Execution -> Shipping -> Basic Shipping Functions -> Shipping Point and Goods Receiving Point Determination -> Assign Goods Receiving Points for Inbound Deliveries

Assign shipping point as a good receiving point for combination of plant and storage location.

Approach 2: - iDOC

Step 1) Output Type for Delivery

Create new output type or modify the existing one

SPRO > Logistic Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output Determination for Outbound Deliveries > Maintain Output Types

T.Code – V/34

Assign output type to Output Determination Procedure

SPRO > Logistic Execution > Shipping > Basic Shipping Functions > Output Control > Output Determination > Maintain Output Determination for Outbound Deliveries -> Maintain Output Determination Procedure

Maintain Requirement as “1”, so that output is triggered only when Post Good Issue is done.

Create Condition Record for Output Type

Logistics > Logistics Execution > Master Data > Output > Shipping > Outbound Deliveries > Create

T.Code – VV21/22/23

Step 2) Confirmation Control

SPRO > Material Management > Purchasing > Confirmations > Set up confirmation control

Confirmation Control key must be selected on the confirmation control tab at item level in Purchase Order.

Make sure to check GR-Relevant and GR Assignment key for control key.

Step 3) Setting of Outbound iDOc

IDoc type - DELVRY03

Tools > ALE > ALE Development > IDoc > IDoc Type Development > IDoc Types

T.Code – WE30

Message Type – DESADV

Tools > ALE > ALE Development > IDoc > IDoc Type Development >Logical Messages

T.Code – WE81

Process Code – DELV

Tools > ALE > ALE Development > IDoc > Outbound Processing > Define Process Code

T.Code – WE41

Function Module - IDOC_OUTPUT_DELVRY

Maintain partner profile for outbound parameter

SPRO > Materials Management > Purchasing > Messages > EDI > Set Up Partner Profile

T.Code – WE20

Partner Type – KU (Customer)

Partner Role – SH

Step 4)Setting of Inbound IDoc

IDoc type - DELVRY03

Message Type – DESADV

Process Code – DELS

Tools > ALE > ALE Development > IDoc > Inbound Processing > Define Process Code

T.Code – WE42

Function Module - IDOC_INPUT_DESADV1

Maintain partner profile for inbound parameter

Partner Type – LS (Logical System)

Actual Process Flow:

The Process flow to generate inbound delivery remains the same in both approaches.

1) Create Purchase Order.T.Code – ME21N

2) Create Outbound Delivery for Purchase Order.T.Code – VL10B

3) Do Pick, pack and Post Good Issue for Outbound Delivery from supplying plant.

4) Output will be automatically triggered.

5) Confirmation control of Purchase Order will be updated with inbound Delivery.

ABSTRACT

IDocs are used in most of the SAP applications for transfer of message from SAP  to other systems and vice versa. A lot of documentation is available on web for IDocs but most of them are technical in nature.  This document is written from perspective of a functional consultant and this will help in dealing with support issues related to IDoc. An effort has been made to capture all the necessary information about IDocs that a functional consultant needs to be aware of.

OVERVIEW

IDoc is an SAP object that carries data of a business transaction from one system to another in the form of electronic message. IDoc is an acronym for Intermediate Document. The purpose of an IDoc is to transfer data or information from SAP to other systems and vice versa.  The transfer from SAP to non-SAP system is done via EDI (Electronic Data Interchange) subsystems whereas for transfer between two SAP systems, ALE is used.

IDoc can be triggered in SAP system or in EDI subsystem. This depends on the direction in which IDoc is sent and is called as Inbound IDoc and Outbound IDoc accordingly. In case of outbound flow, IDoc is triggered in SAP through document message control which is then sent to EDI subsystem. EDI converts the data from IDoc into XML or equivalent format and then sends the data to partner system through Internet.

For inbound flow, EDI converts partner data and IDoc is created in SAP. After successful processing of this IDoc, Application Document is posted in SAP.

EDI STANDARDS AND IDOC

“EDI is electronic exchange of business document between the computer systems of business partners, using a standard format over a communication network”. EDI stands for Electronic Data Interchange.

For transmission of information electronically, two widely used standards are ANSI ASC X12 and EDIFACT. ANSI ASC X12 is a committee formed by representatives of major organizations, government bodies and EDI software companies which defines standards and guidelines for information interchange over EDI. UN/EDIFACT stands for United Nations EDI for Administration, commerce and Transport and was formed in 1985 using ANSI X12 and UNTDI (United Nations Trade Data interchange) as base standards. ANSI X12 describes business document as transactions and each transaction is represented by three digit number e.g. 850 – Purchase Order, 855 - Purchase Order Acknowledgement. EDIFACT describes business document as messages, represented by standard names e.g. ORDERS for purchase order.

IDOC TERMINOLOGIES

IDOC (BASIC) TYPE

IDoc Types are based on the EDI standards and mostly on EDIFACT standards. 

Basic Types (or IDoc Type) defines the structure of an IDoc. Each basic type describes standard IDoc segments, format of data fields and their size. Basic Type also defines number of segments and fields in an IDoc. All the fields that are necessary for transmission of message for a particular business transaction are mapped in different segments. It also defines the structure and relationship of IDoc segments along with mandatory and optional segments.

IDOC EXTENSION

Basic type contains all the standard fields that are necessary for carrying out a business transaction. However, if any additional values are to be sent to the partner then we can make use of the IDoc Extension feature. IDoc extension is extension of basic type and contains additional custom IDoc segments and fields that are not available in standard basic type.

IDOC SEGMENTS

IDoc segments contain the actual data that is sent to or received from a partner. These segments contain the actual values that are sent as part of IDoc transmission.

PARENT AND CHILD SEGMENTS

IDoc segment is termed as Parent segment if it contains its own segments. The dependent segments are called as child segments.

INBOUND/OUTBOUND IDOCS

IDocs sent outside the system are termed as Outbound IDocs and the ones that are received into the system, are called as Inbound IDocs.

IDOC DIRECTION

This signifies the direction is which information is sent and is similar to terminology used in mails. If information is sent outside the system then the direction is outbox when it is received into the system then direction is inbox. In SAP Outbox direction is represent by “1” i.e. outbox and Inbox direction is represented by “2”.

PARTNER

Partner is the Business Partner with which the exchange of information is to take place using IDoc. It can be a vendor or customer or any other system. Depending on the direction of information in which the information is sent it plays a role of either a “sending partner” or a “receiving partner”.

PARTNER TYPE

Partner type/role is used to identify partners within the sap systems. Partner type is KU for customer, LI for vendor and LS for Logical System.

MESSAGE TYPE

IDoc processing involves transmission or receipt of document in the form of a message, each of which represents a document in SAP. These documents can be Order, Shipment Confirmation, Advance Shipping Notification, Goods Receipt, or Invoice.  Message type is associated with Basic IDoc Type (Basic Type) and defines the kind of data or document that is exchanged with the partner.

PROCESS CODE

The process code contains the details of the Function Module that are used for IDoc processing. Message Type can be linked to the Process code.

PORT

IDoc Port contains the information about the way data is sent between the source or target system. The type of port defines the information contained within the port. For port type “Internet” Port will contain IP address of the target system. For port type “file”, directory or file name information is maintained. “tRFC” port contains information about the RFC destination of the target system. For IDoc transmission using ALE “tRFC” ports are used.

PARTNER PROFILE MAINTENANCE

PARTNER PROFILE (WE20)

Partner profile must be maintained for all the business partners to whom we want to send or receive the IDocs. The TCODE for maintaining the partner profile is WE20.

Double clicking on the Partner will show the following screen:

Partner profile contains parameters for Inbound and Outbound processing of IDocs. For each message type we can maintain, inbound/outbound options, message control, post processing options and contact information within Inbound and outbound parameters.

OUTBOUND OPTIONS (OUTBOUND PARAMETERS)

This involves sender/receiver port, Output mode and relation to IDoc type i.e. Basic Type and extension.

MESSAGE CONTROL (OUTBOUND PARAMETERS)

This contains application for which IDoc will be created e.g. EF for Purchase order, the message type of the application that will trigger the IDoc and Process Code that will convert SAP document to an IDoc. For example, if PO is to be sent to the Vendor AXXXXZ, then in the outbound option of the partner AXXXXZ we need to maintain the message type ZXX1 and link it to the Process Code ME10. So when message type ZXX1 is triggered in the PO then an IDoc will be created for the partner vendor AXXXXZ.

Process Code is linked to the Function Module in SAP that converts application data into an IDoc. Standard function modules are provided by SAP for this conversion however these can also be customized as per business needs.

Change Message Indicator indicates whether the IDoc is sent as a notification of change. For example, Purchase Order change messages are sent to vendor using EDI standard message type 860. 

Separate message type should be triggered in the purchase order for PO change. Additional line with change message type must be added in the Message control tab with change message indicator on.

INBOUND OPTIONS (INBOUND PARAMETERS)

For inbound options process code is maintained in the Inbound screen only. IDoc processing can be triggered by background program and triggered immediately.

POST PROCESSING (INBOUND/OUTBOUND PARAMETERS)

In the post processing option we can maintain the workflow details of the users or positions to which an error notification will be sent if an IDoc processing fails.

TELEPHONY (INBOUND/OUTBOUND PARAMETERS)

We can also maintain the contact details in the telephony option.

EDI STANDARD (OUTBOUND PARAMETERS)

EDI standard screen contains the details of the Standard EDI terminology used for the IDoc transmission.

For example, Message Type 850 is an EDI standard for Purchase Order IDoc and is linked to IDoc Message Type Orders.

IDOC STRUCTURE AND RECORDS

STRUCTURE

IDoc structure is divided into Control Record, Data Records and Status records.

These records are stored in the transparent tables in SAP. These are EDIDC, EDID4 and EDIDS.

CONTROL RECORD (EDIDC)

It contains information such as IDoc number, direction, IDoc Status, Basic Type, Message Type, Partner (Sender/Receiver), date and time of creation/update, Interchange File or ISA number,etc.

DATA RECORD (EDID4)

It contains the details of the IDoc segments.

IDoc segment has fields that contain the data necessary for posting the documents.

STATUS RECORDS (EDIDS)

IDoc Status defines the processing status of the IDoc. IDoc statuses are used to track the IDoc and its various processing states. Status Numbers represents IDoc status. Current status of the IDoc is present in Control record.

Initial Status numbers are 64 for inbound and 03 for outbound. Successful status is 53 for inbound and 16 for outbound IDocs.

SENDING AND RECEIVING IDOCS

TRIGGERING AN OUTBOUND IDOC

Outbound IDocs can be triggered from the output message types of Purchase Orders, deliveries, Material Documents, invoices, etc. The following figure shows that once the output ZXX1 of PO XXXXXXX1 is processed an IDoc “000000XXXXXXXXX1” is added/created.

The relationship between the IDoc and the application document can be found in two ways:

1. Relationship tab of IDoc

2. Relationship tab of Application Document, e.g. PO, SO, Material Document, etc.

The initial status of this IDoc will be 30, which after successful processing will convert into status 16.

A successful outbound IDoc will pass through all the above statuses in reverse order (01-03-18-06-12-16). Each status represents an IDoc validation step. If an IDoc passes all the validations it would reach status 16. These different validation steps for outbound IDocs are explained below:

01: IDoc generation successful

30: IDoc is ready to be processed by IDoc Processing job

03: IDoc data is passed to the Port

18: IDoc successfully triggered EDI subsystem

06: IDoc data translated to EDI format

12: IDoc is dispatched successfully to the partner

16: Partner has received the IDoc successfully

IDoc can possibly fail at any of the above steps during validation.

RECEIVING AN INBOUND IDOC

The initial status of an inbound IDoc is 64 and successful status is 53.

Different validation steps for inbound IDocs are explained below:

50: IDoc received successfully in the system

64: IDoc is ready to be processed by IDoc processing job

53: Application document created and saved successfully. The document number can be found by expanding the status node 53

An inbound IDoc goes through all the above statuses in reverse order (50-64-53).

IDOC PROCESSING

AUTOMATIC/IMMEDIATE PROCESSING

In this case, IDoc are processed immediately as they generated or added in the system. The check “Transfer IDoc immediately” is selected in Outbound Options and “Trigger Immediately” is selected in Inbound Option. These checks are generally used when the real time information exchange is necessary between two systems.

MANUAL PROCESSING

IDocs can also be manually processed using the TCODE BD87 in SAP.

PROCESSING VIA BACKGROUND JOB

IDoc processing by background is the most preferred way of processing the IDocs. Following Programs are used from processing the IDocs using background job:

RBDAPP01 - Inbound IDocs

RSEOUT00 - Outbound IDocs

REPROCESSING IDOCS

On the basis of IDoc statuses different programs can be used for reprocessing of failed IDocs. These are given below:

TESTING AND EDITING IDOCS

If an IDoc contains error in the data then such IDocs can be edited using TCode WE02 or WE05. When an IDoc is edited the original IDoc information(backup) is saved in a New IDoc under status 70 (for inbound) / 33 (for outbound). These IDoc stays in the system for reference only and cannot be processed. The status of the edited IDoc becomes 69 (inbound) and 32 (outbound). These IDocs can then be processed using BD87 transaction or batch jobs.

Debugging of IDocs can be done using by copying the IDocs using TCode WE19. WE19 is a test tool for Idocs processing. WE19 copies the existing idoc and creates a new IDoc which can then be modified as per testing needs. The newly generated IDoc can also be processed using BD87.

CONVERTING IDOC STATUS

Report RC1_IDOC_SET_STATUS can be used to change the status of IDoc. Status changes are generally needed to move an IDoc to status 68 – no further processing

SEARCHING IDOCS IN SAP

TCODE WE02/WE05: GENERAL SEARCH

IDocs can be displayed in system via TCODE WE02 and WE05. If IDoc number is not known then  search can be made on the basis of IDoc Date, Direction, BASIC TYPE, MESSAGE TYPE, and PARTNER NUMBER. Partner number can  be found in the Output Messages of the documents.

IDoc search can also be made on the basis of ISA or Transfer file Reference.

TCODE WE09: SEARCHING DATA IN IDOC SEGMENTS

If we are looking for specific information within the IDocs Segments then this can be found using TCODE WE09. This is useful if you are searching for a particular information in similar kind of IDoc within IDoc segments. For example, if you want to search a particular Purchase Order number e.g. 100000001 in multiple IDocs which lies in Segment E1EDK01 of an IDoc under field BELNR. Then the search can be executed in the following manner.

IDOC VALIDATIONS, COMMON IDOC ERRORS AND SOLUTION

Though, the IDoc failure may not be related to any of the above mentioned reasons, the best way to find the IDoc error is to compare the existing IDoc with the good example. Good example IDoc can be easily searched with any of the IDoc search methods as described above.

DOCUMENTATION FOR IDOC TYPES

IDoc documentation can be found using TCODE WE60 and can be helpful to obtain information of the IDoc Type or its particular segment. It also provides information such as  mandatory and optional segments, minimum and maximum number of segments, etc.

GENERAL INFORMATION FOR COMMON IDOC MESSAGE TYPES

The following list gives the Basic Type and Message Type combination for common idocs

ARCHIVING/DELETION OF IDOCS FROM DATABASE

As IDocs grow older they are archived and deleted from the database. Archived IDocs can be viewed using TCODE SARI in Achieve Explorer using archiving object as IDoc. Following are the few programs that are used for archiving and deletion of IDocs from database.

Hi,

   I would like to share a small configuration regarding the rounding off for the condition types in pricing. Case 1 explains how to round off a condition value directly and Case 2 explains how to round off and post the rounded value to separate GL.

   Let us discuss the scenarios in detail:

Case 1: How to Round off the condition values:

     You can round off particular condition values based on the rounding figures, like 10th place, 100th place etc. For example, suppose you have a condition type, say ZMOP. The client requirement is to round up the condition values for this condition type to two decimal places.

   The configuration steps are as follows. (The same is applicable in case of MM pricing procedure as well as tax procedure.)

1. Maintain the rounding rule in the condition type (M/06 or OBQ1) as shown. It could be round up or round down.

2.  Maintain the calculation type "17" in the pricing procedure.

3. Now Maintain the rounding rule for the company code in the transaction OB90.

          If its 100, the value will round off to 100 place, means the 2 decimals will be rounded off to upper or lower  value based on the condition rule specified in condition type.

    After these configuration steps, you can test the scenario. The values for the respective condition types will be rounded off accordingly.

Example: Condition value before the above settings:

Condition Value after the settings made:

Case 2: How to round off and post the Rounding Difference to separate GL:

    If you want to post the rounded value to separate GL, you may proceed with below steps: Here. there will be different condition types for capturing the rounding values.

1. Create a new condition type, say Z001 (in OBQ1 or M/06 or V/06 or similar) for rounding off value.

•      Maintain the condition class as D if its tax condition type. Else, maintain it as A.
•      Maintain the access sequence if its tax procedure. Else, keep it blank.

2. Create a new condition type (in OBQ1 or M.06 or V/06 or similar) for rounded value - You can copy the parent condition type which is to be rounded and change the key.

•     Suppose we need to round off JMOP condition and post the difference to separate GL. Then copy JMOP and create a new condition, say ZMOP.
•     In this example, JMOP will show the value without rounding and ZMOP will show the value after rounding.
•     Maintain the access sequence for the new condition type. We will be maintaining the condition record as 100% for this condition type.

3. Go to the Calculation schema (Tax procedure or MM/SD pricing Procedure) and maintain the condition types in the procedure, as below.

•     Z001 is the condition type to post the rounding difference.
•     ZMOP is the condition type to calculate the value of the parent condition type JMOP after rounding off.

• Calculation type 16 will bring only the round off value, based on the OB90 (configuration explained in case 1).
• The parent condition type is made as statistical in the pricing procedure.
• Now, the system will split the value of the parent condition type (JMOP in example) to ZMOP (rounded value) and Z001 (Round off value).
• Maintain the account key / acruel key for the new condition types depending on tax procedure / pricing procedure.
• Maintain the step number (from and to) accordingly.

Save the procedure.

4. Maintain the GL account for the account keys.

5. If its tax condition type, maintain the condition record for the round off condition type (Z001) as 100% in FV11.

6. Maintain the condition record for the rounded value condition type (ZMOP in example) as 100%.

7. Test the scenario with a new PO:

Result:

   The condition value (12.06 in example) for the condition type (JMOP in example) is splitted as round off value ( 0.06-) and rounded value (12.00). The splitted values will be posted to the corresponding GL.

MIRO GL Postings:

Note: Same procedure (Case 1 and Case 2) is applicable for all similar scenarios in MM / SD / Tax procedure.

Thanks for reading and your valuable suggestions / comments.

Thanks & Regards,

Prasoon

These days, I read documents related with M8 system messages , tolerances , invoice reduction etc.

In this document , i work on implementation and configuration SAP MM Logistic Invoice Verification. My example contains a example which it prevents different postings based on quantity and amount. We will get a problem that i want to post bigger amount, sap will not give permission with error messages finally invoice reduction will solve our this problem.

You can get details : MM-IV-LIV-CRE Set Tolerances for Incoming Invoice - ERP SCM - SCN Wiki

I have a PO , my person posted a material document 100 qty.

     In Miro , can you post more quantities and amounts ? Is it related your tolerances ? Not at all.

     If posting exceed your tolerances , you can post but it is blocked. If not, you can not prevent. Sometimes , you can not be aware of tolerances when you can post fastly. It is dangerous.

Examples :

1 - Amount is bigger than PO.

2- Quantity and amount are bigger than migo and po values.

     What can i do ?

     Firstly , check your LIV system messages.

     You can update your M8 / 81-82-83 messages with ERROR also if you get them.

     MM/Logistic Invoice Verification/Invoice Block/Set tolerance limits

     * Please check DQ and PP tolerance keys.

     However , it is not enough to prevent posting . You have to maintain your LIV system messages.

     * I configure M8 messages with ERROR.

     * When i post our invoices , sap will not give permission...

     ** Unfortunately , i have to post some like a weigher result , vendor errors invoices with variances , how can i solve this problem ?

     **Sometimes , you can post your invoices with tolerance even though you implement system messages. Invoice reduction can help you.

     *Select layout : Invoice reduction , Correction ID : 2 Vendor error - reduce invoice ,Invoice amount Acc to Vendor , however you can use similiar way for quantities. Sap will create one more fi record for differences.

     Results :

    ** Configurations :

     You have to configure your T030 table with RKA transaction (OBYC tcode) and invoice document types.

     I add RK document type for invoice reduction. (OMR4)

     However, if you want to update some datas to implement in your country like a tax rates ..

     You have to update records with enhancement implementation program LMRMCF07 .

     I hope that it can be benefical for your business life thoughts.

     Thanks a lot for spending times ...

     Regards.

     M.Ozgur Unal

Batch Master

Batch Definition

Batch management indicator:

Material Master

• Purchasing View
• Work Scheduling View
• Plant data/stor1. View

SAP Notes:
30656 - Change base unit of measure/batch management requirement
533276 - Setting the batch management requirement

Batchprocess:

Transaction Code: MSC1N/MSC2N/MSC3N  (Table MCH1/MCHA/MCHB)
Check change document: MSC4N
Mass processing: MSC5N

Program:
FUNCTION           VB_CREATE_BATCH
FUNCTION           VB_UPDATE_BATCH
FUNCTION           VB_CHANGE_BATCH

BAPIs:
BAPI_BATCH_CREATE (note 619913, item5)
BAPI_BATCH_SAVE_REPLICA (including classification >=470)

Batch Level

Function module: VB_BATCH_DEFINITION             

Table: TCUCH

FAQ during batch level conversion

Batch Number Assignment

Creating Batch:

• In batch master record maintenance(Batch Management)
• In goods movement(Inventory Management)
• In purchase orders(Purchasing)
• In production/process orders(Production)
• In results recording(Quality Management)

Automatic/Manually: Control in customizing OCHA

Batch number assignment: Internal/External

User-exit:

Automatic: EXIT_SAPLV01Z_001/EXIT_SAPLV01_Z_002

Manual: EXIT_SAPLV01Z_003/EXIT_SAPLV01Z_004, EXIT_SAPLV01Z_013 and EXIT_SAPMM07M_003 (inventory management, only for new batches) can be used to change the master data of a batch.

Common information:

• Since release 470 definition for batch number assignment is transported via table TCUBN
  (before it was part of table TCUCH!)
• Batch numbering without gaps is impossible (for explanation see note 619913, item 6)
• Assign the same batch number for more than one goods receipt:
  Use exit
  EXIT_SAPMM07M_010 (if goods movements are posted)
  Use modification according to note 523589for VB_CREATE_BATCH (relevant e.g. for REM - release >= 470).
  [The modification is replaced by BADI mentioned in note 1035372 - Exception BATCH_EXIST in VB_CREATE_BATCH II]
• Functionmodules:
  VB_NEXT_BATCH_NUMBER (internal batch numbering)
  VB_CHECK_BATCH_NUMBER (external batch numbering)
• Idoc type: BATMAS03
• 1970502 - Error message M3 682 when posting good movements to the same batch in parallel
• 1847487 - The Length of batch number is limited to 10 characters

Related documents:

Align vendor batch number with SAP batch number during Goods Receipt

Batch Classification

Characteristic Types in Batch Classification:

• User-defined characteristics: Characteristics that do not reference table fields
• Object Characteristics: Characteristics that refer to table fields.
• Standard characteristics: These are Batch Management characteristics that are delivered in the SAP standard system. They are reference characteristics from tables MCHA and MCH1. All standard characteristics can be found in F4 help by specifying LOBM_*. You are normally not allowed to make changes to standard characteristics in the characteristic master record.

One batch class per material (note 115581), but batch classification can be assigned to multiple objects (check transaction O1CL)

Accordingto batch level class type is determined (material/client: 023, plant: 022)

Batch classification can be maintained in batch master transactions, and in several applications (goods movements, orders, process messages)

Update standard Features: BMSM

Classifying batch during goods movement: OMJJ

Tables:
Do you know the links among tables in Classification and Variant Configuration?

Classification is called in: VB_CREATE_BATCH and VB_CHANGE_BATCH

Classification FM: CLFM_OBJECT_CLASSIFICATION

User Exits to fill free characteristics:

• EXIT_SAPLV01Z_014(not called in MB* transactions, but in MIGO!)
• EXIT_SAPMM07M_004(called in inventory management transactions and when posting goods movements via MB_CREATE_GOODS_MOVEMENT)

Reports:

• Integrity Check for Batch Classification – BMCC
• RCCLZUOB(checks whether object exists for classification entry in table INOB - e.g. entry for temporary document number)
• RCCLINOBDEL(deletes multiple INOB entries for one object)
• RVBCOR16(checks the customizing of batches concerning classification)

SAP Notes/KBAs:
1427890 - FAQ: Standard characteristics

1797792  - Slow performance when accessing classification data

Related documents:

Batch Class Conversion in SAP

Batch Archive

SARA:

Archiving Object MM_SPSTOCK

Pay attention on the indicator:

‘Only consider batch stock records; batch master record will not be deleted’

Batch Status Management

• Batch status management is activated via transaction OMCT.
• Batch status can be changed in batch master transaction and via usage decision (transaction QA11).
• There are two options to prevent restricted batches from being selected within batch determination:
  - insert characteristic LOBM_ZUSTD in batch class and selection class
  - work with dynamic ATP check (scope of check – OVZ9)
• Functionmodules:
  VB_CHANGE_BATCH_STATUS
  VB_CHANGE_BATCH_STATUS_STOCKS
  VB_BATCH_DEFAULT_STATUS
• Exit:EXIT_SAPLV01D_001 (determine initial status of batch)
• Fields:    TCUCH-KZDZV   T001W-CHAZV (batch level on plant)

Batch Determination

Batch Search Strategy Customizing

Five Scenarios

• Inventory Management
• Production order
• Process order
• Sales and distribution
• Warehouse Management

Five scenarios have similar steps to define the batch search strategy.

Five Steps in OCHA:

1. Define Condition tables : Condition tables are combinations of fields that form the key of the batch search strategy.
2. Define Access Sequences: The order in which the system accesses condition tables during batch determination.
3. Define Strategy Types: The default values used when a strategy record is created.
4. DefineSearch Procedure: The order in which you assign the strategy types is the order in which the system searches for strategy records.
5. Search Procedure allocation and check activation: Allocate the search procedures to the application-specific parameters. Batch determination becomes active as soon as you make the allocation.

Selection Class

Define in CL01/CL02/CL03

With the help of these selection classes, you define according to which criteria, that is, using which characteristics, batches are to be selected

• All characteristics (this applies to standard characteristics as well as to user-defined characteristics) you want to use for selection must also be contained in the batch class. Characteristics LOBM_RLZ and LOBM_LFDAT are an exception; they can be used for selection but not for classification
• To copy the characteristics from client 000 to your logon client, use report RMMCCH01.
• 33396 - Batch determ.: Selection w. remaining life LOBM_RLZ

Sort Rule

Define in CU70/CU71/CU72

With the help of sort rules, you define according to which criteria, that is using which characteristics batches are to be sorted.

• All characteristics (this applies to standard characteristics as well as to user-defined characteristics) you want to use for selection must also be contained in the batch class. Characteristics LOBM_MENGE and LOBM_LGORT are an exception; they can be used for selection but NOTfor classification.
• 1979691 - How to set up FIFO in batch determination

Batch Search Strategy Setup-SD

Transaction Code : VCH1/VCH2/VCH3

Set Up Batch Determination in Sales and Distribution

Batch Search Strategy Setup-PP

Transaction Code: COB1/COB2/COB3

Set Up Batch Determination in Production Planning

When the batch determination should be done in production process.

Batch Search Strategy Setup-MM

Transaction Code: MBC1/MBC2/MBC3

Set Up Batch Determination in Inventory Management

Batch Search Strategy Setup-WM

Transaction Code: LS51/LS52/LS53

Batch determination is used for goods issues and stock transfers in SAP warehouse management systems.

• Batches to be picked are transmitted to warehouse management (batch determination takes place in upstream applications).
• Batches are determined from warehouse management (Batch determination in warehouse management).

Batch Determination Analysis

Function Module VB_BATCH_DETERMINATION

• Trouble Shooting in Batch Determination
• Debugging Point of Batch Determination
• Batch Determination – Debug Tips

User Exit
SAPLV01F

• EXIT_SAPLV01F_001
• EXIT_SAPLV01F_002

BADI
VB_BD_SELECTION

585576 - BAdI preselection of batches in batch determination

Batch Information Cockpit

Basics        

Transaction BMBC functions as single point of entry for batch information and comprises several transactions:

MSC2N, MSC3N, MB56, MMBE, CO09, CL30N, MB5C

Selections

• Note 619912 - FAQ: Batch Information Cockpit

Selection Result

SelectionResults: Batches

Here, the main focus is on the selected batches. The batches are displayed in accordance with the batch definition level.

SelectionResults: Stock

• Here, the main focus is on the stock situation of the selected batches.
• Following stock tables are read:

–MCHB
(free stock, special stock indicator = blank)

–MKOL
(Special stocks from vendor, special stock indicator = k)

–MSKA
(sales order stock, special stock indicator = E)

–MSKU
(special stocks with customer, special stock indicator = V and W)

–MSLB
(special stocks with vendor, special stock indicator = O)

–MSPR
(project stock, special stock indicator Q)

Restrictions

Nmber of batches 50 but only 20 displayed.

• System read all batches of material A, for example 70. User Parameter said maximum 50 batches, so system take the first 50 and send message ‘more then 50 batches found’
• Next step take 50 batches and check if they fit the selection criteria, so for example only 30 batches are displayed customer

In the selection result of the Batch Information Cockpit you can display in all 50 characteristics, but it is limited to 20 for character types, 20 for numeric types and 10 for date and time types.

1701988 - Transaction BMBC - Not all characteristics are displayed in the selection result screen

Old batches are note displayed after upgrade to EHP5, reason is new added field BATCH_TYPE, note 1297566 provide a report to update the old
batches

Main Program: RVBBINCO

BAdI:
BIC_FOLLOW_UP_ACTION
BIC_SELECTION

Batch Derivation

Basic Information

• Batch Derivation is based on batchwhere-usedlist (table CHVW and CHVW_PRE areread).
• Batch Derivation is triggered by certaine vents (transaction DVC8)
• No batch derivation for stock transfers (use exit EXIT_SAPMM07M_004 instead)

Derivation Mode:

• Pull Derivation (1 Receiver, n Sender) 
  The derivation is triggered from a transaction that affects the product. Here, data from various senders can be collected, cumulated, and calculated. Within a derivation according to the pull principle, there can only be one receiver, but there can be several senders (example usage: pick and pack for pharmaceutical products).
  
• Push Derivation (n Receiver, 1 Sender)
  Within a derivation according to the push principle, there can only be one sender and several receivers. This derivation is started from a transaction that affects the component batch. Here, data from a sender batch can be derived onto several receiver batches (Example usage: Filling bulk batches in the Chemicals industry).

Customizing

Derivation events (DVC8)

• Determine at which time a derivation should happen and which rule should be used.
• Static or dynamic derivation
  • Static Derivation: For a static derivation, the attributes determined for the sender batch(es) are transferred to the receiver batch(es).
  • Static derivation is recommended if a batch is newly created or changed and the values in the receiver batch(es) should be filled with the attributes from the sender batch(es).
  • Dynamic derivation: For a dynamic derivation, no attributes are transferred to the receiver batch(es), in other words, the derivation is simulated and the values are merely displayed. The derivation is saved, but the receiver batch(es) are not automatically changed.
  • Dynamic derivation is used when the receiver batch must/should not be changed and the sender values should be used as the basis for a user decision.

Set Up Condition Technique for Derivation (Need to be set for sender and receiver both.)

• Define Condition tables
• Define Access Sequences
• Define Strategy Types
• Define Search Procedures

Derivation activate or not (DVSP)