This is perhaps the part that causes the most heartache for the FI Configurer.   For some reason, although it is an integration area, the FI team always ends up with responsibility for it.  To do a good job you need a reasonable understanding of...]]>

Automatic Account Determination

This is perhaps the part that causes the most heartache for the FI Configurer.  
For some reason, although it is an integration area, the FI team always ends up with
responsibility for it.  To do a good job you need a reasonable understanding of :

1. the business processes in the source modules
2. the FI account postings that they should be generating (what sort of account should be
   debited or credited etc)
3. the organisation structure and its relationships between the source modules
4. the reporting requirements that are expected from the General Ledger or Profit Centre
   Accounting
5. your chart of accounts

Sounds daunting doesn’t it ?  Here is a suggested approach …

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).

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

• SD to FI Account Determination (aka revenue account
  determination).  This and MM seem to confuse people the most.
• More later – This may take a while to complete……..

In the meantime, some general
warnings:

• 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:

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

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

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.

– Main.IvanWong – 23 Jan 2002

Solution, Process and Role-Oriented Education
The new look of SAP Consulting Education incorporates the concept of PACE for developing the educational curriculum. The improved curriculum are based on the Generic Profile Maps, just as the SAP Solution M...]]>

[Updated Jun 2003]

Solution, Process and Role-Oriented Education
The new look of SAP Consulting Education incorporates the concept of PACE for developing the educational curriculum. The improved curriculum are based on the Generic Profile Maps, just as the SAP Solution Maps, it indicates what consulting knowledge is needed for implementation of SAP solutions. Instead of modules, consultants should apply their know-how in the form of business processes. This means that consultants must be able to carry out cross-module implementation. Check out http://www.sap.com/asia/education/ for more information.

SAP currently structures it’s training packages on three broad levels:

SAP provide an Application/Technical Academy, which they claim is the best route for those who do not have any SAP System know-how, who wish to gain knowledge and become a Certified Consultant for the SAP R/3 System.

Experienced, Non-Certified Consultants may take the exams directly, or supplement their knowledge with some alternative courses before taking the exams.

Other applicants can choose to do a standard course in one of the following areas:
Financial Accounting
Controlling
Sales and Distribution
Materials Management
Human Resource
Production Planning
ABAP Workbench

Many people have got their SAP careers kickstarted by obtaining certification beforehand. However, to quote Jon Reed, ‘the key to long-term success in SAP is to develop a career strategy that parallels SAP’s own evolution from “back-end” solution to “outward-facing” e-business architecture.’

From an article in SearchSap, he further comments on the merits of certification:

‘First of all, you don’t need to work for SAP directly in order to become an independent consultant. And if you’ve read my previous columns, you know that I think SAP certification is overrated. You need two things to succeed as an independent SAP consultant: You need a hot, niche skill, backed up by years of relevant, focused experience, and you need client references from multiple SAP projects. Judging from your background, it doesn’t seem like you have either one of those things. The good news is that it’s still possible, in some instances, to break into SAP consulting even if you’ve only worked on one SAP engagement. However, you do need a deep, focused niche. You must address this issue if you want to “go independent.” My suggestion would be to forget about certification and training, and start applying for SAP contracts right now. At this point, if you actually land a contract, that’s a bonus. What you’re really trying to do is get some feedback from hiring managers and find out where your skills fall short. It can be hard to get this kind of specific feedback – too often, the only reply you get is “no thanks,” but be persistent and try to get some feedback that helps you to identify the gaps in your background and figure out which of your skills are the most marketable. Once you determine that, you want to enhance/focus on the hottest skills you have. You might be able to do that within your current project, but if you hit a wall there, consider applying for a perm job at another SAP end client. Those kinds of jobs are out there right now – not in abundance, but they’re there. They aren’t lucrative, but your main goal is not money at this point anyway. Getting an additional project under your belt will give you more credibility and better prospects for future contract positions. Just do your best to choose a perm position that will build on your best skills.’

I believe he offers solid, proven advice. At the end of the day, what employers want is proven SAP experience, and that cannot be obtained solely by attending all the relavant SAP courses.

Further Reading

Advice from Jon Reed from SearchSap

> I’m planning to take a SAP course and came across a lot being offered. I would like to get your expert advice on which course to select. My background is that I have a college degree with double majors in Accounting and Management Information Systems. My knowledge of accounting is very solid. However, I’ve ended up working as a programmer in Cobol and Mainframe environment for 6 years. The SAP FI functional module seems to be very attractive to me but I really don’t know what to choose. I hope you will be able to help me out after knowing my background specifically. Your advice/input is most appreciated. Thank you and hope to hear from you!

This question posed on 25 July 2002

We’ve gotten several questions recently from folks with a combination of financial and IT experience who are trying to break into SAP. At first glance, that would seem like the perfect background for SAP, since successful SAP implementations require both heavy technical skills and strong business process knowledge. However, there are very few successful consultants out there who are 50% functional and 50% technical. We have seen that type of hybrid consultant succeed on smaller SAP projects, where everyone on the project wears many hats, but the bottom line is that there’s just too much ground to cover to stay current in both technical and functional areas at the same time. The ideal mix is something like 80/20 on either side, giving you just enough exposure to be able to interface with the other project teams. Your question seems to indicate that you are aware of this, and you’re trying to choose between functional and technical SAP work. Specifically, you want to either break into technical SAP work or the FI module.

It seems like you’re drawn to the FI work, but you’re not sure if you can pull off the transition from legacy programmer to FI specialist. In fact, this would have been a challenging transition even in the heyday of the SAP market. Right now, in such tight market conditions, that’s not going to easy to pull off. If you decide to try, you shouldn’t think of it as “breaking into FI,” you should think of it as “making a career transition from IT programmer to financial software specialist.” You should look at it as a five to ten year plan, and approach your transition as a long-term strategy with short-term benchmarks. If you look at it this way, you’ll see that SAP FI is only one way forward. There may be other ways of moving towards that same long term goal – for example, perhaps Microsoft’s Great Plains financial software acquisition is opening up new consulting opportunities you hadn’t considered.

But if we assume that you have your sights set on breaking into SAP, your best bet might be to stay technical, and get a perm mainframe programming job working for a major SAP client that is running a hybrid legacy/client-server/web-based IT infrastructure. In that case, you might be able to leverage your legacy expertise and get experience with real-time data integration over the web. This might lead you into Java and XML-related skills, and even if you never got specific SAP exposure, your new “hybrid” IT skills would position you better for the future. Over time, if you win the trust of your employer and make a major contribution to the project on the technical side, you might be able to get them to support a major career transition into the financials side of SAP. Just keep in mind, however, that as I’ve noted in another question this week, core SAP FI experience is also becoming less marketable, as FI becomes more of a back office commodity and less of an innovation. SAP is a moving target – often the best way to get involved is to anticipate where SAP is going next and meet it there. Don’t assume that what used to be hot will continue to be so.

Of course, I am not trying to imply that your previous accounting knowledge and degree is irrelevant. In the long run, it will give you an edge. I am only saying that in a tight market, hands-on project experience is the key to moving ahead. When the economy moves into more of a growth cycle, then more opportunities will open up and there will be more ways forward. Based on this outlook, before you make any serious moves you might want to have a talk with your current employer about your long term skills and career aspirations. It’s always good to try to get help from a company that already appreciates your contributions to date. Good luck!

Further resources
SAP Careers & Certification section at SearchSap.com
Futurestep
Other HR Links
Monster
JobsDB

Examples of industries with SAP industry solutions are the automotive, health, insurance, public sector, telecommunications, power, aerospa...]]>

Industry solutions are basically SAP’s approach to ‘tailor-making’ the basic ERP package to include best-of-breed solutions from specific industries.

Examples of industries with SAP industry solutions are the automotive, health, insurance, public sector, telecommunications, power, aerospace and defense etc.

See also SAP Industry Solutions Home

In addition to the organisation structure relationships that are directly defined in the Enterprise Structure / Assignment s...]]>
This article outlines some salient points in SAP’s implementation of validations and substitutions from a FICO perspective.

Indirect Assignment of Relationships

In addition to the organisation structure relationships that are directly defined in the Enterprise Structure / Assignment section of the IMG, there are further ways that one may need to define these relationships.  These definitions are still donein the IMG, but are buried in a module somewhere.  These are module specific: ie only required if one is using that module.

• Profit Centre Relationships
  
• Relationships created in CO-PA (Profitability Analysis)

Is there anything I have forgotten ? Note that pure master data relationships and account determination configuration is covered in other chapters.

Profit Centre Relationships

When one is using profit centre module and the various logistics modules, then one has to define the relationships in IMG / Enterprise Controlling / Profit Centre Accounting / Assignments to Profit Centres. However before we get too deep into that…

• If you are using SD and not using CO-PA (Profitability Analysis) either instead of or in addition to Profit Centres you should have a good business reason.  Please see my chapter on Profit Centres vs CO-PA for more information.
  
• If you are not using SD and using EC-PCA (Profit Centres) for Profit Reporting only, then I suggest you read my chapter on Profit Reporting
  

Relationships created in CO-PA (Profitability Analysis):

In CO-PA it is possible to ‘derive’ relationships for use in CO-PA.  This could be useful for groupings that are only required for CO-PA reporting. 

The derivation could be of entirely new elements or fields that are not being used elsewhere, or perhaps using an existing SAP field that is not being used by other modules.  The derivation can be based on any or a combination of fields in the data that is being passed to CO-PA.   A sophisticated example might be a derivation based on the SD Customer hierarchy.

It is not a good idea to try ‘overwriting’ values assigned in other modules as this would be confusing and complicate any reconciliation attempts.

See the configuration documentation on CO-PA for more information.  Note that there are ’standard derivations’ that the system does too.  We were talking here about creating new derivations.

This article presents a very basic bare-bones asset accounting setup. It assumes familiarity with SAP configuration terms and concepts.

Setup company codes to be used for asse...]]>

*Caution: article based on SAP ver. 4.0 is and to be used as guide only.

This article presents a very basic bare-bones asset accounting setup. It assumes familiarity with SAP configuration terms and concepts.

Setup company codes to be used for asset accounting.

1. Copy chart of depreciation. [Transaction EC08]

2. Set default tax codes for non-taxable transactions which require tax code. (Impt., errors often rise because this step is omitted)

3. Setup asset classes.

4. Set no posting to G/L for all classes except book depreciation (this is the typical setting)

5. Enable posting of unplanned depreciation and any other special postings (e.g. revaluation)

6. De-activate depreciation areas not required

7. Setup account assignments for all the asset classes. Note that the minimum accounts required are a balance sheet account for asset cost, for accumulated depreciation, and a P&L account for asset depreciation expense. [Transaction AO90]. Additional accounts that will be required are the gain/loss on sale and asset scrapping accounts. Note that more than 1 asset class can share the same account assignment.

8. Assign how depreciation posts to cost centers [Transaction OAYR]

9. Assign asset balance sheet A/Cs to profit centers if required [Transaction 3KEH]

10. Allow revaluation postings for selected company codes with revaluation [Transaction OAYR]

11. Run program RACHECK1 to eliminate inconsistencies between company code and asset management account data

12. Set document types for postings: (setting for transaction types). Suggested document types below:

AA Asset acquisition AS Asset disposal AT Asset transfer AX Asset reversal AF Asset depreciation [Transactions A071, OBA7]

13. Specify transfer of APC values [Transaction OABC]

14. Specify rounding of figures for net book value to nearest whole dollar [OAYO], table T093B

15. Setup depreciation keys as necessary: [Transactions AFAMA]

0000 No depreciation and no interest SLFD Str.line frm acq.value to 0 w/o int. frm start day

-Base method 11: Ordinary straight line using % from life to end of life

SLFM Str.line frm acq.value to 0 w/o int. frm start mth

-Base method 11: Ordinary straight line using % from life to end of life

16. Switch on only the required depreciation areas [Transaction OAYZ]

- Enter default depreciation keys for these 2 asset classes

17. Setup asset number ranges in production client [Transaction AS08]

Additionally, specify company independent number ranges that refer to a base company if necessary [Transaction AO11]

18. Check FI document number ranges for asset postings

19. Check that all asset G/L accounts have tax code and account groups correctly setup

20. Define screen layouts for each asset class as per user requirements

21. Set inter-co transfer methods (Maintain view [V_T093A_05])

Indicator: Transfer with historical values This indicator controls how the system treats transfers between affiliated companies. If this indicator is set, transfers in this depreciation area are not identified as acquisitions or retirements. Instead they are identified as transfers (particularly in the asset history sheet). In addition, posting of the transfer is gross (that is, with historical acquisition costs and depreciation).

Note:
This indicator has the affect described above only if it is used in combination with these two indicators in the definition of the transaction type: ‘post to affiliated company’ ‘gross’ Maintain view [V_T082I_01] for inter-company transfer settings

Optional-Revaluation Setup (Under special valuation section os AA IMG)

22. Set revaluation of cost and accumulated depn for all areas [OABW]

23. Define revaluation measures. (key, description, depreciation areas and posting data).

24. Specify G/L accounts for revaluation of asset acquisiton cost

25. Maintain transaction types for asset revaluation postings if necessary

If you found this website useful, please help support this site by purchasing your next SAP book through the Amazon links on this page.