Customizing Activities For Digital Invoice Processing (Mexico)

Customizing Activities for Digital Invoice Processing (Mexico)
Version 1.1
Version History
Version Date Comments

1.0 April 27, 2009 First version
1.1 May 4, 2009 Data source in the system corrected for fields ‘d’ and ‘g’ in
groups 3, 4, and 6 in the Customizing activity Check Data
Sources Required to Form Original Input Message (for both
SD and FI).
Page 1 of 56
Location of Mexico-Specific Customizing Activities in Main Customizing
Structure
Due to technical restrictions concerning the shipment of IMG structures in SAR files, we are not able to
provide the IMG structure as an attachment to an SAP Note.
After you implement the Support Package specified in the SAP Note, the Customizing activities will
appear as per the screenshot below:
The Digital Signature Settings node for will reveal the following Customizing activities:
Page 2 of 56
This document contains all Customizing documentation for the activities in the above IMG structure.
Until you import the latest Support Package, call up the corresponding views manually in transaction
SM30, and the Business Add-Ins (BAdIs) in transaction SE18. Work from the top of the document to
the bottom, because the document contains the documentation in the same order as the IMG structure
above.
Page 3 of 56
Customizing Documentation
Save PSE File (no view – documentation only)

Use
In this Customizing activity, you store the PSE file that the system uses in the digital signature process in the
required location.
You use the command line tool SAPGENPSE to generate a PSE file, which stores the keys securely.
Note: You cannot sign invoices digitally until you have performed all the steps in this Customizing activity and in
the subsequent activities in this section.
Requirements
You have received the public key certificate and private key from the authorities as files that are password
protected.
If the files that you receive from the authorities are not in the required Public Key Cryptography Standards format,
PKCS#12, you must first convert the files into a single file in that format.
You have concatenated your legal private key, private certificate, and the relevant legal root certificate (issuer) to
the productive PSE file. For more information, see SAP Note 1300880.
Activities
1. To convert the PKCS#12 file into a PSE file (which must follow a special naming convention - see
Naming Convention for PSE File Name below), use the SAPGENPSE tool to import the file in PCKS#12
format using the command import_p12 as follows:
sapgenpse import_p12 -p <targetPSEfilename>.pse -x <target password>

-z <source password> <source PCKS#12 file name>.p12
For example: sapgenpse import_p12 -p PSE.pse -x 12345 -z 98765 PKCS12.p12
For more information, see SAP Library for SAP NetWeaver in SAP Help Portal at http://help.sap.com
under SAP NetWeaver Library -> SAP NetWeaver by Key Capability -> Security -> Network and
Transport Layer Security -> Using the SAP Cryptographic Library for SNC -> Configuring SNC for Using
the SAPCRYPTOLIB Using SAPGENPSE -> Additional Functions -> Importing a PKCS#12 File.
2. Save the PSE file in the subdirectory sec, which is located in the instance directory
$DIR_INSTANCE/sec on each server that you want to use to sign digital invoices.
You cannot use automatic distribution functions to copy the PSE file to other servers.
3. To verify the system's ability to access the servers where the system stores the password for the PSE
file, you use the SAPGENPSE tool on each server to create the server's credentials as follows:
sapgenpse seclogin -p <targetPSEfilename>.pse -x <target password>
In line with the example above for converting the PCKS#12 file into a PSE file, you would enter
sapgenpse seclogin -p PSE.pse -x 12345
For more information, see SAP Library for SAP NetWeaver in SAP Help Portal at http://help.sap.com
under SAP NetWeaver Library -> SAP NetWeaver by Key Capability -> Security -> Network and
Transport Layer Security -> Using the SAP Cryptographic Library for SNC -> Configuring SNC for Using
the SAPCRYPTOLIB Using SAPGENPSE -> Creating the Server's Credentials Using SAPGENPSE.
Note: You must repeat steps two and three above for each server that you want to use to generate digital
invoices. You must not copy a PSE file for which you created credentials from one server to another server; you
must create credentials for the PSE file in the required directory on each server that you want to use for the digital
signature process.
For example, if you use three different servers to sign invoices digitally, you must install the PSE file on each of
the three servers. If you use only one of the servers to sign invoices digitally, you must install the PSE file on only
that server. In this case, you must schedule the jobs that digitally sign invoices on that server.
Page 4 of 56
Naming Convention for PSE File Name
The target PSE file name that you enter must use the following naming convention. Each part of the file name is
separated using an underline and the name is case sensitive:
Prefix: always SAPMXDI
PSE name: you can freely choose the PSE name, although the entire file name must not exceed 132
characters
Suffix: a combination of the client and file extension, for example, 100.pse
For example, you create the following PSE file for sales office 1: SAPMXDI_salesoffice01_100.pse
Page 5 of 56
Enter SSF Profile Parameters (view IDMX_DI_VPSEPROF)
Use
In this Customizing activity, you create the SSF profiles that the system needs to process PSE files as part of the
process of digitally signing electronic invoices in your company.
After the system generates the character string for a digital signature, the system uses the SSF profiles in this
Customizing activity to determine the attributes that it must use to digitally sign electronic invoices for a given
organizational unit.
In addition to the organizational validity, the SSF profile, and therefore the PSE file, is also valid for a specific
period of time, for example, 2 years. However, you must specify the time frame in which you can use the PSE file,
that is, the usage period for the PSE file. You specify the validity period of PSE files in the Customizing activity
Specify Validity of SSF Profiles.
The system requires the following attributes for each SSF profile:
Code page
You specify the code page that the issuer and receiver of the digital invoice use, in line with current legal
regulations. The system requires the code page for the character string when it determines the hash
value, which is the basis for creating digital signatures. For example, code page UTF-8.
SSF hash algorithm

You specify the hash algorithm, for example, MD5, that complies with current legal regulations.
During the digital signature process, the system checks the hash algorithm you enter in this Customizing
activity with the value of the SSF parameter SSF_MD_ALG in accordance with your installed security
product (SAP Cryptographic Library). If the values are the same, the system uses the value of the SSF
profile parameter to generate the message digest in the format and length required by the authorities in
Mexico. The system applies the sender's private key to the message digest (see SSF profile below).
For more information about the SSF parameter, see SAP Library for SAP NetWeaver in SAP Help Portal
at http://help.sap.com under SAP NetWeaver Library -> SAP NetWeaver by Key Capability -> Security
-> Digital Signatures and Encryption -> SSF Parameters -> SSF_MD_ALG.
Format of digital signature

You specify the version of the Public Key Cryptography Standards (PCKS) format, for example, PCKS#1
Padding Algorithm V1.5, that complies with current legal regulations. In addition to the hash algorithm,
the system also requires the format of the digital signature that you must use with a particular PSE file.
SSF profile
You enter the name of the PSE file that contains the public key certificate and private key that the
system uses to encrypt the message digest. For example, SAPMXDI_Filenameoffice1_100.pse.
If required, you can differentiate between different parts of your organization by creating multiple sets of attributes
for a PSE file. For example, you can use a PSE file for certain sales offices or other organizational units, or for
your whole organization.
Requirements
You have imported and saved the PSE file as described in the Customizing activity Save PSE File.
Activities
1. Decide at which level in your organization you require a security profile, for example, at company code
or sales office level.
By default, the system uses the same PSE file and attributes for your whole company code.
2. For each sales office, for example, create a unique profile ID for the SSF profile and enter the required
data about the code page, hash algorithm, PSE file format, and the name of the PSE file.
Note: As soon as a PSE file expires, remove it from your system, because once a file expires, the SAP
Cryptographic Library prevents the system from using that file.
Page 6 of 56
Example
In your organization, you have two sales offices for Mexico City.
To increase the level of security that a digital invoice provides, you want to use a different PSE file for each sales
office. In this Customizing activity, you create SSF profiles as follows:
ID for SSF Profile SSF Profile Name

MXOFF1 SAPMXDI_Filenameoffice1_100.pse
MXOFF2 SAPMXDI_Filenameoffice2_100.pse
Page 7 of 56
Specify Validity of SSF Profiles (view IDMX_DI_VPROFDET)
Use
In this Customizing activity, you enter the usage period and valid company code of the PSE files contained in SSF
profiles that the system uses during the digital signature process.
When the system signs a digital invoice, it uses the company code assigned to the invoice to determine which
SSF profile, and therefore which PSE file, to use.
Requirements
You have created an SSF profile for each company code that you want to use for signing digital invoices in the
Customizing activity Enter SSF Profile Parameters.
Activities
1. For each company code that you want to enable for signing digital invoices, enter at least one SSF
profile, regardless of the validity period assigned to the SSF profile.
2. Enter the usage period of the PSE file that is assigned to each of the required SSF profiles.
3. Check the usage period of the PSE file.
The PSE file that contains the public key certificate and private key from the authorities is valid for a
certain period of time. To ensure that the system does not try to process an outdated PSE file during the
digital signature process, make sure that the usage period you specify for that file ends before the official
validity period of the PSE file expires.
We recommend that you overlap the usage periods of PSE files. For example, if you want the system to sign an
electronic invoice shortly before the usage period of one file expires and there is a delay in the signature process,
the selected PSE profile might have expired by the time the system uses it.
Note
If you no longer want to sign digital invoices in a particular company code, you must remove all entries for that
company code from this Customizing activity.
Page 8 of 56
Specify XML Version for Digital Invoice (view IDMX_DI_VBASIC)
Use
In this Customizing activity, you specify general settings that the system needs to process digital invoices.
You enter the XML version of the system that generates the XML file that you send to your business partners for
each company code that needs to generate digital invoices.
When the system prepares a digital invoice, it adds the XML version as a prefix to the string of characters to
which the system applies the private key and certificate. The version must correspond to the XML version of the
system that generates the XML file. If the version of the XML file in that system changes, you must update the
version in this Customizing activity accordingly.
In addition, you specify the date when the XML version expires. The system uses the XML version when it
generates the character string that the system signs digitally.
Requirements
You have checked the XML version that the system which generates the XML file uses.
You have performed the Customizing activity Specify Validity of SSF Profiles.
Activities
Enter the XML version and the date when the XML version expires, as defined by Mexican law, for each company
code that needs to sign digital invoices.
Page 9 of 56
Settings for Documents in Sales and Distribution
Assign Legal Tax Abbreviations to Account Keys (view IDMX_DI_VTAXES)

Use
In this Customizing activity, you assign all of the legally defined tax abbreviations, for example, IVA (Impuesto al
Valor Agregado, value-added tax) that appear on digital invoices to the relevant tax accounts that you use for
generating digital invoices.
The system adds the abbreviations to the tax section of the character string to which the system applies the
private key and electronic certificate during the digital signature process.
Requirements
You have performed the following Customizing activities:
Save PSE File
Enter SSF Profile Parameters
Specify Validity of SSF Profiles
Specify XML Version for Digital Invoice
Activities
Specify the tax abbreviations for each tax account that you want to use for generating digital invoices.
The tax accounts are represented by account keys.
Note
The system lists only those account keys that are relevant for the application area (for example, Sales and
Distribution (SD)) that appears at the top of the screen.
Example
Assume that you record the special tax on goods and services (Impuesto Especial sobre Producción y Servicios,
IEPS) in an account represented by the account key IEP, and value-added tax (Impuesto al Valor Agregado, IVA)
in an account represented by the account key MWS. You enter the following combination of account keys and tax
abbreviations:
Account Key Tax Abbreviation

IEP IEPS
MWS IVA
Page 10 of 56
Determine Text IDs to Store Billing Document Data (view IDMX_DI_VTXTID)
Use
In this Customizing activity, you set up the system so that it can save, and later retrieve the results of the digital
signature process.
Since not every piece of data required for the digital signature process is stored in a field in the system, the
system uses text fields in the billing document, for example at header level, to store the derived results of the
digital signature process.
Note: Since the text fields contain data related to the digital signature and any manipulation of the data would
render the recipient's view of the digital billing document useless, the text fields are not visible in the invoice. The
language of the text fields in which the system stores data is the language of your company code in the system. In
some text fields, to comply with legal regulations in Mexico, the system always enters texts in Spanish, for
example, the document type for payment flow, regardless of the language of the company code.
The derived results of the digital signature process that the system stores in text fields are grouped in categories:
Encrypted character string

The result of applying the signer's private key to the hashed character string. The result represents a
unique fingerprint of the character string, which contains the legally-defined data.
The encrypted character string is stored in Base 64 encoded format.
Document type for payment flow

Shows whether the document is of type income (ingreso), expense (egreso), or transfer (traslado). The
system always enters the text in Spanish, for example, ingreso.
Approval year for official document number
Approval number for official document number
Serial number of certificate

The serial number of the certificate that you receive from the authorities to sign electronic billing
documents digitally.
Payment installment texts

Contains the number of installments in which a payment is divided and the corresponding legally-defined
text in Spanish. The installments data is stored in the Customizing activity Define Terms of Payment.
Document header supplement (complemento)

Supplemental data that some companies must provide at header level in billing documents.
Line item supplement (complemento)

Supplemental data that some companies must provide at line item level in billing documents.
MD5 hashed character string

The result of applying the hash algorithm, MD5, to the original input message.
The hashed character string is stored in hexadecimal encoded format.
Original input message

The complete set of data in the billing document and derived data required by Mexican law for signing
billing documents digitally.
The original input message is stored as a character string.
Addendum (addenda)
Contains additional data that customers can choose to include in their billing documents.
The categories, which are represented by data IDs in this Customizing activity, correspond to specific, predefined
qualifiers in child segments of standard IDoc types. The qualifiers use specific, fixed values so that other systems
Page 11 of 56
can read the required data in the IDoc segments.
To create a digital invoice, subsequent systems generate an XML file. To generate the XML file, the subsequent
systems need to access the derived data from the digital signature process. Since the SAP system stores the
data in specific, defined IDoc segments, even if different senders transmit IDocs, the required data is always
stored in the same IDoc segments.
The fact that the derived data is always stored in the same IDoc segments also enables the system to access the
data required to print digital invoices.
You use this Customizing activity to ensure that the SAP system stores the data that it derives from the digital
signature process in the correct IDoc segments. To do this, you map the text fields that store the derived data to
the qualifiers (represented by data IDs) of the required IDoc segments.
Requirements
You have created text types for sales texts, for example, at header level, in the Customizing activity Define Text
Types:
Selected the Header radio button for the Billing Doc. text object and chosen the Text types pushbutton
Created new text IDs for the text types in which you want to store the derived data from the digital
signature process in the invoice header
Ensure that the namespace you use for each of the text IDs is unique and not already in use.
Since the text fields must not be visible, and therefore not changeable, in the invoice header in the productive
system, do not add the text fields to a text procedure.
Note: If you change the ID of a text type after you have digitally signed an electronic invoice, the system will not
be able to process that digital invoice correctly, because the system will not be able to access the data in the
invoice.
You have performed the Customizing activity Assign Legal Tax Abbreviations to Account Keys.
Activities
For each entry in the dropdown box in the Data ID column, perform the following steps:
1. In the Text Object field, choose the corresponding text field (for example, VBBK for sales header
texts) in which you want the system to store the derived data from the digital signature process.
2. Choose the text ID of the text type in which you want to store each category of derived data from the
Example
You have created text types with the IDs ZECC, ZDTP, ZAPY, ZAPN, ZSNC, ZPMI, ZCDD, ZHCC, ZOIM, and
ZADD as billing document header texts (text object VBBK) and ZCGD as a billing document line item text (text
type VBBP) as described under Prerequisites.
You assign the text IDs of the text types that you created to the data IDs as follows:
Data ID Text Object Text ID

Encrypted Character String VBBK ZECC
Document Type for Payment Flow VBBK ZDTP
Approval Year for Official Document Number VBBK ZAPY
Approval Number for Official Document Number VBBK ZAPN
Serial Number of Certificate VBBK ZSNC
Payment Method Installments VBBK ZPMI
Document Header Supplement VBBK ZCDD
Line Item Supplement VBBP ZCGD
MD5 Hashed Character String VBBK ZHCC
Original Input Message VBBK ZOIM
Addendum VBBK ZADD
Page 12 of 56
Check Data Sources Required to Form Original Input Message (no view –
documentation only)
Use
In this Customizing activity, you check the sources of the data that the system uses to compile the original
input message (OIM).
You use the data listed in the Source of Data in Original Input Message table to check that the data the
system requires for the OIM is stored in the correct place in your system, and where required, that you have
used a Business Add-In (BAdI) implementation to incorporate the required data in the OIM.
The table below shows the combination of a group and field in the OIM, as defined by the Mexican
authorities. To enable the system to form the OIM in the required order, the system must concatenate data
for the individual fields in each group in a specific order. This means that there is not a one-to-one
relationship between the groups defined by law and the groups that the system uses to form the OIM.
Since the system works with numbers and the legal definition works with letters for the fields within a group,
you must use the latest legal definition of the OIM to find the internal number that the system uses for that
field in the legal definition of the OIM. For example, field a in the group for document data corresponds to
field 1 in the system, field b corresponds to field 2, and so on. The system numbers the fields in each group
in consecutive, ascending numerical order. If the government introduces an additional field between a and b
(a1, aa, or ab, for example) the internal number that the system assigns to that field will be 2, because it is
the second field in that particular group. That therefore affects all subsequent numbers in that group.
For example, assume there is a problem with the contents of the data in one of the fields. The system
outputs an error message that refers to group 1, field 3. Based on the contents in the table below, this
combination corresponds to the following data in the legal definition of the OIM: field c (official document
number) in the Document Data group.
Activities
Check the sources of data for each part of the original input message. For example, if your master data or
Customizing settings are incomplete or incorrect, you can use the table below to identify fields or settings
that you need to change.
Group in Field in Group in

Index of
Legal Legal System
Field in Data Source in System
Definition of Definition of to Form
System
OIM OIM OIM
Document The XML Version field in the Customizing activity
a. Version Group 1 Index 1
data Specify XML Version for Digital Invoice.
b. Official
Document The Reference Document Number (XBLNR) field in the
document Group 1 Index 2
data Billing Document: Header (VBRK) table.
prefix
c. Official
number
The Date on Which Record Was Created (ERDAT) and
Document d. Date and
Group 1 Index 4 Entry Time (ERZET) fields in the Billing Document:
data time
Header (VBRK) table.
The Approval Number field in the Customizing activity
Document e. Approval
Group 1 Index 5 Assign Number Range for a combination of company
data number
code, document class, and approval year.
The Approval Year field in the Customizing activity
Document f. Approval
data year
code, document class, and approval number.
Derived based on the document type that you define in
Document g. Document the Customizing activity Define Billing Types. Based
Group 1 Index 7
data type on the billing type, the system inserts the
corresponding text in line with Mexican law: ingreso
Page 13 of 56
(income), egreso (expense), or traslado (transfer).
Based on the setting of the Installment Payment
checkbox in the Customizing activity Define Terms of
Payment. If you do not select the checkbox, or select
the checkbox and enter only one installment, the
Document h. Payment system inserts the Spanish text Pago en una sola
Group 1 Index 8
data method exhibición (only one payment). If there is more than
one installment, the system enters the Spanish text
Pago en <(número de pagos parciales)> parcialidades
(payment made in <(number of partial payments)>
partial payments).
For a combination of the language in the billing
document and the ID of the Terms of Payment
Document i. Payment
Group 1 Index 9 (ZTERM) field, the system reads the payments terms
data terms
from the Customers: Terms of Payment Texts table in
the language of the billing document.
The sum of each item multiplied by the unit price;
without any surcharges, discounts, or taxes. The
Document
j. Subtotal Group 1 Index 10 system reads the subtotal from the Subtotal 1 from
data
pricing (KZWI1) field in the Billing Document: Item Data
(VBRP) table.
The system calculates the total discounts by
subtracting the subtotal (Subtotal 1 from pricing
procedure for condition (KZWI1) field in the Billing
Document
k. Discount Group 1 Index 11 Document: Item Data (VBRP) table from the net total
data
(the Net value of the billing item in document currency
(NETWR) field in the Billing Document: Item Data
(VBRP) table).
The system adds the subtotal less any discounts (see
Document above) to the taxes stored in the Tax amount in
l. Total Group 1 Index 12
data document currency (MWSBK) field in the Billing
Document: Header Data (VBRK) table.
The tax number stored in the Parameter Value
(PAVAL) field in the Additional Specifications for
Company a.
Company Code (T001Z) table for the respective
code global Company's Group 2 Index 1
company code with the value MX_RFC in the
data tax number
Parameter Type (PARTY) field in the Company Code -
Parameter Types (T001I) table.
Company b.
code global Company's Group 2 Index 2 The Name 1 field in the Addresses (ADRC) table.
data name
Company The Street (STREET) field in the Addresses (ADRC)
a. Street Group 3 Index 1
address data table.
Company b. House The House Number (HOUSE_NUM1) field in the
Group 3 Index 2
address data number Addresses (ADRC) table.
c. Second
Company The House Number Supplement (HOUSE_NUM2) field
house Group 3 Index 3
address data in the Addresses (ADRC) table.
number
Company d. Subdistrict The Street 4 (STR_SUPPL3) field in the Addresses
Group 3 Index 4
address data (Colonia) (ADRC) table.
Company
e. City Group 3 Index 5 The City (CITY1) field in the Addresses (ADRC) table.
address data
f. Location
Company
reference (if Group 3 Index 6 Not supported.
address data
any)
The District (CITY2) field in the Addresses (ADRC)
table. If you do not store the district in this field, you use
Company g. District
Group 3 Index 7 the Get District (GET_DISTRICT) method in the
address data (Municipo)
Customizing activity BAdI: Component-Independent
Data Determination.
Page 14 of 56
Company The Description (BEZEI) field in the Customizing
h. State Group 3 Index 8
address data activity Insert Regions.
Company The Country Name (LANDX) field in the Customizing
i. Country Group 3 Index 9
address data activity Define Countries in mySAP Systems.
Company The City Postal Code (POST_CODE1) field in the
j. Postal code Group 3 Index 10
address data Addresses (ADRC) table.
Sales
The Street (STREET) field in the Addresses (ADRC)
organization a. Street Group 4 Index 1
table.
data
Sales
b. House The House Number (HOUSE_NUM1) field in the
organization Group 4 Index 2
number Addresses (ADRC) table.
data
Sales c. Second
The House Number Supplement (HOUSE_NUM2) field
organization house Group 4 Index 3
in the Addresses (ADRC) table.
data number
Sales
d. Subdistrict The Street 4 (STR_SUPPL3) field in the Addresses
(Colonia) (ADRC) table.
data
Sales
organization e. City Group 4 Index 5 The City (CITY1) field in the Addresses (ADRC) table.
data
Sales
f. Location's
organization Group 4 Index 6 Not supported.
reference
data
Sales table. If you do not store the district in this field, you use
g. District
organization Group 4 Index 7 the Get District (GET_DISTRICT) method in the
(Municipo)
data Customizing activity BAdI: Component-Independent
Data Determination.
Sales
The Description (BEZEI) field in the Customizing
organization h. State Group 4 Index 8
activity Insert Regions.
data
Sales
The Country Name (LANDX) field in the Customizing
organization i. Country Group 4 Index 9
activity Define Countries in mySAP Systems.
data
Sales
The City Postal Code (POST_CODE1) field in the
organization j. Postal code Group 4 Index 10
Addresses (ADRC) table.
data
Customer's a.
The Tax Number 1 (STCD1) field in the General Data in
identification Customer's Group 5 Index 1
Customer Master (KNA1) table.
data tax number
Customer's b.
The Name (NAME1) field in the Addresses (ADRC)
table.
data name
Customer's The Street (STREET) field in the Addresses (ADRC)
address data table.
Customer's b. House The House Number (HOUSE_NUM1) field in the
Group 6 Index 2
c. Second
Customer's The House Number Supplement (HOUSE_NUM2) field
number
Customer's d. Subdistrict The Street 4 (STR_SUPPL3) field in the Addresses
Group 6 Index 4
Customer's
address data
Customer's f. Location
Group 6 Index 6 Not supported.
address data reference
Customer's g. District The District (CITY2) field in the Addresses (ADRC)
Group 6 Index 7
address data (Municipo) table. If you do not store the district in this field, you use
Page 15 of 56
the Get District (GET_DISTRICT) method in the
Data Determination.
Customer's The Description (BEZEI) field in the Customizing
Customer's The Country Name (LANDX) field in the Customizing
Customer's The City Postal Code (POST_CODE1) field in the
If there is more than one line item in a billing document, the sequence a, b, c, d, e, and f in group 7 below is
repeated.
Goods or Group Index

The Actual Invoiced Quantity (FKIMG) field in the
a. Quantity
services sold 7 1
Billing Document: Item Data (VBRP) table.
The Sales Unit (VRKME) field in the Billing
b. Unit of measure
services sold 7 2
Document: Item Data (VBRP) table.
The Material Number (MATNR) field in the Billing
c. ID number
services sold 7 3
The Description (ARKTX) field in the Billing
d. Description
services sold 7 4
The system divides the net total in the billing
Goods or Group Index document (the Net value of the billing item in
e. Unit price
services sold 7 5 document currency (NETWR) field in the Billing
The Net value of the billing item in document
f. Amount currency (NETWR) field in the Billing Document:
services sold 7 6
Item Data (VBRP) table.
a. Customs document Group Index
Customs data Not defined
number 7 7
b. Date when customs Group Index
document was issued 7 8
c. Customs office
Group Index
Customs data where customers Not defined
7 9
document was issued
Property account a. Property account Group Index
Not defined
data number 7 10
Supplement of The Get Supplement Data of the Line Item method
Group Index
goods or services a. Supplement data in the Customizing activity BAdI: SD Data
7 11
data Determination.
The Get Withholding Tax Data method in the
Withholding tax a. Withholding tax Group Index
Customizing activity BAdI: SD Data
data type 8 1
Determination.
The Get Withholding Tax Data method in the
Withholding tax b. Withholding tax Group Index
Customizing activity BAdI: SD Data
data amount 8 2
Determination.
Withholding tax c. Withholding tax Group Index The sum of the withholding tax amount per
data type 9 1 withholding tax type.
If there is more than one tax type in the billing document, the sequence a, b, and c in group 10 below is
repeated.
Group Index Based on the account key; for more information, see the
Taxes a. Tax type
10 1 Customizing activity Enter Tax Code Abbreviations.
Group Index The Rate (Condition Amount or Percentage) (KBETR)
Taxes b. Tax rate
10 2 field in the Conditions (Transaction Data) (KONV) table.
Group Index The Condition Value (KWERT) field in the Conditions
Taxes c. Tax amount
10 3 (Transaction Data) (KONV) table.
Page 16 of 56
d. Total tax Group Index The sum of the Condition Value (KWERT) field in the
Taxes
amount 11 1 Conditions (Transaction Data) (KONV) table.
The Get Supplement Data of the Document Header
Supplement of a. Supplement Group Index
method in the Customizing activity BAdI: SD Data
document data data 12 1
Determination.
Page 17 of 56
Check Location of Data in IDoc Segments (no view – documentation only)
Use
In this Customizing activity, you find the fields in the intermediate documents (IDocs) that contain the data you
require to generate an XML file.
To enable the system to send the required data to an external system that generates an XML file of the digitally
signed invoice, during the digital signature process, the system saves the required data in specific IDoc segments.
There are two kinds of segments, qualified and non-qualified.
Non-qualified segments can be used only a single time within an IDoc, whereas qualified segments can be used
more than once. There are two ways in which the system stores data, either directly within the segment or
indirectly within a related child segment. The system accesses the data by means of qualifier values, which are
fixed values of a domain.
Since there is not a one-to-one relationship between all the data in the original input message and particular fields
in IDoc segments, we recommend that you derive the required data, for example, a location's reference or the
second district, in the sender system before you send the IDoc to the target system that generates the XML file.
You derive the required data and store them in enhanced segments of an IDoc of basic type INVOIC02.
Requirements
You have performed all other Customizing activities under Digital Signature Settings in this section.
You have set up your system to be able to send IDocs to external systems in Customizing for SAP NetWeaver
under Application Server -> IDoc Interface / Application Link Enabling (ALE).
For more information, see SAP Library for SAP NetWeaver in SAP Help Portal at http://help.sap.com under SAP
NetWeaver Library -> SAP NetWeaver by Key Capability -> Application Platform by Key Capability -> Platform-
Wide Services -> Connectivity -> Components of SAP Communication Technology -> Classical SAP
Technologies (ABAP) -> IDoc Interface/ALE.
Activities
1. Create an IDoc of basic type INVOIC02.

2. Send the IDoc to the required target system.
3. When the system that you are going to use to generate the XML file has received the IDoc, to
generate the XML file, map the target fields in the XML file with the corresponding fields in the IDoc.
For details about the fields in IDoc segments in which the system stores the data that you use to generate the
XML file, see the Mapping_OIM_Blocks_to_IDoc_SD document attached to SAP Note 1303712.
Page 18 of 56
Settings for Documents in Financial Accounting
Assign FI Document Types for Payment Flow (view IDMX_DI_VDOCTYP)
Use
In this Customizing activity, you determine the type of digital invoice that you send to your business partners by
categorizing each Financial Accounting (FI) document category that you send as a digital invoice. In line with
regulations for digital invoices in Mexico, you assign one of the following special document types to each FI
document category that you use for digital invoices:
Income (ingreso)
Expense (egreso)
Transfer (traslado)
The special document type forms part of the character string to which the system applies the private key and
electronic certificate as part of the digital signature process.
Requirements
You have performed the following Customizing activities:
Save PSE File
Enter SSF Profile Parameters
Specify Validity of SSF Profiles
Specify XML Version for Digital Invoice
Activities
For each of the FI document types that you use for digital invoices, assign the corresponding special document
type.
Example
Assume you want to sign customer invoices (document type DR) digitally. Since customer invoices generate
income, you assign the entry Payment Is Income to the document type DR.
Page 19 of 56
Assign Legal Tax Abbreviations to Account Keys (view IDMX_DI_VTAXESFI)
Use
In this Customizing activity, you assign all of the legally defined tax abbreviations, for example, IVA (Impuesto al
Valor Agregado, value-added tax) that appear on digital invoices to the relevant tax accounts that you use for
generating digital invoices.
The system adds the abbreviations to the tax section of the character string to which the system applies the
private key and electronic certificate during the digital signature process.
Requirements
You have performed the Customizing activity Assign FI Document Types for Payment Flow.
Activities
Specify the tax abbreviations for each tax account that you want to use for generating digital invoices.
The tax accounts are represented by account keys.
Note
The system lists only those account keys that are relevant for the application area (for example, Financial
Accounting (FI)) that appears at the top of the screen.
Example
Assume that you record the special tax on goods and services (Impuesto Especial sobre Producción y Servicios,
IEPS) in an account represented by the account key IEP, and value-added tax (Impuesto al Valor Agregado, IVA)
in an account represented by the account key MWS. You enter the following combination of account keys and tax
abbreviations:
Account Key Tax Abbreviation

IEP IEPS
MWS IVA
Page 20 of 56
Determine Text IDs to Store Invoice Data (view IDMX_DI_VTXTIDFI)
Use
In this Customizing activity, you set up the system so that it can save, and later retrieve the results of the digital
signature process.
Since not every piece of data required for the digital signature process is stored in a field in the system, the
system uses text fields in the billing document, for example at header level, to store the derived results of the
Note: Since the text fields contain data related to the digital signature and any manipulation of the data would
render the recipient's view of the digital invoice useless, the text fields are not visible in the invoice. The language
of the text fields in which the system stores data is the language of your company code in the system. In some
text fields, to comply with legal regulations in Mexico, the system always enters texts in Spanish, for example, the
document type for payment flow, regardless of the language of the company code.
The derived results of the digital signature process that the system stores in text fields are grouped in categories:
Encrypted character string

The result of applying the signer's private key to the hashed character string. The result represents a
unique fingerprint of the character string, which contains the legally-defined data.
The encrypted character string is stored in Base 64 encoded format.
Document type for payment flow

Shows whether the document is of type income (ingreso), expense (egreso), or transfer (traslado). The
system always enters the text in Spanish, for example, ingreso.
Approval year for official document number
Approval number for official document number
Serial number of certificate

The serial number of the certificate that you receive from the authorities to sign electronic invoices
digitally.
Payment installment texts

Contains the number of installments in which a payment is divided and the corresponding legally-defined
text in Spanish. The installments data is stored in the Customizing activity Define Terms of Payment.
Document header supplement (complemento)

Supplemental data at header level that some companies must provide at header level in invoices.
Line item supplement (complemento)

Supplemental data at header level that some companies must provide at line item level in invoices.
MD5 hashed character string

The result of applying the hash algorithm, MD5, to the original input message.
The hashed character string is stored in hexadecimal encoded format.
Original input message

The complete set of data in the invoice and derived data required by Mexican law for signing invoices
digitally.
The original input message is stored as a character string.
Addendum (addenda)
Contains additional data that customers can choose to include in their invoices.
The categories, which are represented by data IDs in this Customizing activity, correspond to specific, predefined
qualifiers in child segments of standard IDoc types. The qualifiers use specific, fixed values so that other systems
can read the required data in the IDoc segments.
To create a digital invoice, subsequent systems generate an XML file. To generate the XML file, the subsequent
Page 21 of 56
systems need to access the derived data from the digital signature process. Since the SAP system stores the
data in specific, defined IDoc segments, even if different senders transmit IDocs, the required data is always
stored in the same IDoc segments.
The fact that the derived data is always stored in the same IDoc segments also enables the system to access the
data required to print digital invoices.
You use this Customizing activity to ensure that the SAP system stores the data that it derives from the digital
signature process in the correct IDoc segments. To do this, you map the text fields that store the derived data to
the qualifiers (represented by data IDs) of the required IDoc segments.
Requirements
You have created new text IDs for the text types in which you want to store the derived data from the digital
signature process.
Ensure that the namespace you use for each of the text IDs is unique and not already in use.
You create the text IDs as follows:
At header level in the Customizing activity Define Text IDs for Documents
At line item level in the Customizing activity Define Text Identifications for Line Items
Since the text fields must not be visible, and therefore not changeable, in the invoice header in the productive
system, do not select the checkboxes that make the texts visible in the above Customizing activities.
Note: If you change the ID of a text type after you have digitally signed an electronic invoice, the system will not
be able to process that digital invoice correctly, because the system will not be able to access the data in the
invoice.
You have performed the Customizing activity Assign Legal Tax Abbreviations to Account Keys.
Activities
For each entry in the dropdown box in the Data ID column, perform the following steps:
1. In the Text Object field, choose the corresponding text field (for example, BELEG for header texts) in
which you want the system to store the derived data from the digital signature process.
2. Choose the text ID of the text type in which you want to store each category of derived data from the
Example
You have created text types with the IDs ZECC, ZDTP, ZAPY, ZAPN, ZSNC, ZPMI, ZCDD, ZHCC, ZOIM, and
ZADD as header texts (text object BELEG) and ZCGD as a line item text (text object DOC_ITEM) as described
under Prerequisites.
You assign the text IDs of the text types that you created to the data IDs as follows:
Data ID Text Object Text ID

Encrypted Character String BELEG ZECC
Document Type for Payment Flow BELEG ZDTP
Approval Year for Official Document Number BELEG ZAPY
Approval Number for Official Document Number BELEG ZAPN
Serial Number of Certificate BELEG ZSNC
Payment Method Installments BELEG ZPMI
Document Header Supplement BELEG ZCDD
Line Item Supplement DOC_ITEM ZCGD
MD5 Hashed Character String BELEG ZHCC
Original Input Message BELEG ZOIM
Addendum BELEG ZADD
Page 22 of 56
Check Data Sources Required to Form Original Input Message (no view
– documentation only)
Use
In this Customizing activity, you check the sources of the data that the system uses to compile the original
input message (OIM).
You use the data listed in the Source of Data in Original Input Message table to check that the data the
system requires for the OIM is stored in the correct place in your system, and where required, that you have
used a Business Add-In (BAdI) implementation to incorporate the required data in the OIM.
The table below shows the combination of a group and field in the OIM, as defined by the Mexican
authorities. To enable the system to form the OIM in the required order, the system must concatenate data
for the individual fields in each group in a specific order. This means that there is not a one-to-one
relationship between the groups defined by law and the groups that the system uses to form the OIM.
Since the system works with numbers and the legal definition works with letters for the fields within a group,
you must use the latest legal definition of the OIM to find the internal number that the system uses for that
field in the legal definition of the OIM. For example, field a in the group for document data corresponds to
field 1 in the system, field b corresponds to field 2, and so on. The system numbers the fields in each group
in consecutive, ascending numerical order. If the government introduces an additional field between a and b
(a1, aa, or ab, for example) the internal number that the system assigns to that field will be 2, because it is
the second field in that particular group. That therefore affects all subsequent numbers in that group.
For example, assume there is a problem with the contents of the data in one of the fields. The system
outputs an error message that refers to group 1, field 3. Based on the contents in the table below, this
combination corresponds to the following data in the legal definition of the OIM: field c (official document
number) in the Document Data group.
Activities
Check the sources of data for each part of the original input message. For example, if your master data or
Customizing settings are incomplete or incorrect, you can use the table below to identify fields or settings
that you need to change.
Group in Field in Group in

Index of
Legal Legal System
Field in Data Source in System
Definition of Definition of to Form
System
OIM OIM OIM
Document The XML Version field in the Customizing activity
a. Version Group 1 Index 1
data Specify XML Version for Digital Invoice.
b. Official
prefix
c. Official
number
The Date on Which Record Was Created (ERDAT) and
Document d. Date and
Group 1 Index 4 Entry Time (ERZET) fields in the Billing Document:
data time
Header (VBRK) table.
The Approval Number field in the Customizing activity
Document e. Approval
data number
code, document class, and approval year.
The Approval Year field in the Customizing activity
Document f. Approval
data year
code, document class, and approval number.
Derived based on the document type that you define in
Document g. Document the Customizing activity Define Billing Types. Based
Group 1 Index 7
data type on the billing type, the system inserts the
corresponding text in line with Mexican law: ingreso
Page 23 of 56
(income), egreso (expense), or traslado (transfer).
Based on the setting of the Installment Payment
checkbox in the Customizing activity Define Terms of
Payment. If you do not select the checkbox, or select
the checkbox and enter only one installment, the
Document h. Payment system inserts the Spanish text Pago en una sola
Group 1 Index 8
data method exhibición (only one payment). If there is more than
one installment, the system enters the Spanish text
Pago en <(número de pagos parciales)> parcialidades
(payment made in <(number of partial payments)>
partial payments).
For a combination of the language in the billing
document and the ID of the Terms of Payment
Document i. Payment
Group 1 Index 9 (ZTERM) field, the system reads the payments terms
data terms
from the Customers: Terms of Payment Texts table in
the language of the billing document.
The sum of each item multiplied by the unit price;
without any surcharges, discounts, or taxes. The
Document
j. Subtotal Group 1 Index 10 system reads the subtotal from the Subtotal 1 from
data
pricing (KZWI1) field in the Billing Document: Item Data
(VBRP) table.
The system calculates the total discounts by
subtracting the subtotal (Subtotal 1 from pricing
procedure for condition (KZWI1) field in the Billing
Document
k. Discount Group 1 Index 11 Document: Item Data (VBRP) table from the net total
data
(the Net value of the billing item in document currency
(NETWR) field in the Billing Document: Item Data
(VBRP) table).
The system adds the subtotal less any discounts (see
Document above) to the taxes stored in the Tax amount in
l. Total Group 1 Index 12
data document currency (MWSBK) field in the Billing
Document: Header Data (VBRK) table.
The tax number stored in the Parameter Value
(PAVAL) field in the Additional Specifications for
Company a.
Company Code (T001Z) table for the respective
code global Company's Group 2 Index 1
company code with the value MX_RFC in the
data tax number
Parameter Type (PARTY) field in the Company Code -
Parameter Types (T001I) table.
Company b.
code global Company's Group 2 Index 2 The Name 1 field in the Addresses (ADRC) table.
data name
Company The Street (STREET) field in the Addresses (ADRC)
address data table.
Company b. House The House Number (HOUSE_NUM1) field in the
Group 3 Index 2
c. Second
Company The House Number Supplement (HOUSE_NUM2) field
number
Company d. Subdistrict The Street 4 (STR_SUPPL3) field in the Addresses
Group 3 Index 4
Company
address data
f. Location
Company
reference (if Group 3 Index 6 Not supported.
address data
any)
table. If you do not store the district in this field, you use
Company g. District
Group 3 Index 7 the Get District (GET_DISTRICT) method in the
address data (Municipo)
Data Determination.
Page 24 of 56
Company The Description (BEZEI) field in the Customizing
Company The Country Name (LANDX) field in the Customizing
Company The City Postal Code (POST_CODE1) field in the
Sales
The Street (STREET) field in the Addresses (ADRC)
organization a. Street Group 4 Index 1
table.
data
Sales
b. House The House Number (HOUSE_NUM1) field in the
number Addresses (ADRC) table.
data
Sales c. Second
The House Number Supplement (HOUSE_NUM2) field
organization house Group 4 Index 3
in the Addresses (ADRC) table.
data number
Sales
d. Subdistrict The Street 4 (STR_SUPPL3) field in the Addresses
(Colonia) (ADRC)table.
data
Sales
organization e. City Group 4 Index 5 The City (CITY1) field in the Addresses (ADRC) table.
data
Sales
f. Location's
organization Group 4 Index 6 Not supported.
reference
data
Sales table. If you do not store the district in this field, you use
g. District
organization Group 4 Index 7 the Get District (GET_DISTRICT) method in the
(Municipo)
data Customizing activity BAdI: Component-Independent
Data Determination.
Sales
The Description (BEZEI) field in the Customizing
organization h. State Group 4 Index 8
activity Insert Regions.
data
Sales
The Country Name (LANDX) field in the Customizing
organization i. Country Group 4 Index 9
activity Define Countries in mySAP Systems.
data
Sales
The City Postal Code (POST_CODE1) field in the
organization j. Postal code Group 4 Index 10
Addresses (ADRC) table.
data
Customer's a.
The Tax Number 1 (STCD1) field in the General Data in
Customer Master (KNA1) table.
data tax number
Customer's b.
The Name (NAME1) field in the Addresses (ADRC)
table.
data name
Customer's The Street (STREET) field in the Addresses (ADRC)
address data table.
Customer's b. House The House Number (HOUSE_NUM1) field in the
Group 6 Index 2
c. Second
Customer's The House Number Supplement (HOUSE_NUM2) field
number
Customer's d. Subdistrict The Street 4 (STR_SUPPL3) field in the Addresses
Group 6 Index 4
address data (Colonia) (ADRC)table.
Customer's
address data
Customer's f. Location
Group 6 Index 6 Not supported.
address data reference
Customer's g. District The District (CITY2) field in the Addresses (ADRC)
Group 6 Index 7
address data (Municipo) table. If you do not store the district in this field, you use
Page 25 of 56
the Get District (GET_DISTRICT) method in the
Data Determination.
Customer's The Description (BEZEI) field in the Customizing
Customer's The Country Name (LANDX) field in the Customizing
Customer's The City Postal Code (POST_CODE1) field in the
If there is more than one line item in an invoice, the sequence a, b, c, d, e, and f in group 7 below is
repeated.

The Actual Invoiced Quantity (FKIMG) field in the
a. Quantity
services sold 7 1
Billing Document: Item Data (VBRP) table.
The Sales Unit (VRKME) field in the Billing
b. Unit of measure
services sold 7 2
The Material Number (MATNR) field in the Billing
c. ID number
services sold 7 3
The Description (ARKTX) field in the Billing
d. Description
services sold 7 4
The system divides the net total in the billing
Goods or Group Index document (the Net value of the billing item in
e. Unit price
services sold 7 5 document currency (NETWR) field in the Billing
The Net value of the billing item in document
f. Amount currency (NETWR) field in the Billing Document:
services sold 7 6
Item Data (VBRP) table.
a. Customs document Group Index
number 7 7
b. Date when customs Group Index
document was issued 7 8
c. Customs office
Group Index
Customs data where customers Not defined
7 9
document was issued
Property account a. Property account Group Index
Not defined
data number 7 10
Supplement of The Get Supplement Data of the Line Item method
Group Index
goods or services a. Supplement data in the Customizing activity BAdI: FI Data
7 11
data Determination.
Withholding tax a. Withholding tax Group Index The Get Withholding Tax Data method in the
data type 8 1 Customizing activity BAdI: FI Data Determination.
Withholding tax b. Withholding tax Group Index The Get Withholding Tax Data method in the
data amount 8 2 Customizing activity BAdI: FI Data Determination.
Withholding tax c. Withholding tax Group Index The sum of the withholding tax amount per
data type 9 1 withholding tax type.
If there is more than one tax type in the invoice, the sequence a, b, and c in group 10 below is repeated.
Group Index Based on the account key; for more information, see the
Taxes a. Tax type
10 1 Customizing activity Enter Tax Code Abbreviations.
Group Index The Rate (Condition Amount or Percentage) (KBETR)
Taxes b. Tax rate
10 2 field in the Conditions (Transaction Data) (KONV) table.
Group Index The Condition Value (KWERT) field in the Conditions
Taxes c. Tax amount
10 3 (Transaction Data) (KONV) table.
d. Total tax Group Index The sum of the Condition Value (KWERT) field in the
Taxes
amount 11 1 Conditions (Transaction Data) (KONV) table.
Page 26 of 56
The Get Supplement Data of the Document Header
Supplement of a. Supplement Group Index
method in the Customizing activity BAdI: FI Data
document data data 12 1
Determination.
Page 27 of 56
Check Location of Data in IDoc Segments (no view – documentation only)
Use
In this Customizing activity, you find the fields in the intermediate documents (IDocs) that contain the data you
require to generate an XML file.
To enable the system to send the required data to an external system that generates an XML file of the digitally
signed invoice, during the digital signature process, the system saves the required data in specific IDoc segments.
There are two kinds of segments, qualified and non-qualified.
Non-qualified segments can be used only a single time within an IDoc, whereas qualified segments can be used
more than once. There are two ways in which the system stores data, either directly within the segment or
indirectly within a related child segment. The system accesses the data by means of qualifier values, which are
fixed values of a domain.
Since there is not a one-to-one relationship between all the data in the original input message and particular fields
in IDoc segments, we recommend that you derive the required data, for example, a location's reference or the
second district, in the sender system before you send the IDoc to the target system that generates the XML file.
You derive the required data and store them in enhanced segments of an IDoc of basic type FIDCCP02.
Requirements
You have performed all other Customizing activities under Digital Signature Settings in this section.
You have set up your system to be able to send IDocs to external systems in Customizing for SAP NetWeaver
under Application Server -> IDoc Interface / Application Link Enabling (ALE).
For more information, see SAP Library for SAP NetWeaver in SAP Help Portal at http://help.sap.com under SAP
NetWeaver Library -> SAP NetWeaver by Key Capability -> Application Platform by Key Capability -> Platform-
Wide Services -> Connectivity -> Components of SAP Communication Technology -> Classical SAP
Technologies (ABAP) -> IDoc Interface/ALE.
Activities
1. Create an IDoc of basic type FIDCCP02.

2. Send the IDoc to the required target system.
3. When the system that you are going to use to generate the XML file has received the IDoc, to
generate the XML file, map the target fields in the XML file with the corresponding fields in the IDoc.
For details about the fields in IDoc segments in which the system stores the data that you use to generate the
XML file, see the Mapping_ext_IDoc_FI SAP Note 1321680.
Page 28 of 56
Business Add-Ins (BAdIs)
BAdI: Component-Independent Data Determination (IDMX_DI_DATA_DET;

access via transaction SE18)
Use
This Business Add-In (BAdI) is used in the following components:
Sales and Distribution (SD)
Financial Accounting (FI)
This BAdI enables you to add additional data or change existing data when the system creates the original input
message during the digital signature process.
You add or change data that is not always stored in the same place in the system.
If you use a defined standard field to store the data, you do not need to create an implementation for the BAdI,
because the data fulfills one of the following criteria:
The data is mandatory, and so the system finds the required data
The system retrieves the data from a predefined standard field
For more information, see the corresponding documentation under Methods below.
Requirements
You have performed all of the following Customizing activities:
In Customizing for Cross-Application Components under General Application Functions -> Cross-
Application Document Numbering -> Mexico -> Automatic Document Numbering.
In Customizing for Sales and Distribution under Billing -> Billing Documents -> Country-Specific Features
-> Country-Specific Features for Mexico -> Digital Invoice.
Standard settings
There are no implementations in the standard system.
The Business Add-In is not filter-dependent.
Activities
After you call the IMG activity, the system displays a dialog box where you enter a name for the implementation.
If implementations of this Business Add-In have already been created, the system displays them in a dialog box.
You then choose one of them by choosing Create, and continue as follows:
1. In the dialog box, enter a name for the implementation of the Add-In and choose Create.
The system displays the initial screen for creating Business Add-In implementations.
2. On this screen, enter a short description for you implementation in the Implementation Short Text
field.
3. If you choose the Interface tab, you will notice that the system has filled in the Name of the
Implementing Class field automatically, by assigning a class name based on the name of your
implementation.
4. Save your entries and assign the Add-In to a package.
5. To edit a method, double-click its name.
Page 29 of 56
6. Enter your implementation code between the method <Interface Name>~<Name of
Method>. aund endmethod. statements.
7. Save and activate your code. Navigate back to the Change Implementation screen.
Note: You can also create an implementation for an Add-In and not activate it until later. If you want to do
this, do not carry out the following step:
8. Choose Activate.
When the application program is executed, the system carries out the code in the method you wrote.
See also
Methods
Get District (GET_DISTRICT)
Page 30 of 56
Get District
Functionality
This method enables you to incorporate address data in the original input message during the process of signing
electronic invoices digitally as follows:
Incorporate the district for all parties (your company and sales organization, and your customer) in the
original input message
The district is a mandatory field in the original input message. If you do not store the district in the CITY2
field, you must use this method to insert the district in the original input message from the field in which
you store the district.
Insert additional address data in the original input message

If you need to add extra address data about the parties affected by the digital invoice process, you can
use this method to insert the extra data.
Requirements
You have entered the address for all parties involved in the billing process in the system.
Result
The system reads the required address data from the specified location in the system and adds the data to the
original input message.
Parameters
Import Parameter
IS_ADRC (company code)
Changing Parameter
CV_DISTRICT (40 character field)
Page 31 of 56
BAdI: SD Data Determination (IDMX_DI_SDDATA_DET; access via transaction SE18)
Use
This Business Add-In (BAdI) is used in the Sales and Distribution (SD) component.
This BAdI enables you to incorporate SD-specific data contained in billing documents in the original input
message. The data that you incorporate using this BAdI is restricted to data that you do not already incorporate in
your billing documents by means of standard SD BAdI implementations.
For more information, see the documentation under Methods below.
Requirements
You must transport the data required for the following parts of billing documents to the corresponding text fields in
a billing document, which you perform by means of standard SD BAdI implementations:
Line item and header parts of the supplement (complemento)

The supplement contains additional information defined by legislation that some companies are required
to provide in billing documents.
Addendum (addenda)
The addendum contains additional, optional data that some companies want to include in their billing
documents.
You must enter the text fields that contain the above data in the Customizing activity Determine Text IDs to
Store Billing Document Data.
Standard settings
Activities
field.
implementation.
8. Choose Activate.
See also
Methods
Page 32 of 56
Get Withholding Tax Data of the Line Item (GET_LINE_ITEM_WHT)
Get Supplement Data of the Line Item (GET_LINE_ITEM_COMPLEMENTO)
Get Supplement Data of the Document Header (GET_HEADER_COMPLEMENTO)
Get Addendum Data of the Document (GET_ADDENDA)
Get Supplement Data of the Document Header for XML Only (GET_HEADER_COMPLEMENTO_XML)
Get Supplement Data of the Line Item for XML Only (GET_HEADER_COMPLEMENTO_XML)
Get Customs Data of Line Item (GET_LINE_ITEM_CUSTOMS)
Get Property Account Number of Line Item (GET_LINE_ITEM_PROPERTY_ACCOUNT)
Get Document Sender Address (GET_DOCUMENT_SENDER_ADDRESS)
Page 33 of 56
Get Withholding Tax Data of the Line Item
This method enables you to add withholding tax data that your billing documents contain to the original input
message during the digital signature process.
You use this method only if the billing document that you want to sign digitally contains withholding tax. Examples
of cases when a billing document contains withholding tax are as follows:
A person rents a building to a company and invoices that company
A contractor works for a company and sends the company his or her invoice
You use this method to add the total withholding tax amount per withholding tax type to the original input message.
Requirements
The billing document that you want to sign contains withholding tax.
Result
The system adds the following details about withholding tax to the part of the original input message that is
reserved for withholding tax data:
Withholding tax type
Total withholding tax amount per withholding tax type
For each withholding tax type that you use, the method enters the withholding tax type and the withholding tax
amount for that withholding tax type to the original input message.
For example, if you have two withholding tax types and there are three line items for each withholding tax type,
you use this method to export only two lines: the total amount of withholding tax for each withholding tax type:
Withholding Tax Type Withholding Tax Amount

T1 2,000
T1 2,000
T1 1,000
T2 2,000
T2 3,000
T2 3,000
You use the method to export the above withholding tax data as follows:
Withholding Tax Type Withholding Tax Amount

T1 5,000
T2 8,000
Parameters
Import Parameter
IT_KONV (Condition technique used for withholding tax)
Changing Parameter
ET_WITHHOLDING_TAX (Section 11 in the original input message)
Page 34 of 56
Get Supplement Data of the Line Item
Functionality
This method enables you to add data supplements (complemento) about electronic billing documents that some
companies are legally required to include in the original input message.
Some companies are required by law to provide additional data about the goods that they sell, or the services that
they provide. They add this data at line item level in the billing documents that they issue.
You use this method to incorporate the required data, which could relate to any part of the billing document, as
follows:
Data that you enter in the billing document manually
Data that the system enters automatically based on certain contents of a billing document
The format of the supplement depends on the legal requirements that apply to your business.
When you implement this method, you must not include pipeline characters (double (||) or single (|)) at the start
and end of the block for supplement data, because the system enters the start and end double pipeline characters.
The only pipeline character (|) that you must enter is a single pipeline character between the individual fields in
the supplement block. There must not be any spaces between the contents of the individual fields and the single
pipeline characters between the contents of the fields.
For more information, see the example below.
Note: Since the contents of the supplement are not mandatory and depend on legal requirements for different
lines of business, the standard system does not check the contents of the supplement. For this reason, we
recommend that you include a check in the method implementation to determine whether the node concept for
the supplement is built up correctly.
Result
The system enters the supplements for line items in the data extract that the system later reads to enter the data
in the required location in the original input message.
Parameters
Import Parameters
IS_XVBRK (Extended table that contains data at header level in the billing document)
IT_XVBRP (Extended table that contains data about all line items in the billing document)
IT_XVBPA (Extended table that contains data about sales document partners)
IT_XKOMV (Extended table that contains condition data, for example, pricing and taxes)
Changing Parameter
CT_ITEM_COMPLEMENTO
The table that contains the required supplements for a combination of SD document number and line
item in the document. You must not change the SD document number or line item; you must change
only the data in the Supplement Data of Line Item field.
Example
Page 35 of 56
Assume that you run a gas station and a customer buys gasoline with a fuel card; you send the customer a digital
invoice for the transaction.
You use this method to incorporate the following data in the supplement of the line item:
Node Concept
i. ID
ii. Date
iii. Tax number
iv. Gas station code
v. Quantity
vi. Name of gas
vii. Folio number of the transaction
viii. Unit price
ix. Amount
x. Information about the node
Node for Tax
1. Tax
2. Rate
3. Amount
Since the system enters the double pipeline characters (||) at the start and end of the supplement block, ensure
that the node concept contains only a single pipeline character (|), and no spaces, between each field, as in the
following example:
ID|Date|Tax number and so on.
Page 36 of 56
Get Supplement Data of the Document Header
Functionality
This method enables you to add data supplements (complemento) about electronic billing documents to the
legally-required place in the original input message.
they provide. They add this data at header level in the billing documents that they issue.
You use this method to incorporate the required data, which could relate to any part of the billing document, as
follows:
Data that you enter in the billing document manually
Data that the system enters automatically based on certain contents of a billing document
The format of the supplement depends on the legal requirements that apply to your business. If legislation
requires you to build up the supplement data at header level in the form of a node concept, when you implement
this method, you must not include pipeline characters (double (||) or single (|)) at the start and end of the block for
supplement data: the system enters the start and end double pipeline characters.
Result
The system enters the supplements for the billing document in the data extract that the system later reads to
enter the data in the required location in the original input message.
Parameters
Import Parameters
IT_XVBRP (Extended table that contains data about the current line item in the billing document)
IT_XVBPA (Extended table that contains data about all line items in the billing document)
Changing Parameter
CV_HEADER_COMPLEMENTO (Supplement at header level in the billing document)
Example
You use this method to incorporate the following data in the supplement of the document header:
Page 37 of 56
a) Transaction type
b) Account number
c) Subtotal (if it exists)
d) Total
If legislation requires you to structure the above data as a node concept, when you implement this method, you
enter only a single pipeline character (|), and no spaces, between each field in the supplement block, as in the
following examples:
Transaction type|Account number|Subtotal|Total
Total
Page 38 of 56
Get Addendum Data of the Document
Functionality
This method enables you to incorporate additional data (addendum, addenda) about electronic billing documents
that some customers want to include in their billing documents.
You use this method to incorporate the addendum as follows:
In the XML file that your sales partners generate
In billing documents that you print out
Result
The system saves the addendum in a text field that the system then saves in a standard field in a relevant IDoc so
that the receiving system can incorporate the data in the XML file that your business partners generate.
Parameters
Import Parameters
IT_XVBPA (Extended table that contains data about your sales partners)
Changing Parameter
CV_ADDENDA_DATA ( Addendum in the billing document)
Example
Assume that you agree with your business partners to include certain details about the currency of the contents of
the digitally signed billing document that you send to your business partners.
You can use this method to enter the currency and exchange rate in the addendum of the billing document.
Page 39 of 56
Get Supplement Data of the Document Header for XML Only
Functionality
This method enables you to add supplements (complemento) about header data in electronic billing documents
that are required only for the XML file that you generate.
The supplements that you include in the XML file are legally defined and depend on your area of business.
For example, banks must add certain supplements to the bank account statements that they issue. The
supplements that the original input message must contain differ from the supplements that the XML file must
contain.
Result
The system enters the supplements for the document header in the data extract that the system reads to enter
the data in the intermediate document (IDoc) that you send to the system that generates an XML file.
Parameters
Import Parameters
Changing Parameter
CV_HEADER_COMPLEMENTO_XML ( Supplement data in the billing document)
Notes
For more information about the method that you use to add supplements to the original input message, see Get
Supplement Data of the Document Header.
Page 40 of 56
Get Supplement Data of the Line Item for XML Only
Functionality
This method enables you to add supplements (complemento) about line items in electronic billing documents that
are required only for the XML file that you generate.
contain.
Result
The system enters the supplements for line items in the data extract that the system reads to enter the data in the
intermediate document (IDoc) that you send to the system that generates an XML file.
Parameters
Import Parameters
IT_XVBRK (Extended table that contains data about the header in the billing document)
IS_XVBRP (Extended table that contains data at item level in the billing document)
Changing Parameter
CT_ITEM_COMPLEMENTO_XML ( Supplement data in the billing document)
Notes
Supplement Data of the Line Item.
Page 41 of 56
Get Customs Data of Line Item
Functionality
This method enables you to add customs data about line items in billing documents to the original input message.
For example, you can insert the customs document number, the posting date of the customs document number,
and the office that issued the customs document.
Result
The system enters customs data in the part of the original input message that is reserved for customs data.
Parameters
Import Parameters
Changing Parameter
CT_ITEM_CUSTOMS (The table that contains the required customs data for line items in billing
documents)
Page 42 of 56
Get Property Account Number of Line Item
Functionality
This method enables you to add property account data in billing documents to the original input message.
For example, you use this method when the billing document relates to a lease. Assume you issue an invoice to
someone who leases one of your apartments. The apartment has a property account number that you must add
to a particular location in the original input message.
Result
The system adds the property account number to the required location in the original input message.
Parameters
Import Parameters
Changing Parameter
CT_ITEM_PROPERTY_ACCOUNT (Table that stores property account numbers for line items)
Page 43 of 56
Get Document Sender Address
Functionality
This method enables you to change the sender address that appears on a billing document, in line with the
requirements of your company.
By default, the system uses the address of the sales organization as the sender. You can use this method to
enter a different address, based on the body that issues billing documents in your company, for example:
Shipping point
Sales area
Plant
Result
The system enters the required sender address in the original input message.
Parameters
Import Parameters
Changing Parameter
CS_DOC_SENDER_ADRC (The sender address in the original input message)
Page 44 of 56
BAdI: FI Data Determination
Use
This Business Add-In (BAdI) is used in the Financial Accounting (FI) component.
This BAdI enables you to incorporate FI-specific data contained in invoices in the original input message. The
data that you incorporate using this BAdI is restricted to data that you do not already incorporate in your invoices
by means of standard FI BAdI implementations.
For more information, see the documentation under Methods below.
Requirements
You must transport the data required for the following parts of billing documents to the corresponding text fields in
a billing document, which you perform by means of standard SD BAdI implementations:
Line item and header parts of the supplement (complemento)

The supplement contains additional information defined by legislation that some companies are required
to provide in invoices.
Addendum (addenda)
The addendum contains additional, optional data that some companies want to include in invoices.
You must enter the text fields that contain the above data in the Customizing activity Determine Text IDs to
Store Invoice Data.
Standard settings
Activities
field.
implementation.
8. Choose Activate.
See also
Methods
Page 45 of 56
Get Supplement Data of the Line Item (GET_LINE_ITEM_COMPLEMENTO)
Get Supplement Data of the Document Header (GET_HEADER_COMPLEMENTO)
Get Addendum Data of the Document (GET_ADDENDA)
Get Supplement Data of the Document Header for XML Only (GET_HEADER_COMPLEMENTO_XML)
Get Supplement Data of the Line Item for XML Only (GET_LINE_ITEM_COMPLEMENTO_XML)
Get Customs Data of Line Item (GET_LINE_ITEM_CUSTOMS)
Get Property Account Number of Line Item (GET_LINE_ITEM_PROPERTY_ACCOUNT)
Get Document Sender Address (GET_DOCUMENT_SENDER_ADDRESS)
Page 46 of 56
Get Supplement Data of the Line Item
Functionality
This method enables you to add data supplements (complemento) about electronic invoices to the legally
required place in the original input message.
they provide. They add this data at line item level in the invoices that they issue.
You use this method to incorporate the required data, which could relate to any part of the invoice, as follows:
Data that you enter in the invoice manually
Data that the system enters automatically based on certain contents of an invoice
The format of the supplement depends on the legal requirements that apply to your business.
When you implement this method, you must not include pipeline characters (double (||) or single (|)) at the start
and end of the block for supplement data, because the system enters the start and end double pipeline characters.
Result
The system enters the supplements for line items in the data extract that the system later reads to enter the data
Parameters
Import Parameters
IS_BKPF (Table that contains data at header level in the accounting document)
IT_BSEG (Table for accounting document segments)
IT_BSET (Table that contains tax data in accounting document segments)
Changing Parameter
CT_ITEM_COMPLEMENTO
The table that contains the required supplements for a combination of accounting document number
and line item in the document. You must not change the accounting document number or line item; you
must change only the data in the Supplement Data of Line Item field.
Example
You use this method to incorporate the following data in the supplement of the line item:
Page 47 of 56
Node Concept
i. ID
ii. Date
iii. Tax number
iv. Gas station code
v. Quantity
vi. Name of gas
vii. Folio number of the transaction
viii. Unit price
ix. Amount
x. Information about the node
Node for Tax
1. Tax
2. Rate
3. Amount
Since the system enters the double pipeline characters (||) at the start and end of the supplement block, ensure
that the node concept contains only a single pipeline character (|), and no spaces, between each field, as in the
following example:
ID|Date|Tax number and so on.
Page 48 of 56
Get Supplement Data of the Document Header
Functionality
This method enables you to add data supplements (complemento) about electronic invoices to the legally-
required place in the original input message.
they provide. They add this data at header level in the invoices that they issue.
You use this method to incorporate the required data, which could relate to any part of the invoice, as follows:
Data that you enter in the invoice manually
Data that the system enters automatically based on certain contents of an invoice
The format of the supplement depends on the legal requirements that apply to your business. If legislation
requires you to build up the supplement data at header level in the form of a node concept, when you implement
this method, you must not include pipeline characters (double (||) or single (|)) at the start and end of the block for
supplement data: the system enters the start and end double pipeline characters.
Result
The system enters the supplements for the invoice in the data extract that the system later reads to enter the data
Parameters
Import Parameters
IT_BSEG (Table that contains data about accounting document segments)
Changing Parameter
CV_HEADER_COMPLEMENTO (Supplement at header level in the invoice)
Example
You use this method to incorporate the following data in the supplement of the document header:
a) Transaction type
b) Account number
Page 49 of 56
c) Subtotal (if it exists)
d) Total
If legislation requires you to structure the above data as a node concept, when you implement this method, you
enter only a single pipeline character (|), and no spaces, between each field in the supplement block, as in the
following examples:
Transaction type|Account number|Subtotal|Total
Total
Page 50 of 56
Get Addendum Data of the Document
Functionality
This method enables you to incorporate additional data (addendum, addenda) about electronic invoices that some
customers want to include in their electronic invoices.
You use this method to incorporate the addendum as follows:
In the XML file that your sales partners generate
In invoices that you print out
Result
The system saves the addendum in a text field that the system then saves in a standard field in a relevant IDoc so
that the receiving system can incorporate the data in the XML file that your business partners generate.
Parameters
Import Parameters
IS_BKPF (Accounting document header)
IT_BSEG (Table for accounting document segments)
Changing Parameter
CV_ADDENDA_DATA ( Addendum in the invoice)
Example
Assume that you agree with your business partners to include certain details about the currency of the contents of
the digitally signed invoice that you send to your business partners.
You can use this method to enter the currency and exchange rate in the addendum of the invoice.
Page 51 of 56
Get Supplement Data of the Document Header for XML Only
Functionality
This method enables you to add supplements (complemento) about header data in electronic invoices that are
required only for the XML file that you generate.
contain.
Result
The system enters the supplements for the document header in the data extract that the system reads to enter
the data in the intermediate document (IDoc) that you send to the system that generates an XML file.
Parameters
Import Parameters
IT_BSEG (Table that contains accounting document segments)
Changing Parameter
CV_HEADER_COMPLEMENTO_XML ( Supplement data in the invoice)
Notes
Supplement Data of the Document Header.
Page 52 of 56
Get Supplement Data of the Line Item for XML Only
Functionality
This method enables you to add supplements (complemento) about line items in electronic invoices that are
required only for the XML file that you generate.
contain.
Result
The system enters the supplements for line items in the data extract that the system reads to enter the data in the
intermediate document (IDoc) that you send to the system that generates an XML file.
Parameters
Import Parameters
Changing Parameter
CV_ITEM_COMPLEMENTO_XML ( Supplement data in the document)
Notes
Supplement Data of the Line Item.
Page 53 of 56
Get Customs Data of Line Item
Functionality
This method enables you to add customs data about line items in invoices to the original input message.
For example, you can insert the customs document number, the posting date of the customs document number,
and the office that issued the customs document.
Result
The system enters customs data in the part of the original input message that is reserved for customs data.
Parameters
Import Parameters
IS_BKPF (Table that contains data at header level in the accounting document segments)
Changing Parameter
CT_ITEM_CUSTOMS (The table that contains the required customs data for line items in invoices)
Page 54 of 56
Get Property Account Number of Line Item
Functionality
This method enables you to add property account data in invoices to the original input message.
For example, you use this method when the billing document relates to a lease. Assume you issue an invoice to
someone who leases one of your apartments. The apartment has a property account number that you must add
to a particular location in the original input message.
Result
The system adds the property account number to the required location in the original input message.
Parameters
Import Parameters
IT_BSEG (Table that contains data about accounting document segments)
Changing Parameter
CT_ITEM_PROPERTY_ACCOUNT (Table that stores property account numbers for line items)
Page 55 of 56
Get Document Sender Address
Functionality
This method enables you to change the sender address that appears on an invoice, in line with the requirements
of your company.
By default, the system uses the address of the sales organization as the sender. You can use this method to
enter a different address, based on the body that issues billing documents in your company, for example:
Shipping point
Sales area
Plant
Result
The system enters the required sender address in the original input message.
Parameters
Import Parameters
IS_BKPF (Table that contains data at header level in the accounting
IT_BSET (Table that contains tax data in accounting document segments) Changing Parameter
CS_DOC_SENDER_ADRC (The sender address in the original input message)
Page 56 of 56

Customizing Activities For Digital Invoice Processing (Mexico)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Customizing Activities For Digital Invoice Processing (Mexico)

Uploaded by

Copyright:

Available Formats

Customizing Activities for Digital Invoice Processing (Mexico)

Version Date Comments

Save PSE File (no view – documentation only)

sapgenpse import_p12 -p <targetPSEfilename>.pse -x <target password>

For example: sapgenpse import_p12 -p PSE.pse -x 12345 -z 98765 PKCS12.p12

sapgenpse seclogin -p <targetPSEfilename>.pse -x <target password>

Prefix: always SAPMXDI

SSF hash algorithm

Format of digital signature

ID for SSF Profile SSF Profile Name

Assign Legal Tax Abbreviations to Account Keys (view IDMX_DI_VTAXES)

You have performed the following Customizing activities:

Save PSE File

Enter SSF Profile Parameters

Specify Validity of SSF Profiles

Specify XML Version for Digital Invoice

Account Key Tax Abbreviation

Encrypted character string

Document type for payment flow

Approval year for official document number

Approval number for official document number

Serial number of certificate

Payment installment texts

Document header supplement (complemento)

Line item supplement (complemento)

MD5 hashed character string

Original input message

Data ID Text Object Text ID

Group in Field in Group in

Goods or Group Index

1. Create an IDoc of basic type INVOIC02.

Assign FI Document Types for Payment Flow (view IDMX_DI_VDOCTYP)

You have performed the following Customizing activities:

Save PSE File

Enter SSF Profile Parameters

Specify Validity of SSF Profiles

Specify XML Version for Digital Invoice

Account Key Tax Abbreviation

Encrypted character string

Document type for payment flow

Approval year for official document number

Approval number for official document number

Serial number of certificate

Payment installment texts

Document header supplement (complemento)

Line item supplement (complemento)

MD5 hashed character string

Original input message

You create the text IDs as follows:

Data ID Text Object Text ID

Group in Field in Group in

Goods or Group Index

1. Create an IDoc of basic type FIDCCP02.

BAdI: Component-Independent Data Determination (IDMX_DI_DATA_DET;

This Business Add-In (BAdI) is used in the following components:

Sales and Distribution (SD)

Financial Accounting (FI)

The system retrieves the data from a predefined standard field

You have performed all of the following Customizing activities:

There are no implementations in the standard system.

The Business Add-In is not filter-dependent.

Get District (GET_DISTRICT)

Insert additional address data in the original input message