BaanERP 5.0b Localizations 1.1 for BaanERP 5.0b Functions ...€¦ · 1 Country-specific requirements, applicable for just one country (such as legal reports) 2 Generic requirements,

BaanERP 5.0b

Localizations 1.1 for BaanERP 5.0bFunctions and Features

Product Information P3062A US

Edition Control Chart

Edition Date Status Changes Affected pages

A 26-01-99 Actual

Document Authorization

Prepared Checked Approved

Name/Signature Claudio Nunes; Corien van Gent;Fernando Akasaka; LucaColombini; Manthripragada V.Sirinivas; Sjaak Versprille

Date 19/01/1999

Name/Signature

Date

Name/Signature

Date

Name/Signature

Date

Name/Signature

Date

Document information

Document

Document code : P3062A USDocument group : Product InformationDocument title : Localizations 1.1 for BaanERP 5.0b Functions and FeaturesApplication/Package : BaanERP 5.0bEdition : AMonth modified : January, 1999

Check the BaanDoc database to see if this document is still a valid edition.

© Copyright 1999 Baan Development B.V. All rights reserved

The information in this document is subject to change without notice. No part of this document may be reproduced,stored or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the expresswritten permission of Baan Development B.V.

Baan Development B.V. assumes no liability for any damages incurred, directly or indirectly, from any errors, omissionsor discrepancies between the software and the information contained in this document.

Localizations 1.1 for BaanERP 5.0b Functions and Featuresi

Table of contents

1. Introduction 11.1 Purpose of the document 11.2 Definitions, acronyms, and abbreviations 11.3 Document reading guide 1

2. Common 32.1 Common parameters 32.1.1 General localization parameters 42.1.2 Localization Parameters by Country 42.1.3 Localization parameter by user data template 42.2 Multiple taxes 52.2.1 Localization parameters 52.2.2 Localization functionality 62.2.3 Tax group 62.2.4 Kind of tax 62.2.5 Category of tax 62.2.6 Base Value 72.3 Common functionalities 72.3.1 Payment method 72.3.2 Payment schedule 72.3.3 Receipt schedule 82.3.4 Trade notes 82.3.5 Multiple control account 10

3. Brazil 113.1 Localization parameters 113.2 Localization functionalities 113.2.1 Fiscal Entity 113.2.2 Due date calculation and control 123.2.3 Payment schedule 123.2.4 Receipt schedule 133.2.5 Discount 133.2.6 Interest 143.2.7 Different layouts of receipts and payments 143.2.8 Vendor 143.2.9 Electronic bank file 153.2.10Brazilian fiscal books 173.2.11Legal books and standard history 183.2.12Multiple Tax 193.2.13Brazilian taxes 193.2.14Fiscal receipt 203.2.15Invoicing 213.2.16Retroactive invoices 223.2.17Reverse invoices 233.2.18Third party control 23

Introduction

Localizations 1.1 for BaanERP 5.0b Functions and Featuresii

3.2.19Inventory reports 23

4. Argentina 254.1 Localization parameters 254.2 Localization functionality’s 254.2.1 Fiscal identification 254.2.2 Fiscal Entity 254.2.3 Additional address information 254.2.4 Document serial code 264.2.5 Document types 264.2.6 Branch Data 264.2.7 Fiscal document number 264.2.8 Total amount in words 274.2.9 Sales VAT 274.2.10Anticipated VAT 284.2.11Tax exceptions 284.2.12Packing slip 284.2.13Fiscal documents layout 284.2.14Sales, credit notes and debit notes maintenance 294.2.15Credit notes and debit notes origin 294.2.16Fiscal documents history 29

5. Nordic 315.1 Localization parameters 315.2 Localization functionalities 315.2.1 Types of payment for payment methods 315.2.2 Bank costs 325.2.3 Customer codes 325.2.4 Exchange rate agreements 325.2.5 Bank reference 335.2.6 Interest invoices on due invoices 335.2.7 Investment charges 345.2.8 15 payment formats 355.2.9 Extra Journal Report 355.2.10Credit notes 365.2.11Bank account check 36

6. Belgium 376.1 Localization parameters 376.2 Localization functionalities 376.2.1 Intracom reporting 376.2.2 BLWI reporting 376.2.3 Tax journal 386.2.4 VAT report for Belgium 386.2.5 VAT number check 386.2.6 Belgian bank files 38

Introduction

Localizations 1.1 for BaanERP 5.0b Functions and Featuresiii

7. Switzerland 397.1 Localization parameters 397.2 Localization functionalities 397.2.1 Swiss invoice rounding 397.2.2 Electronic cash with customers 397.2.3 Electronic cash with suppliers 407.2.4 Payment slips from suppliers 40

8. India 418.1 Localization parameters 418.2 Localization functionalities 418.2.1 Company data 418.2.2 Multiple taxes 418.2.3 Modvat 428.2.4 Excise invoice 428.2.5 Sales returns 438.2.6 Subcontracting 438.2.7 RG 1 register 438.2.8 Sales tax and octroi 438.2.9 Tax deduction at source 43

9. Australia 459.1 Localization parameters 459.2 Localization functionalities 459.2.1 Sales tax 459.2.2 Prescribed payments system 45

10. France 4710.1 Localization parameters 4710.2 Localization functionalities 4710.2.1Third collector 4710.2.2Bank account check for France 4710.2.3Printouts for France 4710.2.4Canceling trade notes 47

11. Portugal 4911.1 Localization parameters 4911.2 Localization functionalities 4911.2.1Rounding data 4911.2.2Assigning accounts to VAT codes 49

12. Spain 5112.1 Localization parameters 5112.2 Localization functionalities 5112.2.1Common functionalities 5112.2.2Third collector 5112.2.3Cash discount 5212.2.4Periodical journal 52

Introduction

Localizations 1.1 for BaanERP 5.0b Functions and Featuresiv

12.2.5Bank costs in VAT analysis 5212.2.6Sales invoicing 5212.2.7Withholding tax 52

13. Japan 5313.1 Localization parameters 5313.2 Localization functionalities 5313.2.1Common functionalities 5313.2.2Customer approval 5313.2.3Journal reports Japan 5413.2.4Payment file layout 5413.2.5Expenses for employees 5413.2.6Statement of account 54

14. Italy 5514.1 Localization parameters 5514.2 Localization functionalities 5514.2.1Common functionalities 5514.2.2Libro Giornale 5614.2.3VAT book 5614.2.4Suspended VAT 5714.2.5Nondeductible VAT 5714.2.6Intra-EEC VAT 5814.2.7BAM 5814.2.8Shipment document in billing request 6014.2.9Italian VAT on invoice 6014.2.10Print warehouse journal 6014.2.11LIFO by year 6114.2.12VAT number check 6214.2.13Withholding tax & social contribution 63

Localizations 1.1 for BaanERP 5.0b Functions and Featuresv

About this document

Localizations1.1 for BaanERP5.0b give the right fit from a country perspective. Conceptssuch as MRP and MPS are world wide applicable ERP-mechanisms. There are many varietiesin the F&A environment. Each country has its own legislation, which requires the reporting ofcertain data in certain formats. On the other hand, in certain countries and regions you havewidely accepted business practices, which also need to be supported.�A good example are thedrafts (trade notes).

Localizations1.1 for BaanERP5.0b contain two main parts:

1 Country-specific requirements, applicable for just one country (such as legal reports)2 Generic requirements, applicable in more than one country (such as generic tax model and

draft/trade notes).

In Localizations1.1 for BaanERP5.0b, requirements from 15 countries are taken into oneenvironment (1 VRC) and each requirement can be activated by means of the correctparameter.

Requirements from the following countries were included in the Localizations1.1 forBaanERP5.0b (there has been an analysis for Mexico and New Zealand but no specificrequirements were included into Localizations1.1 for BaanERP5.0b; Mexico can use some ofthe Latin American countries functionality, and New Zealand did not require extrafunctionality).

Europe Americas Asia PacificItaly Brazil India

France Argentina Japan

Belgium (Mexico) Australia

Spain (New Zealand)

Portugal

Switzerland

Nordic (4 countries)

Requirements from all countries managed by Baan Development will now be in oneenvironment (VRC). This approach gives enhanced possibilities for countries with sites inmore than one country (where in the various countries localizations are required) and so allcompanies can work in one single environment in parallel.

Each chapter describes the localization-functions for a country. Each chapter is divided intotwo main paragraphs. In the first section the localization parameters are mentioned. In thesecond section, all functionalities that belongs to a specific localization are described insubsections.

About this document

Localizations 1.1 for BaanERP 5.0b Functions and Featuresvi

Localizations 1.1 for BaanERP 5.0b Functions and Features1

1.1 Purpose of the document

The functions and features of the localization VRC described give an overview of thefunctionality of the VRC.

1.2 Definitions, acronyms, and abbreviations

Term Description

localization A modification or add-on to the standard software product that is specificfor a certain country or area. An extension has a VRC code that is differentfrom that of the standard software product. For example, changes in thearea of legal requirements.

1.3 Document reading guide

The localizations are grouped by country. Each country is described in one chapter. Thischapter is divided in to two main sections. In the first section the localization parameters arementioned. In the second, main section, the functions that belong to the localization aredescribed. You can find the functionality grouped by localization’s in the sub paragraphs of thesecond main-paragraph. Sometimes the functions of more than one localization are describedin one sub paragraph. This is done when related localizations have resulted in similarfunctionality.

1. Introduction

Introduction


Common


2.1 Common parameters

In the Common parameters it is possible to set up the localizations for the company. This is toexplain the mechanism of the localization parameters.

Because all requirements have to work in one environment simultaneously, functionality isactivated by setting parameters to get the functionality working.

ParametersEach of the 150 requirements is controlled by a parameter.

The parameters are set up for each country. When you choose Spain, you will get allparameters for Spain. If you are a user in Spain, you can choose the functionality for Spain, oryou can decide to set a parameter for functionality that is only valid in another country.

User templateThe parameters are stored in a localization code and that localization code is linked to a usertemplate. Each user make use of a user template.

In other words, all users in Italy have one and the same template. Users in Spain have anotherone, and so on. This is done so that parameters can work in a multi site environment. In anenvironment where you have central logistics, it is important for the users to know what theparameter setting is when they are in a logistic process. For example, when printing a shippingdocument.

Explanation about schemeIn the following illustration you can see the concept behind the parameter setting and how itcan work in a multinational environment. As shown in the illustration, the countryrequirements are linked to a parameter. This parameter is linked to a localization component(set of functionality needed to fulfill a requirement). These components can be split into globalcomponents, applied in various countries, or country specific components, when legal reportsare required in a certain country.

In the top layer you see the user perspective. A user can select (through the user template) thecorrect composition of localization components (besides the already available standardscomponents) to get software that offers the correct working environment.

2. Common

Common


8 V H U

% U D ] L O , Q G L D 6 Z H G H Q 3 R U W X J D O - D S D Q1 R U Z D \) L Q O D Q G $ UJ H Q W LQ D $ X V W UD OL D ' H QP D UN 6 Z L V V % H O J L XP) UD Q FH , W D O\ 6 S D LQ

* H Q H U L F & R X Q W U \ � 6 S H F LI L F

* HU P D Q

8 V H U

6 S DQ L VK

8 V HU

- DS D QH V H

8 VH U

% UD ] L OLD Q

8 V HU

/ R F D O L] D W LR Q

Q R W � U H T XL U H G / R F D O L] D W LR Q V � UH T X L UH G

* OR E D O� / R F D O L ] D W LR Q

�� & R P S R Q H Q W V

& R X Q W U\ �5 HT X LU HP H Q WV

In the above illustration you see that users in a country, where basically no localization isrequired, can make use of the localization components.

Because of the mechanism provided to activate specific software components through aparameter, and link a parameter to a company and user template, this structure supports multi-national implementations. This is an important improvement for our customers who want torun in more than one country in the same environment.

2.1.1 General localization parameters

Per General Localization code the localization parameters can be maintained.

2.1.2 Localization Parameters by Country

For each general localization parameter, the localization parameters of a country can beswitched on or off. The functionality is the same as in general localization parameters, but herethe localizations are grouped by country.

2.1.3 Localization parameter by user data template

A general localization code can be attached to a user template. This template is maintained inBaanERP Tools.

Common


2.2 Multiple taxes

Multiple tax functionality mainly relates to the creation of a tax group that can hold individualtax codes to apply on the same logistic procedure, such as sales.

A multiple tax solution has been created to cover tax requirements for the following countries:

n Argentinan Australian Braziln Indian Italyn Spain

2.2.1 Localization parameters

Common for all countries:

n Multiple taxn Generic tax

Argentina:

n Anticipated VAT

Australia:

n Australian sales taxn PPS withholding taxn Australian fiscal report

Brazil:

n Brazilian taxes

Italy:

n VAT bookn Intra EEC VATn Withholding tax and social contributionn Non deductible VATn Suspended VAT

India:

n Excise dutyn TDSn Indian sales tax

Spain:

n Withholding tax

Common


2.2.2 Localization functionality

Different kinds of taxes have to be treated differently. For example:

n VAT and manufacturing and transportation tax can be added to the amount posted to theBusiness Partner Control Account.

n Withholding tax and social contribution have to be deducted from the amount posted to theBusiness Partner Control Account.

Generally, in all the countries where tax requirements are very important, more than one taxhas to be applied on different transactions, such as purchase, sales, or payments. To facilitatethe calculation of multiple taxes on one transaction, a tax group procedure has been created inthe Baan system.

If a suitable tax group is created, it can be used in all the areas of the BaanERP system wheretax code can be attached for tax calculation. It will be able to calculate all the taxes defined forthe tax group simultaneously.

2.2.3 Tax group

Tax group can be defined in the system using the new setup structure for taxes.

A tax code can be defined as a group or non group tax code. This facilitates creation of a taxgroup with the help of a one-group tax code and multiple non group tax codes.

Different tax codes for different kinds and categories of taxes can be created here.

2.2.4 Kind of tax

Kinds of taxes available in the current system are manufacturing taxes, VAT, transportationtax, withholding tax, and social contribution.

2.2.5 Category of tax

Different categories available for all the seven countries are:

n Additional excise dutyn Anticipatedn Basic excise dutyn Cessn Credit on resalen Deductiblen Differedn Exemptn Exportn Free trade zonen Non deductible.n Non incidentn Non taxablen Not applicable

Common


n Not registeredn Othersn Reductionn Registeredn Service taxn Special excise dutyn Suspendedn Taxable

The values available for each kind of tax and category of tax are controlled through differentparameters. Please refer to the notes on different countries for information on specificapplication.

2.2.6 Base Value

Generally, different taxes are calculated on different base values even though all the taxes areapplied on the same transaction. To create a flexible base value for tax calculation, a basevalue formula is available.

A base value formula can be created using predefined reserved words and basic mathematicaloperations.

2.3 Common functionalities

The following functionalities are common for more than one country:

n Payment methodn Payment schedulen Receipt schedulen Trade noten Multiple control account

2.3.1 Payment method

The payment method is a definition on how the invoice will be paid. This is part of the termsof payment. In this functionality you can define whether the payment method will be definedeither with the business partner or with the payment schedule in the terms of payment. In thiscase you will no longer have to define your payment method in the sales orders. The sameapplies to the purchase orders.

2.3.2 Payment schedule

The payment schedule is defined with the terms of payment. Here you define the distributionof amounts over the lines. This distribution can be based on a factor or on a percentage. Thepayment day is defined with the payment period, the payment days in the terms of paymentand with the calendar that is linked towards the company (in case of payments), or to businesspartner (in case of receipts).

Based on the entered terms of payment with the invoice the payment schedule will begenerated. When the Payment Schedule parameter is set most payment functionality is linkedto the payment schedule line instead of to the invoice.

Note:

Common


This applies for the following information:

n Line numbern Payment methodn Terms of Paymentn Discount informationn Balance informationn Status for paymentn Suppliers bank coden Reference

When payments are completed, a link is to be made towards the payment schedule instead oftowards the invoice. An advantage of this is that the credit control will be based on theschedule line and not on the invoice level.

2.3.3 Receipt schedule

The same functionality is developed for receipts and acts in a similar way.

2.3.4 Trade notes

Trade notes are a payment method. In this section, a short overview of the main functionalityand status flow of trade notes is given. After this, for each affected module the functionality ofthe trade notes are described. The affected modules are Accounts Receivable, AccountsPayable, and Cash Management.

What is a trade note?

Payment documents will often only balance out an invoice after it is paid. With trade notes youcan have two situations. Trade notes can be either a paper without any value (guarantee) or canbe a document that is replacing the original documents. To support these kind of documents,several functionality’s are added to the current payment handling. The main areas of changeare:

n Handling of the balancesn Reports defined with stepsn Replacement of documentn Stepsn Posting scheme

Common


Flow of trade notes

The trade notes can have different statuses. There are different steps possible within the tradenote processing. Based on the definition, a posting to the general ledger is made at the momentof creation of a trade note and with the change of a status.

A box represents the status of a trade note. The lines under the box indicates which steps aremandatory. Sometimes there is more than one line under one box. At that time, you can choosewhich flow to follow. Each time a line is interrupted it is possible to choose one of thedifferent statuses connected to the arrow. In BaanERP the process of paying with trade notes isstarted with the selection of invoices to be paid.

Accounts receivable

To follow the status changes of the trade note within the general ledger, the control accountscan be defined in the master data of the Financial Business Partner Groups. The followingaccounts can be maintained.

n Payment document drawn Payment document sent to customern Payment document acceptedn Payment document sent for discountingn Payment document discountedn Payment document dishonoredn Payment document endorsedn Payment document sent to bankn Payment document matured

As the invoice can be replaced by the payment document, this will be seen with inquiries thatare made on the open items of the business partner.

Common


Accounts payable

In the master data of the Financial Business Partner Groups, the control account that relates tothe statuses mentioned below can be maintained.

n Trade notes endorsedn Document receivedn Document sent/acceptedn Document maturedn Document dishonored

Cash management

To support the various types of trade note documents, a number of options can be set with thepayment method:

n Replace invoice by payment documentn Update balancen Deductions allowedn Posting scheme of business partner group

You can use the various steps of a payment method to define the report to be used. This differsfrom the current use of the report. A report or file can now only be generated, with the firststep of the payment document.

After you generate the trade note with the first step that is used for the payment method, astatus change can be made with the notification process. In this notification process a selectionis made based on the used banking method and payment method. Also, you can choose the toand from step. The selection changes can then be made and the status change can be processed.The defined ledger accounts are then posted and the payment document in the open entries areupdated.

2.3.5 Multiple control account

With this functionality you can define ledger accounts for different types of invoices. Thenormal trade invoices will be posted to the control account. In case invoices need to be postedthat do not belong to your normal business, a separate account can be used. This account willbe used for all transactions that do follow after the invoice has been registered.For sales invoices you can switch on a parameter to post at a Non-trade Invoice controlaccount. If you do not select the parameter, the booking is posted to a Trade Invoice controlaccount.For purchase invoices you can select one of the following control accounts at the moment ofposting an invoice:

n Normaln Non traden Fixed assetsn Costs

In the Financial Business Partner Groups accounts, all invoices mentioned earlier must bedefined.Automatic generated invoice’s, both for sales and purchase, will be posted on the normalcontrol account.

Brazil


3.1 Localization parametersn Fiscal entity – braziln Payment schedulen Receipt schedulen Discountn Interestn Different layouts of receipts and paymentsn Vendorn Electronic bank filen Brazilian fiscal booksn Financial legal booksn Standard historyn Multiple taxn Brazilian taxesn Fiscal receiptsn Brazilian invoicingn Retroactive invoicesn Reverse invoicesn Third partyn Inventory reports

3.2 Localization functionalities

3.2.1 Fiscal Entity

The fiscal identification is a unique fiscal code that is assigned to companies, businesspartners, suppliers, and carriers. It is composed by the identification type and number. Thefiscal identification is printed in all types of documents handled by the company, such asinvoice, credit note, debit note, fiscal books, and so on.

The last digits of the fiscal number are validated according to a specific algorithm, and twotypes are available: CNPJ or CNPF.

The fiscal identification must be linked to the fiscal entity, where the following information aredefined:

n Fiscal numbern Entity type – company or business partnern Trade identification number and date of issuen State inscriptionn City inscriptionn Business partner originn Base date for payment schedulen Trade zone

3. Brazil

Brazil


The fiscal entity code is linked to the address code and this can be linked such entities as:company, business partner, warehouse and departments. Based on this, the same fiscal numberand other characteristics can be used in several entities.

3.2.2 Due date calculation and control

Besides the standard options to determine how the due date must be calculated (immediately,and at the end of the month) three more options are available:

n End of week – For this option a month is divided into four periods (four weeks) of sevendays each. The due date will be the end of ones period plus payment period. The due datewill be calculated taking the Sunday of the next week as the document date plus thepayment period defined in the term of payment.

n End of ten days – For this option a month is divided into three periods of ten days each. Thedue date is the end of ones period plus the payment period defined. If the invoice date isbetween 1 and 10, the due date will be calculated considering the eleventh day plus thepayment period. If it is between 11 and 20, the due date will be calculated considering thetwenty-first day plus the payment period. If it is between 21 and 31, the due date will becalculated considering the first day of the next period (month).

n End of fortnight - A month is divided in two periods of fifteen days each. The due date isthe end of one’s period plus payment period defined. If the invoice date is between 1 and15, the due date will be calculated considering the sixteen day plus the payment period. Ifthe invoice date is between 16 and 31, the due date will be calculated considering the firstday of the next period plus the payment period.

To perform these calculations, it is necessary to have a financial calendar in order to definewhich period (week, set of ten days, or fortnight) is related to the document date, and also tocheck if the due date is a working day.

For receivable documents the due date is checked with the financial calendar linked to theInvoice-to Business Partner. For payable documents, the check is carried out with the calendarcode linked to the company in enterprise modeling management.

3.2.3 Payment schedule

When the Payment Schedule parameter is set, most payment functionality is linked to thepayment schedule line instead of being linked to the invoice. This applies for the followinginformation:

n Line number – it can be numeric or alphabeticn Payment methodn Bank for paymentn Discount informationn Interest informationn Balance informationn Status for paymentn Suppliers bank coden Reference

Brazil


You can use the Payment Schedule to view for each payment schedule line, the transactionsconcerned to payment, link of credit note, link of advance, and anticipated and unallocatedpayment.

A specific report is available to print the new information from payment schedule with a largenumber of variables in the selection range. For example, company, financial business partnergroup, business partner code, due date, payment method, document number, and status forpayment.

An advantage of this enhancement is that the aging analysis and cash flow are based on theschedule line and not on the invoice level.

3.2.4 Receipt schedule

The same functionality is developed for receipts and acts in a similar way. The followinginformation is available at the line level:

n Line number – it can be numeric or alphabeticn Payment methodn Customer’s bankn Discount informationn Interest informationn Balance informationn Receipt statusn Vendor informationn Reference

You can use the Receipt Schedule parameter to view for each schedule line, the transactionsconcerned to receipt, link of credit note, link of advance, and anticipated and unallocatedreceipt.

A specific report is available to print the new information from the receipt schedule with alarge number of variables in the selection range such as company, financial business partnergroup, business partner code, due date, payment method, and document number and receiptstatus.

Advantages of this enhancement is that the credit control, business partner statement, aginganalysis, and cash flow are based on the schedule line and not on the invoice level.

3.2.5 Discount

There are three levels of discount and they are stored in the payment and receipt schedule. Twotypes are available: rate or amount.

For receipt processing the discount works in two different manners:

n Informative discount – This information is only printed in the receipt report (borderaux) orused to generate the electronic bank file. In such a case, the discount will only be posted ifthe customer makes the payment before the discount date.

n Normal discount – The receipt processing is already done considering the discount amount.This means the receipt date is before the discount date.

Brazil


3.2.6 Interest

The interest on late payment is controlled separately from the main amount of debt. Thecalculation requires some parameters defined on each payment and receipt schedule such:

n Type of rate – it can be percentage or valuen Interest raten Periodicity of the interest rate – It can be daily, monthly or annual

The interest amount stored for each schedule line can be selected by the following processes:

n Payment and receipt processingn Supplier and customer bank transactionsn Cash flow

In the Business Partner Financial Groups there is a new option to define a ledger account topost the interest amount paid and received.

3.2.7 Different layouts of receipts and payments

The layout of three payment reports (borderaux for payment), two receipt reports (borderauxfor receipt and for discount), and the Brazilian cheque are developed to meet the Brazilianrequirement.

When you define a payment method these layouts can be selected by typing the numberreferring to one of these layouts.

3.2.8 Vendor

Vendor is a payment agreement between a company, customer, and bank. The functionality tosupport vendor transactions is divided into:

Master Data

In the CMG parameters the user can define new information such as:

n Interim ledger account for unpaid vendorn Number groupn Series for vendor contractn IOF taxn Positive equalization accountn Negative equalization accountn IOF ledger account.

Receipt schedule

Extra information specific for a vendor can be entered as vendor type (normal, negotiable andinstallment), vendor category (pre, future, and mixed), vendor period, vendor total period,business partner rate, business partner rate period, business partner, index, and bank index.

Vendor process

The receipt procedure is used to compose receipt schedules and generate the vendortransaction.

Brazil


Reconciliation of vendor transactions must be carried out and the user can accept or rejectthem. If you accept the transaction postings are generated, the receipt schedule balance is set tozero, and the amount is credited in the company’s bank account.

Vendor transactions can be reselected in case the customer wants to renew them.

The vendor transaction module offers a wide range of reports, such as vendor contract, vendorfinancial sheet, adhesion letter, vendor informative, vendor transactions, vendor transactionsby bank, and unpaid vendor transactions.

3.2.9 Electronic bank file

Electronic bank file functionality offers a flexible way to set up the file structure, since inBrazil this is the most common receipt method.

Because each bank has its own file layout, a wide range of sessions is implemented to allowthe definition and processing.

Master data

Because the layout of the sequential files are different for each bank, it is necessary to definethe various fields within the record and the relation between the internal codes (used by thecompany) and the external codes (used by the banks).

The following internal codes can be created:

n Bank service typen Occurrencen Instruction

And they must be linked to a generic group which will form:

n Bank service type groupn Occurrence groupn Instruction group

The other variables to be defined under each group are:

n Rejection groupn Time Limit groupn Clearance Days groupn Currency groupn Document Type group

In this way, each group has the definition of internal and external codes.

The layout of incoming and outgoing file groups can be defined with the information needed,such as fiscal document number, document date, due date, discount amount, discount date,interest rate, main amount, bank code, bank office code, bank account, customer name,customer address, customer postal code, city, state, and so on.

All groups listed above must be linked to the highest group code, called EBF Group, and this isthen linked to the bank relation.

Brazil


Time Limit

Group

OccurrenceGroup

IncomingLayoutGroup

Instruction

Group

DocumentType Group

CurrencyGroup

ClearanceDays Group

Rejection

Group

Bank ServiceGroupOutgoing

Layout Group

EBF

GroupBank

Relation

EBF processing

During receipt processing, the EBF database is updated and the anticipated receipt is created.Afterwards, the user can generate an outgoing file and send it to the bank.

The company can proceed in some actions with the outstanding receipt schedules, such as:

n Assign credit notes to anticipated receiptsn Change the due date in the receipt schedulen Reconcile the anticipated receipt manuallyn Cancel the assignment of credit notes to anticipated receiptsn Send new instructions

Each action described above updates the EBF database with new data:

n Example of occurrences: change due date, grant rebate (amount assigned), cancel rebate(amount cancelled), send back the document because the customer paid in the company,protest the document, and so on.

n Example of instructions: refuse payment after due date, discard interest when overdue,protest document after 10 days, overdue due date, and so on.

In these cases the anticipated receipt has to be sent again to the bank in a new file.

The confirmation of the first outgoing file is not mandatory according to each bank. In cases ofsending new occurrences or instructions, the confirmation becomes mandatory.

Brazil


Customer receipt

The file sent by the bank is read and an interim table is updated when processing the incomingfile, the reconciliation is done for those records without error.

An audit of created EBF files is performed to prevent errors in the generation of financialpostings.

3.2.10 Brazilian fiscal books

This functionality is divided into four topics.

Master data

In the Fiscal Books parameters, the user can define the legal representative and its accountidentification, closing book type (maximum number of pages or monthly), maximum numberof pages, initial book number, initial page number, option to group fiscal documents, and theauthorization number used to electronically process the fiscal books.

Inbound books (Livros de Entrada)

The following inbound fiscal books are available following the specifications of the Brazilianlegislation.

n Inbound register (Registro de Entrada)n Goods inbound statement for DIPI (Demonstrativo de Entradas para DIPI)n DIPI auxiliary reports – sender (Relatórios Auxiliares para preenchimento da DIPI)n Cities participation index declaration – inbound (Índice de Participação dos Municípios)n Tax rate variance (Diferencial de Alíquota de ICMS)n Interstate guide – inbound (Listagem das Operações Interestaduais)n Correction letter – fiscal document irregularity communication (Carta de Correção –

Comunicação de Irregularidades da Nota Fiscal)n Opening and closing terms (Termos de Abertura e de Encerramento)

Outbound books (Livros de Saída)

The following outbound fiscal books are available following the specifications of the Brazilianlegislation.

n Outbound register (Registro de Saída)n Goods outbound statement for DIPI (Demonstrativo de Saídas para DIPI)n DIPI auxiliary reports (Relatórios Auxiliares para preenchimento da DIPI)n Cities participation index declaration – outbound (Índice de Participação dos Municípios)n Interstate transactions List (Listagem das Operações Interestaduais)n Interstate guide – inbound (Guia de Informação de Operações e Prestações Interestaduais)n Correction letter – fiscal document irregularity communication (Carta de Correção –

Comunicação de Irregularidades da Nota Fiscal)n ICMS calculation register (Registro de Apuração do ICMS)n IPI calculation register (Registro de Apuração do IPI)n Opening and closing terms (Termos de Abertura e de Encerramento)

Brazil


Sales and purchase transactions in magnetic media

The following files are generated according to the specifications of the ICMS Convention nº96/97.

n Company data – file type 10 (Registro Tipo 10)n Complementary company data – file type 11 (Registro Tipo 11)n Fiscal documents – ICMS – file type 50 (Registro Tipo 50)n Fiscal documents – IPI – file type 51 (Registro Tipo 51)n Fiscal documents – tax substitution – file type 53 (Registro Tipo 53)n Fiscal documents – item data – file type 54 (Registro Tipo 54)n Item or service code – file type 75 (Registro Tipo 75)n Totalizator file – file type 90 (Registro Tipo 90)

3.2.11 Legal books and standard history

Two legal books are developed according to the specifications defined by the Brazilianaccounting legislation. It is divided in two topics.

Master Data

The user is allowed to define the maximum number of pages, for each book name of legalrepresentative, and its accounting identification.

The standard history is part of the legal book and its definition is in the General Ledger MasterData.

For those transactions entered manually, you can choose a code and the history is retrievedfrom the original table. It is possible to maintain it with additional information.

In case the financial transaction is generated by batch there are two possibilities:

n Non integration transactions such as inter company transaction, write off currencydifference, write-off payment difference, and so on. The code has to be entered on the formand it will go with the transaction.

n Integration transactions, such as integration from other modules. With Finance, the standardhistory code has to be linked to the financial transaction, and in Integration with othermodules.

Print legal books

Two legal books are available:

n General journal (Diário Geral)n General ledger (Razão Geral)

Brazil


3.2.12 Multiple Tax

You can use multiple tax solution to:

n Specify the amount on which the tax is calculated

n Set up a tax structure where more than one tax is applied on an invoice, and a tax must beapplied on an amount after adding or subtracting the previous tax amount or some otheruser specified amount, such as handling cost

With the introduction of a new concept, the base value formula allows the user to define thebase value on which the tax rate must be applied. This can be done for a tax code in the case ofa single tax code, and for each tax code line for a multiple tax code.

Steps to set up the tax structure:

n Reserved word – The reserved word types are system that define such goods as amount,discount, freight, other expenses, and so on. You can enter your own reserved words andlink them to the existing types.

n Base value formula – The formula can be entered in the base value formula editor and it isformulated by using the reserved word codes.

n Tax codes – The base value formula code is attached to a tax code in the tax codes bycountry if the tax code is singular.

n Tax codes by group tax code – Here the tax codes defined to each Brazilian tax are linkedto the group tax code.

3.2.13 Brazilian taxes

The following Brazilian taxes are covered:

n Transportation – ICMS and ICMS substitutionn Service – ISSn Manufacturing – IPIn Withholding – IRRF

In addition to the set up of tax structure explained in section 3.2.12, two more steps areneeded:

n Additional tax details code – There is a definition of tax retained (if retained the tax amountis added to the invoice total amount), ICMS substitution check box, net margin percentage(to be used in the ICMS substitution calculation), description (or fiscal text) 1, 2, and 3. Theadditional tax details code must be linked to the tax code.

n Tax code – According to the Brazilian taxation the following data has to be defined: type oftax (manufacturing, transportation, VAT, or withholding) and category of tax (taxable, non-taxable, suspended, difered, exempt, credit on resale, reduction and non incident).

Brazil


You can define more information, even if there is no direct influence an the tax calculation.They are used in several processes, such invoicing, fiscal receipts, fiscal books and inventoryreports.

n Tax substituted state inscriptions for fiscal identification type – In cases of ICMSsubstitution the state inscription of the company in the target state is printed in a specificbox in the invoice, so the state inscriptions number for each state code can be defined perCNPJ.

n Fiscal rating – The fiscal classification for each item/product according to the NBM/SHdefinition.

n Item fiscal data group – The fiscal rating is linked to the item fiscal data group, and this islinked to the item code in general item data.

n Operation fiscal code – In this component there is a definition of: origin/destination (samestate, other state, importation, exportation, same state transference, other state transference,and others), the official CFO code, fiscal document type (shipment, sales, or transference)and the retroactive CFO.

3.2.14 Fiscal receipt

This new module is available in Baan Distribution to register the inbound movements as amatter of fiscal documents. The receipt fiscal documents contain fiscal and logistic informationthat must be considered along with the purchase, inbound, and payment procedures. They alsoare required in some fiscal books.

The Fiscal Receipts module is part of the BaanERP Order Management and it is divided inthree topics.

Master data

In Fiscal Receipt parameters, the user can define the rounding tolerance, decide if there will bea control of receipt date, control of error in registering and approving fiscal documents, andintegration with BaanERP Finance.

Users can be linked to the types of error (quantity, price, fiscal rating, IPI and ICMS). Aninvoice with error, in other words, price in the invoice bigger than the purchase order, cannotbe approved by a user without such authorization.

Fiscal document handling

Two ways of entering fiscal documents are possible:

1 Receipt fiscal document with inbound orders in warehousing

2 Receipt fiscal document without inbound orders in warehousing

The process flows as follows:

n Before confirming the receipt it must be released to fiscal receipts. When it is released, theinformation is recorded in the corporate receipt table, linked to the company defined infiscal receipt parameters.

Brazil


n The user can link one or several receipt lines to the fiscal document to be entered manually.Once the link is carried out, the user is allowed to handle the receipt fiscal documents foreach fiscal identification of the supplier (ship-from CNPJ).

From the fiscal document header the following options are available:

n Fiscal receipt linesn Fiscal receipt schedulen Fiscal receipt documents with errorsn Fiscal receipt error detailsn Relative fiscal documents – Mandatory and available only for complementary fiscal

documents (ICMS Complement, IPI Complement, and Price Complement) and bill oflading

n Approve manually fiscal receipt documentn Reverse fiscal documents

In the Fiscal Receipt module, the user is allowed to enter the following type of documents:purchase with order, purchase without order, shipment, complementary fiscal notes (ICMS, IPIor Price), bill of lading, return of goods, customer's fiscal note, and others.

After the fiscal document has been approved, the receipt line can be confirmed. Open entry inBaanERP Accounts Payable and postings in BaanERP General Ledger can be generated whengeneration of invoices by self-billing is run.

Return of goods

Returning goods to suppliers is only allowed for those fiscal documents that were generatedfrom purchase orders.

The user must create a return of goods order and each line of the order is related to a specificapproved receipt fiscal document line.

Return of goods orders have to be released to warehousing in order to make the outboundprocess. After the inventory has been released the warehousing order must be sent to centralinvoicing, where the outbound fiscal document can be printed and posted to BaanERP GeneralLedger.

3.2.15 Invoicing

The following fiscal document types are developed in central invoicing:

n Salesn Transferencen IPI complementn ICMS complementn Price complementn Shipmentn Debit Noten Reversen Return of goods

Brazil


This functionality is divided into three topics.

Master data

Apart from the standard information to be set up, there is new data that must be defined beforethe procedure in central invoicing can be carried out:

n In logistic tables - Number group and its first free numbers for the fiscal document numbergeneration and carriers

n In fiscal tables – First digits of operation fiscal code in the common parameters

n In item data – A new classification is provided for an item with cost type: freight,insurance, or other expenses

n In SLI parameters – Invoice report currency, default transaction type, and series number forreversed invoices, default standard history code, and invoice date control (if it is checked,an invoice cannot be generated before the date is defined here).

Invoicing handling

The user can create manual sales invoices which do not represent inventory movement, and theinformation to be defined is forwarding agent, operation fiscal code (CFO), charge type(goods, costs, or services), cost type (freight, insurance, or other expenses), fiscal documenttype, fiscal rating, item utilization type, goods origin, and legal report location. Thisinformation is used during invoice generation and printing.

For sales and warehouse order invoices, the data is brought as default and cannot be changedin central invoicing.

Invoicing process

The compose criteria of invoices, also considers the Brazilian characteristics type of document(sales, transference, shipment, IPI complementary, ICMS complementary, pricecomplementary, return of goods, and debit note).

The layout provided to print the Brazilian invoice is type NFF (nota fiscal fatura) and it ispossible to print normal items and services, which includes the tax amounts calculated for IPI,ICMS, ICMS Substitution, and ISS.

For fiscal document type shipment or transference, open entries are not generated in BaanERPAccounts Receivable and the amounts are posted to the ledger account of shipment defined inledger accounts by business partner group.

3.2.16 Retroactive invoices

Previous invoices can be selected to generate new invoices, since the current price of the itemis greater than the price printed in the invoice.

For the selected invoice, a record is created with the price difference amount, and the status isregistered.

Brazil


3.2.17 Reverse invoices

Invoices with the status printed or posted can be reversed. They then become eligible to beselected, composed, and printed again.

3.2.18 Third party control

This functionality controls the quantity of goods sent to and received from a trading partner. Itis possible to issue and register invoices (fiscal documents), post to general ledger, but withoutgenerating an open entry in accounts receivable or accounts payable.

With the specific Brazilian inventory reports quantity of goods and the value of the inventorytransaction can be printed and controlled.

3.2.19 Inventory reports

Two legal inventory reports are available according to the specifications defined by theBrazilian legislation.

n Inventory register book(Registro de Inventário) – P7 model

n Production and inventory control book(Livro Registro Controle da Produção e do Estoque) – P3 model

Brazil


Argentina


4.1 Localization parametersn Fiscal entity – Argentinan Additional address informationn Generic taxn Multiple taxn Anticipated VATn Packing slipsn Argentinean invoicingn Reverse invoicen Invoice history

4.2 Localization functionality’s

4.2.1 Fiscal identification

The fiscal identification is a unique fiscal code that is assigned to companies, customers,suppliers, and carriers. It is composed of the identification type and number. The fiscalidentification is printed in all types of documents handled by the company such as invoice,credit note, debit note, receipt, fiscal books, and so on. Some examples: CUIT 20 – 04448482– 0, CI 00001234112

In case the identification type is CUIT, the last digit of the identification number is validatedby a specific algorithm.

4.2.2 Fiscal Entity

Companies, customers and suppliers have similar fiscal information such as the fiscalidentification, tax parameters, document parameters, and so on. A central data called fiscalentity stores this information and it prevents the same data being entered twice or more. Inother words, for each Baan logistic company, for each customer, for each supplier, and so on.

The link among one company (or supplier or customer) and the related fiscal entity is done bythe fiscal identification.

4.2.3 Additional address information

The address data contains mandatory information required by the tax authorities. Thisinformation is considered in the fiscal document forms, fiscal books and during the taxcalculation.

Information regarding the custom and shipment area is mandatory, depending on the documenttype (for example, invoice for exportation, imported goods, and so on.).

The tax calculation process may be dependent on the state legislation. Sometimes, the specificstate area legislation must be attended. This happens, for example, in transactions that involvecustom areas that have incentive tax.

4. Argentina

Argentina


4.2.4 Document serial code

The document information includes the document type and serial code. For example, SalesInvoice – serial A, Credit Note – serial B.

The serial code of each document depends on the tax situation of the company andcustomer/supplier. For each possible combination of company and customer/supplier taxsituations, there is a predefined serial (for example, serial code is A if company is VATregistered responsible and customer is VAT registered responsible).

The packing slip is an exception, as its serial code is always equal to X. As a result, thecompany and customer tax situations are not considered in this case.

The document numbering control is based on this information.

4.2.5 Document types

A predefined document type code is associated for each document and serial code. This code isused in the fiscal books.

4.2.6 Branch Data

A company may have one or more branches. For example: sales branches, collecting branches,payment branches, and so on. Each branch may be responsible for one or more document type(e.g. sales invoice, credit or debit note, packing slip, receipt, and so on.).

n Centralized branch controlOnly one branch will issue the fiscal documents. In this case, the branch code is pre-definedand its code is equal to 0000.

n Decentralized branch controlSeveral branches will issue the fiscal documents. In this case, the branch code is asequential number and its code range is from 0001 to 9998.

The branch information is printed in all fiscal documents and fiscal books.

The branch code and a sequential number compose the document fiscal number. This meansthat the document numbering control is handled by branch.

4.2.7 Fiscal document number

The branch code and a sequential number compose the fiscal document number. This numbermust be consecutive and chronological by branch.

For example, Invoice A 0000-21110001, Credit Note B 0015-55550002

In the case of an invoice, credit note or debit note, the document numbering control can bedone by document type or set. For other document types, such as receipt and packing slip, thedocument numbering control is done by document type.

Argentina


n Document Type: each document type has its own specific numbering control.

For example:

Document Numbering code

Invoice A NC1

Credit Note A NC2

n Document Set: invoices, credit notes and debit notes with same serial code have the samespecific numbering control.

For example:

Document Numbering code

Invoice A NC1

Credit Note A NC1

4.2.8 Total amount in words

The total amount of the fiscal documents (for example, sales invoice, credit note and debitnote, receipt, and so on.) is written in Spanish. In the fiscal document form there is a specificfield for the amount in words. This information is required only for printing purposes.

4.2.9 Sales VAT

Three VAT concepts related to the goods and service transactions are possible:

n Taxable items (IVA Gravado)Five different VAT amounts may be added to the invoice amount. Because of that, somelines of multiple VAT can be considered during the calculation and booking.− VAT registered responsible (IVA Responsible Inscripto)− VAT not registered responsible (IVA Responsible No Inscripto)− Anticipated VAT (IVA Percepcion)− Export VAT (IVA Exportacion)− Free trade zone VAT (IVA Zona Franca)

n Non taxable items (IVA No Gravado) and exempt items (IVA Exento)

These concepts are applicable for items that have a tax incentive.

In order to get the correct tax rate, the system checks if there is a packing slip related to thetransaction, as follows:

n If there is a Packing Slip linked to the transaction (for example, sales invoice) then thepacking slip date is considered to get the tax rate;

n In the other cases, the fiscal document date (for example, invoice, credit note or debit note,and so on) is considered to get the tax rate.

Argentina


4.2.10 Anticipated VAT

The Anticipated VAT is an amount that may be added to the sales documents (for example,invoice, credit notes or debit notes). This amount is not related to the normal VAT. It is anadditional tax amount.

The Anticipated VAT calculation process considers the fiscal entity information (for example,company, customer, and supplier), transaction data (for example, address), item, taxexemptions, and anticipated tax data.

4.2.11 Tax exceptions

A tax rate exemption (tasas de liberacion) may be considered during the Anticipated VATcalculation, depending on the effective date and customer/supplier tax attributes.

4.2.12 Packing slip

The packing slip (Remito) is a fiscal document and it is mandatory when transporting goods.The main topics are:

n The packing slip can be related to or not related to a sales transaction (for example,consignment, stock transfer, etc.)

n It is possible to generate manual packing slips

n A packing slip can be linked to an invoice depending on the documents status

n The packing slip has a specific form. The delivered quantity is specified in a predefinedfiscal unit

n The packing slip can be cancelled. The related reverse booking and sales order anddocuments updates are made after the document is cancelled

n It is possible to print a non invoiced packing slip report

n The packing slip history is available for inquires during a certain period defined by the law.After this period, it may be removed.

4.2.13 Fiscal documents layout

The fiscal document contain such information as document type, serial, branch and number,fiscal entities (company, customer, carrier), item, non item or service, tax(es), packing slip,linked documents, and so on. The main topics are:

n Sales invoice, credit note and debit note have different layouts depending on the transactionattributes. (For example, company and customer tax situation). There are three differentlayouts for transactions inside the country (in other words, types A, B or C).

n The document for exportation has a specific layout. It contains additional information suchas freight and insurance data, custom area, shipment area, and so on.

Argentina


4.2.14 Sales, credit notes and debit notes maintenance

The sales invoice, credit note and debit note data can be maintained depending on thedocument origin (in other words, manual entering or origin from another document) and status.

During the maintenance, it is possible to link a packing slip to an invoice. The link betweenthese documents is made by the packing slip number.

It is possible to see all the tax information by document (tax details per document) ordocument line (tax details per line).

When the document has its fiscal number assigned, the only option that is available is to cancelthe document. During this process, the related transactions (for example, sales or purchasetransactions) are updated with the current fiscal situation.

4.2.15 Credit notes and debit notes origin

When a credit note or debit note is related to another document such as a sales invoice then alltax information, must come from the original document. This happens even if the governmenthas changed some tax informatio, such as the current rate. For example, a credit noteoriginated from a sales invoice has the sales invoice tax rates and parameters.

4.2.16 Fiscal documents history

The fiscal document history is available for inquires during a certain period defined by the law.After this period, it may be removed. Its data contains the documents information that isrequired by the fiscal books.

Argentina


Nordic


5.1 Localization parametersn Type of paymentsn Bank cost indicatorn Customer codesn Exchange rate agreementsn Bank referencen Interest invoices on due and not yet paid invoicesn Investment chargesn Electronic bank filesn Journal report for finlandn Credit notesn Bank account check


5.2.1 Types of payment for payment methods

For most of the Nordic payment formats an indicator is needed to express what kind ofpayment is being made. The kind of payment is needed for the bank to handle the paymentorder correctly. The default type of payment can be set in Data by Bank/Payment Method, andcan be changed for each individual payment in the Payment Advice. In order to minimizehandling errors, you can link a bank format to (a) particular type of payment(s).

The types of payments available are:

n normaln expressn express checkn concern paymentn telen euron nordpayn account transfern group payment

During the creation of the payment file, information about the type of payment will be writtenin the file, along with the invoice to be paid.

5. Nordic

Nordic


5.2.2 Bank costs

In the electronic bank files, information is needed about who pays the costs in case of aninternational payment. You can specify who pays which costs. The following possibilities areavailable:

n Shared (sender pays domestic, recipient pays foreign).n Sender pays all costs.n Recipient pays all costs.n Express costs paid by recipient.

The default value can be set in Banks by Pay to Business Partner, and can be changed for eachindividual payment in Payment Advice.

5.2.3 Customer codes

For some banks, it is necessary to give customer code, division, operator, and so on. All thisinformation can be entered in Bank Relations through the fields:

n Customer Code/Service Numbern Customer Code Extensionn Bank Branchn Operator/Payer IDn Division

When the payment file is being created this information is added in the file to the bank.

5.2.4 Exchange rate agreements

These are agreements you can make with your bank for exchange rates when paying in foreigncurrencies. For each bank relation you can define the currencies for which you have anagreement for contract rates. You can define if currency agreements can be used in the systemby setting the parameter in the COM Parameters.

For each bank relation you can set up various contracts (currency agreement codes). For eachagreement you define the currency for which you made this contract and you define the ratefor that contract. The following rates can be defined for each agreement code:

n Agreement raten Cross raten Payment rate

When you make use of those exchange rate agreements, you can enter at invoice level whetheryou are applying a currency agreement code or not. If so, you define the bank relation and theagreement applicable for this transaction. As soon as you have entered a currency agreementcode to an invoice, this invoice will have a fixed currency rate. This means that until themoment of real payment, no revaluation can take place. During the flow of the invoice fromregistration until creating the payment file, the agreement code attached to the invoice can bechanged and will not result in any revaluation transaction.

The agreement code will go along with the invoice into the payment file, to let the bank knowwhich currency agreement code is applicable. This information is required for all Finnishpayment files and reduces the cost of payment handling.

Nordic


5.2.5 Bank reference

In Finland the whole payment process is based on a so-called bank reference number. This is acalculated key attached to a document number from business partners. Payments are alwaysreferring to this reference number. The reference number is unique for each invoice.

For Finland it is needed for the reference payments in electronic banking to indicate whetherthe payment is negative or positive. Therefore an indicator is added in Electronic BankStatements values.

n At the supplier side you need a field bank reference when entering a purchase invoice,which can be filled in and has to be validated. For this validation an algorithm is used.

n At the customer side you need an algorithm which can compose the required bank referenceout of a maximum length of 19 numeric digits. This number is composed out of thefollowing elements:− customer code− transaction type− document− company

For each element you have to define what the start position will be and what the (field length)should be. The final reference contains the four elements mentioned earlier.

When generating an invoice the reference number is printed on the customer invoice.

5.2.6 Interest invoices on due invoices

Especially for Denmark, you must be able to generate interest invoices even before thepayment (fully or partially) has been done on a certain invoice. Therefore, a parameter iscreated whether you want to have interest invoices on unpaid overdue invoices. When theparameter is on, you have an extra choice in Maintain Interest Invoice Related Data, namelydue and non due invoices. The other standard choices still exist, namely partially paid and fullypaid.

When we choose for due and non due invoices as the basis, then the interest calculation is doneon the basis of unpaid and paid overdue invoices or payments. In case an overdue invoice hasbeen paid partially, interest is calculated over the unpaid part.

Set up

Interest calculation parameters are set in Interest Invoice Related Data.

There are two added fields, namely Minimum Days between Interest Calculation. Here yougive the minimum number of days between two consecutive interest invoices on the sameinvoice or payment.

Calculate Interest from Date is the first allowed date on which interest will be calculated, evenif the due date lies before this date.

Nordic


Interest calculation

The interest is calculated during the selection of Customer Receipts for Interest Invoices. Thisselects overdue invoices, receipts, and assignments from Open Items (Sales Invoices &Receipts).

The number of interest days is calculated as follows:

The starting date is, in the following priority:

n The end date of the last calculated interest periodn The due date of the invoice

If the start date is before the first allowed date (Calculate Interest From Date), the start date isset to the first allowed date and interest will be calculated from that date onwards.

The end date is calculated as follows:

n For document types normal receipt and assignment the system will take the document dateor the interest per date, depend on which date is the earliest. The earliest of both dates willbe taken.

n For document types invoice the interest per date entered on the screen will be taken as theend date.

The period for the interest calculation is then the difference between the start and the end date,as just described.

A new interest invoice is created only if the status of the existing ones are either printed orposted, or else the existing interest invoice is modified to include the new number of days andthe new interest amount.

Creating interest invoices

After the invoices and payments for the calculation are selected and the interest lines arecreated, you can transfer the lines to the central invoicing module. When the lines are comingin the central invoicing module, they can be printed and posted like normal invoices, bychoosing the correct template.

On the invoice, the number of interest days and the start and end dates of the period for whichthe interest is calculated is printed on the invoice. At that moment, the last calculated interestend date is stored in the open item table.

5.2.7 Investment charges

Especially for Norway, you must be able to handle investment charges. This means that whenyou do purchases for your own use, you cannot reclaim the full amount of VAT.

In order to handle the investment charges you have to specify a VAT code where you specifythe correct percentage and the correct ledger account for the investment charge. The purchasetax account will always be taken to post the investment charges.

Nordic


The tax code you specify for investment charges is also specified in the ACP parameters. Assoon as that tax code is specified in the parameters, and you indicate in the invoice lines thatthe investment charge has to be applied, the investment charge is calculated as the definedpercentage applied on the net goods amount.

When the investment charge is applied the amount calculated is charged to the cost account inthe invoice line and the contra account is taken from the purchase tax account for theinvestment charge tax code.

5.2.8 15 payment formats

For the Nordic area, 15 payment formats are added. As far as the euro is taken into account,the bank files are containing the elements to be euro-compliant. In most of the bank files, newfields are added to indicate whether the payment is being done in local currency or in euros.This is made available in the file layout, where needed.

The table below presents bank files that are supported:

2 Nordic Bank Formats

Country Bank Format Type

Sweden Bankgiro Domestic

Sweden Postgiro Domestic

Sweden Sisu Foreign

Denmark DDB Domestic

Denmark DDB Foreign

Denmark Unibank Domestic

Denmark Unibank Foreign

Denmark DBG Domestic

Denmark DBG Foreign

Norway DNB Domestic

Norway DNB Foreign

Finland LM2/Merita Domestic

Finland LM2/Lionia Domestic

Finland LUM2 Foreign

Finland ULMP"2499" Foreign

5.2.9 Extra Journal Report

According to Finnish Law, Financial transactions have to be registered and reported in timesequence to the daybook and in transaction type sequence to the general ledger. In law, thefinancial transaction concerns only financial accounting transactions, not managementaccounting transactions.

In order to be able to print those legal reports in the correct format and correct sequence, a newjournal report for Finland has been added.

Nordic


5.2.10 Credit notes

In addition to the standard, it is possible to allow credit notes to be handled in the payments.This can be done by selecting the parameter Credit Notes Allowed in Payment Methods. Creditnotes (in other words purchase invoices with a negative amount) are then included when youcreate a payment advice, and where possible composed with other payments.

The banking system in Nordic countries can handle those negative payments, and this way ofworking is generically applied in the whole Nordic area.

5.2.11 Bank account check

For Denmark, the 10-check is added. Instead of having the parameter at common level, wenow have the possibility to use more than one check in one system, because the check can beperformed at country level now.

This makes it possible to have two scenarios.

1 Parameter in localization table on no. Bank account check on 10-check. All bank accountnumbers filled in for business partners should be checked with the 10-check.

2 Parameter in localization table on yes. Bank account check has to be indicated in thecountry-table. For Sweden you enter the 10-check, for Netherlands one 11-check, and forBelgium one 97-check. When you enter a bank account number for the business partner, thesystem is looking for the country attached to the address. If for that country the bankaccount check has to be performed, the bank account of that business partner is validatedaccordingly. The following checks are available:− 11 – check− 97 – check− 10 – check− K11 – check− No check

The check is not only performed for business partner bank accounts, but also on their ownbank accounts (in bank relations).

Belgium


6.1 Localization parametersn Intracom reportingn BLWI reportingn Tax journaln VAT report Belgiumn VAT number checkn Belgian bank files


6.2.1 Intracom reporting

With the added functionality you can create the sales listing according to the Intra-EU trade.The conditions for EU reporting are prescribed in Belgian law. One of the things added in themaster data, is the I-codes at business partner level. This is data for the reports that are requiredin Belgium.

6.2.2 BLWI reporting

Companies in Belgium and Luxembourg are obliged to declare their financial transactions(payments) with foreign countries. Usually, the banks declare the payments. But the companymust declare the open entries.

The declaration is done on the provided form, called Opgave van de vorderingen en schuldent.o.v. het buitenland ingevolge goederentransacties. The statement contains a list withinformation about the total amounts of debts and assets as a result of foreign sales andpurchases.

In Baan, the BLWI data is delivered from different places of the package.

The session Process BLWI-Data copies data from sales and purchase invoices to the fileBLWI- Invoice Data.

Also the I-code fields (with the I-code of business partners) and Terms of Delivery field arefilled (with the term of delivery given in the sales/purchase order or, if not present, with theterm of delivery present in the business partner data).

The following invoices are selected:

n Balance of the invoice is not zero;n The VAT country of the invoice is not the own country;n The document type is invoice, credit note, advance payment/receipt and unallocated

payment/receipt.

Before printing the declaration, you can manually change the data in the session to maintainBLWI data.

6. Belgium

Belgium


6.2.3 Tax journal

For Belgium, the journal must be centralized in different ways in order to create ledger reports,required by tax authorities. They require reports with special layouts for transaction types andcentralization by ledger accounts and tax codes.

The daybook is to be centralized by tax code and ledger account. The trial balance can beprinted in Belgian layout for both the financial and reporting period.

6.2.4 VAT report for Belgium

The VAT reporting for Belgium requires an alternative way of presenting the tax amounts.This requires an extra data element, namely the country groups. Those country groups can bedivided in EU countries and non-EU countries as well as the own country.

Those groups are used for the tax reporting, both the tax declaration and the yearly tax reportsas well as the tax journal.

6.2.5 VAT number check

The VAT number check is a way to validate the VAT number, that is entered for a businesspartner. The VAT number check will be performed by country. This will only be done, if youhave selected the VAT Number Check at central level.

Per country you can specify what kind of VAT number check has to be performed (each EUcountry has its own algorithm to verify, like for the bank accounts). By doing this the VATnumber is being checked by the method which is entered for the country where the address ofthe business partner belongs.

6.2.6 Belgian bank files

The Belgian Bank files that are available are for domestic and foreign payments. The one fordomestic payments is available in Baan. The one for foreign payments is added in thelocalization VRC.

Switzerland


7.1 Localization parametersn Swiss invoice roundingn Electronic cash with customersn Electronic cash with suppliersn Payment slips from suppliers


7.2.1 Swiss invoice rounding

Grand total amounts on customer documents with legal character, like invoices, orderacknowledgment and quotations are rounded on 0.05 CHF (the local Swiss currency).

When the parameter is set for the Swiss rounding on invoices and the currency is specified inCentral Invoicing, the grand total from all invoices generated in Central Invoicing withcurrency equal to the currency specified in Sales Invoicing (SLI) will be rounded to 0.05 CHF.

7.2.2 Electronic cash with customers

This functionality covers two parts:

Payment slip generation on the customer invoice

In Switzerland, it is common practice to send out invoices with a payment slip attached to it.The payment slip, which is printed, contains encoded information in a reference.

As soon the parameter is set, the invoices in CHF (to be specified in the Central Invoicingparameters) will be printed with the payment slip attached. To identify the correct bankinformation (post account, sender ID, company ID, and submitters ID) you can specify this atbank relation. During creation of the invoice with payment slip, that kind of information istaken.

Cash receipt and matching/reconciliation with the invoices

The customer who receives the payment slip pays the bill by using that payment slip to thebank account of the company’s bank relation. The bank collects the receipts, and periodicallysends a bank file. The receipts will be posted to Finance and will be reconciled with thecustomer invoices and will update the customer balance accordingly.

The file from the bank is the VESR file (Verarbeitung Einzahlungs Referenz Nummer).

The functionality contains the possibility to read the file from the bank, and reconcile it withthe open customer invoices. A report is will be created whether all receipt lines could bematched and also whether a session is available to make some changes in order to finish thematching. After reconciliation, the file will be posted and the customer balances willbeupdated.

7. Switzerland

Switzerland


7.2.3 Electronic cash with suppliers

For Switzerland, two bank files are commonly used in the outgoing payment traffic: the DTAand SAD file.

For Switzerland, the Swift code and the clearing number are crucial elements to be written inthe outgoing file. Therefore it is possible to specify both the Swift code and the clearingnumber at the address code of the bank.

According to the payment method in the suppliers’ basic data, the respective file for DTA orSAD is created and a report is printed.

7.2.4 Payment slips from suppliers

In Switzerland, it is common practice to record incoming purchase invoices by using an opticalreader. The way to handle this is that the payment slip attached to the invoice is being read byusing an optical reader, this means reading the amount, account number, and identification ofthe sender. The resulting reference may have up to 49 characters, and the individual elementsare filled automatically in the invoice header. When paying the supplier, part of the data readis to be ised in the payment file (DTA or SAD).

India


Indian localization as a part of Localizations1.1 for BaanERP5.0b covers four taxes: centralexcise, sales tax, patent and tax deduction at source. The consumption taxes were included inthe common solution of multiple taxes. Withholding tax solution has been created as acommon solution for some countries.

In addition to tax calculation and accounting, some additional procedures like excise dutypayments, duty payment registers, excise invoices, subcontracting and so on were created inthe system.

8.1 Localization parametersn Multiple taxn Generic taxesn Excise dutyn Indian fiscal reportn TDSn Indian sales taxn RG1 register


8.2.1 Company data

For companies under the purview of taxes in India, it is important to print the tax numbers,registration numbers, details of controlling tax offices and so on. The system supports thefollowing information: excise registration number, ECC, range, division, commissionrate,sales tax registration numbers, permanent account number of income xax, authorization todeduct tax and so on.

8.2.2 Multiple taxes

For tax master data setup, a new procedure to handle multiple taxes is available inLocalizations1.1 for BaanERP5.0b. A tax group can be created with different tax codes forcentral excise, sales tax and patent. The tax group can be used for calculation of all taxes on aspecific transaction of purchase or sales.

While defining tax master data by attaching a tax code to the country, the following set up ispossible:

n Central excise− Kind of tax – manufacturing tax− Tax category – basic excise duty, additional excise duty, special excise duty, and cess

n Sales tax− Kind of tax – VAT− Tax category – not applicable

8. India

India


n Octroi− Kind of tax – transportation tax− Tax category – not applicable

While defining tax rates for excise and octroi, a new feature of item tax category is available.This feature can have two values: Ad Valorem and Specific.

Ad Valorem indicates tax based on value. Tax rates are defined as a percentage.

Specific indicates slab rate. If this kind of rates is defined, new fields in lines, base unitamount, and notification number are available.

8.2.3 Modvat

Taxes are also calculated on purchase. In India, central excise, sales tax, and octroi are normaltaxes charged on purchase. For a central excise on purchase, we have Modvat credit available.

Modvat credit is available to all input, if input result is taxable. However, for some itemModvat credit is not available. To create such a situation, modvatability of items can bedefined in the system. Also, an item can be created as a raw material or an asset to use Modvaton input or raw materials.

The Modvat procedure allows you to record two kinds of credits:

n Quantity credit for goods receivedn Duty credit for amounts.

Quantity credit can be used in Part I of RG23 A or C registers.

Duty credit can be used in Part II of RG23 A or C registers. Entry numbers can be generatedin these registers, and correction entries can be posted as a separate transaction with separateentry numbers. All the entries in RG23 A or C can be printed for each item.

8.2.4 Excise invoice

Excise duty must be paid on the goods taken from the factory. Also, an excise invoice showingduty payable and paid entries, in addition to goods details, sales tax, and octroi should becreated to accompany goods moving out of the factory.

At the time of delivery of goods, excise duty can be calculated, paid and an excise invoice canbe printed for the consignment ready for delivery. If required, correction entries can be createdimmediately or later.

Excise duty payments can be carried out through duty payment registers including RG23 seriesregisters or PLA. Companies may have one PLA for all the clearances, or can maintainseparate PLAs for each chapter. Deposits can be posted to PLA by means of transaction andthe balance in one PLA in a multi PLA scenario can be transferred to another PLA.

All duty payment registers such as RG23 registers or PLAs can be printed separately for eachitem.

India


8.2.5 Sales returns

Sales returns can be handled as a normal return or as a return for damaged goods or goods thatwere rejected for use, and also for repairs and reconditioning.

In case of normal return, the goods can be taken back into the system and duty paid on suchgoods should be reversed. BaanERP has a procedure to calculate tax on goods returned usingreceipt ID created and modvat credit as duty reversal.

Rejected goods should be scrapped. BaanERP identifies this item as a scrap item and updatesthe inventory of the scrap item instead of rejecting the item.

In case of return of goods for repairs, BaanERP has a procedure to record the validity periodwithin which goods should be returned after repair. If goods were returned within the period ofvalidity, no duty is calculated but a zero excise invoice is printed. If goods returned after dateof validity, it is treated as a new sale and excise duty must be paid.

8.2.6 Subcontracting

Material can be moved out of a factory for delivery to a subcontractor to carry out somespecified operations. At the time of clearance, an excise invoice can be created with duty paidat a fixed rate and while receiving the goods for the subcontracting production order, duty paidat the time of clearance can be used as Modvat credit.

8.2.7 RG 1 register

RG 1 register is the daily stock account in the factory. All goods manufactured in the factoryshould be entered in this register. This register can hold manufactured items, customized items,and, optionally, purchased items.

8.2.8 Sales tax and octroi

Since sales tax and octroi tax codes can be linked to the tax group along with excise, taxes canbe calculated along with excise duty, posted and printed in an excise invoice document.

8.2.9 Tax deduction at source

Tax deduction at source relates to withholding income tax in India. A fixed percentage of theamount can be withheld from the payments made to some categories of suppliers and remit thisamount to the government at specified intervals. Currently in BaanERP, system tax can bededucted from payments made to contractor, sub-contractor, service provider, and rentreceiver.

A tax group code can be created with a withholding tax code linked to it. The withholding taxcode should have the kind of withholding tax and tax type on payments.

Withholding tax is calculated when we create a purchase invoice in the system. However, aliability to pay this tax to the government is not created at this point. This is created as acontingent liability in BaanERP and a liability to pay the tax will be created in BaanERP whenwe create a payment in BaanERP.

India


Withholding tax deducted from different business partners can be paid to the government atperiodic intervals. TDS certificates can be printed for each business partners. You can alsoprint annual reports.

Australia


Australian localization in Localizations1.1 for BaanERP5.0b covers two taxes: Australian salestax and prescribed payments system.

9.1 Localization parametersn Multiple taxn Generic taxesn Australian sales taxn PPS withholding taxn Australian fiscal report


9.2.1 Sales tax

Australian sales tax is basically like the VAT system with changes in tax calculation and taxbase.

For sales tax purposes, business partners can have the tax status as: Exempt, Registered,Consumer, or Reseller.

In case of exempt and registered business partners, a valid exemption certificate number isrequired. No tax is calculated for these business partners. In case of consumer, tax is calculatedbut printed along with goods amount. Sales tax for resellers is like standard VAT calculation.

Sales tax can be calculated on different base values. Tax can be calculated based on nationalwholesale price defined in a price book or defined in item, or it can be based on item salesprice.

9.2.2 Prescribed payments system

Prescribed payments system is the withholding income tax in Australia. This applies to allsubcontracting payments.

For the purpose of charging PPS, subcontractors must have categories like: exempt, reportexempt, variation, and taxable.

For exempt business partners, no tax is calculated and deducted but the transactions with thesebusiness partners are reported to the tax office. For exempt business partners, no tax iscalculated and transactions with these business partners are not reported to the tax office.

In specific situations where a subcontractor obtains a certificate for the deduction of tax andmust pay a specified rate other than the prescribed rate, he is a variation subcontractor. For allabove situations, valid certificates are required.

In case of taxable business partners, we have a situation of submission of annual payeedeclaration or nonsubmission. If the payee declaration is submitted, tax is calculated at aprescribed rate. If not submitted then tax is deducted at non declaration rate.

9. Australia

Australia


Withholding tax is calculated when the purchase invoiceis created. However, the liability forpayment of this amount to the government is not created at this point. A contingent liability iscreated in the system and when payments are made then, a tax liability is created in the system.

PPS withheld from different subcontractors can be remitted to the government periodically .

Reports of PPS deduction and payments can be printed monthly and annually.

France


10.1 Localization parametersn Third collectorn Bank account checkn Check printout for Francen Bill of exchange layoutn Electronic file layoutn Trade note for canceling


10.2.1 Third collector

In some countries it is allowed to pay to or receive from a third business partner. Therefore, itis possible to have a different business partner for paying or receiving. To use this possibility,the parameter for third collector must be activated in the ACP and ACR master data. Then it ispossible to change the default pay-to or pay-from business partner in the transaction sessionthat can be activated within the ACP, ACR, or CMG module.

Afterwards it is possible to change these pay-to/pay-from business partners in the OpenEntries. At creating a payment-advice or a direct debit advice it is also possible to havedifferent business partners for either paying or receiving.

10.2.2 Bank account check for France

For France, a K11 check is developed. This check can be linked to a country in the logisticstables. At entering a bank account, the check linked to the country of the supplier is applied.

10.2.3 Printouts for France

The layout of three payment reports are developed to meet the French requirements for thecheck printout for France, the bill of exchange, and the electronic file layout.

When defining a payment method, these layouts can be selected by typing the numberreferring to one of these layouts.

10.2.4 Canceling trade notes

Within bank transactions you can select the option trade note for cancelation. After this youmust select a trade note to be cancelled. It is also possible to select one or more lines of a tradenote instead of the whole trade note.

You can view cancelled trade notes on screen or print cancelled trade note lines on paper.

10. France

France


Portugal


11.1 Localization parametersn VAT rounding for Portugaln Accounts for advanced paymentsn VAT accounts for credit notes & sales interim accounts


11.2.1 Rounding data

The rounding of the VAT can be defined independently from the currency rounding. Withinthe company data you can select a section of the amount to be rounded. For Portugal, the taxamount must be selected. Also the rounding factor has to be defined.

11.2.2 Assigning accounts to VAT codes

Within a tax code, different ledger accounts can be assigned to different posting types. This isobligatory to deal with the requirement that separate VAT accounts must be used in case ofadvanced payments, even at the moment of assigning the payment to the invoice.

In the case of credit notes the VAT must be posted to separate VAT accounts and also a salesledger account is used for credit notes. The following ledger accounts must be defined to meetthe Portuguese requirements:

n Tax Account for Purchase Credit Notesn Tax Account for Sales Credit Notesn Sales Account for Credit Notesn Tax Account for Assigning Advanced Paymentsn Tax Account for Assigning Advanced Receipts

11. Portugal

Portugal


Spain


12.1 Localization parametersn Payment methodn Payment schedulen Receipt schedulen Third collectorn Cash discountn Periodical journaln Multiple control accountn Trade notesn Bank costs in VAT analysisn Spanish invoice layoutn Spanish zero invoicingn Withholding tax


12.2.1 Common functionalities

For the following subjects, please see the chapter common functionalities:

n Payment methodn Payment schedulen Receipt schedulen Trade notesn Multiple control account

12.2.2 Third collector

In some countries it is allowed to pay to or receive from a third business partner. Therefore, itis possible to have a different business partner for paying or receiving. To use this possibility,the parameter for third collector must be activated in the ACP and ACR master data. Then youcan change the default pay-to or pay-from business partner in the transaction session that canbe activated within the ACP, ACR, or CMG module.

Afterwards it is possible to change these pay-to/pay-from business partners in the OpenEntries. At creating a payment advice or a direct debit advice, you can also have differentbusiness partners for either paying or receiving.

12. Spain

Spain


12.2.3 Cash discount

In some countries, the discount that is given on invoices is subtracted before tax calculation.This discount is always taken from the invoice and will be posted at the moment of invoicinginstead of taking and posting it at the moment of making the payment. For the cash discount, aledger account must be defined for this category in the financial business partner groups. Perbusiness partner you can define whether there is a cash discount and how large the discountpercentage will be. At the order and invoice this percentage can be modified.

12.2.4 Periodical journal

The annual report of the journals can be printed. Main changes compared to the standard reportare:

n No dimensions are shownn Transport totals end/begin of pagen Period totals are storedn Page numbers are stored

12.2.5 Bank costs in VAT analysis

With this functionality, the VAT on bank costs will be shown in the tax analysis as well. Abusiness partner will be assigned. This business partner is used to make these transactionsvisible.

12.2.6 Sales invoicing

The printed sales invoice contains required data such as the receipt schedule and paymentmethod information. Invoices with a zero amount can be skipped for printing and posting.

12.2.7 Withholding tax

The purpose of this functionality is to have an income tax applied to certain business partners.When these business partners do send an invoice, a tax amount must be deducted from the totalinvoice amount. These kind of taxes are for special creditors that are not considered as acompany. When you are paying an invoice sent by this creditor you must pay a specified partof the amount to the VAT authorities.

When you enter an invoice for such a supplier you will have the following transactions. In ourexample you have purchased for HFL 1,000. The normal VAT code is 17.5 % and theretention tax is 15 %.

Purchased goods 1,000 D

VAT 175 D

Income tax 150 C

Supplier 1,025 C

The amount of HFL 1,025 should be shown as the open entry. The amount of income tax is notincluded in the balance and is not shown as turnover.

Japan


13.1 Localization parametersn Payment methodn Payment schedulen Receipt schedulen Statement of accountn VAT report Japann Customer approvaln Multiple control accountsn Trade notesn Expenses for employeesn Payment file layout Japann Journal reports Japan



For the following subjects please see the chapter common functionality’s:

n Payment methodn Payment schedulen Receipt schedulen Trade notesn Multiple control account

13.2.2 Customer approval

With this functionality an additional step is defined within the sales procedure: receipt of thecustomer’s approval document. Only after taking this step, invoices can be printed for theapproved goods. Non-approved goods will be returned and for this rejected quantity a returnorder must be created. The creation of the return order is a manual step. A link will be made tothe original order.

The sales obligation (a financial obligation) is created after the goods are delivered orapproved by the customer and not after the sales invoice.

13. Japan

6DOHV�RUGHU

��*RRGV�GHOLYHU\

$SSURYDO��GRFXPHQW

��5HWXUQ�RUGHU ,QYRLFH

Japan


13.2.3 Journal reports Japan

Some specific layouts for Japan were made according to common practice.

n Journal report per daten Journal report per periodn Print general ledgern Tax report

13.2.4 Payment file layout

Bank file layout according to the Japanese Bank Association.

13.2.5 Expenses for employees

Using this functionality you can register returned receipts on cost accounts through the use ofadvance payments to business partners.

The prepaid amount for employees can be registered with the business partners as an advancepayment. After a trip, the remaining amount is returned with the receipts of the costs made.These costs should be posted with the return of the amount.

At the moment of returning and receiving the amount, this should be registered by creating anegative advance payment for the employee. The expenses of the employee can now be postedto the various cost accounts such as lunches and hotel expenses.

13.2.6 Statement of account

You can print a statement of account on certain closing dates in a month. That is, on the 15th

and at the end of a month. On this statement, all entries of this month are shown.

Other information, which is shown on the statement is:

n Remaining amountn Billed in previous statementn Received for previous statementsn Remaining amount (until this statement)n Detail lines (invoices)n Billed for this period

The statement number is assigned to the invoices shown on the statement. This statementnumber is unique for the business partner. A statement contains all invoices within the samecurrency. The due dates of the invoices are recalculated based on the statement date.

For pay-to business partners, an option is available to assign received statement numbers topurchase invoices. You can either do this manually or by range (as they belong to a statementperiod).

Italy


14.1 Localization parametersn Payment methodn Payment schedulen Receipt schedulen Trade notesn Libro Giornalen Vat Bookn Suspended VATn nondeductible VATn Intra-EEC VATn BAM documentn Shipment document in billing requestn Italian VAT on invoicen Print warehouse journaln LIFO by yearn VAT number checkn Withholding tax & social contribution



For the following subjects please see chapter common functionalities:

n Payment methodn Payment schedulen Receipt schedulen Trade notes

In addition to the generic solution, specific reports are provided to support bank remittancesfor payment methods:

n RIBAn RID

14. Italy

Italy


14.2.2 Libro Giornale

This requirement:

n Provides the Libro Giornale report according to the fiscal Italian rules. The user can decideto print all financial transaction into a general Libro Giornale, or in sections whose totalswill then be printed in a summary report.

n Does not allow you to enter transactions in periods for which the Libro Giornale hasalready been printed.

n Stores finally printed Libro Giornale records in a table to keep track of it and enable checkto be performed during transaction processing on the transaction entry date.

The purpose of linking the section code to each transaction type is to ensure that for anytransaction, all the Libro Giornale details are printed.

Main functions

n Create section codes that are used to print the Libro Giornale. Section codes are linked totransaction types.

n Perform checks on transaction entry dates in transaction processing. This check must ensurethat transactions may not be posted if the Libro Giornale has been finally printed.

n Print the Libro Giornale. In case several sections have been maintained, a Summary LibroGiornale is printed as well. The following print options are available: Preliminary, Final,Summary.

14.2.3 VAT book

This requirement:

n Provides the VAT book report according to the Italian VAT rules. The user can decide tosetup as many VAT book codes as required.

n Does not allow you to enter transactions in periods for which the VAT book has alreadybeen printed.

n Does not allow you to enter a transaction for a date less then the last transaction dateentered.

n Prints the VAT liquidation to summarize all VAT on purchases and sales.

n Stores finally printed VAT book records in a table to keep track of it and enable a check tobe performed during transaction processing on the transaction entry date.

Main functions

n Create VAT book codes that will be used to print the VAT book. VAT book codes arelinked to transaction types. The Intra-EEC VAT book check box determines whether aVAT book is to be printed.

n Check the transaction entry date with the last printed VAT book and the last used documentnumber when the transaction type is linked to a VAT book.

Italy


n Print VAT book. BaanERP supports the following print options: preliminary, final, andVAT liquidation.

n Maintain VAT liquidation.

Master data

T r a ns a c tio n C a te g o r y V a t B o o k T y pe

Pu rch a s e i n v o i cePu rch a s e c red it n o te sPu rch a s e c o rre ct i o n s

Jo u rn a l v o u c h e r

Sa l e s in v o ic e sSa l e s cre d i t n o t e sSa l e s co r rec t io n s

V a t B o o k -p u rc h a se

V a t B o o k- sa le s

14.2.4 Suspended VAT

This requirement:

n Matches the Italian VAT rules related to VAT liquidation: in all cases VAT is owed to thetax authority based on the payment of the invoice instead of the issue/receipt of the invoice.

n Reports the suspended VAT on purchase sales invoices separately from normal VAT in theVAT book.

n Enables additional notes to be printed in the sales invoice when the VAT debit is deferredto the credit collection.

n Prints a list of collected suspended VAT for a given tax year and period range.

Main functions

n Collected/Paid Suspended VAT report: it will be used to provide collected and paidsuspended VAT amount to be included in the periodic VAT liquidation.

n VAT book: suspended VAT invoices are properly marked and summarized in the VATbook footer.

n VAT liquidation: suspended VAT is not included in the VAT net balance of the period.Only collected/paid suspended VAT will be considered.

14.2.5 Nondeductible VAT

This requirement:

n Matches the Italian VAT rules related to VAT liquidation: in all cases VAT is totally orpartially nondeductible.

Italy


n Reports the nondeductible VAT separately from normal VAT in the VAT book.

n Supports G/L accounting scheme to allocate nondeductible VAT in the expense account, towhich it refers.

This feature is only available for cost invoices.

Main functions

n The Tax Category field in the Tax Codes by Country (tcmcs0536m000) session allows youto match the VAT rules related to VAT book and VAT liquidation.

n VAT book: nondeductible VAT is reported in a separate column.

n VAT liquidation: nondeductible VAT is not included in the net VAT balance.

n G/L accounting: nondeductible VAT is posted to the expense account, to which it refers.

14.2.6 Intra-EEC VAT

This requirement:

n Matches the Italian VAT rules related to Intra-EEC VAT on purchases where the VATamounts from Intra-EEC acquisitions are offset at each document level by printing the VATbook for Intra-EEC purchases both as a purchase and sales VAT book.

n Support the invoice posting to offset the VAT amount both in ACP open entries and G/Laccounting

Main functions

n A check box in the Section Code (tfgld108m001) session ensures that a VAT book isprinted twice to offset the VAT amounts in the VAT liquidation

n The Shifted tax type selected in the Tax Codes by Country (tcmcs0536m000) sessionensures that the VAT amount is not added to the open entry amount and that it isautomatically reversed in the General Ledger to offset VAT.

14.2.7 BAM

This requirement:

n Matches the Italian fiscal rules related to shipments of goodsn Prints the transport document of (BAM) according to the warehouse proceduren Enhances the central invoicing process to select orders based on the existence of BAM.

The BAM document is a modified version of the packing slip. In warehousing procedures, theuser must still refer to the packing slip.

Note:

Italy


Sales Order

Order Lines

WarehouseOrders

OutboundOrder Lines

Generate OutboundAdvice

Maintain OutboundAdvice

Release OutboundAdvice

Create Shipments

Shipment LinesItem for manualmust be cost item

Create Loads

Compose Loads

ConfirmShipment

Print BAM

Split Shipments

New field for reason/motive

Release to Warehouse

Selection criteria to include terms of payment,reason, currency, transport mode and means oftransport

Manual Shipment

New field for load capacity

When the shipment weight exceeds thecapacity

Italy


14.2.8 Shipment document in billing request

This requirement:

n Selects shipments for invoicing based on the BAM documentn Ensures that invoice date and number are assigned according to the Italian VAT rulesn Ensures that invoice posting date is assigned according to the Italian fiscal rules

Main functions

n In the Billing Request Templates (cisli2501m000) session, a new selection criteria is addedto sales/warehouse orders as well as manual sales: BAM document. Possible enumeratedvalues are One, Several, None. Selection by BAM is only possible when thesales/warehouse order or manual sales enumerated value is other than None.

n To Maintain Billing Request, the Italian VAT book Entry Date field replaces the standardBilling Request Entry Date and can be maintained by the user. This date will be the invoicedate as well as the invoice posting date in the Compose/Post invoice session.

n In the Compose/Print/Post Invoice (cisli2200m000) session, checks are performed to ensurethe invoice date and transaction entry dates are equal and consistent with the last finallyprinted VAT book and Libro Giornale.

14.2.9 Italian VAT on invoice

The purpose of the requirement is to print the sales invoice according to the Italian VAT rules.In particular additional pieces of information are added:

n BAM document number: invoice lines are sorted by BAM document number and ordernumber

n Summary of VAT figures in the invoice footer.

According to the enhanced tax model, taxable and VAT amounts are grouped by tax article.The tax article description is also printed.

14.2.10 Print warehouse journal

An additional report is provided to list all inventory transactions sorted by:

n Warehousen Transaction daten Item

Italy


14.2.11 LIFO by year

The purpose of the requirement is to provide an inventory valuation according to the Italianfiscal principles that are:

n In the first fiscal year, if there is a quantity on hand at the end of the year, the inventoryvalue of each inventory unit is calculated by dividing the total cost ofpurchased/manufactured items by their quantity.

n For the following years, if the quantity on hand at the end of each year is increased from theprevious year, increments in quantity on hand have to be calculated, according to theprevious paragraph, by dividing the total cost of purchased/manufactured items by theirquantity. If the quantity on hand is decreased from the previous year, decrements are takenfrom increments of previous years, starting from the more recent.

n If the unit average price determined as above is greater than the average market price of thelast month of the fiscal year, the LIFO value can be determined by multiplying the totalquantity on hand by the average market price.

Actually, the quantity valued (used for LIFO purposes) can vary by year, or better still, it canonly decrease as in the following example:

Quantity LIFO

Year Quantity onHand

1° Year 2° Year 3° Year 4° Year 5° Year 6° Year 7° Year

1° 100 100

2° 600 100 500

3° 400 100 300 0

4° 700 100 300 0 300

5° 550 100 300 0 150 0

6° 900 100 300 0 150 0 350

7° 1000 100 300 0 150 0 350 100

Italy


100

600

400

700

550

900

1.000

100

300

0150

0

350

1000,00

100,00200,00300,00

400,00500,00

600,00700,00

800,00900,00

1.000,00

1" Year 2" Year 3" Year 4" Year 5" Year 6" Year 7" Year S1 S

2

Quantity on Stock LIFO Quantity

14.2.12 VAT number check

The purpose of this requirement is to ensure that the VAT number is:

n Entered in the Addresses (tccom4530m000) session as well as in the business partner(tccom4500m000) session.

n Correct according to the specific algorithm valid for each european country.

Main functions

n New fields in Country maintenance have been added to enable the check to be performedon the VAT number according to the algorithms of each european country.

n The VAT number is checked both in the Addresses (tccom4530m00) session and theBusiness Partner (tccom4500m00) maintain sessions: missing or duplicated VAT numberwill prompt a warning message. Wrong VAT numbers are not accepted.

Italy


14.2.13 Withholding tax & social contribution

Purpose

The purpose of this feature is to allow the company to meet the Italian requirements regardingwithholding taxes. Withholding taxes is a wide extended functionality.

For this project we focus on the basic structure for withholding taxes, meaning we must beable to handle withholding taxes based on invoices and not integrated with sales commission,neither agents.

Withholding tax and social contribution definition

n Withholding tax (WT)WT are income taxes that must be paid in advance to the fiscal administration as a fixedpercentage of services paid to suppliers. To ensure that taxes are paid, the governmentrequires the subjects who pays the fee to retain the withholding tax from the vendorpayment and reverse it to the fiscal administration. Thus WT are applied on each paymentdone to specific cathegories of suppliers (typically self-employees and agents).

At the end of each year, the subject who has retained WT on vendor payment (thecompany) must send the vendors a declaration containing the amount of WT retained andthen reversed to the fiscal administration. The supplier then uses this declaration tocalculate delta income taxes to be paid.

WT taxes also apply to employees and they are retained on salary payment.

n Social contribution (SC)SC are amounts which the company must pay to ensure that the supplier will get a pensionas well as social services (medical assistance, and so on). As per WT, SC must be paid perservice provided and typically one part of the SC amount is owed by the company and onepart by the supplier.

Usually, the part owed by the supplier is paid direcly from the company, which retain thisamount from the payments. SC also applies to employees and it is retained on salarypayment.

n WT & SC paymentDepending on the type of taxes (WT and SC in their various typologies) amounts retainedmust be paid according to specific rules, which define expiration dates, grouping by taxtype, reporting needs, and so on.

Both WT and SC are normally retained on vendor payments. In case of SC, as describedearlier, the total amount due is taken part from the supplier and part from the company thatultimately must pay the entire amount to the fiscal administration. Once the company hasretained WT and SC from the vendor payments and accrued the part of SC on its account,these amounts must be paid. The same taxes are paid to the same office and due on thesame date (on a monthly basis). So, it is necessary to be able to select taxes by tax group,due date, and so on, as if they were vendor invoices.

Italy


n WT & SC declarationFor both WT and SC the company must issue specific declarations to different subjects.

Following a brief decription of the documents that the company must issue and either sendto the supplier or to the fiscal administration, or to other organizations.

Main functions

n Enhance business partner master data: new of information is supported whenever a vendoris submitted to both withholding taxes and/or social contribution.

n Generate WT and SC accruals while posting the vendor invoice.n Reverse WT and SC in the tax history database when the vendor is paid.n Provide manual update capability of WT an SC history, as well as inquiry and reports.n Manage WT and SC aging and payment.n Provide WT and SC declarations.n Support proper G/L posting process for the above steps.

Documents

BaanERP 5.0b Localizations 1.1 for BaanERP 5.0b Functions ...€¦ · 1 Country-specific requirements, applicable for just one country (such as legal reports) 2 Generic requirements,