Sapdup Blogging about SAP


SAP MM Automatic Account Determination

Sometimes I wonder how many implementations it would take to get the Automatic Account Determination process down-pat.

Every consultant I've dealt with has had to brush up on the account determination process before implementing it, no matter their experience level.

So, for my sake, and yours, here's a simple (as much as it can be) explanation of what Automatic Account Determination is, what it does, and how to do it.

Why do I need Automatic Account Determination?

Every time a transaction with financial implications is run, postings must be made to financial accounts. I'm a logistics consultant, so to be honest, I don't care. But it has to happen, so since this is an integration point between us and FI, unless you can make the FI consultant do it, we have to fight through it.

We could let the user enter the GL account each time we post an invoice or goods receipt, but SAP is supposed to be a productivity tool, so that's not really acceptable.

So, the idea is that the system will determine (based on our config) what account to post to depending on a number of factors, namely; company code, valuation area (plant vs company code), material / material type, transaction or business event and movement type.

So, with five variables, the determination system must be pretty complex?

Yes. When you come to understand the way SAP have done it, it is an elegant solution, but it is pretty damn complex.

Before you begin, sit down with the FI consultant, find out what accounts there are and in a business sense, how and when each of the accounts should be posted to. Discuss all five of the categories above. With this info set in concrete in front of you, you can begin the SAP config.

Here's the lowdown, try and stay with me.

Essentially all that is happening is that SAP are allowing us to maintain a record of "if x and y happen, then use account z" and "if a and b occur then use account q".

I can just imagine the conversation many years ago in Germany (translated for your convenience):

"Ok, we need a table of possible outcomes for account determination."

"That's faaarrr too easy. Let's break it into fifty different tables, come up with many interchangeable names for the same thing, and hide the tables beneath several different, unimaginable directory paths."

Configuration Steps

First up, since we have to do something first, let's specify our valuation control. This is done via IMG > Materials Management > Valuation and Account Assignment > Account Determination > Account Determination Without Wizard > Define Valuation Control.

All that we're doing here is specifying whether the system should consider the valuation grouping code in it's determination procedures.

"What's the valuation grouping code?" I hear you asking?

The valuation grouping code (vgc) is a collection of valuation areas that will have the same account determination. Since a valuation area can be a company code or plant, we can say that a vgc represents a group of plants or company codes that have the same account determination.

If you don't use the valuation grouping code, you'll have to set up account determination for each plant or company code in SAP.

If you're using the vgc, then jump into "group together valuation areas" and assign your company codes or plant a code (any code). They should be somewhere in the list automatically, all you should need to do is give them a code.

The next step is to manage different account determination per material type. This is where it can get complicated if you let it.

The valuation class is linked to an account category reference. The account category reference (acr) is an artificial code which allows flexibility in linking material types with valuation classes.

"Huh?" I hear you asking. Let's consider the alternatives.

We could relate the GL account directly to the material type. This would be easy to setup for a few material types, but would take a huge amount of time for many material types, and would be hard to understand if changes needed to be made.

We could use the valuation class, assign the GL account to it, and then assign valuation classes to material types. This is better, since we could for instance have a "Raw Materials" vc and a "Finished Materials" vc and then simply link all the various material types under each category to the valuation class. This would make updates and initial loads easier, but there is still one thing missing, a material type can only be part of one valuation class and can only post to one account.

However, in the real world, a material type may post to different accounts depending on things other than just the material type, such as plant, movement type or indeed any of the factors above.

So, we have an account category reference which is linked to a material type. This acr is then linked with a valuation class and the GL account is linked to the valuation class. So a material type can be linked to one or more valuation classes (and hence GL Accounts) and in turn, a valuation class can be linked to multiple material types (enabling ease of understanding and updates).

Now that you (hopefully) understand that, the actual updates are pretty simple.

Go to transaction: IMG > Materials Management > Valuation and Account Assignment > Account Determination > Account Determination Without Wizard > Define Valuation Classes and begin by defining your valuation classes. Then define your account category references and go back into your valuation classes and assign them (or you could do the acr's first). Then go into your material types and assign your acr's to your material types and done! For the moment.

At this point we should consider another factor, the actual business event that is occurring and it's effect on account determination. This is another area where you have to try and see through the impenetrable fog of terminology.

Each time "something" occurs in the system it produces a "key" for each of the postings that need to be made (i.e. debit and credit). This "key" is entered in our account determination procedure so that postings for credit and debit go to different accounts. Simple aye?

Well when (as far as I understand) the "something" can be called 'transaction (key)' or 'event (key)' and the "key" can be called 'value string', 'posting rule' or 'posting string for values' and the column header in SAP for the "key" says "Trans". Fun, fun, fun.

The combinations of movement type and "keys" and how they are determined are all internally programmed by SAP, so we don't really care. What we do care about is the account modifier or 'account grouping code'.

This is the topic I spent the most time on, and I'm still not completely clear, so don't feel bad if you're confused.

The account grouping code (aka account modification code, modifier or (in SAP) general modifier) is a three character code (which rather oddly has no link with the posting strings ("key")) which we use to break account determination down by movement type.

For example, by default in SAP, the system says for movement type 101 and posting key PRD there is no modification. So the account determination is not different based on movement type. However, I can enter a code (e.g. AAA) against movement type 101 and posting key PRD and code BBB against movement type 102 and PRD.

Then in 'Configure Automatic Postings' when we go into posting key PRD, we will make entries for 'general modifier' AAA, account 100000 and BBB of 100001 (there will also need to be an entry for a "blank" modifier which should cover all the other movement types).

So, make sense? Hopefully.

Now you need to go through and for each posting key that we're concerned with, record each of the defining factors mentioned above (you don't need to enter them if you're not using them) and enter a GL account for each permutation.

You should now find that your account determination is working. I wouldn't put any money on that promise. My hope is that having read this guide, you're a little bit closer to having your account determination working, and that in conjunction with a number of other resources you'll get there eventually.


PS: I will be updating this article periodically, and would appreciate your constructive criticism by commenting below.


SRM Sourcing via SAP Enterprise Buyer

Yeah, this is an official document from SAP about SRM.  I haven't used it extensively, but it probably has it's uses.


LO 620 Pricing Course Notes

The final installment (for the moment) in the series of SAP course notes is LO620, Pricing for SAP Sales and Distribution.

This document includes such wonderful topics as:

  • Course Overview
  • Pricing Fundamentals
  • Condition Technique in Pricing
  • Pricing Configuration
  • Working with Condition Records
  • Special Functions
  • Special Condition Types
  • Statistical Condition Types
  • Taxes
  • Agreements
  • Rebates
  • Summary



LO 615 Billing Course Notes

The next in the series of couse notes is LO615, Billing for Sales and Distribution.

This document covers such topics as:

  • Course overview
  • Introduction
  • Billing overview
  • Controlling the billing process
  • Special billing types
  • Data flow in billing
  • Creating billing documents
  • Types of settlement
  • Special business transactions
  • Account determination
  • SD/FI Interface
  • SD/CO-PA Interface
  • Conclusions



LO 610 Shipping Couse Notes

Here we have another set of course notes from the archives. These are for the old SAP course LO610, Shipping for Sales and Distribution.

As for previous sets, it's based on 4.6B (2002) so not exactly up to date. But considering course notes online are as rare as hens teeth, I consider this a pretty good resource.

This document includes the following topics:

  • Course Overview
  • Overview of the shipping process
  • Organizational units in shipping
  • Controlling elements of the outbound delivery
  • Functions relevant for shipping in the sales order
  • Creating and processing outbound deliveries
  • Special functions
  • Picking
  • Packing
  • Goods issue
  • Conclusions



SAP Sales and Distribution (SD) Example Exam Questions

I'm at my desk, watching the clock. Every tick of the second hand brings the inevitable closer. I'm now one second closer to the cataclysmic watershed moment of my life, my SAP Academy Exam.

"What if I fail?"

I drift off into the cloudy world of the not-yet come to pass

With a start I pull myself back to my study.

"Dammit, I will fail if I can't stay focused on my study."

"If only I had some example exam questions."


I've been there. And here we have my collection of SD Exam Questions. I take no responsibility for the accuracy of them or for whether they appear or not in the exam. That's for you to decide. And for the SAP Big Brother, I got these from a colleague who got them from somewhere. I did not steal them from any official SAP document.

Caution: more than one answer may be correct.
Please mark ALL correct answers.

Which statements concerning goods issue are true?

A Goods issue reduces requirements in materials planning
B Goods issue posts value changes to the stock account in inventory accounting
C Goods issue posts value changes to the stock account in asset accounting
D Goods issue posts value changes to the tax account
E Goods issue reduces warehouse stocks

Which of the following statements about billing are correct?

A. Invoice dates for creating invoices at certain times are maintained in the calendar.
B. You cannot carry out pricing again during billing.
C. A transaction-specific requirement, such as "deliveries must be combined in a collective invoice" can be set to control
D. If there are several payers for one delivery, only one billing document is created for each player.

How is the schedule line determined?

A. Item category and document type
B. Item category group and strategy group on the material master record
C. Item category and MRP type on the material master record
D. MRP Type and shipping point

When processing a billing due list, you have the following options:

A. The invoicing run can be started as a simulation run.
B. For performance reasons, the invoicing run via billing due list processing can only be carried out in batch.
C. The invoice run can be carried out for delivery-related and order-related billing documents simultaneously.
D. Order-related billing documents and delivery-related billing documents must always be created separately.

How does the SAP system enable you to check the reason for documents not being combined in a billing document?

A. Using the Spilt analysis function in the environment menu of the billing document.
B. Control of the document flow.
C. Control of the billing log.

How is the schedule line determined?

A. Item category and document type.
B. Item category group and strategy group on the material master record.
C. Item category and MRP type on the material master record.
D. MRP Type and shipping point.


SAP Sales and Distribution (SD) Resources

Below are all the SAP Sales and Distribution (SD) Resources I have collected so far in my career as a SAP consultant.

That's it for the moment.  Enjoy.


LO 530 Course Notes (aka SCM630) – Warehouse Management

If you're interested in SAP Warehouse Management, pick up this file of the SAP 4.6B Warehouse Management Notes.


LO 020 Course Notes (aka SCM500) – Processes in Procurement

This is the first in a series of posts of SAP logistics 4.6B notes that I found somewhere.  This post, the first, is of LO 020 - Processes in Procurement, Version 4.6B.

This is also referred to as SCM500 - Processes in Procurement.


SAP Transaction List

This page contains a list of transaction codes, their descriptions and the functional areas that are responsible for their configuration. I had originally planned to include the entire list, until I realised there were approximately 57,048. So I will start with the codes I've had to use, or at least heard of. Obviously as I study and work more, this list will be expanded.

If you're still looking for a particular SAP transaction, here is a complete list.

Transaction Description Comments Functional Responsibility
AC03 Create Service Master   MM
BP Maintain Business Partner Commonly used in CRM CRM
CJ01 Create Project   PM
CJ02 Change Project   PM
CJ03 Display Project   PM
FBL1 Display Vendor Line Items   FI
FBL3 Display G/L Account Line Items   FI
ME21 Create Purchase Order   MM
ME23 Display Purchase Order   MM
ME27 Create Stock Transport Order   MM
ME28 Release Purchase Order   MM
ME41 Create Request for Quotation (RFQ)   MM
ME42 Change Request for Quotation (RFQ)   MM
ME43 Display Request for Quotation (RFQ)   MM
ME45 Release Request for Quotation (RFQ)   MM
ME47 Create Quotation   MM
ME48 Display Quotation   MM
ME49 Price Comparison List   MM
ME4B Purchasing Documents by Document Number   MM
ME4C Purchasing Documents by Material Group   MM
ME4L Purchasing Documents by Vendor   MM
ME4M Purchasing Documents by Material   MM
ME4N Purchasing Documents by Document Number   MM
ME4S RFQ's by Collective Number   MM
ME51 Create Purchase Requisition   MM
ME52 Change Purchase Requisition   MM
ME53 Display Purchase Requisition   MM
ME54 Release Purchase Requisition   MM
ME55 Collective Release of Purchase Requisitions   MM
ME57 Assign and Process Purchase Requisitions   MM
MM01 Create Material Master   MM
MM02 Change Material Master   MM
MM03 Display Material Master   MM
MM60 Materials List   MM
MMPI Initialize Periods   MM
MMPV Close Periods   MM
OKENN Display Standard Hierarchy   HR
PA20 Display HR Master Data   HR
PA30 Maintain HR Master Data   HR
PFAL HR: ALE Distribution HR Master Data Used to replicate HR Data to SRM, also used for CRM HR
PFTC General Task Maintenance Used to display and edit workflow HR
PPOMA Change Attributes   HR
PPOSA Display Attributes Used to display attributes in SRM HR
PPOSE Display Organization and Staffing Used to look at org structure HR
SE16 Data Browser Alternative to SE16N BASIS
SE16N General Table Display A must! BASIS
SE17 General Table Display Alternative to SE16N BASIS
SU01 User Maintenance   Security
SUIM User Information System   Security
SWI1 Selection Report for Workflows   BASIS
SWIA Execute Work Items without Agent Check Used because it had a "forward to" icon BASIS
SWUS Test Workflow Used to restart failed workflows BASIS
VA01 Create Sales Order   SD
VA02 Change Sales Order   SD
VA03 Display Sales Order   SD
VA21 Create Quotation   SD
VA31 Create Scheduling Agreement   SD
VA41 Create Contract   SD
SM04 Session Manager (Close Hung Sessions) A must know
Filed under: General SAP No Comments