dynamics ax greek localization and best practices … ax greek localization and best practices...

Λεωφ. Κηφισίας 151, 151 26 Μαρούσι, Τηλ.: 210 8767400, Fax : 210 6147955 www.dis.com.gr

- 1 -

DIS – Dynamic Integrated Solutions

Dynamics AX Greek localization and best practices requirements

An overview

July 2007


- 2 -

CCOONNTTEENNTTSS

1 PROBLEM STATEMENT / PROJECT SCOPE. ............................................................................. 3

2 INFO SOURCES & REFERENCES. .................................................................................................. 4

3 DEVELOPMENT AND RUNTIME ENVIRONMENT .................................................................... 5

4 REQUIREMENTS OVERVIEW ........................................................................................................ 6

4.1 GENERAL ACCOUNTING REQUIREMENTS. ........................................................................................ 6 4.1.1 Chart of accounts ....................................................................................................................... 6 4.1.2 Accounting periods .................................................................................................................... 6 4.1.3 Tax office / tax registration number .......................................................................................... 6 4.1.4 Transactions .............................................................................................................................. 7 4.1.5 Cost center and dimensions allocations .................................................................................... 7 4.1.6 The “branch” entity ................................................................................................................... 8

4.2 SALES AND PURCHASE DOCUMENT HANDLING ................................................................................ 8 4.3 ANALYTICAL LEDGER ACCOUNTING (SIMILAR TO AX’S COST ACCOUNTING) ................................... 9 4.4 INVENTORY COSTING AND PRODUCTION COSTING REQUIREMENTS .................................................. 9 4.5 IMPORT COSTING (TOTAL LANDED COST). ..................................................................................... 10 4.6 POST DATED CHEQUES AND PROMISSORY NOTES (DRAFTS) ........................................................... 10 4.7 EXPORT FILES AND DATA .............................................................................................................. 11 4.8 REPORTING ................................................................................................................................... 11


- 3 -

1 Problem statement / project scope. For a software application to enjoy a smooth and successful introduction into a new market, it has to comply with local regulatory issues, but also with local best practices considered to be of the “can’t do without” kind. The latter may not always be required legal issues, but best practices related to legal issues that have extensively been developed by local competitive software. The problem to solve is to develop within Microsoft Dynamics AX, version 4.0 onwards, all the functionality needed to meet local authorities’ requirements and the best practices functionality usually required by local accounting professionals and controllers. It has to be stressed, that the way the functionality will be developed, has to have the philosophy and even terminology established locally. It is thought that the localization will be developed in the form of vertical solutions. The scope of the project extends throughout the product’s modules and functionality with the exception of payroll. Payroll will most probably be an external product, after concluding a partnership with a local vendor, to be integrated with Dynamics AX. Out of the product’s modules, functionality relative to production and production costing will be developed at a later stage. As timetables now stand, financial and commercial related modules will be localized. Since the localization is not developed internally by Microsoft, it will have to be developed within the BUS layer.


- 4 -

2 Info sources & references. The basic information source that contains most legal requirements is contained within law 186 (known as KBS after Books & tax documents legal Code), which is continually updated whenever changes or adjustments are made by the authorities.


- 5 -

3 Development and runtime environment The localization modules and add-ons will be developed and integrated within Dynamics AX version 4.0. It seems that the most suitable layer is BUS, since it is closer to the inner SYS layer. The development should be done with the architecture to ensure easy version upgrades. This means the version upgrades of the core product should easily be extended with the localization code, excluding of course new localization development required.


- 6 -

4 Requirements overview In the following paragraphs an overview of the legal requirements is presented. The information presented serves the purpose to familiarize a person with the philosophy behind it. The documentation provided is not sufficient to proceed to design From a general point of view, one could think the Greek accounting standards as quite contemporary and quite close in principle to International Accounting Standards (IAS). However local tax authorities have imposed a number of acts, laws, etc, aiming at tighter and easier controlling procedures, mainly concerning tax. So what Greek localization is all about is implementing these tax authorities’ requirements.

4.1 General accounting requirements.

4.1.1 Chart of accounts Accounts in the Greek accounting system are hierarchical. So there are 1

st level

accounts, 2nd

level accounts, etc. Total levels may range depending on the type of the account, but usually there can be a total of 4 – 6 levels. Upper levels are simply accounts of type “total” in AX that contain lower levels down to a lowest level. They cannot accept transactions. Only lowest level accounts can accept transactions. The coding of the accounts is fixed by the Greek accounting standards down to 2

nd level

accounts as to their accounting purpose. No magic exists; one has fixed asset accounts, liability accounts, expense accounts, revenue accounts, and so on.

4.1.2 Accounting periods Accounting periods are simply like any other accounting system. Also for the opening period which has to be named and be kept separately, but must otherwise have a posting date within the normal fiscal year. Opening transactions are usually created either until March 31

st, or April 30

th.

Closing periods however are more than one. Closing periods can range from 1 to 3 and they refer to the “stage” of the balance sheet balances after the last step’s closing transactions. These steps are simply the accounting logical steps taken to fully close a fiscal year. Depending on the type of business more or less closing periods may be needed. Sometimes they are nicknamed 13

th month type periods. The closing steps are

normal steps like anywhere else in Europe, only maybe a little bit exaggerated. The balance sheet is one major report that is required to be issued as per period and, therefore, closing period, so as to show the closing stage and accounts balance at the specific stage.

4.1.3 Tax office / tax registration number Any legal entity in Greece (company or individual) must have a tax registration number in order to function. This is not a VAT registration number, it is a general registration number (it is practically the entity’s code for the tax authorities IT system). The system should have such a field for every business relation (customer, vendor, etc). Whenever files are exported for use by the authorities this registration number is used to identify the entity. There is an algorithm that tests registration number validity.


- 7 -

Tax office is also an info that should be part of any legal entities record. It is prnted on invoices, etc. Tax office codes are usually the ones that tax authorities use. Profession. A profession is an entity’s activity. It is both informational but also legal since it printed on sales documents. They too are coded by local authorities.

4.1.4 Transactions The way transactions should be kept is maybe one of the most difficult to understand matter in terms of complexity. A little bit bureaucratic, with a tendency to be simplified. Transactions are characterized by a hierarchy of “containers”:

Firstly there is every original autonomous document. It can be called document, original document, or voucher. It exactly matches AX’s voucher with document and document date fields

Document. This is a container that can hold one or more vouchers. To that amount it is equivalent as a container with AX’s journal. However one cannot have simply one journal code and numbering. There have to be several and they are distinguished by factors like:

o Locality, like branch, warehouse, etc o Transaction type, like general journal, cashier, costing, sales documents,

purchase documents, etc o Sometimes they may be specialized down to employee or batch type,

used for reconciliation purposes It is very important to note that the way documents are coded is identical to the way they are filed and therefore be looked at both by personnel and controllers (especially tax controllers)

Journal. Journal could but are not AX’ s type of journal. They account for containers that keep daily transactions per type. One can have the general journal, the cash journal, the sales journal, etc. The journals used to be printed at end of month in official pre-approved by tax authorities’ paper. Nowadays this has been abolished, they are supposed to be printed though upon request in normal paper for reconciliation paper and still have their format (columns) fixed.

No exotic aspects govern transaction info. Plain accounting transactions info. One thing though that is extensively used as a technique, is transaction reversing. When reversing transactions, debits should go as negative debits and credits as negative credits. Preset transaction documents are a very common feature in local software industry. Preset transaction documents may contain accounts dimensions and amounts and are simply recurring transactions (e.g. on a monthly basis) or may only contain accounts and dimensions and th user simply enters amounts.

4.1.5 Cost center and dimensions allocations Allocations to dimensions or accounts and dimensions are normal practice, especially for expenses. Allocations cannot be set at an account level like in AX. At transaction level an allocation sheet has to be built. Allocation sheets can be preset and used with several accounts or can be built at entry time ad hoc. Allocation can take place with a number of allocation criteria: most common are percentages, allocation factors or actual data within accounts or dimensions used as allocation factors.


- 8 -

4.1.6 The “branch” entity Companies that have branches within the country have a number of accounting principles to comply with.

Firstly, inventory may be either evaluated cross company, or per groups of warehouses or branches

Books may either be printed per branch or globally

Item transfers between branches or warehouses

Etc It seems that AX’s idea of a branch is a company account and intercompany transactions. In this case however one will have to build on top of that so that the system knows which company accounts are branches and which are companies. The hierarchy has to acquire metadata to describe the company structure and make deployment and parameterization easier.

4.2 Sales and purchase document handling

Sales documents (and their opposite kind, purchases) are maybe the most legal related documents of all. They are officially called “taxable items”. This is due to the fact that tax authorities are continually seeking of ways to handle tax evasion practices. So they seek to be able to keep track of every document issued and make sure they are not fictitious, for tax and especially VAT.

First documents to be issued are distinguished for their different general purpose. So there are different document codes for services and / or items. There are different types for sales or returns. Different documents for packing slips and invoices.

Documents have also got to be distinguished per issue location. So there have to be different document codes per issue location like branch or warehouse.

Since continuity on different dates must be preserved and companies are not allowed to issue document no 10 ready to ship first thing tomorrow morning and then issue no 11 for today, there must be kept different document codes for that purpose too.

Sales documents are filed per all these types. To do that local authorities (and also local software) are using the term “series” (like in Dynamics NAV). People have a different series for every combination of the factors above. Alternatively the “series” can simply be made of 3 information fields (entities):

Branch

Document type (services, items, packing slip, invoice, return (simply quantities), credit invoice, etc.

Series, to distinguish between different documents for other more detailed processes.

Every series must have its own counters. Counters can be reset for every fiscal year, or can be continuous. When a document is issued, at least 2 copies are printed. There are or were cases where more copies are printed. One copy is filed at the company’s office and there is a separate file per series.


- 9 -

No double printing can ever be done, not even by mistake. This means that a document cannot be reprinted. This is because tax authorities consider every printed document as a taxable revenue and VAT. There are cases where the sequence of documents is preset at order taking. So there can cases where a packing slip will be issued and then an invoice. At packing slip time a user can only either issue an invoice or a return receipt. If a return receipt is issued only a credit invoice can be issued. Another legally controlled issue is document cancelation or reversing. There is a very specific jurisprudence as to how a company should cancel an invoice or packing slip due to an issue mistake or because of customer absence when goods arrived on site. A cancelation document is issued that fully produces a reversing of all transactions. Canceling documents need not have as many series as original documents do. However it should not be a user’s choice to issue a reversing of packing slip for an invoice and so on. This matter should be fully controlled by the system. Cancelation brings the document of the previous step to an open state. That means that if one cancels an invoice then the packing slip issued before the invoice has to return to an “open to be invoiced” state Last but not least one should mention that, since around 3 years, electronic signing of documents is necessary. The application itself does not necessarily do anything or has to control anything. But a document and its signature (a type of HASH1 algorithm signature) are unique. No 2 signatures should be issued for the same document or vice versa. This is only mentioned in order to stress the fact that reprinting cannot be done. In case of physical loss or damage to the printed document, canceling and reissue of a new document is the right way to proceed. One peculiarity that is not Greek and yet it is not met as a requirement, is the need to first issue an invoice and issue a packing slip. The invoice in this case is only values and does not post any quantities. This is required during export or import processes.

4.3 Analytical ledger accounting (similar to AX’s cost accounting)

Analytical ledger accounting is a relocation of expenses that is done through a parallel analytical chart of accounts, organized on a per cost center basis. So expenses incurred are posted to general ledger and reallocated (either on line or at end of month) on a per cost centre basis. After this first allocation, costs are allocated to production and posted to analytical ledger on o per product or group of products basis. Further, after inventory evaluation costs of goods, cost of sales and sales values are also posted, resulting in a parallel way to come up with the accounting closing financial result/statement. Analytical accounting is now becoming slowly obsolete in Greece, but since there are companies that are using it, one has to implement it in a localization project.

4.4 Inventory costing and production costing requirements

A very commonly used inventory cost evaluation method, other than month average, FIFO, LIFO, etc, is the year to date average method. Using this method, the average requisition price is calculated as a normal average, but cost of sales, cost of transfers and inventory cost are also calculated as year to date. This must be done without


- 10 -

affecting previous accounting periods. So, if one has closed month 3 having calculated a cost of sales to be 1.000 € and at month 4 the cost of sales is 1.350 € calculated on a year to date basis, then at closing of month 4 a transaction with posting date 30/4/xx should appear for that item for 350 € (1.350 – 1.000 already posted). This is the case even if in month 4 no sales were made for that item. One should note that it is a company’s choice to evaluate either globally over all warehouses, or per warehouse, or per groups of warehouses. If a company makes use of such an evaluation method then production costing should also go with the same method. A finished production order may have its cost changed because average wages or other expenses have changed. Another thing that goes with production costing is that actual, month end costs are allocated to production and not preset costs in work centers, or professionals to be posted when production is posted. Matters of costing are fairly difficult to implement and this description does not reflect the full complexity of the matter

4.5 Import costing (total landed cost).

Imports and the problem of evaluating total landed cost is like anywhere else in Europe. Calculating custom duties when applicable may differ from country to country, however the main functionality needed to handle imports is common:

The first thing that arrives is the invoice. the goods themselves and the corresponding packing documents arrive some time later

Expenses that are made may refer to one or more shipments. One therefore has to allocate expenses like freight, insurance, duties (no matter how they have been calculated), etc, to one or more shipments, while every shipment may include a big number of items

The allocations above may be executed using number of criteria, depending on the expense. Criteria can be quantity shipped, volume of goods, value of goods (for insurance), etc.

While expenses are being incurred, they must go against special accounts to be cleared later.

When the import is concluded, a closing procedure runs, which clears the temporary account and all costs are posted to inventory and general ledger on the date of closing the import “folder”.

All the above simply cannot be done using miscellaneous charges manually, apart of course from the fact that local software deals extensively with this requirement.

4.6 Post dated cheques and promissory notes (drafts)

In local payment practices the extensive use of post dated cheques is very – very common. In fact the use of normal cheques is very –very rare. It is simply an exception. A post dated cheque or a promissory note is like a normal cheque only the recipient goes to the bank and cashes the cheque on the date specified on it and not before. Depending on how difficult the situation is a post dated cheque can be for 2, 4, or maybe even 6 or 8 months at extreme cases.


- 11 -

Apart from simply stating “I will cash your merchandise at a later time but I issue a cheque for you which is a document with legal implications and therefore you are sure to get your money”, the very fact that cheques are post dated brings up a number of implications:

First there is a whole workflow that goes around with such a cheque. It can be transferred from a branch to central office. It can be transferred as payment to a vendor against purchases. It can be transferred back from this vendor because he might want a closer date. Then transferred to another vendor, or simply be kept and just be transferred to the bank to be paid. It can be called a “bad” (unaccounted for) cheque. All these are transaction types that can be made against a cheque. One should note that a transfer to a vendor is equivalent to a payment and should therefore debit the vendor. All these transactions must post to the general ledger

A company can get cheques from customers and issue post dated cheques of its own.

Credit control has to take postdated cheques into account. Credit limits must be specified both as open account, open cheques, total and so on

A number of reports have to be produced (4-5) some of which are legal reports required by the authorities or the controllers

4.7 Export files and data

There are 2 types of files produced and sent to local authorities, which they use for cross check

Customer Sales and vendor purchases. Basically it contains aggregated data per customer and vendor (2 different files) with total sales or purchase amount per customer, number of documents issued and so on. This file references a calendar year (1/1 – 31/12) irrespective of fiscal periods.

Electronic file containing balance sheet data per account. Very recently it is required only for 1

st level accounts.

4.8 Reporting

There is a number of reports that are required for controlling and official purposes. There are 2 official reports, which are the general ledger trial balance report and the inventory trial balance reports. The term official means that:

1. They are printed and the printouts are kept filed on a monthly basis regardless of being demanded by a controller or not. Having printed the reports means on cannot go back in older fiscal periods and insert or update transactions.

2. The paper they are printed on is either preprinted (titles and number of pages) or in any case predestined for this purpose.

Apart from these official reports there is a number of counting reports that have to comply with local standards and practices. Examples of such reports are:

Trial balance, account statement and journal type reports for all kinds of accounts: ledger accounts, customers and vendors These reports are to be printed with options to print local currency amounts / foreign currency amounts


- 12 -

Opening balances reports for all types of accounts, namely ledger accounts, customers, vendors, inventory (opening quantities, opening costs), cheques and promissory notes, fixed assets

Aging analysis reports for open items for vendors and customers

Reports on the average payment times for customers and vendors including cheques (payment occurs at the cheques date and not ata cheque receiving date)

Fixed assets special journal

Inventory reports on quantities, cost amounts, sales amounts and gross margins

BOM official report

Production cost analysis report