CNTR Manual 600-Gr

Localization Process SAP ERP 6.0 Country Manual

© SAP HELLAS S.A. 1

SAP Hellas

SAP ERP May 2008

SAP ERP 6.0 Localization for Greece

User Guide SAP ERP 6.0

SAP HELLAS S.A.

20 Ellinidon str.

Athens



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



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



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



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



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.



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.



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.



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 .



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



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.



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.



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:



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.



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.



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.



Table J_1GGL looks like:

Lang Chart of

Account

Level

number

Long text

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.



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.



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



(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%





10 ASSET DOMESTIC ACQUISITION 0%





15 ASSET ACQUISITION 3rd

COUNTRIES 0%


COUNTRIES 6%


COUNTRIES 9%


COUNTRIES 13%


COUNTRIES 19%

20 GOODS ACQUISITION DOMESTIC 0%





25 GOODS ACQUISITION 3rd

COUNTRIES 0%


COUNTRIES 6%


COUNTRIES 9%


COUNTRIES 13%


COUNTRIES 19%

30 GOODS ACQUISITION EEC 0%





40 ACQUISITION RAW+PACKAG.MAT.DOMESTIC 0%





45 ACQUISITION RAW+PACKAG.MAT. 3RD

COUN. 0%


COUN. 6%


COUN. 9%


COUN. 13%


COUN. 19%

50 ACQUISITION RAW+PACKAG.MAT. EEC 0%







60 VAT INPUT – EXPENSES 0%

61 VAT INPUT – EXPENSES 4,5%





66 VAT INPUT – NON DEDUCTIBLE EXPENSES 0%

67 VAT INPUT – NON DEDUCTIBLE EXPENSES 4,5%



70 OUTPUT TAX FOR SALES OF SERVICES 0%

74 OUTPUT TAX FOR SALES OF SERVICES 19%

75 VAT INCOME OTHER ACTIVITIES 0%



75 OUTPUT TAX FOR INCIDENTAL OCCUPATIONS 0%



80 OUTPUT TAX FOR SALES OF ASSETS 0%

81 OUTPUT TAX FOR SALES OF ASSETS 4,5%

83 VAT SALES ASSETS 9%



86 VAT INPUT FOR ASSETS 0% – NON DEDUCTIBLE

87 VAT INPUT FOR ASSETS 4,5% – 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%




C0 OUTPUT TAX FOR SALES OF TRADING GOODS 0%

C1 OUTPUT TAX FOR SALES OF TRADING GOODS 4,5%





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%







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



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



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.



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;



- 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



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



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



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



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



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


Credit balances of balance carry forward plus credit balance of the periods before the period


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.



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.



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.



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:



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.


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.


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:



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



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.



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



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



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.



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



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



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



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.



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.



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:



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



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



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



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



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.



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



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



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



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

Posted by Item

96 Income - Gross Analytical

Results utilized



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:

Phase 1 and 2 will be used throughout this text.

SPL

G/L A/L

CO

SD

M

M

FI FI

Phase 1 Phase 2



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



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



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.



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



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.



- 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



- 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



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



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.



- 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



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.



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.



- 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, ΓΑ-ΤΙΜ,



ΓΑ(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.






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.




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

Goods Issue Requirements

10-days check and „never cancel twice‟ check

J_1GRV61A907

Pricing Requirements

Domestic Free Goods

J_1GRV64A901

Pricing Formula: Condition Value

Free Goods Cost

J_1GRV64A902

Pricing Formula: Condition Value

Free Goods Tax

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



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



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.



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.



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



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



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.



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

Type

Accounting

Cat. Reference

Valuation

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



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

Expense

MYF Document Type VAT Tax Code Due for

Payment

Comments

Freight NO R* 0% 0A YES Freight Expenses

Exempted

Agency YES R* 19% 0A YES Agency Fees

VAT 19%


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



are similar to the postings of an ordinary invoice.

Transporter

Stock Account

2X99000000

Import PO

3201.X00000

Offsetting

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.


customs broker account is credited and the Import PO and VAT accounts are debited.

Case

Type of

Expense

MYF Document

Type

VAT Tax Code Due for

Payment

Comments

Freight YES RE 0% 0A YES Freight Expenses

Exempted

Agency YES RE 19% 0A YES Agency Fees

VAT 19%


customs broker account is credited and the Interim Account of Purchases Import is debited.

Transporter

320000099 VAT

5400…

357

200

100

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



are similar to the postings of an ordinary invoice.

Transporter

Stock Account

2X90940000

Import PO

3201.X00000

Offsetting

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

(3)

10 120

Stock GR/IR Purch.

(1)

(2)

100

20

(2)

100

100 (1) (3)

120

Vendor Offsetting .

120 (2) 120 (3)



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

Value

Standard Price or

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

Value

Standard Price or

Moving Average

Goods Receipt (1) 10 10

Stock Transfer (2) 10 10

Stock CoS

(1)

100 100 (1)



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.

Stock

602 SAP std

Returns to unrestricted Stock 653 SAP std

Returns to blocked Stock 657 SAP std

Cancellation of return to unrestr.

stock

654 SAP std

Cancellation of return to blocked

stock

658 SAP std

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



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

be a different plant

All Material

Movements create an

Accounting Document

Possibly Many

Plants will be

created

No use of the

Standard SAP

Functionality

The

Subcontractor‟s

Invoice will be

posted through FI




be a vendor under a

company owned

plant

There is no need to

create extra plants

Use of the

Standard SAP

Functionality

(Subcontracting)

The

Subcontractor‟s

Invoice will be

posted through

MM against a

Purchase Order

Stock Movements to

the Third Party do not

create an Accounting

Document, so:

(a) no value can be

printed on the

Warehouse Book for

these movements

(b) Third Party Stock

Accounts mandatory

for Analytical Ledger

cannot be updated (at

least not online)


be a vendor under a

logical “Third

Party” plant

(assigned to a

different Valuation

Grouping Code)

Use of the

Standard SAP

Functionality

(Subcontracting)

The

Subcontractor‟s

Invoice will be

posted through

MM against a

Purchase Order

Stock Movements

to Subcontractor

may create an

accounting

document(so the

Warehouse Book

and AL can be

updated)

Movements at Third

Party plant level might

exist, so the

Warehouse Book will

contain one extra

Material/ Plant

combination (the

WHB has been

modified to deal with

most of these

movements)


be a vendor and

plant

simultaneously

Case 3 Case 3

Possibly many

plants should be

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



2 Goods Receipt /

Consumption of

Components

based on an

existing BOM or

the

specifications of

the PO

2.1 Goods Receipt

at Third Party

Plant

Copy of a Consumption

Document produced by the

Subcontractor for the

production process

X Not always

available

2.2 Goods Receipt

at a Company

Owned Plant

Subcontractor‟s Delivery

Note

X

3 Subsequent

Settlement

(adjustment of

Consumed

quantities)

Settlement document of the

Subcontractor

X

4 Invoice

Verification

Settlement document of the

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.



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

Value

Standard Price or

Moving Average

Goods Issue 10 10

Stock Forecast

Expense

Account

Expense

Account

(6X.XX)

Special

Sales

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.



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:

Asset

14

Income

from use

of stock as

asset

78.10.08

VAT of

purchases

of fixed

assets

54.00.28

VAT of

Revenue

54.00.79

General

Ledger

X X X X

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:

Stock

2X.90.94

Cost of

consumpti

on

2X.90.97

MM

consumptio

n.

X X

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



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.



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.



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.



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:



Val. Gr.

Code

Acct.

Mod.

Val.

Class

Account

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



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‟



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



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



. 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



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



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



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:



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



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:



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



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

CNTR Manual 600-Gr

Documents

Transcript of CNTR Manual 600-Gr