If you are a consultant or team member working with SAP Financials on an Enterprise Resource Planning (ERP) or Enterprise Performance Management (EPM) project, this blog’s for you.  You have the opportunity to influence the Financial Accounting (FI) blueprint on a new ERP installation, or you are in position to reshape an existing working design.  It is essential to have a broad perspective on your SAP chart of accounts (COA) design and to consider the impact beyond the ERP system how the chart of accounts may integrate with one or more of the SAP EPM tools:

• SAP Business Planning and Consolidation (BPC)
• SAP Profitability and Cost Management (PCM)
• SAP Strategy Management (SSM)
• BusinessObjects (XI)
• SAP Netweaver Business Intelligence (BI)

As a former Platinum Consultant at SAP who has had the opportunity to assist in or review many ERP implementations, and who now works with the EPM applications, I would conclude that the chart of accounts design is often done quite well to meet strictly the needs of the ERP system.

Case in point: when comparing legacy to SAP, many SAP projects can point to the success of reducing the number of G/L accounts which have to be maintained.  Indeed, on a typical SAP project, we’ll find that the legacy chart of accounts can be substantially trimmed, due to the nature of how SAP postings work.  It is not uncommon to reduce the number of G/L accounts from tens of thousands in legacy to just a few thousand G/L accounts in SAP.  This is possible because with the SAP posting logic in the Financial and Controlling (FI/CO) applications it is appropriate to eliminate the sub-ledger accounts, the cost centers, the inter-company segments, and other reporting dimensions from the chart of accounts, since these dimensions are captured in separate fields in the account-assignment coding block or in a sub-ledger.

However, if the evaluation of the SAP chart of accounts design is viewed more broadly than just the single purpose of meeting the needs of the ERP transactional system, then the grade is lowered.  Let’s look at some of the scenarios that prove to be challenges when trying to integrate the ERP chart of accounts with the EPM applications.  Then I’ll offer some suggested work arounds to these challenges.

1) Group Accounts

A common problem with trying to share a common chart of accounts between ERP and EPM is that planning is often done at a group account level (e.g. Total Salaries & Benefits as opposed to individual, detailed salary and benefits accounts).  To post a plan value at the group account level it means, of course, that the group account must exist in the master data (dimension members) in the EPM application.  Yet the owners of the chart of accounts in the ERP system have no use for the group account to exist in the master data. To remedy this group account issue, I’ll mention that the SAP ERP system provides the ability to assign each G/L account to a group account number (data element BILKT) or to an alternative account number (data element ALTKT_SKB1).  If carefully designed, either of these two fields could be used as the source for the chart of accounts in the EPM application, instead of using the main chart of accounts defined for the ERP system.  To the extent that some customers may have already defined their group or alternative account numbers for other purposes, then creative solutions have to be put forth for solving the group account issue required in EPM.  One creative approach is highlighted next in the discussion on sub-totals, but applies to the group account requirement as well.

2) Sub-totals

Another quandary often faced when trying to integrate the chart of accounts between ERP and an EPM application is how to handle sub-total result values, such as total assets, or net margin or net income.  These sub-totals are not needed in the master data in ERP, because they can’t be posted to and are calculated on the fly in reports.  However EPM applications might directly plan or need to report against these values, without wanting to have to accumulate all the detailed account data into the sub-total levels.  To solve these issues, I am aware of projects which have created financial statement versions in ERP with the appropriate level of summarization they needed for planning or reporting, then through a custom program they have created the necessary master data automatically (either in ERP or NW-BI) by building it from the hierarchy nodes.  This solution is useful because it offers a controlled process for master data maintenance and keeps the source system primarily in the system book of record.

3) Planning-only Accounts

Another frequent problem encountered in an EPM project is the nature of planning is forward-looking and may require accounts that do not yet exist in the chart of accounts sourced from the ERP system.  Fortunately this problem can be addressed easily.  If planning needs special planning-only accounts used for forward-looking or what-if scenarios, then it is simple to create these accounts in the ERP system, but block them from being usable for postings in ERP.  Sometimes I have seen opposition to this philosophy, but the argument against it really does not hold up to the alternative of maintaining the chart of accounts in two places.

4) Account Texts

When looking broadly at the integration between the ERP and the EPM applications with regard to the chart of accounts design, one has to consider that some EPM applications interact with its dimension members (master data) using the account texts, rather than the account numbers.  In other words, the G/L account number may just be an attribute or property of the text values which is available for reporting, but data input and data selections use the text values themselves.  This fact makes it important, more than ever, to adopt standardized naming conventions and abbreviations in the text descriptions for each category of accounts.  Furthermore it makes it vital to avoid using special characters in the master data text descriptions, so that they are not misinterpreted in the EPM application.  Some specific guidance examples are provided below.

• Avoid use of the hyphen to not be confused with subtraction in a formula
• Avoid use of the asterisk (*) to not be confused with multiplication in a formula
• Avoid use of the plus to not be confused with addition in a formula
• Avoid use of the ampersand (&) to not be confused with a variable identifier

5) G/L accounts vs. Cost Elements

SAP users know well that the chart of accounts subject is not a simple topic and the fact that one set of accounts exists in Financial Accounting known as G/L accounts and another set of accounts exist in Controlling known as cost elements.  This complication has to be dealt with when attempting to integrate the chart of accounts between the ERP system and the EPM applications.  Which set of accounts is the right source for the EPM application?  In my experience, what works best is to take a superset of both the G/L accounts and the cost elements.  This is the same approach the Profit Center Accounting application took to this dilemma, as PCA was positioned as an Enterprise Controlling application above both FI and CO and sourced its data from both areas of the ERP system.  Thus, it is easy to integrate the chart of accounts between ERP and EPM if you elect to use the generic “Account Number” (data element RACCT) as master data, instead of the G/L account (data element SAKNR) or cost element (data element KSTAR).  If BW is a source to your EPM application, then the equivalent concept is use of the characteristic InfoObject 0ACCOUNT, instead of either 0GLACCOUNT or 0COSTELMNT.

6) Statistical Accounts

Many legacy general ledgers and competing EPM tools maintain statistical accounts for data such as sales volume, number of employees, etc. in their chart of accounts.  SAP offers a different approach.  For example, sales volumes may exist in the financial applications on the same G/L account or cost element as sales revenue, but stored in a quantity key figure (measure) which is different than the amount key figure.  Other types of statistical data such as headcount is typically kept outside of the chart of accounts altogether by what is known as a statistical key figure.  These variations in treatment for statistical data must be dealt with on projects that seek to integrate ERP and EPM applications on a case-by-case basis.  However, I am not aware of any situations that can not be easily accommodated either by maintaining separate dimensionality in the EPM application for the statistical accounts, or merging the statistical data with the main chart of accounts in the load files for EPM.

7) Once Source of the Truth

Too often at SAP projects I see the chart of accounts master list being maintained in a spreadsheet, with the practice of loading a file into the ERP production system at time of go-live.  Then thereafter, updates are maintained directly in Production. The commonly used offline strategy is usually taken for two main reasons.  1) They lack control of the development system resulting in creation of rogue chart of accounts data by unsolicited users.  2) They seek to avoid mistakes in creating accounts that get posted with the wrong field attributes (e.g. functional area) or the wrong numbering sequence.

In contrast to the off-line approach, I strongly advocate maintaining a central chart of accounts in the golden development client and promoting this master chart of accounts throughout the SAP system landscape through the SAP transport management system or, even better, through an ALE scenario.  By maintaining the chart of accounts in the golden development system, where no postings should occur, it is possible to delete an account number, for example, if the numbering sequences change, and updates to field attributes are easily handled.  Furthermore, this approach is a controlled process that is easily monitored for its progress, in contrast to the off-line method.  Most importantly, it offers the ability to have a complete and consistent set of master data useable not only for the ERP system for allocation logic, planning layouts, or report definitions but also by the EPM applications – no matter whether the project phase is in development, test, or production.  In other words this methodology, which I recommend, will give once source of the truth.

8) Chart of Accounts <> Financial Statement Items

It's an incorrect premise to expect that an extraction of the SAP chart of accounts from the ERP system can be used soley for financial statement planning or reporting in the EPM applications.  In many instances, the financial statement item definition is a combination of the account and another object.  Very typically this other object is the SAP functional area, but may also be a grouping of cost centers.  I'll explain in a separate webblog why so many SAP projects suffer in realizing their financial reporting due to the manner in which they have defined their functional areas.  Then I'll make a suggestion how this can be improved, especially when viewed from a broader perspective of integration to the EPM products. 

In my last Beyond ERP - Improve your SAP Chart of Accounts design to integrate with EPM I discussed some key considerations that will improve the integration between ERP and EPM regarding the chart of accounts design.  Today I am writing on a related topic to improve the design and use of the field in Financial Accounting called the Functional Area.  Together the chart of accounts and the functional area are often the building blocks for defining the items in the financial statements when the company presents its P&L using the cost-of-sales accounting method in the ERP system.  However, I'll explain in this blog why EPM users should consider using only the functional area field to define their line item or account dimension used for financial statement items.  This option necessitates a re-examination of the functional area design that starts in ERP.  Let's take a deeper look at this topic.

Cost-of-sales accounting

With the cost-of-sales accounting income statement, sales revenues are matched to the costs or expenses involved in making the revenue (cost-of-sales).  The expenses are listed in functional areas as the example is shown below.

Producing a cost-of-sales income statement in a typical legacy general ledger systems is achieved by simply defining the appropriate ranges of G/L accounts for each P&L row, since their chart of accounts probably will have included a departmental segment that is representative of the function.  However, given the architecture of the financial applications in the ERP system which separates the general ledger in Financial Accounting from the management ledger in Controlling, producing the cost-of-sales P&L is not as straight-forward, compared to other general ledgers.

Salary expense example

Realize it is possible and advisable to have a smaller chart of accounts in SAP than usually found in legacy G/L's.  In fact, the SAP chart of accounts will reflect only the natural categorization of the expense. For example, you may have only one salary account, rather than a separate salary account for each cost center (department).

But think about how salary expense is included in multiple lines on the P&L.  The salaries of the manufacturing supervisors are part of the cost of goods sold line, warehouse management salaries are in the distribution costs, plant and headquarters management costs and support function salaries are included in the administration section, the salaries of the engineers and scientists are rolled into R&D expenses, and so on.  How is this achieved?  The apparent answer would be to define the P&L rows using both the G/L accounts and the cost centers, but that approach is not recommended by SAP.

A brief history lesson

It is helpful to understand the origins of this issue.  In what is now referred to as the "classic G/L", SAP made the design decision to not encumber its general ledger reporting tables with the cost center field.  (For emphasis, I make the distinction between a reporting table (e.g. GLT0) verses the document line item table (BSEG) which does contain the cost center field). To the architects at the time, it would not have been good judgment to add hundred or thousands of rows of cost center detail to the general ledger, in order to be able to summarize it back to a few lines on the cost-of-sales accounting P&L.  Thus the idea of the functional area field was born.  The trick was to utilize the account assignment objects (such as the cost center, or the WBS element, or the order) provided in the posting to determine the "functional" nature of the expense and to update the reporting tables (GLFUNCT, GLPCT) by this new functional area dimension.  The result was the cost-of-sales type P&L could be rendered using the functional area or a combination of the accounts and the functional area, while still keeping the financial reporting table(s) relatively small to minimize any performance deterioration that would have occurred if the cost center field were to be added.

[For completeness I will mention, lest I'll hear from you, that with the "New G/L" that has been available since the release of SAP ERP 2004, the cost center field is now available in the general ledger reporting tables.]  However, the functional area field persists there too and is still the preferred way of creating cost-of-sales P&L statements.

Common practice

In my prior solution review experience at many ERP projects, I have often seen the functional area field defined to provide only the few lines of detail needed below net sales on the P&L.  In a typical installation, the functional areas often included lines for cost of goods sold, distribution, general and administrative, selling, and R&D.  The functional areas did not typically include balance sheet accounts or top-line P&L accounts, such as revenues and discounts.  But this design of the functional area posting logic causes some FI document lines items to have a blank functional area (balance sheet and P&L accounts through net sales, for example), while other line item expenses to have the functional area field populated.

The above design of the functional area posting logic is common practice and works for ERP-based reporting.  In order to produce the P&L in the ERP system, it involves creation of the Financial Statement Version.  The financial statement version can be defined using G/L accounts, functional areas or a combination of both of these elements.

However the design and use of the functional area as described above does create issues when attempting to deal with financial planning and reporting scenarios in other applications, such as with Netweaver BI or the EPM tools.  I'll explain more shortly, but first I will mention one shortcoming that exists even in the ERP system book of record.

Audit and Controls

From a financial audit and control perspective it is better to have the functional area field always filled and an error message output from a validation rule if the functional area is not derived in the posting.  Otherwise if the functional area is not filled on each line item, it may be just intended or it could signal a missed assignment or substitution rule, an event you would not want.  Of course, a similar validation rule could be used to verify a functional area is derived when expected for a subset of accounts, but it would require more advanced prerequisite logic to look for certain ranges of accounts and/or to check for the existence of cost objects.  In other words, it is easier to issue an error message, if the functional area is not populated in the financial document, and this is a more consistent and complete design for the audit team to sign-off on.

Best practice

Since not all common practices are indeed best practices, I would like to recommend to you what I consider to be the best practice for the functional area design.  Namely, to define the functional area as the lowest level that you seek to show on your financial statements, then to create a financial statement version hierarchy without accounts by using only the functional area.  This means, of course, that every financial posting needs to have the functional area filled no matter if it involves a balance sheet account, a revenue account or a discount account.  What does this alternative design offer?  It becomes obvious when attempting to utilize other tools beyond ERP for financial planning and reporting.  Let's look at a common issue that arises in BW if the common functional area design scenario exists.

BEx Reporting

A frequent and undesirable problem that I came across on SAP projects was a lack of drill-down from the financial reports.  This manifested when attempting to create financial statements using the BEx Analyzer reporting tool within the SAP Business Warehouse.  Financial users demand the ability to run financial reports and drill-down into details of what caused a variance on a report, for example.  If they see a variance in the distribution section of the P&L they want to drill-down and see if it was caused by warehousing or transportation, for example.  If it was in warehousing, they may want to know was it at company-owned warehouses or leased space, and so on.  They want to keep drilling down in logical groupings of expenses until they reach the detail level.  Ideally, users are able to traverse a hierarchy of financial statement items to do this analysis, and they can open or close a hierarchy node at their will, without having to see all row expansions at once.  Nor do they want to be presented a financial report that contains the list of accounts in one column and the list of functional areas in the next.  This output creates an almost unreadable grid effect, but it is prevalent in BEx reports that attempt to use a hierarchy along with another drill-down characteristic in the lead columns.

To present the cost-of-sales P&L appropriately formatted in BEx, it may be necessary to define the rows individually using a combination of both the chart of accounts and the functional areas.  In BEx, this query definition must contain what is known as a row structure.  In practical usage, structures greatly limit the ability for users to drill-down in an ad-hoc way.  Typically, report-to-report jumps have to be setup before hand.  Creation of structures and creation of jump queries are usually only handled by a small group of so-called powerusers.  Due to an unfortunate design of the functional area field in the ERP system and the resulting reporting issues, widespread roll-out and use of ad-hoc reporting to all members of the financial community is hampered, which reduces system acceptance and lowers the project's return on investment.

0GLACCEXT

The problem described above was not intended by SAP; however it is a common issue experienced on projects because the designers don't define their functional areas optimally and they often do not utilize delivered BI content for financial statement reporting.  See the link on Financial Statement Reporting in SAP BW for more background information.  Within the standard BI content there exists the characteristic InfoObject 0GLACCEXT used for financial statement items.  This special characteristic is unique since it can contain G/L accounts as well as functional areas.  In this way, both P&L reporting methods (cost-of-sales and period accounting) can be displayed in the SAP BW system. 

Task steps

In summary, a useful approach to take with the functional area design is summarized into the following task steps.

1) Define functional areas equal to the lowest level wanted to be displayed on financial statements. This is applicable to both balance sheet and P&L.

2) Assign functional areas to CO objects and where possible directly to G/L accounts and cost elements. Be careful since it may not be possible until the next fiscal year start to change an assignment after a posting is made to these objects.

3) Define substitution rule steps to derive the functional areas, if the direct assignment option is not suitable for each circumstance.

4) Define the financial statement version using only the functional area.

5) Run report RFBILA00 in ERP to validate results.

6) Activate BW business content for the following:

• 0FIGL_VC2 Cost of Sales Ledger: Balance Sheet and P&L Statement
• 0FIGL_C01 Cost of Sales Ledger: Transaction Figures

7) Setup the ETL related to the above; specifically see that the financial statement version is created as a hierarchy on InfoObject 0GLACCEXT using datasource 0GLACCEX_T011_HIER for BS/P&L item.

8) Run query 0FIGL_VC2_Q0001 Bal. Sheet and P&L (Cost-of-Sales Acc.): Actl/Actl Comparison

EPM suite integration

In the EPM applications, most P&L models need an account or line item type of dimension.  Depending on your planning or reporting needs, that may best be represented by the chart of accounts as I explained in my prior blog.  But if financial statement reporting is desired, the chart of accounts alone will not be sufficient and the functional area field may also be needed, if the financial configuration has been defined as common practice.  Sometimes the data modeler does not want to deal with two dimensions in their planning or reporting process.  They may even decide to concatenate the account with the functional area field through ETL in order to deal with a single dimension.  Alternatively, if the functional area is customized differently in ERP as suggested here, the functional area field alone may satisfy financial statement reporting.  I've detailed how to utilize this approach in SAP BW.  This concept is easily extended to the EPM solutions, as the functional area field or InfoObject 0GLACCEXT could be used as a basis for the account or line item dimensionality in the EPM products.

As financial planning and reporting has transferred from the ERP system and into the Enterprise Performance Management (EPM) applications, it is important to re-examine the design and use of the core enterprise structure elements, in order to improve for an integrated solution across the entire suite.

1. BusinessObjects.  Quite a lot of material on Business Objects though maybe not as much as I had expected.  I saw Access Control in GRC.  On the Financial side there was an excellent session from SAP on PCM and how best to manage it with existing CO-OM and CO-PA solutions in ERP.  As expected, a lot of coverage was given to the SAP BusinessObjects Planning and Consolidation tools compared to only two BCS sessions.  It's interesting that the conference can serve as a measuring stick for the industry as a whole in a way that the SAP sponsored functions like SAPphire can't.  The WIS Expert conferences are dominated by Partners and Customers (Where are you ASUG?) so SAP's opionions and market direction isn't as prevalent here.  Based on that, BCS is dead and customers appear to be buying into BPC.
2. IFRS.  Anything and everything to do with IFRS was covered.  From a purely SAP ERP Financial perspective I sense more and more people are now recognizing that there is much more to IFRS than just migrating from the classic GL to the (new) SAP GL.  I've sensed for awhile that most customers assumed that one was dependent on the other (it's not) and that they are one in the same (definitely wrong).  But there was enough material and sessions that customers will start addressing IFRS soon.  Maybe this year...  but more likely they'll continue to just gather information and cutover later.  They have until 2014 and there needs to be more clarity as to how IFRS will be interpreted here in the US.  There were several sessions on how to best approach the adoption of IFRS; major implications, project planning, key tasks, etc.  All in all it was a very informative area.
3. In spite all of the new material for these new areas, the basics in FI and CO saw plenty of coverage.  I've always thought that customers still struggle with the basic block-and-tackling of SAP and that none of us should lose sight of this in spite of any of the new stuff...  in this case, "new" is anything that came out after 2000 (<-- that's both a serious statement and a joke at the same time).  FSCM, BOBJ, OutlookSoft, etc.  There are still numerous inefficiencies in basic GL processing, LIV, and most any other core FICO process that should warrant plenty of focus.  The sessions reflected that.
4. The SAP GL.  This has been one of the dominant themes at the SAP Financials Conferences for several years now.  2010 didn't see any drop off and the materials are getting better and better.  Plenty of informative guides on how best to implement the GL, different approaches, segment reporting and document splitting.  I sat in on some sessions from MI6 Solutions, QS&S and Vortex Solutions that were quite good.
5. Audit.  There were 18 sessions on Audit as compared to only 8 for FI and 12 for CO.  I sat in on one session regarding GRC controls which got a bigger turnout than I would have normally thought.  As a consultant that tends to butt heads with the Security folks, I can't say that I was happy to see this.  But seriously...  18 sessions on audit?  For an SAP event?  Wow.  It just surprises me that there was that much coverage and the turn out was as strong as it was.

Can an Asset Also be a Liability?

Virtually all fixed assets are retired at some point. They either get scrapped for no value or sold off to another party. In this typical process the retirement activity isn’t given much thought until it occurs. Simple, right?

But in some situations, companies that manage long life fixed assets are obligated to account for the retirement costs well in advance of the retirement itself. In fact, they have to account for the retirement costs at the time that the asset is initially capitalized and recognize it as a pending liability. The liability must then be continuously funded throughout the asset’s life and must also account for transactions made to the asset such as partial retirements, transfers, or other value adjustments. This poses a bit of a quandary because it means that a liability must be setup to offset the initial fixed asset purchase. So, yes, an asset can sometimes require its own specific liability.

• Integration – AROM is an end-to-end solution whereas previous solutions (noted above) tended to be a combination of point solutions within SAP ERP and external spreadsheets. AROM is integrated with the necessary components of ERP Financials such as the General Ledger, FI-AA, and Lease Accounting (FI-LA). Fixed asset records are created and automatically updated based on adjustments to the AROs.
• Automation – The AROM solution can automatically calculate the retirement costs, the terminal value and the initial settlement value of the ARO. It also automatically handles the monthly accrual postings, and the capitalization and ongoing depreciation of the ARO.
• Multiple Accounting Principles – As SAP customers continue to adopt international accounting standards (IAS) in addition to their local GAAP regulations, most and more SAP solutions are providing the ability to manage an item’s value to support different principles. AROM allows SAP customers to manage up to 8 separate accounting valuations for a single ARO.
• Rate and Event Changes – The ARO solution can account for changes in interest and inflation rates, as well as different events that might trigger adjustments to the ARO.
• Compliance & Control – By being integrated throughout the relevant modules of ERP, AROM provides a far more centralized, controlled, and auditable solution than previous off-line methods. AROM also provides tracking of changes to AROs as well details into the calculations and further analysis with the Asset Explorer and LAE Explorer.
• Reporting – A key advantage to AROM is that the reports provide a centralized and integrated list of a company’s AROs. AROM provides several ALV list based reports that provides detail into the AROs, their expected maturity date, their value, and their association to any underlying objects (assets, real estate, etc.). In addition, there is a sorted list report that is similar to the Asset History Sheet in FI-AA. Like the Asset History Sheet, it provides a way to flexibly define a column/row structure to best present the ARO data.
• Standard Solution – Accounting for AROs within ERP no longer requires a host of enhancements or any self developed screens/tables.

AROM is supported only on SAP ERP 6.0 EhP4. In addition, the EA-FIN add-on is required because the new depreciation calculation program that it contains serves an important function in the determination of some of the values. You can read more about the NewDCP in the following blog series (New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 1), New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 2), New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 3), New Ways to Depreciate Fixed Assets in ERP 6.0 (Part 4))

AROM heavily integrates with the Lease Accounting Engine (LAE) that is part of the existing FI-LA module. LAE plays a critical role for AROM because while the calculation of the ARO values is done within AROM, it is LAE that manages the posting of those values to the GL and FI-AA modules. LAE also provides functionality to the AROM solution to perform one time postings and provide detailed analysis via the LAE Explorer. Here is a diagram that gives an overview of how ARO and LAE relate to one another.

Next Blog

In the next blog I’ll provide specifics about how AROs are managed and calculated in AROM.

ERP Post Implementation Challanges – Part 1 Understanding COGM, COGS, Price Difference & Closing Stock Calculation

Author: Ranjit Simon John

After our Go-Live we had gone through various tough stages while trying to stabilise the system.

Major challenge we faced was resistance from end users, lack of confidence on the new system by the external and internal stake holders. Finally after working so hard on the various points raised by the internal as well as external team, we succeeded.

In this blog I would like to highlight the most important challenge we faced. Mainly they are two in number;

          1) Clarity on COGM,  COGS & Production Order Price Difference general ledger accounts.

          2) Trying to equate the formula

          Opening Stock + Receipt – Issue = Closing Stock

1) COGM,  COGS & Production Order Price Difference general ledger accounts.

Let us start with COGM;

There will be mainly two entries posted in Cost of Goods Manufactured;

1)    During Production Order Confirmation

2)    During Production Order Settlement

First let me try to explain the GL entries posted during various stages starting from Raw Material receipt to Finished Good sales.

The postings can be divided into various Parts;

Part 1: Raw Material Receipt 

               Step 1: Raw Materials are received. (Goods Receipt – MIGO_GR)

Part 2: Vendor Payment

               Step 2: Invoice Receipt

               Step 3: Vendor Payment

Part 3: Raw Material Issue to Production

               Step 4: Raw Material used for the production of Semi Finished Good 1

                               Step 5: Semi Finished Good 1 used as raw material for the production of Semi Finished Good 2

                               Step 6: Semi Finished Good 2 used for the production of Finished Good

                  Part 4: Finished Good received in Inventory

Part 4:                      Step 7: Finished Good Receipt

                 Part 5: Sales

                                Step 8: Sales Delivery

                                Step 9: Billing released from Accounts

                                Step 10: Customer Payment

Part 1: Raw Material Receipt 

                 GL Entries during Step 1: Raw Materials are received at Inventory

Table 1.0

Part 2: Vendor Payment

           GL Entries during Step 2: Invoice Receipt

                    Table 2.0

           GL Entries during Step 3: Vendor Payment

Table 3.0

                Part 3: Raw Material Issued to Production

GL Entries during Step 4: Raw Material used for the production of Semi Finished Good 1

Table 4.0

GL Entries during Step 5: Semi Finished Good 1 used as raw material for the production of Semi Finished Good 2

Table 5.0

GL Entries during Step 6: Semi Finished Good 2 used for the production of Finished Good

Table 6.0

Part 4: Finished Good Received in Inventory

GL Entries during Step 7: Finished Good Receipt

Table 7.0

Part 5: Finished Good Sales

GL Entries during Step8: Sales Delivery

Table 8.0

Live posting example during sales delivery. VL01N/VL02N.

GL Entries during Step 9: Billing released from Accounts

Table 9.0

Live posting example during sales invoice release from accounts using VFX3.

GL Entries during Step 10: Customer Payment

Table 10.0

Now let us try to understand COGM, COGS and Production Order Price Difference Accounts;

Finished and Semi Finished Material will be valuated at "Standard Price" for all COGM, COGS and Closing Stock calculation.

1.1) COGM: Cost of Goods Manufactured

Transactions hitting COGM account are;

a) Goods Produced

b) Goods Issued to Production Order

c) Reversal of Goods Produced

d) Entries posted during settlement of Production Orders ( Variance)

I have broken down the COGM entries for clear understanding. Please find the below screen shots.

The above figure is divided into three sections;

Section 1: Materials Produced

Section 2: Materials Issued

Section 3: Production Order Settlement

The below attached image shows how the Production Order Settlement amount of 1,403,463.52 has been arrived.

If  ML is not activated we will not be able to apportion the total variance between stock, COGM and COGS. We follow the below mentioned procedure to split the variance.

In the first column the total variance for each product has been entered. Second column we enter the total quantity produced for the material. So Total Variance / Production Quantity =  Variance Per Ton.

You have the quantity for Closing Stcok, COGM and COGS of the material. Multiply it with Variance per ton.

Closing Stock Quantity * Variance Per Ton

COGM * variance Per Ton

COGS * Variance Per Ton

1.1.a) Goods Produced:

              When a finished or semi finished good is produced i.e after confirmation stock of the finished or semi finished good will be Debited and cost of  manufacturing the finished or semi finished good will be Credited with document type "WA". (Refer Table 6.0)

Entires will be posted against the particular material i.e with material number.

                                                                       Figure 1.0

1.1.b) Goods Issued to Production Order:

When a Semi finished good is issued against a production order Stock of the semi finished good is credited and  cost of  manufacturing the semi finished good is debited with document type "WA". (Refer Table 6.0)

Entires will be posted against the particular material i.e with material number.

                                                                        Figure 2.0

1.1.c) Reversal of Goods Produced:

When a finished / semi finished good "A" Quantity is produced at "X" rate and reversed "B" Quantity at "Y" rate, the quantity will be reversed at "Y" rate and the difference in price "X - Y" will be posted in Price Difference and COGM account.

GL entries posted will be;

(For GL entries posted when Raw Material is Issued to Production of Semi Finished Good refer Table 4.0)

Table 11.0

1.1.d) Entries posted during settlement of Production Orders ( Variance)

During settlement of production order variance will be posted to Production Order Price Diff Account and COGM

KIndly chek my blog "Understanding Production Order Variance Part - 1 " (http://scn.sap.com/community/erp/manufacturing-pp/blog/2012/03/13/understanding-production-order-variance--part-1).

Note: There is no hard and fast rule for analysing COGM. Analyse COGM based on the analysis I have given above, if any other entries are posted we have to analyse those entries one by one.

Let me try to explain COGM entry for one material.

COGM entry posted for material "FG1" is 27,134.90 AED.

Let me explain the entries. "FG1" produced is (Execute Transaction Code MB5B for movement type 101 + 102 ) 28,507,148.10 AED.

"FG1" issued to production order is (Execute Transaction Code MB5B for movement type 261 + 262 ) 28,480,013.2 AED.

COGM -> 28,507,148.10 - 28,480,013.2 = 27,134.90

1.2) COGS: Cost of Goods Sold

For calculating Cost of Goods Sold materials will be va;luated at standard price maintained in the material master.

Execute Transaction Code MB51 for movement type 601 + 602. Also consider price difference during sales reversal.

Both the 601 & 602 values should match with COGS general ledger (If no price diference for sales reversal is there).

                                                                        MB5B 601 + 602 Report

                                                                                  Figure 4.0

                                                                           FBL3N COGS Report

                                                                               Figure 5.0

1.3) Production Order Price Difference Account

KIndly chek my blog "Understanding Production Order Variance Part - 1 " (http://scn.sap.com/community/erp/manufacturing-pp/blog/2012/03/13/understanding-production-order-variance--part-1).

2.0) Closing Stock:

Formual for closing stock;

( Opening Stock + Receipt ) - Issues =  Closing Stock

i.e Opening Stock + COGM = Closing Stock

But in most of the cases if we apply the formula the closing stock will not match. All material movement has to be considered while calculating closing stock of material.

Let us try to analys few Scenarios:

Scenario 1: Material Stock Transfer

Let us consider two materials RMOPCK2 and RMSRCK1

Table 12.0

If we substitute the values in the formula the closing stock will not match. We need to consider all material movements.

Table 13.0

Formula modified as below;

( Opening + Receipt + Price Diff. + Material Transfer ) - Issue = Closing Stock

Sustituting the Valyues

FG1 -> (276,120.06 + 116,157,464.09 + 37,161.73 + 225,528.12) - 115,882,172.88 = 814,101.12

FG2 -> (0.00 + 7,868,063.25 + 0.00 + (251,646.75)) - 7,616,416.50 = 0

Useful Transaction Codes:

MB5B - Material Movement Report

MB51 - Material Movement Report

FBL3N - General Ledger Report

Also Refer: http://help.sap.com/erp2005_ehp_06/helpdata/EN/7e/cb7ead43a311d189ee0000e81ddfac/frameset.htm

                 "ERP Post Implementation Challanges - Part - 2Reconciling GL, Raw Material Consumption, Finished/Semi Finished Material Production, Vendor Invoice"

In my previous blog "ERP Post Implementation Challenges’ - Part 1" I have explained the concept of COGM, COGS and deriving the closing stock. In this blog I will be concentrating on the Reconciling GL, Raw Material Consumption, Semi Finished / Finished Goods Production and Vendor Invoice.

Let me divide the topic into;

Reconciliation 1:

     Opening Stock + Raw Material Receipt - Raw Material Consumed  =  Raw Material Closing Stock

Reconciliation 2:

     Receipt of Raw Material = Invoice received from Vendor

Reconciliation 3:

     Raw Material Consumed = Raw Material Issued for the Production of Finished Good

                                         = Raw Material Consumption GL

Reconciliation 4:

     Raw Material Closing Stock =  Stock GL of Raw Material

Now let us analyze each scenario;

Reconciliation1: Opening Stock + Raw Material Receipt - Raw Material Consumed  =  Raw Material Closing Stock

As explained in my Previous Blog "ERP Post Implementation Challenges’ - Part 1" all material movements should be considered for calculating the closing stock of material.

Reconciliation2: Receipt of Raw Material = Invoice received from Vendor

     The Raw Material received should be matching with the invoice received from the vendors. I have done quite a lot of research to generate report on the list of invoices received against a material.

   Material Receipt (MB5B) with movement type 101+102 = Stock GL of Raw Material + Price Diff GL of Raw Material with Type "WE"

To find the list of Invoice generated against the Raw Material:

There can be invoice and Credit/Debit notes posted against the material.

To generate Invoice listgenerated against the material:

We have to combine few tables for generating the report.

Execute SQVI and create a query with the following data.

Tables: RBKP, RSEG, LFA1

Joining Condition:

Tables RBKP-RSEG -> Joining Fields BELNR,GJAHR

Tables RBKP-LFA1 -> Joining Fields LIFNR

Figure 1.0

Figure 2.0

To generate Credit Note / Debit Note listgenerated against the material:

We have to combine few tables for generating the report.

Execute SQVI and create a query with the following data.

Tables: RBKP, RBMA, LFA1

Joining Condition:

Tables RBKP-RBMA -> Joining Fields BELNR,GJAHR

Tables RBKP-LFA1 -> Joining Fields LIFNR

Figure 3.0

Figure 4.0

Debit / Credit will be recorded as "S" or "H"

Reconciliation 3: Raw Material Consumed = Raw Material Issued for the Production of Finished Good  = Raw Material Consumption GL

Raw Material will be consumed for the production of Semi / Finished Good, which will be created against Process Order. The total raw material consumed against a process order can be generated from transaction code KOB1.

Let me explain with an example:

Raw Material 1 (RM1) is used for the production of three Finished Good (FG1, FG2, FG3)

Total Raw Material RM1 issued during the period is 106,136.00 TO. This is the quantity used for then production of 473,424.00 TO of FG1, FG2, FG3.

Table 1.0

(Report from MB51 movement Type 101 + 102)

From transaction KOB1 we will be able to equate the Finished Good Produced and Raw Material Consumed quantity.

Figure 6.0

Figure 7.0

Raw Material (RM1) Consumption GL should be updated with the value of 1,061,360.00

(Report from FBL3N Raw Material (RM1) Consumption GL + Raw Material (RM1) Price Difference GL)

Fugure 8.0

GL Entries Posted During the Process;

Raw Material Consumed for Production of Finished Good

Reconciliation 4: Closing Stock = Stock GL of Material

Generate Closing Stock report for Material from MB5B

Figure 9.0

Stock Report of Material From FBL3N

Figure 10.0

Generally We can reconcile opening, receipt, issue Closing by inputting values in the table listed below;

Table 2.0

0 Quantity - Execute Transaction MB5B. Sort Based on Movement Type

0 Quantity Included Price Revaluation & MIR7 entries

0 Qty of FG1 Entry:

  0 Qty Other        =   54,700.53 +

Price Revaluation =  256,027.28

0 Qty                   -> 310,727.81

Figure 11.0

Table 3.0

Important Transaction Codes:

Table 4.0

Scenario We got a scenario where we have to calculate the withholding tax over a specific vendor on the basis of below mentioned rules.

If Cumulative Amount of Invoices raised by vendor is less than 1,00,000 then tax to be deducted is 4% & once the vendor raised us invoices more than 1,00,000 then 10% is to be calculated on additional Amount.

For Ex :

Case A

Vendor raised Invoice 1 ( Amount 1,00,000)

System will calculate 4% of 1,00,000

Case B

Vendor raised invoice 1 ( Amount 1,50,000)

System will calculate 4% of 1,00,000 & 10% of 50,000

Case C

Vendor Raised Invoice 1( Amount 50,000) , Invoice 2 ( 25,000) , Invoice 3 (1,00,000)

System will calculate 

For Invoice 1 : 4% of 50,000

For Invoice 2 : 4% of 25,000 ( Cumulative 75,000)

For Invoice 3 : 4% of 25,000  & 10% of 75,000

Proposed Solution :

Create a separate Withholding tax type for exemption purposes with configurations mentioned in screenshot.

Note : Tick Acc. wtax to max. & insert accumulation type per yr ( in case this cumulative exemption is to be maintained for a yr)

Create a separate Withholding tax code against this tax type.

Note : do not maintain any withholding tax rate & activate w.tax form.

Now maintain formula for withholding tax calculation

Enter the Tax type & tax code combination with an effective validity date ( from which accumulation actual takes place)

Select the line item & double click Formula for calculating .

Save & Enter this tax type & Tax code in the vendor master for which this exemption rate is to be maintained.

Note : System will only accumulate from the date it is maintained in vendor master. Old Entries would not be considered in accumulation of invoices amount.

Hope this document will help you

FICO Consultant: We’re done with successful UAT phase of the project, now we need to migrate legacy data to SAP ERP.

User:  What data? And from where can I get it?   

FICO consultants are less likely to face this question if they had prepared a Data Migration Strategy (DMS) Document and presented to the users in Business Blueprint Phase….. But preparing this document is not easy right?

Many junior consultants would try to search the web to find a DMS document or try to contact some senior folks for guidance, which is fine.  Senior folks may try to search folders of their earlier projects.  Even if we get few DMS documents, we need to understand well what data we need? And educate the users so that they may provide us good data.  In the following few paragraphs, in a simplest possible way, I would try give you the concept of data we need in each of the FICO sub modules.

Off course, we need Master Data of all important objects like GL, Customer, Vendor, Asset, Cost Center, Profit Center, Activity Types, SKF and so on……  but I would keep my focus on transactional data only, as this is what users need to understand.  I’ll also not go to the technical details of upload methods like LSMW, BDC etc. assuming we all know it.

Apart from normal GL accounts, we need one or more Data Migration GL Accounts, which must have a ZERO balance after the data migration. It’s a key check for accurate data migration in FICO.  The data migration GL Accounts must have line item display and Open Item management ON in their master data. 

General Ledger:

For simplicity we assume that we are migrating data from the start of a new fiscal year.  In this case we don’t need to migrate P&L Accounts.  Only Balance Sheet accounts should be migrated.   Even if the data migration is required during a Fiscal Year, I would not recommend migrating P&L Accounts.  In this case we should consider Financial Statements of the Last Closed Fiscal Period and post the difference of P&L accounts to Retained Earnings account defined in OB53.

Here we’ll talk about all balance sheet accounts except reconciliation accounts of Customer, Vendors, Assets and Materials.  The key decision to make here is to move all open items in each GL Account OR only the ending balance?  Obviously it’s a business decision but being FICO Consultant we should strongly recommend our customer to move only the ending balances of all GL Accounts.  An exception to this rule may be Inter-Company GL accounts.   We may need to break up the ending balance of IC GL Accounts for each Trading Partner Company code.

For each debit balance GL account e.g. Assets, data migration account will be credited. Vice versa for Liabilities and Equity accounts.

Assets:

For assets data migration we need to do some settings in SPRO for each Company Code we want to migrate.  The following settings are necessary:

The company code status must be set to 2:

We need to specify the date of Legacy Data Transfer. It determines the last closed Fiscal Period/year in Legacy System:

Rests of the settings are optional depending upon different factors, such as if the data migration takes place at Fiscal Yearend or during a Fiscal Year.

After the settings we can upload Asset Balances (APC and Accumulated Depreciation) through AS93.  We also have the option of migrating NBV (Net Book Value) if required by Business Users.  In my experience it’s better to migrate APC and Accumulated depreciation both which automatically calculates NBV.

AUCs (Asset Under Constructions) are treated differently than normal fixed assets.  We may need to migrate Open Items of AUCs.  It’s because the earlier AUC Line Items may still be open at the time of Data Migration OR more values are expected against some AUCs in future.

Accounts Payable:

All of the open vendor items (Invoices and Debit/Credit Memos) should be migrated to SAP ERP during Data Migration.  By “Open Items” I mean real open items: Means Invoices or Debit/Credit memos which are not actually paid.  Some times in many legacy systems Users may not have “Clearing” functionality i.e. they can’t knock off Invoices with Payments and Debit/Credit Memos.  In this case Users may have to do an extra effort to identify the real Open Items. If they can’t than it’s better to take only Vendor Balances, obviously with User’s acceptance/approval.

Data Migration GL Account gets debit for each Open Invoice and Credit for each Debit Memo.

Accounts Receivable:

Customer balances are very similar to Vendors.  I would recommend migrating Open Items and not merely ending balances.  We need to make sure Trading Partner Field is properly filled in all Intercompany Customer and Vendor Account Open Items.

Data Migration GL Account gets Credit for each Open Invoice and Debit for each Credit Memo.

Cost Center Accounting:

No balances are loaded to Cost Centers in case of Year End Data Migration.  We may need to upload Activity Type Quantities and Planned Rates through KP26. We may also need to upload SKF (Statistical Key Figures) for Allocation Cycles which may be used as Cost Drivers / Tracing Factors.

Periodic Cost Allocation business processes are not normally followed by many companies in Legacy Systems, so we may not need any upload for allocation cycles.  There may be few allocation cycles which may be manually created after agreeing with Users.

Product Cost Planning:

This one may be the most complicated task in data migration as we may need to create Standard Cost Estimate for all of the Materials (Specially Finished and Semi Finished Goods).  Since Standard Cost Estimate is highly integrated with BOM, Routings, Work Centers, Cost Centers, Activity Types, SKF, Material Master etc… getting an accurate or close to the legacy Standard Cost Estimate may require a lot for repetitions and adjustments in prices / quantities.

I may write a separate blog for this in future.

Profitability Analysis and:

No data migration may be required in COPA unless you agree on migrating P&L Accounts, which I would never recommend.

Profit Center Accounting:

In case New GL and Document splitting is ON, we need to assign Profit Center in all of the GL, AP, AR and Asset Balances.  No separate PCA transactional data upload may be needed.

Data Migration in SAP is a big subject, I understand it can’t be covered in one short write-up.  I write this document to share my experience with all of you and to know your experiences as FICO Consultant which you faced during the Data Migration phase.  I hope this blog may initiate some productive discussion about SAP Data Migration and we may share our knowledge.

ERP Post Implementation Challenges – Part 3 Preparing The Cost Sheet

Author: Ranjit Simon John

The main aim for any organization to implement any form of ERP is for various reasons, more profit, better decision making, easy reach of customers etc bottom line is more and more profit and no doubt SAP is the best option any organization can have.

We have implemented SAP ERP with the standard funstionalites with very little number of custom made reports. Initially it was very difficult to conculde whether SAP was taking us in the right direction since analysing and studying the system requires expert brains. We could see entries hitting finance from all directions and we were totally lost. IT department was given two options, either to discard SAP or proceed, the option was left out for us. Like all the other departments did it would have been easy for us to submit our weapons and surrender. Infact we decided to gather all strength and fight. The main idea that guided us through the entire battle was if we have to surrender that would have been a defeat from our side not SAP's, since SAP is a best practice ERP practiced and succesfully run by hundreds of organizations through out the world.No doubt SAP is a 100 % proven best practice across various verticals. The more and more I explore SAP my passion towards SAP grows.

We finally won the battle, sorted out all issues, clarifications. But the final clarification will be having only when the cost sheet is prepared and tallying with the GLs. I have to mention one tool that helped me in preparing the cost with ease, EXCEL4APPS GLWand, in simple terms excellent and simple.

Using GLWand and  MS Excell I have prepared a cost sheet with dashboards suiting for our requirement, only standard SAP and GLWand used for the prepartion of the entire cost sheet.

Below given is an highlight the management dashboard prepared highlighting all details relating to the material selected.

Figure 1.0

Figure 1.1

My second graphical dashboard provided details pertaining to sales, break even point etc.

Figure 1.2

Figure 1.3

I have created nearly 25 different graphical reports against each material, which provides with entire details relating to a particular material selected.Details like;

• Month wise production cost,
• Sales price,
• Variance,
• Variance / Ton,
• Over head consumptions,
• Raw material consumptions,
• Other expense,
• Electricity consumption,
• Administration expense.

By analysing the dashbaord management gets a clear understanding about the status of the particular material.

Apart from the graphical dashnoard I have developed nearly 40 reports relating to each material.

I will share with you how I have prepared the dashboard.

Previously every month I use to prepare report on the Opening, receipt / production, Consumption, closing, sales etc report seperately. So though since all these datas are interrelated why can we integrate them and get the final report.

Below attached is a snapshot of the main control page of my workbook.

Figure 2.0

I have 9 Master Data entry sheets where every month I have to key in the values manually.

Figure 3.0

Let me take you though each data entry page;

Report MD1: Material Consumption Report

All Finished and Semi Finished Good will be produced against a process order. In this report we have to fill in the quantity and Amount of Finished / Semi FInished good produced for the month (Using the corresponding Process Order) and the rawmaterials used for the production of the Finished / Semi FInished good.

Figure 4.0

The material produced should be the 101+102 (Semi Finished / Finished Material Receipt) quantity in all the other reports ex: MB5B, MB51. The Materials Consumed should be the 201+202 or 261+262 (Raw Material Consumed) quantity in all the other reports ex: MB5B, MB51.

This details can be extracted by executing transaction code KOB1 by providing the process order number.

The Material Produced will be updated in the Stock GL with document type "WE". The raw material issued for producing the finished good will be updated in the consumption GL with document type "WA."

So by inputting values in Report MD1 we have updated Finished / Semi FInished Good Stock and Raw Material Consumption GL.

Report MD2: Over Head Consumption Report

In this report we have to fill in the quantity and Amount of Finished / Semi FInished good produced for the month (Using the corresponding Process Order) and the Overgeads used for the production of the Finished / Semi FInished good.

This details can be extracted by executing transaction code KOB1 by providing the process order number.

Figure 5.0

The values entered in this sheet dose not have any relation with the postings in any of the GL accounts. Values from this sheet is used for production order variance calculation.

Report MD3: Material Receipt Report

All raw material receipt has to be filled in this sheet. For Semi Finished / Finished good material receipt (material produced) we have entered in Report MD1.

Figure 6.0

Raw Material Stock GL will be updated with the values entered in this sheet with document type "WE". Material receipt can be extracted from transaction codes "MB5B" with movement types 101 +102

Material Issued for production has been updated in the stock GL with document type "WA". So WE - WA = Closing Stock.

No we have calculated the Material Receipt, Material Consumption, Closing Stock and Opening Stock for the next month.

Report MD4: Standard Sales Report

Material Sales for each month has to be entered in the sheet.

Figure 7.0

The details entered in this sheet will be updated in COGS GL. Details of sales can be extracted using transaction code "MC+E".

Report MD5: 0 Quantity Report

While calculating the closing stock of material you have to consider if any entry has been made against the particular material with 0 quantity and with price.

Figure 8.0

While Cacluating the closing stock price 0 quantity amount is also considered.

Figure 9.0

Figure 10.0

For understanding more about COGM and COGS please go though the blog

http://scn.sap.com/community/erp/financials/blog/2012/03/20/post-implementation-challenges-part-1

For calculating the actual over head postings we have to extract the details from GL account either against cost center of material based on how you have done the psting. For us we have it against material as well against cost center.

In my excell I have created the required formats and layouts for the cost sheet I needed and used GLWand for pulling out the required data from SAP. So each time I dont have to log on to SAP, I need to only refresh the excell to be filled in with the latest data.

I have prepared nearly 40 reports pertaining to single material, providing more calrity to management on each and evry activity  perofmed on the materila from start till end. Every month after period close the graphical dash board will be submitted to management which gives them a clear understanding about each material.

SAP BI helps us in this as well as in hundreds of other funcationalites like this, since we were not clear on whether to invest more on the ERP side I thought of developing a dashboard like this.

I remember a dialogue from the movie "Pearl Harbour", after they attacked Pearl Harbour, the Japanese prime minister saying "' All what we have done is to awaken a sleeping giant'". If any company decides to implement SAP ERP and if they dont have the control then this will be the case, without ERP the company will work in the way it is working; once you decide to implement SAP ERP then make sure the full system is in your control. Prepare the cost sheet on a regular basis and ensure that all postings, updations in system are done correctly. Conduct SAP Audits regularly atleast thrise a year. Please check the blog on SAP Audit;

http://scn.sap.com/docs/DOC-29892

If you require help on cretaing the dash board and cost sheet please contact me.

Please go though my other blogs also;

http://scn.sap.com/people/ranjit.john/content#filterID=contentstatus%5Bpublished%5D~objecttype~objecttype%5Bblogpost%5D

Many times I have seen people who just entered in SAP have a kind of fear of CIN (Country India Version), even I was one of them. To overcome this fear we just need to put some logic and understand how system does calculations. Once you know how it works, you will start getting interest in it.

Here I am writing this blog just for those who just entered in SAP FI. I am not going to write whole configuration steps here, just an overview on the TAXINN procedure and how the system calculates excise duty and taxes.

Here we go.

Transaction Code: OBYZ

Calculation Procedurescontains necessary specifications for the calculation and base for calculating and posting of taxes on sales/purchases. Many tax calculation processes have already been defined in the standard SAP system for certain countries. For India its TAXINN and TAXINJ. TAXINN is a tax procedure which follows condition based record (not like percentage/formula base in TAXINJ).

Here first you need to check whether TAXINN procedure is available in system or not.

Condition Type is the condition calculation rule. It defines on which base amount tax/surcharge/discount is calculated and this base is defined in calculation procedure. You also need to check whether all required Condition Types are there in SAP system or else you need to add missing condition type in SAP system. There is a relation between condition type and access sequence. The access sequence is mentioned in condition type which calls the accesses maintained in that particular access sequence while maintaining condition record.

Access Sequence contains definition of which combinations of fields are to be taken into consideration to decide the Condition Records. Say for instance Plant/Vendor/Material, which means if a user is creating a purchase order for material “X” with vendor “A” in Plan “P” he can define the tax rate on this basis. Below the tabular explanation;

Here combination of Material, vendor and plant is one of the access maintained in access sequence and tax rate is condition record.

You can create the new accesses in Access  Sequence as per your requirement. Below are some examples of access sequence;

Assignment of Country to Calculation Procedure

Transaction Code: OBBG

Assignment of tax procedure TAXINN to country India

Specifying Excise Accounts per Excise Transaction

Here you specify which excise accounts (for excise duty and CENVAT) are to be posted to for the various transaction types. Enter all the accounts that are affected by each transaction type. This defines the credit and debit sides of accounts for different transaction types.

Transaction types

Accounts specification

Specifying G/L  Accounts per Excise Transaction

Transaction Code : NA

Path : Logistics – General > Tax on Goods Movements > India > Account Determination > Specify G/L Accounts per Excise Transaction

Here we maintain GL Accounts for Excise transactions for automatic account determination. This will define which GL account to be posted for specified duties for every transaction type. There may be sub transaction type in certain cases, for those also we need to maintain GL accounts.

Definition ofTAX Code

Transaction code: FTXP

TAX Code, on the basis of which the system calculates excise duty and tax. An end user just enter the tax code in a transaction and all duties and tax calculations are done by the system.While defining tax code for TAXINN you just need to define TAX Code, TAX Type and its Description. Please note do not mention tax percentage in its description as there will not be any access to end user to change the description (in case Govt. changes the tax rate in budget). In budget government may announce change in tax rate or duties, user need to change condition records only not the tax code. Maintenance of condition record is mentioned below in separate point.

Here there is no need to mention Tax Percentage Rates.

Assignment of Tax Code to Company Code

We need to assign the tax code to company code to make it effective in that particular company code.

Maintain Condition Records

Transaction Code: FV11

Here user need maintain the required condition record for particular condition type (for instance we will maintain condition record for Basic Excise Duty).

Select Access Sequence (You can select as per your requirement)

Maintain condition record.

Similarly you need maintain the all the Condition Records which are applicable to your business process. Hence the end user can change the condition records as and when it is required, FV11 is an end user transaction.

NoteTo calculate duties correctly you must have maintained Vendor, Customer, Material, Plant and like in transaction code J1ID to which you want to calculate excise duty.

This way the system calculates the duties and taxes in the system.

I had tried to cover an overview required for a Functional Consultant at beginner level. It might be incomplete. I request experts to contribute to the blog,  so that many SAP functional consultants can be benefited from this.

Regards,

Sandeep Kashigaonkar

Definition – groups of cost centers in a tree structure within a controlling area that represent specific areas of cost incurrence from a Controlling perspective.

A cost center hierarchy comprises all cost centers for a given period and therefore represents the whole enterprise. This hierarchy is known as the standard hierarchy.

Cost Center hierarchies are typically defined before creating cost centers.

Usually considered as configuration objects, high volume and complexity in nesting may call for automated load methods. Here’s one way of automating creation (load) of CCH into SAP.

Define Input/Load File Structure

Since CCH is defined at CO. Area level, a “header” line is used to create CCH per Co. Area. This way, the same process/files can be reused for loading standard and alternate hierarchies under same/different controlling areas.

Sample Data

LSMW:

• LSMW method: BAPI - BAPI_COSTCENTERGROUP_CREATE
• Business Object: BUS1112, Cost center group 
• Method: CREATE                    
• Message Type: COSTCENTERGROUP_CREATE    
• Basic Type: COSTCENTERGROUP_CREATE01

Structures/Fields to populate:

• E1COSTCENTERGROUP_CREATE (Header segment)
  • CONTROLLINGAREAIMP

  Note: Populate the above field with controlling area value only for header records  

• E1BPSETHIET (Interface structure for groups – Hierarchy table)
  • GROUPNAME
  • HIERLEVEL
  • VALCOUNT
  • DESCRIPT

Note: Populate the above fields only for hierarchy lines

Post-load review/reconciliation

• Execute transaction KSH3
• Input Top Node name & Display
• Validate if all nodes have been created correctly

  – KP (Blogging Irregular)

We are working on the development of HANA-Based Analytics, the VDM (Virtual Data Model), for ERP FIN. Now we are seeking SAT (Solution Acceptance Test) tester who has interest on HANA and can support us on the product testing.

As our SAT tester, you can earn a lot. The benefits that you can get from our SAT are:

1. to have better understanding of the hottest topic of SAP - HANA
2. to have better understanding of business application knowledge - FI/CO
3. to have better understanding of the latest UI technologies (HTML5, Crystal Report and etc.)

In total 7-8 testers are needed. If you are familiar with the FI/CO module or if you have experience of using the FI/CO R/3 report, do not miss this great chance to be the early adopter of our next generation product.

Last but not least, we’ll fully support your testing but please take notice that you will not get paid for your contribution. Please contact Elena(Elena.Wu@sap.com) for more details by September 21, 2012.

As is often the case at this time of the year,  I spent a week chained to a desk with a bunch of sales people and sales engineers. This situation could possibly only be worse if  they were all from marketing, or I was a customer! Well, you know what I mean…

At any rate, during the course of our meetings we revisited the concept of personas and roles in the organization and once again I spent time talking about who the real decision makers are in meetings with SAP customers, who the influencers might be and who are quite simply, tire kickers.  For those of you unfamiliar with what a tire kicker is, it is a person who goes to the used or new car lot periodically, and especially on weekends and sunny days and spends their time peering in through the windows of the parked cars, running their hands up and down the sleek lines of the vehicle, occasionally sitting in them, squinting under the hood or bonnet looking intelligent or simply, well, kicking the tires of the car to see if it collapses in a heap.

Technology tire kickers are important and perhaps I will write about them another day, but for now, I want to focus on how in the world of finance, and in particular finance with ERP. There are really two different kinds of finance people. There are those focused on the accounting side and those that focus on the management side. As a consultant it is important that you know the difference between the two, their expectations and needs.

An industry colleague that I was talking to a few weeks back, really summed it  up quite nicely to me. The financial accountants focus on the historical stuff and correctness of reporting and the financial managers are more focused on what all that historical stuff means for the future. In other words, both are critical functions and both have equal weight in the world of business. Failure to get the accounting right could mean problems with your regulatory compliance, problems with the statements of account and potentially fines or jail time for the CFO or persons responsible for reporting. This is one of the reasons why the financial accountants and finanicial accounting managers are a little bit paranoid about correctness, fidelity in the processes and precision of things like journal postings. Failure to close the books in a timely fashion for example will also see the auditors and stock markets fretting about whether the books are being cooked.

Financial managers are also interested in the correctness of the financial accounting because they rely on those numbers to hone their crystal ball skills. Financial managers will also identify ways to cut costs, identify anomalies in the trends and try to gather in information from sources other than the accountant’s relatively narrow view of the world.  The distinction between these two roles makes an important impact when you consider the kinds of education qualifications that an accountant vs. a financial manager need.

Many accountants, controllers, CFO’s and Finance executives are CPA’s (Certified Public Accountant) or CA’s (Chartered Accountant) ; that means that they have achieved some level of professional qualification that relates specifically to the practice of accounting. Though they may not have endured quite the same level of educational rigour as a doctor or surgeon, it will have taken them some time to achieve their Certified or Chartered status and it is usually a status that they will take with them to the end of their days. One of these certifications is important, depending on the country, to actually be able to sign off on the chart of accounts for a public enterprise. If you don’t have a CPA or CA in your organizational fold, then likely your auditors or accounting firm will have one who is designated to do it. Management acountants don’t have quite the same expectations associated with their role, though interestingly, many who come to the role with a Master in Business Administration (MBA) qualification are actually also qualified or previously qualified CPA’s or CA’s. Many come with another qualification too, that of the CMA, or Certified Management Accountant – supposedly much more focused on the whole corporate finance function.  The management accountant has as his  key objective - the creation or improvement of the financial health of the organization, either by generating cash, or by adding related resources to support productive cash flow. Financial management is about governance and maintenance of financial assets with less focus on the quantifying techniques and more focus on financial asset assessment.  Financial management is often referred to as the science of money management. (1).

In the end the qualifications themselves really are, as with all certifications and qualifications, just indicative of a person’s ability to learn; study and be tested in a particular discipline. None of them of course tell you about their actual abilities or their ability to envision a different way of doing things.  The role and title of the individual does of course help you in understanding what that person does and the qualifications that they hold indicate the kind of science that they may bring to their individual role. In financial management for example, there is a lot of planning, Controlling, and Decision-making; the American Institute of Certified Public Accountants (AICPA) conversely describes accounting functions as being largely focused on  “The art of recording, classifying, and summarizing in a significant manner, and in terms of money, transactions, and events, which are, in part at least, of financial character, and interpreting the results thereof.” (2)

From a usage of SAP perspective they similarly have different expectations, needs and wants with respect to what the system needs to deliver to them. Accordingly when talking to someone around in the finance department about system requirements. You need understand what drives their work activity every day.  Is it daily processing, is it period close or is it reporting. A lot of the solutions that are offered today as add-ons to SAP, whether they be dyed-in-the-wool SAP solutions or third party applications focus on the management side of finance and sales in particular, not the accounting side of finance and yet the accounting finance part of business activity feeds into sound and effectiveness financial management and decision making.

Dashboards and dash boarding solutions are great and carry an element of sizzle but in the end they can be a bit like presentation slide decks without the supporting dialog or speaker notes.  This means that when you’re positioning your requirements gathering questions you need to be clear what drives your audience to a more satisfactory decision making state. financial accountants are for the most part looking for speed, agility/adaptability, accuracy and consistency whereas the financial managers are assuming that you are helping the financial accountants and financial management accountants to get all that good data in in a timely fashion, but that you’ll find some elegant and creative ways to help them slice, dice and even splice data to help them make informed decisions.  Interestingly, I find that both groups love Microsoft Excel too; that should help you to understand that when you need to look at hard numbers either from a pure accounting or a financial management perspective there are very few tools better than Excel for presenting that information in an easy granular way.

A concluding thought; counting the livestock in the pens is great if you just want to make sure that they are all there – this may be all that your audience is asking you for; however if you have no idea which ones are cows, bulls, goats, pigs and sheep, you’ll have a tough time deciding whether you’re a dairy, wool or bacon farmer.

Additional Reading

(1) http://www.economywatch.com/finance/financial-management.html   

(2) https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Accountancy.html

(3) http://www.amazon.com/gp/product/0324422695  Financial Management: Theory & Practice (with Thomson ONE - Business School Edition 1-Year Printed Access Card)

I have been spending the last couple of days at the Hotel Russell in London at the Finance transformation and CFO conference run by the Shared Services Online Network (SSON) and have had the opportunity to meet with a couple of different business leaders who are involved in business transformation in the Finance field. Discussions with them have been interesting, not only because their businesses are household brands but also because their focus and attention on transformation is as varied and differentiated as their businesses.

These discussions got to me thinking about what Finance Transformation in particular, really means? Back in 2011 KPMG released a White Paper entitled Transforming Finance – Challenges and breakthrough solutions for CFOs. As pointed out there, gone are the days of finance simply being about collecting, paying and reporting. Finance has become more focused on faster more accurate and more insightful post processing analysis and reporting while ensuring risk and cost were managed appropriately during the entire financial data lifecycle.

In the world of SAP this achieved in a number of ways. The process starts with implementing the system and configuring it in a standardized way and sometimes doing some business process reengineering at the same time.  Applying appropriate data management strategies and data processing controls is part of this process as is the implementation of appropriate yet flexible technologies like SharePoint, browser based interfaces with backend systems and tight and robust integration with  desktop applications like Microsoft Excel.

In the idealized world of finance every interaction with the system of record is done through a single UI with a single consistent and reliable user experience. The reality though, is that these user experiences are not consistent and not always as reliable as they should be. The reason is primarily because of the fundamentally different requirements and work practices of different aspects of the finance and accounting function. Accounting is mostly focused on the historic record keeping and Finance is focused on the changes and potential outcomes of future activity. As a consequence, there is a requirement for much more granularity in the processing data in the accounting function and much more forecasting, what if analysis and aggregation in the finance function. Accounting is often also about the hard numbers and the end-to-end reconciliation whereas finance is about variances in outcomes based on dialing down or dialing up reported numbers.

3 areas of particular focus for the CFO described by KPMG were Trust, Simplify and Insight.

Focusing on the Simplify aspect of finance transformation would mean giving core consideration to accuracy & quality, standardization & reliability, efficiency, elimination of duplicates. As KPMG also point out, there are no ‘off the shelf’ transformation solutions and no universal roadmaps to success.  Success only comes as a result of having a vision and determination followed through with a methodical approach to identifying opportunities in technology, organizational change and business process optimization. This methodical approach need not necessarily be rapid or disruptive depending on the business urgency and the level of investment that is required. If there is an urgency  then it needs to be understood what the driver for the urgency is, and whether this is in fact something that requires a long term finance change or merely a temporary deviation in activity focus. Mergers and Acquisitions for example can bring urgency and process change but only be of a temporary nature.

Transformation that focuses purely on efficiency may ignore the other important facet of effectiveness, A classic example would be the delegation of back office processing to an offshore shared service center however the effectiveness of this approach may be undermined by poor data quality inadequate data governance and controlled processes or even unsuitable staffing or time zone offset issues.

Focusing on the target of improving overall effectiveness of the finance function often leads to reductions in complexity and cost reduction but these outcomes are heavily dependent on the design of the transformation objectives. With a core focus on creating additional value and driving efficiency, transformation initiatives are more likely to be successful.

Very often a FI consultant faces this question and there is no text-book answer to this. SAP ECC field for Vendor number (LIFNR) is 10 characters long and it could be both numeric and alpha-numeric depending on how we configure the number-range. But do we use all the 10 digits? What about future growth? What is correct length? Consultants almost quote standard practice or best practice and their own past project experience.

There are various factors that we need to consider before we settle on the length of Vendor number in SAP. And the life of a consultant becomes relatively easy if SAP ECC is not the source for Vendor Master.

What is the source system for Vendor Master?

• If this is not SAP ECC, then a SAP consultant can do little about the vendor number because the legacy precedent over-rules in almost all cases. Although we can create a new vendor number for every legacy vendor number in SAP, this will increase redundancy of data. Which number will we communicate to the vendor? Which number will the vendor use to send this invoices/credit memos into SAP? The best possible solution will most often be using legacy vendor numbers as External numbers in SAP.
• If SAP ECC is the source system for Vendor then the consultant has lot more flexibility. The consultant can choose internal numbering because it is numeric, improves SAP performance in terms of data fetching for processing and reporting.

What are the non-SAP systems that will be using this Vendor number?

• If there are other legacy systems that dependent on this vendor number then, the length chosen should be less than the maximum length the legacy systems can handle, assuming that the legacy system length cannot be increased, which is most often the case.
• Again if SAP is not the source and if we choose to assign internal numbers, then we need to think about converting the data back from SAP number to the legacy number.

What is the most productive vendor number length for the users when working in SAP?

• If an organization is implementing SAP, then it could be safely said that this organization has well laid-out processes that use vendor number in their non-SAP world. If so, the Accounts Payable users have been well-trained to use their legacy number length. Most often than not it is in the consultant’s best interest to stick with the same length even in SAP. This avoids keying errors, training overhead, unnecessary learning curve to get used to the new number length.
• In my experience, I have seen 7 digits/characters as the most commonly used length although there is no documented proof supporting this length and its efficiencies.

There are some pit-falls to note as well:

In my earlier post on How long should be a Vendor number in SAP?, I concluded saying that commonly the vendor number length is between 5 to 8 characters. The same parallel could be drawn for SAP Customer Number length as well.

Having said that, Plants/Sites in SAP also are assigned Customer/Vendor Numbers. These Plant/Site Customer/Vendor Numbers are used for MM/SD processes such as inter-company stock transfers, inter-company sales, movement of stock between Plants or Sites etc. These processes post financial postings which in-turn use Plant/Site Customer Vendor numbers similar to FI-AR or FI-AP postings. Given this feature in SAP, the question that comes up is “Should SAP Plant/Site Customer/Vendor Number be same as the Plant/Site Number?”.

The answer to this question is valuable because it dictates the amount of pre-work to be done in the legacy systems. This pre-work could be cleansing the legacy vendor master data and bringing on-board all the affected vendors with the upcoming changes, if any, and to pave the path for successful implementation of SAP processes.

I have seen that the Consulting community is split between two schools of thought:

• One opinion is that SAP Plant/Site Customer/Vendor number should be same as the Plant/Site number. This is the most supported and common school of thought. The basis for this opinion and the often stated reasons are:
• keeping the numbers same will yield in better process efficiencies in terms of

• end-user experience
• ease of reporting/analytics
• harmonization of Master Data

This opinion is also supported by SAP. But one main drawback of this opinion is that it does not explain why should we restrict Plant/Site vendor number to be same as Plant/Site number knowing that SAP has no systemic limitation.

• Other opinion is that SAP Plant/Site Customer/Vendor number could be different from the Plant/Site number. This opinion hinges on the following facts:

• standard SAP does allow for these numbers to be different
• no known systemic limitations

It would be interesting to see if there were any specific examples (both technical and functional) where each of these options worked better or had issues.

hi.....friends,

i have one doubt in Asset accounting, We have one Asset life of period 10years. After that time period also we are using the same asset. so, how will process of that asset after 10th year.

shall we consider new asset ? can any one suggest ?

Report Painter is a very flexible reporting tool which can help the Functional Consultants to develop various reports without the help of ABAP. The advantages of the Report Painter are that defining report is very easy and flexible and you have control over the layout. The Rows and Columns are display in the definition the way they are in the report itself.

Common reports that most of the clients require are:

• Statement of Financial Positions
• Income Statements
• Cash Flow Statements
• Segmented Financial Statements
• Aging Analysis Reports
• Ratio Analysis

This is my first blog on SCN and I have attempted to share my knowledge in order to make the users familiar with this reporting tool and contribute a little to the SAP Community. This blog is restricted to the a simple designing of a “Vendor Aging Analysis Report”.

Step 1 – Create Form (FKI4)

• Enter the Form Type as Line Item Analysis
• Use your own naming convention to give a description to the form
• The structure should be Two Axes (Matrix)

In the next screen (below) you will see a form of unstructured row and columns.

Initially, it is recommended to set General Data Selection to the form. Go to Edit-> Gen. data selection-> Gen. data selection.

On the next screen, enter the Company Code in the selected characteristics

On the next screen, double click the lead column and change the description to Vendor Aging Analysis

The next step is to enter the characteristics in the rows. Double click Row 1 and select characteristics, i.e. the vendor

On the next screen enter the following in the selected characteristics:

• Account Type – K
• Vendor – From “0” to “9999999”

The next step is to add the number of days in the columns for aging. Assuming the requirement from the client is to age the vendors based on the following days:

• 30 Days
• 60 Days
• 90 Days
• 120 Days
• 150 Days
• 150+ Days
• Total

In order to achieve this, double click column 1 and select “Key Figures with Characteristics”

On the next screen enter the following in the selected characteristics:

• Due date analysis – 1 (1 means analysis of line items due. You can even select it from F4)
• Days for net due dat
  • From “0” to “30” (For aging of 30 days)
  • From “31” to “60” (For aging of 60 days)
  • From “61” to “90” (For aging of 90 days)
  • From “91” to “120” (For aging of 120 days)
  • From “121” to “150” (For aging of 150 days)
  • From “151” to “99999” (For aging of 150+ days)

Enter the heading of the Columns. The form (below) will eventually look like this:

In order to add the totals in the last column, double click the dots and select formula

On the next screen, enter the formula in the Formula line by using the formula components as shown in the next screen shot

You will be prompted to enter the description of this column. Enter “Totals” in the text box.

Always save your form after completion of every step.

That was the last step for creating a form. Eventually, the form will look like this as shown below.

Step 2 – Create Report (FKI1)

Upon successfully creating the form, the next step is to prepare the report for execution. Here you are required to select the report type as “Line Item Analysis”.

Enter the form as “APAGING”. This is the form that is assigned with the report. Use the same naming convention of the report as the one used for designing the form. We will enter the name as “APAGING” and “Vendor Aging” in the Long text.

On the next screen, the characteristic for currency will be appearing. You may enter the currency used for your reporting. I am using PKR for my purpose. Also add Vendor in the sel. Characteristics .

In the next tab for “Output Type”, select the output type as Classic Drill Down and Basic List: D-Down and save the report.

Step 3 – Report Execution (FKI0)

Go to the above T-Code and select the report APAGING in the line items tab and execute this report.

You can even asks the ABAP consultant to create a T-Code at a later stage for this report instead of going through FKI0 and add that T-Code to your Favorites.

In the next screen, select the open items key date and execute the report. It will appear something like the one below:

You can compare the APAGING report with the current standard report in FBL1N in order to get confidence that the report developed is accurate.

For testing purpose, I have selected Vendor No. 600015 in FBL1N Report.

Upon comparison of both the report, we can see that the report created by report painter is providing accurate data.

Conclusion

I wish you all Best of Luck in designing the above report for your clients/ companies and I hope that I have shared my knowledge to the extent that the users get familiar with the Report Painter tool and are able to cater multiple reporting requirements.

I will also try to share many further reports very soon!

Cheers

Anss Shahid Essani (ACCA)

Certified SAP Consultant

Earlier this week, I had the opportunity to talk with Birgit Starmanns from SAP, who is presenting at the upcomingFinancials 2013 event in Las Vegas, March 19-22.

One of the sessions Birgit is presenting is titled"The mobile revolution is here: How SAP mobile applications for finance can help your organization thrive".

With all the new mobile devices and functionality out there, and organizations looking to mobilize critical business processes for both their customers and employees, I expect this will be a packed session!

I wanted to talk to Birgit before the event just to give customers a quick preview of what they can expect to learn during her session. And to get some of her insights into the biggest trends going on with regards to companies mobilizing their finance operations. She had some great insights, and provided a quick look into her favorite mobile apps!

Make sure to listen in here: bit.ly/VBmqGH

Looking forward to attending her session in Las Vegas.

Hope to see you there!

-Allison

You have activated extended withholding tax in your company code and want to reset the clearing in a document in which you have a withholding tax.

Kindly consider that it is not possible to reset a clearing document if within this clearing a withholding tax line item is posted.

For other documents (which are not connected to withholding taxes) you should still be able to use "reset only" or "reset and reverse" on the popup appearing, as you have already checked.

Please understand that the clearing information of the reversal document must not be reset for documents with withholding tax, in order to keep the accumulation tables (WTAK/WTAD) remains correct.

In case, both the withholding tax amount and the withholding tax base amount is zero for all items, the resetting of the reversal is allowed.

This is also mentioned in SAP Note 431095 and has been corrected also for new releases in Note 1062551. Hence, the error  'Use the transaction for resetting check payments' Error Code 'FS 642' rightly issued.

You may be able to reset the document if tables are manipulated, but this is not recommended.

As a workaround, posting a new document could be a possible solution.

Such behavior is SAP standard and there is no other way to avoid it as per the standard.

In case, you want to use FBRA to manually reset the clearing document, it can be done, as a result of which both invoice and payment document will be treated as open items. It is a fact that, reset alone reverses the clearing process. For example, resetting a payment document will leave the invoice as an open item, but would not reverse the payment document.

With resetting, the amount paid is not lost as the document is still active and open. Later the payment document can be cleared with other invoice. Since FBRA is a manual transaction, it is important that user should be aware of the steps they are performing. There is no restriction with reference to resetting, as some of you can use this transaction to reset and then clear the payment document with other invoice.

On the other hand, you may require to reverse the payment and void the check,  then the following steps need to be reviewed:

After resetting through FBRA, you generally manually void the check in FCH8. Instead you can directly use FCH8 to complete the process. Whereas, in FBRA, if you try to reset and reverse the document, then system doesn't allow to do so by giving a message 'Use the transaction for resetting check payments' Message Code being ‘FS 642’.