You are on page 1of 105

Localization Process SAP ERP 6.

0 Country Manual

SAP Hellas

SAP ERP
May 2012

SAP ERP 6.0 Localization for Greece

User Guide SAP ERP 6.0

SAP HELLAS S.A.


20 Ellinidon str.
Athens

© SAP HELLAS S.A. 1


Localization Process SAP ERP 6.0 Country Manual

0. WHAT’S NEW IN SAP ERP 6.0 ............................................................................................ 6

1. INTRODUCTION .................................................................................................................. 6

1.1 Purpose and performed tasks of this Manual .................................................................. 6

1.2 Definition of the term Hellenization ................................................................................. 6

1.3 Hellenization Deliverables ................................................................................................ 7

1.4 Release Strategy and Interim Policy for Greek Versions ................................................ 7

1.5 Prerequisites for Customers ............................................................................................. 7

1.6 Significant Notes................................................................................................................ 7

1.7 Types of Companies operating in Greece ......................................................................... 8

1.8 Explanatory issues for Effective Hellenization usage ..................................................... 9

2. GENERAL ISSUES.............................................................................................................. 12

2.1 Main specifications for Greece ....................................................................................... 12

2.2 A Sample Company ......................................................................................................... 13

2.3 Validations ....................................................................................................................... 13

2.4 Fiscal Year Variant for Greece ....................................................................................... 13

2.5 Greek Calendar - Public Holidays .................................................................................. 14

3. FI TOPICS COVERED BY THE LOCALIZATION PROCESS ............................................... 15

3.1 A Sample Greek Uniform Chart of Account .................................................................. 15

3.2 Sample Sale and Purchase Taxes for Greece ................................................................. 18

3.3 FI Master Files ................................................................................................................ 22


3.3.1 G/L Accounts ............................................................................................................ 22
3.3.2 Customers ................................................................................................................. 23
3.3.3 Vendors ..................................................................................................................... 23
3.3.4 Banks ........................................................................................................................ 24

3.4 A/R and A/P account groups........................................................................................... 24

3.5 Document types ............................................................................................................... 25

3.6 Field status group ............................................................................................................ 26

3.8 Special G/L indicators ..................................................................................................... 26


3.8.1 Special GL for Customers .......................................................................................... 26

© SAP HELLAS S.A. 2


Localization Process SAP ERP 6.0 Country Manual

3.9 Automatic account determination tables........................................................................ 27

3.10 FI Reporting .................................................................................................................... 27


3.10.1 G/L and A/L Journal .................................................................................................. 28
3.10.2 Legal G/L and A/L Trial Balance .............................................................................. 30
3.10.3 G/L and A/L Trial Balance ........................................................................................ 32
3.10.4 G/L and A/L Ledger .................................................................................................. 32
3.10.5 G/L and A/L Summarized Ledger .............................................................................. 32
3.10.6 Customer Trial Balance ............................................................................................. 33
3.10.7 Customer Ledger ....................................................................................................... 33
3.10.8 Customer Financial Data ........................................................................................... 33
3.10.9 Vendor Trial Balance ..................................................................................................... 33
3.10.10 Vendor Ledger ............................................................................................................ 33
3.10.11 Vendor Financial Data ................................................................................................. 33
3.10.12 VAT Reconciliation Report ......................................................................................... 34
3.10.13 Sales and Purchases reconciliation report (MYF) ......................................................... 34
3.10.15 Vendors withholding tax forms report ......................................................................... 37
3.10.16 Day end cash control report ........................................................................................ 39
3.10.17 Chart of accounts list ................................................................................................... 39
3.10.18 Document printout....................................................................................................... 39
3.10.19 Year end customer balance .......................................................................................... 39
3.10.20 Year end vendor balance ............................................................................................. 39
3.10.21 Trial balance in Magnetic Media ................................................................................. 40
3.10.22 Printing of Pre-numbered tax-authorized forms ........................................................... 40

3.12 Post dated checks receivable management ..................................................................... 40

3.13 Statistical Postings for non EEC imports ....................................................................... 43

3.14 Payment procedures ......................................................................................................... 43


3.14.1 Payment Program Configuration for the Sample Company ........................................ 43
3.14.2 G/L Account checks .................................................................................................. 45

3.15 Year end FI closing procedures ...................................................................................... 45

3.16 Year start FI opening procedures ................................................................................... 46

4. AM TOPICS COVERED BY THE LOCALIZATION PROCESS ........................................ 47

4.1 Asset Master File ............................................................................................................. 47

4.2 Definition of company code............................................................................................. 47

4.3 Depreciation Areas .......................................................................................................... 47

4.4 Asset Class ....................................................................................................................... 48

4.5 Customizing the ‘Calculation keys’ and the ‘Valuation keys’ ....................................... 48

4.6 Asset Management Automatic Account Determination and Depreciation Tables ....... 49

4.7 Asset Revaluation ............................................................................................................ 49

4.8 Legal books related to Fixed Assets ................................................................................ 50

© SAP HELLAS S.A. 3


Localization Process SAP ERP 6.0 Country Manual

5. ANALYTICAL ACCOUNTING .......................................................................................... 53

5.1 Introduction..................................................................................................................... 53

5.2 Internal Accounting assessment of Operation Costs ..................................................... 53

5.3 Internal Accounting assessment of Production Costs of Manufacturing Companies .. 54

5.4 Internal Accounting Observation of Stock Movement .................................................. 55

5.5 Internal Time Arrangement of Purchases, Expenditures, Income, and Non-Operating


Results in Monthly Basis and Determination of Monthly Results ............................................ 55

5.6 Mandatory A/L Accounts ............................................................................................... 56


5.6.1 System of Autonomy ................................................................................................. 56

6. SD - RELATED ISSUES FOR GREECE.............................................................................. 61

6.1 Organizational Structures .............................................................................................. 61

6.2 Customer Master Files – Partner Functions .................................................................. 62

6.3 Integration with FI .......................................................................................................... 62


6.3.1 Tax determination...................................................................................................... 62
Posting to Tax Accounts ........................................................................................................... 64
6.3.2 SD Account determination ......................................................................................... 65
Mapping of SD billing documents to FI document types ........................................................... 65
Posting to G/L Revenue and Sales Deductions Accounts........................................................... 65

6.4 Special Business Transactions ........................................................................................ 67


6.4.1 Special Business Transactions - Cancellations ........................................................... 67
6.4.2 Special Business Transactions - Deliveries free of charge .......................................... 68
6.4.3 Special Business Transactions – Rebates ................................................................... 68
6.4.4 Special Business Transactions - Retail sales .............................................................. 68

6.5 Legal Forms .................................................................................................................... 68


6.5.1 Legal requirements .................................................................................................... 69
6.5.2 Customizing for legal documents ............................................................................... 69

7. MM TOPICS COVERED BY THE LOCALIZATION PROCESS........................................ 73

7.1 Master Data ..................................................................................................................... 73


7.1.1 Accounts ................................................................................................................... 73
7.1.2 Materials managed on a quantity and value basis ....................................................... 78
7.1.3 Other Materials & Services ........................................................................................ 79

7.2 Business Processes ........................................................................................................... 80


7.2.1 Buy ........................................................................................................................... 80
7.2.2 Sell ............................................................................................................................ 83
7.2.3 Make ......................................................................................................................... 85
7.2.4 Other ......................................................................................................................... 87
7.2.5 Special stocks and Greek legal requirements ............................................................. 90

7.3 Customizing ..................................................................................................................... 92

© SAP HELLAS S.A. 4


Localization Process SAP ERP 6.0 Country Manual

7.3.1 Customizing in the standard SAP tables ..................................................................... 92


7.3.2 MM Reporting ........................................................................................................... 94

7.4 Material Valuation .......................................................................................................... 94

7.5 Warehouse book .............................................................................................................. 94

7.6 Procedure of physical inventory of stocks and statutory requirements ........................ 94


7.6.1 General ...................................................................................................................... 95

7.7 Other Programs of Hellenisation .................................................................................... 95


7.7.1 15-days Validation in Inventory Management............................................................ 95
7.7.2 Activation of the purchasing account (PU)................................................................. 96
7.7.3 Transfer of posting from 32 to 20 ............................................................................. 98

7.8 270 AND SAP ERP SOLUTION .................................................................................... 99


Introduction .............................................................................................................................. 99

OPERATING ASSUMPTIONS – BASIC FUNCTIONS .......................................................... 99

DESIGN – IMPLEMENTATION .............................................................................................101

IMPORTANT SAP NOTES ........................................................................................................105

© SAP HELLAS S.A. 5


Localization Process SAP ERP 6.0 Country Manual

0. What’s new in SAP ERP 6.0

Since ERP 2004 (ECC 5.0) there has been a major change in the Hellenization. Since this release
the Greek Country Version was included in the CEE CORE ADD-ON SAP CORE CEE 110_600 together
with other Eastern countries etc and has to be installed as a whole even if these countries are not
relevant for customer installation.

Software is available for download only as described in Note 520991.

It was found that the delivered customizing of the Greek Model company may had conflicts with std
SAP customizing, especially in single client installations. Based on this fact, it was decided that
customizing of a typical Greek company will not be part of the add-on. It is though attached as
transport requests in several SAP notes.
A big part of the documentation below is only valid when this request is implemented in a system.

All the major notes that deal with Hellenization issues are presented in the end of this document.

1. Introduction

1.1 Purpose and performed tasks of this Manual

SAP ERP is an enterprise resources planning system, which is being used in many countries.

To adapt SAP ERP to each and every country’s local financial regulations and common business
applications, it is necessary to do country specific development and configuration projects. All the
projects done for adapting SAP ERP according to Greek requirements are gathered under the topic
‘Localisation’ or ‘Hellenization’.

This user guide covers the explanations of the reports and tables developed and configured as part
of the localization process.

The purpose of this manual is to present an example of a Greek model company applicable to all
Greek companies. There are issues that are relevant to Greek legislation (e.g. regarding specific
Industry Sectors) that are not included in this country manual or in the delivered solution. No
industry specific requirements are covered. Also requirements that are not valid for all companies,
e.g additional books of Article 10 of Books and Data Code are not included in the solution.

1.2 Definition of the term Hellenization

Hellenization is the Greek Localization for SAP ERP. It deals with Greece, that is treated by SAP as
all other countries, by implementing a well documented Greek Model Company GR01. The Greek
Model Company possesses attributes concerning special characteristics of Greece such as language
EL, currency EUR, Greek Uniform Chart of Accounts CAGR, Fiscal Year 13 periods (K1) and so
on that also meet customer independent legal and business requirements.

Hellenization is an on going process rather than a project, since it is related to managing a changing
environment in terms of:

SAP ERP new versions and releases .


New technology and new legislation.

© SAP HELLAS S.A. 6


Localization Process SAP ERP 6.0 Country Manual

1.3 Hellenization Deliverables

The Hellenization deliverables are listed below:

A set of development objects (programs, tables, objects etc). These constitute a customer
independent model Greek Company, complying with the legal requirements, the business
practice and corporate specifications.
Documented local requirements both Business and Legal in various SAP Notes.
Detailed description of the solutions in most of the cases
Customer training and support available on request.
Training of consultants available on request.

1.4 Release Strategy and Interim Policy for Greek Versions

SAP Hellas is a subsidiary of SAP AG, therefore fully aligned with the corporate policy. That
means that SAP Hellas is going to offer localised versions of all SAP ERP releases from now on,
unless Corporate decisions change.

Hellenization process is neither customer nor industry specific and deals with issues related to all
Greek Customers as explained in point 1.1 above.

Individual translation of Customer specific texts should be performed and documented at customers
risk since any upgrade procedure will overlap and consequently damage these translation objects.

1.5 Prerequisites for Customers

Customers should take care of the following:

Proper Installation of the SAP ERP System – preferably Unicode.

Installation of the appropriate SAP ERP modules.

Standard SAP procedures knowledge.

Training for programs and customized data that constitute the model Greek Company.

Compliance to the posting procedures needed for Greece.

1.6 Significant Notes

All objects delivered to customers via Hellenization delivery process and installation are
working properly if the delivery process and the installation procedure have been performed
normally on a successfully installed standard SAP system which has not been changed by
customers.

© SAP HELLAS S.A. 7


Localization Process SAP ERP 6.0 Country Manual

All objects delivered to customers are tested and set up in a way to allow customers to meet legal
requirements after following specific posting rules (e.g. MYF “Data Media Exchange with Tax
Offices as Sales and purchases Reconciliation”). If the customer fails to follow the proper
posting rules (e.g. not posting the AFM “Customer Tax code”) compliance to Greek law may be
risky.

Reporting related to Hellenization should be executed at the proper dates with Customer
responsibility (e.g. Journals, Trial Balances, Year End Trial Balances)

Hellenization Objects are useful in Industry Solutions although they have to be tested
specifically with the special data provided by the Industry Solutions (IS).

Hellenization objects are useful for Greek Companies that deviate from the model company in
terms of posting in a different than Greek Chart of Accounts (COA) but having the Greek as a
secondary (Country or Local) COA.

Hellenization objects are useful for Greek Companies that deviate from standard model company
in terms of posting in a different than EUR Currency in Greek Chart of Accounts (Offshore
Companies).

Downgrading Hellenization objects may be impossible in case solutions are based on


functionality that is not offered in previous standard SAP versions.

It was found that when upgrading from an earlier version of R/3 (e.g. from 30F to 3.1H or from
3.1H to 4.0 B etc ) the ‘Hellenization’ is first deleted (all programs, tables, data elements,
domains, validations etc) as it is treated as Add-on and has to be reinstalled from the CD. This is
of major importance with respect to tables that hold data. Provided this fact it is strongly
recommended that companies should take a full backup before upgrading in order to be able to
continue its operations in case something goes wrong during the upgrade. SAP Note 772476
describes the Upgrade procedures from previous versions of Greek add-on to CEE Add-on.

1.7 Types of Companies operating in Greece

Companies posting in Greek COA, in EUR, in Greek Fiscal Year and reporting only for fiscal
purposes (MODEL GR01).

Companies posting in Greek COA, in EUR, in Greek Fiscal Year and reporting not only for
fiscal purposes.

Companies posting in International COA, in EUR, in Greek Fiscal Year and reporting not only
for fiscal purposes.

Companies posting in International COA, in currency different than EUR, in Greek Fiscal Year
and reporting not only for fiscal purposes.

Companies posting in International COA, in currency EUR, in Fiscal Year different than Greek
Fiscal Year and reporting not only for fiscal purposes.

© SAP HELLAS S.A. 8


Localization Process SAP ERP 6.0 Country Manual

Companies posting in International COA, in currency different than EUR, in Fiscal Year
different than Greek Fiscal Year and reporting not only for fiscal purposes

1.8 Explanatory issues for Effective Hellenization usage


In order to achieve better understanding of the Hellenization processes for the customers and
answer any questions that may arise, further instructions are given below.

a) Technical issues

‘Model Greek Company’ is designed to work in an environment that needs Greek language
support, impact printers for invoice/reports printing (optional) and other relevant settings.

All device types regarding printers should have the respective settings, to support Greek
fonts.

SAP ERP is Unicode compatible so it can support all languages simultaneously. This does
not mean that if you logon with English and put data with Greek characters, you will be able
to meet the legal requirements by running the reports contained in this CD. The suggested
approach is to install Greek Language and logon with it when running the legal forms and
books.

b) Greek Translation Issues

Greek language has a limited priority in comparison to other languages (level 3 language)

SAP Releases, as well as object classes to be translated are decided by SAP AG SLS and the
respective IBU’s and GBU’s in order to meet other level 3 languages for servicing Multinational
companies. (Note: Not all texts, not all modules are translated).

Greek Translation is mainly related to User Interface level (short texts in GUI, Text elements
etc) and reporting of the most significant, in terms of legislation and business practice, modules
(FI, MM, CO, SD etc).

c) Greek Legislation Issues

Greek Legislation related to Software Specifications Document are found in article 23 of Books
and Data Code Regulations (KBS) which is the base for Hellenization.

Greek Legislation can be met in more than one ways since specifications found in article 23 are
general enough to permit different technical approaches.

Hellenization objects allow the Greek Companies to meet the Greek law offering at least one
commonly accepted solution. Note: There may be cases that a customer may change its business
practices in order to meet Greek Legislation .

© SAP HELLAS S.A. 9


Localization Process SAP ERP 6.0 Country Manual

There are no limits in going live in any date of the fiscal year, although not going live on the 1st
of the corresponding fiscal year needs extra effort, because more data including transactions
have to be transferred from legacy systems.

d) Customizing data Implementation Issues

Standard SAP procedures are used as a Basis in all Greek Business Transactions.

Customized data are SAMPLE DATA that can be used as REFERENCE for the creation of real
data commonly accepted in Greece (e.g. Uniform Greek Chart of Accounts).These data are
only available on request or downloadable as attachment in specific notes and are not part
of the s/w download.

IMG activities for all Localisation tables are available

Posting Rules are recommendations for Master File (MF) and Transaction File (TF) creation
(e.g. Customers and Vendors Posting rules according to the Greek Law).

e) Program Development Issues

Standard SAP programs, DDIC (Data Dictionary) or Other Objects have not been modified.

Functionality for covering Greek requirements is additional to standard SAP functionality apart
from the modifications that the customer may have to do (e.g spelled amounts).This means that the
software delivered is modification-free. If the modification is decided, then it is implemented in the
customer system.

SAP development standards have been followed for implementing new objects (e.g. naming
conventions, CHECKMAN procedures, etc).

Reporting Layouts have been designed in order to cover most of Greek companies with as less as
possible new objects.

f) Business Practice Issues

In few cases more than one solutions have been delivered for covering every Greek company’s
needs (e.g. Profession in text or in check table via code).

g) Documentation Issues

Documentation related to Hellenization has been written in English covering Customizing and
solutions in the document titled “ SAP ERP Localization for Greece”.

Documentation related to Greek Legislation Books and Records Code (KBS) has been written in
Greek. This document comprises of text and some print screens. Note: Both text and print
screens should be updated after amendments and /or upgrades. This is not an explicit

© SAP HELLAS S.A. 10


Localization Process SAP ERP 6.0 Country Manual

documentation because of the tremendous extend of SAP solutions customization and in no case
can replace the required manual for end users.

Documentation related to special topics is also available (installation guide)

Technical Documentation related to objects (programs, tables, data elements, domains etc) is
also available on request.

© SAP HELLAS S.A. 11


Localization Process SAP ERP 6.0 Country Manual

2. General issues

2.1 Main specifications for Greece

Greece is a member of the European Union and follows most of the prevailing EU directives (e.g.
Intrastat , VAT etc.).

There is legislation related to Books and Records Code regulations (KBS) as far as business
software is concerned (article 23), which involves the following:

Mandatory tree structure of chart of accounts with specific rules per group of accounts
(predefined both codes and descriptions in Greek language), see chapter 3.

User manual in Greek language providing at least regulations of article 23 that must be updated
in case software upgrades occur.

General ledger and materials management rules in terms of ’15 - 45’ and 10 days check of
postings. Sequential numbering of entries (documents) on the Journal. No interpolations are
permitted.

Reporting is provided in Greek Language and EUR currency. It consists of Journals, Trial
Balances, Ledgers, Warehouse Book, Assets Register etc, with descriptive but not a fully
defined layout. Some reports mentioned above are official and have to be printed on stamped or
perforated authorized papers, providing report and page totals.

Journals, Ledgers, Warehouse Book and Asset Register are referring to original documents via
a) Reference Document Number that is posted to field BKPF-XBLNR and b) Posting Date that
is posted to field BKPF-BUDAT. These fields are mandatory for issuing the above reports
based on the requirements of legislation and also help customers finding out the respective
original document which is filed in a physical folder.

Electronic submission of MYF and the year end Trial Balance before making adjustment
postings for issuing the Balance Sheet are lodged to Tax Offices.

Several reports and especially the Warehouse and the G/L Trial Balance have to be kept in
magnetic media as CD’S and must be presented in a possible Tax Audit.

There are specific check digits regarding Tax Codes (AFM) which cross check for both double
and incorrect entries. Also for posting keys and account groups of domestic customers /
vendors.

Hellenization includes the calculation procedure ‘TAXGR’ where taxes - related to incoming and
outgoing invoices - such as VAT, Withholding and EC acquisition have been defined.

In addition, it uses payment methods based on a) Checks including Post Dated Checks, provided
with check digit in bank lot numbers and b) Bank Transfer.

It follows purchasing accounting logic for MM transactions since Greek companies are obliged to
maintain purchase account in COA.

© SAP HELLAS S.A. 12


Localization Process SAP ERP 6.0 Country Manual

Finally, it issues printed forms copied many times for documents accompanying transported
goods (using impact printers) and filing of originals. According to new legislation this has changed
and there will be electronic filing of such documents together with the introduction of ‘ Digital
signature’ for the printed documents (see respective chapter in SD issues).

2.2 A Sample Company

Country Version:

The standard SAP ERP system includes data which has been previously created according to a
sample German company’s legal and business requirements. This company’s code is defined as
‘0001’.

Sample data of company code GR01 are part of the customizing request which may be provided by
SAP Hellas on request or downloaded by the customer. This transport can be imported in client 000.
Then you can selectively copy entries contained in client 000 for objects of GR, put them in a
transport and transfer into another client.

The fiscal year variant of this company is K1 (Periods are Calendar months with 1 special period
13).

In the country description part of the configuration menu, information about Greece has already
been entered. The country code is given as ‘GR’, currency as ‘EUR’, language as ‘EL’ and the tax
calculation scheme as ‘TAXGR’. A Greek calendar has been developed including all Greek public
holidays.

All the above are only possible after importing the customizing request provided by SAP
Hellas.

2.3 Validations

A validation for Customers and Vendors tax code (AFM) exists in the function
J_2GTAX_CODE_CHECK since the 9th digit of the Greek Tax Codes is a check digit that is
calculated from a mathematical function of the previous 8 digits. This function can be used in many
points within SAP (e.g. in the user exits on Customer and Vendor Master Creation, on exception
reports lists etc.). However, starting January 1st 1999 the length of the tax code (AFM) was 9 digits
long due to new legislation. This function module works with tax codes of length 9.

Program ‘J_1GVALD’ contains code that includes several validations. It is also needed to be
activated (customizing table V_T001D and possibly V_T891B).

Message classes 8N1 and 8X1 are also part of Hellenization. The classes includes all the texts of
the messages that are depicted at the bottom of the screen along with the occurrence of the
validation.

2.4 Fiscal Year Variant for Greece

Fiscal Year in Greece is a Calendar Year comprising of 12 month periods and a special 13th period,
comprising of 4 months, for Balance Sheet preparation.

There are 3 Fiscal Year types in Greek Companies:

© SAP HELLAS S.A. 13


Localization Process SAP ERP 6.0 Country Manual

1. Normally, Companies have 12 month periods with a 13th special Balance Sheet Period starting
on 1st of January , the start of the Calendar year.

2. Companies have 12 month periods with a 13th special Balance Sheet Period starting on 1st of
July.

3. Companies have more than 12 month periods with a 13th special Balance Sheet Period starting
on an ordinary date. In this case, if the company has the first Fiscal year type, the books are
closed either in the 1st year of operations (31/12/20xx) or the same date of next year. If the
company has the second Fiscal year type the books are closed on the 30th of June of the 1st
fiscal year or the same date of next year.

2.5 Greek Calendar - Public Holidays

Greek Calendar is included in standard SAP solutions from release 4.6c.

New Year’s Day 1/1


Epiphany 6/1
Annunciation 25/3
Labor Day 1/5
Assumption 15/8
National Holiday 28/10
Christmas Day 25/12
Boxing Day 26/12
1st Monday of Lent Gr. Orth. Easter Relative - 48
Good Friday Gr. Orth. Easter Relative -2
Easter Sunday Gr. Orthodox Easter
Easter Monday Gr. Orth. Easter Relative +1
Whit Monday/Holy Spirit Gr. Orth. Easter Relative + 50

Movable Holidays are related to the Greek Orthodox Easter which determined via Gauss algorithm.
Unfortunately the movable holidays related to Easter are wrong, as Easter Sunday is following the
Orthodox Easter algorithm (not supported) and have to be changed manually. SAP Note 142759
can be used to facilitate finding the Easter related holidays.

© SAP HELLAS S.A. 14


Localization Process SAP ERP 6.0 Country Manual

3. FI Topics Covered by the Localization Process

3.1 A Sample Greek Uniform Chart of Account

According to the Greek Books and Data Code Regulations all Greek Commercial Companies
(Legal entities) are obliged to post their Business Transactions in General Ledger by using the
Greek Uniform Chart of Accounts (EGLS).

The Greek Uniform Chart of Accounts (EGLS) is a tree structured Chart of Accounts 3 to 5 levels
based on the number of digits of the Account Numbers. COA consists of 3 areas, defined by Greek
legislation:

1) Area 1 comprises of Accounts that are used for informational purpose postings that do not
affect the Company’s property (All account numbers start from 0).

2) Area 2 is used for normal General Ledger postings. It consists of eight group of accounts:
Group 1 comprises of accounts that are used for Fixed Assets. (All account numbers start from
1).

Group 2 comprises of accounts that are used for stocks and materials. (All account numbers start
from 2).

Group 3 comprises of accounts that are used for debtors, cash both at bank and in hand. (All
account numbers start from 3).

Group 4 comprises of accounts that are used for capital and reserves. (All account numbers start
from 4).

Group 5 comprises of accounts that are used for creditors. (All account numbers start from 5).

Group 6 comprises of accounts that are used for operating expenses. (All account numbers start
from 6).

Group 7 comprises of accounts that are used for operating revenues. (All account numbers start
from 7).

Group 8 comprises of accounts that are used to derive accounting results. (All account numbers
start from 8).

3) Area 3 is used for Analytical Ledger postings. G/L postings of 2, 6, 7 and 8 group accounts
are reallocated by destination in Analytical Ledger for cost controlling purposes. (All account
numbers start from 9).
Every Greek company is obliged to issue Balance Sheet and Profit and Loss Statement at the end of
the fiscal year. The Balance Sheet is structured having assets on the left and liabilities on the right.

Assets include 1, 2 and 3 group accounts.


Liabilities include 4 and 5 group accounts.
Profit and Loss Statement has the operating revenues, expenses and net results (profit or loss) for
the respective year before taxes. Therefore, it is composed by group accounts 6, 7 and 8.

© SAP HELLAS S.A. 15


Localization Process SAP ERP 6.0 Country Manual

The tree structure of the first 2 areas is similar but may generally differ from the 3rd area in terms of
levels and digits per level.

Level structuring, digits per level, as well as level account coding and descriptions are determined
differently by each Greek company according to their needs by using the following rules:

The 1st level is mandatory by the law, 2 digits are mandatory by the law, and descriptions are
specified by the law.

The 2nd level is mandatory by the law, 2 digits are mandatory by the law, and descriptions are
specified by the law.

The 3rd level is mandatory by the law, the number of digits are according to company’s needs, and
descriptions are according to company’s needs.

The 4th and possibly the 5th levels are according to the company’s needs. The number of digits are
according to the company’s needs, and descriptions are according to the company’s needs.

Posting Accounts are only the accounts of the last level which are defined as standard G/L Accounts
in SAP ERP system.

Compliance to the above specified rules is achieved by using 2 Country Greece specific tables:

J_1GGS for maintaining Level Structure of A/L and G/L


J_1GGL for maintaining Chart of Accounts Level (non posting) Descriptions

Table J_1GGS looks like:

Chart of Account G/L-A/L 1st Lvl 2nd Lvl 3rd Lvl 4th Lvl 5th Lvl Starting
account
CAGR G 2 2 2 4 0 0100000000
CAGR A 2 2 2 2 2 9000000000

Note that A/L accounts can have different structure than G/L ones.

© SAP HELLAS S.A. 16


Localization Process SAP ERP 6.0 Country Manual

Table J_1GGL looks like:

Lang Chart of Level Long text


Account number
EN CAGR 11 BUILDINGS-TECHNICAL INSTALLATIONS
EN CAGR 1100 BUILDINGS INSTALLATIONS
EN CAGR 110000 BUILDINGS
EN CAGR 1199 ACCUM. DEPRECIATION-BUILDINGS INSTAL. TECHN,
ISTAL
EN CAGR 119900 ACCUM. DEPRECIATION-BUILDINGS - INSTALLATION
EN CAGR 12 PLANT AND MACHINERY - TECHN. INSTALLATIONS
EN CAGR 1200 PLANT AND MACHINERY
EN CAGR 120000 PLANT AND MACHINERY ATHENS

You can reach the tables via the corresponding IMG Activity or through program J_1GCOA_TREE
(transaction J1GCOA). When a user wants to create an account, at least one example is given for
each general ledger representative account.

At the Chart of Accounts level, data is entered in the following fields according to the properties of
the accounts:

Name: Short Text


G/L Account Long Text

Control: Balance Sheet Account


P&L Statement Account Type
Account Groups

At the company code level, data is entered in the following fields:

Account Control: Currency


Tax Category
Reconciliation Account for Account Type

Account Management: Open Item Management


Line Item Display
Sort Key

Document Entry Control: Field Status Group


Post Automatically Only

Flow of Money: Relevant to Cash Flow

Reference: Alternative Account No.

For Greece, the sample company is defined by the code ‘GR01’. Accounts for this sample company
are opened under the GR01 company code. This company’s country code is defined as ‘GR’,
currency as ‘EUR’, language as ‘EL’ and Chart of Accounts as ‘CAGR’.

Printout of the Greek COA tree in terms of Chart of Accounts Level as well as in terms of Company
Code level is performed through the program J_1GCOA_TREE.

© SAP HELLAS S.A. 17


Localization Process SAP ERP 6.0 Country Manual

In addition, SAP Hellas recommends the following in terms of the transformation of Chart of
Accounts from an old system to SAP :

A set of G/L accounts, found in the company’s old Chart of account that is related to personnel
accounts, should not be opened in SAP as G/L Accounts. All these accounts should be opened as
Vendors or Customers typical example Employees. (reconciliation accounts of these Customers or
Vendors should exist as G/L Accounts possibly similar to those in the old Chart of Accounts).

A set of G/L Accounts, found in the company’s old Chart of account that is related to import
purchasing files, should be opened as only one account in SAP, providing MM module is
implemented. This is enough since management of file of imports can be achieved via the purchase
order number, that can be a required field for every posting in this unique Account
(32012XXXXX).

A set of G/L accounts, found in the company’s old Chart of account that is related to Electricity
Authority, Tax Offices, Social Security Offices etc. should not be in SAP as G/L Accounts. All
these accounts should be opened as Vendors or Customers. However, reconciliation accounts of
these Customers or Vendors should be similar to the G/L accounts of the old Chart of Accounts).

3.2 Sample Sale and Purchase Taxes for Greece

For Greece a tax calculation procedure has been created with the code ‘TAXGR’. This tax
procedure is linked to country GR with which company GR01 is linked. Sample VAT, EC
acquisition, and withholding codes have been defined within this procedure.

Their names are referred below:

Output tax
Input tax
Input Tax not deductible, not allocated, (Separate line item posting indicator is required)
Input tax not deductible, allocated, (Distribute to relevant expenses/revenues items posting
indicator is required)
Credit Acquisition tax
Debit Acquisition tax
Withholding tax 1 (Xartossimo)
Withholding tax 2 (OGA)

Withholding tax 3 (IKA)


Withholding tax 4 (Ageliossimo)
Withholding tax 5 (Specific)
Withholding tax 6 (Third)
Withholding tax 0 (Interim)

To support the calculation process and define the above tax codes, ‘TAXGR’ uses two main tools:
a) condition types and b) account keys. Every condition type corresponds to one account key.
Within the account key the following attributes are defined: tax type (i.e. input, output, etc.),
deductible or not, posting indicator (i.e. separate line item, distribute to relevant expenses/revenues
items etc.). Within condition type some of the following attributes are defined: calculation type,
rounding rule, condition class (i.e. taxes, prices, discounts etc.) and so on.

© SAP HELLAS S.A. 18


Localization Process SAP ERP 6.0 Country Manual

The so called “Withholding” taxes in Greece are based on Vendors invoices and are irrelevant to
payments.

The withholding tax requirement can be covered through Std SAP Extended Withholding tax
functionality which is suggested to all customers instead of the approach described above.

One of these required fields is the ‘Tax Category‘, an attribute of G/L Accounts. To assign any G/L
account to a tax code the first field must be filled. The possible entries of ‘Tax Category’ field are
referred below along with their meaning:

‘blank’ = the account is not tax related


‘xx’ = the account has specific tax code
‘-‘ = only input tax is allowed for this account
‘+’ = only output tax is allowed for this account
‘*’ = all tax types are allowed for this account
‘<’ = the account is an input tax
‘>’ = the account is an output tax

Special care should be given to a tax code assignment to G/L accounts for expenses, revenues and
taxes. Specifically, a) expenses should be assigned to either to ‘-‘ or ‘*’ tax category, b) revenues
should be assigned to either ‘+’ or ‘*’, and c) taxes should be assigned to either ‘<’ or ‘>’(e.g. only
input tax allowed, only output tax allowed, specific tax code etc.). Expenses, revenues and taxes
G/L accounts are developed accordingly in order not to allow the users to post wrong tax codes.

As soon as this customization is completed, at the time of posting documents, users should first
activate the check box ‘Calculate Tax’ and then enter the respective tax code. During these postings
the relative accounts are updated. Unless ‘Tax Category’ and tax code are compatible, the posting
will be terminated.

Notice that for tax codes linked to expenses that are not deductible, the requirement for correct base
amount is essential. In this case the tax code should not create automatically new line item for tax
account but it should only calculate the correct base amount.

The transaction code FTXP leads to information about tax procedures. More specifically, it shows
the Base Amount, the Output Tax, the Input Tax, the Non-Deductible Input Tax (MWVZ), the Non-
Deductible Input Tax (MWVN), the Acquisition Tax Credit, and the Acquisition Tax Debit, the
Withholding Tax, the Stamped Tax on withholding Tax, and other Non - VAT relevant taxes.

There is a standard SAP procedure that requires manual post processing for the import of tax codes
(message F4 794 and respective SAP Notes).

As far as tax related properties are concerned, the indicator for invalid tax amount is not set. Hence,
a warning message appears in place of an error one and allows Vendor invoices postings with
incorrect calculations of VAT amount. Rounding rules for all taxes have been set on Business. This
means that 4.4 will be rounded to 4 and 4.6 will be rounded to 5.

In addition to this, all tax accounts linked to tax codes have been defined as automatic posting only.

In case of Interfaces from non SAP systems toward SAP for posting documents which include
taxes, they may use the same percentages but different rounding rule. For example, Sales Related FI
documents posted from a non SAP system into SAP. If the rounding rule is different Base amount,
Gross Amount and Tax amount do not reconcile and a difference has to be determined. In this case
the identification of 2 out of 3 amounts that reconcile to SAP’s automatic calculation is essential

© SAP HELLAS S.A. 19


Localization Process SAP ERP 6.0 Country Manual

(for example Base amount and Tax amount that reconcile with the percentage). The document
should be posted using these amounts and gross amount should be posted in 2 line items (the first as
Customer receivable amount and the second as a difference).

Proper Tax posting is essential for Greece since many fiscal reports need the correct Base Amounts
of incoming and outgoing invoices.

Ctry GR GREECE

Code Description

00 EEC ASSET ACQUISITION 0%


01 EEC ASSET ACQUISITION 6%
02 EEC ASSET ACQUISITION 9%
03 EEC ASSET ACQUISITION 13%
04 EEC ASSET ACQUISITION 19%
10 ASSET DOMESTIC ACQUISITION 0%
11 ASSET DOMESTIC ACQUISITION 6%
12 ASSET DOMESTIC ACQUISITION 9%
13 ASSET DOMESTIC ACQUISITION 13%
14 ASSET DOMESTIC ACQUISITION 19%
15 ASSET ACQUISITION 3rd COUNTRIES 0%
16 ASSET ACQUISITION 3rd COUNTRIES 6%
17 ASSET ACQUISITION 3rd COUNTRIES 9%
18 ASSET ACQUISITION 3rd COUNTRIES 13%
19 ASSET ACQUISITION 3rd COUNTRIES 19%
20 GOODS ACQUISITION DOMESTIC 0%
21 GOODS ACQUISITION DOMESTIC 6%
22 GOODS ACQUISITION DOMESTIC 9%
23 GOODS ACQUISITION DOMESTIC 13%
24 GOODS ACQUISITION DOMESTIC 19%
25 GOODS ACQUISITION 3rd COUNTRIES 0%
26 GOODS ACQUISITION 3rd COUNTRIES 6%
27 GOODS ACQUISITION 3rd COUNTRIES 9%
28 GOODS ACQUISITION 3rd COUNTRIES 13%
29 GOODS ACQUISITION 3rd COUNTRIES 19%
30 GOODS ACQUISITION EEC 0%
31 GOODS ACQUISITION EEC 6%
32 GOODS ACQUISITION EEC 9%
33 GOODS ACQUISITION EEC 13%
34 GOODS ACQUISITION EEC 19%
40 ACQUISITION RAW+PACKAG.MAT.DOMESTIC 0%
41 ACQUISITION RAW+PACKAG.MAT.DOMESTIC 6%
42 ACQUISITION RAW+PACKAG.MAT.DOMESTIC 9%
43 ACQUISITION RAW+PACKAG.MAT.DOMESTIC 13%
44 ACQUISITION RAW+PACKAG.MAT.DOMESTIC 19%
45 ACQUISITION RAW+PACKAG.MAT. 3RD COUN. 0%
46 ACQUISITION RAW+PACKAG.MAT. 3RD COUN. 6%
47 ACQUISITION RAW+PACKAG.MAT. 3RD COUN. 9%
48 ACQUISITION RAW+PACKAG.MAT. 3RD COUN. 13%
49 ACQUISITION RAW+PACKAG.MAT. 3RD COUN. 19%
50 ACQUISITION RAW+PACKAG.MAT. EEC 0%

© SAP HELLAS S.A. 20


Localization Process SAP ERP 6.0 Country Manual

51 ACQUISITION RAW+PACKAG.MAT. EEC 6%


52 ACQUISITION RAW+PACKAG.MAT. EEC 9%
53 ACQUISITION RAW+PACKAG.MAT. EEC 13%
54 ACQUISITION RAW+PACKAG.MAT. EEC 19%
60 VAT INPUT – EXPENSES 0%
61 VAT INPUT – EXPENSES 4,5%
62 VAT INPUT – EXPENSES 6%
63 VAT INPUT – EXPENSES 9%
64 VAT INPUT – EXPENSES 13%
65 VAT INPUT – EXPENSES 19%
66 VAT INPUT – NON DEDUCTIBLE EXPENSES 0%
67 VAT INPUT – NON DEDUCTIBLE EXPENSES 4,5%
68 VAT INPUT – NON DEDUCTIBLE EXPENSES 9%
69 VAT INPUT – NON DEDUCTIBLE EXPENSES 19%
70 OUTPUT TAX FOR SALES OF SERVICES 0%
74 OUTPUT TAX FOR SALES OF SERVICES 19%
75 VAT INCOME OTHER ACTIVITIES 0%
76 VAT INCOME OTHER ACTIVITIES 13%
78 VAT INCOME OTHER ACTIVITIES 19%
75 OUTPUT TAX FOR INCIDENTAL OCCUPATIONS 0%
78 OUTPUT TAX FOR INCIDENTAL OCCUPATIONS 9%
79 OUTPUT TAX FOR INCIDENTAL OCCUPATIONS 19%
80 OUTPUT TAX FOR SALES OF ASSETS 0%
81 OUTPUT TAX FOR SALES OF ASSETS 4,5%
83 VAT SALES ASSETS 9%
84 VAT SALES ASSETS 13%
85 VAT SALES ASSETS 19%
86 VAT INPUT FOR ASSETS 0% – NON DEDUCTIBLE
87 VAT INPUT FOR ASSETS 4,5% – NON DEDUCTIBLE
88 VAT INPUT FOR ASSETS 9% – NON DEDUCTIBLE
89 VAT INPUT FOR ASSETS 19% – NON DEDUCTIBLE
8E ASSET SALE 0% EEC
8X ASSET SALE 0% THIRD COUNTRY
90 GROUP 8 OUTFLOWS 0%
91 GROUP 8 INFLOWS 0%
98 VAT INPUT 0% - ON OCCASSIONS WITH NO TAX
99 OUTPUT TAX 0% - ON OCCASIONS WITH NO TAX
A0 OUTPUT TAX 0%
A1 OTHER GOODS ACQUISITION EEC 6%
A2 OTHER GOODS ACQUISITION EEC 9%
A3 OTHER GOODS ACQUISITION EEC 13%
A4 OTHER GOODS ACQUISITION EEC 19%
C0 OUTPUT TAX FOR SALES OF TRADING GOODS 0%
C1 OUTPUT TAX FOR SALES OF TRADING GOODS 4,5%
C2 OUTPUT TAX FOR SALES OF TRADING GOODS 6%
C3 OUTPUT TAX FOR SALES OF TRADING GOODS 9%
C4 OUTPUT TAX FOR SALES OF TRADING GOODS 13%
C5 OUTPUT TAX FOR SALES OF TRADING GOODS 19%
CE OUTPUT TAX FOR SALES OF TRADING GOODS 0% EEC
CX OUTPUT TAX FOR SALES OF TRADING GOODS FOREIGN 0%
D0 OUTPUT TAX FOR SALES OF OTHER SERVICES 0%
D1 OUTPUT TAX FOR SALES OF OTHER SERVICES 4,5%
D2 OUTPUT TAX FOR SALES OF OTHER SERVICES 6%

© SAP HELLAS S.A. 21


Localization Process SAP ERP 6.0 Country Manual

D3 OUTPUT TAX FOR SALES OF OTHER SERVICES 9%


D4 OUTPUT TAX FOR SALES OF OTHER SERVICES 13%
D5 OUTPUT TAX FOR SALES OF OTHER SERVICES 19%
DE OUTPUT TAX FOR SALES OF OTHER SERVICES 0% EEC

3.3 FI Master Files

Master data needed for Hellenization are structured into the following FI Master Files:
- G/L Accounts :Account type ‘S’
- Customers :Account type ‘D’ and Reconciliation
- Vendors :Account type ‘K’ and Reconciliation
- Fixed Assets :Account type ‘A’ and Reconciliation

Level Accounts within table J_1GGL link ‘S’ via their number, whereas Banks link ‘S’ via an
attribute in MF. Fixed Assets will be analyzed in a separate chapter devoted to AM Configuration.

3.3.1 G/L Accounts

In Greece the posting level accounts need the following fields to be updated in order to comply with
SAP standard procedures and the requirements of the localized reports.
SKA1 :G/L Accounts Master (Chart of Accounts)
SKA1-KTOPL :Company’s own Chart of Accounts
SKAT-TXT20 :G/L Account Short Text
SKAT-TXT50 :G/L Account Long Text
SKA1-GVTYP :Indicator that the account is a Profit and Loss statement account.

In Greece there are mainly two Ledgers. The General ledger and the Analytical ledger for
controlling. Some of the accounts in the General ledger are not necessary (obligatory) by the
CAGR. These accounts are used for the Material Management (MM) postings (e.g. cost of sales and
consumption).
For the P+L accounts of the General ledger the indicator ‘X’ is used. SAP recommends for the
special accounts used by MM other indicators (e.g. 1-9) in order to transfer their balances within a
different account balance than the ‘X’ because they should not be included in the Retained earnings.
The P+L account groups for G/L are:
60 - 69
70 - 79
81 - 85 and the special accounts used by MM
X : 4201000000

All P&L MM (2X.99) accounts are using Balance sheet closing account to 2X.99.99.9999 (debit or
credit) ie.
20.99.P&L closing account= 20.99.99.9999
21.99.P&L closing account= 21.99.99.9999
24.99.P&L closing account= 24.99.99.9999

SKA1-XBILK :Indicator that the account is a balance sheet account.


SKA1-KTOKS :The account groups proposed by SAP Hellas are the standard.
SKB1-WAERS :Always EUR

© SAP HELLAS S.A. 22


Localization Process SAP ERP 6.0 Country Manual

SKB1-MWSKZ :As per standard. SAP Hellas proposes the tax accounts to
have the >,< indicators.
SKB1-XKRES :It is necessary for the Greek reports except for the
reconciliation account type K, D.
SKB1-FSTAG :Field status group. We use the standard but, we would like to have the text
necessary in all postings. The problem is usually for the automatic postings.
SKB1-FDLEV :Planning Level
SKB1-XGKON :Cash Receipt Account/Cash Disbursement Account
SKB1-ALTKT :SAP Hellas proposes the sample account of the CAGR.

3.3.2 Customers

In Greece the following fields should be updated in order to have all the necessary data for the year
end sales and purchases reconciliation report.

KNA1-NAME1 :Name of the customer. Should be updated in Greek capital


letters.
KNA1-NAME2 :Name of the customer in English.
KNA1-NAME3 :Profession.
KNA1-NAME4 :Tax office.
KNA1-STRAS :Address (space) number.
KNA1-PSTLZ :Postal code.
KNA1-LAND1 :GR for Greek customers
KNA1-SPRAS :EL for Greek customers
KNA1-STCD2 :Local VAT registration number (9 digits)
KNA1-STCEG :Should be checked against Tax code 2 (EL+local VAT
registration number)
KNA1-AKONT :Reconciliation account.

For the profession and the tax office you can also use tables such as industry instead of profession
and region instead of tax office for the cases that a company uses coding.

Also International Address version is supported from Hellenization programs

3.3.3 Vendors

In Greece the following fields should be updated in order to have all the necessary data for the year
end Sales and Purchases reconciliation and confirmation reports.

LFA1-NAME1 :Name of the vendor. Should be updated in Greek capital letters.


LFA1-NAME2 :Name of the vendor in English.
LFA1-NAME3 :Profession
LFA1-NAME4 :Tax office
LFA1-STRAS :Address (space) number
LFA1-PSTLZ :Postal code.
LFA1-LAND1 :GR for Greek vendors
LFA1-SPRAS :EL for Greek vendors
LFA1-STCD2 :Local VAT registration number(9 digits)
LFA1-STCEG :Should be checked against Tax code 2 (EL+local VAT registration number)
LFA1-AKONT :Reconciliation account.

© SAP HELLAS S.A. 23


Localization Process SAP ERP 6.0 Country Manual

LFB1-REPRF :Check flag for double invoices

For the Profession and the Tax office we can also use tables such as Region instead of Tax office
and Industry instead of Profession for the cases that a company uses coding.

Also International Address version is supported from Hellenization programs

Note: Some vendors must be created twice under different account numbers because the
reconciliation account indicates if the invoices of the vendor should be included in the year end
confirmation reports. So, invoices of the same vendor will be posted in both accounts.

Note: One-time accounts (customers/vendors), by definition, are not F relevant master files.

3.3.4 Banks

Banks in Greece have codes that are classified to those related to house banks and banks of
customers and vendors:
a) House Banks are maintained in FI Customization menu. The fields depicted below should be
filled in :
T012-BANKS :Key for the country in which the bank is located.
T012-HBKID :ID for the house bank. Greek Bank codes consist of 3 digits and follow the
naming convention (BB) stored in table BNKA.

To maintain Bank accounts for each Bank some additional fields must be filled too.
T012K-HKTID :ID for account details. Bank Account codes is proposed to use the naming
convention (BBAA).
T012K-BANKN :Bank account number.
T012K-HKONT :G/L Account that will be updated. To prepare Bank Statement Postings, for
example, the following naming conventions for G/L Accounts should be
used:
38.03.BB.AA00 for main bank statement account.
38.03.BB.AA01 for interim G/L account Checks payable.
38.03.BB.AA02 for interim G/L account Checks receivable.
38.03.BB.AA03 for interim G/L account Interest.
T012K-WAERS :Currency.

b) Banks of customers and vendors need to be created within subsystems accounts


receivable and payable, respectively. They can be reached via the following menu path:
Accounting Financial accounting Accounts receivable / payable Master records Banks
Create
As far as the logic is concerned is the same with that of House banks. The only difference is
regarding the field - ‘BNKA-BNKLZ’ - of the account number that must be filled.
Note: Coding conventions for G/L accounts within Chart of Accounts CAGR should be followed, to
facilitate electronic bank statement posting.

3.4 A/R and A/P account groups

The account group is a classifying feature within the master record of the customer. The account
group determines:
- in which number range the customer account number should be;

© SAP HELLAS S.A. 24


Localization Process SAP ERP 6.0 Country Manual

- whether the number is assigned by the user or by the system;


- which specifications are necessary or possible in the master record.

In Greece, regarding accounts receivable, we create the following account groups:

3000 Domestic. customers


3001 Foreign customers
3002, 3003 Domestic customers from public sector
3395 Other debtors
3A00 Domestic branch offices
3L00 Domestic retail customers

In Greece, regarding accounts payable, we create the following account groups:

3500 Customs clearers


3501 Employees
5000 Domestic vendors
5001 Foreign vendors
5002 Greek state vendors
5D00 Domestic vendor dealers
5M00 Domestic vendor transporters

Each account group is assigned to one number range interval that is either numerical or
alphabetical. The number assignment can be either external or internal.Posting keys

3.5 Document types

The document type defines the following:

1. Number range of the document. Some document types could annually start from 1 and others
continue counting.
2. The account type that will be used (A, D, K, S, M).
3. In which journal the entry will appear.
4. Which is the Reverse Document Type.
5. Which Document Type is valid for Sales/Purchase Reconciliation report (MYF)

An example of placing in to (MYF).

Document Type Posting Key


Account Receivables Q1 01
Q3 11
Account Payables K1 31
K3 21

© SAP HELLAS S.A. 25


Localization Process SAP ERP 6.0 Country Manual

3.6 Field status group

Field status group defines the fields that will be displayed on the screen for posting. It also defines
which of these fields are mandatory, optional or suppress.

Field status GR01 includes the standard SAP field status group as well as Hellenization’s G900 for
analytical ledger.

When the implementation sets off the fields status group have all the fields optional. As this process
goes on the customization of fields occurs according to the customers’ requirements.

3.8 Special G/L indicators

Special G/L indicators change the standard flow procedure of special G/L transactions. The posting
is made to an alternative reconciliation account instead of the normal receivables account or the
liabilities.

Such an example is the receipt of receivable check or promissory note.

1. The receipt of receivable check or promissory note have the following steps:

1st line Posting Key (09) Special G/L (W: for checks) or (X: for promissory note)

2nd line Posting Key (15)

The (W) indicator assigns the receipt to the special reconciliation account 33.90.00.0000 and not the
normal reconciliation account 30.00.00.0000.

The (X) indicator assigns the receipt to the normal reconciliation account 31.00.00.0000 and not the
normal reconciliation account 30.00.00.0000.

The respective posting keys for special G/L entries are those that end to 9 (i.e. 09, 19, 29, 39).

3.8.1 Special GL for Customers

A Reverse down payment


D Failed post-dated cheques
G Guarantee
W Post-dated cheques
X Bill of exchange
Y Failed post-dated cheques

Special GL for Vendors

A Reverse down payment


W Bill of exch. Payable

© SAP HELLAS S.A. 26


Localization Process SAP ERP 6.0 Country Manual

3.9 Automatic account determination tables

Accounting documents coming from different modules (like MM, SD and AM) are automatically
transferred to the General Ledger in SAP ERP. Also, some documents are posted automatically
within financial accounting module. For example, after entering the tax code, the system makes the
necessary posting related to the tax account depending on the content of the tables in the
configuration. To enable these postings according to the accounts in the Greek Uniform Chart of
Accounts (CAGR), related accounts have been entered into various tables in the configuration.
Following is a list of such tables:

T030 (Standard Accounts Table)


Banking, which defines the posting keys for the bank transactions.
Balance Sheet, which lists account balances of assets, liabilities, and equity. The difference
between assets and liabilities equals the equity in the business, including any profit or loss since the
balance sheet was last reported.
Balance Sheet Preparation, which includes all the procedures for closing, at a specific date (the
balance sheet date), the fiscal year.
Taxes on Sales/Purchases include amount of sales tax, withholding tax, output tax, and so on, to
be posted and reported to tax authorities.
Exchange Rate Differences shows the difference that results from posting and matching a
payment in foreign currency at different exchange rates.
Goods/Invoice Received Clearing Account, where temporary entries are posted. This happens,
because of timing differences between business transactions.
Materials Management Postings(MM), which defines the MM posting keys.
Down Payments, where payments for a product or service have not been supplied or performed
yet.
Check/ Bill of Exchange, which specifies the posting keys for transactions of this kind.
Income Invoices, which define the posting keys for the vendor incoming invoices.

T074 (Special G/L Accounts)


In relation to Customer and Vendor Accounts:
Down Payment
Reserve for Bad Debt
Guarantee

T095 (Balance Sheet Accounts For Depreciation Areas)

3.10 FI Reporting

According to the Greek Books and Data Code Regulations (KBS) the following reports have been
delivered by SAP Hellas in order to comply to the law in terms of data related to General Ledger:

G/L and A/L, Year-End Journals


G/L and A/L Legal Trial Balance
G/L and A/L Trial Balance
G/L and A/L Ledger
G/L and A/L Summarized Ledger
Customer Trial Balance
Customer Ledger
Customer Financial Data

© SAP HELLAS S.A. 27


Localization Process SAP ERP 6.0 Country Manual

Vendor Trial Balance


Vendor Ledger
Vendor Financial Data
VAT reconciliation report
Sales and Purchases reconciliation report (MYF)
Vendors Withholding tax report
Day end cash control report
Chart of accounts list
Document printout
Year end customer balance
Year end vendor balance
Revaluation of Fixed Assets (See chapter 4)
Fixed Assets Register (See chapter 4)
Fixed Assets Transaction list (See chapter 4)
Investment Book (See chapter 4)
Customer, Vendor, Fixed Assets Lists
Lists to be stamped by tax Office
Checks Receivable Register
Greek Financial Statement
Checks payable w/ Payment advises
Trial balance in Magnetic Media

3.10.1 G/L and A/L Journal

The G/L and A/L Journal is the program report ‘J_1GJOURNAL’ that is designed specifically for
Greece. This report selects all FI postings of a specific posting date range. The selected documents
are presented on a list which depicts the following:

1 A Header per posting date. It shows both Debit and Credit balances of the last official run
posting date, as well as the number of printed page.

2 Lines per document. It includes information taken from tables BKPF (header) and BSEG
(line items), such as posting date, doc number, doc type, description of doc type, account,
description of the account, cost centre, posting key, etc. and
3 A Footer per posting date. It shows both new debit and credit amounts.

In case that postings of a date are shown on more than one pages, summarized Credit and Debit
amounts are transferred from the bottom of one page to the top of next one.

This program is controlled via the J_1GCONTROL table for maintaining official run dates, serial
numbering of documents and totals in terms of debits and credits. Also table J_1GJR_LN keeps the
association of official numbering of documents printed on the journal and the SAP document
number. Both tables are accessed through the menu J_1GJRMENU.

According to the Greek Books and Data Code Regulation:

A company may use as many Journals as needed after having them declared to the Tax office
responsible for auditing the Company.

© SAP HELLAS S.A. 28


Localization Process SAP ERP 6.0 Country Manual

SAP Hellas proposes that an efficient control is achieved at a minimum effort by the usage of the
following 3 journals: 1 General Ledger postings Journal, 2 Analytical Ledger postings Journal and
3 Year end Journal

All postings shown on a Journal should be numbered sequentially (At the beginning of the year, the
Journal should start from number 1)

Totals of a Journal corresponding to one date, in terms of Debit and Credit should be equal and
reconcile (exactly the same) to the totals of Debit and Credit shown on other 3 reports (Trial
Balance, Ledger and Summary Ledger) for the same posting date.

Document postings should not be done for dates that have already been included on the respective
journal.

Document postings can be done according to the latest possible date allowed by the law, which is
up to the 15th day of the posting month after the document has been received (so the period can be
up to 45 days).

Posting of documents should show at header or line item level the following: G/L account, type
transaction, text, relevant vendor/customer, and incoming or outgoing paper document number
(reference number).

There is also the option of performing the Opening document. In order for this to run the user has to
enter the number of document in J_1GOD_CTRL_V through J1GJRMENU.

FI Documents that contain area 1 accounts are shown on the normal journals for G/L postings.

A Special Journal is needed for year end postings for which the posting date 31/12/PrevYear is
mandatory. These postings are actually performed between the first of January till the end of March
of Next Year. No validation is needed in terms of posting date.

Analytical Ledger Journal (or Journals) should reconcile to the 3 reports for Analytical Ledger
(Trial Balance, Ledger and Summary Ledger) for the same posting date.

The following tables are needed for customizing of this program:

J_1GJOURNAL1 Journal type list (declaration of Journal Codes)


J_1GJOURNAL2 Journal Code Description
J_1GJOURNAL3 Journal Definition (Link of FI Document types to a journal Code)
J_1GCONTROL SAP table for controlling reports
J_1GJR_DT Description of document types for journals

J_1GJR_PK Posting keys description for journals


J_1GJR_LN Link document number /journal number

The customizing menu of the journal is reached through transaction code J_1GJRMENU but
it is also contained into the Greek specific IMG.

Correct Standard Configuration for FI posting and strict Posting Procedures are essential for
complying to the Greek Books and Data regulations.

Since a text is obligatory for any line item shown on the Journal describing the reason of the
particular posting, the posting key’s description is used in case a user has left the relevant text field

© SAP HELLAS S.A. 29


Localization Process SAP ERP 6.0 Country Manual

blank. Also, header text is shown as posted and is replaced by document type description if not
posted.

The field BKPF-BELNR is shown on the Journal as a remark that is used not only for retrieving
purposes but also for filing the original incoming paper documents (e.g. Vendor Invoices) and the
copies of the outgoing paper documents (e.g. Customer Invoices).

The field BSEG-KOART is essential for determining the Vendor/Customer related to the Business
Transaction. SAP Hellas recommends that users should avoid including more than one
Vendors/Customers within one document. The line item of the document may be found in G/L
ledger, Customer Ledger, or Vendor Ledger.

The field BKPF-XBLNR is essential for determining the relative Paper incoming or outgoing
document (e.g. invoice no). SAP Hellas recommends that users should avoid including more than
one paper incoming or outgoing documents within one SAP document. This field is used in
conjunction to the BSEG-BELNR for showing the original paper documents to the auditors as well
as to show the document on the screen.

All business transactions are represented by documents having a unique document number giving at
posting time. Journal numbering is given at printing time after official run and is not maintained on
the Data base, since it is not required to be shown on any other report than Journal.

If a Journal has run in official mode, total debit, credit amount and last sequential number used are
stored in table J_1GCONTROL. This information is used next time the journal is run, because then
it is printed as a carry forward balance at the top of the report.

In case of rerunning after an official run (e.g. due to paper stuck on printer) J_1GCONTROL data
should be maintained manually.

Since a) Posting of documents should not be done for posting dates that have already been depicted
on the respective journal and b) Postings should not mix G/L and A/L accounts validations must
be set up in terms of Header and Line item Call up points checking the following:

Header Call up Point: Posting date of a document should be in the range from max. Last Official
Run Date of the respective Journal J_1GCONTROL up to Current date (SY-DATUM).

Line Item Call up Point: Postings comprising accounts BSEG-HKONT starting from 9 (Analytical
Ledger Accounts) should not be found in a document that has not a document type defined in the
table of the valid for Analytical Ledger Document Types as well as the opposite : Postings
comprising accounts BSEG-HKONT not starting from 9 (Analytical Ledger Accounts) should not
be found in a document that has a document type defined in the table of the valid for Analytical
Ledger Document Types.

Note: Noted items do not create two line items of debit and credit and therefore, are not depicted on
the Journal. Also parked items and automatically created clearing documents without line items are
not included in the journal.

3.10.2 Legal G/L and A/L Trial Balance


The G/L and A/L trial balance is the program report ‘J_1GTBGL0 ‘ that is legally required by the
Greek tax authorities. It gives insight in the financial flow (summarized per period) within the
company, both on posting and non-posting account level. An official version of the G/L and A/L

© SAP HELLAS S.A. 30


Localization Process SAP ERP 6.0 Country Manual

trial balance has to be produced for every account (including all levels) for every posting period.

Periodically, i.e. each trimester, the accounting department will request a G/L and A/L trial balance
for the past fiscal periods. It is based on the table SKA1, SKB1 as well as the tables J_1GGS and
J_1GGL.

If there is a need to put more selection criteria and therefore read from an extended ledger the name
of the extended ledger should fill the relevant field.

The user can select to have sums on specific digits of the account and output the results in either the
Company chart of accounts or in the alternative chart of accounts or in the group chart of accounts.

Furthermore the user can input a range of accounts specified in the company chart of accounts or in
the selected for output chart of accounts.

There is also the option of performing the Opening document. If this is required by the company,
then the opening document filled by the user, although it is posted in the reporting periods, it is
included in the previous period section (this must be done in accordance with the official journal).
In order for this to run the user has to enter the number of document in J_1GOD_CTRL_V through
J1GJRMENU.

The results for the selected period (either fiscal period range or posting date range) are presented on
a list which depicts the following columns:
Debit total of balance carry forward plus debit total of the periods before the period selected
by the user.
Credit total of balance carry forward plus credit total of the periods before the period
selected by the user.
Debit balances of balance carry forward plus debit balance of the periods before the period
selected by the user.
Credit balances of balance carry forward plus credit balance of the periods before the period
selected by the user.
Debit total of the reporting period
Credit total of the reporting period
Total debit up to the reporting period
Total credit up to the reporting period
Debit balances at the close of the reporting period
Credit balances at the close of the reporting period

The sorting is alphabetically on level and account number. When the report fills out more than one
page, the pages will contain carry forward totals, giving the cumulative total for each column
printed. The next consecutive page will contain these same totals at the top of the page. This same
cumulative total will be printed as report total at the end of the general ledger trial balance as well
as the totals per account level.

This program is controlled via the J_1GCONTROL table for maintaining official run dates and page
counters for official runs in pre printed paper. This table is accessed through the menu
J_1GJRMENU.

© SAP HELLAS S.A. 31


Localization Process SAP ERP 6.0 Country Manual

In case of reprinting after an official run (e.g. due to paper stuck on printer) J_1GCONTROL data
should be maintained manually.

3.10.3 G/L and A/L Trial Balance

The program described above has 2 layout options official and a second one.
The differences between these are:

In the non official layout opening document functionality is not offered as described previously.

Moreover, the first 4 columns of this report are performed in a different way in comparison with the
J_1GALTB report. These columns contain the following information:

Debit total of balance carry forward


Credit total of balance carry forward
Debit total of previous periods (up to the one selected by the user)
Debit total of previous periods (up to the one selected by the user)

The first two columns can be displayed as debited or credited Balance carry forward with the
appropriate sign according to user selection.

This functionality is performed for the 2 last columns of the report also (new balance) based on
selection screen choices.

3.10.4 G/L and A/L Ledger

This is a report program ‘J_1GGL000‘ that shows line items for all posting accounts. It is based on
the table BSIS as well as the ones SKA1, SKB1 and SKAT. This report includes all account line
items except for those of customers and vendors. Reconciliation accounts balances of customers and
vendors are displayed on the ledger without any particular customizing.

It is recommended by SAP Hellas to use line item display to all accounts that are not reconciliation
accounts such as vendors and customers for which specific ledgers are produced.

Standard SAP is very rich in terms of reporting related to line items, using very efficient techniques
like work-lists, open items etc.

3.10.5 G/L and A/L Summarized Ledger

This is a report program ‘J_1GSL000’ that shows monthly debits and credits per date at level 1-4
accounts. It is based on the table BSIS as well as the tables J_1GGS, and J_1GGL. This report
includes all account line items except for those of customers and vendors. Reconciliation accounts
balances of customers and vendors are displayed on the ledger without any particular customizing.
The report is printed officially at the end of following month and is reconciled against journal and
trial balance. Table J_1GCONTROL keeps track of the last period and the page numbering that the
report was officially run. Table can be reached through transaction J1GJR9.

© SAP HELLAS S.A. 32


Localization Process SAP ERP 6.0 Country Manual

3.10.6 Customer Trial Balance

This is a report program ‘J_1GTBDE0’ that shows period balances for all customer accounts It is
based on the table KNC1 as well as the tables KNA1, KNB1. Thus, it should reconcile to the
balances of the relevant customer reconciliation accounts shown on the G/L trial balance. In case
special G/L transactions are used, the customer must create special purpose ledgers as described in
program documentation.

3.10.7 Customer Ledger

This is a report program ‘J_1GCL000’ that shows line items for all posting customer accounts. It is
based on the table BSID as well as the tables KNA1, KNB1 and KNC1. This report includes all
normal line items related to customers as well as the special G/L transactions. It should, also,
reconcile to the balances of the relevant customer reconciliation accounts shown on the G/L trial
balance.

3.10.8 Customer Financial Data

This is a report program ‘J_1GFD_D’ which shows in a detailed list all the information existing in
the master data of customers for a specific company code such as name, profession, reconciliation
account etc.
In this list one time customers or customers marked for deletion can be included or excluded
according to user selections.

3.10.9 Vendor Trial Balance

This is a report program ‘J_1GTBKR0’ that shows period balances for all vendor accounts. It is
based on the table LFC1 as well as the tables LFA1, LFB1. It should reconcile to the balances of the
relevant vendor reconciliation accounts shown on the G/L trial balance.

3.10.10 Vendor Ledger

This is a report program ‘J_1GVL000’ that shows line items for all posting vendor accounts. It is
based on the table BSIK as well as the tables LFA1, LFB1 and LFC1. This report includes all
normal line items related to vendors as well as the special G/L transactions. It should reconcile to
the balances of the relevant vendor reconciliation accounts shown on the G/L trial balance. In case
special G/L transactions are used, the customer must create special purpose ledgers as described in
program documentation.

3.10.11 Vendor Financial Data

This is a report program ‘J_1GFD_D’ which shows in a detailed list all the information existing in
the master data of vendors for a specific company code such as name, profession, reconciliation
account etc.

In this list one time vendors or vendors marked for deletion can be included or excluded according
to user selections.

© SAP HELLAS S.A. 33


Localization Process SAP ERP 6.0 Country Manual

Note : The above programs (Vendor/Customer Trial Balance and Ledger) read data of ‘regular’
plus special GL transactions on customers and vendors. Because no standard table is delivered with
the system that keeps track of period totals per special GL transaction, a special purpose ledger
table is recommended to be installed in order to be able to retrieve summarized data per period for
these special GL transactions.

3.10.12 VAT Reconciliation Report

This is a report program J_1GFPAREPORT that shows all the advance tax report information as
well as a list of all documents that the tax amount differs from the automatically calculated one. It is
used monthly for reconciling tax amounts that need to be shown on the tax office relevant to VAT.

3.10.13 Sales and Purchases reconciliation report (MYF)

According to the Greek Books and Data Code Regulation every company should submit a diskette
or tape that includes a file showing the base amounts that are more than 300 EUR per customer and
vendor in a pre-defined format comprising of 5 types of records.

Since the output is a file of comprising data posted in a year, possibly containing data not
appropriately posted, the sales and purchases reconciliation report is produced by a set of programs
that are performing in the 5 following phases:

1 Master data check phase: During this phase data found on customer and vendor master files
(KNA1, KNB1, LFA1, LFB1) are checked in terms of VAT tax code, profession, tax office etc.
This check occurs only for customers and vendors that are to be submitted in the diskette. An
exception report is produced for all missing or incorrect data.

2 Calculation of amounts phase: During this phase amounts found on customer and vendor
line items BSIK/BSAK and BSID/BSAD are rejected, added or subtracted per customer or vendor.
This check occurs only for customers and vendors that are to be submitted in the diskette. Totals
per customer and vendor are stored on a maintainable table.

3 Edit phase: During this phase data containing totals per customer and vendor that are stored
on a maintainable table. This table can be edited in terms of Insert, Update or Delete.

4 Load phase: During this phase data coming from systems other than SAP regarding totals
per customer and vendor (in the form of the standard format Greek Books and Data Code
Regulation) are loaded and stored on the maintainable table – it is a mass insert.

5 Print phase: During this phase data regarding totals per customer and vendor that are stored
on the maintainable table are printed according to the format described by the Greek Books and
Data Code Regulation.

Both customer and vendor master file creation rules as well as posting rules regarding incoming and
outgoing invoices, credit notes and cancellation notes are essential for sales and purchases
reconciliation report.

SAP Hellas proposes the following:

© SAP HELLAS S.A. 34


Localization Process SAP ERP 6.0 Country Manual

Master File Rules

Customers and vendors that are to be submitted in the sales and purchases reconciliation report
should be only regular vendors with data from tables KNA1, KNB1 and LFA1 and LFB1. One
time customers and vendor are not included.

Customers and vendors that are not to be submitted in the sales and purchases reconciliation report
should have different reconciliation accounts from those that are to be submitted as well if possible
a different account group since some fields are mandatory in their case.
Customers and vendors that are to be submitted in the sales and purchases reconciliation report
should have country GR and their name should be written in capital letters according to their
official name that is shown on the invoice - Latin or Greek letters can be used.

Customers and vendors that are to be submitted in the sales and purchases reconciliation report
should have all relevant text fields needed (e.g. address) stored on the same field - preferably the
one proposed by SAP Hellas - in Greek capital letters.
The peripheral tables linked to fields such as profession in the field ‘industry’ or tax office in the
field ‘region’, should be updated with Greek descriptions in capital letters.

Also, posting rules for line items of customers and vendors that are to be submitted in the sales and
purchases reconciliation report should be followed.

The postings of documents related to customer and vendor for the sales and purchases reconciliation
report comprises of the following three categories: invoices, credit notes, cancellation notes that
correspond to specific FI document types.

According to the Greek law:

Invoices add number of invoices, add total amount


Cancellation of Invoices subtract number of invoices, subtract total amount
Credit notes add number of invoices, subtract total amount
Cancellation of credit notes subtract number of invoices, add total amount

Documents of the above mentioned categories should be posted in currency EUR and in regural
calendar year periods (1/1 - 31/12 ) containing one and only one customer or vendor and comprising
of non special G/L transactions.

Base Amount is calculated in the most complicated situation (e.g. including “withholding” tax, and
more than one expense or revenue line items by subtracting from the payable amount found in
BSIK/BSAK or BSID/BSAD) the total of taxes found in table BSET and is added or subtracted in
case it is more than 300 EUR.

Special care should be given to the following “invoices”:

Documents that are posted through invoice verification


Documents that are posted through billing
Documents that are posted for employees expense reports
Documents that include withholding taxes
Documents that are posted for customs
Documents that are posted for loading trucks

Documents that are posted through invoice verification:

© SAP HELLAS S.A. 35


Localization Process SAP ERP 6.0 Country Manual

Documents that are posted through invoice verification should be assigned to appropriate document
types that are distinguishing the cases of invoices and credit memos.

Documents that are posted through billing:


A user exit is needed for assigning different document types in case of invoice or credit memo.

Documents that are posted for employees expense reports:


Employees expense reports should be posted according to the following rules:

Employee master files should be defined in the vendor master file.

Employee business transactions regarding payments are normal vendor payment transactions - the
payment program can be used.
The posting should be to debit ‘employee’ and credit ‘cash’.

The employee’s expense report has attached invoices that should be split in two categories: a) those
that affect the sales and purchases reconciliation report and b) those that do not affect it.

Employee’s expense report is posted as following:

Debit expenses for the amount of the invoices that do not affect the sales and purchases
reconciliation report should be posted as employee invoices.
Debit of expenses account for the amount of each invoice that affects the sales and purchases
reconciliation report and credit each vendor.
Credit employee and clear the vendor invoices relevant to sales and purchases reconciliation report.

Documents that include withholding taxes:


Special care should be given in these postings in order to be able to determine base amount by
subtracting vendors from payable amount all taxes defined as sales and purchases.

Documents that are posted for customs:


Special care should be given in these postings since the customs vendors document include
expenses that are not to be assigned to him. A proposed solution is to post this business transaction
by posting two documents with two different document types.

The first document for the amount of the invoice that affects the sales and purchases reconciliation
report of the customs vendor relevant document type DT1.
(Debit Expenses - Credit Customs Vendor)
The second for the amount of the invoice that do not affect the sales and purchases reconciliation
report of the customs vendor relevant document type DT2.
(Debit Expenses - Credit Customs Vendor)

Documents that are posted for loading trucks:


In case of a monthly summarized report posting, the system cannot determine the number of
invoices. In this case the editable entry of these vendors should have correct
amount but wrong number of invoices (e.g. 12 instead of 10.000). This entry should be maintained
manually.

Posting rules for invoices, credit memos and cancellation notes:

The posting of invoice documents comprises of the following four categories: invoices, credit
notes, cancellation notes for invoices (Reverse posting), cancellation notes for credit notes (Reverse

© SAP HELLAS S.A. 36


Localization Process SAP ERP 6.0 Country Manual

posting). Each of the above categories corresponds to a different document type (field BKPF-
BLART).

The documents with posting date 31/12/XX (field BKPF-BUDAT) and period 13 (field BKPF-
MONAT) correspond to a specific document type. This is the document type which is printed on
the Journal and on the Sales and Purchases reconciliation report.

In Greece, it is recommended by SAP Hellas the reference document (field BKPF-XBLNR) to be


filled with the invoice number written on the original invoice document.

SAP Hellas proposes that all the posting documents should comprise of only one vendor or
customer line item.
An exception is the posting which refers to documents with instalments. In this case, more than one
line items are created for the same vendor.

SAP Hellas proposes that invoices should not include line items with special G/L indicators (field
BSEG-NEWUM).

A base amount is calculated in the most complicated situation (i.e. including “withholding “ tax,
and more than one expense or revenue line items) by subcontracting from the payable amount found
in BSIK/BSAK or BSID/BSAD the total of taxes found in the table BSET and is added or
subtracted in case it is more than 300 EUR.

In Greece, the Text (field BSEG-SGTXT) must be a required field for all the line items, because it
is legally required to be printed on the journal.

An exception is the line items which are created automatically. For these line items, the text printed
on the journal is the description of the related posting key.
Using the tables V_T053 and TTXID, Sap Hellas recommends to be set standard texts as a proposal
for each category of documents.

Posting of documents between the A/R sub-ledger and the A/P sub-ledger (transfer of amounts
between vendors and customers) is only permitted for line items of customers and vendors that are
not submitted in the sales and purchases reconciliation report.

The menu for customizing and creating the diskette of purchases and sales reconciliation is J1GM.

3.10.15 Vendors withholding tax forms report

According to the Greek Books and Data Code Regulation: a) every company should yearly submit
to each vendor a certificate that shows the withheld tax at their between transactions and b) every
company should yearly submit a summary report of withheld tax amounts of vendors that had
transaction with. The above certificate that confirms the withholding tax is used by the vendor for
his income tax declaration. The respective report program is called ‘J_1GWTCP‘.

Since the output is a printout comprising of data posted in a year possibly containing data not
appropriately posted the vendors withholding tax forms report is produced by a set of programs that
is performing in the 4 following phases:

1 Master file data check phase: During this phase data found on vendor master files (LFA1,
LFB1) are checked in terms of VAT tax code, profession, tax office and so on. This check occurs
only for vendors that are to be submitted in the file.

© SAP HELLAS S.A. 37


Localization Process SAP ERP 6.0 Country Manual

2 Calculation of amounts phase: During this phase the amount found on vendor line items
BSIK/BSAK are rejected, added or subtracted per vendor. Totals per vendor and withholding tax
account are stored on a maintainable table.

3 Edit phase: During this phase data containing totals per vendor and withholding tax account
that are stored on a maintainable table can be edited in terms of Insert, Update or Delete.

4 Print phase: During this phase data regarding totals per vendors, stored on the maintainable
table are printed on a form.

A control table is needed for declaring per company code the G/L accounts that are relevant to
withholding taxes.

Master File Rules

Vendors that are to be submitted in the withholding tax form report should be regular vendors with
data in LFA1 and LFB1 only (no one time vendors).

Vendors that are to be submitted in the withholding tax form report should have different
reconciliation accounts from those that are not to be submitted.

Vendors that are to be submitted in the withholding tax form report should have country GR and
their name should be written in capital letters according to their official name that is to be shown on
the invoice (Latin or Greek letters can be used).

Vendors that are to be submitted in the withholding tax form report should have all relevant text
fields needed (e.g. address) stored on the same field (preferably the one proposed by SAP Hellas)
in Greek capital letters and the peripheral tables linked fields updated with Greek descriptions in
capital letters (e.g. profession in the field Industry or Tax Office in the field region).

Posting rules for line items of vendors that are to be submitted in the withholding tax form report:

The postings of documents related to vendors that are to be submitted in the Withholding tax form
report comprises of the following three categories: invoices and credit notes that correspond to
specific FI document types.

Document types that correspond to each of the above mentioned categories should be different since
Invoices add amount and Credit Notes subtract amount.

Documents of the above mentioned categories should be posted in currency EUR and in regular
calendar year periods (1/1 - 31/12 ) containing one and only one vendor and at least one G/L
account that is relevant to withholding taxes.

Documents of the above mentioned categories should not be any special G/L transactions.

Base Amount is calculated in the most complicated situation (e.g. including “withholding” tax, and
more than one expense or revenue line items) by subtracting from the payable amount found in
BSIK or BSAK the total of taxes found in table BSET and is added or subtracted.

Withholding tax amount is calculated per G/L account regardless of how it is found on the
document (automatically or manually).

© SAP HELLAS S.A. 38


Localization Process SAP ERP 6.0 Country Manual

The menu of customizing and printing of the reports is the J1GV. The proposed layout of
Withholding tax certificate is named J_1G_WTC.

3.10.16 Day end cash control report

This is a report program ‘J_1GFICHL0’ that allows control of a cashier. It reads tables BKPF and
BSEG and respective New G/L Tables.

3.10.17 Chart of accounts list

There is a report program ‘J_1GCOA_TREE’ which gives a list of G/L or A/L accounts. The
above program includes two options, to give this list a) per company code and b) chart of accounts
and gives the descriptions in 2 languages (Greek and English) provided that all level accounts and
posting accounts have been maintained in both languages.

3.10.18 Document printout


The main program for printing FI documents is ‘J_2GPFI ’. This program is executed through
multiple selection options in order to make document searching more specific. The document
selection criteria are the following:

Print task code


The print task code is the refinement of a Logical paper. It belongs to a logical paper and
specifies which printer and layout set to use as well as the numbering of the printed
document .
The maintenance of FI logical papers is taking place in J_2GLPDOCSFI table.
The assignment of FI logical papers to FI documents is defined in J_2GLPFI table. In this
table every logical paper is allocated to the desired document types, posting keys and G/L
accounts in order the document selection criteria for the logical papers to be defined.
Company code
User
Fiscal year
Document number
Document type
Posting date

The user has the ability to print immediately the selected documents or create a spool request or
even have a print preview of the documents to be printed.

There is also a report program ‘J_1GFISA’ which gives a printout of the SAP document, so called
FISA. This printout is attached to the original document and is mainly used for filing.

3.10.19 Year end customer balance

There is a report program ‘J_1GCUST_VAL’ which gives only the year end balance of each
customer. This report shows the valuated total per each customer.

3.10.20 Year end vendor balance

© SAP HELLAS S.A. 39


Localization Process SAP ERP 6.0 Country Manual

There is a report program ‘J_1GVEND_VAL’ which gives only the year end balance of each
vendor. This report shows the valuated total per each vendor.

3.10.21 Trial balance in Magnetic Media

In the end of the fiscal year, according to the Books and Data Code Regulations, every company in
Greece has the obligation to submit to the tax authority a file with the G/L trial balance. The
program ‘J_1GTBAC0’ downloads the G/L trial balance in an ASCII file, ready for submission or
further processing. The program also prints the submission form to the Tax Office.

3.10.22 Printing of Pre-numbered tax-authorized forms

All tax- authorized reports such as journals, summarized ledger report, warehouse book report are
printed on pre-numbered paper. Program ‘J_1GLBPPC’ is created for printing of legal books
headers for submitting to tax authorities prior to printing reports. The printout contains company
code address data as well as a header title and page number.
The company code address data and the way this data appear in the header of the legal books is
customized in the J_2GFIELDV table.

The tables for this customizing are the following:

‘J_2GFMC’ for companies


‘J_2GFMD’ for customers
‘J_2GFMK’ for vendors

3.12 Post dated checks receivable management

Since Release 4.70 there is functionality available which covers the use of Post dated cheques
more extensively. SAP Hellas suggests the use of this functionality. For more info please refer
to std SAP Help on Bill of Exchange usage for Turkey. Alternatively you can follow the
approach described below with limited functionality.

Post dated checks receivable is a common way of customers incoming payments. These are normal
bank checks that their expiration date is in the future. These checks are delivered to the company at
a given date by which they are posted according to the Greek legislation and since their expiration
date is on the future, the document date has to be one after the posting date, and it is used in order to
efficiently calculate days in arrears for a customer.

A customer who pays with post dated checks delivers to the company more than one post dated
checks, at once, that generally belong to different banks. Each post dated check has a lot number but
most of the companies assign to each check an internal sequential number that corresponds to the
SAP document number.

The company keeps the post dated checks on a portfolio until their expiration date. This means that
every day deposits the checks of a specified set of banks to house banks together with an order to
put the total amount to a house bank account.

In case a check cannot be paid by the house bank (because the customer’s account is not
replenished with the adequate amount) the house bank sends back to the company the post dated
checks that meet this problem.

© SAP HELLAS S.A. 40


Localization Process SAP ERP 6.0 Country Manual

Normally, the company negotiates with the customer who in most of the cases replaces the bad post
dated check with a new one.

CONFIGURATION OF POST DATED CHEQUES

Transaction OBYN

Start from A/R module . Assign for special G/L ‘W’ the alternative customer account (i.e.
30.00.00.00.00 to 33.90.00.00.00). Under properties the posting keys relevant to W are created. The
standard system provides 09 for debit and 19 for credit.

Transaction OBYH

Define the posting keys needed for usage (collection).

Transaction OBYK

Assign for each bank, the special account needed for postings on bank transactions. This G/L
account must be open item managed and will serve as intermediate account for posting the transfer
of post dated from the company to the bank when the post dated check is due for collection.(i.e.
cagr, 38.03.00.00.00.00, I, W,38.01.00.00.00).

TRANSACTIONS FOR POSTED DATED CHEQUES RECEIVABLE

Transaction F-36

The payment of customers by post dated check is recorded by bill of exchange->payment, The
necessary data for entry is:

SAP FIELD DESCRIPTION ASSIGN


BKPF-BLDAT DOCUMENT DATE POST DATED CHEQUE DUE DATE
LINE 1
BSEG-BSCHL POSTING KEY 09
BSEG-KUNNR ACCOUNT CUSTOMER ACCOUNT
BSEG-UMSKZ SPECIAL G/L W
BSEG-WRBTR AMOUNT CHEQUE AMOUNT
BSEG-SGTXT TEXT TEXT
BSEG-ZFBDT CHEQUE DUE DATE POST DATED CHEQUE DUE DATE
BSED-WBZOG DRAWER NAME OF CHEQUE ISSUER
BSEC-BANKL BANK KEY BANK CODE NUMBER
BSEC-BANKN BANK ACCOUNT NO CHEQUE LOT NUMBER
LINE 2
BSEG-BSCHL POSTING KEY 15
BSEG-KUNNR ACCOUNT CUSTOMER ACCOUNT
BSEG-WRBTR AMOUNT AMOUNT
BSEG-SGTXT TEXT TEXT

The transaction is the following:


document type: DZ

© SAP HELLAS S.A. 41


Localization Process SAP ERP 6.0 Country Manual

09W customer amount


15 customer amount

Transaction F-34 or FBWE

Transaction F-34 is used in order to post the transaction of collection to the bank of one customer’s
post dated checks.
Transaction FBWE is used in order to control all of post dated checks posted to account (i.e.
33.90.00.00.00) by due date. Via transaction FBWE is possible to:
select post dated checks to submit to a bank for collection
print the necessary papers for bank submission
post automatically the transaction

The program SAPMFBWE is used with the following selection :

DESCRIPTION ASSIGN
COMPANY CODE COMPANY CODE
BILL /EXCHANGE ACCOUNT 33.90.00.0000
DUE FROM RANGE OF CHEQUES DUE DATE

Select the check for collection


Push bottom ‘ALLOCATE HOUSE BANK’ and then ‘ALLOCATE BILL/EXCHANGE
DIRECTLY TO BANK’
Enter in field ‘BILL/EXCHANGE USAGE ‘ , ‘Collection’
Enter Bank Details

DESCRIPTION ASSIGN
HOUSE BANK ID HOUSE BANK
ACCT ID HOUSE BANK ACCOUNT ID

Press ‘Posting parameters’


Correct Posting & Presentation date if necessary and press SAVE .
In the window appearing press ‘Start immediately’ and ENTER.
The system creates a batch input session and after running this session the following FI document is
created:
document type: DA

40 bank account amount

50 bank collection account amount

Transaction F-20 or F.93

Via transaction F-20, a document is posted that reverses customers liability of the post dated check
cleared from the bank. Transaction F.93 selects the post dated checks submitted to bank for
collection and posts the same document automatically.

The program used is RFWOBL00 with the following selection :

DESCRIPTION ASSIGN

© SAP HELLAS S.A. 42


Localization Process SAP ERP 6.0 Country Manual

DESCRIPTION ASSIGN
COMPANY CODE COMPANY CODE
G/L ACCOUNT 33.90.00.0000
BILL/EXCHANGE POSTING x
POSTING DATE OF POSTING POSTING DATE
DOCUMENT DATE OF POSTING DOCUMENT DATE
BILL/EXCHANGE DUE DATE DUE DATE OF CHEQUES
BILL/EXCHANGE USAGE I (Collection)

Under the ‘Posting parameters’ tab user can select whether to stimulate the procedure (test run) or
create batch input session or even post immediately (productive run).

The document created is the following:


document type: DA

40 bank collection account amount


19W customer amount

Post Dated Checks Reporting

It is common practice to print a report for controlling the flow of post dated checks. That is to be
able to trace transactions and the status of each check. The program prints a list of post dated checks
sorted by: due date and customer number. This program is J_1GFICPD0.

Special care should be given since a possible deviation from the standard business transactions is
needed for the following cases:
check is exchanged by a new one before posting collection
check is exchanged by a new one after posting the collection
check is exchanged by cash before posting collection
check is exchanged by cash after posting collection
check is registered as ‘failed’ by the bank
check is registered as ‘non collectable’ by the bank and returned to the company. The same
check is selected again for collection.

3.13 Statistical Postings for non EEC imports

Incoming invoices from non EEC countries in foreign currency, need a special treatment for
Greece, since they require an extra statistical posting to group 0 accounts with a specific month rate
that is predetermined by the Government (Previous month last Wednesday’s rates).

Selection criteria for these postings are: valid documents which include all invoices that have a
vendor from non EEC country and are posted in an non EEC foreign Currency (e.g. GBP,USD etc.)

This requirement is not covered through any of the delivered programs.

3.14 Payment procedures

3.14.1 Payment Program Configuration for the Sample Company

© SAP HELLAS S.A. 43


Localization Process SAP ERP 6.0 Country Manual

SAP ERP system provides the payment program already customized according to different
countries’ requirements. The payment program has also been customized for the sample Greek
company ‘GR01’.

In the ‘All Company Codes’ and ‘Paying Company Codes’ sections data is entered for ‘GR01’.
In the ‘Payment Method/Country’ section, two sample payment methods ‘1’ for daily checks and
‘0’ for bank transfers are proposed for Greece and should be customized.
In the ‘Payment method/Company code’ section same payment methods are defined for ‘GR01’
company code.
In the ‘Bank Selection’ section, definitions are given for the two main banks for ‘GR01’ company
code.
For the two main banks, available amounts are defined with ranking order according to the payment
methods. On the other hand the accounts at these banks are assigned to the related accounts in chart
of accounts.

The following significant issues regarding Greece are related to the payment program and
specifically the process of issuing outgoing checks:

Checks in Greece are printed on a special pre-printed paper that is unique for every company. This
paper is shown for confirmation to the banks and after approval an interval of lot numbers is given
to the company by each bank. Bank lot numbers for checks include a last digit after the lot number
that is a check digit.

Checks that are printed via the payment program or the post and print form transaction, in order to
be submitted to Greek banks should present the amount in Greek words.

The standard table has been filled with the words used for transforming an amount in EUR in Greek
words. (capital letters were used).

Since Bank lot numbers for checks include a check-digit after the lot number that generally is
calculated differently per bank account, table J_1GCD has been specifically designed to be used in
order to allocate every bank account to a calculation procedure for the check digit. Since the
introduction of EUR as official currency, this has been simplified having one common calculation
procedure.

A special printing program has been developed in order to allow the outgoing checks printing.

Special parameters have been defined for this printing program.

Payment program - Printing of checks

In Greece the payment program is used as the standard SAP procedure. All the changes refer to the
printing program. These changes are mentioned below:

1. Print program for checks: J_1GPMT3V

This print program refers to the payment method ‘1’ and has the following include:

Include: J_1GPN13V

© SAP HELLAS S.A. 44


Localization Process SAP ERP 6.0 Country Manual

This include contains routines for the calculation of the check digit following the lot numbers given
by each Greek bank. Routine selection is achieved via table ‘J_1GCD’ which contains the following
fields:

Bank ID
Company code
Bank account ID (without slashes and with zeros in front of the account number)
Current check lot (field which is being maintained by the program)
Current check digit (field which is being maintained by the program)

c) Printing of numbers in Greek words is achieved via the Spell amount function module
(LF017F01) which uses the table ‘T015Z’ which contains the Greek descriptions for the amount on
the checks. See SAP Note 398681 for more info.

The print program for checks J_1GPMT3V uses the sample form J_1GCHECK specially prepared
for Greek companies.

3.14.2 G/L Account checks

Two more programs exist for printing G/L account checks :

‘J_1GCKCP0 ’ is a program used to create and print G/L account manual checks for
existing payment documents with the limitation that the document should have only one line
item credited , the G/L account of the bank.

‘J_1GCKPR0 ’ is a program used to print manually created checks with the same limitation
mentioned above.

3.15 Year end FI closing procedures

Year end procedures for Greece apart to the technical settings supported by standard SAP
procedures (e.g. opening of periods etc.) should be performed specifically for Greece.

There is a date range of approximately 15 days in the beginning of the fiscal year for which the
following 3 different kind of postings should be performed:

1 Regular postings for previous year (e.g. Vendor Invoices)


2 Regular postings for new fiscal year (e.g. Cash transactions, sales etc.)
3 Year end postings for previous year (31/12/previous year period 13)

There is a date range of approximately 3 months starting 15 days after the beginning of the fiscal
year for which the following 2 different kind of postings should be performed:

1 Regular postings for new fiscal year (e.g. Cash transactions, sales etc.)
2 Year end postings for previous year (31/12/prevyear period 13)
For these date ranges special care should be given for document type usage in terms of validations
as well as fulfillment of 3 different Journals Printing (a) Normal for previous year, (b) Normal for
next year and (c) Year end journal for previous year.

© SAP HELLAS S.A. 45


Localization Process SAP ERP 6.0 Country Manual

At the end of January (regardless of the fiscal year variant a Greek company uses) vendors
withholding tax forms report should be printed in order to be mailed to the relevant vendors for the
submission of their own tax report.

3.16 Year start FI opening procedures

When the balances of the previous year have been defined and updated, the following course of
action must be taken:
transfer of G/L balances to the new fiscal year, by executing the program ‘SAPFGVTR’ (using
transactions F.16, GVTR, or GLGVTR)

transfer of A/R and A/P balances to the new fiscal year, by executing the program ‘SAPF010’.

The purpose of the above programs is to update the field ‘UMSAV = transfer balance’ of the tables
‘SKC1A’ and ‘SKC1C’ for the G/L balance sheet accounts and the ‘LFC1’ and ‘KNC1’ for the
A/R-A/P accounts. Since profit and loss accounts transfer their balance to the balance sheet
`accounts, the first ones do not have any transfer balance.

The ledger of G/L, A/R and A/P accounts as well as the respective trial balances are updated by the
above programs.

According to standard SAP, the execution of the above programs represent the closure of the year.
However, the Greek legislation claims the presence of the opening posting on the journal. To do so,
each company has to execute a special program. Along with this execution, a new document type
with key that can be defined in Journal customizing and description ‘opening transaction of the
new year’ is created.

This posting will be depicted on the journal with:


document type – as defined previously
number x+1, stored in the table ‘J_1GJR_LN’, where ‘x’ represents the number of the last
posting of the journal.

When this posting is over and the printout of the stamped journal is complete, the table
‘J_1GCONTROL’ must be updated with the number (x+1), the amount plus the amount of the
opening posting (debit and credit) and the total number of the printed pages.

As an alternative the opening document can appear in the Balance Sheet journal even if it does not
exist as a saved document in FI.
After executing the balance carry forward program this document shows all accounts balances
carried forward from the previous year in document format with document type defined in
customizing of journals (transaction J1GJR3).

In this transaction is also defined whether the opening document should be an FI document or not.

We perform this function by maintaining opening document number in the respective view of the
control table J_1GCONTROL.

Note: It is proposed the opening transaction of the new year should be printed on the journal of the
balance sheet with the posting date 01/01/XX.

© SAP HELLAS S.A. 46


Localization Process SAP ERP 6.0 Country Manual

4. AM Topics Covered by the Localization Process

4.1 Asset Master File

In Greece following fields are used in the Asset MF:

Description - ANLA-TXT50
Account determination- ANLA-KTOGR
Quantity - ANLA-MENGE

Cost center - ANLZ-KOSTL (Used for automatic updating of the


depreciation posting)
Capitalization date - ANLA-AKTIV (Automatically, updated from the
acquisition posting)
Plant - ANLZ-WERKS
Location - ANLZ-STORT
Evaluation group 3 - ANLA-ORD43 (Law of investment to be shown in the
Asset History Sheet)
Evaluation group 4 - ANLA-ORD44 (Claims of the Asset to be shown in the
Asset History Sheet)
Investment reason - ANLA-IZWEK (for Investment book)
Investment support - RA02S-INVSL
Supplier - ANLA-LIFNR
Original asset - ANLA-AIBN1
Original sub-asset - ANLA-AIBN2
Classification key - ANLA-VMGLI
Man.prop.value - ANLA-WRTMA

4.2 Definition of company code

SAP Hellas recommends the following customizing for Greece:

Company code :GR01 (Test company code)


Chart of accounts :CAGR
Chart of dep. :1GR
Status company code :2 (Test company code: Data takeover always alllowed)
:1 (Old assets data takeover in process)
:0 (Old assets data takeover completed)
CoCode for number assignment :GR01
Fiscal year variant :K1 (12+1 periods)
Document type dep. posting :AF (Used for periodic posting of depreciation)
InputVat Ind.:No tax :98 (Input Vat 0% - when such situation occurs)
Allocation Profile :AI (Settlement assets under construction)

4.3 Depreciation Areas

In the Asset Management system, a sample Chart of Depreciation for Greece is defined by the code
‘1GR’ where six depreciation areas are defined. Within these depreciation areas, specific posting
and depreciation rules (such as the depreciation keys) are determined. The depreciation areas that
are stated below are mainly used in Greece:

© SAP HELLAS S.A. 47


Localization Process SAP ERP 6.0 Country Manual

Depreciation area 01 is mandatory for updating the Greek G/L accounts. The depreciation run for
this area should be executed once a month because of A/L update needs. Also, the memo value for
this area is 0,01 cent.
Depreciation area 30 can be used for updating accounts in companies using primary COA different
than CAGR, maintained in EUR.
Depreciation area 31 can be used for updating accounts in companies using primary COA different
than CAGR, maintained in foreign currency.
Depreciation area 51 is relevant for investment grants. The memo value for this area is 0,01 cent.

4.4 Asset Class

The asset class is the main classification criterion for fixed assets. Each asset must be allocated to
exactly one asset class. In each asset class, you can define control parameters such as account
allocation, screen layout, number assignment, asset type, and default values. For example,
depreciation keys can be set as default values in the asset class master, in order to update
automatically the assets belonging to the respective asset class.
Asset main numbers and asset sub numbers should be found in the same asset class. In Greece, the
last one corresponds at least to second level accounts.

4.5 Customizing the ‘Calculation keys’ and the ‘Valuation keys’

In Greece the calculation of the fiscal depreciation is done according to legal regulations. The
percentages used are stated percentages only.
The depreciation methods and their calculation schemes are defined in tables ‘T090NA
,T090NAZ,an d ‘T090NS’. These tables can be reached via transaction code ‘SPRO’ under
customizing menu: Goto Sap Reference IMG Financial Accounting Asset Accounting
Depreciation Valuation Methods Depreciation Key Calculation Methods Calculation
Methods / Maintain depreciation Key.

SAP Hellas recommends the following customizing for Greece:

Calculation Methods
Base methods
Type of depreciation Ordinary depreciation
Dep. method Stated percentage
Reduce use.life at FY end X
Dep. after plnd.life end X
Multi-Level Methods
Validity start 2 ( From ordinary depratiation start date )
Levels
Base value key for depr. Calc. 03 ( Replacement value )
Depreciation rate According to legal regulations ‘e.g. 10,0000’
Depreciation Key
Class Straigtht - line depreciation
Assignment of calculation methods
Chnge method No automatic changeover
Multiple shift No effect on depr.and useful life
Scrap value Cutoff value is ignored
Shutdown Yes

© SAP HELLAS S.A. 48


Localization Process SAP ERP 6.0 Country Manual

4.6 Asset Management Automatic Account Determination and Depreciation Tables

Automatic account assignments in the Asset Accounting module are carried out in the tables
‘T095T, T095, T095B’. These tables can be reached from customizing via the transaction code
‘ao90’.

For each account assignment, the following related G/L accounts are entered on the basis of
depreciation areas:
Acquisition: Acquisition and production
Acquisition from affiliated companies
Clearing revenue from asset sale
Profit from asset sale
Loss from asset sale
Loss made on asset retirement w/o revenue
Clearing revenue sale to affiliated company
Revaluation acquisition and production
Contra account: Revaluation APC
Clearing of investment support
Revenue from write-up on ordinary depreciation
Revenue from write-up on special depreciation
Revenue from write-up on unplanned depreciation
Accumulated depreciation account: Revaluation of ordinary depreciation
Contra account: Revaluation ordinary depreciation

4.7 Asset Revaluation

The revaluation of assets is done by the program ‘J_1GAMARE1’.


The program is under the transaction code J1GAM_ARE1.
After the program execution assets are collectively reevaluated according to the criteria given by the
user.
The revaluation transactions are carried out according to the selection fields of the program and the
entries in table ‘J_1GAM2GR’ and ‘J_1GAMASN’ (Asset Super Number).

Prerequisites:

Maintain the field ANLA-WRTMA in the asset master record with the objective value of the
reevaluated asset.
Maintain table ‘J_1GAM2GR’ with the revaluation percentages for each combination (asset
class - acquisition year). Use transaction code ‘SM30’.
Maintain table ‘TABWG’ with transaction code ‘SM30’. Create the transaction type group ‘85’
with copy from transaction type group ‘81’ and change the period control from ‘1’ to ‘5’.
Maintain asset super numbers in table ‘J_1GAMASN’
Create transaction type ‘805’ using the transaction type group ‘85’. The relevant tables are
‘TABW’ and ‘TABWT’ and they can be maintained using transaction code ‘OA81’.
The calculation keys used for the depreciation calculation of the reevaluated assets should
calculate on ‘base value’: 03 - Replacement value. The name of the field is T090P-BEZWKZ.

Only the asset classes entered in the table ‘J_1GAM2GR’ will be reevaluated. If on the selection
screen of the program ‘J_1GAMARE1’ the productive run is chosen, then the revaluation postings

© SAP HELLAS S.A. 49


Localization Process SAP ERP 6.0 Country Manual

will be done on the fixed asset sub-ledger. These postings are recorded only on the master file of
each asset.
The program ‘Post Depreciation’, which is running at the end of the year, makes the relevant
postings to the related accounts in the general ledger concerning the depreciation and revaluation
transactions.

4.8 Legal books related to Fixed Assets

Fixed Assets Legal Register

For Greece the standard SAP-program ‘RAGITT01’ does not cover the legal requirements by §
2.2.103 of the Greek accounting law for the ‘Asset Legal Register’. In Greece we need to have
following data on the header of each asset in the Asset Register:
- fixed asset code (main number and sub-number)
- fixed asset description
- the first and last level relevant G/L Accounts with descriptions
- the location of the asset
- the asset depreciation start date
- the asset depreciation end date
- percentage of depreciation (normal and special)
- the G/L Account for the cumulative depreciation of the asset
- name of the special law implemented for the asset
- claims on the asset

Therefore the report had to be modified to the report ‘J_1GAMLARA’ which has a selection screen
more limited than ‘RAGITT0’ with the addition of the parameter for ‘productive run’ which results
into not printing the report header with the company code data.The program can be executed via
transaction code J1GAM_LA.
The above program uses the customizing tables J_1GAMREG and J_1GAMREP which define the
screen output of the report and can be reached via the transaction codes J1GAM_R1 and
J1GAM_R2 respectively..
In table J_1GAMREG exists a list of fields related to assets transactions which can be chosen to
appear in the report output.

The functionality of defining the field length and performing totals per field is also given and can be
defined through this table .

In table J_1GAMREP technical settings such as line-size and line-count are defined.

Both tables can be accessed through the output screen of the program by pressing the relevant push
buttons (use also transaction SM30 in order to customize these tables or the corresponding activities
of IMG).

Fixed Assets Transaction list

The report ‘J_1GAMARG0’ used is a modification of the standard report ‘RAZUGA01’ so that it
can list all transactions regardless the transaction type where they belong.

Investment Book

© SAP HELLAS S.A. 50


Localization Process SAP ERP 6.0 Country Manual

The Investment Book is a list of all assets bought by a special law which have to be shown
separately according:
- to the year of implementation of the law and
- if the investment has to be shown as a reserve or a tax deduction.
The critical field for this Report is ANLA-IZWEK (Investment reason). The Greek report
‘J_1GAMAIB0’ is a copy of the standard SAP program RAHERK01. This is an obsolete program,
replaced by J_1GAMIBOOK.
Investment Book (J_1GAMIBOOK) is a report that fulfils all the legal requirements concerning the
management of the investment support in Asset Accounting.
In the selection screen we have the option to limit the output data’s according to certain limitations
based on fields like:
1. Company code
2. Asset number
3. Asset Sub number
4. Asset class
5. Business area
6. Cost center
7. Plant
8. Location Asset super number
9. Capitalization date
10. Investment Law.
The above fields are predefined on the standard screen of this report.

Additional fields are offered for extra limitations or and selections under the button for the extra
dynamic selections (Shift + F4).

Also there are tree (3) indicators.


Posted Depreciation (If you set this indicator, the system shows the depreciation posted
in the general ledger since the beginning of the year, instead of planned annual
depreciation
Alternative Accounts (If you set this indicator, the system shows alternative appropriate
general ledger , instead of the original accounts)
Headers (If you set this indicator, the system shows above the output layout additional
header concerning all the Company Code information data’s (address data’s e.t.c).
There are also two radio buttons.
If the investments radio button is on we get assets investment book report else we get tax
free reduction report.
The report (investment book ) is sorted by Asset Law (Evaluation Group 3) ,Asset
Group, Asset number and Asset subnumber.
Totals are displayed per Asset law/asset group and asset law.
Values are calculated from depreciation area 51.
The report(Tax free reduction) needs customizing in order to calculate tax free reduction
per law.
We maintain the percent per bukrs and investment law in table J_1GAMAFA
Transaction J1G_AMF.
Totals are displayed per Asset law/asset group and asset law.
Values are calculated from depreciation area 01.
We must maintain asset laws in Evaluation Group 3.

The report (investment book) is displaying the following fields.


1. Asset No
2. Sub No

© SAP HELLAS S.A. 51


Localization Process SAP ERP 6.0 Country Manual

3. Description
4. Cap. Date
5. Depreciation Percentage
6. Investment Reason.
7. Maximum Investment Percentage.
8. Investment Amount posted P.Y.
9. Revaluation of Investment amount posted.
10. Investment Amount CY.
11. Depreciation Investment amount .PY.
12. Depreciation Investment amount CY.
13. Investment Balance amounts.

The report (Tax Free reduction report) is displaying the following fields instead of 5 – 13 fields of
the above report)
1. Document No
2. Vendor code
3. Vendor Name
4. Asset Acquisition Value
5. Asset Value Transactions.
6. Tax Reduction

Sums and sorting are the same like investment book report.

© SAP HELLAS S.A. 52


Localization Process SAP ERP 6.0 Country Manual

5. Analytical Accounting

CAUTION: According to the limitations of the naming convention of special purpose ledger, some
of the objects of Analytical Accounting included in this software do not follow the J_1G naming
convention in some cases.

5.1 Introduction

Apart from the Hellenic General Ledger Accounting system, Greece follows an Analytical
Accounting system as well.

There are several criteria that some companies must follow according to the Analytical Accounting
system.

According to the Hellenic General Ledger Accounting that the Analytical Accounting system is the
assessment procedure of cost analysis.

Analytical Accounting involves:

With cost process of expenses.


Assessment of cost by divisions, operations, activities, business areas.
Comparison of actual expenses to the planned expenses.
Monitoring and analysis of cost results for controlling purposes of a companies activities.

Analytical Accounting abides by the Greek Legislation ( sec. 1.100 clause 1. . 1123/80) and can
operate in two ways.

The Analytical Ledger Accounting system as an independent/autonomous accounting system (in


relation to the General Ledger Accounting system). Accounts of group 9 are posted in separate
documents without mixing with G/L Accounts from other groups.

The two accounting systems work in parallel with the requirement that the Analytical Accounting
system is autonomous in relation with the General Ledger accounting system.

5.2 Internal Accounting assessment of Operation Costs

All enterprises depending on the type of business, that apply the Analytical Ledger system follow
different guidelines:

They need to follow internal accounting procedures in order to configure their costs of
operations.
Example. 92 Cost Centres
92.00 Production Costs
92.01 Administration Expenses
92.02 Research and Development Costs

92.03 Distribution Costs


92.04 Finance and Administration Costs

Development of third level accounts that represent cost centers; under the second level of

© SAP HELLAS S.A. 53


Localization Process SAP ERP 6.0 Country Manual

accounts according to the organizational structure of the company.

The cost centers are divided into Main Cost Centres (Production oriented) and
Secondary Cost Centres (e.g Plant maintenance). The Main Cost Centres distribute
their expenses to the semi-finished and finished product and services.

The Secondary Cost Centres allocate their expenses to other secondary cost centers and/or the main
cost centers.

Develop the cost centre account on a posting level in Analytical Accounting according to the
corresponding expense accounts of Group 6 & 8 in the General Ledger accounting system.

Following a minimum example (compulsory) of cost centre accounts analysis to the type of
expense account :

92 COST CENTERS
92.00 PRODUCTION COSTS
92.00.00 PRODUCTION DIVISION A
92.00.00.60 EMPLOYMENT EXPENSES AND SALARIES
92.00.00.61 SALARIES AND EXPENSES OF THIRD PARTY
92.00.00.62 THIRD PARTY BENEFITS
92.00.00.63 VALUE ADDED TAX ( V. A.T)
92.00.00.64 MISCELLANEOUS EXPENSES
92.00.00.65 --------------------------------
92.00.00.66 ASSET DEPRECIATION
92.00.00.67 FORECAST
92.00.00.24 RAW MATERIALS - MATERIAL PACKING
92.00.00.25 CONSUMABLE MATERIALS
92.00.00.26 ASSET REPLACEMENT PARTS
92.00.00.28 TYPE OF PACKAGING
92.00.00.92 EXPENSE RATIO OF ASSISTING COST CENTERS

Updating all the Analytical Accounts with the stock:


1. The purchased stock, data regarding purchase stock, operating expenses, operating
income and non-operating results are posted first in G/L and then but not later than the
end of the month, are transferred to the account of the analytical accounting.
2. The purchase stock, data regarding purchase of stock, operating expenses, operating
income and non-operating results are posted at the same time in the accounts G/L as well
as the accounts of the analytical accounting.

Updating all the A/L Accounts centralized into one total or analytical at least once a month.

5.3 Internal Accounting assessment of Production Costs of Manufacturing Companies

Companies of manufacturing sectors using their internal accounting system, are obligated to
assess the product cost of finished and semi finished goods, based on the type of good, the latest
at the end of every month. For this purpose the account used is “PRODUCTION COSTS OR
PRODUCTION IN PROGRESS”. According to the “autonomous” system the production costs
are monitored in account 93. According to the parallel operating accounting system the
production costs are monitored in account 23.

The sub- level accounts of production cost accounts (93 or 23) collect and monitor the total

© SAP HELLAS S.A. 54


Localization Process SAP ERP 6.0 Country Manual

production cost of semi finished and finished goods, services, assets, and the costs of research
and development. These sub level accounts contain the actual cost of production and include by
rule analysis of direct raw materials, direct labour, and general industrial expenses.

The first level account “COST OF PRODUCTION” is developed only if there are objects to be
followed in the following at least second level accounts:

1. Cost of production finished and semi-finished products


2. Cost of production sub-products and remaining or cost of services
3. Cost of our production regarding assets
4. Cost of further activities
5. Cost of product developing

These second level accounts are further developed into third level accounts regarding each product
produced or own produced assets or services providing.

The cost at the level of the product its analysed further including the following components:

Direct raw materials


Direct labour
General Industrial expenses

5.4 Internal Accounting Observation of Stock Movement

The Analytical Accounting observes by using accounts, material stocks (with the constant
inventory method) by quantity and value.

In the system of the Analytical Accounting all movements regarding stock movements (imports-
exports) have to be assessed the latest by end of the month (with the consumption prices
calculated from valuation).

Stock movements have to include:


1. Incoming movements regarding purchase, production, internal stock movement or assessments of
inventories and
2. Outgoing movements for sale, consumption, or deliveries to different warehouses, destruction, or
losses.

5.5 Internal Time Arrangement of Purchases, Expenditures, Income, and Non-Operating


Results in Monthly Basis and Determination of Monthly Results

All the stock movements must be assigned a value depending on the nature of the stock materials
(bought, produced etc) depending on the transaction
The operating expenses by item of account group (6) of G/L are posted within the month and
then considered accrued irrespectively if the respective paper document (vendor invoice) has
arrived.
The operating expenses by item of the account group (7) of G/L are posted within the same
month
The non-operating income -expenses, profit and losses regarding account group (8) of G/L are
posted within the same month they regard.
The autonomy system of the Analytical Accounting, gross analytical results are determined in

© SAP HELLAS S.A. 55


Localization Process SAP ERP 6.0 Country Manual

the account 96 “INCOME - GROSS ANALYTICAL RESULTS” where in this account is posted
the income and their cost of production. In the account 98 “PERIOD RESULTS” are posted
during the month, the non-operating income, profit, and losses, which are posted in the account
group (8) of G/L.
The system of co-operation G/L and A/L, the gross analytical results are determined in the
account 96 “INCOME GROSS ANALYTICAL RESULTS” or in the appropriate accounts of the
account group (7) of G/L. In these accounts is transferred the cost of production of goods sold
the latest by the end of every month.

5.6 Mandatory A/L Accounts

Analytical Accounting has the following mandatory accounts and they are as follows:

5.6.1 System of Autonomy

90 Intermediate Accounts
92 Cost Centres
93 Cost of Production (Production in Process)
94 Stock
96 Income - Gross Analytical Results
98 Analytical Results

First Level Accounts:

91 Reassessment of Expenses, Purchases, and Income


95 Standard Cost variances
97 Tangible Variance and Imputed Costs

These Accounts are not mandatory, but when the company decides to follow movements and facts
regarding these accounts, they become mandatory. Mandatory accounts are also second and third
level imposed by the Greek Legislation.

Intermediate Accounts (90) are named as follows.


1. Interim: interact between G/L and A/L
2. Contra: affecting in full Group Accounts 2, 6,7, and 8, of G/L

These are accounts used for transfer reasons in analytical accounting without affecting the G/L
accounts.

Analytical Accounts
G/L Accounts Debit Credit
Group 2
Stock Inventory 94 Reserves 90.01 Starting Reserves posted
Fiscal Year Purchases 94 Reserves 90.02 Purchases posted

Group 6 92 Cost Centres 90.06 Operating Expenses posted by


Item

Group 7 90.7 Operating Income 96 Income - Gross Analytical


Posted by Item Results utilized

© SAP HELLAS S.A. 56


Localization Process SAP ERP 6.0 Country Manual

Group 8
Expenses and Losses 98.99 Utilized Results 90.08 Results posted
Income – Profits 90.08 Results posted 98.99 Utilized Results

Based on the above, we must have equal results between the figures posted in the account groups 2,
6, 7, and 8 (81-85) of G/L in comparison to the figures posted in the analytical accounting.

This equality can be violated in the following situations:

1. It is not necessary that all the stock appropriation, expenses, income and results which are posted
in G/L to be transferred in the analytical accounting, e.g. The account “Insurance” to be debited
with expenditure which regards period before or after insurance took place in comparison to the
costing period.
2. In Analytical accounting it is possible to post expenditures or income, which have to be posted in
G/L, or they have been posted with different amounts. This happens when:
There is a difference between posting periods in G/L in relation to the costing period.
Due to planned expenses, which are possible to be posted in specific calculations of account group
90 e.g. (90.99). Such expenses can be regarded as the payout of the business owner, know-how
payout etc.
The calculated expenses there are not posted in G/L accounts because they are not represent real
value pay-outs or income, but they can be posted in the analytical accounts in order to derive the
right figures.

Customizing of Analytical Ledger (menu J1GAL)

The following description of customizing refers to postings performed through the modules of SD,
FI, CO. All MM transactions are explained to the MM section of the manual.
According to the Greek Chart of Accounts the accounts that are relevant for this solution are those
of group 6 (operating expenses), 7 (revenues), 81-85 (non-operating expenses and revenues).
All functions of A/L (customizing and program execution) can be found in area menu J1GAL.

Analytical Ledger (A/L) uses Special Purpose Ledger (SPL), auxiliary tables and programs in order
to define during General Ledger postings, the accounts of A/L to be posted and actually perform the
postings on a later stage.
SPL acts as a filter when posting in General Ledger, selects only the postings that affect A/L and
stores them temporarily both at line item and summary level (SPL tables).

SPL also acts as a feeder to FI by performing postings in A/L, so that all necessary books (trial
balances, ledgers and journals) can be printed.

This flow is represented in the following diagram:


G/L A/L

CO

SD FI
SPL
FI
M
M

Phase 1 Phase 2
Phase 1 and 2 will be used throughout this text.

© SAP HELLAS S.A. 57


Localization Process SAP ERP 6.0 Country Manual

SPL usage has the following advantages:


1. It facilitates control of data that will update A/L.
2. It provides information with respect to A/L using standard SAP tools like report painter.
3. It provides the ability to perform postings directly to SPL.
4. On-line validations of the FI/CO postings that will later update A/L (e.g. check of cost objects).
On the other side there is some data redundancy as they are kept twice (both in SPL and FI)

Phase 1

During phase 1 SPL is updated either on-line or off-line (depends on the customizing) from the
daily transactions of SAP modules.

Prerequisites for phase 1 are:


Installation of SPL for A/L.
Table maintenance for J_1GAR, J_1GOR etc,

Table J_1GALC (Control parameters for A/L)

Table J_1GALC contains general parameters that are relevant to all A/L functions.

1. Name of SPL for A/L


2. Flag for using alternative accounts of the Chart of accounts in tables J_1GAR, J_1GGA,
J_1GIA, (please note that you can not use alternative COA if you do not activate this option).
3. The type of message (Warning, Error) produced during the original posting (FI, CO postings),
when there is no link between G/L and A/L Account in table J_1GGA.
4. Flag for checking or not the existence of accounts defined in customizing tables

Tables J_1GAR (Account ranges), J_1GOR (Object ranges), J_1GGA (Connection rules A/L)

In these tables the connection between G/L and A/L is defined.

In J_1GAR we define G/L account ranges or groups of secondary cost elements

In J_1GOR we define ranges (groups) of objects that characterize and/or classify the FI or CO
postings. Only the following object types are supported:

CTR Cost center


PTR Profit center
COB Cost element
ORD Order
BUS Business area
MAT Material
PLN Plant
WBS Work Breakdown Structure Element

In table J_1GGA we store combinations of objects and accounts of A/L .

Table J_1GOP (Objects priorities)

In this table the sequence of cost objects to be processed during the posting is defined, in case there
is more than one object (e.g. cost center and order). For the first object that a link can be found

© SAP HELLAS S.A. 58


Localization Process SAP ERP 6.0 Country Manual

processing stops and SPL is updated.

The table is declared as ‘Fully buffered’ to increase performance.

Special Purpose Ledger (SPL)

SPL of A/L is defined in 4 tables, which are delivered as part of the Localization, but SPL table
installation and further customizing possibly needed must be performed to the customer site. Due to
naming conventions of SPL the tables must start with Z, Y. By running program J_1GALCTG, with
sample table group ZGRSAPAL, the following SPL tables are created:

ZGRSAPALT Summary table


ZGRSAPALA Line items
ZGRSAPALO Object table 1
ZGRSAPALP Plan line items

ZGRSAPALO is a technical table defining the key of SPL, which consists of:

BUKRS Company code


ACCT A/L Account
ZZGLACC G/L account
ZZOBJTP Object type
ZZOBJECT Object

This means that analysis of period balances can be given for any combination of the above-
mentioned objects.

Program J_1GALVU (User exits for A/L)

This program contains all the basic routines used for the field movements of SPL, for finding the
accounts to be posted in A/L etc. This program must be declared in SPL customizing in the area
GCX2 (A/L user exits) and the routines codes must be declared in SPL (field movements).

Please note that if a customer uses a different program in variable field movements, J_1GALVU
can be converted to Include (program attributes – type “I”) and assigned to the existing program.
The subroutines contained in J_1GALVU are:

Code Functional area Function


U90 FI postings It returns the A/L account to be posted no matter
what the sender field is
U91 CO postings It returns the type of object used to derive the A/L
account to be posted no matter what the sender field
is.
U92 FI/CO postings It returns the A/L account to be posted no matter
what the sender field is
U93 FI/CO postings It returns the type of object used to derive the A/L
account to be posted no matter what the sender field
is.
U95 CO postings Sender is the cost element of CO (COEP-KSTAR)
and if it is primary, it returns the alternative account
(SKB1-ALTKT), else if secondary the same cost
element (COEP-KSTAR) and is used when having

© SAP HELLAS S.A. 59


Localization Process SAP ERP 6.0 Country Manual

alternative COA.
U94 FI / CO postings Source is the order (ACCIT_GLX-AUFNR or
COIOP-AUFNR) and if production order it returns
the produced material.

These codes of User-exits are used in customizing, while technical are derived like U90
E90_MVC

These user-exits (U90, U91, U92, U93), work as follows:

Input is the original posting’s data (from structures ACCIT_GLX for FI, and COEP or COIOP for
CO). Then the objects are processed with the sequence defined in the respective customizing table.
If a link to an A/L account is found, SPL is updated. If not, a message is issued and SPL is not fully
updated and the SPL ledger must be updated off-line after adding the missing entries in
customizing.

Phase 2

In this phase the A/L is periodically updated from SPL by using program J_1GALTL, which
performs A/L postings.

Prerequisites for phase 2 are:


SPL Installation for A/L
Table maintenance of customizing tables mentioned before
Execution of batch input program (J_1GALTL).

Table J_1GAT (Transfer method in A/L of FI-SL Activity)

Transactions that update A/L are of two types:


Those that need an intermediate account (e.g. expenses, revenues) and
Internal A/L postings (e.g. distribution of expenses to products etc)

In table J_1GAT it is defined which activities will have an intermediate account in A/L and which
will not.

Table J_1GIA (Intermediate accounts)

In this table the intermediate account to be used by A/L for groups of G/L accounts is defined. These
entries are used by program J_1GALTL to perform the postings.

Program J_1GALTL (Update A/L – Batch input)

This program creates Analytical Ledger Documents based on the data from SPL tables.

The initial selection screen has:


Execution mode selection:
1) Test run,
2) Productive run
3) Display of old postings

In the first case only a list of postings to be performed depending on the criteria entered by the
user.
In the second case the actual postings are performed.

© SAP HELLAS S.A. 60


Localization Process SAP ERP 6.0 Country Manual

In the third case the user has the possibility to see the previous productive runs of the programs

A group of parameters for selecting documents from G/L that will be transferred to A/L:
Record type
Company code
Posting date
Document type
SPL document
Original document
Account
A/L account
FI-SL business activity

Finally there is a group of parameters that are relevant to A/L posting:


1) Posting date
The user can select if the A/L posting date will be the original’s document posting date or the
last day of the period.
2) Document date
3) Document type
4) Document header text
5) Line item text

The user can select whether the program will transfer the line item text of the original document
or it will automatically create one. In the second case the line item text consists of document
number, posting date and period.

SPECIAL NOTE: Recently it was announced that companies using IFRS as their primary
Valuation method can be excluded from the mandatory Analytical Accounting
Bookkeeping. Also the requirement to keep Analytical ledger irrespective of IFRS usage
has been dropped as requirement of KBS code, but remains as obligation – not on a short
term period though.

6. SD - Related issues for Greece

The SD-related issues that have to be treated differently in Greece due to either Books and Records
Code Regulations or to Greece-specific tax regulations or to common business practices mainly fall
in the following areas.

6.1 Organizational Structures

A branch of a typical Greek Company is a separate organizational unit (in a different geographical
location) that comprises its own customer-related activities that may be one or more of the
following:
- selling
- warehousing/delivering (distribution centre)

The SD-relevant requirements for Greek companies that comprise several branches - as derived
from current regulations - are as follows:
- Functional differentiation of the branches (SAP ERP organizational units level)
- SD postings from various branches to different G/L accounts

© SAP HELLAS S.A. 61


Localization Process SAP ERP 6.0 Country Manual

To meet this requirements SAP Hellas proposes the following procedure:


- Company’s Branches are usually differentiated through Plants
- The delivering plant is set as a criterion in account determination, i.e. create a user defined
account determination table that comprises the delivering plant as one of its fields.

Special treatment should be given to Shipping Point Determination as the issuing point of Legal
Documents (Header information to Delivery Document)

6.2 Customer Master Files – Partner Functions

The standard SAP SD partner functions used in the SD documents are the following: (between
brackets is their meaning for Hellenization)

Sold-to party in Sales Order (Order taking)


Bill-to party in Billing document (Fiscal address of Sold-to and Ship-to)
Payer in Billing document (A/R customer for FI)
Ship-to party in Delivery note (Shipping Address)

The rules concerning the Hellenization for the partner functions are the following:
- Customer branches and warehouses are treated as alternatives ship-to to the Head office (payer).
In the sales order the Bill-to cannot be changed manually and is used as a temp for the original
Payer in case of a new Payer at the movement. This is because when the Payer is different from the
Bill we are obliged to note it on the Delivery note.
We have always delivery split for different payers.

6.3 Integration with FI

6.3.1 Tax determination


In the Greek Model Company delivered by SAP Hellas, one tax category, namely MWST, has been
defined for Greece, representing the standard Greek V.A.T. ( .), defined in Table TSTL

VAT Rate for a particular SD document line item is controlled via the following factors:
- Customer Tax Classification
- Material Tax Classification
- Tax Code assigned to each combination of customer and material tax classification

The above-mentioned elements are used for the automatic calculation of the VAT rate in SD
transactions.

Customer Tax Classification


For each customer the tax classification must be entered in the Customer Master (Billing Screen,
field KNVI - TAXKD), from where it is then copied to all relevant SD transactions. More
specifically, in the billing document it is copied to field: VBRK-TAXK1. The possible values for
customer tax classification are defined in SD Customizing (Tax Category: MWST, Table: TSKD,
Trans.Code: OVK3).

The following indicative customer tax classifications are proposed for Greece:

- VAT Exempt (0%) e.g. embassies, etc.


- VAT Exempt (0%) for EU exports customers.
- VAT Exempt (0%) for non-EU export customers.

© SAP HELLAS S.A. 62


Localization Process SAP ERP 6.0 Country Manual

- Full VAT (i.e. 19% when selling a material with 19% VAT)
- Low Tax (30% off full VAT Rate), for residents of specific areas in Greece (i.e. 13% when
selling a material with 19% VAT)

Material Tax Classification


For each material the tax classification must be entered in the Material Master (Sales 2 Screen: field
RM03M - TAXKM). The information is actually stored in MLAN - TAXM1. From the material
master the tax classification is copied to relevant SD transactions. More specifically, in the billing
document it is copied to field VBRP-TAXM1. The possible values for material tax classification
are defined in SD Customizing (Tax Category: MWST, Table: TSKM, TCode: OVK4).

The following indicative material tax classifications, are proposed for Greece:
- Trading Goods 19%
- Trading Goods 9%
- Trading Goods 4,5%
- Finished Products 19%
- Finished Products 9%
- Finished Products 4,5%
- Semi-finished products 19%
- Semi-finished Products 9%
- Semi-finished Products 4,5%
- By-Products 19%
- By-Products Products 9%
- By-Products Products 4,5%
- Services19%
- Services 9%
- Services 4,5%
- Other Income 19%
- Other Income 9%
- Other Income 4,5%

Important Note
Given that in Greece the postings to VAT accounts have to be differentiated according to:
- VAT Rate
- Corresponding G/L revenue and sales deductions
For the purpose of producing the VAT advance return, the above-mentioned distinctions for
material tax classifications are necessary.

Definition of Possible combinations of Customer/Material Tax Classifications


The mapping of the different combinations of customer and material tax classifications to the
corresponding VAT rates is performed through assigning a valid FI tax code to each combination
(TCode VK12). In this way, each combination will inherit the VAT rate defined for the assigned
Tax Code in FI customizing. The Tax Code will also determine the tax account to be posted to for a
specific line item of a SD billing document

Due to technical problems, this mapping cannot be included in the Hellenization deliverables. It is
therefore necessary for the users to add the mandatory entries in their systems.

These combinations are defined in SD Customizing for the following cases:


- Domestic Taxes

© SAP HELLAS S.A. 63


Localization Process SAP ERP 6.0 Country Manual

- Export Taxes

Definition of VAT Rates-Tax Accounts for Domestic Transactions (within Greece)


Assign an existing Tax Code (already defined in FI) to all possible combinations of
- Customer Classification
- Material Classification
- Plant (when branches are involved)

Definition of VAT Rates for Export Transactions (from Greece to other Countries)
In Greece, export transactions are normally not liable for V.A.T. If necessary, assign an existing
Tax Code (already defined in FI) to all possible combinations of:
- Destination Country
- Customer Classification
- Material Classification

Definition of Customer tax classification from partner function.


The standard SAP SD partner functions used in the SD documents are the following:
- Sold-to party in Sales Order
- Ship-to party in Delivery note
- Bill-to party in Billing document
- Payer in Billing document

The tax classification in the documents is derived from the Ship-to-party.

Posting to Tax Accounts


According to standard SAP ERP the tax accounts to be posted to, are derived from the tax code that
applies to a particular billing document line item. More specifically the tax account posted to is the
account allocated to the specific tax code in FI.

Important Note
Given that in Greece the postings to VAT accounts have to be differentiated according to:
- VAT Rate
- corresponding G/L revenue and sales deductions, for the purpose of calculating the VAT
advance return
The following tax accounts (and of course the corresponding tax codes) are necessary for a typical
Greek company selling trading goods only!

- 5400700018 Trading Goods 19% sold to Full VAT Customers


- 5400700013 Trading Goods 19% sold to Low VAT Customers
- 5400700008 Trading Goods 9% sold to Full VAT Customers
- 5400700006 Trading Goods 9% sold to Low VAT Customers
- 5400700004 Trading Goods 4,5% sold to Full VAT Customers
- 5400700003 Trading Goods 4,5% sold to Low VAT Customers
- 5400700000 Trading Goods 0% sold to any Customer or
Trading Goods 19, 9, 4,5% sold to VAT Exempt Customers

© SAP HELLAS S.A. 64


Localization Process SAP ERP 6.0 Country Manual

6.3.2 SD Account determination

Mapping of SD billing documents to FI document types


It is imperative in Greece to discriminate the postings according to their nature in the Journals, the
Warehouse Book, etc. To serve that purpose SD billing documents should map FI documents as
indicated below:

Billing Types FI Postings


Sales Invoice Revenue Account , Deductions …
Return Credit Memo Sales Returns Account, Deductions ...
Credit Memo Revenue Account , Deductions …
Debit Memo Revenue Account , Deductions…
Cancellation Invoices Reverse Posting

This can be done through SD customizing of the billing document type and has the following
restrictions:

- fully characterization of the “accounting” nature of the billing type


- the possible values are defined by SAP and cannot be changed in customizing (whereas the
different SD Billing types can be freely created or deleted in customizing)

The solution comprises of the following steps:


- Define the desired FI document types
- Map standard SD billing type document categories to the target FI document types by SD
billing type maintenance

Posting to G/L Revenue and Sales Deductions Accounts


In Greece, the Books and Data Code regulations impose that postings to G/L Revenue and Sales
Deductions Accounts be differentiated according to:
customer type
- domestic
- foreign
- affiliate companies
etc.
material type
- Trading Goods
- Finished products
- Semi-finished products
- By-Products - raw Materials
- Services
- Other Income (e.g. freight/packing surcharges to customers, etc)
etc.

Therefore, the standard SAP ERP SD Account Determination Technique is used as follows:

- The different customer types are defined as different Customer Account Assignment
Groups, in tables TVKT, TVKTT (TCode OVK8). Each customer is assigned to a specific account
assignment group in the Customer Master file - Billing Screen (KNVV-KTGRD).

Example of Customer Account Assignment Groups:

Acct.Assg.Group Description

© SAP HELLAS S.A. 65


Localization Process SAP ERP 6.0 Country Manual

01 Domestic Revenues
02 Foreign Revenues
03 Affiliat.Comp. Revenues

- The different material types are defined as different Material Account Assignment Groups,
in tables TVK , TVK T (TCode OVK5). Each material is assigned to a specific account
assignment group in the Material Master file - Sales 2 Screen (MVKE - KTGRM).

Example of Material Account Assignment Groups:

Acct.Assg.Group Description
00 Trading Goods –GR
10 Finished Products-GR
15 Semi-Finished Pr.-GR
20 Raw Materials – GR
30 Services – GR
50 Other Income – GR

The mapping of the different combinations of customer and material account assignment groups to
certain G/L Accounts is defined in condition tables (C001-C500 for standard SAP condition tables
and C501-C999 for user defined condition tables) via transaction VOK1. Condition table C001 is
usually adequate for the SD Account Determination of a typical Greek Company with no branches.
If a company comprises branches, the Delivering Plant should usually be a criterion for the account
determination, since different G/L accounts should be posted to.

Important Note
In standard SAP ERP sales returns are posted to the same accounts as sales revenues.
Most Greek companies discriminate between sales and sales returns by postings to different G/L
accounts (e.g. 7000000000 and 7095000000). This distinction is due to certain legal requirements
that imply - but not explicitly impose - this feature. In this case we have to use at least two Account
Determination Procedures one for Returns and one for Sales, Credits, Debits.

Extract of the account determination table (no branches, no different revenue account, no diff. tax):

App CndTy ChAc SOrg. CAAG MAAG ActKey G/L account


V JINV CAGR 0001 01 00 ERL 7000000000
V JINV CAGR 0001 01 00 ERS 7098000000
V JINV CAGR 0001 01 10 ERL 7100000000
V JINV CAGR 0001 01 10 ERS 7198000000
V JRET CAGR 0001 01 00 ERL 7000000000
V JRET CAGR 0001 01 00 ERS 7098000000
V JRET CAGR 0001 01 10 ERL 7100000000
V JRET CAGR 0001 01 10 ERS 7198000000

Note:
In the case of the “Free goods with posting “ scenario, account determination differs in that,
- a new cash account procedure must be defined so as to debit expense account instead of
reconciliation account.

© SAP HELLAS S.A. 66


Localization Process SAP ERP 6.0 Country Manual

- a different condition table could be used (standard SAP table).


- a new account allocation key is defined (namely JKL0) so as to credit the relevant revenue
account.

6.4 Special Business Transactions

6.4.1 Special Business Transactions - Cancellations

Cancellation of sales order


An order without subsequent documents can be deleted.

Cancellation of deliveries
A delivery can be deleted provided that it has not been posted. A delivery that has been posted can
be first GI cancelled and then deleted.

Cancellation of billing documents


In case of incorrect pricing, a billing document can be cancelled by a cancellation-billing document.
The previous document (order or delivery) remains open to be billed again.

Cancellation of goods issues


In Greece, the standard practice for dealing with wrong Goods Issues, is the cancellation of the
wrong delivery with a reverse inventory movement, which will reset the open order quantity to the
original status, so that a correct delivery can be made.

Cancellation of a transaction

The cancellation of a whole transaction .(incorrect quantities & prices) consists of cancellation of
billing (reversing FI document), cancellation of GI (reversing MM document), deleting delivery,
rejecting the sales orders.

For this case the following program has been developed (J_2GLPCANCELSD)

This program cancels SD deliveries and billings and prints the appropriate documents If the
inputted document is a delivery the program cancels the GI document and the user has the ability to
delete the delivery afterwards, thus releasing the stock holded in the delivery. The user has also the
ability to reject all line items of the orders with rejection reason ZZ. If the inputted document is a
billing the user is asked to either cancel the billing only-values- ( in case the billing is not a TDA )
or cancel the delivery too --values and quantities ). If the billing has come from a lot of deliveries
the user can only cancel the billing. The individual GIS have to be cancelled manually with VL09 in
that case. In case of TDA the billing and the delivery will be cancelled. Again the user has the
ability to delete the delivery and reject the order line items whenever the GI is cancelled.
If the document is a TDA the print task code to be used for printing the cancellation ( billing-
delivery ) must be specified in the field J_2GLPP1-CPRNTSK1 of the TDA print task code and
must be a TDA itself. If the document is a DA the print task code to be used for printing the
cancellation GI must be specified in the field J_2GLPP1-CPRNTSK1 of the DA print task code and
must be a DA itself. If the document is a TIM and the delivery will be cancelled too , then the
cancellation can be printed as
TDA or DA and TIM. If the field J_2GLPP1-CPRNTSK2 of the TIM print task code has a value

© SAP HELLAS S.A. 67


Localization Process SAP ERP 6.0 Country Manual

then we will print as TDA otherwise as a TIM and DA getting the values form the J_2GLPP1-
CPRNTSK1 field of the TIM and DA documents.

VL09
The program J2GLPVL09 instead of VL09. The program behind the
transaction is J_2GLPCANCELGI and is a copy of the standard SAP
with specific changes to allow input of the cancellation date in
batch mode.

6.4.2 Special Business Transactions - Deliveries free of charge

In Greece, when a company offers items free of charge to its customers, it has to pay the sales tax
(VAT- ) on the item cost price to the State. Therefore a posting is made of the following
type:
- credit of a special sales revenues account with the cost value
- credit of a special tax account with the VAT value on the cost
- debit of a special expense account

- The deliveries free of charge should be differentiated from normal sales by using a different MM
movement type (SD & MM customizing)

For the rest of the cases , with the use of cash account determination and revenue account
determination SD could make the appropriate postings through standard customizing.

6.4.3 Special Business Transactions – Rebates

Rebates are quite common in Greek companies and they are covered by std SAP Functionality.

6.4.4 Special Business Transactions - Retail sales


In Greece, retail sales comprise the following SD-related issues:

- Pricing: VAT is included in Gross price


- Transactions: The Billing and the Incoming payment transactions are considered as one step
- Forms: The customer receives only a receipt upon payment instead of an Invoice and then a
receipt.
- In the Annual Sales & Purchases report all retail sales appear cumulatively and not per
customer code.

For the handling of the above-mentioned requirements SAP Hellas proposes the creation of a fast
entry tool, where the Sales order - Delivery - Billing - Incoming Payment transactions will be
unified.

(The incoming payment transaction can be produced automatically through standard payment cards
functionality.)

6.5 Legal Forms


In Greece, every company needs specific programs to be used for outgoing paper documents (such as
delivery notes, billing documents etc.), since the standard SAP document printing does not cover the
legal requirements.

© SAP HELLAS S.A. 68


Localization Process SAP ERP 6.0 Country Manual

Examples of Documents that must be printed are the following:


- Delivery Note
- Invoice
- Credit memo
- Goods receipt
- Cancellations

Issuing paper documents can be multi copy pre-printed papers that already include a pre-printed
sequential number used for avoiding misuse or simple printouts produced by laser printers. After
printing these documents, they will comprise three numbers:
- pre-printed number
- SAP document number
- Reference number

6.5.1 Legal requirements


- Printing is done through specific layout forms for each case. The three basic layouts are the
delivery note, the billing document and the combined delivery note-billing document.
- Every posting to FI and MM must be printed and assigned to legal series and numbering.
- The legal paper number must be unique, and must be incremented as the date increments.
- Gaps between the numbers are not allowed.
- Printing with a previous date than the one the last document was printed, is not allowed.
- Usually a document results from another business transaction, which must be referenced with its
legal number. (Example: Invoice - Delivery Note.)
- For the combined document to be printed, the delivery note and the Invoice must be identical.
- The Payer and the Ship-to party must be printed on the legal papers.
- Updating the document with the legal number must be done at printing.

The programs developed for legal document printing are necessary, mostly because at posting a
document there is no way of knowing the assignment that has to be made between the standard and
the Greek legal paper number.

6.5.2 Customizing for legal documents

A. Important tables:

- J_2GLPLK and J_2GLPLKT : Logical kinds and their description

Logical kinds identify the type of the document to be printed, and the necessary data to be collected.
Example of a logical kind: Invoice
These tables shall not be maintained by the customer.

- J_2GLPLP and J_2GLPLPT : Logical papers and their descriptions

Logical papers check the several document types that can be printed per logical kind. Retrieving the
reference document through a specified path (VBFA path) is performed at this stage.
For example:
We have the logical kind TIM ( Invoices ) and two logical papers of the same logical kind : Simple
invoice ( )and a Cancellation invoice ( ). Although both logical
papers belong to the same logical kind they may allow different sets of Billing document types.

© SAP HELLAS S.A. 69


Localization Process SAP ERP 6.0 Country Manual

- J_2GLPP1, J_2GLPP2, J_2GLPP3: Print task codes with series and numbering

Print task codes are company dependent and are a refinement of a logical paper. They belong to a
logical paper. They also belong to a logical kind. The logical paper and logical kind will dictate the
way the print task code will be processed.

Print task code is a required parameter when issuing Greek legal Paper Documents with the printing
programs.

Print task code specifies the layout set to be used for the printing and the printer where the Greek
legal Paper Document will be send to.

Print task codes specify the following parameters for a document:


Printer
Layout set
Series and numbering
Logical paper
Last date of a printed document

IMPORTANT NOTE : During setup of the print task codes we should follow the rule : No two
print task codes that offer numbering ( do not have reference print task codes ) should have the
same SERIES and STEXT ( ). This is checked in the printing programs as it may lead
to the scenario of two different Greek legal Paper Documents having the same numbering. Also
print task codes that reference others must share the same STEXT ( )

- J_2GLPLEGDOC is a table in which the records of printed and non-printed SAP documents are
kept.
- J_2GLPPR specifies the pricing procedures and the condition types used.

B. Printing programs for legal documents from SD :


J_2GLPPSD The main program file for processing Billing documents
J_2GLPTIM Process logical kind TIM
J_2GLPDATIM Process logical kind
J_2GLPPSDUTILITIES General utilities ( popup dialogs )
J_2GLPPSDCUSTROUTINES Routines that you might want to change-customise

J_2GLPPDL The main program file for processing Delivery documents


J_2GLPDASD Process logical kind (SD)
J_2GLPPDLUTILITIES General utilities ( popup dialogs )
J_2GLPPDLCUSTROUTINES Routines that you might want to change-customise

Common files to all printing programs


J_2GLPPTCODESUTILITIES Print task code checks & collect information
J_2GSCRP0 SAPscript library
J_2GBII00 Batch input utilities
J_2GLPEXIT0 User exits for further tests on logical papers.
Read the program for directions.
J_2GLPPARASTRUCTURES Libraries utilities data structures logical kinds
TIM, , (SD), (MM)
J_2GLPPARALIBRARIES Library utilities for logical kinds TIM, ,

© SAP HELLAS S.A. 70


Localization Process SAP ERP 6.0 Country Manual

(SD), (MM)

IMPORTANT NOTE : Be careful when making changes to the last two files because some
routines apply to all logical kinds.

Other programs
J_2GLPUPDATELEGALDOCUMENTS : Updates SAP documents
according to J_2GLPLEGDOC and
J_2GLPDOCSFI (FI Logical Kinds)
J_2GLPXVBRK: Repairs FI documents with awtyp
field XVBRK.
J_2GLPPRFL0: Fill up J_2GLPPR from the SD pricing procedures.
J_2GLPBLOUT: For output determination in Billing in order to insert an entry in
J_2GLPLEGDOC at billing creation
J_2GLPMMUSEREXITFORDELIVERIES: In order to insert an entry in J_2GLPLEGDOC
at MM document creation

C. Checks provided in legal document printing

PROGRAM J_2GLPPSD : Checks made on logical kind


1. The Billing document type is compatible with the print task code allowed billing document
types.
2. If the Billing document is FI relevant ( vbrk-rfbsk ne ‘D’ ) there exists exactly one FI document.
3. There is at least one billing line item.
4. All reference documents ( ) have a legal association ( printed )
5. All reference documents are either billing or delivery documents.

Documents to be updated with the legal number

The FI document in case the Billing document is FI relevant.

PROGRAM J_2GLPPSD :

Checks made on logical kind


1. There is at least one billing line item.
2. The Billing document type is compatible with the print task code allowed document types.
3. Determine if the billing is a cancellation billing.
4. There is exactly one delivery involved for the whole billing document and all billing line items
came from this one and only delivery.
5. If the billing is a cancellation billing check that the delivery is the delivery of the cancelled
billing.
6. The delivery type is compatible.
7. The delivery has been post goods issued.
8. The billing date is the same as the post goods issue date of the delivery.
9. All delivery quantities in the Delivery document are found in the Billing document.
10. There is exactly one FI document for the billing.
11. There is an MM document associated with the delivery and there is either no FI document
associated with it or there is exactly one.
12. All reference documents ( ) have a legal association ( printed )
13. All reference documents are either billing or delivery documents.

© SAP HELLAS S.A. 71


Localization Process SAP ERP 6.0 Country Manual

Documents to be updated with the legal number


The FI document of the Billing Document.
The MM document of the Delivery document.
The FI document of the MM document if it exists.

PROGRAM J_2GLPPDL :
Checks made on logical kind (SD)
1. The Delivery document type is compatible with the print task code allowed document types.
2. There is an MM document associated with the delivery and there is either no FI document
associated with it or there is exactly one.
3. The delivery belongs to the company code selected by the user.( Check against the sales
organisation of the delivery).
4. There is at least one delivery line item.
5. The delivery has been post goods issued.
6. All reference documents ( ) have a legal association ( printed )
7. All reference documents are either billing or delivery documents.

Documents to be updated with the legal number


The MM document of the Delivery document.
The FI document of the MM document if it exists.

INDEX OF SD USER EXITS INCLUDED IN GREEK LOCALIZATION:

VOFM Related
J_1GRV07A913 10-days check and ‘never cancel twice’ check
Goods Issue Requirements
J_1GRV61A907 Domestic Free Goods
Pricing Requirements
J_1GRV64A901 Free Goods Cost
Pricing Formula: Condition Value
J_1GRV64A902 Free Goods Tax
Pricing Formula: Condition Value
Enhancements
J_1GZXVVFU02 SD-FI Interface: Text in A/R line of Accounting Document
J_1GZXVVFU03 SD-FI Interface: Text in Cash Clearing of Accounting
Document
J_1GZXVVFU04 SD-FI Interface: Text in G/L line of Accounting Document
J_1GZXVVFU06 SD-FI Interface: Text in Tax line of Accounting Document

EAFDSS and application in Greece

According to legislation (Article 10 of Law 3052/2002 and POL 1234/2002, POL 1257/2002 and
POL 1284/2002) all companies that use computers for printing documents for goods transfer and
billing, are obliged to validate every document with a 'digital signature'.
Goals of this decision are:
1) to outplace the punching of the documents (Delivery Notes, Invoices etc) in the respective Tax
Office Authorities
2) to fully secure the transactions in terms of tax reporting

© SAP HELLAS S.A. 72


Localization Process SAP ERP 6.0 Country Manual

3) to reduce the costs of filing and buying the respective papers


4) to facilitate the direct check and control of the originality of the documents etc

Even companies that have been previously allowed not to punch these documents (because of
revenue and personnel number) are subject to this legislation.
This 'digital signature - ' has to be issued by a specially designed device called " "
which is linked to the computer through the serial port and has applied the Secure Hash
Algorithm(SHA-1) for generating this unique 77 character number (consisting of machine no, etc).
These devices must be approved by the Ministry of Finance and an interparty commitee that fully
complies with the legislation.

On top of that there is a requirement to produce 3 txt files every day (a,b,c) containing the
documents (all data), the daily digital signatures and the daily signature that replaces all the others
(so called z). These files have to be stored either in file server, PC hard disk or CD-ROM's etc and
should be available for Tax-audit.

There are 2 approaches for solving the above mentioned issue:

Solution A

In this case the H/W vendor provides both H/W (device) and S/W that complies with the legal
requiremets and some modifications may be required into the SAP environment regarding the use of
saplpd for printing these documents (they have to be ASCII and nott bitmap). Also depending on
ther number of devices needed there should be somehow declared to the SAP system.There is at
least one solution available of this type in the Greek market.

Solution B

In this case the s/w house has to modify it’s application in order to be able to co-operate with one of
the approved devices.The general philosophy of how this will work is the following:
SAP printing program is going to have an RFC before printing to a C program that will then
communicate with the device protocol, gets the unique sign and then returns to SAP and prints the
document. All printing programs changes and C program are part of the SAP ERP Enterprise
Hellenization package. Further info can be found in SAP Note 647873.

7. MM Topics Covered by the Localization Process

7.1 Master Data

7.1.1 Accounts

7.1.1.1 Structure of Material Accounts

The typical accounts that are used in SAP ERP materials management are the following:

I. Compulsory Accounts from the Unified Greek Chart of Accounts


A. Opening & Closing Stock Balance (20.00 for Trading Goods, 21.00 for finished and
semi finished products, 24.00 for raw and packaging materials etc)
B. Purchases (per material type 20.01.01, 24.01.01 etc)
C. Imports - Purchases (per material type 32.01.24.0000, 32.01.20.0000 etc)
D. GR/IR - Purchases to be settled (58.2X)

II. Forecast or Information Accounts

© SAP HELLAS S.A. 73


Localization Process SAP ERP 6.0 Country Manual

A. Stock Account (per material type)


B. Cost of Sales (per material type)
C. Cost of Consumed Materials to Production (per material type)
D. Offsetting Purchasing Account (per material type)
E. Account for Clearing Accounts (per material type)
F. Price Difference on Purchases (per material type)

The above-mentioned forecast accounts are compulsory for quantity and value managed materials
for standard SAP. Following the Unified Greek Chart of Accounts these accounts are used only for
information purposes. Similar to the forecast accounts are the accounts in the analytical ledger e.g.
the stock account is similar to the ‘Continuous Inventory Stock’ Account (94.2X.) etc.

A typical G/L Account list is given below for trading goods:

2000000000 OPENING STOCK BALANCE FOR TRADING GOODS


2000003000 OPENING STOCK BAL. FOR TRADING GDS THIRD-PARTY
2001000000 PURCHASES DOMESTIC TRADING GOODS
2001000010 PURCHASES E.C. TRADING GOODS
2001000020 PURCHASES THIRD COUNTRIES TRADING GOODS
2099000000 PROVISIONS STOCKS OF TRADING GOODS
2099000201 COST OF CONSUMED TRADING GOODS TO COST CENTER
2099000261 PROVISION-COST OF CONSUMPTION TRAD.GDS TO ORDER
2099000555 PROVISIONS-COST OF SCRAPPING TRADING GOODS
2099000561 PROVISIONS-OFFSETING INITIAL STOCKS TRADING GOODS
2099000601 PROVISIONS-COST OF SOLD TRADING GOODS
2099000701 PROVISIONS INVENTORY DIFFERENCES TRADING GOODS
2099002000 DEVIATION ON PURCHASES GOODS
2099003000 PROVISION STOCK OF TRADING GOODS THIRD PARTY

2099003561 PROV.-OFFSET. INIT. STOCKS TRADING GDS THIRD-PARTY


2099003701 PROV. INVENTORY DIFFER. TRAD. GOODS THIRD-PARTY
2099009000 PROVISIONS FOR REVALUATION GOODS
2099009999 OFFSETING ACCOUNT GOODS
2099999999 PROVISION CLOSING STOCK BALANCE TRADING GOODS

7.1.1.2 Compulsory Accounts from the Unified Greek Chart of Accounts – Characteristics

The accounts are posted according to the following principles:

I. The Opening & Closing stock balance account is posted once a year at the close year
procedure and is transferred to the next year. This account should have the same balance
with the stock account at the year-end for reconciliation reasons.
II. The value of purchases should be debited to the Purchasing account. The purchase value
should be shown in the accounts of group 2. The postings are:
A. At the goods receipt
1. The value debited to the stock account (2 .99) would be debited to the
‘Continuous Inventory Stock’ Account (94.2X.) of the analytical ledger and
an interim account 582X would be hit.

© SAP HELLAS S.A. 74


Localization Process SAP ERP 6.0 Country Manual

2. The price differences (2X.99.) correspond to the debits of the ‘Price


Difference’ account (95.2X) of the analytical ledger only in the case of std
cost being the official valuation method of the company.
3. At SAP the price difference account is defined as a Profit & Loss account.
Following the Greek practice this should be a balance sheet account. Part of
the price difference is relevant to the remaining stocks and part of the
difference should be used to adjust the values at the consumption accounts.
Therefore part should adjust the cost of goods sold and part the expenses
(inventory differences etc.). Interim results are more easily calculated, using
the price difference accounts as P/L accounts. For the year-end the
differences should be allocated, where appropriate.
B. After the invoice receipt the actual purchasing value is debited with the use of a
batch program, as this is shown to the vendors’ and other creditors invoices and
credit invoices. The purchases should reconcile with the purchases shown at the
warehouse book. It is against the typical Greek practice that the invoice value is a
result of several postings at the purchases, as it is considered to make more difficult
the tax audit.
C. The 32.01.2X.0000 and 32.01.2X.0001 accounts are posted instead of the
purchasing accounts, when a material is imported. These accounts are balance sheet
accounts and are cleared to the purchasing accounts. Therefore the structure at the
two groups of accounts should be similar. The criterion should be the purchase order
line item, which should be updated at the allocation field apart from the sort criterion
of the accounts, which should be the PO number as well.

III. The GR/IR account exists as a compulsory account in the Unified Greek Chart of Accounts.
The practice is that it is used only at the year-end. According to the requirements of law 270
the account to be hit in cases of GR and not IR is the account of periodic allocation of
expenses 58.2 X where x = 0,4,5,6,8 according to material types 0 = trading goods, 4 = raw
materials, 5 = consumable stock materials, 6 = spare parts and 8 = ret.packaging.

7.1.1.3 Forecast Accounts - Characteristics

The Forecast accounts are in the group 2X.99 depending on the material type. These accounts have
the following characteristics:

1. The balance at transactional level of the 2X.99 accounts should be equal to zero whenever a
quantity is received/withdrawn from the warehouse except for the Goods Receipt for purchase
order where the GR/IR account is also used. These Forecast accounts should not interfere with
the compulsory accounts, as the company’s results should be calculated following the
compulsory accounts.
2. The Forecast accounts can be used for the interim closings during the year and for real time
information.
3. The forecast stock account carries the best-estimated value of the company’s stocks. It is debited
when a material is received and credited when it is issued. This account is automatically posted
only and can have a debit or zero balance. It is a balance sheet account and should be carried
forward to the next year, together with the ‘Forecast clearing’ account.
4. The purchasing account is always offset by the offsetting purchasing account in order to close
the 2X99 balance to zero together with the 58.2X.
5. Values for all issues are debited to consumption Forecast accounts. These accounts can be used
to calculate interim results during the year.
6. The Forecast Clearing accounts are used for the clearing of all P/L Forecast accounts at year-
end.

© SAP HELLAS S.A. 75


Localization Process SAP ERP 6.0 Country Manual

7.1.1.4 B/S and P/L Accounts

Material Management group 2 accounts are B/S and P/L in terms of SAP.

In general B/S are the following accounts:


Stock Account
Purchasing
Clearing
GR / IR

P/L are all consumption and, in general, offsetting stock accounts, as:
Cost of goods produced (forecast)
Cost of goods destroyed (forecast)
Cost of goods sold (forecast)

The price difference account (PRD) is normally P/L (compulsory for multinational companies
where it is defined as P/L in their primary chart of accounts, for example),
but it could also be defined as B/S (prefer B/S if a part of it is to be apportioned to B/S accounts).
All following discussions will assume that PRD is a P/L account.

The basic principle is that whatever needed in CO must be cost element and, as a result, a P/L
account.

7.1.1.5 Price Differences Accounts in Materials Management

In SAP ERP every movement of a material (at plant level ) that has quantity and value update,
produces a financial effect (accounting document). Different Accounts are posted for different
categories of materials. This is done via the combination movement type/value string/valuation
class. Accounts and relevant automatic account assignment are described elsewhere in this manual.
In this topic we will focus on the Price difference account.

Price Difference Account

Moving Average Price Control

Content and Basic Characteristics

At the arrival of an invoice or a credit invoice, the given account is hit only if the Stock Account
Balance refers to quantity less than the one referred in that Credit Invoice or the Value Difference
of the invoice.
It is an account, which is supported at the standard Material Management in SAP. Its use is
compulsory from SAP standard postings. The account number given is 2X99002000.

Properties

It depends on the valuation class of the materials.


It is a P/L type account in terms of SAP.
The postings are done via the key PRD.

Standard Price Control

Content and Basic Characteristics

© SAP HELLAS S.A. 76


Localization Process SAP ERP 6.0 Country Manual

The difference between the standard price and the Purchase Order price is posted in the account at
the goods receipt. At the invoice receipt, the posting is such that in the account the difference
between the standard price and the invoice value is finally posted. It is an account, which is
supported at the standard Material Management in SAP. It’s use is compulsory for std SAP
postings. The account number given is 2X9900200 - for company code 0001.

Properties

It depends on the valuation class of the materials and the plants.


It is a P/L type account in terms of SAP.
The postings are done via the key PRD.

Important Notice 1

The meaning of the price difference account for standard and moving average price controlled
materials is different:

For Moving Average Price controlled materials, the account is rarely hit and is not used for any
control purposes, but only to keep the correct moving average price

For Standard Price controlled materials, the account is used as a tool for controlling the standard
price.

General Ledger Relationship

As in SAP this account is declared as P/L account type, its balance has to be closed with postings in
year end (transfer to clearing account of forecast accounts of group 2).

Analytical Ledger

This is a special Greek autonomous financial system which aims to determine the cost of
purchased/consumed/produced goods of a company, the gross and net results of the company per
material class, the cost of the basic functions of the company(Management, Production, R&D, Sales
and Distribution etc) and the analytical follow up of the material stocks and movements of a
company.

According to the relevant legislation and provided that the company keeps track of standard cost
the differences between standard and actual cost which equals the price variances must be posted to
the account 95 (Variances from the standard cost). Of course the section of Materials price
variances is one of the sections this account has.

With the aim of SAP Hellas’s Analytical Ledger applications all the price variances of purchased
goods are transferred to the respective Analytical Ledger accounts.

Moreover, these price variances should be split among the quantities of goods remaining to stock
and the ones that were sold/consumed in production. According to the legislation that requires
determination of analytical results every month, this exercise has to take place every month so that
the stocks will be valuated at actual cost and the result of the company will include the price
variances (Loss or Gain).

Additionally to what was described so far, in SAP there is one more case where a price variance

© SAP HELLAS S.A. 77


Localization Process SAP ERP 6.0 Country Manual

account is posted. This happens when the production order is settled. In such a case the production
order has gathered in the debit side the costs of materials, labour costs and overhead and in the
credit side the cost of materials produced (at std or map). If this balance is not zero the settlement of
production order provides the actually produced quantity of the material with this variance. These
variances are also transferred to 95 Accounts.

Year end closing/Periodic closing in Materials Management

See End of this chapter for Law 270 paragraph 7.8.

7.1.2 Materials managed on a quantity and value basis

7.1.2.1 Analysis of the Materials Accounts in the Unified Greek Chart of Accounts

The required analysis in the unified chart of accounts for the material accounts (Purchases and
Opening Stock Balance) is the following:

First Level Accounts Description


20 Trading goods
21 Finished and Semi-finished Products
22 By Products
24 Raw material
25 Consumption
26 Spare parts
28 Returnable Packaging

7.1.2.2 Material types

It is suggested that the material types follow the structure of the accounts in the Unified Greek
Chart of Accounts. The codes are similar to the compulsory account numbers.

Material Types
Code Description (E) Description (G)
2000 Trading goods
2100 Finished product
2101 Semi-finished product
2200 By-products
2400 Raw material
2401 Packaging
2500 Consumables
2600 Spare parts
2800 Returnable Packaging

The analysis is not mandatory but the respective customizing is included in the MM customizing
transport.

© SAP HELLAS S.A. 78


Localization Process SAP ERP 6.0 Country Manual

7.1.2.3 Valuation Class

Given the required analysis of the Greek compulsory accounts the following valuation classes are
suggested to a company operating in the Greek market.

Valuation Class
Code Description (E) Description (G)
2000 Trading Goods
2100 Finished
2101 Semi-finished Products
2200 By product
2400 Raw Material
2401 Pack. Material
2500 Consumption material
2600 Spare Parts
2800 Returnable Packaging

The analysis is considered the minimum required, it can be extended though to the one required by
the company.

7.1.2.4 Relation of Material Type, Accounting Category Reference and Valuation Class

An example of the link of the material type to the valuation class can be the following. No
restrictions exist for the account category reference.

Material Accounting Valuation


Type Cat. Reference Class
2000 0005 2000

2100 0009 2100


2101 0008 2101
2400 0001 2400

2401 0004 2401

2200 0007 2200


2500 0002 2500
2600 0003 2600

2800 0006 2800

7.1.3 Other Materials & Services

A company may purchase materials and/ or services that are not kept in stock. The relevant invoices

© SAP HELLAS S.A. 79


Localization Process SAP ERP 6.0 Country Manual

are posted directly to the expense accounts. The required analysis of the expenses is very extensive
and can be found to any Greek accounting books regarding the Unified Chart of Accounts. For such
materials, additional valuation classes will have to be set up in order to hit automatically the correct
expense accounts. Therefore valuation classes could be defined following the compulsory accounts
in the Unified Greek Chart of Accounts at group of accounts.
Please note that the compulsory accounts descriptions are written in bold.

7.2 Business Processes

7.2.1 Buy

Import of materials

Three following basic scenarios will be described :


a. Transporter’s invoice after vendor’s invoice receipt
b. Transporter’s invoice before vendor’s invoice receipt one expense updating MYF
c. Transporter’s invoice with two expenses updating MYF (irrespectively of vendor’s invoice
status).
d. Customs Broker Invoice

a. Transporter’s invoice after vendor’s invoice receipt.


This is entered as a subsequent invoice.

b. Transporter’s invoice before vendor’s invoice receipt one expense updating MYF.

The entry will be through FI since there is no Invoice Receipt of the Vendor to reference in MM.
Normally the transportation invoice will consist of two expenses, the freight expenses and the agent
fees. The case of this scenario one of the expenses update MYF therefore the entry is the following :
The entry will be through FI and MM. The entry in FI is a simple entry of invoice where the
customs broker account is credited and the Import PO and VAT accounts are debited.
Case

Type of MYF Document Type VAT Tax Code Due for Comments
Expense Payment
Freight NO R* 0% 0A YES Freight Expenses
Exempted
Agency YES R* 19% 0A YES Agency Fees
VAT 19%

The entry will be through FI and MM. The entry in FI is a simple entry of invoice where the
customs broker account is credited and the Interim Account of Purchases Import is debited.

Transporter 320000099 VAT


5400…
357 300 57

The MM posting will be an invoice receipt which does not update MYF and with 0 tax. The
custom’s broker will be credited with 0 because he has already been credited by FI. The postings

© SAP HELLAS S.A. 80


Localization Process SAP ERP 6.0 Country Manual

are similar to the postings of an ordinary invoice.

Transporter Stock Account Import PO Offsetting


2X99000000 3201.X00000 Purchasing
0 300 300 300

With this posting the accounting article is not complete. For this reason another analytical line will
be inserted (Edit > New Line > G/L account) in order to credit an additional account. This account
is 3201000099.

3201000099
300

The accounting article is complete.

c. Transporter’s invoice with two expenses updating MYF (irrespectively of vendor’s invoice
status).

The entry will be through FI since there is there are two expenses to enter that update MYF with
two different tax rates. This invoice receipt can not be entered only through MM because in MM
only one of the two taxes can be entered for the invoice and it is a necessity for MYF that only one
invoice is shown but with two different tax rates. This problem is bypassed by entering the invoice
through FI where two different tax rates can be entered.

The entry will be through FI and MM. The entry in FI is a simple entry of invoice where the
customs broker account is credited and the Import PO and VAT accounts are debited.

Case
Type of MYF Document VAT Tax Code Due for Comments
Expense Type Payment
Freight YES RE 0% 0A YES Freight Expenses
Exempted
Agency YES RE 19% 0A YES Agency Fees
VAT 19%

The entry will be through FI and MM. The entry in FI is a simple entry of invoice where the
customs broker account is credited and the Interim Account of Purchases Import is debited.

Transporter 320000099 VAT


5400…
357 200 57
100

The MM posting will be an invoice receipt which does not update MYF and with 0 tax. The
custom’s broker will be credited with 0 because he has already been credited by FI. The postings

© SAP HELLAS S.A. 81


Localization Process SAP ERP 6.0 Country Manual

are similar to the postings of an ordinary invoice.

Transporter Stock Account Import PO Offsetting


2X90940000 3201.X00000 Purchasing
2X90900000
0 300 300 300

With this posting the accounting article is not complete. For this reason another analytical line will
be inserted (Edit > New Line > G/L account) in order to credit an additional account. This account
is 3201000099.

d. Customs Broker Invoice (after vendor’s invoice receipt).

The Customs Broker Invoice will incorporate several (attached to his invoice) invoices that have
been paid by the Customs Broker. In this case the attached invoices are entered through MM as
subsequent invoices with the corresponding tax code and document type but blocked for payment
since the Customs Broker has paid them already. With this entries the vendors of these expenses
have been credited but this is incorrect since the Customs Broker must be credited for these
amounts. Therefore through FI the Customs Broker account will be credited and the vendors
accounts will be debited the specific amounts that were initially credited through MM.
The Customs Broker normally pays the VAT on the price of the material that the
Customs are calculating according to specific currency exchange prices. This amount is called
‘Plasmatiki Axia’. In order to enter this posting two Information Accounts are debited and credited
with an amount which with tax code 18% VAT will result to the amount of VAT the Customs
Broker paid to the Customs. The VAT account 540020000 is automatically debited and the
Customs Broker Account is credited manually the resulting VAT amount on the ‘Plasmatiki Axia’.

Purchase with EIN process deactivated

Quantity Total Value Moving Average


Purchase Order 10 100
Goods Receipt (1) 10 10
Invoice Receipt (2) 120
Update by program 10 120
(3)

Stock GR/IR Purch.


(1) 100 100 (1) (3) 120
(2) 20 (2) 100

Vendor Offsetting .
120 (2) 120 (3)

© SAP HELLAS S.A. 82


Localization Process SAP ERP 6.0 Country Manual

7.2.2 Sell

7.2.2.1 Normal Sale

7.2.2.1.1 Goods Issue for Sale

This movement is carried out at the delivery of the SD module.

Goods Issue for Sale

Unlike the Greek accounting practice, where no posting is carried out at the goods issue, a posting
will be carried out, as shown in the following case.

Case:

Quantity Total Standard Price or


Value Moving Average
Goods Issue (1) 10 10

Stock CoS
100 (1) (1) 100

This is the real time valuation price and is used in CO-PA and for on line information. It is not the
actual cost of sales that has to be recalculated at period/year end through the equation mentioned in
other chapter.

7.2.2.1.2 Return from Customer

This movement is carried out at the delivery of the SD module.

Goods Receipt to Blocked Stock (mvt. 657) or Good receipt to unrestricted stock (653) etc

Case:
Quantity Total Standard Price or
Value Moving Average
Goods Receipt (1) 10 10
Stock Transfer (2) 10 10

Stock CoS
(1) 100 100 (1)

© SAP HELLAS S.A. 83


Localization Process SAP ERP 6.0 Country Manual

7.2.2.1.3 SD - MM Interface Required Movement Types

In SAP ERP most of the warehouse movements that concern sales of products/other materials are
covered through the SD functionality where the schedule line category is linked with the movement
type. Because there are requirements concerning the warehouse book and the legal documents
(printouts) as far as the type of movement is concerned the following were defined with respect to
‘Hellenisation’. The list is only a proposal and can be further extended.

Sales from unrestricted stock 601 SAP std


Cancellation of sales from unrestr. 602 SAP std
Stock
Returns to unrestricted Stock 653 SAP std
Returns to blocked Stock 657 SAP std
Cancellation of return to unrestr. 654 SAP std
stock
Cancellation of return to blocked 658 SAP std
stock

During implementations it was found that the only way to identify this kind of movements and
separate the automatic account assignment from MM was to have these separate movements. Also
from an inventory management point of view there is a need to have summarised reports per
movement type so it is easier to have information if different mov. types are used for the various
business transactions.

7.2.2.4 Samples

Standard SAP functionality for consignment stock at customer can be used.

Goods Issue to Customer consignment stock


Goods Return from Customer consignment stock

Goods Issue to Customer consignment stock: From the ‘Sales’ Plant the fill up of the consignment
stock can be carried out with MM movement type 631, straight from the SD module.

No accounting document is created for this movement

Goods Return from Customer consignment stock: From the ‘Sales’ Plant the reverse fill up of the
consignment stock can be carried out with MM movement type 632, straight from the SD module.

No accounting document is created for this movement

The material when issued to a consignment stock:

remains debited to the plant that issued the material


no more debited to the specific storage location

© SAP HELLAS S.A. 84


Localization Process SAP ERP 6.0 Country Manual

is debited to the stock type customer consignment stock

It is possible to monitor the consignment stock per customer, via the warehouse book, where the
stock per customer is shown separately as it should.

Alternatively to this scenario a solution with different plants and material movements can be used
but it requires more transactions in the system. The FI posting in these cases is specific (Account 6..
with account 78) and is usually done through FI. (There is a report, which gathers all these
movements for VAT Purposes).

7.2.2.5 Collective Delivery

The case of the sales person selling door-to-door materials debited to him with a collective delivery
note can be resolved as follows:

Plant To Plant Stock Transfer (from the actual plant to the plant ‘Sales’ where the sales person
can be defined as a storage location) - Printout of the collective delivery note with the quantities
received
Sell from plant ‘Sales’ - hand-written update of the collective delivery note, computerized issue
of the invoice-delivery note

7.2.3 Make

7.2.3.1 Own Production

7.2.3.2 Subcontracting (Procedure, Solutions, Problems)

In SAP ERP there is a possibility to use the standard functionality that can represent special
business scenarios like Subcontracting

7.2.3.2.1 Materials Provided to Vendor (Subcontractor) - Scenarios

It is used for providing materials at a third party, which uses them for producing a new material
(either finished product, banded material, semi finished product etc). The ownership of the material
is always of the company code that issues the materials.

There are various ways to represent this scenario in SAP:

Alternative Description PROS CONS


1 Each Third Party to All Material Possibly Many
be a different plant Movements create an Plants will be
Accounting Document created
No use of the
Standard SAP
Functionality
The
Subcontractor’s
Invoice will be
posted through FI

© SAP HELLAS S.A. 85


Localization Process SAP ERP 6.0 Country Manual

2 Each Third Party to There is no need to Stock Movements to


be a vendor under a create extra plants the Third Party do not
company owned Use of the create an Accounting
plant Standard SAP Document, so:
Functionality (a) no value can be
(Subcontracting) printed on the
The Warehouse Book for
Subcontractor’s these movements
Invoice will be (b) Third Party Stock
posted through Accounts mandatory
MM against a for Analytical Ledger
Purchase Order cannot be updated (at
least not online)
3 Each Third Party to Use of the Movements at Third
be a vendor under a Standard SAP Party plant level might
logical “Third Functionality exist, so the
Party” plant (Subcontracting) Warehouse Book will
(assigned to a The contain one extra
different Valuation Subcontractor’s Material/ Plant
Grouping Code) Invoice will be combination (the
posted through WHB has been
MM against a modified to deal with
Purchase Order most of these
Stock Movements movements)
to Subcontractor
may create an
accounting
document(so the
Warehouse Book
and AL can be
updated)
4 Each Third Party to Case 3 Case 3
be a vendor and Possibly many
plant plants should be
simultaneously created

If the facility of the subcontractor is used for delivering to customers of the company, it must be
represented as plant (in order to facilitate the Warehouse book). Otherwise, there is a need to make
additional transactions in SAP that do not physically take place (inward movement in company’s
warehouse and outward movement from it for the invoice to follow).

7.2.3.2.2 Procedure

Steps Description Reference Document WHB Comments


1 Create a
Subcontracting
Purchase Order

© SAP HELLAS S.A. 86


Localization Process SAP ERP 6.0 Country Manual

2 Goods Receipt /
Consumption of
Components
based on an
existing BOM or
the
specifications of
the PO
2.1 Goods Receipt Copy of a Consumption X Not always
at Third Party Document produced by the available
Plant Subcontractor for the
production process
2.2 Goods Receipt Subcontractor’s Delivery X
at a Company Note
Owned Plant
3 Subsequent Settlement document of the X
Settlement Subcontractor
(adjustment of
Consumed
quantities)
4 Invoice Settlement document of the
Verification Subcontractor

7.2.3.2.3 Clarifications

By the month end and especially when the third party produces goods for the company, he/she is
obliged to print a legal document called ‘Settlement’ which states what was the previous balance,
what was produced, consumed and the closing balance. It is also, the Invoice for the subcontracting
fee.

Problems that might arise (if the above procedure is not accepted)
Part of this information has to be printed to the legal books of the company and specifically to the
warehouse book. The reference document for the consumption of materials should be the
‘Settlement’ number. This is not covered by the current warehouse book report as normally the
consumption takes places every time a material is received either at the subcontractor’s plant or at
the company’s plant.

7.2.4 Other

Goods Issues like free sales, scrapping, own consumption (not for production), to fixed assets, it is
generally required by the Greek Tax legislation that the output VAT should be posted. The cost of
goods should be used as the base price for the tax calculation. The compulsory accounts to be hit
are usually defined by each company. Examples are shown below.

An accounting document may be created for each consumption or one accounting document may be
created for all postings per month per movement type.

© SAP HELLAS S.A. 87


Localization Process SAP ERP 6.0 Country Manual

7.2.4.1 Issue to Consumption

Goods Issue to Cost Centre


Accounting Posting at the VAT

The stock account will be credited and a Forecast expense accounts debited at the goods issue. An
additional posting should be carried out at the compulsory accounts.
The accounting posting to be carried out at the month end, will be against the value posted to the
Forecast expense account.

Case:

Quantity Total Standard Price or


Value Moving Average
Goods Issue 10 10

Stock Forecast Expense Special


Expense Account Sales
Account (6X.XX) Account
(78.XX)
100 (1) (1) 100 (2) 118 (2) 100

VAT
18 (2)

Note 1
All three account (Forecast Expense Account, Expense Account (6X.XX), Special Sales Account
(78.XX)) are profit & loss accounts. It is important to lead to the CO the values selected with or
without VAT. It is advised that the expense account and the special sales account are not created as
cost elements, but this is a decision to be made by the customer.

Note 2
These movements can be shown valued or not in the warehouse book depending on the approach of
the company.
Note 3
A company may choose to post the expense account with the net amount and credit the difference
that equals the VAT to a different account.

7.2.4.2 Issue to Fixed Asset

7.2.4.2.1 Description

This functionality covers the scenario of turning stock items into assets. The standard
SAP approach (credit of stock account, debit of asset account) does not cover the legal requirements
of the Greek code and is therefore not used.

© SAP HELLAS S.A. 88


Localization Process SAP ERP 6.0 Country Manual

7.2.4.2.2 Accounting Issues

The postings that must take place at the consumption of a stock item, which is turned into an asset,
are the following:

Income VAT of
Asset from use purchases VAT of
14 of stock as of fixed Revenue
asset assets 54.00.79
78.10.08 54.00.28
General X X X X
Ledger

The above postings will be manually entered from FI. In order to simplify the tax postings, a tax
code leading to both postings may be created and used during the posting of the Income account. In
MM this consumption will be entered as consumption to a cost centre (movement type 201). The
postings that will take place are the following:

Cost of
Stock consumpti
2X.90.94 on
2X.90.97
MM X X
consumptio
n.

The above is the least posting that may take place. Depending on the set up of the analytical ledger
functionality, additional postings can be made to an intermediate account (90) or a 96 account.

7.2.4.2.3 Controlling Issues

During the MM consumption, a cost centre will be debited, thus updating the CO module about the
consumption.

7.2.4.3 Quantity Differences


When quantity differences are identified, the stock account will be credited and the ‘cost of
shortages’ account debited. If an additional movement is required, this can be treated as above.
Similar procedure with above

7.2.4.4 Scrapping

Several solutions can be proposed depending on the customer.

When goods are found damaged or have reached their expiration date, following the Greek
legislation, they cannot be scrapped immediately, as this must happen when the tax authorities are
present, Therefore the materials have to be reserved for scrapping, till the day of the actual
scrapping. The reservation can occur either via the reservations functionality or via the blocked

© SAP HELLAS S.A. 89


Localization Process SAP ERP 6.0 Country Manual

stock type.

At the day of the scrapping, a delivery note has to be issued, where the receiver will be the scrap
yard. The scrap yard has to be defined as a customer, for the scrap yard to be shown at the delivery
note.

Further to the delivery note a statutory document (protokolo katastrofis) has to be issued, referring
to the values of the scrapped materials.

Again accounting postings are done only to the forecast accounts, postings to the compulsory
accounts if required will be done separately.

7.2.4.4 Plant to plant stock transfer - 2step

The plant to plant stock transfer is carried out in two steps. The first step (mvt 351) already debits
the receiving plant. The second step (mvt 101) transfers the stock from in transit to unrestricted use
stock. The second movement will not be shown to the warehouse book. There is also a possibility to
perform this transfer through SD delivery (movement types 641 and 101 are used) or through MM
with 303 and 305 movement types.

7.2.5 Special stocks and Greek legal requirements

In SAP ERP there is a possibility to use several functionalities that can represent special business
scenarios like:
1. Consignment
2. Subcontracting
3. Stock transfer via stock transport order
4. Third-party processing
5. Returnable transport packaging
6. Pipeline handling

Most of these scenarios have to do with the ownership of stock, it’s physical location and the
representation in SAP ERP and for tax purposes (Warehouse Book).The stocks can be divided to:

7.2.5.1 Own Special Stocks

Material Provided to Vendor (Subcontractor)

It is used for providing materials at a third party, which uses them for producing a new material
(either finished product, banded material, semi finished product etc). The ownership of the material
is always to the company code that issues the materials.

There are various ways to represent this in SAP (See earlier in the document)

Additionally by the month end and especially when the third party produces goods for the company,
he/she is obliged to print a legal document called ‘Ekkatharisi’ which states what was the previous
balance, what was produced, consumed and the closing balance. Part of this information has to be
printed to the legal books of the company and specifically to the warehouse book the reference
document for the consumption of materials should be the ‘Ekkatharisi’ number. This is not covered
by the current warehouse book report as normally the consumption takes places every time a
material is received either at the subcontractor’s plant or at the company’s plant.

© SAP HELLAS S.A. 90


Localization Process SAP ERP 6.0 Country Manual

Consignment Stock at Customer

Consignment material belonging to the company that is stored with the customer.
In Inventory Management you can only post initial entry of inventory data for this special stock.
Other goods movements are processed in the Sales and Distribution (SD) component.

Sales Order Stock

See earlier in the document

Project Stock

The project stock is the quantity of a material, which is held in stock for the completion of a project.
The project stock is allocated to a work breakdown structure (WBS) element. Components can only
be withdrawn for the WBS element.
Project stock can be valued or no valuated but posted to a cost collector as with sales order stock

No special care was taken in the warehouse book to cover any such cases.

7.2.5.2 Externally Owned Special Stocks

Externally owned special stocks belonging to a vendor or customer that are stored at our company.
In the SAP System the following types of externally-owned special stocks are available:

· Vendor consignment
· Returnable transport packaging

Vendor Consignment

This type of stock comprises consignment material belonging to the vendor that is stored on
company’s premises. If the materials are sold the legal requirements comprise of :

Keeping the warehouse book on quantity basis


By the end of month a legal document called ‘Ekkatharisi’ which is a kind of billing document
should be printed.

The vendor consignment functionality offered by SAP does not cover all these requirements and
so a different approach was used in some companies. The materials were defined as non valued
they were included in Warehouse Book and a separate program was developed to print this billing
document.

In case the materials are not for selling purposes but for production this approach could not be used
because no cost could be determined for the consumption of these materials. In such a case (not
used as of today) the standard SAP approach has to be implemented and the warehouse book should
be properly amended.

Returnable Transport Packaging (RTP)

Multi-trip packaging medium (such as pallets or containers) in which goods can be transported
between vendors and customers. It is the property of the vendor and is therefore not included in the
customer's valued stock.

© SAP HELLAS S.A. 91


Localization Process SAP ERP 6.0 Country Manual

Goods movements for returnable transport packaging are described in Returnable Transport
Packaging. Not dealt in the Warehouse book as there was no such requirement.

7.3 Customizing

7.3.1 Customizing in the standard SAP tables

7.3.1.1 Organization structure

All warehouses which have a separate address, should be defined as plants. Special stocks can help
to reduce the total number of defined plants.

Given the small size of Greek companies, detailed purchasing organization structure is out of scope.
Purchasing groups though are needed.

Furthermore the purchases of different plants with autonomous accounting where invoicing is
carried out, should be separated. Thus such plants should be linked to different valuation grouping
codes.

7.3.1.2 Plants

In SAP ERP the entity plant serves many functions like Planning/Production/Inventory keeping etc.
With regard to Greece the plant will be analyzed from the financial point of view (especially
bookkeeping). There are some special characteristics concerning the plant that must be addressed
here and are the following:

Plant is the Logistics entity that has an address and AFM etc that can be printed in accompanying
documents for material movements.

Plant is indirectly the level where the value of material is kept (Table MBEW) so automatically
becomes the equivalent of accounting warehouse (for tax purposes).

Relation to Warehouse Book

Most companies in Greece have to produce monthly a fiscal report including all the material
movements in quantity and some in value (purchase and sales value at least).
All these values together with other values concerning materials that are created through price
change postings, financial adjustment postings etc are in company code level and they include if
needed the entity plant. Due to this fact the level where this book must be produced and printed is
either the plant or the company code.

According to Greek legislation the warehouse book must be kept separately for every stock keeping
physical warehouse. In order to accommodate this, every warehouse where stock is kept must be
represented as plant in SAP. This assumption creates difficulties in the maintenance of data that are
at plant level (Material, BOM etc).
If the same material has more than one MARD records (storage location) it is difficult to separate
the financial postings as the tables for accounting documents (BKPF, BSEG) do not include the
field storage location.

© SAP HELLAS S.A. 92


Localization Process SAP ERP 6.0 Country Manual

7.3.1.3 Movement Types

Movement types customizing should take into account the following:


Can the movements be shown correctly in the warehouse book?
Are the account postings in the General ledger correct? Are they shown correctly in the
company’s statutory reporting?
Are the supporting documents - forms (delivery or goods receipt note) legal?

Movement types to be shown in the Warehouse Book in general:


movement types creating an accounting document should be included in the WHB
movements concerning 2 plants should be included in the WHB
movements in and out of the plant should be included in the WHB
movements “inside” the plant, where a delivery note (change of address) is required (e.g. 541)
should be included in the WHB (this rule refers to movements for special stock)

Movement types inside the plant and not like the above should not be included in the WHB, e.g.:

All material transfer movements like : Material transfer from storage location to one other
storage location (e.g. 311)
Material from Stock Type to other stock type. (e.g. 344)

7.3.1.4 T030

Example of a T030 customizing, can be found in the client 000 of the delivered system with CAGR
as chart of Accounts.A sample list is given below for trading goods

Trans Val.g Acct VClass G/L account G/L account|

BSX 0001 2000 2099000000 2099000000


GBB 0001 BSA 2000 2099000561 2099000561
GBB 0001 INV 2000 2099000701 2099000701
GBB 0001 VAX 2000 2099000601 2099000601
GBB 0001 VAY 2000 2099000601 2099000601
GBB 0001 VBR 2000 2099000261 2099000261
GBB 0001 VKA 2000 2099000601 2099000601
GBB 0001 VNG 2000 2099000555 2099000555
KDM 2000 2099002000 2099002000
PRD 2000 2099002000 2099002000
PRD PRA 2000 2099002000 2099002000
UMB 2000 2099009000 2099009000
WRX 0001 2000 5820000000 5820000000

7.3.1.4.1 Materials management exchange rate differences (KDM)

Materials management exchange rate differences occur when an invoice for a PO is posted with a
different exchange rate than the goods receipt and the material cannot be credited/debited to
because it is subject to standard price control or there is insufficient stock coverage. The relevant
key KDM should be customized exactly like the PRD key:

© SAP HELLAS S.A. 93


Localization Process SAP ERP 6.0 Country Manual

Val. Gr. Acct. Val. Account


Code Mod. Class
2000 2099002000
2400 2499002000
2401 2499012000
2500 2599002000
2600 2699002000
2800 2899002000

7.3.1.4.2 Materials management exchange rate rounding differences (KDR)

The materials management exchange rate rounding differences occur at the input of invoices in
foreign currency during the rate translation. It is then possible to have an extra automatically created
line in order to have the document balance in both exchange rates. These amounts are very small,
no more than EUR 5. The key does not depend on the valuation class therefore it cannot be posted
to the purchases. It is set up to hit the 8100990002 account, which is a P/L account. This account
should be linked automatically to a cost centre, as it is not possible to define manually a cost centre
to this automatically created line.

7.3.2 MM Reporting

7.3.2.1 Warehouse Book

See section 7.8

7.3.2.2 Warehouse Book Trial Balance

See section 7.8

7.3.2.3 Forms (Delivery Note & Goods Receipt Note)

Description of the forms will be given to the sales & distribution part of this document. Following
the same logic, the forms have to be customized to support the movement types that require the
printing of a statutory document.

The printing of documents will require some additional customizing to the inventory management
movements. For example when a material is issued for company use, the receiver may be needed to
be defined as a customer/vendor, in order to have his name and the company data printed on the
form.

7.4 Material Valuation


See section 7.8

7.5 Warehouse book


Se e section 7.8

7.6 Procedure of physical inventory of stocks and statutory requirements

© SAP HELLAS S.A. 94


Localization Process SAP ERP 6.0 Country Manual

7.6.1 General

All the Greek companies keeping own stock are obliged by the law to produce at year end the
Statutory Inventory Book. This is a report which basically presents, by material and plant, the
available at the last fiscal day quantity of each material and the corresponding value. This value is
calculated using a unit rate which is the minimum of the following three : (a) the calculated rate on
the acquisition cost data, using the official valuation method approved for each company (WACC,
FIFO, LIFO etc), (b) the potential purchase/production price and (c) the potential liquidation price
at that period of time. This program is part of the application dealing with Warehouse Book,
Valuation etc. The name of the program to be used is J_1GVL_INVB and the prerequisite is to have
run productively Valuation and Warehouse Book for the previous year. In the selection screen you
can select the official run indicator (to carry forward totals) and update period 00 to transfer these
values to period 0 of the Warehouse Book as Initial Stock of the year.

7.7 Other Programs of Hellenisation

7.7.1 10-days Validation in Inventory Management

Legal requirement: Material transactions cannot be posted in a date, which is more than 10 days in the
past.

Initial Approach - Problems

The initial solution given was through the corresponding accounting posting. The accounting posting is
checked, not the material document. With the implementation of this method there is a problem with
the material documents that do not create accounting postings (materials managed on quantity basis).

Examples
311 Transfer posting storage Location (one step)
etc.

New Approach

A solution has been given to this problem by establishing validation after the entry of the date in the
program and the relevant screens (Process After Input) with the help of a field exit.

This validation does not exist in the case of movements which are entered through SD
and other modules (PP, QM, CO). Therefore it will not exist for movement types : 601,651, 631, 632,
633, 634, 261, 262, 321 etc. The solution for this problem is described in Greek notes in SAP
Support Portal under XX-CSC-GR.

The procedure consists of a new database table (J_1GMM2GD), a new program (J_1GMMMMVO)
and an activation of a field exit. Table J_1GMM2GD and program J_1GMMMMVO are contents of
the Greek Localization.

Procedure Description

To activate this validation maintain table J_1GMM2GD> Insert a new record into table wit the
following values:

J_1GMM2GD-J_1GMMDUMMY = ’1’

© SAP HELLAS S.A. 95


Localization Process SAP ERP 6.0 Country Manual

J_1GMM2GD-J_1GMMACTV = ’X’
J_1GMM2GD-J_1GMMMSTP = ‘E’
J_1GMM2GD-J_1GMMMSCL = ‘8X1’

J_1GMM2GD-J_1GMMSNO = ’001’

1. J_1GMM2GD-J_1GMMDUMMY : Dummy field with required value ’1’


2. J_1GMM2GD-J_1GMMACTV : Activation type of validation. Initial value means that validation is
not active. To active it enter an alphanumeric value.
3. J_1GMM2GD-J_1GMMMSTP : Type of message that will be displayed during the validation. ‘I’ for
Information, ‘W’ for Warning, ‘E’ for Error, ‘A’ for Amend.
4. J_1GMM2GD- J_1GMMMSCL : Message class of the message that will be used. Value ‘8N1’
required.
5. J_1GMM2GD-J_1GMMSNO : Number of the message that will be displayed . Value ’001’ is
required.

The technical details for this solution are described in Greek Notes in SAP Support Portal.

7.7.2 Activation of the purchasing account (PU)

7.7.2.1 Introduction

In SAP ERP you have the possibility to activate or not the Purchasing account.Most of the Greek
companies do not want to update the purchasing account during goods receipt but during the
invoice verification. The solution developed will be described in the following paragraphs.

7.7.2.3 Solution

The postings of the second example are made by the program J_1GPUPOSTING. The program
searches in the table BKPF (account document header) for the source document types. When it
finds one (e.g. RE) looks in the table BSEG (account document segment) and finds that this
document has two line items that have material: GR/IR and stock/price difference account. It sums
the amount (100+ 20) and make a posting (doc.type PU with external numbering 0FXXXXXXXX,
where XXXXXXXX is the number of the original (RE) document and 0F is the prefix of the new
document which is defined in the customizing table.

7.7.2.4 Program

Selection screen

Company code mandatory


Fiscal Year mandatory
Document optional
Posting date optional
Check box : Vendor
Check box : Partner Partner role
Checkbox for test run
Checkbox Display documents
Checkbox Display documents not PU yet

© SAP HELLAS S.A. 96


Localization Process SAP ERP 6.0 Country Manual

Indicator: Test run


Indicator: Print documents
Indicator: Full check
Indicator: No date checking
Indicator: No GR checking
Indicator: No checking
Indicator: Negative postings (When this indicator is on the programs performs negative postings,
provided that all necessary customizing has been done). Please try it extensively before using it !
Indicator On line batchinput
Batch input session (Session name)

7.7.2.5 Tables

7.7.2.5.1 Valid Document types

All Document Types that are to be included are selected from the FI document database. As source
document types are document types like RE that make the original postings in the invoice
verification. Target document type is the PU.

Table J_1GPUPREFIX (Valid doc.types)


Fields Key
Client X
Company code X
Source document type X
Target document type
Prefix

Correction Accounts

In this table we define the accounts that are going to be posted, depending on the: plant, valuation
class item category of the Purchase order and the tax code of the original posting.

Table J_1GPURULES (Correction Accounts)


Fields Key
Client X
Company code X
Plant X
Valuation class X
Item category X
Tax code X
G/L account debited
G/L account credited

Program Logic
This program does the Purchasing postings to transfer posting done on the SAP
stock account to the corresponding greek account of purchasings.
Preconditions
For this program to run correctly the following must be true:
. Table J_1GPUPREFIX must be maintained

© SAP HELLAS S.A. 97


Localization Process SAP ERP 6.0 Country Manual

. Table J_1GPURULES must be maintained


. The necessary FI customization must be done to open in the
coding block the fields for matnr,lifnr,meins,menge,werks,bwtar.

Operations
This program collects all necessary FI documents that are candidates
for PU postings. It uses the customization from table J_1GPUPREFIX to find
all documents of the specified document types. It checks if the PU
posting had already been done or not and then it continues to gather
the necessary information needed to perform the posting.
The program collects information per ebeln ebelp and then using the
information from table ekbe it calculates the delivered quantity,
the invoiced quantity and the quantity that has already been posted. If
the delivered quantity is bigger or equal to the invoiced minus the PU
one the PU posting can be performed otherwise it is flag as an
error.
The PU posting is done with a document type given from table J_1GPUPREFIX
and with number (belnr) compose by the prefix found also in J_1GPUPREFIX and
the number of the corresponding FI document.

OUTPUT
The necessary log is produced to indicated all exceptions.

7.7.3 Transfer of posting from 32 to 20

This dialog program ( J_1GPU32TO20) transfers automaticly open items of accounts type 3201 to the
respective 2X accounts and it also performs automatic clearing of these line items.
Preconditions
For this program to work correctly then following must be true:
1) Table J_1GPU32RULES exists and it is maintained correctly
2) Report sapf124 (performs clearing) is run through transaction J1GPUF124 which is used in the
above J_1GPU32TO20 program:
3) Table TF123 is maintained for the range of 32 accounts and the ebeln
and ebelp are set as the criteria. (View Maintenance)
4) Since automatic clearing is done on equality of ebeln and ebelp
make sure that no other FI postings might be misused.
5) There is also a need to perform customizing in FI for tolerance groups (Table T043T).
OUTPUT
The program displays all item to be processed. The user has the ability to display either the FI
document or the PO document, exclude some of the line item selected, and save (i.e. perform the
automatic clearing) of all the lines in the table. Sorting capabilities and paging are also included.

Selection screen

Company code Obligatory


Document date Obligatory
Posting date Obligatory
PO Number From To
G/L Account From To
Period to be cleared Posting date
Indicator: Negative postings (When this indicator is on the programs performs negative postings,
provided that all necessary customizing has been done). Please try it extensively before using

© SAP HELLAS S.A. 98


Localization Process SAP ERP 6.0 Country Manual

7.8 270 AND SAP ERP SOLUTION

Introduction

The opinion 270/2273/1996 of National Accounting Council ( ) provides clarifications with


respect to the Analytical Ledger accounts (group 9 of the Greek Chart of Accounts), the calculation
of operating costs through accounting postings and the extraction of results of the company on a
periodic basis (monthly or trimester). Adherence of what is described in this opinion is obligatory
for the Greek companies from 1.1.1999. Due to that a solution was developed in SAP ERP, which
provides the possibility to perform all the necessary tasks for A/L updating and results analysis. The
applications developed cover the following functions:

1. Transfer Posting from accounts from groups 6,7 and 8 to accounts of group 9 through
special purpose ledger techniques.

2. Allocation and distribution of expenses from 92 accounts to cost objects


(prod.orders,materials etc) or from 91 to 92 accounts through special purpose ledger.

3. Valuation of materials on a periodic basis with specific valuation methods.

4. Warehouse Book Multi-Ledger from where the gross margin per product/material is derived.

5. Update of A/l accounts of groups 93,94,96,97 with material related postings.

The following text explains the assumptions, the required customizing and the tasks that should be
performed in SAP ERP on a periodic basis. It covers points 3,4 and 5 of the above mentioned
topics.

OPERATING ASSUMPTIONS – BASIC FUNCTIONS

For the smooth operation of the application (working only with customizing) the following must
apply:

The company uses FI,MM,SD,CO and optionally PP

The possibility of user intervention is limited (mainly through corrective postings )

Posting rules that are described in this country manual are adhered to. These posting rules are
related to initial stock uploading, to the allowed document types/movement types etc.

Materials valuation can be performed on company code level or on plant level.

The supported valuation methods are mainly weighted moving average for produced materials and
weighted moving average and FIFO (First in-first out) for purchased materials.

In case a company has branches the warehouse book shows only quantities, while in the respective
report of the central offices all quantities and values are shown.

Stocks owned by third parties but kept at the company’s premises do not participate in the valuation
procedure but they are presented in the Warehouse book reports (quantity only).

© SAP HELLAS S.A. 99


Localization Process SAP ERP 6.0 Country Manual

Some of the prices/values used, are calculated by solving financial equations which are described
later in this text.

Quantities and values in the warehouse book reports are printed on separate lines due to limitations
of the printed characters (255 maximum)

When deciding to use trimesters as fiscal periods for valuation/results and A/L postings the Warehouse
book does not have all values on a monthly basis. Values are only shown for inventory stock, invoiced
purchases, GR/IR and invoiced sales. All other columns (including remaining stock) are shown by
quantity only even in months 3,6,9,12. This becomes unavoidable due to the “continuity” requirement
(year-to-period-N cumulative amounts = carried forward amounts of period N+1. In period 3 for
example, the carried forward amounts from period 2 are zero. Adding the period N totals (not zero)
leads to meaningless cumulative totals).

Quantities and Values for all columns will be shown per material for the whole preceding trimester
(and not for the whole year, even in the case of year-to-date valuation). Neither “carried forward from
previous trimester” nor “cumulative totals carried forward to next trimester” lines are printed.

The application at the moment does not support valuation of stocks based on the lowest rate
(minimum price between historic cost and current purchase price or liquidation price etc). It is
planned that this will be developed in the near future.

There are some components in the application that are not 100% operational and might not be used
before extended testing is performed. This applies to WIP calculation and to cyclic production.
Before implementing any of the above solutions please be informed about the supported
functionality from SAP Hellas.

The valuation programs assume that the “components” of an assembled material are identified by the
following argument: the assembly material document has one line item for the assembled material and
N line items with opposite D/C indicator for its components. The program does not support assembly
movements in which the components and the assembled product are in separate documents linked, e.g.,
via a CO production order.
For the valuation of the disassembled materials two methods have been designed, although only
method I is currently supported.

Method I treats the disassembled materials as components and not as products. Thus, disassembly
behaves like the reversal of the assembly and the components are always valuated first.

Method II treats the disassembly products as produced materials. Thus, if we have both assembly and
disassembly in the same period, the valuation equations are coupled and must therefore be solved by
invoking the cyclic production solver routine.

Produced materials may be valuated using the WMAW routine, which takes into account open
production orders (WIP orders). The user is responsible for determining the open orders as well (there
is a tool assisting the user in the selection by proposing possible orders) as well as filling the costing
sheet for all products.

The basic functions of the application are:

Calculation of historic cost of purchased materials per material/period or cumulatively

© SAP HELLAS S.A. 100


Localization Process SAP ERP 6.0 Country Manual

Valuation of purchased materials based on historic cost

Calculation of cost of production per material per period or cummulatively

Valuation of produced material stocks

Analytical Ledger postings

Printout of Warehouse book reports

Printout of supporting documents (FIFO, Valuation report etc).

Printout of physical inventory document

DESIGN – IMPLEMENTATION

The application consists of the following elements:

A central table which is updated on-line through user-exits from SAP ERP transactions. This table
can also be updated off-line with a special program (either for performance reasons or because of
wrong update due to errors in customizing) on request.Finally there are fields of these table (values)
which are updated only after the productive run of the valuation.

A set of customizing tables where the basic parameters are defined (valuation method, printouts
layout, Analytical Ledger accounts etc)

Programs for material valuation, print out of the warehouse book report and Analytical Ledger
postings.

A set of tables where data are stored after the productive run of the programs mentioned above.

A set of utilities (programs) which perform control tasks or error corrections tasks

A user exit of MM for updating the central table mentioned before (from material movements and
from FI movements)

Analytical technical documentation is provided within the CD.

Program logic – Sequence of execution

The application has prerequisites and specific sequence in order to give correct results. The
prerequisites are:

Data are entered in the system based on the posting rules and the respective customization is
correct.

All postings that concern the period under review have been performed (Sales, Purchases etc)

All CO-activities for expenses allocation have been performed

The execution sequence is the following:

© SAP HELLAS S.A. 101


Localization Process SAP ERP 6.0 Country Manual

Valuation of consumables/spare parts for CO- reposting


CO-Activities performed for allocating/distributing the expenses to the produced materials
Valuation of all materials
Printing of Warehouse reports
Postings in the Analytical Ledger accounts

The last two tasks do not have to be performed in that sequence.

HISTORIC COST/VALUATION

The application supports valuation methods that are based on the cost of acquisition (historic).

Several valuation methods are presented as valid choices to the user for selection. Some of them,
though, will be supported in the future. Currently, valid choices are:
For ‘BUY’ materials: FIFO, WMA (also WMAW can be selected with no harm, although it
does not make much sense).
For ‘MAKE’ materials: WMA, WMAW, FIX.
For ‘fixed price’ materials, FIX is involved in a hard-coded way.
In addition, the following restrictions apply:
The FIX routine assigns prices without taking purchases into account.
In the case of cyclic production the remaining materials are valuated using WMA; WMAW is not
supported yet for cyclic production.
At this stage other accepted valuation methods like LIFO or specific cost identification or standard
cost are not supported.

The valuation program solves some equations in order to determine the remaining stock and the
consumption values. The main equations are :

Initial Stock + Purchases + Other imports = Consumptions/Sales + Remaining .Stock

Initial Stock + Production cost + Other imports = Consumptions/Sales + Remaining .Stock

Production cost = Direct materials + Direct Labor + General expenses

In these equations all the quantity related terms are known and some values too (purchases). The
program calculates the price for the remaining stock, the value of the remaining stock and the cost
of consumptions, cost of sales etc together with the respective prices.

The formulas used are:

WMAV ( Weighted Moving Average )

IS Value + Period Purchases


Valuation Price = ----------------------------------------------------
IS Qty + Purchases Qty

In case of produced materials the formula is

IS Value + Period Production value


Valuation Price = ----------------------------------------------------
IS Qty + Production Qty

© SAP HELLAS S.A. 102


Localization Process SAP ERP 6.0 Country Manual

There are two ways of calculating these valuation prices and they are dependent on the period of
valuation. In the first case the WMA is rolling on a monthly basis, while in the second is
recalculated cumulatively up to the period that the program runs (year to date logic). Based on that
different valuation prices are calculated and different logic applies both to Warehouse Book and to
Analytical Ledger postings.

First in First out (FIFO)

According to this valuation method, the remaining stocks should be valuated based on the invoice
prices that cover quantitatively the remaining stocks. In case there are not any purchases during the
period, the values of the remaining stock of previous period are used to perform the necessary
calculations for valuating the remaining stocks.

The formula for calculation this value is

Remaining stock value = Qi * Pi, Qi = quantity, Pi = invoice price

Consumption value = Initial stock value + Purchases – Remaining stock value .

This is the only FIFO variation that is currently supported and works only with the Year to
date logic.

All equation terms are defined in a customizing table (transaction category). Due to the fact
that these transaction categories are used in the application’s source code, they must not be
amended by the users.

WAREHOUSE BOOK MULTI-LEDGER

Based on the opinion mentioned before, the Warehouse Book as it is defined in article 8 of the Books
and Data code should be properly amended, so that it can react as analytical ledger of specific A/L
accounts (94.2 , 96.2 , etc) and to facilitate the reconciliation with these accounts.

The program can print 255 characters with some elements being constant (like
Date,Doc.type,description, etc) and up to 10 columns which can be defined in a customizing table.
The layout is different between purchased and produced materials.

The report can be either analytical or in a trial balance form with only one defined as authorized in
perforated paper.

Some basic points are:

The material ledger level is the plant and the special stock location and not the storage location.

The consumption values printed in the warehouse reports are the product of consumption price *
quantities consumed per movement, so the valuation program should run in productive mode in
order for these values to be correct.

At the end of the printout there is a separate ledger per material where various fields show
adjustments. This is due to reconciliation between warehouse reports with the results of valuation.
These adjustments can have the following explanation:

© SAP HELLAS S.A. 103


Localization Process SAP ERP 6.0 Country Manual

Rounding differences (due to the multiplication referred above)


Special movements (goods receipt in month n, invoice receipt in month n+1 with no stock coverage
Year to date valuation method so the adjustments occur because of the recalculation of values up to
current month.

These adjustments are on material level and not on plant level because of the unique material
valuation price.

ANALYTICAL LEDGER POSTINGS

This program uses the values stored in the application tables per material, transaction category etc ,
reads the accounts from the respective customizing table and performs the postings with direct input
method. The postings are performed by material and period and transaction category (exception is
the consumption in production value which is posted per material and production order).

Due to design limitations the consumption in production postings can not be posted directly from
stock account to cost of production accounts (especially when using different accounts for stages of
production). This is the reason for using an interim account from which the values are transferred to
93 accounts per production stage.

The program can run in simulation mode and gives totals per account to be posted.

In the case the company uses year to date logic, the program calculates what was posted in the
previous periods and performs the postings with the differences between the total value up to the
current period and to what was posted so far, so that reconciliation with valuation and material
warehouse book multi-ledger is achieved.

Important Note: In order to be able to run effectively this application, there are steps that should
be performed in customizing and std SAP enhancements. At least the following should be done

Activate MB_CF001 user exit using include ZXMBCU01 in order to on line update the J_1GVL_ML
table.

The following tables should be maintained with the following entries:

TRWCI: RWIN Component

Sample entry ZWHB


Sample entry ZRV

TRWCA: RWIN Component, Year, Active


Sample entry ZWHB 2050 X
Sample entry ZRV 2050 X

TRWPR:

BELEG POST 960 ZWHB J_1GVL_RWIN_POST


BELEG PROJECT 960 ZWHB J_1GVL_RWIN_PROJECT
DOCUMENTPOST960 ZWHB J_1GVL_RWIN_POST
DOCUMENTPROJECT 959 ZWHB J_1GVL_RV_PROJECT

© SAP HELLAS S.A. 104


Localization Process SAP ERP 6.0 Country Manual

DOCUMENTPROJECT 960 ZWHB J_1GVL_RWIN_PROJECT

All the above are customer dependent and they are not part of the delivered CD.

The entries delivered in the customizing tables can only be used as a template and must be
carefully examined.

IMPORTANT SAP NOTES

In the following paragraph you will find a collection of Notes related to the installation, upgrade
and functional issues of Hellenization which are most commonly used and must be carefully
studied.

SAP Note Description

520991 Release strategy for the SAP CORE CEE add-on


936842 SAP CORE CEE 110_600 installation on SAP ECC 600
936843 Upgrade to SAP ECC 600 with SAP CORE CEE add-on
772476 Greece – SAP R/3 country version upgrade procedure
142759 Greek Orthodox Easter
398681 Spell_Amount: Greek configuration
913649 Hellenization: Missing authorization checks
1090404 Hellenization: Incomplete authorization checks
974643 Legal reporting improvements (NewGL extend.support)
1016141 Compliance of Greek add-on to IAS legislation II
1148425 Annual Valuation
1135997 Valuation of co products
647873 SAP and Greek Tax Devices
1037952 Inconsistency between table J_1GCONTROL and its views
1147021 Customizing for Greece - delivery ERP 6.0
1160879 Missing tax rates - Greek tax scheme TAXGR
969653 Documentation of Greek Localization for mySAP ECC 6.0
822949 Implementation Guide for country Greece
823388 Missing IMG Activities for country Greece
927687 Missing entries from Greek IMG
718372 Deactivate country specific components
158983 MM postings: 10 Days Validation
337157 SD postings: 10 days validation
1135527 SD user exits are not working for cancellation docs

© SAP HELLAS S.A. 105