Вы находитесь на странице: 1из 83

SAF-T for Portugal

User Guide v1.08


Version History
1.0 Daniela Schobert 17.02.2014 First Release
1.01 Daniela Schobert 12.08.2014 First Revision
1.02 Daniela Schobert Second Revision
1.03 Daniela Schobert Third Revision
1.04 Paul Taylor 25.01.2017 Fourth Revision
1.05 Paul Taylor 18.12.2017 Fifth Revision
1.06 Paul Taylor 05.07.2018 Sixth Revision

 Simplified title of document.


 Addition of new Invoices sources for Self-
billing.
 Addition of Chapter 15 - External
Documents.

1.07 Paul Taylor 30.11.2018 Seventh Revision

 CNCode Indicator added.


 IS-OIL Integration added.
 External Documents Integration &
description of additional Customizing steps.
 Self-billing sections revised and consolidated.
 Customizing for Outbound Deliveries added.
 Customizing for Down Payment Documents
in FI.
 Customizing for Down Payment Documents
in SD.
 Assign Taxonomy Codes Customizing
changed.
 Taxonomy Codes Customizing description
changed.
 Chapters 10 and 15, covering external and
manual documents have been merged.

1.08 Paul Taylor 05/09/2019 Eighth revision

 Usage and behavior of BP Line check box.


Contents

1 TABLE OF CONTENTS
2 INTRODUCTION .................................................................................................................................................. 4
3 FILE STRUCTURE AND PURPOSE ......................................................................................................................... 5
ANNUAL FILE FOR AUDIT PURPOSES ............................................................................................................................ 6
MONTHLY FILE FOR INVOICE REPORTING (E-FATURA) .................................................................................................... 7
4 SELECTION LOGIC ............................................................................................................................................... 8
CERTIFIED DOCUMENTS: INVOICES AND DELIVERY DOCUMENTS ........................................................................................ 8
4.1.1 Exceptions: Excluded documents .................................................................................................................. 8
Reversals ................................................................................................................................................................8
Internal SD documents not posted in Accounting .................................................................................................9
Rebate Agreement credit memos ..........................................................................................................................9
Delivery Document replaced by invoice ................................................................................................................9
WORKING DOCUMENTS .......................................................................................................................................... 9
VENDORS AS CUSTOMERS ........................................................................................................................................ 9
RESTRICTIONS ........................................................................................................................................................ 9
4.4.1 Invoice Lists with Foreign Currencies ............................................................................................................ 9
4.4.2 Billing Documents in Invoice Lists ................................................................................................................. 9
4.4.3 Sales Office Restriction ................................................................................................................................ 10
4.4.4 Plant abroad Restriction ............................................................................................................................. 10
5 SETTINGS ...........................................................................................................................................................10
HOW TO ACCESS THE CUSTOMIZING VIEWS ................................................................................................................ 10
5.1.1 Generic Settings  Specify Generic Settings .............................................................................................. 11
5.1.2 Country-Specific Settings  Portugal ......................................................................................................... 12
SPECIFY GENERIC SETTINGS IN DETAIL ....................................................................................................................... 13
5.2.1 Specify Generic information ........................................................................................................................ 13
5.2.2 Map Document Type to Invoice Type [FI Invoices] ...................................................................................... 15
5.2.3 Map Material Type to Product Type ........................................................................................................... 18
5.2.4 Specify Material Master Data ..................................................................................................................... 19
5.2.5 Define Material Numbers Based on G/L Accounts ...................................................................................... 20
5.2.6 Map sales category to invoice type............................................................................................................. 21
5.2.7 Specify Sales Office...................................................................................................................................... 23
COUNTRY-SPECIFIC SETTINGS IN DETAIL .................................................................................................................... 24
5.3.1 Portugal  Specify Business Cases ............................................................................................................. 25
5.3.2 Portugal  Specify Tax Code Details .......................................................................................................... 28
5.3.3 Portugal  Define Ranges for Internal Documents .................................................................................... 32
5.3.4 Portugal  Define Alternate Accounts ....................................................................................................... 33
5.3.5 Portugal  Specify Prefix for Material Numbers ........................................................................................ 35
5.3.6 Portugal  Display Taxonomy Codes ......................................................................................................... 36
5.3.7 Portugal  Assign Taxonomy Codes to G/L Accounts ................................................................................ 37
5.3.8 Define Document Types for Outbound Deliveries as Invoices ..................................................................... 38
5.3.9 Specify Down Payment Documents for FI ................................................................................................... 39
5.3.10 Specify Down Payment Documents for SD.............................................................................................. 40
5.3.11 Portugal  Source Document Mappings ............................................................................................... 41
Map Payment Method to Payment Mechanism ..................................................................................................41
Specify Details for Tax Like Materials (Product) ..................................................................................................43

6 DATA EXTRACTION ............................................................................................................................................44

1|Page
RUNNING THE DATA EXTRACTION............................................................................................................................. 45
6.1.1 Extract ......................................................................................................................................................... 47
6.1.2 Delete .......................................................................................................................................................... 47
6.1.3 System messages while executing .............................................................................................................. 48
Extraction / Creation:...........................................................................................................................................48
Creation: ..............................................................................................................................................................48
Deletion: ..............................................................................................................................................................48
6.1.4 Administration ............................................................................................................................................ 48
6.1.5 Application Log ........................................................................................................................................... 48
7 FILE CREATION ..................................................................................................................................................50
RULES ................................................................................................................................................................ 52
8 FILE DOWNLOAD ..............................................................................................................................................52
9 FILE VALIDATION ...............................................................................................................................................56
10 SPECIAL DOCUMENTS - EXTERNAL AND MANUAL DOCUMENTS........................................................................57
SCOPE OF EXTERNAL DOCUMENTS IN SAF-T ............................................................................................................. 57
10.1.1 In-scope Documents ............................................................................................................................... 57
10.1.2 Out of scope Documents ......................................................................................................................... 57
EXTERNAL DOCUMENTS INTEGRATION PROCESS ......................................................................................................... 57
10.2.1 Aggregated/Summary documents ......................................................................................................... 57
Digital signature ...................................................................................................................................................57
Location in SAF-T file............................................................................................................................................58
10.2.2 Individual documents.............................................................................................................................. 58
Prerequisites ........................................................................................................................................................58
Digital signature ...................................................................................................................................................58
Location in SAF-T file............................................................................................................................................58
Correction document for external invoices .........................................................................................................59
10.2.3 Documents created manually outside the system (on paper) ................................................................ 60
11 SPECIAL SAF-T FILE – SELF-BILLING ....................................................................................................................60
SELF-BILLING DOCUMENTS AND VENDORS IN SAF-T .................................................................................................... 60
11.1.1 Self-billing vendor ................................................................................................................................... 61
11.1.2 Self-billing documents ............................................................................................................................ 61
SELF-BILLING FILE STRUCTURE ................................................................................................................................. 62
11.2.1 Yearly File................................................................................................................................................ 62
11.2.2 Monthly File ............................................................................................................................................ 62
SETTINGS FOR SELF-BILLING FILE .............................................................................................................................. 62
11.3.1 How to access the customizing views ..................................................................................................... 62
COUNTRY-SPECIFIC SETTINGS FOR SELF-BILLING ......................................................................................................... 63
11.4.1 Portugal  Specify Business Cases ........................................................................................................ 63
11.4.2 Portugal  Specify Destination of XML files storage ............................................................................. 63
11.4.3 Portugal  Generate Selfbilling files...................................................................................................... 64
DATA EXTRACTION FOR SELF-BILLING FILE ................................................................................................................. 65
DELETING EXTRACTED DATA FOR SELF-BILLING FILE ..................................................................................................... 66
FILE CREATION AND DOWNLOAD FOR SELF-BILLING FILE ............................................................................................... 67
FILE VALIDATION FOR SELF-BILLING FILE .................................................................................................................... 68
12 SPECIAL CONFIGURATIONS: FSV FOR GENERAL LEDGER ....................................................................................69
LEGAL CHART OF ACCOUNTS - SNC ......................................................................................................................... 69
CHART OF ACCOUNTS IN SAF-T – GENERALLEDGER .................................................................................................... 69
CHART OF ACCOUNTS IN THE SAP SYSTEM FOR SAF-T ................................................................................................ 70
12.3.1 Using the FSV to create a hierarchical CoA............................................................................................. 70

2|Page
12.3.2 How to create an FSV for SAF-T .............................................................................................................. 70
13 SPECIAL CONFIGURATIONS: PRODUCTS IN FI INVOICES.....................................................................................76
DETERMINATION OF THE PRODUCT DATA .................................................................................................................. 76
13.1.1 Real Estate invoices (RE-FX): ProductCode definition ............................................................................. 76
13.1.2 FI invoices: ProductCode definition ......................................................................................................... 77
13.1.3 FI invoices with Material: ProductCode determination .......................................................................... 79
STORING THE PRODUCT INFORMATION (RE-FX AND FI INVOICES) .................................................................................. 79
14 BADI ..................................................................................................................................................................80
15 AUTHORIZATIONS IN SAF-T ...............................................................................................................................80
INTRODUCTION .................................................................................................................................................... 80
AUTHORIZATION OBJECT: F_SAFT_BUK ................................................................................................................. 80
AUTHORIZATION OBJECT: F_SAFT_OPR ................................................................................................................. 81
AUTHORIZATION OBJECT: F_SAFT_XML ................................................................................................................. 81

3|Page
2 INTRODUCTION
According to Portaria 321-A/2007 of the Portuguese legislation, published in March 26th by the Portuguese
government, a requirement became mandatory as of fiscal year 2008 for all companies that use
computerized means to manage their accounting and billing procedures: the obligation consists in
producing a file, the so-called SAF-T (PT) file, whenever requested by the tax authorities for auditing
purposes or as part of the year end closing activities.

This requirement is part of the requisites that belong to the Software Certification (Digital Signature for
invoices and delivery documents. Check note 2107258 that is obligatory for Billing Software, in Portugal.
Both requisites are therefore linked together, and reference will be made in this manual whenever
appropriate.

The SAF-T (PT) file also serves another purpose, which is the monthly reporting of invoices, the so-called E-
Fatura. This obligation was introduced by Law Decree 198/2012. There have been several legal changes
since.

Relevant legal references:

 Portaria 321-A/2007
 Portaria 1192/2009
 Portaria 160/2013
 Portaria 274/2013 – SAF-T version 1.03_01
 Portaria 302/2016 - SAF-T version 1.04_01

Under the following link you can find all useful information regarding the legal requirement, namely the
XSD file, validators, description of the structure, links to legal texts, etc.:
http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/NEWS_SAF-T_PT.htm

NOTE: The legal change according to Portaria 302/2016, version 1.04_01, is the one described in this
document.

This manual describes all the steps that are necessary to create the SAF-T (PT) file: Settings, Data Extraction,
File Creation and Download and Validation1.

Creation &
Settings Extract Validation
Download

1
As of Portaria 302/2016 and the release of SAF-T (PT) version 1.04_01, the tax authorities in Portugal no longer
provide an online validation URL for file validation.

4|Page
The process to create the SAF-T (PT) file is the same for both the monthly and the yearly file. Whenever
there are differences they are mentioned accordingly.

3 FILE STRUCTURE AND PURPOSE


The SAF-T (PT) file is an XML file with different sections to accommodate the data from different domains,
e.g. accounting, billing, master data, etc. The composition of the file varies according to its purpose. That is
to say that not all the sections are always included.

When creating the SAF-T (PT) file the user should be aware for which purpose the file is being created.

NOTE: the file structure description in the law text contains a few errors. The correct structure is given by
the XSD file.

The table below shows the file sections of a complete SAF-T (PT) file.

File section Explanation

1.1. Header File header

2. MasterFiles Master Data

2.1. GeneralLedger GL Accounts master data

2.2. Customer Customers Master Data

2.3. Supplier Vendors Master Data

2.4. Product Products/Services Master Data

2.5. TaxTable Tax Master Data

3.1. GeneralLedgerEntries Accounting documents

4. SourceDocuments: Source Documents

4.1. SalesInvoices Billing documents

4.2. MovementOfGoods Delivery/Transport documents

4.3. WorkingDocuments Secondary documents to customers

4.4. Payments Receipts/Payment documents

The section containing the Accounting data (GeneralLedger) must contain the complete financial data of
the company in one file only, not to be split in smaller files. The SourceDocument section can be split into
smaller portions.

5|Page
ANNUAL FILE FOR AUDIT PURPOSES
The annual file is normally provided to the tax authorities upon request and it is part of the year-end closing
activities. The obligation to report the data for audit purposes always consists in reporting the complete
data. This can be done in one complete file or in several smaller files, which altogether contain the
complete data. The options and requirements are:

 Integrated file: contains the complete data in one file, related to accounting and logistics (source
documents: sales invoices, payments, movement of goods), both transaction and master data.
 Accounting file: contains only data related with Accounting in one file, both transaction and master
data.
 Billing file: contains only data related with billing, both transaction and master data; it can be split
into smaller portions of smaller periods of at least one month.
There are different kinds of billing files according to the invoices’ nature, e.g. normal customer
invoices, invoices issued on behalf of a third-party and self-billing invoices.

The table below shows the composition of the file according to its nature, as described in the law.

Belongs to file type


(=included; =not included)
File section Explanation
Integrate
Accounting Billing
d

1.1. Header File header   

2. MasterFiles Master Data2   

2.1. GeneralLedger GL Accounts master data   

2.2. Customer Customers Master Data   

2.3. Supplier Vendors Master Data   

2.4. Product Products/Services Master Data   

2.5. TaxTable Tax Master Data   

3.1. GeneralLedgerEntrie Accounting documents 


 
s

4. SourceDocuments: Source Documents   

4.1. SalesInvoices Billing documents   

4.2. MovementOfGoods Delivery/Transport documents   

2
master data may be shown transaction dependent.

6|Page
Belongs to file type
(=included; =not included)
File section Explanation
Integrate
Accounting Billing
d

4.3. WorkingDocuments Secondary documents to 


 
customers

4.4. Payments Receipts/Payment documents   

MONTHLY FILE FOR INVOICE REPORTING (E-FATURA)


The monthly file is produced every month to report invoice data for tax purposes. This is done by
submitting the file on the portal of the tax authorities, the so-called E-fatura portal. When submitting the
file, the portal executes some validations and discards the information that is not needed, since only a
limited amount of information is relevant for invoice reporting purposes. The result is a much smaller file
with a simplified structure containing only the information stored in the database of the tax authorities.

According to the law, the monthly file for the purpose of reporting invoices (E-fatura) has the structure of a
billing file. In practice however, since not all the information is relevant to the tax authorities some of the
information that normally belongs to the billing file can be left out with no impact on the quality of the
reported data. This information is given explicitly or implicitly in the law or can be derived from the
behaviour of the portal. The simplified file, as mentioned above, makes it evident how much of the
information delivered in a SAF-T (PT) file is actually not needed.

The table below shows the composition of the monthly file and shows the sections that are not relevant, as
explained above.

Belongs to Billing file type


(=included; =
File section Explanation
excluded from E-fatura;
=not included)

1.1. Header File header 

2. MasterFiles Master Data 

2.1. GeneralLedger GL Accounts master data 

2.2. Customer Customers Master Data 

2.3. Supplier Vendors Master Data 

2.4. Product Products/Services Master Data 

2.5. TaxTable Tax Master Data 

3.1. GeneralLedgerEntries Accounting documents 

7|Page
Belongs to Billing file type
(=included; =
File section Explanation
excluded from E-fatura;
=not included)

4. SourceDocuments: Source Documents 

4.1. SalesInvoices Billing documents 

4.2. MovementOfGoods Delivery/Transport documents 

4.3. WorkingDocuments Secondary documents to 


customers

4.4. Payments Receipts/Payment documents 

This data is not being excluded in the E-fatura file and when submitting the file in the AT-portal, it is
automatically discarded by the portal itself.

4 SELECTION LOGIC

CERTIFIED DOCUMENTS: INVOICES AND DELIVERY DOCUMENTS


Referring to the rules of Software Certification, invoices and delivery documents must be certified (digitally
signed), without exception, regardless of where and how they were issued, in a billing or in the accounting
system. Following this logic, the decisive criterion to select the relevant documents for the extraction and
inclusion in the SAF-T (PT) file is the digital signature. Thus, all digitally signed documents will be selected
and included in the SAF-T (PT) report while not signed documents will not be included in the file. This logic
is not completely implemented yet, as documents are still being retrieved based on the former logic,
including also not signed documents.

PLEASE NOTE: Digital Signature is a prerequisite for all invoice documents. As of July 1st 2017, a new
validation is in place operating under the following conditions:

 During a 180-day period, from the date of installation, after the 1st of July 2017, you will still be
able to extract data and generate SAF-T files from documents lacking a digital signature, with a
warning being issued for each item.
 After this 180-day period you will no longer be able to extract data from your selected documents
which are not digitally signed, as the validation will cause an error in the report.

4.1.1 Exceptions: Excluded documents


Some documents are excluded from the SAF-T file:

Reversals
Reversal documents of FI and SD invoices are considered internal documents, not representing a
commercial transaction. They are therefore being excluded from the SAFT file – table 4.1. Only the reversed
document is shown in the file. Please note, that reversal documents must have their own number range
and document type.

8|Page
Internal SD documents not posted in Accounting
Such documents are identified by their Posting Status equal D (VBRK-RFBSK) and are automatically
excluded from the SAF-T file – table 4.1.

Rebate Agreement credit memos


Such documents are internal documents never to be printed or issued to a Customer. Therefore they are
excluded from the SAF-T file – table 4.1, based on their Billing Category equal B or C (VBRK-FKTYP).

Delivery Document replaced by invoice


Invoices can be used as delivery documents when sent together with the goods shipment. In such cases
they replace the delivery document which can be considered an internal document that shall not be
included in the SAF-T file – table 4.2. Such delivery documents will be excluded automatically provided the
respective settings are done.

WORKING DOCUMENTS
Some SD documents are automatically reported as Working Documents (table 4.3) and not as Sales
Documents:

 Proforma Invoices identified based on their Document Category equal U (VBRK-VBTYP), are
automatically included in table 4.3-WorkingDocuments. No further customizing is needed. Do not
customize such documents in the FIPTC_DOC_EXC table as this will lead to error.
 Internal documents according to the settings (FIPTC_DOC_EXC) are considered Working
Documents. If, however, such documents don’t have a customer line, they are also excluded from
table 4.3 and will only be included as an Accounting Document.

VENDORS AS CUSTOMERS
When filling the Masterfiles section for Customers (2.2.) the program may select data related also to
Vendors, provided the respective settings have been done, in order to reflect the Vendors as Customers
scenario.

RESTRICTIONS
4.4.1 Invoice Lists with Foreign Currencies
The use of certain documents with foreign currencies (Invoice lists, for example) is unsupported by the SAF-
T solution. This may lead to inconsistencies due to exchange rate differences from the invoice issue date to
the invoice list issue date.

Although unsupported, you may still submit documents in foreign currencies. However, SAP cannot
guarantee acceptance and validation of amounts by the Tax Authorities due to differing exchange rates.

4.4.2 Billing Documents in Invoice Lists


If you use different fiscal periods for the Invoice List creation, you will produce an inconsistent SAF-T file. To
avoid this, you must create as many Invoice Lists as you have fiscal periods. For example, you might have
Invoices 1 & 2 in one fiscal period, and Invoice 3 & 4 in another fiscal period, you cannot group these
invoices in a single Invoice List, but must split them into two separate Invoice Lists (Invoice List A for
Invoices 1 & 2 and Invoice List B for Invoices 3 & 4).

If you need to carry out a reversal of an Invoice List, you must reverse it in the same fiscal period.

9|Page
4.4.3 Sales Office Restriction
If you need to issue a SAF-T file (i.e. for e-Fatura purposes) for a Portuguese sales office in a non-
Portuguese company code, you can only issue a Billing SAF-T. You cannot extract Accounting SAF-T for non-
Portuguese company codes (relevant for the annual audit file).

4.4.4 Plant abroad Restriction


Presently the Plant Abroad scenario is not supported.

5 SETTINGS

Creation &
Settings Extract Validation
Download

Several customizing tasks must be carried out prior to executing the file to ensure that the correct data is
collected, the correct file format is produced and the correct filling rules are applied (e.g. to produce the
Chart of Account hierarchical structure, to collect product data, where it is not defined in the database, or
to identify specific business scenarios).

This is important because sometimes a different behaviour is required to fill the SAF-T (PT) file correctly.
Normally the definition of such settings is a one-time activity or valid for a specific time interval.

The several views in the SAF-T Framework customizing area are explained in this chapter. Use these views
to specify the cases that are applied in the company.

NOTE: The entity on which the SAF-T(PT) file is based is the company code. It cannot be created for
multiple company codes in one step. Running the report for multiple company codes will result in multiple
files, namely as many as there are company codes. These files cannot be merged. Please bear in mind that
the Accounting data must be in one file only according to the legal requirement.

For the entire SAF-T(PT) solution, the company code should be located in Portugal.

RPFIEU_SAFT extractions must be deleted and run again when customizing settings are changed and a new
RPFIEU_SAFT extraction is needed with the new settings.

HOW TO ACCESS THE CUSTOMIZING VIEWS


The views can be accessed in several ways:

Option 1:

Use the transaction code to go directly to a specific view, as specified in each customizing activity case in
this chapter.

Option 2:

10 | P a g e
1) Execute RPFIEU_SAFT report and then select the Define Settings radio button to navigate to the SAF-T
Settings (EU) area menu.
2) Navigate to the next menu as needed
 Generic Settings  Specify Generic Settings

or

 Country-Specific Settings  Portugal

Click the Create New Entry icon to create a new setting. Or, select an existing entry and click the Change
Entry icon to change the existing setting. After creating new entries or changing existing ones, always save
the data before exiting.

5.1.1 Generic Settings  Specify Generic Settings


This menu includes generic settings that are defined based on country. Therefore, always select country PT
before navigating to the specific sub-menu. Multiple definitions are possible, based on company code and
validity period.

11 | P a g e
5.1.2 Country-Specific Settings  Portugal
This menu includes generic settings for each country. Open the menu belonging to Portugal to access to the
next sub-menu.

12 | P a g e
SPECIFY GENERIC SETTINGS IN DETAIL
In this chapter each of the sub-menus will be explained in terms of function, use and the meaning of the
fields. You can access the customizing view by menu navigation as explained above, or using the
transaction code mentioned in each case.

In the following screen you will find the several configuration options, which are explained in this chapter.

5.2.1 Specify Generic information


Use this view to specify the generic parameters that define the scope of the data that needs to be included
in the various sections on the SAF-T (PT) XML file. This customizing task is mandatory.

Please note: You may also use transaction FIEU_GEN to maintain FIEUD_GENERIC table.

13 | P a g e
Explanation of the table fields

Fields Description Content

FSV_PCOA FSV Primary If your Portuguese Company Code uses the Primary Chart
of Accounts (KTOPL in the company code master data),
then specify the Financial statement version in this
field.*3

FSV_CCOA FSV Country If your Portuguese Company Code uses the Country
Chart of Accounts (KTOPL2 in the company code master
data), then specify the Financial statement version in this
field.*

COA Chart of accounts Enter the main chart of accounts defined for the
Portuguese Company Code (even if executing the report
for the country chart of accounts, the entry here is
always the main chart of accounts).

COMPANY_ID Company ID Specify the information required for CompanyID field in


the SAF-T (PT) file Header: Registration Place and
Number, or in case of no registration indicate the VAT-ID
only. Use the syntax required according to SAF-T rule:

 Only one space between the registry place and


the registration number. No spaces in the name
of the place
 No country prefix for the registration number.

Example: Vila_Nova_de_Gaia 500123456

BUSSINESS_NAME Business name Name of the Company for which it is commonly known

14 | P a g e
Fields Description Content

LEDGER Ledger The unique identification of a ledger, in case one is


specified for the data belonging to Portugal. This is the
ledger that contains the data to be reported.

Note: RPFIEU_SAFT does not support Special Ledger


functionality. Only New GL and non-leading ledgers
under New GL are supported.

In case a non-leading ledger is selected then the data of


this ledger along with the data of the leading ledger will
be reported in the XML file. This means that the data of
the leading ledger is always automatically selected
because only the invoices in the leading ledger are
digitally signed.

DIR_SET FTWN Directory Indicate the Directory Set you have maintained for
Set storing SAF-T XML files, under transaction FTWP, in the
File directories tab, where the server path to store the
SAF-T XML files is defined. This is only needed for
downloading very huge XML files. Refer to chapter File
Download for more information.

*Note: Maintain either Financial statement version (primary) or Financial statement version (country), but
not both.

5.2.2 Map Document Type to Invoice Type [FI Invoices]


According to the SAF-T(PT) definitions, the various invoice types are to be reported with the following
values in the SAF-T file:

Invoice Type Invoice type according


to XML

Invoice FT

Simplified Invoice FS

Invoice-Receipt FR

Debit Note ND

Credit Note NC

Sale for Cash and Invoice/ Sales Ticket a) VD

Sale Ticket a) TV

Return Ticket a) TD

15 | P a g e
Invoice Type Invoice type according
to XML

Assets Alienation a) AA

Assets Return a) DA

Premium or Premium Receipt RP

Return Insurance or Receipt of Return Insurance RE

Imputation to Co-Insurance Companies CS

Imputation to Leadership Co-Insurance Companies LD

Accepted Re-Insurance RA
a)
These document types are allowed only until 31-Dec-2012. SAF-T-(PT) files issued after this date must not
contain such invoice types.

FI invoices are identified through the document type. Thus, the system document types must be classified
according to the SAF-T invoice types. In this customizing view the following is specified:

 FI invoice document types that must be included in the SAF-T(PT) file


 The SAF-T invoice type to which the document type corresponds

Prerequisites

 Manual FI Invoices checkbox in the Customizing view FIEUD_BC has been already selected (see
chapter Portugal → Specify Business Cases).

The InvoiceType field in the XML file is filled with the invoice type customized for the retrieved document
type.

Transaction: FIEU_MFI to maintain table FIEUD_MFI

Explanation of the table fields

16 | P a g e
Field Description Content

MANDT Client Client

LAND1 Cty Country PT

BUKRS CoCd Company code for which SAF-T file will be


created.

VALIDITY_FROM Valid from Start date of the validity period

VALIDITY_TO Valid to End date of the validity period

DOC_TYPE Type System document type of FI documents which


are invoices, credit or debit notes and therefore
to be retrieved. This is the internal SAP document
type that will be conversed to FT, NC or ND
according to the SAF-T logic and the nature of the
document.

BP_LINE BP Line This checkbox only has an effect on the


TotalDebit and TotalCredit fields in the 4.1 SAF-T
file section.

Unchecked, the system will consider the amounts


of the G/L lines that represent the invoice line(s)
in the SalesInvoices section of the SAF-T(PT) file
to be summed in the TotalDebit and TotalCredit
fields.

In the case of Down Payment Invoices or Down


Payment Clearing documents, issued in FI, the
amounts to be considered for the TotalDebit and
TotalCredit fields are the ones of the Business
Partner line(s). Therefore, check this box for the
specific document types used for Down Payment
Invoices and Down Payment Clearing to obtain
correct values in the TotalDebit and TotalCredit
fields.

TAGT_INV_TYPE Inv. Type The corresponding official invoice type as


required by the SAF-T(PT) file.

SOURCE Source For Portugal, this field should be defined as blank.


This field is used for SAF-T Luxembourg only.

NOTE: For the retrieval of FI documents, please also refer to the important note given in chapter Using the
FSV to create a hierarchical CoA.

17 | P a g e
5.2.3 Map Material Type to Product Type
According to the SAF-T(PT) definitions, products must be classified according to their type: product, service,
tax like product, or other. The corresponding value is shown in the XML file according to the SAF-T(PT)
rules:

Product Type Value in XML

Products P

Services S

Others O

Taxes, Levies & Parafiscal I


Charges

Special Consumer Taxes E

The SAP standard material types are already defined by default in the program as follows:

Material Type Product Type

DIEN S

FERT P

HAWA P

Customer specific material types must be customized in this view.

Transaction: FIEU_PTYPE to maintain table FIEUD_PRODS.

18 | P a g e
Explanation of the Table Fields:

Field Description Content

MANDT Client Client

LAND1 Country Country PT

BUKRS Company code Company code for which SAF-T file


will be created.

VALIDITY_FROM Valid from Start date of the validity period

VALIDITY_TO Valid to End date of the validity period

PRD_TYPE Material Type The relevant material type as


customized in the system

TARG_PRD_TYPE Product Type Corresponding code as required by


SAF-T file: S, P, O, I or E)

5.2.4 Specify Material Master Data


This view is used to determine Product master data information for FI invoices, in case it does not exist. In
such cases, one option is to define such details based on the revenue account(s) where the FI invoices was
posted to.

Also refer to chapter Special Configurations: Products in FI Invoices, where detailed information on this
process is provided.

Transaction: SAFTPT_FIMD to maintain table SAFTPT_FIMD.

19 | P a g e
Explanation of the Table Fields:

Field Description Content

MANDT Client Client

BUKRS Company code Company code for which SAF-T file


will be created.

GLACCOUNTFROM G/L Account From Revenue Account of the account


interval that determines the
product

GLACCOUNTTO G/L Account To Revenue Account of the account


interval that determines the
product

PRODUCTCODE Product Code Product ID

PRODUCTTYPE Product Type Corresponding code as required by


SAF-T file for filed ProdutType

PRODUCTGROUP Material Group Description of the Product group


Description

PROD_DESCRIPTION Material Description Product description

CUST_SPECIFIC Batch Management This field can be ignored


Indicator

5.2.5 Define Material Numbers Based on G/L Accounts


This view is used to determine the Product ID for FI invoices, in case it does not exist. In such cases, one
option is to define such details based on the revenue account(s) where the FI invoice was posted to.

Note: Always be sure to define the product ID in such a way that it prevents the creation of duplicates to
the ones defined in MARA or for RE invoices.

Also refer to chapter Special Configurations: Products in FI Invoices, where detailed information on this
process is provided.

Transaction: PTSAFT_MATACCNT to maintain table PTSAFT_MATACCNT

20 | P a g e
.

Explanation of the Table Fields:

Field Description Content

MANDT Client Client

BUKRS Company code Company code for which SAF-T file


will be created.

GLACCOUNT G/L Account From Revenue Account based on which


the product is determined

MATNR Material Number Product ID assigned to the postings


of the respective account. This field
is the link to the MARA table.

5.2.6 Map sales category to invoice type


For SD invoices it is necessary to define the InvoiceType according to SAF-T specific InvoiceType they
correspond to. This is defined based on the document category in the SAP system. You can use this
transaction to do the following:

 Specify the possible sales document categories that must be included in the SAF-T
 Map sales document categories to the invoice types as required for SAF-T.

Invoice Type Invoice type according


to XML

Invoice FT

Simplified Invoice FS

Invoice-Receipt FR

Debit Note ND

Credit Note NC
a)
Sale for Cash and Invoice/ Sales Ticket VD

21 | P a g e
Invoice Type Invoice type according
to XML

Sale Ticket a) TV

Return Ticket a) TD

Assets Alienation a) AA

Assets Devolution a) DA

Premium or Premium Receipt RP

Return Insurance or Receipt of Return Insurance RE

Imputation to Co-Insurance Companies CS

Imputation to Leadership Co-Insurance Companies LD

Accepted Re-Insurance RA

a)
These document types are allowed only until 31-Dec-2012. SAF(T)-PT files issued after this date must not
contain such invoice types.

The following SD document categories are already mapped by default in the program:

Sales Document Category Invoice type according to XML

M FT

N FT

O NC

S NC

P ND

Use this customizing view to define other Sales document categories if needed. The corresponding Invoice
Type is then filled in the XML file.

Transaction: FIEU_SDGEN to maintain table FIEUD_SDGEN

22 | P a g e
Explanation of the table fields

Field Description Content

MANDT Client Client

LAND1 Country Country PT

BUKRS Company code Company code for which SAF-T


file will be created.

VALIDITY_FROM Customizing entry valid from Start date of the validity period
date.

VALIDITY_TO Customizing entry valid to End date of the validity period


date.

VBTYPE SD document category The relevant SD document


category that needs to be
defined in addition to the default
mentioned above.

TAGT_INV_TYPE SAF-T (PT) : Target Invoice The respective code for SAF-T
Type invoice type (FT, ND, NC,….).

5.2.7 Specify Sales Office


A company based in Portugal may have multiple sales offices from which the operations are done.
However, among those not all sales offices are necessarily relevant, or you may wish to create a SAF-T(PT)
file only containing the invoices of a specific Sales Office.

To include the invoices only from these specific sales office(s) in the SAF-T(PT), proceed as follows:

Use this customizing view to define the Sales Offices as needed. The corresponding Invoices will be filtered
to be included in the XML file.

Transaction: FIEU_SOFC to maintain table FIEUC_SALESOFC

23 | P a g e
Explanation of the table fields

Field Description Content

MANDT Client Client

LAND Country Fill with the Sales Office country

BUKRS Company Code Company code for which SAF-T file will be
created and to which the sales office
belongs.

VKORG Sales Organization Define the Sales Organization the Sales


Office belongs to

VKBUR Sales Office Define the Sales Office for which the
invoice shall be filtered and included in the
SAF-T(PT) file.

Restriction

1. Filtering invoices by Sales Office is only possible for Sales Offices located in Portugal (Country is
defined as “PT”), just as it is mandatory for the Company Code to be located in Portugal as well,
according to the restriction explained under chapter 3. Settings. If the case is a company code in
another country, with a sales office in Portugal, this solution will not work.
2. The scenario for a foreign company code can only be realized through the implementation of a
BAdI method. Please refer to the BAdI documentation attached to SAP note 1987687.
3. In case there is more than one sales office, then the extraction / deletion of extracted data must be
done for all sales office in one step. It is not possible to extract/delete/create the SAF-T file for each
sales office at a time.
4. If you need to issue a monthly SAF-T (i.e. for e-Fatura purposes) for a non-Portuguese company
code, with a Portuguese sales office, you can only issue Billing SAF-T. You cannot extract Accounting
SAF-T for non-Portuguese company codes.

COUNTRY-SPECIFIC SETTINGS IN DETAIL


In this chapter each of the sub-menus will be explained in terms of function, how to use it and the meaning
of the fields. You can access the customizing view by menu navigation as explained above, or using the
transaction code mentioned in each case.

24 | P a g e
5.3.1 Portugal  Specify Business Cases
Define system or business cases that apply to your company. The report will behave accordingly when
extracting the data or creating the file. Some of these options require additional customizing.

This customizing task is mandatory.

Transaction: FIEU_BCP to maintain table FIEUD_BC

For a new entry, define the general parameters (country key, company code and validity dates) and proceed
to define the details in the frames below. Flag the options which apply to your company.

Explanation of the parameters

Master Data

Field Description Content

VEND_CUST_IND Vendors as Check this to determine if the Vendor's manual


Customers FI credit memos should be considered as
manual FI invoices during the XML file output.

25 | P a g e
Master Data

Field Description Content

INCL_SER_IND Service as Report services as products in the XML file. This


Products is relevant if services are specified in the ASMD
table.

This indication is needed in order to properly fill


Product related information in the XML file for
the products maintained in the ASMD table.

COA_CONV_IND Chart of Indicate whether chart of account conversion


Account or changes to accounts have been performed in
Conversion previous years. This allows you to report the GL
based information as valid in that respective
year.

This setting can also be used in case you need


to reflect a different CoA in the file than the
one in the system (see details under chapter 9.
Special Configurations: FSV for GeneralLedger).

TAX_LINE_MAT_IND Tax like Material Special taxes on the invoice (e.g. luxury tax,
alcohol tax, eco tax, etc.), other than VAT or
Stamp Tax, shall be shown in the XML file as an
invoiced product. Like for “normal” products,
there must be an entry in the Product master
data file section. In the sales document they are
shown in line items like an invoiced product.

IND_CNCODE Disable CNCode The SAF-T file uses Commodity Code/Import


Number for Foreign Trade (Field MARC-STAWN)
to fill the CNCode (Combined Nomenclature
Code).

In your daily business scenario this


alphanumerical field (STAWN) can have
multiple use cases and content.

CNCode, being an official numbers-only code, if


the field contains a value other than numbers,
the SAF-T file will be generated with errors. To
avoid this, you can disable this SAF-T field as it
is not mandatory.

Once you set this indicator the field will not be


filled and it will not show in the SAF-T file.

26 | P a g e
Master Data

Field Description Content

MAIN_ALT_ACCT Main/Alternate Specifies which is the chart of accounts used in


Account the system for Portugal: the primary or the
country chart of account.

Select M, if the Company Code uses the


primary CoA for Portugal; or select A if the
Company Code uses the country CoA for
Portugal

TAXOREF Taxonomy This identifies the type of accounting standard


Reference used by each business, per company code, as
defined in Portaria 302/2016.

S - SNC (ASS)-based accounting rules

N - International Accounting Standards

M - SNC (ASS)-based rules for micro-companies

O - Other accounting systems (undefined)

BUS_SECTOR Business Sector Check this box if the company's business sector
is related to the Insurance business.

27 | P a g e
Transaction Data

Field name Meaning

System data Select which billing documents, or which information regarding the
invoice payment to be extracted. The billing documents can be in
another module, or another system or of a specific kind for a
specific file type.

 Manual FI invoices
 Self-billing Invoices
 FI-CA/IS-U
 RE Classic Data
 RE-FX
 IS-M
 Include Invoice Payment (4.1.4.20.6)
 IS-OIL Data

Enable the options that are applicable for your company.

The Include Invoice Payment (4.1.4.20.6) option allows to include


the payment information in the sub-structure 4.1.4.20.6 which for
performance reasons is excluded by default. This information is not
relevant from a fiscal point of view and may be included/excluded
according to the request of the Tax Authorities.

External data Select the source for invoices to extract; this can be another SAP
solution: Select an external source; this applies when you use other
systems that integrates data in SAP (FI/SD).
For invoices in particular, by making this setting, the information
originated outside SAP, related to Invoice status, Invoice number,
Hash and Hash Control will be read from table SIPT_IF_VBRK. See
chapter Special Documents - External Documents.

It can apply to accounting, billing and tax data.

Include FI-CA Data With the features in this box, you can include the data from an
integrated FI-CA module

Integrated FI + FI-CA By checking this option, the data from the FI-CA systems will be
system included in the file integrated with the FI data.

Stand-alone FI-CA By checking this option, only the data from the FI-CA system will be
system included in the file.

5.3.2 Portugal  Specify Tax Code Details


The tax master data (TaxTable) in the XML file requires tax information different from how it is stored in the
system. Use this view to specify the tax parameters as required to provide the VAT information according
to the requirements of SAF-T(PT). This information is needed in Masterfiles/TaxTables and also in Sales
Invoices.

28 | P a g e
Besides defining VAT or Stamp Duty, you can also use this table to make the settings for Withholding tax.
This information is required in Sales Invoices.

This customizing task is mandatory.

Transaction: SAFTPT_TAX to maintain table SAFT_PT_TAX_DATA

Explanation of the Table Fields

Field Description Content

MANDT Client Client

TAXTYPE Tax Type Desc Define whether the tax code refers
to VAT (IVA), to Stamp Tax (imposto
de selo) (IS), Withholding Tax (IRF)
or if it is not subject to tax (NS).

TAXCOUNTRYREGION Country/ Region Country or Region according to


Portuguese tax regulation:

 For Mainland fill with PT


 For Madeira fill with PT-MA
 For Azores fill with PT-AC

TAXCODE Tx Tax code in SAP system used for


VAT, Stamp Duty or Withholding tax
(entry must exist in table T007A).

29 | P a g e
Field Description Content

TAX_CODE_OFFICIA Tax.Code SAF-T TaxCode, which classifies the


tax code according to its nature; this
information is required in TaxTables
and in Sales Invoices:

for TaxType = IVA:

 «RED» for reduced rate;


 «INT» for intermediate rate;
 «NOR» for normal rate;
 «ISE» for exempted rate;
 «OUT» for other;

for TaxType = IS,

 fill with the official Stamp


Tax Law Code;

For TaxType=IRF,

 fill with IRC


 fill with IRS
 fill with IS

For TaxType=NS,

 fill with NS

TAXEXPIRATIONDAT Tax Expiry date End of validity: last valid date for
this tax rate. This field cannot be left
empty. Enter 31.12.9999 if the tax is
still valid.

DESCRIPTION Text For TaxType=IVA: fill with the


description of the tax code as
required by law in the invoice.

For TaxType=IS: fill with description


of the tax event according to the
Stamp Duty Law.

TAXPERCENTAGE Condition Rate Fill the value of the tax percentage


(only the number, not “%”). If the
tax is not based on a percentage, do
not fill this field. For tax exemption
or not subject to tax fill with 0.

30 | P a g e
Field Description Content

TAXAMOUNT LC tax amount Tax amount in local currency (EUR):


fill only in case tax is defined as
amount

TAXEXEMPTIONREAS Tax Exemption.Reason Reason for Tax Exemption:


mandatory when TaxPercentage or
TaxAmount is zero (exempted or not
subject). Fill with applicable legal
fundament; This information is
required for Sales Invoices

TAXCURRENCY Currency EUR

TAXEXEMPTIONCODE Tax Exemption Code ID code which identifies the reason


for tax exemption.

NON_REVENUE_BASED TaxNRvBa When the specified tax code is


flagged here as being non-revenue-
based it means that the tax amount
is not calculated from a predefined
percentage, but, for example, the
tax calculation is missing from the
line item, or the amount is a fixed
amount value.

This will cause the field “TaxBase” to


be filled with the calculated tax
base; at the same time
CreditAmount, will be filled with 0.

Example:

Tax Country Tax Tax TaxN


Tax Off.Tax. Tax Expiry TaxEx
Type / Text Rate Amount Exemp.Re Crcy RvBa
Code Code Date emp
Desc Region in LC ason

30.06.201 IVA à Taxa


IVA PT A1 NOR 20 EUR
0 normal …

IVA à Taxa
IVA PT A1 NOR 20 EUR
normal …

Isento de Isenção
IVA PT A2 ISE 0 EUR M08
IVA, CIVA…. artº….

Cheques de
IS PT X8 4 qualquer 1.00 EUR
natureza

31 | P a g e
Não
NS PT XY NS Não sujeito 0 EUR M99
sujeito

1
In case an invoice document is issued without a Tax Code the report will see this as a non-taxable
transaction and by default, fills the fields as a non-taxable invoice. The report will assign the following
values:

TaxType - NS

TaxCountryRegion - PT

TaxCode - NS

TaxPercentage - 0

TaxExemptionReason - Não sujeito

TaxExemptionCode - M99

5.3.3 Portugal  Define Ranges for Internal Documents


Internal Documents are documents which you do not want to use for SAF-T file creation, as they do not
meet the legal requirement for an invoice. You must identify documents you consider as internal document
in SD, by defining a number range to which these documents must belong.

Please note: When a document is considered as an internal document it is only possible to exclude the ones
that don´t have a customer line in the accounting document.

If the accounting document of the SD invoice has a customer line, it must be reported in Table 4.3 and
cannot be excluded from Table 4.

For more information, please refer to Error! Reference source not found. Error! Reference source not
found..

Transaction: FIPT_DOC_EXC

Explanation of the Table Fields

Field Description Content

BUKRS Company Code The organizational unit within


financial accounting.

FKART Billing Type

32 | P a g e
Field Description Content

NUMKI Number Range This defines a number range for


internal documents. The number
range typically determines the
document type.

INACTIVE Inactive Determines if number range is


inactive or not.

WRKTYPE Work Type SAF-T files require a Work Type for


Working Documents.

 CM Table Consultation
 CC Consignment Credit
 FC Consignment Invoice
 FO Worksheets
 NE Order Forms
 OU Others
 OR Quotations
 PF Pro Forma
 DC Issued Documents
 RP Bonus or Bonus Receipt
 RE Reversal or Receipt of
Reversal
 CS Attribution to Co-Insurer
 LD Attribution to Leading
Co-Insurer
 RA Accepted Re-Insurance

5.3.4 Portugal  Define Alternate Accounts


Some companies may have carried out a Chart of Accounts Conversion (legally required in 2010 in
Portugal), or simply changed a few accounts. In such cases the accounts history (former account number
and name) may be lost.

In the SAF-T (PT) file, however, the data must be shown according to the facts of the reporting year. For
example, if a conversion was performed during 2010 and a SAF-T file for 2009 is to be created, the
accounts’ data must correspond to the information valid in 2009.

Use the customizing table SAFTPT_ALT_ACCTS, to maintain account information that is deviating from the
currently set parameters.

Whenever an entry exists in this table for the given company code, fiscal year and account it is taken into
the file, otherwise the actual account will be taken from the accounts master data (table SKB1).

Transaction: SAFTPT_ALTACCTS to maintain table SAFTPT_ALT_ACCTS

33 | P a g e
Explanation of the Table Fields

Field Name Description Meaning

MANDT Client Client

F_BUKRS CoCd Define a company code range for which the


T_BUKRS Co.Code account definition is valid

Fiscal year until which the defined account


VALIDTO Year
parameters are valid

Current account number of the Main Chart of


PRIMARYACCOUNT G/L Account
Accounts

Account number as valid in given fiscal year for


ALTERNATEACCOUNT Group acct no.
SAF-T (PT) file

Example:

Scenario 1

In Company Code PT01, Chart of Accounts for Portugal (CAPT) is the main chart of accounts in SAP system;
You choose to create the SAF-T (PT) file with the option “Primary Chart of Accounts”.

In 2009 account 100000 existed in CAPT. However, in 2010 it was replaced by a new account with another
account number 300000.

 SAF-T (PT) file for 2009 shall show account 100000 (in MasterFiles and GeneralLedgerEntries)
SAF-T (PT) file for 2010 shall show account 300000 (in MasterFiles and GeneralLedgerEntries)

 Customize SAFTPT_ALT_ACCTS:

CoCd Co.Code Year G/L Account Group acct no.

PT01 2009 300000 100000

34 | P a g e
Scenario 2

In Company Code PT02, Chart of Accounts for Portugal (CAPT) is the Alternative Chart of accounts in SAP
system; You choose to create the SAF-T (PT) file with the option “Country Chart of Accounts”

In 2009 the main account 100000 had the alternative account 1000 assigned;
In 2010 a new account is assigned to the same main account: 3000.

 SAF-T (PT) file for 2009 shall show account 1000 (in MasterFiles and General Ledger Entries)
 SAF-T (PT) file for 2010 shall show account 3000 (in MasterFiles and General Ledger Entries)
 Customize SAFTPT_ALT_ACCTS:

CoCd Co.Code Year G/L Account Group acct no.

PT02 2009 3000 1000

5.3.5 Portugal  Specify Prefix for Material Numbers


Use this view to specify a prefix for the Product code that identifies the real estate service. This may be
needed to avoid duplication of Product codes and to assure that the Product code is unique.

See more detailed information in chapter Special Configurations: Products in FI Invoices.

Transaction: SAFT_MATPRE to maintain table PTSAFT_MATPRE

Explanation of the Table Fields

Field Name Description Meaning

BUKRS CoCd Company code for which SAF-T file will be created.

Prefix that is concatenated to the Product ID derived from other


MAT_PREFIX Prefix of M No. parameters (see chapter 10. Special Configurations: Products in
FI Invoices)

35 | P a g e
5.3.6 Portugal  Display Taxonomy Codes
Portaria 302/2016 introduced the concept of taxonomy classification codes (Taxonomy Codes), as
described in the official taxonomy lists published in Annex II and III of the Portaria, by the Tax Authority in
Portugal. These Taxonomy Codes indicate the accounting standard associated with each Taxonomy Code.
The Taxonomy Codes are delivered by SAP and are not to be customized by the user. Furthermore, this
table indicates the behavior to be expected for each account in terms of balance.

Transaction FIPT_TAXOCODE to display table FIPTI_TAXOCODE

Explanation of the table fields:

Field Description Content

TAXOREF Taxonomy Reference The accounting Taxonomy


Reference for your company code.

According to Portaria 302/2016 all


Portuguese companies must have
assigned a Taxonomy Reference,
which will identify the type of
accounting standard used by the
company.

TAXOCODE Taxonomy Code Taxonomy code classifies your


company's G/L accounts according
to the official classification
provided by the Tax Authorities.

36 | P a g e
Field Description Content

EXPBAL_CODE Expected Balance Code The Expected Balance Code is used


to inform the user of the expected
balance of the account for each
individual Taxonomy Code, within
the overall SAF-T process.

DESCRIPTION Taxonomy Code Description This field describes the Taxonomy


defined in the TAXOCODE field,
above.

5.3.7 Portugal  Assign Taxonomy Codes to G/L Accounts


To each G/L account under one Company Code, and validity period, you must assign a Taxonomy Code.

Please note: Accounts of type *9 should not be included in this Customizing.

Transaction: FIPT_TAXOACC to Customize table FIPTI_TAXOACC

Explanation of the table fields:

Field Description Content

BUKRS Company code Company code for which SAF-T file will be created.

BEGDATE From Date Define the beginning date of a validity period for the
assignment of Taxonomy Codes to G/L Accounts.

ACC_FROM From Account Define the beginning of a range of G/L Account


numbers for the assignment of Taxonomy Codes.

ENDDATE To Date Define the end date of a validity period for the
assignment of Taxonomy Codes to G/L Accounts.

37 | P a g e
Field Description Content

ACC_TO To Account Define the end of a range of G/L Account numbers for
the assignment of Taxonomy Codes.

TAXOCODE Taxonomy Code Classify your company's G/L Accounts according to an


official classification provided by the Portuguese Tax
Authorities

Note: to provide a more efficient processing of data, please make entries for account number ranges,
instead of making individual entries for every account. For example:

CoCd From Date From Acct To Date To Acct TaxonCd

PT01 01.01.2013 12000000 31.12.9999 12000000 2

PT01 01.01.2013 12000001 31.12.9999 12000001 2

PT01 01.01.2013 12000002 31.12.9999 12000002 2

PT01 01.01.2013 12000003 31.12.9999 12000003 2

PT01 01.01.2013 12000031 31.12.9999 12000031 2

PT01 01.01.2013 12099999 31.12.9999 12099999 2

Would become:

CoCd From Date From Acct To Date To Acct TaxonCd

PT01 01.01.2013 12000000 31.12.9999 12099999 2

5.3.8 Define Document Types for Outbound Deliveries as Invoices


For SAF-T in Portugal, table FIPTC_INV_SHIPTO allows the definition of the relevant billing types for usage
as outbound deliveries. Additionally, this also includes the configuration of the relevant Ship-to Partner
function.

Transaction: FIPT_INV_OUTB_DLV to Customize table FIPTC_INV_SHIPTO

Explanation of the table fields:

38 | P a g e
Field Description Content

BUKRS Company code Company code for which SAF-T file


will be created.

FKART Billing Type Classifies types of billing document


that require different processing by
the system.

ENDDA To Year Define the end date of the validity


period.

BEGDA From Year Define the beginning date of the


validity period.

PARVW Partner Function An abbreviation that Identifies the


partner function associated to the
outbound delivery.

5.3.9 Specify Down Payment Documents for FI


For SAF-T in Portugal, table FIEUC_FI_DOWNPAY allows the definition of the relevant document types for
usage as Down Payment invoice or Down Payment Clearing document. Additionally, this also includes the
configuration of the Special GL indicator used and the procedure applied when posting (net or gross).

Transaction: FIEU_DP_FI to Customize table FIEUC_FI_DOWNPAY

Field Description Content

BUKRS Company code Company code for which SAF-T file will be
created.

GJAHR_FROM From Year Define the beginning year of a validity


period for the assignment of down
payment documents

GJAHR_TO To Year Define the end year for a validity period


for the assignment of down payment
documents.

BLART Document Type Specify the type of accounting documents


which should be identified as Down
Payment or Down Payment Clearing
documents.

UMSKZ Special GL Indicator Identify the Special GL indicator which is


used by the documents. In SAP, Down
Payments are posted to special
reconciliation accounts (special G/L
accounts).

39 | P a g e
Field Description Content

FIEU_IND_DP DP Indicator Identify the entry as a Down Payment or a


Down Payment Clearing document.

FIEU_IND_PROCED DP Prcd. Identifies the Down Payment Procedure


applied to this entry. There are two
procedures available, Gross and Net.

For information on these functions and


concepts, see the "Net or Gross Display for
Down Payments" section of the SAP Help
Portal.

Also make sure to flag the BP-Line checkbox for these documents in the Map Document Type to Invoice
Type [FI Invoices] Customizing as described in sub-chapter 5.2.2.

5.3.10 Specify Down Payment Documents for SD


For SAF-T in Portugal table FIEUC_SD_DOWNPAY allows the definition of the relevant pricing condition
used for the Down Payment Clearing item in the invoice.

Transaction: FIEU_DP_SD to Customize table FIEUC_SD_DOWNPAY

Field Description Content

BUKRS Company code Company code for which SAF-T file


will be created.

GJAHR_FROM From Year Define the beginning year of a


validity period for the assignment
of down payment documents

GJAHR_TO To Year Define the end year for a validity


period for the assignment of down
payment documents.

KSCHL Condition Type Assign the condition type applied to


the SD down payment clearing item
in the invoice.

40 | P a g e
5.3.11 Portugal  Source Document Mappings
The following customizing tasks can be performed:

 Map payment method to payment mechanism


 Specify Details for Tax like materials

Map Payment Method to Payment Mechanism


Use this transaction to map the payment method customized in the system (specified in an invoice) to the
payment mechanism indicators as required for SAF-T file. The payment mechanisms are to be reported
with the following values in the SAF-T file:

Payment Mechanism Meaning


according to SAF-T

CC Credit Card

CD Debit Card

CH Check

CO Check or gift card

CS Compensation of balances

DE Electronic money, e.g. customer loyalty card or points card, etc. ;

LC Bill of exchange

MB Multibanco reference (Portugal specific payment method);

NU Money

OU Others

PR Exchange of goods;

TB Bank transfer or authorized direct debit;

TR Restaurant Ticket

The following payment methods customized in the SAP system are already mapped by default in the
program:

41 | P a g e
Payment Method acc. to SAF-T Payment Method in SAP

C CH

T TB

If it's required to map any other payment methods other than the above-mentioned default values, then
this has to be customized in this view. If no entry is maintained in this table, then the program takes the
value OU (=other) by default to fill this field in the SAF(T) PT file.

Transaction: FIEU_PAYM to maintain table FIEUD_PAYM

Explanation of the table fields:

Field Description Content

MANDT Client Client

LAND1 Country Country PT

BUKRS Company Code Company code for which SAF-T file


will be created.

VALIDITY_FROM Valid from Start date of the validity period

VALIDITY_TO Valid to End date of the validity period

PAY_MECH Payment Method Specify the relevant SAP payment


method (C, T …).

TARG_PAY_MECH Payment Mechanism Select the respective code for SAF-T


(PT) payment mechanism (NU, CH,
TB,…).

42 | P a g e
Specify Details for Tax Like Materials (Product)
Special taxes other than VAT or Stamp Tax shall be treated as an invoiced product (e.g. excise duty, specific
ecological charges, etc.). In terms of SAP system such taxes are normally defined in the SD pricing
conditions. These pricing conditions shall be found and shown as a separate line item in the invoice, net of
VAT. All line item amounts and VAT amounts are recalculated accordingly:

 DebitAmount/CreditAmount (SAF-T fields 4.1.4.19.13 and 4.1.4.19.14): indicate the amount of the
tax/charge/fee in question, net of VAT. In case it is subject to VAT and the VAT amount is included
in the amount given by the pricing condition, the VAT amount is substracted automatically by the
program.
 Tax (4.1.4.19.15): the VAT information regarding this tax-like-material, in case it is subject to VAT,
will be filled in these fields. The VAT amount, subtracted automatically from the amount given in
the pricing condition, is shown here.

These taxes must also have an entry in Masterfiles/Product, as they represent a product. For this, a
customizing table must be maintained in order to define the “product” information, e.g. product number,
product type, etc.

The respective pricing conditions in the SAP system must be identify and customized in table SAFTPT_IMAT.

Transaction: SAFTPT_TAXMAT to maintain table SAFTPT_IMAT

Explanation of the table fields:

Field Description Content

MANDT Client Client

BUKRS Company Code Company code for which SAF-T file


will be created.

TAXLIKEMAT TaxLikeMaterial Indicate the pricing condition of the


tax-like-material. It will also be
taken as Product ID.

MATKL Material Group for SAF-T Material Group for Tax like material
(PT)

43 | P a g e
Field Description Content

EAN11 EAN/UPC International Article Number


(EAN/UPC); identical with the
ProductID

VAT_RELEVANT VAT Relevant VAT relevant Indicator: indicate


whether the tax is subject to VAT.
In case the pricing condition is
defined as “Surcharge” (Condition
Class = A) => non-relevant; in case
the pricing condition is defined as
“Taxes” (Condition Class = D) =>
relevant 1= VAT relevant; 2=Non-
VAT relevant

PRODUCT_TYPE Tax-like Material Value The following values are possible:


O=Other, E=Special Consumer
Taxes; I= Taxes, Levies & Parafiscal
Charges;

6 DATA EXTRACTION

Creation &
Settings Extract Validation
Download

The next step is to perform the data extraction, in order to fill the RPFIEU_SAFT extraction tables
(FIEUD_FIDOC_H, FIEUD_FIDOC_I, FIEUD_FISUMMARY, FIEUD_SDINV_H, etc.). These tables are the basis
for data retrieval while running the report. Before running the extraction you must take some decisions:

- For which purpose do you want to create the file?


- For how many/which periods do you want to create the file?
- Do you want to create a file containing all sections, or only a few?

The answers to these questions determine the scope of the SAF-T file.

NOTE:

Invoices should always be created in “normal” periods (1-12). Special periods are meant for special
accounting activities, such as results determination, account transfers, etc. If there is the case of invoices
being posted in special periods, this will be reflected in the SAF-T file and return an error by the AT-portal
validation.

The master data to populate the Masterfiles section is read directly from the system tables during the XML
file generation; no specific RPFIEU_SAFT extraction tables are used in this case. This is important to bear in
mind especially if you perform frequent data reorganization that implies deletion. Once you delete master

44 | P a g e
data it is no longer available in the database tables. Thus, you should create the XML files before deleting
data. In case you archive data, you need to use the function to retrieve data from the archives.

RUNNING THE DATA EXTRACTION


Execute RPFIEU_SAFT report and then select the Extract Data option.

The selection screen for the data extraction will open. Here you can make your selection according to the
scope of the file you want to create. Consider the explanation of each field shown below.

First you determine whether you want to extract data and fill the RPFIEU_SAFT tables, or if you first want to
delete the current content of the RPFIEU_SAFT tables. If the RPFIEU_SAFT tables are populated with data
from a previous run - for the same or an overlapping period of time - you must first delete it before running
the extraction you need, unless the content is exactly the one you need.

45 | P a g e
Field name Meaning

By selecting this radio button you determine that you want to


Extract
extract data and populate the RPFIEU_SAFT tables

By selecting this radio button you determine that you want to


Delete
delete data from the RPFIEU_SAFT tables

Choose the module for which you want to perform the action. Press
F4 key to see the possible values. For Portugal all modules are valid,
Extract Module except 5-Assets and 6-Purchase Invoices.

An extraction for each module has to be run if data from both


modules has to be included in the same file.

The company code for which you wish to run the extract and create
Company Code the XML file, or remove data from the RPFIEU_SAFT extraction
tables.

Specify the date interval of the data to be extracted, or of the


extract to be removed. You can choose the date interval by
pressing F4 key. NOTE: This selection is based on the date
configuration made under chapter Portugal  Specify Business
Casesas described above.

The Date field provides an F4 help option that allows you to see the
Extraction Date
intervals that have already been extracted. This will help the user to
choose the correct time intervals and/or the correct extract that
already exists, instead of re-creating it.

You must adjust the extraction dates to the XML creation date
interval you will use. The interval must match with the period of the
fiscal year that is reported.

The fiscal year for which you create the extract and want to create
the XML file.
If the fiscal year as defined in the company code is not identical to
the calendar year, the user does not need to worry about that. The
program will always retrieve the data based on the fiscal year.

Note: The SAF-T(PT) file is always created based on fiscal year, not
Fiscal year on calendar year. Companies that use a fiscal year that is different
from the calendar year must be aware that they will not be able to
create one file based on calendar year, if the fiscal year goes across
years.

Non-calendar fiscal years must follow the rules of the IRC Code
(Corporate Income Tax Law). Data of SAF-T(PT) field 1.8 FiscalYear
must corresponds to the year of field 1.9 StartDate.

Database Use this option to retrieve data from the database.

46 | P a g e
Field name Meaning

If documents from the database are linked in the document flow


Includes archive with archived documents you must select this option to additionally
include the archived data.

Use this option to retrieve archived data of the selected extract


module.

If in the selected interval some documents are in the database and


others archived, you must run two extractions. One with Database
Archive
option and a second one with the Archive option.

If the archived data is to be retrieved from FI and SD but the


archives cover different periods of time, the archives must be
extracted individually. This mixed situation is presently not covered.

6.1.1 Extract
Extract the data into the extract tables for a single period, for the complete fiscal year or for a freely
defined interval. The data extracted includes:

 FI transactional data for Accounting data (GeneralLedgerEntries)


 SD transactional data for Billing data (SalesInvoices)
 FI transactional data for Billing data, i.e. FI invoices (SalesInvoices)

Note: make sure that all settings are correctly done as described in chapter Settings.

Choose Extract to run the data extraction from relevant modules (Accounting / Billing). Additionally, the
report will also calculate the total values (total entries, total debit and credit) during the extraction.

If the data volume is high, execute the report in background mode.

If the tables already contain extracted data it is only possible to extract a distinct date interval in order to
add data. It is not possible to run the extraction for overlapping date ranges.

Restrictions:

6.1.2 Delete
Choose Delete under operation selection if you want to remove extracted data from the table. This can be
useful e.g. when

 New documents have been posted in a period after RPFIEU_SAFT data was last extracted.
 Customizing settings have been changed and a new RPFIEU_SAFT extraction is needed with the
new settings.
 You have previously created an extract with the wrong selection criteria.
 The data is no longer needed
 The table size has reached storage limit

47 | P a g e
Note: when deleting RPFIEU_SAFT data you should be using the same dates’ definition you used when
creating the extract. Partial deletion is not possible, extracted dates can be selected from F4 help.

6.1.3 System messages while executing


While running the extraction, file creation or deletion the following situations will trigger a message:

Extraction / Creation:
 Error message when only for “from date” is selected
 Information message when no data is present for extraction.
 Success message when data has been successfully extracted.
 Error message if the extraction is performed for already extracted date range.
 If the fiscal year set is different from the fiscal year of the interval. The same error message will
appear if the dates given belong to different fiscal years.
 If the company code indicated is not configured in the customizing table.

Creation:
 If the dates indicated belong only partially to one of the extracted intervals.

Deletion:
 Information message to avoid partial deletion.
 Success message when data is deleted successfully.

6.1.4 Administration
If new postings are made in a period which has already been extracted, the table content must be deleted
and the period re-extracted.

Note that accounting documents must be extracted if there are FI invoices even if GeneralLedgerEntries are
not to be included.

6.1.5 Application Log


Once the file creation is concluded the system creates a log reporting the number of entries for each
master data section as well as for the transaction data. The log is shown right after the execution. However,
all logs will be stored in the system and can be consulted at any time later. To view the log, proceed as
explained below.

Transaction: SLG1 to access the application Logs created during the different stages of the SAF-T file
creation process.

The Analyze Application Log screen will open (see image below). Enter the selection data as explained in
the table below.

48 | P a g e
Field Description

Object Enter RPFISAFT_LOG

Sub Object In case of the SAF-T (PT) (i.e. for Portugal) enter PT in this field

External ID This field can be left blank

Time Restriction

From (Date/time) From Date / time information of the interval when the
RPFIEU_SAFT report was executed

To (Date/time) To Date /time information of the interval when the RPFIEU_SAFT


report was executed

Log Triggered By

User If known, enter the user name of who had executed the report

Transaction Code Enter *, for any transaction

Program Enter RPFIEU_SAFT

Log Class Select the “All Logs” option

Log Creation Select the “Any” option

49 | P a g e
Field Description

Log Source and Select the “Format Completely form Database” option
Formatting

After having defined all selection fields, press execute or F8 to run the log. In the next screen, as result of
running the log, a list containing all application logs that correspond to the selection criteria will be shown.

The red, yellow or green symbol will tell you whether there were any errors in the execution. Double click
on the exectution you want to see in detail and check the details in the frame below.

The counter beside the symbols shows the number of existing incidents for each
situation, e.g. errors, warnings and simple information.

Look for the critical entries and analyse the error. This can be for instance missing information of a
particular field, missing accounting document to a particular invoice, etc.

7 FILE CREATION

Creation &
Settings Extract Validation
Download

The next step is to perform the file creation, in order to obtain the XML file.

For this choose the option “Create File”. As you click on that radio button the selection screen opens.
Consider the explanation of each field shown below.

50 | P a g e
Field name Meaning

Company Code The company code for which you created the extract and want to
create the XML file.

Tax Accounting Basis ‘TaxAccountingBasis’ field in File Header: Specify which data to
include in the file: C=Accounting; F=Billing; I=Integrated
Accounting and Billing; S=Self Billing; P=Partial Billing.

Depending on the option you select the following data will be


included in each case (see chapter 2.1):
I = complete data included in the SAF-T (PT) file
• Master data GL accounts with the opening and closing balance
• Master data Customers
• Master data Suppliers
• Master data Products
• Master data Tax Table
• General Ledger Entries
• Source Documents (SalesInvoices, MovementOfGoods,
WorkingDocuments, Payment)

C = Only accounting information included in the SAF-T (PT) file

• Master data GL accounts with the opening balance


• Master data Customers
• Master data Suppliers
• Master data Tax Table
• General Ledger Entries

F and P = Only Billing information included in the SAF-T (PT) file


• Master data Customers
• Master data Products
• Master data Tax Table
• Source Documents

Date Date interval for which you created the extract and want to create
the XML file.

51 | P a g e
Field name Meaning

Fiscal year The fiscal year for which you created the extract and want to
create the XML file.

Tax Entity Tax entity, which indicates the establishment that the generated
SAF-T file.

Header Comment Field ‘HeaderComment‘ in File Header: fill with your own free text

File Name File name and path of the target XML file you want to create.

If you have maintained a directory set in transaction FTWP (see


customizing details for FTWN Directory Set) you should respect
specific rules in this field: only file name (without file path) should
be provided, otherwise the XML will be generated in the path
specified, but will not be accessible from FTWN transaction. An
entry would be present in the transaction FTWN for the file.

RULES
For yearly reporting only one Accounting file shall be created for the entire year. Billing files can be created
in multiple smaller files (e.g. per period).

Monthly file: The following rules apply:

 When to run: every month


 What to report: Masterfiles: Customer and Taxes; SourceDocuments: Sales invoices (Billing and FI
Invoices), VAT on Cash Payments
 Deadline: 20th of the following month
 How: Submit the file on the portal

Annual file: The following rules apply:

 When to run: at year end closing or upon request from the Tax Authorities
 What to report:
o Masterfiles: GeneralLedger, Customer, Supplier, Product, TaxTable;
o SourceDocuments: SalesInvoices (Billing and FI Invoices), MovementOfGoods,
WorkingDocuments, Payments
o GeneralLedgerEntries
 Deadline: According to “when to run” specified above.
 How: hand over the file to the TaxAuthorities

8 FILE DOWNLOAD
To download the file to your local PC, run the report RPFIEU_SAFT and proceed with the Download File
option.

52 | P a g e
If you choose Download File, an additional frame will open below, with 3 options. These options refer to
the estimated file size. Select the option that is most suitable for your case. The report will keep this
configuration for the future, but you can change it anytime with the Back (F3) button.

There are 3 options,

 Small to medium files (up to 300 MB): select the ‘File size < 300MB option
 Larger files (more than 300MB up to 1GB): select the File size < 1GB option
 Very large files (more than 1 GB): select the File size > 1GB option

Each option has its own behavior, as explained below:

 For option 1 – File Size < 300 MB (Program RFASLDPC): the following screen will open:

53 | P a g e
Field name Meaning

Source file This field is pre-filled with the generated file; you can also
choose another file.

Input the data used in RPFIEU_SAFT, option Create File,


field File Name.

File type Fill with “**”

Delete source file Check only if you want to delete the file from the server

Copy source file Check this field if you don’t want to remove the file from
the server

Change byte order Leave this field empty

Target disk drive Choose the target drive, or press the Selection of Path and
File button.

Subdirectory (hard disk) Define the target directory

Target file Define the target file name

Standard Code Page 1100 Do not check this option

SAP Logon code Page Do not check this option

No Character Set Conversion Check this option

Manual Entry of Code Page Do not check this option

54 | P a g e
Field name Meaning

Target Code Page Do not check this option

Press the Execute button to download the file. The file download will be confirmed with the following
message on the next screen.

 For option 2 – File Size < 1 GB (Transaction CG3Y): the following screen will open:

Field name Meaning

Source file on application Indicate the source file path and name.
server
Input the data used in RPFIEU_SAFT, option Create File,
field File Name.

Target file on front end Define target path and file name on the local pc

Transfer format for data Define as “BIN”

Overwrite file Check this box if you want to overwrite a previously saved
file with the same name.

Press the Download button to download the file. The file download will be confirmed with the following
message on the next screen.

55 | P a g e
 For option 3 – File Size > 1 GB (Transaction FTWN): the following screen will open:

If you have previously made the right settings to use this option (see customizing and file creation details)
the XML file will be stored in the FTWN environment, in the directory set defined and under the
corresponding fiscal year as indicated for the file creation. The following window of the FTWN environment
will open:

Drilldown to the file you are looking for by opening the fiscal year folder, the SAF-T directory set you
defined and you will find the file(s) that have been created. The file will remain here until you delete it. You
can now use the Export to local file function in the upper menu to download the file to the local PC.

Note: if downloading the file is not possible due to size issues you can also get it directly from the server.

9 FILE VALIDATION

Creation &
Settings Extract Validation
Download

As of Portaria 302/2016 and the introduction of the schema version 1.04_01, the tax authority in Portugal
no longer makes available the online validation feature for SAF-T Portugal, rendering the option to submit a
file for validation as non-usable.

In order to confirm that the file is in accordance with the legal requirements in terms of structure, please
use the official validator from the Tax Authorities. You can find this validator on the Portal das Finanças.

56 | P a g e
Note: The validation of a file created in a system other than the productive system will return an error, as
the public key is not known for test systems.

When submitting a monthly SAF-T (PT) file for the purpose of reporting invoices to the Tax Authorities,
another file validator is provided. This validator excludes some of the validations as they are not relevant
for this purpose. It is automatically called when submitting the file in the portal of the Tax Authorities
without the user noticing.

10SPECIAL DOCUMENTS - EXTERNAL AND MANUAL DOCUMENTS


External Documents comprise documents (e.g. Invoices) that from a system perspective are issued in
another system (with the same or different software) and for business reasons are integrated in the
reference SAP system. They are digitally signed and reported in the SAF-T file of the source software.

The integration of such documents is documented in Despacho 8632/2014. It has special impact on the
creation of the SAF-T file as they must be identified as external documents.

Documents that are integrated in the target system directly in the Accounting system are not relevant for
this process.

SCOPE OF EXTERNAL DOCUMENTS IN SAF-T


Not all external documents are covered by the SAF-T solution for Portugal. In the following sections, you
will find the scope of external documents.

10.1.1 In-scope Documents


The integration of external documents in the existing SAF-T solution covers documents created via the SD
module that will later integrate SAF-T tables 4.1 and 4.3.

10.1.2 Out of scope Documents


The SAF-T for Portugal solution does not cover the integration of external transport or delivery documents.

EXTERNAL DOCUMENTS INTEGRATION PROCESS


External documents can be integrated in the SAP system in two different ways:

- as Aggregated/summary documents
- as Individual documents

10.2.1 Aggregated/Summary documents


In this scenario, several invoices produced externally are integrated as one single document in SAP, e.g. all
documents from the day. This originates a new document that is not a copy of any of the original
documents it represents and therefore must be handled as an original SAP document properly identified in
the SAF-T report.

Digital signature
These documents should have a specific number range and must be digitally signed.

57 | P a g e
The configuration in SIPT_NUMBR_SD table must allow these documents to be digitally signed when they
are being posted. This information will be stored in table SIPT_VBRK.

These documents must not be printed as invoice documents.

Location in SAF-T file


These documents are relevant for table 4.1 and must be identified as a summary document representing
documents from another system. This is done in the InvoiceStatus field by filling it with the value ‘R’.

To pass this information to SAF-T please use BadI Method:

10.2.2 Individual documents


In this scenario, the external document is being replicated in the SAP system on a 1:1 basis. While it is being
created as a new document in the SAP system, some of the original information, such as document date(s),
document number and digital signature, must also be migrated into the SAP system.

However, due to restrictions and validations (legally required for Portugal) in SAP, some differences or
validation problems cannot be avoided. For example, rounding differences between the original and the
target document may be generated, or validations regarding the chronology and sequencing of the invoice
numbering may fail. In such cases, adjustments are needed.

Please check Note 2166344 - Despacho 8632/2014: Interface documents with digital signatures
generated in external systems

Prerequisites
1. View must be maintained to identify the document type of the individual
external documents.
2. In Specify Business Cases (table FIEUD_BC) set the flag for external documents.

Digital signature
Use a specific number range to post these documents.

All validations performed on invoices in the SAP system also apply to the invoices that are originated by
external documents.

However, for these cases, SAP has provided a BAdI (SAP Note 2166344) that allows switching off some of
the validations. Thus, issues deriving from the chronology of dates and the digital signature can be
overcome, provided that the digital signature relevant information of the original document is integrated in
the SAP system.

However, if you choose not to use the the BAdI mentioned above, the external documents will be
redundantly signed when being replicated in the SAP system. This digital signature will be ignored for the
SAF-T reporting as only the original information is relevant.

Location in SAF-T file


To guarantee that the relevant original data are properly reported in the SAF-T file, it is required to
populate table SIPT_IF_VBRK with the needed information from the original document. Check the content
of the table below:

58 | P a g e
OUR_VBELN SAP Billing Document
VBELN Original Billing Document
BUKRS Company Code
NRRANGENR Number range number
LEAD_DOCTYPE Signature PT: Original Leading Billing Document Type
SERIES Signature Portugal: Original Series
INV_DATE Signature PT: Original Invoice/Billing Date
SY_DATE Signature PT: Original System Entry Date and Time
INV_NO Signature PT: Original Invoice Number
GROSS_TOTAL Signature PT: Original Gross Amount
PREVPRINT_CHAR Signature PT: Original Print Characters from the previous invoice
PRINT_CHAR Signature PT: Original Print Characters
CERT_ID Signature PT: Original Certification ID
KEY_VERS Signature PT:Original Encryption Key Version
CREAUSER Signature PT: Original Created By User
CREADATE Signature PT: Creation Date
CREATIME Signature PT: Creation Time
CHANUSER Signature PT: Changed By User
CHANDATE Signature PT: Changing Date
CHANTIME Signature PT: Changing Time
SIGNATURE Original Digital Signature
INVOICE_STATUS SAFT: Original Invoice Status

The table SIPT_IF_VBRK is therefore used as the data base from which the original information of the
external invoices can be retrieved.

In the SAFT file, the integrated external documents must be identified as such. This is achieved by filling
some of the fields differently:

 Fill the field InvoiceNo with the original invoice number from the external system.
 Fill the field HashControl in tables 4.1 and 4.3 as follows: certificate number from the original
software + dot + version of the certificate of the original software. Example: “9999.1”; where 9999
is the certificate and 1 is the certificate version key;
 Fill the Hash field with the digital signature created in the original software;
 Fill the SourceBilling field with the value ‘I’;
 In case the original software is not certified, the Hash field should be filled with ‘0’ (zero) and the
HashControl field with the phrase ‘Não certificado’

Correction document for external invoices


The correction of external documents should always happen in the original system. In SAP, the correction
invoices (eg. credit memos) are subject to validations and must refer to the invoice being corrected. If the
corrected invoice is an external document, it is the original information that must be shown in the SAFT file
as the reference document. The SAFT program will check this in the SIPT_VBRK or in SIPT_IF_VBRK tables.

If the corrected invoice is not present in the SAP system at all, its number must be maintained in the
SIPT_CM_EXT_REF table so that its validation does not fail.

59 | P a g e
10.2.3 Documents created manually outside the system (on paper)
Documents that are created manually on paper, i.e. in case of system downtime, and later integrated in the
billing and accounting system should follow specific rules:

- Use a specific number range when integrating such documents in the target system and activate
the digital signature for such documents.
- Integrate this document in the SAF-T file considering the following rules:
o Fill HashControl field in tables 4.1 and 4.2 with the certificate key version + hyphen + the
SAF-T document number; add the value ‘M’ at the end of the document type (which is part
of the SAF-T document number). Example: 1-FTM abc/00995, where ‘FT’ is the document
type; ‘M’ is the added value that identifies the document as a manual document; ‘abc’ is
the series and 00995 is the sequential number.

11 SPECIAL SAF-T FILE – SELF-BILLING


Special SAF-T files are files that are issued when special business scenarios exist, for instance Self-billing. All
steps described above apply to the special SAF-T files as well. The specificities are described here.

Self-billing invoices are invoices that a company issues to itself on behalf of the vendor. These are invoices
that need to be reported in the SAF-T (PT) file, namely in the SourceDocuments – SalesInvoices section of
the SAF-T structure.

When this scenario is practiced it is assumed that an agreement exists between the selling and buying
party. In practice, Self-billing invoices are issued by the client. Being documents that are reported as Sales
Invoices they must be reported by the Selling party. However, they are created in the buyer’s system
According to the legal requirement of the SAF-T file, the SAF-T file should always be created in the system
where the data is created and the reported documents are issued.

From this, it is clear that it is the Buyer (the issuer of the Self-billing invoices) who is obliged to create the
Self-billing SAF-T file. Once the file is created, he hands it over to the vendor, who eventually submits it to
the authorities.

Note: It is necessary, and legally required, to create one separate SAF-T file per Self-billing vendor. Each file
contains the Self-billing invoices, Products and Vendor data pertaining to that specific vendor only. There
will be as many Self-billing SAF-T files as there are Self-billing Vendors with Self-billing invoices in the
reporting period.

The Self-billing SAF-T file shall not be integrated with any other SAF-T file. The structure of the file is
described next.

SELF-BILLING DOCUMENTS AND VENDORS IN SAF-T


The self-billing files are to be generated for each vendor with whom the company has the self-billing
agreement set.

60 | P a g e
11.1.1 Self-billing vendor
To define a vendor as Self-billing vendor, you need to do the appropriate settings in the vendor master
record. Go to the vendor’s master record and in the Purchasing data tab flag the AutoEvalGRSetm Del. and
AutoEvalGRSetm Ret.checkboxes.

11.1.2 Self-billing documents


Only invoices created with the following transactions and certified according to legal requirement are
considered when creating the Self-billing SAF-T file in SAP:

 Vendor Invoice
o MRRL: Evaluated Receipt Settlement
o MRNB: Settle Consignment/Pipeline Liabs.
o MIRO: Enter Incoming Invoice
o MRER: Auto. ERS Automotive
o MRIS: Settle Invoicing Plan
 Consignment
o MRKO: Revaluation

Note: other transactions used to generate Self-billing invoices, including invoices generated in FI, are not
supported.

61 | P a g e
SELF-BILLING FILE STRUCTURE
The structure differs only very little from the normal Billing SAF-T file, the so-called “F” file
(TaxAccountingBasis = F). The differences are specified here. In all other aspects the same rules as for F-files
apply.

11.2.1 Yearly File


The Yearly Self-billing SAF-T file includes the following file sections, with the respective content:

 Table 1: Header (content: data of the Supplier company)


 Table 2: Master Data
o Table 2.2 – Customer (content: data of the invoice issuer – only one entry)
o Table 2.4 - Product (content: only the products mentioned in the invoices)
o Table 2.5 - TaxTable (content: only the tax information from the included invoices)
 Table 4: SourceDocuments
o Table 4.1 – SalesInvoices (content: self-invoices issued on behalf of the particular
supplier mentioned in the Header)

11.2.2 Monthly File


The Monthly Self-billing SAF-T file includes the following file sections, with the respective content:

 Table 1: Header (content: data of the Supplier company)


 Table 2: Master Data
o Table 2.2 – Customer (content: data of the invoice issuer – only one entry)
o Table 2.5 - TaxTable (content: only the tax information from the included invoices)
 Table 4: SourceDocuments
o Table 4.1 – SalesInvoices (content: self-invoices issued on behalf of the particular
supplier mentioned in the Header)

According to the general rules of the monthly SAF-T file, the Product table (2.4) is not included.

SETTINGS FOR SELF-BILLING FILE


Before using the RPFIEU_SAFT report to create the Self-billing SAF-T file, a few configurations must be
made. These are described in this chapter.

11.3.1 How to access the customizing views


Follow the instructions detailed under the chapters How to access the customizing views and Country-
Specific Settings -> Portugal to access the settings area. You will find a submenu that is meant for Self-
billing settings only.

62 | P a g e
COUNTRY-SPECIFIC SETTINGS FOR SELF-BILLING
In this chapter the Self-billing relevant sub-menus will be explained in terms of function, how to use it and
the meaning of the fields. You can access the customizing view by menu navigation as explained above, or
using the transaction code mentioned in each case.

11.4.1 Portugal  Specify Business Cases


Follow the instructions detailed under chapter Portugal Specify Business Cases and enable the Self-billing
business case.

11.4.2 Portugal  Specify Destination of XML files storage


When files for multiple vendors are to be generated maintain the file path where the files shall be stored in
the application server by maintaining the information here.

Transaction: FIEU_PATH to maintain table FIEUC_SBXML_PATH

Explanation of the Table Fields

63 | P a g e
Field Name Description Meaning

LAND1 Ctr Country Code

BUKRS CoCd Company Code

Choose Self Billing (MM module )


invoices generated via one of the
INV_SOURCE Invoice Source
following Tcodes: MRER, MRIS,
MRRL, MRNB, MIRO, MRKO

FILE_TYPE File Type Choose Self-billing

Provide the complete path and file


FILE_PATH File name name in the server where you wish
to store the files.

11.4.3 Portugal  Generate Selfbilling files


Here you make the settings regarding which transaction and document type you use to create Self-billing
invoices for a vendor.

Transaction: FIEU_SBINFO to maintain table FISAFTPTC_SBINFO

Explanation of the Table Fields

Field Name Description Meaning

BUKRS Company Code Company Code

LIFNR SAFT PT: Self Billing Vendors ID of the vendor

BLART Document Type Document Type used for that vendor

64 | P a g e
Field Name Description Meaning

VALIDFROM Date for beginning of validity Date from which this setting is valid

VALIDTO Date validity ends Date until which this setting is valid

SHKZG Debit/Credit Indicator Is the posting made as debit or credit

Transaction codes used to post the Self-billing invoice,


according to the list contained in Self-billing documents:

 Vendor Invoice
o MRRL: Evaluated Receipt Settlement
TCODE Transaction Code o MRNB: Settle Consignment/Pipeline Liabs.
o MIRO: Enter Incoming Invoice
o MRER: Auto. ERS Automotive
o MRIS: Settle Invoicing Plan
 Consignment
o MRKO: Revaluation

DATA EXTRACTION FOR SELF-BILLING FILE


Proceed as described under chapter Data Extraction in order to extract Self-billing data, choose the
respective Extract Module 9 Self Billing. Upon filling the selection parameters, a new user input sub window
appears. It is specific for the Self-billing scenario and allows you to choose the vendors for whom you want
to run the report and create the file.

Options:

 Extract for individual Vendor: choose this option to run the file only for specific Vendors
 Create data for All Vendors: choose this option to run the file for all Vendors at once. A Self-billing
SAF-T file will be created for each of the vendors entered in the customizing table as described
under chapter Portugal -> Generate Selfbilling files.
 Selfbilling Vendor: fill this field with the vendor ID or vendor ID range according to the files you
want to create. These selection fields are available for the Extract for individual Vendor option only.

Continue as described under chapter Data Extraction.

In the case of Self-billing SAF-T file creation the log will refer to the data related to the Self-billing vendors
set, whether documents exist, etc.

65 | P a g e
DELETING EXTRACTED DATA FOR SELF-BILLING FILE
To delete the extract for re-extraction of data for the same vendor for already extracted periods or for
clearing the database after the submission process is completed and verified, if needed, select the option
Extract Data > “Delete” as shown below.

Like the Extraction, the Deletion of extracted data can be done for individual vendors or for all vendors as
maintained in the table and for which there were data extracted previously.

To delete the data for an individual vendor or for a few vendors, select the “Delete for Individual Vendor”
option and provide the relevant vendor numbers in the “Self Billing Vendor” selection field.

If all Self-billing data extracts need to be deleted select the “Delete for All Vendors” option and execute the
report

In both cases the deleted data from the extract table is shown in the log showing next.

66 | P a g e
FILE CREATION AND DOWNLOAD FOR SELF-BILLING FILE
Proceed as described under chapter File Creation. All that is described there applies for Self-billing SAF-T file
creation.

For creating Self-billing SAF-T files, some of the selection parameters have to be filled with specific values:

 TaxAccountingBasis: S

Upon filling the selection parameters, a new user input sub window appears. It is specific for the Self-billing
scenario and allows you to choose the vendors for whom you want to run the report and create the file(s).

Options:

 Individual Vendor: choose this option to run the file only for specific Vendors
 Create File for All Vendors: choose this option to run the file only for all Vendors at one time. A Self-
billing SAF-T file will be created for each of the vendors entered in the customizing table as
described under chapter Portugal -> Generate Selfbilling files.
 Selfbilling Vendor: fill this field with the vendor ID or vendor ID range according to the files you
want to create. These selection fields are available for the Individual Vendor option only.

When creating the file for an individual vendor, provide the file name in the appropriate File Name field on
the selection screen. If no path is specified the file will be stored in the physical path location maintained as
the logical file path DIR_HOME.

In case of file generation for all vendors, the file name is created automatically, consisting of the vendor ID,
the date interval for which the file is created, creation date and time.

Once the process is completed, an application log with the file names and the summary of the data
included in each file will be shown.

67 | P a g e
For downloading the file proceed as described in chapter File Download.

FILE VALIDATION FOR SELF-BILLING FILE


For validating the Self-billing file proceed as described in chapter File Validation.

68 | P a g e
12SPECIAL CONFIGURATIONS: FSV FOR GENERAL LEDGER
The file section GeneralLedger in Masterfiles contains the data regarding the company’s accounts..

As of Portaria 160/2013, this section shall include all accounts, even internal accounts, in a hierarchically
structured manner. This is a legal change compared to the previous rule, where only valid bookkeeping
accounts were required and the hierarchical structure was not reflected.

To achieve this, special configurations are needed in the SAP system. The tool used is the Financial
Statement Version (FSV), a standard tool in SAP Financials. In SAP, this information is pulled from FI.

Once the FSV has been created it must be defined in the RPFIEU_SAFT settings so that the program knows
which one to use. If necessary, update the FSV every time the chart of accounts changes. To know more
about how to set the FSV for the report, please refer to chapter Specify Generic information.

NOTE: The existence of an FSV is NOT needed for retrieving the accounting documents into SAF-T. In
compliance with the legal requirement, all financial postings are selected for SAF-T.

LEGAL CHART OF ACCOUNTS - SNC


In the Portuguese Official Chart of Accounts – SNC – accounts are structured in a hierarchy consisting of
movement accounts (lower level) and grouping accounts (higher level) (see picture below). Movement
accounts are accounts where the actual postings are registered and grouping accounts are accounts that
group movement accounts of the same kind and totalize the balances.

The image below is an excerpt of the SNC.

CHART OF ACCOUNTS IN SAF-T – GENERALLEDGER


The 2.1.-GeneralLedger file section includes the Chart of Accounts information. It has the following fields:

Field number Field Name

2.1.1 AccountID

2.1.2 AccountDescription

2.1.3 OpeningDebitBalance

69 | P a g e
2.1.4 OpeningCreditBalance

2.1.5 ClosingDebitBalance

2.1.6 ClosingCreditBalance

2.1.7 GroupingCategory

2.1.8 GroupingCode

The fields GroupingCategory and GroupingCode characterize an account in two aspect.

The GroupingCategory field indicates

 the level of the account: 1st level, grouping account or movement account, and
 whether it is an internal or analytical account, or a bookkeeping account

The GroupingCode field indicates the account in the immediate upper level of the account in question,
except for 1st level accounts, which are the highest level.

Thus, the accounts information included in the GeneralLedger section reflects the CoA structure according
to the SNC.

CHART OF ACCOUNTS IN THE SAP SYSTEM FOR SAF-T


In the SAP system, accounts are stored in a flat table. The concept of a hierarchical Chart of Accounts (CoA)
with grouping and movement accounts does not exist. In order to correctly select and structure the account
information as required, the Financial Statement Version (FSV) is used. The FSV is a tool in Standard SAP
Financials that is used to build a report structure based on accounts, such as the Balance Sheet, the P&L
Statement, etc.

12.3.1 Using the FSV to create a hierarchical CoA


The FSV is a reporting tool that is used in this context to build the CoA as needed in the GeneralLedger
section. It allows you to build the hierarchy, to define the account groups, to characterize accounts as
internal or as bookkeeping accounts, to distinguish movement, grouping and 1st level accounts and to sum
balances.

In this chapter important details are described that have to be considered to create an FSV that fulfils all
SAF-T requirements.

IMPORTANT NOTE: It is recommended to create a specific FSV for the SAF-T purpose. The ones normally
used for Balance Sheet or Trial Balances do not comply with all requisites. Only by creating a specific FSV
can you ensure that all the necessary settings can be done without interfering with other FSV applications.

12.3.2 How to create an FSV for SAF-T


Use transaction OB58 to create the FSV.

The FSV can be created based on the Primary Chart of Accounts (KTOPL) or on the Country Chart of
Accounts (KTOP2). Choose the option that is in place in your company code.

70 | P a g e
When defining the FSV for SAF-T please consider the following:

a) The CoA structure according to SNC:

For this, you need to define the group and the 1st level of each account in accordance with the SNC.
For example: consider that you use in the system 4 different cash accounts.

According to SNC, the characterization of the accounts is as follows:

Account No. Account description CoA level

Cash and cash


100000 1st level
equivalents

110000 Cash Grouping account level

111000 Cash account A Movement account

112000 Cash account B Movement account

113000 Cash account C Movement account

114000 Cash account D Movement account

Since only the movement accounts actually exist in the system, you must therefore define the two upper
levels (shown in blue) in the FSV. Only then they can be reflected in the SAF-T file.

The 1st level account and the grouping account (shown above in blue) normally are not defined in the SAP
system, because they are not used for posting. This can be solved with the FSV and is explained below.

b) The SAF-T GeneralLedger

When translating what is said above to the SAF-T fields in the GeneralLedger section, you must pay special
attention to specific fields where the characteristics of the CoA are determined. Please look at the example
in the table below where this is explained: two columns were added to show how to use the fields
GroupingCategory and GroupingCode.

SAF-T
Account GroupingCategory SAF-T
Account description CoA level GroupingCode
No. Official Internal [=the node above]
accts accts

Cash and cash


100000 1st level GR AR
equivalents

Grouping account
110000 Cash GA AA 100000
level

111000 Cash account A Movement account GM AM 110000

71 | P a g e
112000 Cash account B Movement account GM AM 110000

113000 Cash account C Movement account GM AM 110000

114000 Cash account D Movement account GM AM 110000

Define for each account in the CoA how to fill the GroupingCategory and GroupingCode fields.

The GroupingCategory determines two characteristics: the account level and the account nature as
bookkeeping or internal account.

 Account nature: G means bookkeeping account: GR, GA and GM; A means internal account:
AR, AA and AM.
 Account level: R means 1st level, A means grouping account level and M means movement
account level. Thus GR and AR are used for 1st level accounts, GA and AA for grouping
accounts and GM and AM for movement accounts.

c) The FSV structure:

Once the CoA structure has been defined, proceed to create the FSV, with its items and nodes so as to
correspond to the CoA structure.

The upper FSV item corresponds to the 1st Level Account, the node below corresponds to grouping
account, and the accounts grouped by the node are the movement accounts. Refer to the images below
where this is explained.

 The opening and closing balances will be summed from bottom to top:
from the underlying movement accounts into the Grouping account, and from the grouping
accounts into the 1st Level Account.

NOTE: Be sure to flag Debit and Credit for all accounts, otherwise duplication of the account can happen in
the XML file.

d) Bookkeeping and internal accounts:

The accounts must also be characterized according to whether they are internal (eg. analytical account, not
official account of the SNC) or bookkeeping accounts. This is specified in the Item text field of the FSV item.

72 | P a g e
 Internal account: to specify an account as internal use the prefix “TP” in the FSV item text
field, followed by the text of your choice. See the picture below. The report automatically
interprets this as an internal account indicator. For these accounts the system will
automatically fill the GroupingCategory field with one the respective codes (AR, AA or AM),
according to the account level.
 Bookkeeping account: all accounts where the prefix is not used, are interpreted as
bookkeeping accounts.

e) Account level:

The accounts must also be differentiated according to their hierarchical level. In the FSV the account level is
determined according to the FSV level to which the account has been assigned. The SAF-T report interprets
this automatically and fills the GroupingCategory field accordingly:

SAF-T
GroupingCategory
CoA level FSV level
Official Internal
accts accts

1st level Main parent node: 1st Item level GR AR

Grouping account Sub node: 2nd Item level GA AA

Movement Lowest level: the actual GL account


GM AM
account assigned to the 1st or 2nd node

Please see the example below for bookkeeping accounts.

73 | P a g e
NOTE: Be sure to flag Debit and Credit for all accounts, otherwise duplication of the account can happen in
the XML file.

f) Hierarchical structure:

The hierarchical structure of the accounts is expressed by the GroupingCode field in the SAF-T. It contains
the account ID of the parent account (the level immediately above). In terms of FSV this corresponds to the
account specified in the immediate parent node. The report fills this field automatically and nothing needs
to be specified by the user.

This is valid for all accounts except for the 1st Level Account, since it does not have a parent node. The
table below shows how the GroupingCode field would be filled by the report in the case of the example
above.

SAF-T
Account No.
GroupingCode

100000

110000 100000

111000 110000

112000 110000

113000 110000

114000 110000

g) Summing the balances:

The SAF-T file also requires the opening and the closing balances of each account. For grouping accounts
and for 1st level accounts the balances consist in the sum of the balances of the accounts below.

In order to sum the account balances from the underlying accounts proceed as follows: check the Display
total checkbox in the FSV item. The report will automatically sum the balances of the underlying accounts
and write the value in the OpeningBalance and ClosingBalance fields.

74 | P a g e
In the example above,

 The account 110000 should show the sum of the underlying accounts; in the example accounts
111000, 112000, 113000, 114000.
 The account 100000 should show the sum of the underlying accounts; in this example account
110000.

IMPORTANT NOTE:

The Start of Group, End of Group and Graduated Total fields must be left empty, as shown in the image
below marked in yellow). This is important for technical reasons because if any text is maintained here, the
accounts will appear multiple times in the file.

Leave Start of Group,


End of Group and
Graduated Total fields

75 | P a g e
13SPECIAL CONFIGURATIONS: PRODUCTS IN FI INVOICES
Sometimes invoices are posted directly in the accounting system instead of the billing system. Such invoices
are what we usually referred to as FI invoices. These invoices have to be reported in this SAF-T file as well.

Normally the goods or services invoiced in FI are not taken from products/services databases, as it is the
case in billing systems (such as SD), and no product/service master record exists. However, even for such
documents the SAF-T file requires master data information to be reported (ProductCode, ProductGroup,
ProductDescription).

The documents affected are invoices posted in FI and invoices from the Real Estate module (RE-FX). The
process for such scenarios is the subject of this chapter. For the settings please refer to chapters Specify
Generic Settings in detail and Country-Specific Settings in detail.

DETERMINATION OF THE PRODUCT DATA


In FI invoices information about the invoiced product/service frequently exists only in the document itself
and not as organized data in a database. Therefore, in order to adequately fill the respective fields in the
SAF-T file the information has to be derived from the data given in the invoice document. This affects the
fields ProductCode, ProductGroup, ProductDescription.

In the following three situations are described which need special treatment.

NOTE: Always be sure to define the product ID in a way to prevent the creation of duplicates to the ones
defined in MARA or for RE invoices.

13.1.1 Real Estate invoices (RE-FX): ProductCode definition


RE-FX invoices can be recognized by their fields Contract Type (TZB0A-RANTYP) and Flow Type (TZB0A-
SBEWART) which are RE specific and always populated. Their value is characteristic for the given business
event of the invoice.

Therefore it seemed natural to take the concatenation of these two fields as the Product Code. This is done
automatically by the system, and if needed, a prefix can be defined to ensure that the number is unique
(see details under chapter Portugal ( Specify Prefix for Material Numbers).

For organizing and storing the product number with the additional data needed please refer to chapter
Storing the product information.

The image below describes the process flow, from the invoice reading to the filling of the SAF-T XML file, in
3 steps.

76 | P a g e
13.1.2 FI invoices: ProductCode definition
For non-Real Estate FI invoices (direct FI postings not fulfilling the criteria for RE invoices) not containing
material reference from MARA, the product/service can be derived from the revenue account that was
posted. For example, if the “Security Services” revenue account was posted, the product derived may be
“Security Services”.

Now, the logic to define the product number must be found. There are two options, one based on the
PTSAFT_MATACCNT table, and the other based on SAFPT_FIMD table:

1. If a product master record in MARA table is used to maintain the product information, use
PTSAFT_MATACCNT table to create the link to the MARA table. For details please refer to chapter Define
Material Numbers Based on G/L Accounts.

2. If the MARA table for product master records is not maintained, use SAFPT_FIMD table to store the
relevant information as needed for the SAF-T file. For details on how to maintain the table, please refer to
chapter Storing the product information.

The image below describes the process flow, from the invoice reading to the filling of the SAFT XML file.

77 | P a g e
78 | P a g e
13.1.3 FI invoices with Material: ProductCode determination
Sometimes FI invoices are posted with reference to the product/service master record (MARA-MATNR). In
this case the material number field is populated in the document and all information can be easily retrieved
from MARA table. No further action is needed.

STORING THE PRODUCT INFORMATION (RE-FX AND FI INVOICES)


Once the definition of the product number (ProductCode) is set, a way must be found to organize and store
the product code associated with the pertaining details. There are two options

1) Use the appropriate Materials Master Record table from MM/SD (MARA table).
2) If the MARA table is not being used at all it may be found more practical to use SAFTPT_FIMD table, as
it requires no further system configuration and is meant for this particular purpose only.

For either option, now you need to create new entries with the product codes obtained as described under
chapters Real Estate invoices (RE-FX): ProductCode definition and FI invoices: ProductCode definition,
associated with the other information needed (ProductGroup, ProductDescription). When running the
report the data is taken from here to fill the fields in the XML file.

Explanation of the fields in the XML file.

Field in XML file Explanation Data source

ProductType Indicator for product MARA or SAFTPT_FIMD


type; for FI invoices it is
generally related to a
service.: Set “P” for
products, “S” for services
and “O” for Others.

ProductCode Unique code to identify MARA or SAFTPT_FIMD


the product

ProductGroup Product group MARA or SAFTPT_FIMD

79 | P a g e
Field in XML file Explanation Data source

ProductDescription Product description MARA or SAFTPT_FIMD

ProductNumberCode EAN Code. If not available Equal ProductCode.


fill field with ProductCode

14BADI
The SAF-T solution includes some BADIs - enhancements that are mainly used to enable the customers to
make their own settings, for purposes that are based on customer specific scenarios. Please check this list
in SAP Note 1987687.

15AUTHORIZATIONS IN SAF-T

INTRODUCTION
Authorization checks in SAF-T are mandatory after SAP Note 2692936 (49_F).

Once this SAP Note is implemented, it is mandatory that the adequate activities are inserted in the
profiles/roles of the Users executing SAF-T. The detailed description of the objects can be found below.

Please update the user roles/profiles according to your internal processes.

AUTHORIZATION OBJECT: F_SAFT_BUK


This object enables you to control the authorizations for the execution of SAF-T activities for a specific
company code. An authorization check of this object is carried out when the user executes any task
involving a company code.

o FIELDS

 BUKRS - Company Code

 ACTVT - Activity

o ACTIVITIES

 03 - Display

 16 - Execute

80 | P a g e
AUTHORIZATION OBJECT: F_SAFT_OPR
This object enables you to control the authorizations for the extraction and deletion of SAF-T data. An
authorization check of this object is carried out when the user executes a Data Extraction or a Deletion.

o BUKRS - Company Code

 ACTVT - Activity

 MODULE - Extraction Options

o ACTIVITIES0

 01 - Extract

 06 - Delete

AUTHORIZATION OBJECT: F_SAFT_XML


This object enables you to control the authorizations for the creation of SAF-T files for a specific company
code and tax accounting basis. An authorization check of this object is carried out when the user executes
any task involving a company code and tax accounting basis.

o FIELDS

 BUKRS - Company Code

 ACTVT - Activity

 ACCBASIS - Tax Accounting Basis

o ACTIVITIES

 01 - Create or generate

81 | P a g e

Оценить