Central Finance: Challenges in Finance Transformation

There are many business cases for S/4HANA Adoption for existing SAP Customers. However, the journey to S/4HANA Business Suite is fraught with its own challenges which are inevitable – the costs and risks of migrating and upgrading to a new system, especially for those customers, who have built very complex and distributed landscapes spanning across geographies and businesses.

One element of S/4HANA, which has caught the imagination of many of the Global Customers is Central Finance, which has been projected as the “Smartest”, “Fastest”, “Simplest” way to latch on to S/4HANA bandwagon with a quick win of simplified and unified financial reporting structure. The approach of Central Finance, instead of forcing customers to migrate their SAP instances to S/4HANA Application, allows financial documents to be replicated into a new Central Finance instance running on S/4HANA Business Suite. This is particularly true for Customers who have multiple old SAP ERP Instances and non SAP Systems as well. This gives an organization wide financial reporting view, with minimal intervention to the Transaction Processing Source SAP and non SAP Systems. It has been claimed to be a quick win solution for all the Enterprise Customers of SAP, with extremely short turnaround time for adaption.

However, there are series of multiple challenges, which need to be considered in implementation of Central Finance. Some of them can dearly cost the S/4HANA Journey and cost thousands of dollars in terms of effort and missed objectives. Some of the business related challenges and technical product related challenges that I have encountered in my journey on Central Finance Project are below:

1. Organizational Structure: One of the biggest use cases for central finance is to look at harmonized reporting for multiple markets. A logical extension of central finance on S/4HANA is to use the same CFIN System as a future Business System with integrated Finance and logistics transaction system. Therefore, it makes the organizational structure design extremely critical. In one of my projects, the customer in the legacy ERP (Source SAP ERP Systems) was using Business Area, Segment, Profit center etc as key considerations for reporting. Additionally, the Logistics Org Structures like Sales Org were not having in synch in various Source ERP System, as well as non SAP Source system did not have the org object which were relevant from SAP standpoint. As an IT Strategy roadmap, the customer wanted all the markets, where it operated to be on S/4HANA Business Suite and CFIN was the starting point. Additionally, many of the org structures were used in Account Based COPA in CFIN. So the Organizational structure design is a very crucial factor for long term journey and it is critical that design of org structure is thought through in CFIN. This should take into consideration the future logistics org structure as well

2. New GL and Document Splitting in S/4HANA Central Finance: Document splitting and parallel ledgers functionality is one of the key asks from Finance Transformation for a large scale Enterprise level customer. Many of the customers might be using a source system without functionalities like new GL or Document splitting, but would want to use the S/4HANA CFIN with these functionalities. However a source system without Document splitting for eg and a target CFIN System with Document splitting is NOT a functionality which is supported out of box. It takes a real challenge to make sure that all the documents replicated from the source SAP ERP and non SAP Systems have the right level of details to support Document splitting. There are options available like BADI_FINS_CFIN_AC_INTERFACE, which can be used to enable the right rules for populating the account assignments for Document splitting. Some of the examples for Document splitting and parallel ledger usage:

◈ The account assignments for Document splitting can be populated only in some of the line items and let standard Splitting set up take care of offsetting line item (eg, Profit Center and segment update in line items and let vendor line item derive the same from offsetting line item in case of Vendor Invoice Posting).

◈ Some of the FI Document line items can derive account assignment objects for document splitting from areas like material master, cost center etc. The customer specific changes, should not be triggered in case, where standard derivation logic can work

◈ Secondary CO Postings from Source systems, where the profit center is not available in one of the line items, the customer specification needs to be updated

◈ Data from Non SAP systems needs to be enriched with account assignment details for postings in the target central finance system

◈ There are transfer postings between subledgers which fail in the target system if it has document splitting active.

3. Master Data Harmonization: Master data replication of objects like Cost Center, Profit center, GL Accounts, customers, Vendors etc is a challenge. Data harmonization is a key challenge in Enterprise customers with multiple SAP Systems. Some of the challenges in master data set up in Central Finance encountered in my experience are:

◈ Customer Vendor Integration - The central finance function was used in S/4HANA 1610 EM instance, where the customers and vendors are created as Business Partners and the number ranges were overlapping in the source system for Customer and vendor account groups. To tide over the issue, the number ranges for Vendors were changed in the target CFIN System

◈ GL Master Data Replication - The SAP ERP System were substantially old systems, where transactional data existed for more than 15 years. As part of CFIN replication, only few years of historical data was being replicated into the target CFIN System. So the GL Master replication was designed based on the no of years in past where transactional data existed for a GL, that only was replicated into the target system

◈ Profit Center and Segments – One of the outcome of org structure redesign in CFIN was the whole profit center and segment usage in Central finance. The profit center in target CFIN system was tagged to Brand for reporting, while a segment was concentrated around line of business. However, the brands in the source system were limited to profit center with Business area being used for line of business reporting. The usage of different objects for reporting in source and target system entailed usage of complex mapping framework for replication of master data

◈ Material master – The material master usage was also a challenge due to disparate systems. A governance structure was required to be put in place to synch up the master data in the source systems and than have the same replicated in the target system.

◈ Data Services or SLT for Master Data – Harmonization and Business Objectives for Master data usage greatly determined the usage of the technology layer for replication between Source SAP and non SAP Systems to S/4HANA Central Finance Environment. Based on specific requirements like Data Filters for GL Account, Numbering changes etc, it was decided to introduce Data Services as a technology layer between Source and Target system for master data replication in S/4HANA Master Data replication.

1. MDG Layer and Value / Key Mappings: Central Finance offers an integrated MDG layer which can be used to recreate the accounting document in the target system, based on the data replication from the source. Some of the key learnings from my association with the central finance project were:

◈ Mapping Action - The mapping action determines if a transformation is required for any data element. In one of my project, business area was very widely used for financial reporting in the source SAP system. However, the complete reimagining of financial reporting meant that business area was not a key reporting factor in Central Finance. Hence a mapping action was set to clear the business area information from the source data. Essentially, the Mapping action should be designed taking into consideration of what are the key financial reporting parameters and if those parameters will hold true for the business even in case of a completely integrated system of records with finance and logistics transactions happening in the same system some time into future.

◈ Key Mapping - Typically the identifiers for a business object can be different in source and target system, given that Central Finance has the ability to connect to a heterogeneous set of SAP and non SAP systems. Eg, a customer 2212 in a source system may be customer (BP) 500000 in CFIN to harmonize master data. In one of the projectw, the key ask was to manage millions of customer master, vendor, gl etc to name and arrive at a common structure. The current design of central finance does not support automatic mapping of the source and target object number, though there is a standard upload tool to do an excel upload using the transaction code FINS_CFIN_MAP_MANAGE. However, to manage the real time replication of master data in the mapping layer, a custom program was created for each of the object to ensure, that there are no failures in transactions

◈ Value Mapping Structure - The value mapping is used in Central Finance to ensure if any transaction specific value has to be transformed. In some of the projects, the source systems had custom values for objects like Document types, Tax Codes etc. The whole objective of the transformation program was to ensure a standardized approach to finance structure across multiple markets. Eg, the markets used Document type R1 and RX for billing in two different geographies, but the intention in the target central finance system was to ensure that all the geographies, where the business operated should have the same document type for billing transactions. Hence the value mapping functionality was used to ensure that the new system has a standardized approach

2. COPA Transformation from Costing based COPA to Account based COPA: Most of the customers in SAP World use Costing based COPA. However, the preferred approach for reporting in S/4HANA Is Account based COPA. The data replication from the Costing based COPA to Account based COPA is not a standard and out of box functionality in S/4HANA. Some of the challenges encountered have been:

◈ There are scenarios in CB COPA where COPA data and GL postings happen at different time, whereas the expectation on AB COPA is to have the data based in COPA and GL at the same time. This presented it’s own challenges since AB COPA was supposed to be used for all kind of profitability analysis. Some of the design considerations for this transformation included moving key data like Sales Area data, material product hierarchy etc from material master, customer sales area data into central finance. These attributes were used in the derivation rule to ensure that the right attributes are populated. In some of the scenario like post goods issue, the data which is relevant for COPA was pulled through custom enhancements into Central finance.

◈ There are condition types on the billing cycle, which post data into COPA but not into GL. This functionality is not yet supported in AB COPA in S/4HANA. This means that the business had to look at the way, in which some of the discounts and pricing could be extended to Billing cycle

3. Transactional Data Posting: Central finance is supposed to reflect all of transactional financial data into a single place from multiple systems. However, the fine print is not all straight forward. There are not all scenarios which can be replicated into Central Finance. For eg, the transactional postings on Asset Sub ledger and WBS Elements through direct replication is not yet supported in central finance. There are quite a few challenges for customers, who already have SAP Source system which have parallel ledgers implemented. In such cases, the fiscal year differe nce in multiple ledgers presents its own issues. Some of the challenges assigned in Transactional data postings are:

◈ Asset Subledger postings are not supported in S/4HANA Central Finance. The posting on asset sub ledger in the source system have to be replicated on a normal GL Accounts in the target central finance system. We utilized the Key Mapping functionality in MDG Layer in Central Finance to ensure that the postings happened correctly

◈ The Transactional postings on WBS System in the source are not replicated into Central finance. This is mapped as a functionality, which will be addressed in the new releases of Central Finance. A custom enhancement was done in one of our projects to create the postings on other supported cost objects like internal order.

◈ Some of the legal entities had multiple ledgers in the source system with both ledgers having different fiscal year variants (one corresponding to 5-5-4 set up and other being April – March). The specification of the cutover month in source system for balance upload and document replication start due to different fiscal years in leading and non leading ledger meant duplicate data being posted in the non leading ledger, since the balance upload happens based on the fiscal year set up for leading ledger.

◈ A big challenge faced was the replication of the open items on the sub ledger and GL. The original document in source might be open at the time of initial load, but cleared in the period replication started. Such practical issues led to document failures in replication when subsequent actions on open items are not replicated immediately in central finance. These have been resolved through implementation of correction notes and custom code involvement

Continue reading

Configure Quota Arrangement in SAP MM

Quota Arrangement:

As we know about source list, as well as source list, we can use quota arrangement.

We know source list is used for a source for a material. In purchase requisition there is a tab Assign Source of Supply.

We can assign a number of vendors in source list so that when we press Assign Source of Supply, system will automatic pick the vendor for the material.

We can assign many vendors to source list, at that time system will propose all vendor in source of supply field and we have to choose one from the list.

But via quota arrangement, we can give the quantity and percentage for a vendor, so if we maintain many vendors in source list, system will take the correct vendor with comparison of quantity of document and quota arrangement.

That is the main facility of quota arrangement..

To use quota arrangement, we have to do some configuration, we have to maintain the quota arrangement, then we can see the result.

Configuration

In this part, we will configure all things which is required for quota arrangement.

Define Number Ranges

Go to OMEP or path SPRO-IMG-Materials Management-Purchasing-Quota Arrangement-Define Number Ranges

The initial screen will appear.

Click on the Intervals

Enter your number range.. You can set the number range as external or internal (Its depend on your business process).

Then Save you data.

Define Quota Arrangement Usage

In this part, we will configure the quota arrangement uses.

Go to SPRO-IMG-Materials Management-Purchasing-Quota Arrangement-Define Quota Arrangement Usage

The initial screen will be appear.

You can see in My system 1,2,3,4 is already created. Now I am going to create Quota arr. Usage 5.

Click on New Entries

As you can see I have selected only Purchase Requisition but you can select these option as per your business requirement.

Then save your data.

Now we have to give assign quota arrangement uses to material master.

Go to MM02, enter your material, select plant and in purchasing tab give the newly created Quota arrangement uses number.

Save your data.

Create Info record

Now suppose we have 3 vendors KKNN001, KKNN002, KKNN003, they will supply the material. and we have to use in quota arrangement as per quantity basis for these vendors.

So we have created Info record for each vendor with regards to material.

Create 3 valid info records for Each vendor.

Create Quota Arrangement

Go to MEQ1

The initial screen will be appear.

Give the Material and Plant and then press enter.

You can see the above screen. Enter the valid to date, (Valid from date will be automatically set as current date of quota arrangement create date)

In the option Minimum qty split, Its specify for the splitting quota (for more help, you can press F1 on this option). You can choose as per your business process…

Now press enter.

After pressing enter, You can see the date from is appeared as current date.

Then you can choose Item or you can double click on the line item.

You can see the initial screen will be appeared for quota arrangement creation.

Here we can found many options for quota uses. We have to choose as per our business process.

To know about every field, you can select the field and press F1 for a help topic for the field.

I have used Maximum Quantity for quota arrangement selection.

I have set the quota arrangement like this

If I use below 20 quantity in PR, then the source of supply will be the vendor KKNN003.

From 21-50 quantity in PR, it will pick the source of supply KKNN002.

From 51-100 quantity in PR, it will pick the source of supply KKNN001.

You can see I have given quota = 3 for vendor KKNN003 and quantity 20 and its percentage shows 50.0, it means When I use below or equal 20, then system will propose the vendor KKNN003.

Now we will check the uses for quota in Purchase Requisition.

I have created a PR with quantity 15..

When I have pressed the Assign Source of Supply, system has proposed me the vendor KKN003.

You can see my default vendor is came into source of supply field.

Now I have changed the quantity 25..

System will shows me a warning message

That means system wants to propose me that as per quota arrangement entry, your prior vendor will be KKNN002.

Now when I press Assign Source of Supply, System will change the source of supply to KKNN002.

Now I have changed the quantity to 90..

System will propose me the vendor KKNN001.

And when I press the Assign Source of Supply, system will change the vendor to KKNN01 in field source of supply.

Now I have changed the quantity 110, as we can see in that position our quantity is exceed against quota arrangement setup.

Now we can see system will propose the all vendors which is can be used as source of supply not only the quota arrangement setup.

Here we can see, system is not proposing me only the vendor which is under quota arrangement, system will propose me all vendor which can a source for this material, and also system will gives us a warning message “Choose a source of supply”

Now we can choose a source as per our requirement.

Just click on the blank option which is left on the vendor number.

After pressing this, you can see a green indicator on the vendor.

Now press Assigned Source..

You can see the source of supply is raised as per our selection…..

How to Remove a vendor from QA List

Now suppose you have ordered some quantity to the 3 vendors.

As you can see I have placed order for all vendor..

Now Vendor KKNN002 inform us that he can’t deliver the material any more. So source of supply should not be vendor KKNN002.

But if we order the material for qty 5 to 10, then it will shows the vendor KKNN002 as source of supply.

In that position, we can;t delete the vendor from quota arrangement, because we have already placed some order.

We have to just remove the quota from vendor KKNN002, so that it will not display on source of supply..

And suppose vendor KKNN003 will delivered the rest of quantity of vendor KKNN002.

Then we can increase the maximum quantity to 30. So that when we placed order for quantity 1 to 15, it will always take the vendor KKNN003 as source of supply.

It will be looks like that

Or if you don’t want to change the quota sequence, then you can also change the maximum quantity.

Then it will be like this

Just change the maximum quantity as same as allocated quantity, then the vendor will not able to use in source of supply..

If you want that the vendor KKNN001 will supply the rest of quantity of vendor KKNN002, in that case, you can increase the maximum quantity of KKNN001 as 110.

How to Add a Vendor in QA List

Now suppose vendor KKNN004 wants to deliver the material, and you have to add the vendor KKNN004 in quota arrangement list, so that the vendor will com automatically in source of supply.

Suppose vendor KKNN004 inform you that he can borrow the order of maximum quantity 7.

But the vendor has already supplied the material with quantity of 5. In that situation, you have to entered the quantity 5 in Quota Base Qty, so in quota calculation, then vendor will prior for just quantity 2.

Then you can add the vendor in existing QA list.

It will be looks like

In this situation, Vendor KKNN004 will be sourced for only quantity (7-5)= 2 quantity.

If you have placed order below than 2 quantity, then the source will be vendor KKNN004 and over 2 it will goes to vendor KKNN003.

Vendor Selection With Same Quota

If you vendor content the same quota in QA, then the source list will picked as per maximum quantity..

But in that scenario, you have to maintain the sequence for maximum quantity…

Here you can see my maximum quantity is 50 for vendor KKNN001 and 500 for vendor KKNN002. Both vendor has same quota.

When I order below 50 quantity, system will propose the vendor KKNN001 and when I order more than 50, then system will propose the vendor KKNN002 as source of supply.

In that way, we can configure quota arrangement in our system…

Continue reading

Automatic Account Determination

Inventory Management

Simply explanation: Managing the stock of material on qty and value basis is known as Inventory Management.

Whether Inventory is required or not for the material is controlled at material type and valuation area (plant) level.

In OMS2, Configuration required for each material type qty and value updating at valuation area level.

Case 1: If both Qty and Value update indicators are selected then PO can be raise for stock purpose and at GR material can be placed in store on qty basis and this Qty means stock value will be updated in inventory or stock G/L account.

Case 2: If qty update selected and value update not selected for material type at valuation area level, These material type related materials must procure for consumption Purpose. Means you should select account assignment category in PR and PO. At GR, received material is placed in store on qty basis but material value will be booked in relevant consumption G/L account but not in stock or inventory g/l account.

Inventory Management scenario’s can be defined as 1) Goods Receipt 2) Goods Issue 3) Stock Transfer 4)Transfer Posting

Characteristics of Goods Movements:

1) At least one material document will be generated and if goods movement is relevant to FI then accounting document to be generate.

2) Stock and Stock Value and Consumption Value may increase or decrease based on the goods movement.

3) If GR is entered against PO then PO history to be updated in Display PO.

4) Total value and Total stock, Moving average price to be updated (may be increase or decrease) in Material Master.

5) If Quality Management views are maintained with required fields, then when you completed the GR or GI, inspection lot to be generated when you run in QA32 , Based on Usage decision stock to be accepted or Rejected.

Sample process for Goods Receipt, Goods Issue, Stock Transfer, Transfer Posting.

Goods Receipts: 1) GR w.r.t Po for raw material

                               2) GR w.r.t Production order for finished Product.

                               3) GR With out for Production order

                               4) GR with out Purchase Order.

Goods Issue:      1) GI w.r.t Production order for raw material.

                              2) GI w.r.t sales order for finished product

                              3) GI to cost center or to plant maintenance.

                              4) GI to Scrap.

Stock Transfer:   1) Plant to plant stock transfer with in the company code.

                                2)From plant to plant across company code.

                                3)Store to Store stock transfer

Transfer Posting:  1) Unrestricted ⟺ QI ⟺ Blocked

Account Determination: (MM & FI Integration)

With this account determination Configuration settings,system will determine a suitable G/L account while posting GR (or) GI etc.

1) Account Determination with out wizard

I explained simply in one diagram, it is use full to remember the Process. Below I explained step by step.

1st Part:

Chart of account includes G/L accounts. This chart of account to be assigned to one company code or multiple company codes.

Note: Similar account determination required plants are grouped together and assigned to a valuation grouping code and then account determination will be configured at valuation grouping code level.

Step 1: Define Valuation Control (OMWM)

Here need to activate valuation grouping code.

For account determination, you can group together valuation area by activating the valuation grouping code.

Step 2: Group together valuation area.(OMWD)

here you assigned the valuation grouping code with combination of company code and chart of account and valuation area (plant) combination. If suppose similar account determination required plants are grouped together , here you can assign same valuation grouping code to multiple plants (or) multiple valuation areas.

2nd Part:

Material type and Account category reference and Valuation class.

Step 3: Define Valuation Classes.(OMSK)

In this step, you define which valuation classes are allowed for a material type.

So I am not going to this detailed. As account category reference is main controller and Mediator for material type and valuation class.

There is no direct configuration between material type and valuation class. Account category elaborates which material types related materials can be choose the which valuation classes.

You should enter this valuation class in material master.

3rd Part:

Step 4: Define Account Grouping for Movement types (OMWN)

Note: It is not possible to define new valuation string and new transaction event keys but account modifiers are editable with any movement type, for GBB or PRD or KON transaction keys are triggering then only account modifier also triggers.

Based on movement type system is triggering a valuation string and this valuation string is again triggers several transaction keys. but few transaction keys again triggers account modifiers or account grouping code also.

Below are the transaction event keys relevant account modifiers

GBB ⇨ BSA,INV,VBO,VBR,VNG,ZOB

PRD  ⇨ PRA,PRE,PRU

KON ⇨ PIP

Step 5: Configure Automatic Postings (OBYC)

In this step, you enter the system settings for inventory management and invoice verification transactions for automatic postings to G/L account.

Continue reading

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

Every movement of goods is followed by movement type only and without movement type use / without help of movement type – no goods movement is possible in SAP. During goods movement of transaction posting, movement type trigger transaction event key and G/L account assignment triggers based transaction event key (OBYC) with valuation class where valuation class determines the valuation class available in material master which is used for transaction posting. For automatic account determination, the vital direct parameters involves are  movement type, valuation class, chart of account, valuation area, business key (transaction key), valuation grouping code{ valuation modification or valuation modifier}, account grouping code{general modification or general modifier },nature of G/L account ,posting keys and value string.

Moderately understandable, only large vital factor – valuation class in material master determine G/L account on goods movement for a movement type and then, all are happy on validation in/for business process by cross checking accounting entries in each case/stage. Essential regard to account category reference (which is very much responsible of having valuation class in material master), play grandparent role by being silent friend for success to automatic account determination process.

The account category reference (ACR) is an artificial code of four characters which allows flexibility in linking material type with valuation class. In reality, the valuation class is linked to an account category reference and account category reference linked to material type. In other term account category reference is used to simplify the assignment of permitted valuation class/valuation classes to the material type/ material types.

Business Case-1: How to use Account Category Reference

Based on requirement, business can have one material type, one account category reference and one valuation class by assigning material type to account category reference and then assigning account category reference to valuation class. For example business can have one custom material type ZROM (Raw Material) with custom account category reference (Z001) and new valuation class (3005) for Raw Material(Raw material – inventory managed with quantity and value)

During material creation with transaction code: MM01 with certain material type manually or by any uploading tool, only one permitted valuation class is defaulted for that material type by account category reference. So in material creation process no chance of making any mistakes by users or by any uploading tool.

Business Case-2: How to use Account Category Reference

Based on requirement, business can have one material type, one account category reference and multiple valuation classes by assigning material type to account category reference and then assigning account category to valuation classes. For example business can have one custom material type ZROM (Raw Material) with custom account category reference (Z001) and new valuation classes i.e. (3005) for Raw Material, (3006) for Chemicals and (3007) for Filter material (all materials are inventory manage with quantity and value)

During material creation with transaction code: MM01 with certain material type manually or by any uploading tool, only permitted valuation classes are defaulted for that material type by account category reference . Here, there is a chance of entering wrong valuation class by user manually or through upload file using a tool which needs to be validated.

Business can go for designing a custom transaction code where material can be created through uploading file which can be verified by central material creation officer.

Business Case-3: How to use Account Category Reference

Based on requirement, business can have multiple material types, one account category reference and multiple valuation classes by assigning material types to account category reference and then assigning account category reference to valuation classes. For example business can have three custom material types such as  ZROM (Raw Material), ZCHE(Chemicals ) and ZFIL(Filter material ) with one custom account category reference (Z001) and three new valuation classes ie.. (3005) for Raw Material, (3006) for Chemicals and (3007) for Filter material (all materials are inventory manage with quantity and value)

During manual material creation with transaction code: MM01 or material creation by any uploading tool, only permitted valuation classes are defaulted for that material type by account category reference. Here, entering correct combination of material type for material and valuation class are expected through manually or through upload file which needs to be validated.

Business can go for designing a custom transaction code where material can be created by referring uploading file which can be verified by central material creation officer.

Also business can think of having “material master creation form” for any new material master creation, if necessary material code/ material number is not available in system – User/Users can fill the “template of uploading file’ with duly filled “material master creation form” and send for approval.On appropriate check and verification with approval from approving authority, if central material creation officer is happy, then he /she can upload file with custom transaction code for new material code.

Continue reading

Pricing procedure Steps and Details in SAP MM

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 comfortable with 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 we can save 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 contains many condition tables.

Suppose we maintain 4 condition tables in one access sequence. Then when a condition type will be searching for condition record via this access sequence, the access sequence will allow to search only this 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.

In general, below image will give the concept how a condition type will search for the condition records :

Configurations:

Step 1 : Maintain Condition Table

T-code M/03 or Path SPRO-IMG-MM-Purchasing-Conditions-Define Price Determination Process-Maintain Condition Table-Create condition table.

The initial screen will be appear for create condition table.

Give the new condition table no. You can use old condition table number as reference. To give reference just give the old condition table number in below “copy from condition table”.

Note: As per standard SAP, they give the entire condition table for general business requirement. If any condition table doesn’t fulfill your requirement, then you can create new condition table. Please use between 501 to 999 as condition table.

Now press enter

You can see the left side will be blank in initial screen, Right side will be always filled. Just double click on the right side field which you can add for this condition table.

When you double click the field the field will be blue colour and the field is appear in left side.

As we can see the 1 field I have selected in this condition table.

Save your data.

You can change the option as per your business requirement. For more details for these options, just press F1 on these option, you will find sap help doc.

Step 2: Maintain Access Sequence

T-code M/07 or path SPRO-IMG-MM-Purchasing-Conditions-Define Price Determination Process-Define Access Sequences.

The initial screen will appear.

You can create a new access sequence or maintain the condition table in existing access sequence (depend on your business process)

If you want to create then click New Entries. (Or you can use copy reference, Just select the access sequence and press Copy as…)

Enter your Access Sequence and give the description and also you can choose Access category.

Then select the AS and double click on Accesses

Click on New Entries

Enter the access number, condition table and if required the give routing number and Exclusive.

If you tick exclusive indicator, then if valid condition record found then system will stop searching after the first.

Choose as per your requirement.

Then select the line item and click on the fields (left side) to activate the condition table in access sequence. You do not need to do anything here, just double on the fields and go back. If you will not do that, then your condition table will be not accessible. You can add more condition table (s) on this access sequence.

Save your data.

Step 3: Maintain Condition Type

T-code M/06 or path SPRO-IMG-MM-Purchasing-Conditions-Define Price Determination Process-Define Condition Types-Define Condition Type

The initial screen will be appear 

As for gross price SAP default maintain as PBXX for time independent condition and PB00 for time dependent condition.

Time Independent condition is use with validity period, which can be differ as validity period (we use it in info record, RFQ, Contract, SA(as per configuration for document type)).

So we don’t need to create new condition type for gross price, although you can create your own starting with Z.

Assign you newly created access sequence to the gross price condition type (I have maintain in for PBXX)

Here you can find all types of condition type like as freight, discount, rebate, cash discount etc. If it can fulfill your requirement, then no need to create new condition type. If doesn’t the go for New Entries.

Here I have maintain ZCAH as discount, I give condition class A, Calculation type A, Plus/Minus X-Negative

(Note: Not required to maintain like that, you can maintain as per your requirement.)

As per this way please create other condition types as per your requirement (which will be used in Pricing Procedure)

Save you data.

Step 4: Maintain Calculation Schema

T-code M/08 or path SPRO-IMG-MM-Purchasing-Conditions-Define Price Determination Process-Define Calculation Schema

This is very very important part in pricing procedure.

Here we give the calculation for all condition types.

Here also you can find the SAP default calculation schema, you can also use one of them as your pricing procedure. Although you can create new calculation schema as per your requirement.

Just click on New Entry. (or you can copy old schema and can modify yourself. then select copy as…)

Give the name and description for new procedure.

Then Select this procedure and press Control (in left side)

You can see a lots of option there, You can read all option help which is provide by SAP (Just select the portion and press F1)

Maintain PBXX as gross price in step 1, counter 1, leave the from and to blank, Subtotal will be value 9-Copy values to KOMP-BRTWR (gross value).

Maintain other condition types as per your requirement.

I have maintained ZCAH and ZCAS, I have used from 1, it means it will calculate the value against Gross Price (PBXX)

I have used Total Discount amount, from 7 to 9, It shows the total discount value (Total of ZCAH and ZCAS)

At last I have used TOTAL AMOUNT, It shows net value for this pricing procedure.

Step 5: Maintain Schema Group for Vendor

T-code OMFN or path SPRO-IMG-MM-Purchasing-Conditions-Define Price Determination Process-Define Schema Group-Schema Groups: Vendor

Just click on New Entries and enter the Schema Grp Vndr and give the description.

Here I have maintained Z1.

Step 6: Maintain Schema Groups for Purchasing Organizations

T-code OMFM or path SPRO-IMG-MM-Purchasing-Conditions-Define Price Determination Process-Define Schema Group-Schema Groups for Purchasing Organizations

Just click on the new entries and enter the Schema GrpPOrg and description.

Here I have maintained ZMM1.

Step 6: Assign Schema Group to Purchasing Organization

T-code OMFP or path SPRO-IMG-MM-Purchasing-Conditions-Define Price Determination Process-Define Schema Group-Assignment of Schema Group to Purchasing Organization

Here find your Purchase Organization, and assign Schema GrpPOrg to Purchase organization.

Step 7: Maintain Schema Determination

T-code OMFO or path SPRO-IMG-MM-Purchasing-Conditions-Define Price Determination Process-Define Schema Determination-Determine Calculation Schema for Standard Purchase Orders

Step 8: Assign Schema group to Vendor

When you are going to create a vendor from XK01 in purchasing data you will find “Schema Group, Vendor”

Here assign the schema group which you have created on step 5.

You can also maintain it on existing vendor via XK02.

Step 9: Maintain Condition Record

T-code MEK2

Maintain the condition record against the key combination.

Save your data.

Finally all configurations has been done.

Now see the result.

Create PO with this purchase organization and with this vendor.

We can see the my new pricing procedure is working perfect.

We can use this in SA.

Just we have to configure this for document of schedule agreement.

Go to path SPRO-IMG-MM-Purchasing-Scheduling Agreement-Define Document Types

Just un-tick Time Dep. Condition for SA document type.

Then Create SA for this vendor and purchasing organization.

This is called time independent condition. You can also use this pricing procedure for RFQ. But Contract and Info record will be always time dependent condition.

Time Independent conditions are not dependent on time. It hasn’t any validity period, that means it will be always same for all time. The above settings are for time independent condition. Whenever you will use time independent condition, then you need to do these above settings.

Time dependent conditions are always time dependent. It has the validity period. You can use more than one price for the same condition record with different validity period, so that system will change it automatically as per the validity period.

I think I do not need to explain anything more about the differences Time dependent condition and Time Independent condition because there are many discussions already there for the differences.

You can use either time dependent or time independent for Schedule Agreement and Request For Quotation but you can only use time dependent condition for Contract and Info record and for Purchase Order, you need to always use time independent conditions.

For time dependent settings, you just need to set the up the condition type, Access sequence, Condition table and Calculation schema. Schema group is not needed for the time dependent condition.

We can also maintain the fixed discount for particular vendor.

Suppose one of my vendors gives me material as 5 % discount for all material.

We can maintain it in condition record.

Go to MEK2

Click on Supplement Condition. Maintain there your condition type for ZCAH as 5.

You can see the default 5% discount has been automatically arrived in PO or SA.

You can only able to see these condition types which is associated with the condition type which you have entered at the first screen and it will be your gross condition type.

To add some more condition type, you need to add these condition types in the associated calculation schema. To find the calculation schema which is associated with the gross condition type, you need to go to M/06 and you will find the calculation schema as below:

You can add your condition type in this calculation schema in t-code M/08. Then your condition type will be visible for time dependent condition (MEK1) or Info record or Contract.

Continue reading