The features and problems arising at SAP implementation of ERP Roll Out of projects in branches of the western companies in Russia

Roll Out the project in Russia implies a task of the organization in the system of a possibility of accounting by rules RAS, without breaking at the same time basic processes. The complexity of the project depends not only on quantity and types of differences between corporate and local accounting, but also on flexibility of methodologists of the client and their readiness to find golden mean between desire to follow a letter of the legislation and to optimize costs for automation of these requirements in a system. First of all, it is reasonable to define all available differences, to find methodological approaches to their elimination and to try to pull together, as far as possible, accounting.

The main problems which can arise at combination of the Russian and corporate accounting in one system:

• Differences in the moment of reflection of economic transactions;
• Differences in rules of reflection of economic transactions;
• Corporate and local charts of accounts;
• Shift of financial year;
• Different currency of the reporting.

For implementation of parallel accounting the following global SAP ERP tools can be used:

• Alternative chart of accounts (functionality of FI-GL);
• Special registers (functionality of FI-SL);
• Additional registers GGK (functionality of FI-GL, New (Flexible) ledger);
• Different areas of assessment of fixed assets (functionality of FI-AA);
• Different methods and methods of value assessment of stocks (including ML (Material Ledger) is the Register of materials);
• Functionality of consolidation.

In this article we consider the main problems arising on Roll-out projects and also the methodological and technical approaches according to their solution used by us in practice. The implementation option using the alternative chart of accounts is considered.

Chart of accounts

The chart of accounts of RAS is configured as the alternative chart of accounts to corporate. It is necessary to work carefully mapping between accounts of the operating plan of accounts (GAAP) and the alternative chart of accounts of RAS that further it is correct to perform necessary tunings. By preparation mapping-and, it is important that the account of the main chart of accounts was used in those and only in those transactions for which in RAS the appropriated alternative account is used. Besides, the account should correspond on technical characteristics: the control account, management of open positions, tax category, etc., Russian Add-on required for the corresponding alternative account in functionality.

The operating plan of accounts breaks into three parts, each of which services:

• only local postings of GAAP;
• generic postings of GAAP and RAS;
• only postings of RAS.

For a possibility of joint conducting parallel accounting technical accounts both in corporate and in the alternative chart of accounts which are irrelevant for the corresponding reporting are created.

It must be kept in mind the following features of maintaining alternative accounts:

• the alternative chart of accounts should be configured as the chart of accounts of the country in global parameters of balance sheet unit.
• alternative accounts should have the name in the RU language.
• all alternative accounts used at setup of master these key accounts should contain in the alternative chart of accounts.

Non-compliance with these rules leads to incorrect work of the standard reporting of Russian Add-on.

Shift of taxable year rather calendar

One of important problems on Roll Out projects, is use in corporate accounting of this company of financial year which, will shift rather calendar. The shifted financial year not only complicates work of users when forming annual accounts for the purposes of RAS, but also requires additional adaptation of standard functionality of Russian Add-On.

In the course of implementation of functionality of Russian Add-On on several projects, in the companies working with shifted financial year, it was succeeded to reveal and correct errors of program logic. Mainly it concerns solutions in the field of accounting of the VAT:

• separate accounting of the VAT, including for export transactions;
• program for transfer of the VAT for secondary events.

As a result of joint work with SAP AG several fresh notes were issued:

• 1800993 14.12.2012 (J_3rfum26: Shifted year for separate VAT accounting)
• 1793287 11.12.2012 (J_3rfum26: Document could not be posted due to splitting)
• 1809771 13.02.2013 (J_3rfum26: Wrong debit/credit sign posting from ALV)

Accounting of the VAT

Accounting of the VAT for Roll Out projects is implemented in SAP ERP based on the standard functionality delivered within the Russian localization. An important factor of technical capability of accounting in a system, according to last modifications and requirements of RAS, is installation of the last service pack and notes. All reporting is under construction based on data of the leading register using the Russian Add-on tools.

Tax scheme and VAT codes

The tax scheme for each country, for Russia - TAXRU is provided in ERP. Irrespective of the fact which the tax scheme will be used for Russia (there are projects on which use of the uniform tax scheme is regulated and it is impossible to use TAXRU), it should be tuned up – are added conditions of ZUD and ZUK.

It is also necessary to consider the following features of SAP ERP regarding setup of the tax codes. When using one corporate chart of accounts for all countries, setup of tax accounts for VAT codes does not depend neither on BE, nor on the tax scheme. As a result, change of tax accounts for the country influences global setup of this code, i.e. can jam setup of accounts for the same VAT codes for other branches (BE). Therefore if change of tax accounts is required, it is necessary to be convinced that changeable codes are used only for our balance sheet unit.

One more specifics used in Russia are the target VAT codes which are seldom used in the western companies. Therefore except that this feature requires setup of an additional system of codes, the western colleagues should explain a technique of their application in addition. Target VAT codes are used for the following processes:

• Transfer of the entering VAT to offset (transfer with 19 * on 68 * the account);
• Transfer of the entering VAT to offset taking into account secondary events: tax agent, capital construction, etc.;
• The VAT on goods in way (the target code is used only for the purposes of the correct functioning of the standard development on accounting of the VAT for goods in way which is a part of Russian Add-on);
• Technical target VAT codes are necessary for standard Russian functionality on accounting of the export VAT.
• Accounts of group of companies for accounting of the VAT
• It must be kept in mind the following features of setup of accounts of the Ledger for accounting of the VAT on the Russian accounting.
• For convenience of the analysis of the entering VAT several 19th separate accounts for the purposes of RAS usually are created.
• For ensuring correct work of the Russian localization of Russian Add-On of the account of the postponed entering VAT (19, 76) should be obligatory with "management of open positions";
• 68 * the account used for payment of the VAT should be control.

These technical features need to be considered when forming mapping-and accounts of the VAT special attention should be paid them to technical characteristics.

The VAT in the advance payments issued

Often this process needs to be configured completely as the foreign companies usually do not use process of Down payments payable. It is required to perform a number of the additional tunings which are not provided usually by a configuration of global processes.

Settings pursue the following aims:

• VAT amount output in Purpose of payment in the payment order, for unloading in Client-Bank and for a printed form;
• Compensation of the VAT if there are such requirements from the client.

If compensation of the VAT is not required, then it is enough to configure for each rate by one technical VAT code with reference to the technical account which treats in TAP and is inherited when entering advance payment. It allows to calculate VAT amount when forming the advance payment document which is used when forming the Purpose of payment field in the payment order. (In addition transaction VVA setup - Automatic postings is required.

If necessary to compensate the VAT on outgoing advance payments – it is necessary for each VAT rate to create a chain of two VAT codes, first of which creates wiring on the 76th accounts, and the second (target), using the program of transfer, creates wiring of compensation into the 68th account. Then, after alignment of advance payment with the invoice the return wiring on the 76th accounts is automatically created and, as a result, wiring of compensation on advance payment is compensated.

It is necessary to remember that in the advance payments it is necessary to have the advance invoice for compensation of the VAT, signed by the receiver in whom the exact amount of the advance received by it is specified.

The VAT in the advance payments received

Charge of the VAT to payment on the received advance payments also is the Russian specifics and is performed based on carrying out the entering advance payments. All payments are registered on settlement accounts with debtors when processing the bank statement. At post-processing of the bank statement the responsible specifies the corresponding VAT code.

For implementation of process of Down payments receivable it is required to perform a number of the additional tunings which are not provided usually by a configuration of global processes:

• The outgoing tax codes (10%, 18%) configured on separate 68 * the account for which management of open positions, tax category is activated are created ">".
• Wiring forms in correspondence with the 76th account which, should be without management of OP, tax category
• The transaction MVA - Automatic postings is configured with reference to the 76th account.
• Codes of OGK are configured.

Accounting of the VAT on goods in way

The Russian specifics of accounting of the VAT on goods with the property right postponed by transition often require change of a corporate order of reflection of transactions in a system. At goods issue, implemented without transition of the property right the possibility of time diversity of process of charge of the VAT to payment and invoicings is necessary.

For automation of this process the standard functionality of Russian Add-On (transaction of J3RFVATSD) is successfully used.

This development allows:

• add the VAT to payment at the time of shipment of goods without creation of the invoice;
• execute invoicing and create postings on debt and implementation at the time of property right transition, according to terms of the contract;
• browse a chain of operations on goods in way with a possibility of viewing all documents and also reverse any document from a chain.

In addition, correct work of process, requires setup of a separate type of the invoice of SD which allows to carry out invoicing of the order without formation of financial postings.

Separate accounting of the VAT and export

Separate accounting of the VAT is implemented in SAP ERP in EhP5 service pack. The standard solution on separate accounting of the VAT gives following features:

• Maintaining the coefficients setting a proportion of distribution of the entering VAT between leviable, free transactions and assessed at the rate of 0% (for example, export);
• Separation of the entering invoices into three parts: leviable, free and export transactions, according to coefficients;
• Linking of the entering invoices with invoices on export implementation.
• Transfer to compensation of a share of the entering tax connected with normal implementation;
• Transfer to compensation of a share of the entering tax connected with export implementation taking into account existence of confirmation (a secondary event).

At implementation of this solution in practice there are following problems:

• At the time of purchase of material/goods/service at suppliers it is usually unknown where it will go: for export, for domestic sale or on tax-free transaction. Therefore it is impossible at an invoice entry stage on purchase to put down the correct VAT code defining reference of these goods to separate accounting.
• Besides, there is a question of a method of calculation of coefficients of distribution in case sales of goods for export drags on for several periods and a part of purchase "hangs up" in a warehouse for indefinite time.
• The standard solution assumes use in the system of a chain of implementation the Contract-> the Order-> Delivery-> a SCD-> Sales the Invoice-> the Finance Document of the Invoice-> Payment. In case of lack of one of objects of a chain it is necessary to finish standard functionality of input of confirmations on export implementation.
• The procedure of transfer of a tax and alignment of positions of accounts of the entering VAT as, splitting to one invoice is resulted by several documents of transfer becomes complicated, besides transfer of a leviable and free part of a tax for one invoice can be executed during the different periods therefore there is a partial alignment. Therefore the program of transfer of tax J_3RFUM26 does not align the postponed positions. Therefore at implementation of separate accounting of the VAT the procedure of automatic alignment of positions of the entering VAT shall be worked out.
• Lack of functionality by calculation of coefficients for separate accounting. At the moment the matter is handled by SAP, as a result, the solution on FI-SL is proposed.
• Impossibility of manual correction of results of accomplishment of processes of separation of the entering invoices and their linking with invoices on implementation;
• Always there is a question of a method and opportunities of distribution of the amount of the entering VAT relating on free implementation for the corresponding accounts and accounting items for reference on cost value or other transactions. Or in a system the program of distribution is developed, or distribution is made out of a system and results are loaded in the form of postings.
• The complexity of process of adjustment and reversal of documents, especially previous periods increases.

When using of the shifted financial year on export it is necessary to apply the following notes to accounting of the VAT:

• 1800993 14.12.2012 (J_3rfum26: Shifted year for separate VAT accounting)
• 1793287 11.12.2012 (J_3rfum26: Document could not be posted due to splitting)
• 1809771 13.02.2013 (J_3rfum26: Wrong debit/credit sign posting from ALV)

Payments in currency

Setup of currencies

By default for a principal currency of BE it is set a course type of M and this setup it is impossible to change. But the problem is that the foreign companies use the currency (USD, EUR) as base currency for the M course type while for RAS it should be rubles.

There are following settings helping to solve this problem.

• The alternative course type, for example, of ZRU with base currency – RUB is created. Respectively, Central Bank rate is taught not for the M course type, and for ZRU.
• In transaction of "Determination of conversion factors for currencies" (Currency) for each couple of recalculation from foreign currency in rubles the Alternative course type of ZRU is specified.

As a result at any transaction of recalculation in rubles the course type of ZRU allowing to make recalculation at the rate of the Central Bank while other BE of the company will save recalculation by the rules will be used.

Reflection of the amount of revaluation of open positions in Reconciliation statements

The standard reports intended for reflection of the overpriced amounts by settlings with Debtors and Creditors, entering into Russian Addon are constructed based on tables of the Flexible Ledger. If in its activation in a system it is not provided, then these tables are not filled out, respectively reports form without results of revaluation.

Programs:

• J_3RF_ASK – Vendors reconciliation statement
• J_3RF_ASD – Customers reconciliation statement
• J_3RFPCR - Payments of vendors (RU)
• J_3RFPDE - Payments of customers (RU)
• J_3RFREVHISTFC - The history of valuation

As SAP supports in new developments only the solutions based by GGK now, if desired to solve this problem it is necessary to revise these programs independently.

Exchange differences

By rules RAS it is necessary to conduct separately an expense and income on exchange differences on separate accounts. As in the western accounting of similar separation it is not required, most often, for reflection of results of calculation of exchange differences one account without separation into income and expenses is configured.

Setup of currency difference accounts global also does not depend on Balance sheet unit. If the corporate policy of the company allows to expand the global chart of accounts, having added separate accounts for reflection of a dokhodaraskhod from exchange differences, then the problem is solved only by accomplishment of necessary settings. In this case at setup of the corporate reporting of the income and expenditure account are specified together in one line, and for the purpose of RAS – in different lines.

But a problem that most often the corporate policy of the company does not allow to separate accounts. In this case technical accounts into which, according to the results of closing of the period, adjustment postings taking into account separation into income and an expense are manually executed are created. Further these accounts are used at setup of the reporting under RAS.

Accounting of calculation results of exchange differences is also specific in terms of formation of Income tax. Using the standard solution of the Russian Labour Party on Income tax implemented on functionality of FI-SL or FI-GL it is possible to separate income and an expense at the time of broadcast of data from FI in the tax register.

Calculations in UE

Conducting calculations in UE is specifics of the Russian accounting. One of implementation methods of this process – creation of separate currency types, for example RUU (for USD), RUE (EUR). The rate for these currency types can automatically be calculated at the time of loading of rates of principal currencies as some derivative of real currencies (for example, USD+EUR)2).

The document of debt forms in UE, at the same time the payment currency in the document is specified to RUB. The program of payments when forming payment heads in rubles for a payment date. If the rate of UE forms by special rules on the basis of the agreement, then the payment is entered rubles, directly with indication of the amount at the necessary rate.

Alignment of payment and debt is made in UE in transaction of FB05 allowing to set a rate.

The complexity arises when forming payments on the basis of the logistic invoice created in transaction of MIRO as it is impossible to specify payment currency which should be inherited in payment in this transaction. In this case it is necessary to change the created finance document of the invoice in FB02.

To select separately the results on exchange differences arising from revaluation of open positions in UE (for the purpose of accounting under RAS and Income tax), in setup of accounts of revaluation for UE separate income accounts and an expense treat.

Forms of accounting records

Setup of forms of accounting records is made based on the alternative chart of accounts that users at report generation saw results on accounts of RAS. When forming accounting records it is necessary to consider two factors:

• For an output of alternative accounts in the reporting it is necessary to activate the option "Alternative Account" on the selection screen;
• If in the company the shifted financial year is used, then for reporting for calendar year the option "Alternative Period" is used.

These options are available in all standard transactions to formation of the balance sheet reporting: F.01, J_3RFBS_ALL, J_3RFFV4.

Note: For the report of J_3RFFV4 (Form-4) there is a specific logic of filling of the screen of the choice in case of use of the shifted financial year. If necessary to obtain data for calendar years, it is specified quality of financial year, and the indicator the Alternative period does not treat.

Fixed asset accounting

For the replicated western systems the fixed asset accounting and depreciation which is conducted on 01 main areas of assessment is accounting by corporate rules.

For accounting by local rules the certain area of assessment without postings and also the additional area of assessment reflecting the difference arising between two areas is usually created. On this additional area of differences postings at the end of the period on accounts, technical for corporate accounting, usually form. In this case for formation of balance sheet forms under RAS it is necessary to use the amounts of the corresponding accounts on 01 areas of assessment and additional area of differences.

In case of use of the shifted financial year there are following problems:

• The spent term in cards form not by rules RAS (according to calendar year), and on the shifted financial year as switching of year is made at the time of change of year;
• Stock reports OS function within a year. It is possible to browse balance for the end of month in a year only if year is not closed. In case of the shifted year it is possible to appear in a situation when a part of calendar year belongs to already closed period.

The similar situation can arise in case of adjustment of any parameters of calculation of depreciation for an object if such changes are made when financial year already ended, and calendar year not yet. In this case adjustment of parameters will influence only calculation of depreciation of already new financial year and if these changes had to cause correction of the depreciation relating to months of the previous financial year, the amounts of adjustments will not be calculated automatically any more, and they will need to be entered manually.

Cost accounting

The requirement of RAS is obtaining actual cost of the made and sold products. Calculation of tax product cost or goods which rules of calculation can differ from accounting is also necessary for tax accounting.

The majority of the western projects use the register of materials ML (Material Ledger) for determination of cost value of goods and products. The problem is that practically in all cases of the rule of its formation differ from the rules determined by our legislation.

Depending on types of setup of the register there can be following problems. Most often account of goods is kept at the standard price and revaluation (change of this price of actual) is made only once a year. Deviations between the standard and actual price collect on separate accounts. Thus, the actual cost by materials in a system is not conducted. Besides, rules of formation of deviations according to corporate standards can differ from requirements of RAS and tax accounting.

Calculation of tax cost value is a part of the Russian Labour Party on income tax, entering into Russian Add-on and implemented based on FI-SL or new group of companies. But even when using the Russian Labour Party settlement process of cost value requires additional tuning of "data" and "distributions" of the amounts of deviations, because of differences in their structure for the purposes of corporate and tax accounting.

For obtaining the actual accounting cost it is possible to use several approaches, and all of them are based on starting additional technical accounts which are not relevant for corporate accounting, and are used only for RAS.

The amount of deviations during the period collects on certain accounts by materials. At the end of the period it is necessary to carry out calculation and distribution of these deviations to the corresponding flows – goods or products in a warehouse, implementation, defects, etc.

If rules of calculation of actual cost using the register of materials do not provide accomplishment of rules RAS, depending on requirements and opportunities of the project the following approaches are used:

• the separate program which analyzes movements of goods is developed, collects all costs of the period, makes calculation and creates postings on technical accounts;
• calculation and distribution is made out of a system what at the end of the period unloading from the system of data on formation of deviations and postings on movements of materials is made for. In Excel calculation of actual cost of each material on the basis of a remaining balance for the beginning of month, movements on receipt (purchase or production) and to implementation is made. Then loading through functionality of batch input from Excel file in the system of adjustment postings on write-off of cost of sales into technical accounts is made. It is necessary to store the cost of stock remainders by goods out of a system (in Excel) to use for calculations of the next month.

Postings on technical accounts form without section on materials, and the price of the actual stock remainders does not change (remains standard) therefore the part of deviations falling on a stock remainder participates in distribution of the next month.

In both cases development of methodology, setup and selection of reports for unloading, setup of batch input and loading is required.

Differences in time of reflection of transactions (Accruals)

On Roll Out projects there are difficulties also in connection with a difference in the period of recognition of expenses between corporate accounting and RAS. Recognition of an expense on corporate accounting happens in the period of emergence of an expense, and under RAS – on receipt date of primary documents. As in the majority of the western configurations tough closing of the period in the first days of the next month is regulated, reflection of these discrepancies assumes carrying out additional adjustment postings on the technical accounts relevant only for the purposes of accounting under RAS.

This process causes not only additional Accruals and difference in an expense amount when forming cost value, but also complicates accounting of the VAT as leads to increase in volume of the transactions which are included in Additional sheets of the Purchase ledger. For correct formation of Additional sheets, the documents of previous periods which arrived in current are entered in a current period by the following rules: posting date belongs to a current period, document date - is equal to the date specified in printed form. In this case the standard functionality of the Purchase ledger creates Additional sheets automatically.

Reduction of volume of differences can be reached by the tough regulations defining an order of adoption of documents to accounting, for example, it is possible to make management decision - to include in expenses of a current period only the documents which arrived up to 2-3 numbers of the next month. Such restrictions can be accepted regarding rules of inclusion of expenses in actual cost of month.

Completion of the Purchase ledger is necessary for providing strict requirements on reflection in the Purchase ledger of all documents of a current period which arrived to the 20th day of the next month.

Logistics

Output logistic forms

The problems arising when forming output printed forms of the Invoice, Bidding-12, etc.:

• each client has specific requirements of filling of fields of documents;
• often there is a need to create output documents in several currencies and in several languages;
• difference of rules of filling of fields the master of data in the existing configuration from the data accepted for structure formation and Russian Add-on put in functionality;
• sometimes creation of business process of the company requires to make printing of the output document not on that transaction to which this printing is provided in the standard.

The logic of rules of filling of fields in printed forms can be adapted to the structure existing in a corporate system using standard BADI, but there can be a need of change of logic of the program that requires separate development.

Accounting on a SCD

The standard solution on accounting of a SCD assumes write-off of goods by a SCD on FIFO within the Plant, but without binding to batches. The situation when at a holiday of a batch not that GTE on which this batch arrived is put down can result. Completion of the standard solution is necessary for solution.

For introduction of a SCD to a system, using transaction of J3RFGTDUSAGE there are three options for an institution SCD:

• to order;
• on the document of material;
• on an invoice.

It must be kept in mind what is included in the Purchase ledger of a SCD only in case of an institution to order.

Closing of the period

Closing of the period becomes complicated not only the fact that in the western accounting do not use the closing postings on monthly results, for example: Dt90 Kt20 (44), Dt84 Kt90, etc. but also the fact that the shift of financial year rather calendar is possible. For formation of report forms and formation of the closing postings by rules RAS technical accounts which are not used in corporate accounting, but, in total with the used accounts are created, create the correct picture of closing for the Russian accounting.

If there is no shift of financial year, then technical accounts are created as accounts of profits losses which have one account of result (also technical) corresponding to the 84th account. As a result at the end of every period the closing postings which are not affecting corporate accounting are manually executed. In the end of the year technical accounts are automatically closed into the technical account of result and as postings were made only in this block of accounts, all results as a result are automatically nullified.

In case in the company the shifted financial year is used, transfer of balance into the account of result happens earlier, than it is necessary for RAS (for example, at the end of September at shift on the last quarter). To avoid it technical accounts are created by the accounts of existence corresponding the 90th, 44th, 91st and 84th for preserving of the saved-up turnovers. Operations with these accounts join in the reporting under RAS, but in this case, at the end of the calendar year, it is necessary to make the reversing postings on these accounts.