Automatic Account Determination

Automatic Account Determination

This is perhaps the part that causes the most heartache for the FI Configure.   For some reason, although it is an integration area, the FI team always ends up with responsibility for it. 

The IMG section under GL / business transactions / integration will take you through all the necessary account determination for the automatic postings that the system may need to post.  You may not need all of these.You could maintain on an as needed basis.  As the project teams test or prototype their expanding functionality, the SAP system will look for the accounts to which it should post.  The error message and the SAP documentation and configuration does not always explain clearly which piece of account determination is used for which type of functionality, so it is sometimes difficult to be pro-active. 

Being reactive has the benefit that hopefully each side (eg: MM and FI) can develop an understanding of what the business transaction is and therefore where it should be posting. Otherwise the MM person may not even be aware that he has generated a certain type of posting ! (You'd be amazed at some of the lack of ownership from a logistics consultant for the financial postings that they generate).

Will be explaining each account determination area simply and clearly with posting examples

Whenever you change the field status settings for an account, ensure that you have verified that any automatic postings will be able to meet the requirements. EG: do not make business area mandatory if your system may make a posting which cannot determine and post the business area.

Consider specifying that accounts that are posted to automatically can only be posted to automatically.  This will simplify reconciliation between the source module and the GL account should you need to do this.

SD-FI Account Determination and Postings

This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc).  This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger.

The integration is controlled both in SD and in FI.

In SD there is a awesome area of configuration called the pricing procedures.The pricing procedure determines the final price quoted to the customer for a particular product.  This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc.  These prices or charges are called 'condition types'.  This condition technique is used in a number of areas of SAP.

For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys).  You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:

       ERF freight revenues

       ERL revenues

       ERS sales deductions

       EVV cash settlement

       MWS sales tax

Now we start getting to the integration by mapping the account keys to GL accounts.  But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach.  Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to.  The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!

So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc  (Yes it is that 'condition technique' kicking in again.  Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )  

We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys".

The chart of accounts part is standard in all account determinations, so let us look at the rest.  This access sequence allows us to specify different GL accounts for different Sales Organisations. 

So if we had a billing document line item where the customer had some special deductions for one of the products he purchased, we could map accounts by Sales Organisation.  To make it even simpler a document is within one Sales Organisation so we have an overall mapping as follows:

SD Line Item	Condition type	SD Amount	Account Key	Sales Organisation	GL Account
1	Sales deduction for being such a nice guy	$10	ERS	1000	800010 - Sales deductions for 1000
	Sales deduction for special promotion on particular product	$15	ERS
	Base Revenue	$200	ERL		800000 - Revenue for Sales Org 1000
	Total for item 1	$175
2	Base Revenue	$100	ERL	1000	800000 - Revenue for Sales Org 1000
	Total for item 2	$ 100
Document Total		$ 275

So the invoice that the customer gets (and that you can view in SD) will look something like:

Item (Note this is the SD Invoice line item)	Amount
Item 1:	$175
Item 2:	$100
Total owing , 30 days terms etc:	$275

The GL document posting that the system will make to FI will look something like this though:

FI Line Item	Debit / Credit	Account	Amount
1	Debit (PK=01)	Customer (AR Account)	$ 275
2	Credit (PK=50)	Revenue (GL Account)	-$ 300
3	Debit (PK=40)	Sales Deduction (GL Account)	$25
Balancing to 0 as all GL documents must....			$0

Note : There is no direct relation between an SD Line item and an FI Line Item - they are different things.

Other considerations:

       Remember that if you are using business areas, then depending on your configuration there, the system may create additional FI line items if it needs to post to different business areas.  This may be even more of a reason why you do not need additional GL accounts.  If your Sales Organisations already map to different business areas, you could use the GL accounts for all Sales Organisations.

       Different access sequences will allow a broader variety of GL accounts (for example: by customer account) group. I strongly suggest having a good understanding of the reporting requirements expected to be supported from the General Ledger vs the SIS (Sales Information System)  or CO-PA (Profitability Analysis) or (CO-PCA) Profit Centre modules before you create too many GL accounts.  At the risk of repeating myself, the SD to FI account determination should only be as detailed as your statutory reporting requirements.   The reporting from other tools like Profitability Analysis are so much more flexible and powerful, you may never look at the General Ledger for internal profit reporting again except to do a reconciliation check.

The SAP Condition technique

Conditions have many uses in SAP.  The easiest to understand or to relate to is usually in Pricing, where conditions are used to specify the many components of a price (base price, surcharges, discounts, freight, taxes etc).  These components may differ for different customers, materials, regions - in fact they may differ in a lot of ways depending on the particular businesses requirements. We may give a customer in West Australia a better price or discount for a product than a customer in NSW for example.

We start with a procedure which I think of as a "spreadsheet".  This "spreadsheet" tells the system the calculations to do and the order in which to do them to calculate the final price or cost of an order item.  Each type of calculation is specified by a condition type.   In other words the condition type is simply telling the system what kind of calculation to do (a flat amount or a percentage for example).  It does not in itself say what numbers to use.

Procedure (Spreadsheet)
Line Number	Condition Type (Calculation Type)	Based On Line
10	Price
20	Discount	20
	Total

When an order is entered into the system, the system knows a whole lot of information (everything it can get from the customer master, the material master and whatever was entered on the order itself).

It first works out which procedure to use (using procedure determination configuration).  Then for that procedure, it needs to look up what numbers to use for the calculations in the "spreadsheet".  IE: what prices apply here, what discounts, what taxes for this customer, material etc.

For each condition type (or calculation type), there can be lots of records in the system with numbers (e.g.: lots of different prices).  The system needs to know which is the right record (or price) and in which order should it look for the right record.  The configuration lets us specify an "access sequence" for each condition type.  The access sequence tells the system in what order to should "access" or look for records.

For example for the 'PRICE' condition type it may have the following order:

'Price' Access (Look Up) Sequence
Description	Table
Region / material	100
Customer Group / material	120
Material	200

So the system will first look in table 100 which is keyed by region and material, and will look last in table 200, which is keyed just by material.   Each condition table will have some condition records (master data).  For example table 100 may have:

Region	Material	Price
WA	X	10
NT	X	12

Table 120:

Customer Group	Material	Price
A	X	11

Table 200:

Material	Price
X	15
Y	200

For a condition record to be the 'right' record, the information in the order, customer master or material master must match the key of the record.  If not then the system will go on to check the next table.

Worked Examples using data from the example tables above
Customer	Customer Group (from the customer master)	Region	Material	Price
1234	A	NSW	X	11
1224	A	WA	X	10
2346	C	QLD	X	15
1224	A	WA	Y	200

A similar lookup is then done for each condition type. E.g.: the discount condition could specify various percentage discounts.

TAX APPLICATION

For the tax condition type, it is most likely that the tax classification fields on the customer and material master would be used as keys for the tax condition records.

SAP Fiori for Sales & Distribution

SAP Fiori is a collection of applications created by SAP under the new SAP user experience (UX) paradigm. SAP Fiori is part of the HANA suite of products launched in 2013. This is how will benefit from significantly better screens, simplified flows, and renewed transactions with the use of SAP 

Fiori apps.

SAP Fiori apps that are specifically designed for SD. We recommend that you verify the listed apps, and determine which ones are most suitable to your specific needs and business. You should also check to see whether any further waves of apps have been released. As a reminder, transactional apps can be implemented with your current database, which means that installation of the SAP HANA environment is optional for this type of app. (That’s right: you can benefit from SAP Fiori transactional apps without even installing SAP HANA)

SAP Fiori UX, App Types

To provide you with the best user experience, SAP Fiori provides four types of apps. 

Transactional 

Task-based apps, where tasks such as change, create or approve are performed. You can run transactional apps using your current database. For transactionalapps, SAP HANA migration is not mandatory.

Transactional apps Features

• There are some activities can be performed from Fiori Cockpit where browsing and searching for sales order is possible.

• All the information related with selected sales order could possible, like, display sales order line items, availability check, pricing, etc.

• Changing Ship-to address is also possible based on the data available in customer master.

• Preceding documents like multiple or single shipment for the ordered items is possible.

• Invoice can be found by searching with reference to customer, document number, purchase order and sales order

• A clear overview of Invoice details available.

• an advantage of finding all contracts of a single customer and switching between them is possible here.

• A clear overview of contact details available.

Analytical

Apps dedicated to trigger insights and KPIs, or other related analyses.

Analytical apps features

• From the process flow screen it is possible to view any issue related with customer details, requested delivery date, etc.

• During issue solving we can find issue type wich signifies the document on which we have block.

• A issue list can be generated with expected dates of product availability, shipping and picking.

Factsheet

Apps.that allow sales rep to search and explore information.

Fact apps Features

• Header and Item level business data are available in FactSheet.

• A document flow is possible to see through Factsheet. Where it shows the preceding and subsequent documents.

SAP Smart Business

Apps that allow sales rep. to analyze and evaluate strategic or operation KPIs in real time.

Key Features

• To fulfil the business needs of internal Sales representatives we can create one or more KPIs. 

• Using these KPIs we can access SAP Smart Business.

• Through availability check order quantieies can confirm. 

From Issue list its possible to get the block details and then it can be removed from billing document. 

Output Determination in SD

The output determination component is used for output control. Output control is used to exchange information with internal and external partners.

Output determination in sales and distribution allows you to control proposal using assignments and groupings in such a way that the system selects the output allowed in each sales transaction and carries out output processing according to predefined criteria.

In the SAP System there are two possible ways of controlling output determination for each output:

Proposal of output from the customer master record.

Proposal of output using the condition technique.

SAP recommends the output proposal using the condition technique. This is because it is much more flexible than taking the proposal via the customer master. For example, the condition technique makes it possible to determine the most suitable output from several different types of output.

The output determination also involves

Condition Table

Access Sequence

Condition Types
Output Determination Procedure

Output Determination Procedure Assignment


1) Condition Table-TCode V/57

SPRO Path -IMG - SD - Basic Function - Output Control - Output Determination using Condition Technique - Output Determination for Sales Documents - Maintain Condition Table

You have to define combination of fields for which you want condition records in condition tables of output. Provided existing standard condition tables does not meet your requirement. In case of new condition table enter name of condition table, the number of table must be starting from 900. Select the fields for table from allowed fields and generate new condition table.

2) Access Sequence

SPRO Path IMG - SD - Basic Function - Output Control - Output Determination using Condition Technique - Output Determination for Sales Documents - Maintain Access Sequence

You have to define new access sequence by copying existing one and change to your requirement, provided standard access sequence does not meet you requirement. It is search strategy which system uses to find out condition records stored in condition tables for condition types. Unlike pricing, all output type has access sequence. Therefore, you maintain output condition record for all output types.

3) Output Types TCode V/30

SPRO Path IMG - SD - Basic function - Output control - Output determination using condition technique - Output determination for sales documents - Maintain Output Types

You have to define new Output types by copying existing one and change to your requirement, provided standard output type does not meet you requirement- 

Languages of Output
Print Program: print specification
SAP Script: layout
Partners (to whom you need to send output)
You need to mention Partner function wise Output type. 

Assign Output types of Partner Function
SPRO Path IMG - SD - Basic Function - Output Control - Output determination using condition technique - Output determination for Sales documents - Assign Output type to Partner Function

Here you assign Output types to desired Partner function like SP/SH/PY etc.. Generally that would be the intent recipient of that output type.


4) Maintain Output Determination Procedure

SPRO Path IMG - SD - Basic function - Output control - Output determination using condition technique - Output determination for sales documents - Maintain Output determination procedures

You have to define new Output determination procedure by copying existing one and change to your requirement, provided standard output determination procedure does not meet you requirement.


5) Assign Output Determination Procedure

TCode V/43 

Assign Output determination procedure to Sales document header level

TCode V/69 

Assign Output determination procedure to Sales document item category


SPRO Path IMG - SD - Basic Function - Output control - Output determination using condition technique - Output determination for sales documents - Assign Output determination procedures

You need to assign output determination procedure to Sales document. You may assign as per your requirement Header level and item level.

Similar steps could be followed for output determination for Sales activities and Billing documents.

Define Communication Strategy
SPRO Path IMG - SD - Basic Function - Output Control - Determine Communication Strategy

You need to create communication strategy, system should search for communication methods in case of transmission medium 5.

Output Determination Level & Assignment in Sales

Output Determination - Level

Assign to Output Determination - Sales Document:Header assigned to Sales Document Type 

Output Determination - Sales Document: Item assigned to Sales Document Item Category 

Output Determination - Delivery Document: Header assigned to Delivery Type 

Output Determination - Delivery Document: Item assigned to Delivery Item Category

Output Determination - Billing Document: Header assigned to Billing Type

Output Determination - Billing Document: Item assigned to Billing Type


Some Standard Output Types

Output Type relevant Sales Document


Standard Output Type

Transfer Order -WMTA 

Packing -PL00

Sales Orders -BA00 

Cash Sales -RD03 

Sales Invoice -RD00 

Delivery Note -LD00 

Condition Record


Without or in absence proper condition record maintenance, the desired output type will not determine in relevant sales document type. Therefore condition record is crucial in Automatic determination of output type.

Condition Record Maintenance for

VV11 / VV12 / VV13
Sales Document relevant Output Type


VV21 / VV22 / VV23
Delivery Document relevant Output Type


VV31 / VV32 / VV33
Billing Document relevant Output Type

Output types are used to represent various format of output in the SAP system, Eg of output types in Sales and Distribution processing are order confirmations, freight lists, and invoices. You use the output type to control how the output should be transmitted, Eg, whether an order confirmation should be send via EDI, or printed.