1.

Outbound process

2. Inbound process

OP:

1.Application document is created.

2.IDOC is generated

3.IDoc is transferred from SAP to Operating system layer

4.Idoc is converted into EDI standards

5.Edi document is transmitted to the business partner

6.The Edi Subsystem report status to SAP

IP:

1.EDI transmission received

2.EDI document is converted into an IDOC

3.IDOC is transferred to the SAP layer

4.The application document is created

5.The application document can be viewed.

IDOC:

IDOC is a container that can be used to exchange data between any two process.
Each iDoc is assigned a unique number for tracking and future reference.

iDoc Consist of several segments,and segments contain several fields.

iDoc contains the following three type of records...

1.One Control Record.

2.One or many Data Record

3.One or many Status record.

PORT:

Port is used in the outbound process to determine the name of the EDI subsystem
program,the directory path where the idoc file will be created at the operating system
level,the idoc file names and the rfc desinations.

RFC Destination:

Used to define the characteristics of communication links to a remote system on which

a functions needs to be executed.

Partner Profile:

Partner profile specified the various componets used in an outbound process ( Partner
number,IDoc type,message type,Port,Process code),the mode in which it
communicates with the subsystem(batch or immediate) and the person to be notified in
case of errors.

Message Control

Used in pricing,account determination,material determination,and output

determination.The message control component enables you to encapsulate business
rules with out having to write abap programs.
Process:

Setup RFC destinations SM59

Port Destinations WE21

Partner Profile WE20

Message control NACE

Purchase Order ME21

Check IDOCs WE02,WE05

Explain to me about Idoc?

IDoc (for intermediate document) is a standard data structure for electronic data
interchange (EDI) between application programs written for the popular SAP business
system or between an SAP application and an external program. IDocs serve as the
vehicle for data transfer in SAP's Application Link Enabling (ALE) system.

IDocs are used for asynchronous transactions: Each IDoc generated exists as a self-
contained text file that can then be transmitted to the requesting workstation without
connecting to the central database.

Another SAP mechanism, the Business Application Programming Interface (BAPI) is

used for synchronous transactions.

A large enterprise's networked computing environment is likely to connect many

geographically distributed computers to the main database. These computers are likely
to use different hardware and/or operating system platforms. An IDoc encapsulates data
so that it can be exchanged between different systems without conversion from one
format to another.

IDoc types define different categories of data, such as purchase orders or invoices,
which may then be broken down into more specific categories called message types.
Greater specificity means that an IDoc type is capable of storing only the data required
for a particular transaction, which increases efficiency and decreases resource
demands.

An IDoc can be generated at any point in a transaction process. For example, during a
shipping transaction process, an IDoc may be generated that includes the data fields
required to print a shipping manifest. After a user performs an SAP transaction, one or
more IDocs are generated in the sending database and passed to the ALE
communication layer. The communication

layer performs a Remote Function Call (RFC), using the port definition and RFC
destination specified by the customer model.

The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external
system.

has to create a PR, PO, GR, GI, Invoice receipt(MIRO) and Vendor Invoice (FB60) through
IDOC's, which are inbound to SAP.

I'm not an expert but as per my knowledge these are the IDOC types and you can check
the IDOC structures using we30.

Purchase Requisition: PREQCR101

Purchase Order: ORDERS01

Post Goods Issue: MBGMCR01 / MBGMCR02

Goods Receipt: WMMBID02

Invoices: INVOIC01

What is Pricing procedure?

The main concept of pricing procedure is combination of different type charges, like Gross price,
freight, discount, surcharges etc etc.

We use pricing procedure to determine these all conditions into one procedure, where we can
find the sub-total for net amount.
To understand pricing procedure, we have to be comfortable about these below things :

1. Condition Table

2. Access Sequence

3. Condition Type

4. Condition Record.

5. Schema Group

6. Calculation Schema

7. Schema Determination

Let’s discuss about all these points in details.

1. Condition Table

It’s a table where system saves the all fields with the combination for individual condition
record. Suppose if I use Plant as condition table, then the condition record will be created for
plant only.

We can use many fields in one condition tables.

2. Access Sequence

The main concept of Access sequence is, it searches condition record for condition type from
condition table.

One access sequence can contain one or multiple condition tables.

Suppose we maintain 4 condition tables in one access sequence. Then when a condition type will
search for condition record via this access sequence, the access sequence will allow to search
only these 4 condition tables.

3. Condition Type

In simple term, condition type is used for different type of charges. Like gross price, discount,
freight, rebate etc etc.

Suppose we purchase a material for price 10, we get a discount of price 2. Then the price 10 will
be going to a condition type and the price 2 will be going to another condition type.

4. Condition Record
Condition record contains the record which is maintained against condition table with regards to
condition type.

It can be fetched via access sequence and condition type.

Suppose we maintain a condition record against condition table (vendor) with regards to
condition type. Then whenever the vendor used this condition type, the condition record will be
fetched.

5. Schema Group

It’s assigned to our vendor and Purchase Organization, It helps the vendor and purchase
organization to choose pricing procedure.

One schema group will be assigned to vendor and one schema group will be assigned to
Purchase organization. With this combination, system will fetch the pricing procedure.

6. Calculation Schema

Here we maintain sequence for the pricing calculation, like gross price, discount, rebate,
surcharges etc. Here we maintain the calculation for all condition types and group together all
required condition types for our pricing procedure.

7. Schema Determination

Here we maintain the pricing procedure for purchasing document. We maintain calculation
schema combination of per each vendor – schema group and each purchase organization –
schema group

PB00 and PBXX- Difference ?

PB00 is with acess seq that is condition recored is to be maintained

PBXX is manual cond with out acess seq

Eg for PB00 is if u maintain inforrecord this is the condition record and price in PO with be
taken from Info rec for PB00

and if Infor record is not maintaine that when u maintain price directely in PO then PBXX comes
in pitcher

When you go to interview, you must be specific at some points as how many years u r in Support, Implementation
and Rollout projects. And you must be able to explain the works you had done in the respective projects.

After reading this, you can get knowledge on Implementation Project, Rollout Project, Supporting Project, And
some Key points.
SAP Has 3 types of Projects : ( I R S Simply)

1) Implementation Project

2) Rollout Project

3) Supporting Project

IMPLEMENTATION PROJECT:

As the word suggests, i mean, IMPLEMENTATION means implementing Business Processes. After purchasing the
SAP (ERP), Companies do Study the Methodologies and various process and case studies.

In Implementation, Several People works on various functional modules listed below (can be considered as SAP BI
ARCHITECTS, DESIGNERS, SAP CONSULTANTS)

Every Module has its Importance and is linked to other module in one or many ways(SAP is all Tables and Table
Relations)

1. 1. Function Modules: Ex: FI CO Consultant, SD Consultant etc.

2. 2. Technical Module ABAP Programmer.
3. 3. Basis & security Administration
4. 4. Others

Function Modules:

 Financial Accounting (FI)

 Financial Supply Chain Management (FSCM)
 Controlling (CO)
 Materials Management (MM)
 Sales and Distribution (SD)
 Logistics Execution (LE)
 Production Planning (PP)
 Quality Management (QM)
 Plant Maintenance (PM)
 Project System (PS)
 Human Resources (HR)

Technical Module:

 SAP Technical (ABAP Programmers)

Basis & Security Consultants:

OTHERS

1. BIW (BI or BW) – Business Information Warehouse

2. CRM – Customer Relationship Management
3. IDES – International Demonstration and Education System
 4. KW – Knowledge Warehouse
5. MDM – Master Data Management

You can easily find the different SAP Types in diagram as follows:

Companies follow 5 Step/Stages ASAP Methodology to Implement a Project.

A. Project Preparation
B. Business Blueprint
C. Realization
D. Final Preparation
E. Go-Live & Support

ROLLOUT PROJECT:

Rollout exactly means, expanding the business after Implementation.

An Organisation whis is started in one country, expanding their services to other countries, follows Rollout.

Exactly in Rollout we can find that the Organization works accordingly to Government there in other countries like

Taxation: As the taxation will be different in other countries. Ex: Some allowances, Income Tax, etc.

Master Data: As the new employees join the organization

So many modifications should be done according to Country.

So Rollout is little tough but effective after completion.

SUPPORT PROJECT:

After Implementation completed, Support is in Action.

That’s same as an exam you had written in a stipulated time of 3 Hours, lastly 10 minutes before giving the answer
sheet to Examiner, you will verify for any unanswered questions, unexplained etc.

But in our scenario Implementation errors will be rectified in Support ( i.e. Answer sheet is again given to add or
change) by USER by arising a Ticket to solve the bug.

*We use Remedy as a Ticketing tool for tracking the issues/tickets/calls*

SAP UPGRADE PROJECT:

SAP Upgrade means upgrading the software with a latest version which has got more advantages (i.e. Bugs fixed
compared to previous version)

Example: Just think , this is out of topic but easy to describe the above concept easily. Android Phone with Version
2.2 upgraded to 4.2 will have same features but interfaces change at a great look)
we can upgrade form SAP 3 to 3.5 (Example).

Release Strategy

defines the approval process for purchase requisitions or external purchasing documents. 8
levels

without classification can be used to relese the Internal Purchasing Documents and With
classification can be used for both internal/external documnts

Transaction OLME > PR > release procedure

Release Procedure

In this section, you set up the release (approval) procedure for purchase requisitions.

You can elect to use either the procedure without classification or the one that is linked to the
classification system.

Procedure without classification (Release procedure 1)

This release procedure is only available for requisitions.

The aim of this correction and approval procedure is to check the data on the material, quantities,
and delivery dates for correctness and to ensure that the right account assignment and source of
supply have been specified.

This procedure provides for the approval of the individual items of a requisition, as a
precondition for the subsequent issue of RFQs or purchase orders.

Procedure with classification (Release procedure 2)

This procedure works in conjunction with classification. It provides you with the option of
specifying considerably more requirements than just "value", "material group", "account
assignment", and "plant". As a result, you have more flexibility in setting up the release
procedure.

The aim of this release procedure is to replace manual written authorization procedures using
signatures by an electronic one, while maintaining the dual control principle. The person
responsible processes the relevant document in the system, thereby marking it with an
"electronic signature" which can give the document legal force.

This procedure provides for the release (approval) not only of requisitions (i.e. internal
purchasing documents), but also of the external purchasing documents RFQ, purchase order,
contract, scheduling agreement and service entry sheet.
Note that in contrast to purchase requisitions, the other purchasing documents can only be
released in their entirety: item-by-item (or partial) release is only available for requisitions...

For Account Determination 5 major character 2019s are as follow:

1.Chart of Account,

2.Valuation Class,

3.Transaction Event Key,

4.Valuation Grouping Code,

5.Account Grouping Code/Account Modifier.

Subcontracting is a special procurement scenario where the manufacturer does not have the
technology or ability to do the value addition in the finished that he has produced. There can be
another scenario where the manufacturer will produce the required finished good or semi-
finished good and for the final packaging/serialization/electroplating/painting , he will give the
partially complete manufactured goods to the subcontracting vendor and he will perform the
value addition and will give back the final finished goods to the manufacturer. This is not
considered as a sale from the manufacturer. For making the final finished goods, the
subcontractor needs the semi- finished goods from the manufacturer and the required
components.

The process is as follows for a subcontracting process in SAP MM-

Process flow

1. Creation of the material masters for finished goods and components (SAP T code-MM01)
and vendor master(SAP T code-XK01/BP).

Business users needs to create the material master for all the components and the finished goods
with respective plant.

2. Creation of info record (Info record category as L(Subcontracting) SAP T code-ME11.

Business users needs to create the subcontracting info record for updating the lead time, standard
qty and the subcontracting charges.

3. Creation of BOM(SAP T Code CS01).

This is an important master data that is required for subcontracting. BOM (Bill of material is the
master data that explains for making a unit of finished goods, how much qty of components is
required.
4. Creation of the subcontracting PO (SAP T code- ME21N).

The buyer will create the subcontracting PO and will give to the vendor. While giving the
subcontracting PO to vendor, buyer will also give the required components to the subcontractor
for making the required qty of the finished goods. The qty of components that is to be issued to
the vendor will be given by system using the method of BOM explosion For this, the item
category in PO needs to be selected as L- Subcontracting. After selecting this, user can see new
button in PO item details (Material tab). The price details will be automatically derived from the
info record if created.

5. PO release.

The business stake holders will approve the PO and after the final release, the PO will be given
to the vendor. (SAP T code- ME29N or ME28).

6. Issuing the components to the subcontractor through 541 movement type.

The next step is the issuing the components to the subcontractor. This is done via MIGO. Select
transfer posting against the purchase order. Even though the goods are issued to the
subcontractor, the ownership of the stock is still lying with the manufacturer because the actual
stock consumption will happen only when manufacturer receives the finished goods. Due to this,
there is no accounting document created for this material document. This issued stock will be
shown in the MMBE as stock issued to the vendor. This is a special stock in SAP and called as
parts provided to the vendor. (SAP T code- MIGO/MB1B).

7. Goods receipt.

In this step, the manufacturer will receive the finished goods from the vendor. When the finished
goods are received from the subcontracting vendor, that means that the components are
consumed at the vendor premise for making the finished goods. So, there will be tow accounting
impact in the goods receipt 1) accounting document and material document for updating the
receipt of the finished goods. 2) the accounting and material document(same document with
different line items with 543 movement type) for reducing the component stock. (SAP T code-
MIGO).

8. Invoice verification.

The accounting clerk in the accounts payable can do the invoice verification (SAP T code-
MIRO).

9. Vendor payment.

The baking team in the accounts payable department will do the vendor payment.(SAP T code-
F100)

Accounting Entries at the time of Goods Receipt:

BSX – Stock A/C for Assembly/ Semi-Finished – Dr

BSV – Change in Subcontracting Stock Cr.

FRL – Subcontracting Charges Dr.

WRX – GR/IR Clearing (Semi-Finished) A/C Cr.

BSX- Stock A/C for Components Cr.

GBB-VBO - Consumption A/C for Components Dr.

Consignment stock is special kind of stock .The stock is lying at your storage location but the
responsibility vendor .Consignment stocks are not valuated. When the material is withdrawn it is
valuated at the price of the respective vendor.

Vendor liability will arise at the moment when you are withdrawing the stock or transfer the
stock to your own stock.

Info records with info category Consignment are created before creating the PO (you must
maintain the consignment price for the vendor in an info record).The price is required for
material valuation and accounting purposes.

Steps:

1.Assign Standard purchase org.to plant in Enterprise assignments (IMG)

2. Consignment Info record Activate in IMG material's management..

2. Create Info record for the material & vendor with info category consignment and maintain the
price which will be used for the valuation and accounting entries.

2.You enter purchase requisitions for consignment materials in exactly the same way as for other
materials.( item category K).

3.Creat Purchase Orders / Outline Agreements for Consignment Materials in the similar way
(item category K).

4.Goods reciept with 101 as its item Cat K it will not create the AC doc.

5. you can transfer stock to your storage location or goods issue for the consumption whatever
may the case with movement 411

6.Consignment materials are settled through MRKO... and payment will run in FI.
Special Procurement Types
In standard procurement, a customer purchases a material from a vendor and the material is
delivered to the customer. Upon delivery, the ordered goods become the property of the
customer.

In a case of special procurement, the goods do not necessarily flow from the vendor to the
customer. In third-party processing, for example, the ordered material is delivered directly by the
vendor to a customer of the customer. In stock transfer processing a material is procured
internally and transported from a storage location to the place where it is needed.

The following special procurement types exist in the SAP System:

 Consignment
 Subcontracting
 Stock transfer using stock transport order
 Third-Party Processing
 Returnable transport packaging
 Pipeline Handling

Consignment
In consignment processing, the customer orders goods from the vendor. Following delivery, the
goods still remain the property of the vendor. The goods only become the property of the
company to which they have been supplied at such time as they are consumed. Settlement is
effected with the vendor at agreed periods (such as monthly) in respect of the quantity of
consignment goods withdrawn from stock for consumption during the period that has elapsed.

Subcontracting
In subcontracting, the vendor (the subcontractor) receives components from which he
manufactures a product. The product is ordered in a purchase order. The components required by
the vendor to manufacture the ordered product are listed in the purchase order and provided to
the subcontractor. The components can be determined by the system via a bill of material.

Stock Transfer Using a Stock Transport Order

In stock transfer processing, goods are procured and supplied within a company. One plant
orders the goods internally from another plant (receiving plant/issuing plant).

The goods are procured using a special kind of purchase order: the stock transport order. With
the stock transport order, you can request and monitor the transfer of goods. The delivery can be
processed in Inventory Management or in the Shipping component ( LE-SHP ).
Third-Party Processing
In third-party processing, an enterprise forwards a sales order to an external supplier, who sends
the goods directly to the customer. The sales order is not processed by your company, but by the
vendor. Third-party items can be entered in purchase requisitions, purchase orders, and sales
orders.

Third party processing is linked to the Sales and Distribution component (SD). If the sales order
contains third-party items, the system creates a purchase requisition from the order.

Returnable transport packaging

Here ordered goods are delivered with returnable transport packaging (pallet, container). This
continues to belong to the vendor and is stored on the receiving enterprise's premises until such
time as it is sent back.

Pipeline Handling
In pipeline handling, the material does not need to be ordered and stored. It is readily available as
and when required via a pipe or pipeline (e.g. oil or water) or cable (e.g. electricity).
Consumption of the material is settled with the vendor on a regular basis.

What is RICEFW in SAP?

During the realization of any SAP project, all the functional and technical SAP consultants work
on SAP RICEFW. RICEFW stands for Reports, Interface, Conversion, Enhancements, Forms,
and Workflow. Another name for RICEFW is WRICEF in SAP.

RICEFW in SAP is produced during the Explore phase of the SAP Activate methodology – a
process designed by SAP to implement SAP products, such as SAP S/4 HANA.

Fit and Gap analysis help identify the gaps and business requirements that cannot be fulfilled by
standard SAP functionalities. These additional objects are noted and defined using RICEFW
classifications during any SAP implementation or migration project.

RICEFW vs WRICEF

WRICEF in SAP means exactly the same thing as RICEFW but just uses a slightly different
acronym. WRICEF stands for Workflows, Reports, Interface, Conversion, Enhancements, and
Forms. You may see both RICEFW and WRICEF used interchangeably when working through
the Explore phase of any SAP implementation project.

The reason to use RICEFW vs WRICEF will usually be down to a personal preference. As a
result, some SAP projects will use the RICEFW acronym while others WRICEF acronym.
SAP RICEFW objects
SAP RICEFW objects fall outside of standard SAP functions and are divided into the following:

Reports

An SAP report is an executable program that is able to read data and generate output based on
the criteria selected by the end-user. It displays data based on filtered selections. The three
categories of reports are:

 Standard SAP reports — ex. COOIS, MD04, etc.

 Custom reports developed by an organization.
 Queries.

Reports are developed with the help of an ABAP (Advanced Business Application
Programming) team. Reports can help determine when standard SAP functions do not meet the
client or business requirements.

When this is the case, a custom report is created. For this it is necessary to understand the
complete requirements and finalize the data using the selection screen. When the report is
executed, it becomes a RICEFW object which can be used to help define target processes.
During this time, teams work through the Explore phase of the SAP activate methodology.

SAP reports can be used to create material requirements planning (MRP) validation reports, for
example. This report checks whether sufficient procurement elements are generated to meet
current requirements.

Interfaces

During the Explore phase, you can identify business processes such as payroll, shipping, fixed
assets, QA, etc. which are managed with third-party systems. These external activities may need
connecting to the SAP system. To do this, SAP Interface programs are developed to automate the
process.

An interface is essentially a channel between SAP systems and non-SAP systems. For example,
during shipping, an organization may use a third-party logistic system to pack and ship
deliveries. For this, SAP delivery information will be sent to the external third-party system.
Then the shipment information is received in SAP through a middleware.

These EDI communications are done through SAP Interfaces, and IDocs are used to transfer
data.

 Conversions

When IT implements or upgrades SAP systems, they will need to convert legacy system data to
loadable formats. These can then be converted into their SAP application. To upload this data in
the new SAP system, it needs to be converted from one form to another as per the system’s
requirement. This process is called SAP Conversion.

Conversion is important and needs accuracy, so it’s common that a separate team may be
deployed for this activity alone. To perform a conversion, teams will need to extract data from
their legacy systems. The project team then will upload that data into the updated SAP system
using data migration tools such as BDC, LSMW, LTMC, etc.

Client and technical teams will work with the functional consultant to write programs that read
data from those files. From here, they will be able to load it into the new SAP application. This
will then become another object in the RICEFW list.

Enhancements

SAP Enhancements are added if the business requirement cannot be satisfied using standard SAP
features. During large implementations, an SAP standard blueprint will be prepared and
followed. When business requirements cannot be achieved using a standard blueprint, project
teams will add some custom functionalities by modifying the solution – these are called
enhancements.

Enhancements are created by ABAP teams who make use of BADIs, enhancement frameworks,
or user exits. These will then become the RICEFW objects the project teams work with to
modify or leverage the SAP standard. Another option is to create new custom solutions based on
business requirements and target architecture.

An example of an SAP enhancement is to develop Radio Frequency Mobile Data Entry (RF)
capabilities at the Inventory Management (IM) level. Standard SAP has given the RF at the WM
or EWM level. When a client manages a warehouse on the IM level and is looking for RF
capabilities, the enhancement is needed to meet business objectives.

Forms

SAP forms are simply print outputs created by the SAP application after saving transactional
data. These forms can be the development of layouts for invoices, account statements, delivery
notes, purchase order print, etc. SAP Standard provides a template for all these forms.

If they do not meet specific business requirements (i.e. company logo or print legal text), the
functional team will need to work with ABAP to develop custom forms for each specific need.

Workflow

The last RICEFW object is SAP workflow. Workflow refers to the sequential flow of
transactional data from one level to another as per the organization’s hierarchy. At each level,
actions are required, and once taken, the workflow will advance to the next level.
During this objective, the functional consultant coordinates with the technical team to develop
custom flow logic. These will contain the details of the data to be sent and will provide the
conditions to trigger the workflow.

For example, budget approvals handling. A purchase order is created for a value and sent to the
manager for approval. When approved, it will go to the VP for further approval, and so on until
signed off. In this case, the business requirement is not available in a standard SAP application,
so the result is a new RICEFW object.

How is RICEFW used in a S/4HANA project?

Both, the Explore and Realize phases of the SAP Activate methodology require RICEFW objects
to achieve the specific business processes and goals. This is especially important during
S/4HANA transformation so that all customer-specific requirements are integrated into the
solution. This way, business users are able to perform their daily tasks using their SAP system.

The S/4HANA RICEFW objects are identified mainly during Fit to Gap analysis sessions which
take place during the Explore phase. This is where project teams identify which non-SAP
solutions need to be integrated.

During the Realize phase and testing activity, a cutover plan is created. This moves the
S/4HANA WRICEF objects into the production system which will eventually be used by the
business in real-time.

Conclusion
The creation of SAP RICEFW objects is a process during the Explore phase of the SAP Activate
methodology to identify third-party systems integrated within SAP.

The result of the RICEFW template is a customer-specific solution that meets the unique
business requirements identified earlier in the transformation process.

It is essential that SAP project leads and architects identify all the requirements so the business
systems and processes will run smoothly once migrated. Establishing and reporting to SAP CoE
proves to be very helpful.

Make to Order: Production is the process where the production order is triggered from a Sales
Order. Ex: The Prod process will start only after receiving the sales order from the customer.
Strategy group 20 or 50 will be used.
Make to Stock: The incoming customer requests are fulfilled from the inventory. That means
before receiving the sales order, we can start production through planned independent
requirement and keep it in inventory. The made-to-stock products are normally the consumer
products or products which sold out of the existing inventory. Such products are developed and
produced continuously over the years till the product comes to the end of its life cycle.

The difference between MTO and MTS is

MTO--> Make to Order

Production is the process where the production order is triggered from a Sales Order.
Ex: The Prod process will start only after receiving the sales order from the customer.
In this case the product could be customer specific only (Variant)

MTS--> Make to Stock

MTS scenario can be accomplished by the following settings:
- Need to use strategy group 20 in material master MRP view-Strategy group 20 is
assigned to strategy 20
Strategy 20 is assigned to Requirement type KE (Individual customer requirement)
- Requirement type KE is assigned to requirement class 040 (Indiv.cust.w/o cons.)
- Requirement class has all the parameters where we can define Production order type
that will be used to create th prod order. The above link needs to be established.

Also the MTS can be achieved using Sales Order schedule line category which will be
assigned to Requirement type/class. Item category is assigned to Reqtype/class and
the Item category is maintained in the material master.

You can use any of the above Config settings.

For MTO --> you just need to have all PP cycle settings in place nothing special
needed as it is a plain PP cycle.

1. Make-to-order production is a process in which a product is individually

manufactured for a particular customer. In contrast to mass production for an
unspecified market where a material is manufactured many times, in make-to-order
production a material is created only once though the same or a similar production
process might be repeated at a later time.

2. You can use make-to-order production in two scenarios -

(a) For branches of industry or products where a small quantity of products with a
large number of different characteristics are manufactured (Variant Configuration).
(b) When a product has to be assembled particularly for a sales order (Individual
Customer Requirement).
3. Stock keeping is not usually carried out for products that are made to order. In
companies using make-to-order production, the demand program only determines the
production area, in which various variant types are produced. Depending on how you
track the costs associated with make-to-order production, there are two ways to
process make-to-order items during sales order processing.
(a) Make to order using sales order
(b) Make to order using project system (not relevant for SD application)

4. For make to order production using the sales order, all costs and revenues involved
for an order item are held collectively at that item. A particular rule is used that can be
changed manually to transfer costs to profitability analysis.

5. Make to order production is largely a production planning configuration. It is also

controlled by the requirements type, which is determined by three things
the strategy group (MRP 3) in MMR
the MRP group (MRP1) in MMR
the item category and MRP type (MRP 1)

6. Make-to-order production is controlled by the requirements type. The requirements

type is determined on the basis of the MRP group (MRP1) and the strategy group
(MRP3) in the material master record. In addition, a plant must be assigned for make-
to-order items in the sales order.

Intra—We can transfer the stock from one plant to another where the plants belong to the
same company (i.e.Under one company code for Ex: HOFI)
• Inter/Cross- We can transfer stock from one plant to another where the plants belong to the
different company (Have different company codes).

MRP is a system designed to plan manufacturing production. It identifies necessary materials, estimates
quantities, determines when materials will be required to meet the production schedule, and manages
delivery timing – with the goal of meeting demands and improving overall productivity.
https://www.sap.com/dam/application/shared/graphics/mps-flow-graphic.svg

https://www.stechies.com/what-is-the-meaning-of-mrp-in-sap-pp/

Automatic Account Determination- MM-FI Integration

 Two ways of GL accounts – Source

Purchasing- GL account will come in PO automatically- Material and account assignment plays
a major role

Inventory-Goods Movement - GL account will be taken automatically as per the Material and
Movement type

Concepts/Terminologies to remember:

1. Material
2. Material type
3. Account category reference
4. Valuation class
5. Valuation area
6. Valuation grouping code
7. Movement type
8. Transaction Event Key
9. Account Modifier/General Modifier
10 Chart of accounts
1.Material

We will create/Order the material from the vendor and for that we need to maintain the material
in material master and along with that we are linking valuation class in accounting 1 view for
each material with the help of material type.

Link- Valuation class is linked to GL accounts in OBYC (Will study deeply below)

2. Material type

Material type plays an important role in account determination, where while creating material
type, we are mentioning the quantity/Value tabs and, we are maintaining the valuation class with
respect to material type in material master.

So that whenever we create material for that material type then automatically certain valuation
classes with appear to update the material in material master with the help of account category
reference (Linking will study below).

3. Account category reference

Account category reference acts as a mediator between the material type and valuation class,
where we will define the account category reference to create the valuation class and assigning
the material type to account category reference (A=B, B=C= AC)
If we have 10 material types, then we can create 10 account category references and each
account category reference will have certain valuation classes like 5 valuation classes (Based of
material groups how many we have under 1 material type).

But 1 material type will have only 1 account category reference.

E.g.: Account category reference – 0111(create New)

Account category reference-Valuation classes- RK01, RK02, RK03, RK04, RK05(Create

valuation classes)

Material type (ROH)- Account category reference (0111) (Link to Material type)
Now automatically material type ROH will take valuation classes - RK01, RK02, RK03,
RK04, RK05

Note: We need to mention the correct valuation class while creating material in material master
manually, so that respective GL will pick up (Will learn below how)-This step will be done by
MDM team, but we need to train them like on what basis we need to update the valuation class.

4. Valuation class

Valuation class is defined as for 1 material type how many material groups- Based on real
scenario
If we have 10 material groups under the category of 1 material type, then we will create 10
valuation classes and each valuation class will be linked to creation GL accounts (It may change
as per your organization rules)

We need to select the correct valuation class depends on the material; MDM team will take care
on this how to update.

5.Valuation area

As we know all the organizations will evaluate the material in plant /Company code level and
SAP recommends valuating the material in plant level because price may change plant to plant as
per the state and specifications.

We need to check the option that valuation area at plant level and we cannot change it once its
defined in enterprise structure.

6.Valuation grouping code

We have certain plants having same attributes with same account determination, so all those
plants will combine and create a valuation grouping code.

We will make all those plants to one grouping code and assign GL accounts as per that so that it
will reduce the number of entries in OBYC settings.
So that all that plants will trigger same set of GL accounts with the help of Chart of accounts for
the entire grouping code.

If we require a separate GL account system, then we need to create a new valuation grouping
code it means 2 grouping codes for same chart of accounts with different GL accounts in OBYC.

Generally, for 1 valuation grouping code, we may create 4-5 different or same accounts in
OBYC (FI Consultants will do this) because we may have different types of procurements like
sub-contracting, Consignment, Pipeline, Goods transfer.

We can achieve the above step with the help of general modifiers (Explained below thoroughly).

7.Chart of accounts

Here chart of accounts contains a certain GL accounts, where INT contains all GL accounts and
as we maintained valuation grouping code for similar plants then automatically all those plants
will come under the chart of accounts INT.

Depends on the procurement order type GL account will take automatically.

8.Movement type

As we explained in starting page of blog, GL accounts will be triggered when we are doing
MIGO, so movement types are linked to general modifiers and these settings are standard and
every organization will follow the same settings as SAP recommended.

Every movement type is linked with certain general modifiers and transaction event key.
Note: Modifiers can be allowed only for GBB and PRD.

Some of the general modifiers are VBR, VNG, VBO

As per the procurement process like sub-contracting, Consignment, Pipeline, Goods transfer
these general modifiers will come and hit the respective GL accounts.

9.Transaction Event Key

We have a predefined transaction event key like BSX, WRX, GBB.

It mainly explains BSX-Inventory postings, it will store GL accounts that related to stock
updating or removing from plant and whenever we are adding stock or removing stock then
respective GL account will pick from BSX- Its mainly for inventory addition and subtraction.

WRX- after doing the normal inventory addition and subtraction the vendor should get paid and
for that we have WRX-GR/IR clearing account.
So, when you do a normal PO-BSX and WRX will affect for the purpose of inventory and GR/IR
clearing purposes.

GBB- Where we have many procurement types like sub-contracting, Consignment, Pipeline,
Goods transfer- there we have different modifiers should effect because we may pay or not
because few are internal transfers and some should be like consignment and sub-contracting and
few are goods issue to cost center- this may be different type of stock gets credited.

For this we have modifiers linked to movement types and each procurement type we have
different movement types and its linked to account determination, so that respective modifier
will affect.
We have transaction event key- PRD which is for price difference.

When we maintain the material master price indicator as S-Standard price, then if PO is created
with different price then difference price amount will be posted for PRD level GL account.

Even we have separate condition prices in PO- so it will affect the respective GL accounts as
predefined by SAP- Just learn which is affecting like BSX, GBB.

10.Account Modifier/General Modifier

Account modifier is possible for GBB and PRD

When we are creating MIGO with movement type and once you enter details, system will read
K,O,W,P,Q- Special stock indicator, in settings its already defined for plant valuation area to
strings and transaction event key and next to that we can find modifier.

It means when we are doing special type of procurement activities – Modifier accounts like BSA,
VNB, BSA and VBO will get triggered.

Process- Backend (SPRO Settings)

Step 1: Define valuation control

Here we are defining valuation is under grouping code or not

Most possible 99% we will go to group together valuation area.

Step 2: Group together valuation areas:

Here we are assigning similar plats to one group and for this group GL accounts are assigned in
OBYC.

Here we can also find the chart of accounts, where it will be defined by SAP and we can
maintain 1 chart of accounts to 1 valuation grouping code or 2 valuation grouping code.
If 2 valuation grouping codes, then we need to define the different GL accounts for the second
grouping code.
Here Chart of accounts contain the GL accounts along with grouping code and modifiers-Check
in OBYC.

Step 3: Define Valuation Classes:

3.1 Here we will define the account grouping code as per the material types

3.2 We will define the valuation classes for this account category reference- Valuation classes
are like material groups and create as per the company requirements.

3.3 Here link the material type to account category reference, we can assign to N number of
material types

Whatever the settings have been done- the requirements are like while creating material the
valuation class should come automatically as per the material type

Because we defined account category reference to valuation class.

Step 4: Define account grouping for movement types:

Here the settings are standard and no need to change

Here we can find the movement types with types of procurement of material and transaction
event key has been assigned to all those and next we can find the account modifier which we will
enter if the procurement type is different.

Don’t change these settings unless you are creating new movement type which is very rare.
Step 5: Configure automatic postings: OBYC- Done by FI Consultant

Here they have standard transactions and they will maintain the GL accounts as per Valuation
grouping code and modifiers.

STO Process – MM STO/Intra /Inter STO (MM-SD Integration

STO- Stock transport order

Concept:

Every company will be having many plants and even they have same kind of materials for few
kind of production activities, every time procuring from vendor is time consuming and even
money because one of the other plant having those stocks without usage, so to save money for
the company we use STO process.

SAP has been recommended STO type order “UB” for internal procurement purpose and we can
have goods moment within company to company and plant to plant.
 STO-There are 5 kinds of STO
1. One step Method between two plants
2. Two step Method between two plants
3. Stock transfer between two plants without delivery (MM STO)
4. Stock transfer between two plants with delivery without billing (Intra STO)
5. Stock transfer between two plants with delivery with billing (Inter STO)

1.One step Method between two plants:

One step method means -the supplying plant will transfer the goods to receiving plant and
posting goods movement accordingly by supplying plant,

Like using 301 movement in MB1B, the member will transfer the goods to other plant.

2.Two step Method between two plants:

Two step method means- the supplying plant will transfer the goods to receiving plant and now
once they transfer the goods to receiving plant it will get posted in Transit in order stock and
when the receiver sees the stock in plant then receiver will post the other movement to move
from in transit to plant stock.

Supplying plant will do 303 movement type in MB1B and receiving plant will do 305 movement
type in MB1B.

3.Stock transfer between two plants without delivery (MM STO):

This process is also called as MM STO, but many of the companies will use intra or inter
process because of more features wrt stock.

In this case the respective receiving plant will creates a PO, with details mentioned as from
which plant and stock required and all the details.

PO will be created with document category UB and item category as U, so that it’s a inter STO
PO created for internal stock movement.

Once the PO is created will give to the supplying plant and the from the supplying plant there is
a goods movement done by plant person.

Using movement type 351-MB1B, movement of goods will happen once we create PO.
Now the goods will be in in transit and the receiving plant person will be doing MIGO wrt PO,
so that stock will show as unrestricted stock.

4.Stock transfer between two plants with delivery without billing (Intra STO)
Inter STO also have the same features as I mentioned below, whereas here the stock transfer is 2
different company codes with different plants and each from one company code.

Here we require help of SD Consultant, whenever you were creating STO PO, we need to take
help of SD consultant. Stakeholders need to inform the receiving plant, so that they will be
creating the customer code for that particular plant and maintain some distribution channel
accordingly for that, As a SAP MM Consultant we need to maintain the backend settings for the
receiving plant, so that will get shipping tab in the PO for that particular receiving plant.
This type of process is called MM-SD Integration

**********We cannot perform 3rd scenario if we are working 4th as present, to work for 3rd
scenario we need to delete the settings for 4th step and process always*********

Requirements

We need to ensure that material that we are shipping from 1 plant to other plant should be
extended in material master for both the plants.

Both the materials should have sales and purchasing and accounting views mandatory.

Sales data will be given by SD Consultant and if not, we can request SD Consultant to give the
sales data to update for the material master.

Ensure to select all the 3 sales views and maintain the important data required in all the 3 screens
to avoid SD errors.

In Material master we need to maintain the standard language for those receiving plants-
Additional Data-Languages, Maintain the language like DE_ Germany

Ensure stock is there in supplying plant, or else we will get error in OBD-Outbound delivery

Back-End settings for Shipping (Intra):

To get shipping tab details in PO, we need to maintain few backend settings for PO-STO

SPRO-
Materials Management-
Purchasing-
Purchase Order-
Setup STO

(!) Define Shipping data for Plants:

Here we need to define the shipping data for plants, maintain the receiving plant details like -
double click on receiving plant-Enter Customer number, Sales organization, Distribution channel
E.t.c.

All the Above information will be given by SD Consultant.

Enter all the details and save the screen.

(!!) Assign delivery type and checking rules:

We need to maintain the delivery type and some checking rules for this step.
Order type as Order type-UB
Supplying plant-
Delivery type- NL(Intra)
We have 2 delivery types NL and NLCC
Checking rule maintain as 01

(!!!) Assign Document type One step Procedure, Under Tolerance

SPL plant –
Rece plant-
Order type-

Once we done all this correct -PO will take shipping tab automatically for this scenario.

Process:

We have done with backend settings, now create PO- Me21n and mention the purchasing
document as UB and item category as U.

Enter the material, shipping plant and receiving plant- enter the quantity and other data-PO will
pop up a Shipping tab with NL order type.

Now let’s think shipping pant is having stock to create OBD.

OBD is the process where shipping plant will create a delivery invoice in which material will be
adjusted to move out to receiving plant.

VL10D-Outbound Delivery

Open VL10D and Purchase orders- maintain the purchase order and check the dates the PO
delivery is between that dates and execute -so that it will take to quantity screen and select line
and go to background.
If you want to check the log- check and take the OBD number or else if any errors found, try to
resolve.

PGI-

Once the OBD is done, the supplying plant should issue the goods to receiving plant, for that
they require PGI-Post goods issue.

PGI will be done based on OBD quantity and same will be moved as intransit.

VL02N-PGI will be done with OBD reference number – just take the picking tab and mention
the quantity as OBD posted and post PGI.

Once PGI is posted, goods will be moved to intransist and we can see in MMBE stock report-in
transist.

If we check for movement type happening its 641 and once everything is done and goods
received to plant, then post MIGO

Following with MIGO with OBD and not with PO, Post MIRO and this Intra goods concept has
been end.

*****there will be no billing for with in company code transfers **********

5.Stock transfer between two plants with delivery with billing (Inter STO)

Inter STO is also same as intra STO, whereas we have little different because vendor (XK01) is
involving in terms of supplying plant.

Why we are involving vendor, because they should be billing to be done to supplying plant from
receiving plant.

Inter STO is also called as MM-SD Integration

Because higher level credits and debits will be involved for company code level, here two
different company codes, so billing should TAKES PALCE.

We will be creating material as normally and maintaining in both the plants as we did for intra
STO by maintaining sales data for both.

Now create maintain a vendor and inside purchasing data -maintain for plant as supplying plant-
once you enter vendor in PO -it will take supplying plant backend.

Requirements

Material (SP+RP)
Vendor-Purchasing to plant as SP
Customer number from SD Consultant

Back-End settings
Define shipping data for plants

Maintain the receiving plant customer code and remaining data that received from SD Consultant

Assign Delivery type and checking rule

Here we re creating PO with Document type NB- because vendor is involving indirectly
NB document type
Item category -Standard

Assign Document type One step Procedure, Under Tolerance

Document type is NB-mention the shipping and delivery plant and save the back-end settings.
Process

Now we can create a PO, with NB document type and blank item category, whereas we already
maintained vendor as plant in XK01.

Now as per the backend settings and XK01 vendor mater shipping tab will come automatically
with delivery type NLCC

Now post OBD-Outbound delivery, VL10D-proceadure has been explained above

Now post the PGI-Post goods issue with respect the OBD and once PGI is posted goods will be
in intransist.

Now do the billing for the plant to which we are sending through VF01 and this implies with
billing from the respective cost center.

Now we can do the MIGO with respect to OBD and following with MIRO.

Difference between Purchase Organisation/Standard/Referenced along with Mass maintenance

1.Purchase Organisation:

Purchase organisation main responsibility is to maintain the proper purchase related

activities and they will take care of all requirements for that plant/Company code as you assigned
in the organisation structure.

Each purchase organisation has been linked to 1 plant (Plant wise) or 1 company code (Company
code wise) or Client wise (1 purchase organisation for the client).
When do we maintain 1 Purchase organisation?

When we have the company worldwide and even vendors are also in worldwide who is
supplying for all countries then we can maintain the centralised purchase organisation-where it
controls all terms and negations for all the plants in the world.

This is the normal way for all the companies maintaining purchase organisation.

Cons: we cannot get the individual data of one country and if getting its too hard to calculate
purchasing activities.

This is called centralised purchasing- once purchase organisation controls centrally for all the
company codes.

When do we maintain 1 purchase organisation for 1 company code?

We will maintain the purchase organisations as per the company code, it means 1 purchase
organisation = 1 company code.

Where we have many vendors, but they can provide with in the country and there was no import
and export then we can maintain individual purchase organisation as per the company code.
In this case each company will be having 1 company code.

This purchase organisation will manage the all the plants in the respective company code, it
means all the purchasing activities.

Same purchase organisation needs to be maintained for all the plants in that company code, in
this case reporting will be easy and managing also easy but you will not get more discounts.
maintain 1 purchase organisation for 1 plant?

We will maintain 1 purchase organisation for 1 plant, where purchase activities will take in the
plant itself and it can control only that plant.

If we have 1000 plants around worldwide then we can have 1000 purchase organisations.
This is called distributed purchasing

When do we maintain 1 purchase organisation for 2 plants with different company codes?

As we know we cannot maintain 1 purchase organisation for 2 company codes.

Then we can get succeed through plant level, where company code A contains 1 and 2 plant with
purchase organisation controlled by X.

Now, company B contains 3 and 4 plants with purchase organisation controlled by Y.

Now we need to assign 1 purchase organisation for 2 plants which was controlled by 2 company
codes.
Assign plant wise, as systems allows that 1 plant can be controlled by 2 purchase organisations,
then in plant wise maintain the 2-purchase organisation (Setup in enterprise structure)
So that 2 purchase organisations controls different plants with different company codes.

2.Standard Purchase organisation:

Standard purchase organisation is same as normal purchase organisation, where in normal

purchase organisation the plants will not be used to other activities like consignment and pipeline
procurement.
If the plants are using different procurement activities like consignment and pipeline then the
plant should me maintained by other purchase organisations, in that case we can define that as
standard purchase organisation.

Standard purchase organisation will control mainly for consignment, pipeline and other special
procurement activities.

3. referenced Purchase Organisation:

Referenced purchase will be used for contracts and scheduled agreements purposes.
Lets think we have a contract that is having some company code and all the plants in that
company code, now even some other purchase organisation also use this contract because you
have some less prices in contract, then in that case we need to maintain the different purchase
organisation, different company code plants we should use in contract.

We cannot maintain directly in that contract, because it will allow only 1 company code and 1
purchase organising plants only, now we need to maintain the referenced purchase organisations
with purchase organisation.

Once we maintain that linking in enterprise structure then system will allow to maintain those
plants in contract, and it can be released through contract to orders.

We need to do all this setting in enterprise structure.

Basics in Enterprise Structure for Learners

As a MM consultant we will not define full implementation, here client and company code will
be created and maintained by FI Consultant

MM consultant will define only Plant, Storage location, Purchase organisation, Purchase group.
Plant: while we are defining new plant, system will ask for factory calendar settings number-
defined by PP consultant.

Once we maintain all the assignment then we can check the flow in EC02, whether the flow has
been maintained correctly or not.
 If we are creating plant then we will create few plants which will be used for STO purposes then
we need customer number to be maintained for Intra STO, in that case SD consultant will
prepare and send it to us.

Plant: we must copy the plant as always from pre-defined plants by SAP, because we have many
settings backend if we have created new but knowing is good for your knowledge.

Material Statues and Mass maintenance in SAP:

As we are creating material master will create many materials and all the tabs related to MM
needs to be updated by us, in this case we have few tabs -controls the materials for many
activities. For example, purchasing block, inventory block and many more.

We have options in 2 levels

1. Purchasing level
2. Client level

First, we need to define our own material status as per the client requirements in the path below.

SPRO-Logistics general- settings for key fields- define material status

Define our own name and select the level of block like only for purchasing or only for inventory
or else both.

Its goods to have individual blocking codes, so that there is no clubbing.

Basic data- always in client level and if we maintain X-plant material status then it applies for
whole plants in the client.

Purchasing tab- when we maintain X-plant material status then its will be applicable for only 1
plant as we maintained.

Mass Maintenance

We will create lot of materials and if we get requirement to update certain fields for all those
materials then we cannot do all those manually.

For those things we have mass maintenance, where we have certain T-codes from where we can
do that activity.

For these things we should aware of table names MM, so that we can maintain at a time.
As per tab wise table name will get change – Material master try -MM17
For vendor master try – XK99
 Note: if we don’t know that from which table, we need to maintain these things then try for T-
code MASS, where select the activity as per that and process accordingly.

Import Procurement full overview explanation

•Procuring of goods from US to India or any other places

India to USA
•Currently India is using GST, so there are no different condition types will trigger
•Whereas in case of different country, the condition types for customs will come into picture
•Remove the tax code or maintain it to 0% and maintain the vendor to unchecked GR based IV
•Customs Clearance vendor will be different/Same as per the company requirements

•But if the customs vendor is different then IV needs to be posted before GR and that should be paid
•Once material received to plant then GR and following with IV will happen

•Orders or u can use even same normal doc type(Preferred to use different)
•Material master—Foreign trade import tab –Fill details what type of products /region and Origin
•Vendor master—remove the GR based IV check for vendor or Invoice tab
•Check calculation schema whether import condition are maintained to calculate charges in PO
•Perform PO with all the details and do the Invoice with planned delivery costs
•Now perform the Goods receipt and Invoice receipt for normal goods
•Payment will release to vendor and prior payment of customs will be processed to vendor.
•This completes Import type of procurement

Release procedure for Purchase requisition

Release procedure defines, how the document is going to release. The document can be PR, PO,
Contract, Scheduled agreement, RFQ. Here we study about the purchase requisition.
Purchase requisition will be created by the respective stake holders of there plant, if a request is
created it will go to buyers Que to create purchase order and before that who ever is created
purchase requisition he should approve and after that respective manager should approve.
We can create an N number of approvers for the documents like PR, where as an SAP MM
consultant its their duty to maintain the release approvers.
We can maintain the release process for respective documents also.
Eg: we can maintain the release strategy for plant or material group also.

Release procedure:

we have 2 types of release procedures, defined below.

1. With Classification
2. Without Classification

1.With Classification:

We have 2 sub-terms in with classification.

Where we can release these documents in Document header level or Item level as per our
business requirement.
 1.Header Level
2.Item level

Header Level:

Header level contains PR, PO, Contract, Scheduled Agreement, RFQ

Item Level:

Item level contains PR.

2. Without Classification:

Without classification we have only 1 type of release process

1.Item level

Flow-chart for above 2 Classifications

Release procedure--
With Classification--
Header --- Item--
PR, PO, Contract, SA, RFQ
PR
Release procedure--

Without Classification--
Item--
PR

To maintain the release procedure for particular document types in SAP MM, we have communication
tables/Structure for document types, mentioned below

Document type Communication table

PR- CEBAN
PR, PO, CO, SA, RFQ CEKKO
SES CESSR
 In the above-mentioned communication tables are used to know the details for respective document type
field component.
We have T-code to help to find the component for the respective field in the communication table, that is
SE11, where we can only display the data (ABAP Data), its mainly used to find the component for the
document type with the help of communication table.

Eg: CEBAN is used for PR, if we are maintaining the release procedure with respect to plant than we
need to find the respective component for the plant filed in PR.
So, go to SE11, maintain the communication table as CEBAN if you are working for PR or else you can
maintain CEKKO, CESSR for the remaining data field components.
As mentioned in the example, we have only one condition (Plant) to maintain the release strategy, if I
would like to maintain the release strategy with combination of conditions then we need to define as
mentioned below.

Note: Important Note: 1 condition = 1 Characteristic

2 Condition = 2 Characteristic

Note: Maintaining the release strategy we need to follow the below steps.

1. Edit Characteristic
2. Edit Class

3. Setup procedure with classification

1. Release Groups
2. Release Codes
3. Release indicator
4. Release strategies
1. Release prerequisites
2. Release statues
3. Classification

Path to go to above release procedure (OLME)

SPRO--
IMG--
 Materials Management--
Purchasing--
Purchase requisition--
Release procedure--
With Classification—

Practicing:

Now will maintain the release procedure with respect to purchase group and Item category.
Follow the steps as mentioned above:

Edit Characteristic:
Where 1 condition is equal to 1 characteristic
We have 2 conditions here (purchase group and Item category), so we need to maintain 2 characteristics
in the path I mentioned above.
OLME-With Classification

Characteristics: M1(Enter M1 and check whether its maintained already or not by clicking specs icon),
if not created already then click on create icon next to the spec.
Here we should maintain the field components (Purchase group and item cat from SE11)
Go to additional data and maintain the table name as: CEBAN
Go to SE11 and take the field components by selecting the Purchase group and item cat.
P.group-EKGRP
Item cat-PSTYP
Now in this characteristic, we need to maintain either P.group filed component or Item cat component,
because we mentioned above 1 condition =1 characteristics.
Maintain field name as: PSTYP

Now create an another characteristics for P.group

M2(Enter M2 and check whether its maintained already or not by clicking specs icon), if not created
already then click on create icon next to the spec.
Here we should maintain the field components (Purchase group and item cat from SE11)
Go to additional data and maintain the table name as: CEBAN
Go to SE11 and take the field components by selecting the Purchase group and item cat.
P.group-EKGRP
Item cat-PSTYP
Now in this characteristic, we need to maintain either P.group filed component or Item cat component,
because we mentioned above 1 condition =1 characteristics.
Maintain field name as: EKGRP

Note: Now we maintained the two characteristics that we want to use for release strategy.

Edit Classes:

Here we should define the class for characteristics, where we maintained 2 characteristics and we cannot
maintain all characteristics directly to release strategy.
We need to define a class and we need to link all the characteristics in that class, so that in the next steps
we can use class instead of all characteristics.
Go to Edit Class-
Class-M3
Class type-Release strategy
Click on create icon
Maintain the description as “Something relevant like this is for PR to convert to PO”
Go to characteristics-maintain the both Char numbers we created above.
M1
M2
Save

Select “setup procedure with classification”

Here we need to do some functions like-release groups, release codes, release indicator, release strategies.

Select-Release group:

We need to maintain a new group in release group and we need to assign the class to this release group
M4 (Newley created group) assigned to M3(Class we defined)
Save

Release Codes

Maintain the release codes.

Group we maintained is M4-code is CR and maintain the description.
Here if we want two approvers then we need to maintain 2 column’s M4 and next to maintain CR-creator
and MN-Manager and maintain the description as same.
M4-CR
M4-MN

Release Indicator

Maintain new entries, where we need to maintain the Block and release fields here
B-Block
R-Release

Release Strategy

Maintain release group what we maintained-M3 and release strategy number as 10.
Release codes-Mention
CR
MN
Select Prerequisites—
 Select the last tab and continue—

Select release statuses---

Select the last tab as R-so that once we get all approvals PR will allow to create PO.
Select Classification
Item cat-Z
P.group-000
Maintain few values for the fields we defined for release strategy.
Now create the PR with above combination, we will see a new tab in the item level…. Release strategy
Go to ME54N and open the PR and release the PR to create PO.

Pricing Procedure and Price flow process in PO-- SAP MM

Pricing procedure: pricing procedure defines the price flow process in purchasing document like
PO, we can define a pricing conditions as per our needs and requirements and maintain +/-
accordingly.
Price flows into purchase documents with the help of access sequence- where access sequence is
a 3-digit key and consists of sequence of some purchase documents like Contract, PIR with
plant, scheduled agreement.
Based on the access sequence the price will go and enter in PO from contract or PIR or
scheduled agreement.

few basic concepts need to know before entering in to pricing procedure.

1. Access sequence
2. Condition types
3. Condition table
4. Calculation schema
5. Schema group
6. Schema determination

On what basis pricing conditions flow into PO.

Based on Vendor and purchase organization.

4.Schema group

Schema group: grouping all international vendor into one grouping pricing condition called as
schema group

Explanation:
 we all know, in procurement we will deal domestic and international vendors and pricing
conditions are different as per there location like discounts, tax and net calculation and for
differentiating those price we need schema group(which will be assigned to vendor) and 1 more
schema group for purchase organization.

SPRO-
Materials Management-
Purchasing-
Conditions-
Define price determination process-
Define schema group-

Schema group- vendor

Schema group- purchase organization
5.Schema determination: Assign schema group to purchase organization

Schema group- vendor:

Here we will define a schema group based on vendor location like either its local or
international.
We need to assign the schema group to vendor in vendor master-Purchasing data-schema group.
We will be assigning to all the vendors which was created in the SAP for the procurement
purpose.

Totally we will define 2 schema groups for an organization, 1 is for local and 1 is for
International.

Schema group- purchase organization:

Here we will define schema group for purchase organization, in which we will assign calculation
schema with schema group

Basically, we have RM0000 as a default condition and based on that we will define a new
condition and assign to schema group for purchase organization.

Assign schema group to purchase organization:

We will link schema group to purchase organization and schema condition-calculation schema.

Now, based on vendor schema group and purchase organization the condition-
calculation schema will be defined automatically.

Pricing flow procedure- from contract, Outline agreement and PIR Overview:
 1.Access Sequence:

SPRO-
Materials Management-
Purchasing-
Conditions-
Define price determination process-
Define Access sequence-

We all know, price will flow into PO from Older PO’s or PIR or Contract.

But where this is defined and how the system is taking priority like this, this can be achieved by
access sequence.

Where we will maintain the access sequence with this condition like below.

1. Scheduled agreement
2. Contract
3. PIR
4. Older PO’s

Based on this sequence, price will be picked in PO automatically.

Because access sequence is always linked to condition types like PB00.

PB00 is a condition where gross price will be calculated for auto PO’s- so we need to maintain
an access sequence and link to condition type.

1 condition type can be linked to 1 access sequence only.

2. Condition types-

SPRO-
Materials Management-
Purchasing-
Conditions-
Define price determination process-
Define Condition types-

Condition type defines the debit or credit or discount (+/-)

Few of the condition types are PB00- Gross price

PBXX- Gross price manually

FRA1- Freight charges
ZA03- Discount
Condition types are mainly 4 types-
Basic price
Discount
Tax
Freight

If we are defining new condition type, then always copy from standard condition types

Like for net/gross- copy from PB00

For freight related- Copy from FRA1
For surcharge related- copy from ZA00

3.Calculation schema:

SPRO-
Materials Management-
Purchasing-
Conditions-
Define price determination process-
Define Calculation schema -

Here we will define a schema condition in which all the price condition types will be maintained.
Will define all condition types like Gross, friend, Discount conditions

1.Step- indicates the sequence

2.counter- Indicates the sub in the sequent
3.Condition type- define the condition type required
4.from- if it’s a net/gross price- then we need to maintain the excel formula to calculi like 10:10
5. To- if it’s a net/gross price- then we need to maintain the excel formula to calculi like 10:10 or
10:20
6.Manual- Means we need to maintain the field in PO manually
7.required- It means the condition type is mandatory.
8.Statistical- It means it will be there but 0 price also, no problem.
9. printing control
10. subtotal field – press F4 and select the total number like 9.
11. Requirement
12.Cal. type
13.Bastype
14. Accrual Key- If any new account key effect is there then we can mention it here
15. Accrual account Key

3.Condition table:

Condition table is a 3-digit key, where we fill update the sequence of condition to be
impacted in the condition record like PB00.
Here we will update the sequence of combination like material, vendor, plant, Purchase
organization.

Once we have updated the conditions, system will check for any master data which contains
price and update the same condition in PO.

Material
Vendor
Plant
organization

Final Overview to understand the pricing procedure:

Price flow process:

Condition fields- Material, vendor, Plant and Purchase organization

| | | |
Condition table: 017
|
Access Sequence: 0002
|
Condition types: PB00
Calculation schema: ZRM0001
flow from condition fields which will be maintained in condition table.
Access sequence tells from which sequence price should take either from contract
or PIR

Condition types will be always linked to access sequence, so PB00 – linked to

0002
Calculation schema would be implemented by vendor and purchase organization
setup.
Consignment Procurement and Pipeline process in SAP MM

Consignment:

Consignment is a process of material procurement from the vendor, but stock lies in plant
premises, but owner of the product is vendor, even its same process of creating normal PO but
item category is K.

Concept:
Normally we use to purchase the stock from vendor, in this case we will purchase the stock, but
we don’t know when we will use that stock for the production. So, for that we have SAP
recommended procurement process-Consignment, where stock keep in the plant and there is
premises for vendor -we can call as vendor consignment stock, whatever the stock present in
plant the owner will be vendor and when we require any stock then we can move that stock from
vendor consignment stock to production stock and we will post MRKO instead of MIRO, so that
report will be generated for the transfer stock and vendor will get paid for that.

If we withdrawal any stock from vendor consignment stock like 5 PC, then MRKO will be done
with 5 quantity and vendor will get paid for 5 PC.

The refilling process will be done by creating a PO with account assignment K for only filling
the gap stock.

PIR:

If we are creating consignment PO, then few mandatory things are PIR. Where price and tax
code will be calculated from PIR itself, because we don’t have price in PO.

The reason we don’t have price in PO is -Price will get fluctuate every month and stock lying
with us we will use, and we don’t know when we will use that stock.

Every month price will be given by the vendor for the material and purchasing team will update
the price in PIR and when the stakeholders do MRKO, the price will be picked from PIR for that
month.

One mandatory thing is PIR should be created to subcategory Consignment.

Process:

Create a material, vendor and PIR-mandatory and create a PR with this thing with item category
K-consignment.

Once we create PO for the above PR, the stock in MMBE shown as In-order Consignment stock.
Then once you receive the goods to plant then do the MIGO for full quantity.

Now check the stock for the material and plant in MMBE, it will show as stock lying with
vendor as vendor consignment stock.

When you do MIGO, the movement type will be taken automatically 101-K, where it’s a
consignment.

Here coming to accounting data- there is material document created but there is no FI document
posted.

Now as per your requirements we need to transfer the goods from vendor consignment stock to
our own stock by movement type 411-K
Now will stock will be lying in unrestricted stock

If we do transfer for 5 PC then we need to do MRKO for 5 PC, so that Invoice will be posted
automatically for 5 PC and vendor will get paid for 5 PC.

Whenever we do stock transfer from vendor consignment stock, we need to do MRKO.

If we want to move from vendor consignment stock to direct production/cost center and
department, then we need to know their cost center so that we can transfer goods directly from
vendor

consignment stock to cost center by movement type 201 K or 261 K

While moving vendor consignment stock to direct production/cost center and department a
material document as well financial document has been created with BSX and WRX.

Whenever there is financial document is created then GL account will hit for debit of their
respective cost center GL account.

We can do initial posting of goods to any plant by T-code MB1A -561 movement type, normally
we will do this when client is using different ERP and transferring to SAP.

Same as above we have MB1B for the goods movement from 1 place to other

We have MB1C for Goods issue, we can also have goods receipt without PO and for also free
goods.

Running cycle for Consignment:

Let think now we have a requirement for some materials, but we don’t know when we use these
materials fully, in that case requester has been ordered for Consignment -Created a consignment
PR 1164 with 100 PC.

Now the purchasing team will create a PO 2264 for the PR 1164, few of the mandatory things
are PIR with subcategory K -quantity 100 PC.

Once we create PO, the stock will show in MMBE-Consignment stock for that plant as 100 PC
Once we receive the material to plant the respective receiver will post the GR in MIGO-sating
material has been received to plant and placed in consignment stock (Posting MIGO for full
quantity-100 PC).

Now the stock will show in vendor stock in MMBE as 100 PC

Now check for FI postings- because vendor has been delivered goods to plant- in normal case a
Material doc and FI doc will be created automatically.
In this case, we have only material stock gets posted, and FI doc will not be created because it’s
a consignment- stock lying in vendor consignment stock.

Process has been completed for procurement, now the actual process will come into picture.
ordered material is for production requirements, now the stock is in vendor consignment stock
and we need to use for own purpose or industry purpose.

In this case, we need to use “Goods transfer” from one stock to other stock with the help of
movement types.

We have already stock in vendor consignment stock in our plant, so just we need to move to our
own stock by using movement type 541(vendor consignment stock to own stock)

We can also use 201 K and 261 K for directly move the stock from vendor consignment stock to
cost center which are using those goods.

Once we do the goods transfer the stock will get moved to plant own stock, once we do this a
material document has been posted along with that there is a financial document has been
posted(because we are using vendor consignment stock and we need to pay to the vendor).
Just think we have moved only 10 PC instead of 100 PC.

Now we need to do the MRKO process, where we need to mention the material and plant the
select the settle option which are not settled.

Once we do the MRKO for 10 PC, then APAY will run the cycle and match the reconciliation
quantity and vendor gets paid for 10 PC.

Whenever we use the quantity from vendor stock, we need to do MRKO, so that vendor will get
paid.

Why MRKO and Why not MIRO?

Because in MIRO, you cannot post the split price. We need to do full invoice.
Whereas in MRKO, we can do split invoice.
Pipeline Procurement:
Pipeline procurement is the process where, material will be flowing from the vendor premises to
plant premises, and there is no material is listed in inventory and we cannot measure the stock
anywhere in MMBE or other T-codes because its flow like petrol, current and coming to
payment its similar to consignment.

There is no PR and PO required for pipeline.

But PIR is mandatory for Pipeline material and while creating material master we need to select
the material type as Pipeline material.
Update the PIR price and tax code or else we can receive an error in MRKO posting

Coming to enterprise structure – Standard purchase organization must be linked to this plant,
because we are doing special procurement and always for special procurement plants, it must be
linked to standard purchase organization.

Process:

Whenever we require any quantity from pipeline and process the MRKO, just we need to release
the quantity and coming to power usage, we need to maintain MRKO on monthly basis as used
power watts and vendor gets paid for that.

We can take the goods directly in plant and coming to SAP we have movement type 201 P and
261 P to maintain the goods issue.

Once goods issue is done as per the usage, we need to post the MRKO as settled for unsettled
usage.

Few Important points to be noted:

Tax code in PIR will be defined by SAP FI consultant, and if we require then raise a ticket for
them and get the tax code and assign in PIR.

We will not do MIRO for consignment and pipeline and instead of that we use MRKO, where
backend FI document has been created for the payment purpose.

Once the invoice is posted in normal PO’s then we need to do credit note only if any issues
found and after cancel the GR and repost.

Any extra pay for vendor we needs to use the subsequent credit to vendor and directly we cannot
maintain in MIRO.