sap sd material account assignment group

• Terms of Use
• Privacy Policy
• SAP ERP Solutions
• What does SAP stands for

ETCircle.com SAP FI and CO consultant information

Materials: account assignment groups | ovk5.

In this configuration activity we are able to define account assignment groups for materials used in Sales and Distribution Module ( SD ).

Transaction: OVK5

IMG Path: Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination ->  Check Master Data Relevant For Account Assignment

Tables:  TVKM, TVKMT

If you use the IMG Menu, you will have to choose the first option on the pre-selection screen.

On the main screen there is a list of Account Assignment Groups for Materials. You can create new here if you need.

Tags Account Assignment OVK5 TVKM TVKMT

About Emiliyan Tanev

Related articles, assign g/l accounts | vkoa, customers: account assignment groups | ovk8, define automatic credit control | ova8, configure automatic postings | omwb.

In this FICO configuration activity we are able to define account determination for automatic postings …

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.

SAPHANATUTOR.COM

SAP ECC | SAP S/4 Hana Tutorials

Revenue Account Determination in SAP SD: A Comprehensive Guide

Revenue Account Determination in SAP SD , is a crucial integration point between the SD and Financial modules. It ensures that when a billing document is created, the system accurately identifies and posts revenues, taxes, and sales deductions to the appropriate accounts. This process, deeply rooted in the condition technique of SAP, requires a collaborative effort between the SD and Finance teams. Here’s a step-by-step guide to understanding and implementing revenue account determination in SAP SD .

Table of Contents

Revenue Account Determination in SAP SD

Revenue Account Determination in SAP SD involves 6 configuration steps they are

• Check Master Data Relevant for Account Assignment
• Define Dependencies for Revenue Account Determination
• Access Sequence and Account Determination Types
• Define and Assign Account Determination Procedure
• Define and Assign Account Keys
• Assign G/L Accounts

Step 1: Master Data Relevance in Account Assignment

Path : SPRO -> Sales and Distribution -> Basic Functions -> Account assignment/Costing -> Revenue Account Determination -> Check Master Data Relevant for Account Assignment.

The first step involves checking the master data relevant for account assignment. This includes:

• Material Account Assignment Group : This groups materials to post related revenues into specific accounts. For instance, revenues from laptop sales might be posted to one account, while desktop sales go to another. This grouping is maintained in the Material Master ( MM03 ) under the Sales org data 2 view.

• Customer Account Assignment Group : Similar to materials, customers are grouped to direct revenues into designated accounts. This could differentiate between domestic and international customer revenues. This grouping is found in the Customer master ( VD03) under the Sales area view/Billing tab.

Step 2: Defining Dependencies

Path : SPRO -> Sales and Distribution -> Basic Functions -> Account assignment/Costing -> Revenue Account Determination -> Define dependencies of Revenue account determination.

The second step is about defining dependencies for revenue account determination. This involves creating field catalogs and condition tables , which are essential for setting up the account determination tables.

Step 3: Access Sequence and Account Determination Types

Path : SPRO -> Sales and Distribution -> Basic Functions -> Account assignment/Costing -> Revenue Account Determination -> Define Access Sequences And Account Determination Types.

This step focuses on setting up the access sequence for account determination and defining the account determination types. The access sequence dictates the order in which tables are accessed, while the account determination type functions like a condition type in the pricing procedure.

Detailed Configuration Steps

Step 4: account determination procedure.

Path : SPRO -> Sales and Distribution -> Basic Functions -> Account assignment/Costing -> Revenue Account Determination -> Define and Assign account determination procedure.

Step 5: Account Keys Definition and Assignment

Path : SPRO -> Sales and Distribution -> Basic Functions -> Account assignment/Costing -> Revenue Account Determination -> Define and Assign Account keys

Account keys play a pivotal role in account determination. They are linked to pricing condition types and are critical in linking the pricing procedure with the account key. Different pricing conditions have distinct account keys, like “ERS” for discounts, “ERL” for price, and “MWS” for taxes.

Step 6: Assigning G/L Accounts

Path : SPRO -> Sales and Distribution -> Basic Functions -> Account assignment/Costing -> Revenue Account Determination -> Assign G/L accounts.

The final step involves assigning General Ledger (G/L) accounts. This is akin to maintaining condition records for pricing condition types. The G/L account determination is a combination of the application, account determination condition type, chart of accounts, and account keys

Role of Account Keys in Pricing Procedure

Learn about role of account keys in pricing procedure here.

Related posts:

• Role of Account Keys in SAP Pricing Procedure
• How to configure material determination in SAP?
• SAP SD Partner Determination: Configuration Guide
• Exploring SD Pricing in SAP -Detailed Explaination
• How Customer Account Groups in SAP SD are created | Saphanatutor.com

G/L Account Determination in SAP SD

Most of the transactions in SAP are recorded against the GL account. During creation of billing document form a sales order , an accounting document is created where material value is posted against a G/L account. The post describes how the system determines the G/L account for a material sold to a particular customer by the GL account determination technique.

Lets try to create a sales order for a customer with some material and then creating a billing document from the sales order which also generated the accounting document.

To create sales order go to Tx- Va01

Lets create a debit memo request for the sales area 1000/10/10.

Provide the customer number and few materials and its quantity and double click on the first material to see the item details.

From the pricing procedure – for the pricing condition type- PR00 material value is calculated as 175.50 EUR.

For the second material  for the pricing condition type- PR00 material value is calculated as 1598.00 EUR. Go back.

Select the header button.

In the header section, in the Conditions tab, the total price is the sum of two materials.

Save  and DMR is created.

Go to Tx- VA02 and  from the menu choose Billing.

Select Save button to create a billing document. mark billing document type is determined as – L2.

Go to Tx- VF03 and display the billing document. Choose Accounting button.

Choose Accounting document.

Here is the accounting doc with few lines.

First entry is for the customer as we used the customer – 491000, the account becomes 491000 for the customer.

For the second line, the GL account calculated as 502000. Let’s figure it out how this g/L account is determined.

Go to Tx- VF02 and edit the billing document.

From menu, navigate along the highlighted path.

Well, it says the Account Determination procedure is KOFI00 and for the first item , for the pricing condition type PR00, the G/L account as 502000.

Same for the second item.

The G/L account determination requires few customizing steps.

First check what is the chart of account assigned to the company code. In SPRO IMG structure navigate along the highlighted path to see the chart of account assigned to the company code. 

For the demo we use company code- 1000

The chart of account is – YIKR

Next step , the customizing in the Sales&Distribution section for the Account Assignment/Costing.

First execute – Check master data relevant for account assignment.

Select first option- Materials : Account Assignment Groups.

Here Material account assignment group is created which is assigned to the material master when created in Tx- MM01

Select second  option- Customer : Account Assignment Groups.

Here Cusomter account assignment group is created which is assigned to the customer master when created in Tx- XD01

For our used material in sales order- H11, open this material in Tx- MM03 and in the Sales: sales org.2 tab, the material account assignment group is assigned to the material.

Similarly for another material used in sales order, it is assigned to the material account assignment group.

For our customer – 491000, open this customer in Tx- XD03 and go to the sales area data & in the billing document tab, customer account assignment group is assigned to the customer.

This customer and material account assignment group will help to determine the GL account.

GL account determination uses the condition technique. Now the next step is to define the condition tables. So choose option- Define Dependencies of Revenue Account Determination.  If you want to create new tables you can choose Create Table option. For this demo we are leaving this as already we have few condition tables.

Next is defining the access sequence and the condition type. So choose the highlighted opton.

Access Sequence is defined as – KOFI( a new access sequence can be created bu New Entries button ).  Select the access sequence and choose Accesses from left hand section to see all the access lines with condition table.

Well this access sequence KOFI has five access line each refers to one condition table.

Select one access line and choose Fields button to see all the fields included in the condition table to form the access line 10.

Access line-10 with condition table 001 has 4 fields.

Similarly for other access lines with condition tables other fields are there.

For access line 30.

For access line 40.

Choose Define Account Determination type.

Here Condition type- KOFI is created which is assigned to the access sequence KOFI which has 5 access lines with different condition tables.

Choose the option as pointed to create account determination procedure.

Procedure KOFI00 is created and assigned to the account condition types. Choose the procedure and select Control data from left side.

Here the account determination procedure is assigned to the condition type.

Choose the option – Assign account determination procedure.

Here the account determination procedure is assigned to the billing type.

Next step is to define account key. Choose the marked option.

For different types like revenue, tax and other different account keys are defined. For revenue its ERL.

Next step is to assign the account key to the pricing procedure – condition type PR00.

Here for the pricing procedure ZVAA01 and condition type PR00, the account key is assigned as ERL.

In the above created sales order, item we can check the pricing procedure as below bu selecting the Analysis button in the conditions tab of the item detailed screen.

Next time is to assign the G/L account. Choose the marked option.

Here we have five options. as account condition type KOFI of the account determination procedure KOFI00 is assigned to the access sequence – KOFI with five access lines.

This is like maintaining the condition records. During the GL account determination process, it checks to find the GL account by taking all the values from the billing document and checking against the condition records for table 001. If found it calculated the G/L account and if not found then checks for the condition records for the second table and so on upto 005 until it finds a G/L account.

Choose/double click on the first line.

Here we have maintained for V-Sales, KOFI- account condition type, YIKR as the chart of account and other four fields like sales org, customer account group, material account group and account key comes from the condition table, for our demo purpose we have assigned the G/L account as- 502000.

( Before assigning to the G/L account here it should be created first).

For our demo

• From Billing Type L2 it derives the account determination procedure as- KOFI00
• From account determination procedure- KOFI00 it find the account condition type as – KOFI
• During creation of billing its finds for the item, pricing procedure and the condition type as PR00
• Then it finds the account key for the pricing procedure with condition type PR00 as ERL
• The customer account assignment group is – 03
• The material account assignment group is – 01
• The chart of account as- YIKR fot the company code- 1000
• By taking all these values, the G/l account number calculated as – 502000

• Click to share on Twitter (Opens in new window)
• Click to share on Facebook (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on WhatsApp (Opens in new window)

12 comments

Very well explained

Can you please explain me how to assign different GL account while creating accounting document? What changes do I have to make?

is there any way to do a mass analysis on how account assignment has been done over a period of time? ie which tables were used with with criteria? We want tot clean up the SD account assigment tables which currently have over 100.000 entries and are not manageble anymore.

It’s truly a nice and useful piece of info. I’m happy that you shared this useful info with us. Please keep us up to date like this. Thank you for sharing.

Hi. I have an inquiry regarding the classification of ERL account group. In my current company, there are two GL accounts which are currently tagged to ERL (Revenue) – one is cash and another is VAT adjustment (based on their description). My question is, are those two accounts valid to be determined under ERL? If so, what is the impact if this matter is unresolved? Hope someone can take up and provide me a good input. Many thanks in advance.

this is how the fucking a document must be. excellent!

Thank you so much, detail explanation. Appreciate the hard work

Could you add little detail on ” how does the pricing procedure ZVAA01 and condition type PR00 linked/determined for an item”

Pricing procedure is not determined on the item level. Pricing Procedure is determined on the header level. In tx- OVKK , the determination of pricing procedure customizing are maintained. The sales area, document pricing procedure and the customer pricing procedure determines the pricing procedure. When an order is created we know the sales area(sales org, dist channel and division), the document pricing procedure derived from the document type and from the sold-to-party (customer) the customer pricing procedure is derived. With all these information, Pricing procedure is derived.

The pricing procedure contains condition types like PR00 and others. In Tx- VK11/VK12/Vk13 we can maintain pricing condition records against each condition types. When we enter a material in an item, from the already determined pricing procedure it gets the condition types and tries to find the pricing condition record for the material. This is how the price is found for that item condition type.

Hope this helps!

Like Liked by 1 person

Thanks to you Siva and Manish, I am not in to SD but was trying to have extended understanding between FI-SD integration and found your tutorial, its really help full. I was going through with the tutorial and played your videos as well in you tube. It helps me to understand the process and bridge the gaps from SD side. Really appreciate your effort on preparing and sharing the knowledge

Thanks for the details .suggest reading the note on account-determination helpful things are described there

execellent..well done..thank you

Leave a Reply Cancel reply

• Already have a WordPress.com account? Log in now.
• Subscribe Subscribed
• Copy shortlink
• Report this content
• View post in Reader
• Manage subscriptions
• Collapse this bar

• What is SAP SD?
• SAP SD Training Tutorials for Beginners
• SAP SD T-codes
• SAP SD User Exit for Billing Document
• SAP SD User Exits for Sales Order
• SAP Customer Down Payment Configuration
• SAP PGI (Post Goods Issue)
• SAP IS-Retail Module
• SAP Incoterms
• SAP SD Variant Configuration Steps
• SAP SD Configuration Step by Step Guide
• SAP SD Credit Management Interview Questions
• Account Assignment Group In SAP
• Subcontracting Process In SAP SD
• Rebate Processing In SAP SD
• Difference Between Rebate And Discount
• Movement Type In SAP
• SAP SD Availability Check Configuration
• Debit And Credit Note in SAP
• Sales Documents List
• Intercompany vs Intracompany
• SAP SD Pricing Routines & User Exit
• Shipping Condition In Sales Order
• SAP SD Invoice Table
• SAP SD Certification & Course Fees
• SAP SD Interview Questions

Define Account Assignment Group

Updated May 18, 2018

Field found in Material Master Sales Organization 2. To define the General Ledger Posting:- IMG -> Sales and Distribution -> Account Assignment/Costing -> Revenue Account Determination -> Assign G/L Accounts With this link, the material that used this account assignment group will be posted with the desired G/L accounts during Billing. User will not be able to Release the billing document to Accounting if this is not setup. If you happened to assign it via Cust.Grp/MaterialGrp/AcctKey, then you can let your user use this report to check the material assignment. * Transaction code VKOA REPORT ZMATNR_AC_ASSIGN LINE-SIZE 132 NO STANDARD PAGE HEADING LINE-COUNT 044(001).

• 05 Apr 2010 6:12 am Manzoor Ahmad Its very good and helpful for SD Trainee.
• 08 Oct 2010 8:24 am Guest very nice.....

Mastering Partner Functions and Determination in SAP SD Modules

• riazul-islam
• August 30, 2024

Table of Contents

Understanding partner functions and determination procedures in SAP is a key skill for those working with SD and LE modules. According to expert research, over 75% of SAP customers leverage standard partner determination to map their sales, delivery and billing processes.

As an AI and machine learning architect who has worked on multiple SAP implementation projects, I cannot stress enough the importance of getting your partner configuration right!

In this detailed guide, let me expand on the core concepts of building partner determination workflows using transaction VOPAN and share some pro tips from my experience.

Why Partner Determination Matters

Before jumping into the configuration, it is vital to understand why accurate partner determination matters:

Seamless integration flows: Well defined partner processes are crucial for enabling different SAP modules like SD, MM, FI, CO and S/4 HANA to seamlessly integrate and exchange information.

For example, key master data attributes like customer number, address etc. need to accurately flow from SD to FI documents for clean invoice generation. Any gaps in determination logic can break this critical integration.

Unified customer experience: Having a 360 degree view of all customer interactions allows businesses to deliver exceptional service. Partners play the key role of bringing together data from different systems to enable this unified view of order history, payments, contacts and more.

End-to-end automation: Smooth automated information flows between order fulfilment, inventory management, billing and payment processes relies heavily on accurate partner determination all through the chain. Any weak links can disrupt straight through processing.

Rapid troubleshooting: When issues hit, identifying the root causes quick and remediating them faster is key. Correct partner mappings make troubleshooting easier by providing transparency on who interacts with who in the workflow.

These reasons underscore why mastering partner configuration needs to be high priority for teams implementing and supporting SAP solutions.

Now let us get into the details of how to set it up in SAP…

Partner Function Concepts

Partner functions capture the purpose of a participant within a business process. Few examples across different processes:

Sales Process

• Ship-To Party (ST): Receives Goods
• Bill-To Party (BP): Makes Payment
• Sold-To Party (SO): Places Order
• Payer (PY): Payment Responsibility

Purchasing Process

• Goods Recipient (WE): Receives Items
• Invoice Recipient (ER): Gets Invoices

Master Data

• Contact Person (IK): Communicates Queries

Unlike organizational data captured in master records, functions identify roles played in specific business context. This allows flexible mapping of business partners, reducing redundancy.

For instance, same customer master can be assigned with ship-to and bill-to functions in a sales order based on delivery preferences.

Core Steps in Partner Determination

Accurately setting up partner determination involves these key steps:

1. Define Partner Functions

First core building block is creation of partner functions like SO, WE, ER etc. as needed for business processes via VOPAN transaction.

2. Build Determination Procedures

Next, relevant functions are bundled into determination procedures for specific purposes like billing, deliveries etc.

3. Assign Procedures to Objects

Last step is assigning these determination procedures to related objects like customer master, item categories and so on.

Now, let‘s explore these steps to set up partner determination with examples…

How to Configure Partner Determination in SAP

The best way to learn partner configuration is by actually creating the basic elements in your SAP training system.

In this section, we will walk step-by-step to build sample determination procedure for delivering goods to multiple locations using VOPAN transaction.

The first building block is the partner function, created as follows in VOPAN:

Enter VOPAN in command field

Select object as Customer Master

Edit –> Create new partner function

Enter ID & description

{{< img src="sample-partner-function.png" alt="New Partner Function Example" >}}

Here ‘ST‘ defines ship-to party receiving goods.

Similarly, other functions like bill-to party, contact person etc. can be defined. This provides the base elements.

Pro Tip: Leverage standard SAP functions before creating custom ones!

2. Build Determination Procedure

Let‘s group relevant delivery functions into new determination procedure:

Go back and select main Partner Determination Procedure

Double click Partner Functions and add new entry

Enter ID (e.g. JIT ) and related Partner Function

{{< img src="sample-determination.png" alt="Partner Determination Example" >}}

So here JIT procedure contains delivery function ST .

Expert Note: Logical grouping of functions aids maintenance!

3. Assign Procedure

Finally, we need to assign the JIT determination to customer master:

From main screen, select Account Groups node

Double click Functions and create new assignment

Input Account Group (e.g. Z100) and select JIT procedure

{{< img src="sample-assignment.png" alt="Assign Partner Determination Example" >}}

This maps the delivery functions to customer group Z100.

And now your partner determination logic is configured!

On creation of customer master records, the linked functions will be triggered based on groups defined above.

This was a simple hands-on example of setting up partner procedures for deliveries in SAP SD. You can extend the same approach to build more complex rules and mappings as needed.

Let‘s now move on to an advanced concept of custom enhancements…

When to Create Custom Partner Determination?

SAP provides a range of standard partner functions and objects to meet common business needs like sales, shipping, billing etc.

However, there may be complex scenarios that require specialized custom enhancements beyond standard VOPAN capabilities.

Some examples where custom determination makes sense:

Non-standard object mapping : Requirement for triggering partner resolution from customer equipment, service contract or custom object

Specialized integration : Custom interfaces with non-SAP applications like billing or warehouse systems that need additional determination logic

Complex rules : Intricate multi-step formulas, not possible via standard configuration, for resolving correct partners

Enhanced user exits : Custom code to override standard SAP partner identification for areas like shared financial accounts

Legacy data transfers : Custom mapping of outdated legacy partner IDs into new SAP model

The decision on custom vs standard partner procedures depends on the effort vs flexibility tradeoff. It is best to start with standard functions where possible and extend only if needed.

Let‘s now go over some key tips when managing determination procedures…

Management Best Practices

Based on lessons learned across many SAP projects, here are some best practices I recommend for managing partner determination:

Evaluate complexity early – The number of objects, assignments and rules grows quickly. Continously assess effort needs.

Reuse existing elements – Check for relevant standard functions or templates from industry best practices before building custom.

Modularize assignments – Group relevant objects into procedures and assign in bundles rather than individual entries.

Trace end-to-end flows – After configuration, test scenarios spanning master data to transactions to identify gaps.

Document key objects – Maintain descriptions and usage for main determination objects, functions and procedures.

Getting partner strategy right is well worth upfront investment, as it forms the backbone across business processes.

Now let‘s go over some key troubleshooting tips…

Troubleshooting Partner Determination Issues

With complex determination procedures spanning various modules, issues are bound to arise leading to disruptions and master data corruption.

Here are some useful methods I follow to troubleshoot such errors:

Check assignments – Verify if right determination procedure is assigned to transaction/object.

Analyze trace logs – SPRD transaction in SAP provides detailed logs on resolution process.

Test simple scenario – Strip down to bare minimum master records and functions. Then add complexity back till error resurfaces.

Consult configuration – Carefully examine entire determination setup without assumptions. Revisit configuration decisions if needed.

Enable custom logging – For tricky cases, add debug code via BAdIs to log resolution analysis and intermediate values.

Rebuild piecemeal – As last resort, dismantle and rebuild determination logic in small controlled pieces. Helps pinpoint issue areas.

Thorough troubleshooting by methodically narrowing down root causes is key before making changes. This minimizes disruptions and rework.

Now over to you…please feel free to reach out with any partner determination questions!

• sap , sap-sd

Read More Topics

What is a sap client and why create new ones, creating robust material masters for sales: an ai-powered guide, craft optimized junit test suites: a 4-step master plan, managing postgresql tables: a comprehensive expert guide, software reviews.

• Alternative to Calendly
• Mojoauth Review
• Tinyemail Review
• Radaar.io Review
• Clickreach Review
• Digital Ocean @$200 Credit
• NordVPN @69%OFF
• Bright Data @Free 7 Days
• SOAX Proxy @$1.99 Trial
• ScraperAPI @Get Data for AI
• Expert Beacon
• Security Software
• Marketing Guides
• Cherry Picks
• History Tools

Lifetime Deals are a Great Way to Save money. Read Lifetime Deals Reviews, thoughts, Pros and Cons, and many more. Read Reviews of Lifetime Deals, Software, Hosting, and Tech products.

Contact：hello@ gurusoftware.com

Affiliate Disclosure:   Some of the links to products on Getorskip.com are affiliate links. It simply means that at no additional cost, we’ll earn a commission if you buy any product through our link.

© 2020 – 2024 Guru Software

3512048 - Error in Purchase Request : Account determination group is missing for product category

Error: Account determination group is missing for product category , in the Purchase Request

Environment

SAP Business ByDesign 

Reproducing the Issue

• Go to Purchase Requests and Orders work center.
• Search for Purchase Request. 
• Select all the items present in the Purchase Request individually and add the desired Product Category.
• Click on check to see the error : Account determination group is missing for product category.

Item Type of Items in the Purchase request are Material, but in the fine-tune activity - Default Account Determination Groups for Product Categories, for the product category used in Purchase request, the maintained default account determination group is for services but not for materials. 

Hence the error is thrown. 

Follow below steps to view and modify the account determination group maintained for Product category of Service or Material :

• Then go to the Business Configuration work center, and choose the Overview view.
• Select the fine-tune activity Default Account Determination Groups for Product Categories.
• Choose View.
• Here we can view the Product Category ID, Product Category Description , Default Account Determination groups for Materials and Services. 
• Account determination groups can be added / updated for the Materials or Services here.

1597417 - Error: Account determination group is missing for product category

Account determination group is missing for product category, account determination for services, account determination for materials  , KBA , SRD-SRM-PRO , Purchase Requests and Orders , Problem

Privacy | Terms of use | Legal Disclosure | Copyright | Trademark