MANUAL DE CONFIGURAÇÃO CT-e INBOUND

Sumário
1- CT-e Inbound.................................................................................................................1
2- Processing Inbound CT-es...........................................................................................1
3- Business Process Determination for CT-es...........................................................2
4- Process Settings and Customizing (Inbound)......................................................3
5- CT-e Basic Process........................................................................................................8
6- CT-e Cancellation Process..........................................................................................9
7- CT-e Flexible Process..................................................................................................10
8- BAdIs for Inbound CT-es............................................................................................14
9- CT-e Fiscal Workplace................................................................................................15
10- CT-e for NF-e Inbound with LES (Logistic Execution System)..................17
11- CT-e for NF-e Outbound with LES (Logistic Execution System)...............24
12- CT-e for NF-e Inbound with TM (Trade Management).................................31
13- CT-e for NF-e Outbound with TM (Trade Management).............................38

1- CT-e Inbound
 
The CT-e Inbound of SAP Nota Fiscal Eletrônica has the following scope:
Manage and automate the receipt of electronic invoices received from suppliers:
 CT-e – receipt/validation of inbound freight invoices
The CT-e Inbound of SAP Nota Fiscal Eletrônica consists of the following topics:

2- Processing Inbound CT-es

 
Business Process Identification
You must identify the correct business process for every individual CT-e before
processing.
Preprocessing Step 1: Receive the CT-e
 The vendor sends a CT-e via XML to the company.
 The system receives the incoming CT-e from the vendor via PI, checks if the
CT-e is relevant for the company, and saves it to the database.
Preprocessing Step 2: Identify the Correct Business Process
 The business process is identified.
For more information, see: Business Process Determination for CT-es.
You can control the process determination with the Business Add-In Determine
Business Process for CT-e in Customizing:   Nota Fiscal Eletrônica  Inbound 
Business Add-Ins for Inbound CT-es  BAdI: Determine Business Process for CT-e  .
For a detailed description of business processes, see:
 CT-e Basic Process
 CT-e Cancellation Process
 CT-e Flexible Process
 CT-e for NF-e Inbound with LES (Logistic Execution System)
 CT-e for NF-e Outbound with LES (Logistic Execution System)
 CT-e for NF-e Inbound with TM (Trade Management)
 CT-e for NF-e Outbound with TM (Trade Management)

3- Business Process
Determination for CT-es
 
You can assign specific business processes to incoming CT-es for further processing.
Determination of the business process is carried out using the CNPJ of the service
taker (Field CNPJ_DERIVED_TOM in table/XNFE/INCTEHD) and the indicator for the
service taker (Field TOMA in table /XNFE/INCTEHD).
Maintain your settings as described in Customizing under   Nota Fiscal Eletrônica 
Inbound  CT-e: Maintain Business Process Determination for Inbound CT-es  .

Procedure
Assign a process type to the combination of CNPJ (number of the service taker) plus
indicator of the service taker. Permitted values for the indicator of the service taker
are:
1. '0' = goods sender
2. '3' = goods receiver
CNPJ (service taker) TOMA (indicator for service taker) Process Type

Blank 3 A

74.544.297/0004-35 0 B

If the service taker with CNPJ 74.544.297/0004-35 acts as goods sender (TOMA = 0),
then process type B is determined for the incoming CT-e. If a service taker with a
differing CNPJ acts as goods receiver (TOMA = 3), then process type A is determined
for the incoming CT-e.
Also see:
 Process Settings and Customizing (Inbound)

4- Process Settings and

Customizing (Inbound)

Procedure
Maintain Logical System for Own Tax Numbers
 Use
When inbound NF-es are processed, process steps can be carried out that require
communication with an ERP system. The corresponding ERP system is
determined using the recipient's CNPJ number from the incoming NF-e. In this
Customizing activity, you define the assignment of the recipient’s CNPJ number
to the corresponding ERP system. To determine the logical system, the system
checks whether it can find an entry for the CNPJ number of the recipient of an
incoming NF-e.
 Requirements
You have maintained a logical system for each ERP system (see the
corresponding Customizing activity).
 Activities
Define the assignment of the recipient’s CNPJ number to the corresponding ERP
system.
 Example
o Recipient's CNPJ
1234567890
o Logical System
ABCCLNT400
 If an NF-e is received for CNPJ number 1234567890, system ABCCLNT400 is
determined.
NF-e: Maintain Business Process Determination for Inbound NF-es
 Use
In this Customizing activity, you assign specific business processes to incoming
NF-es for further processing. The business processes are determined based on
the CFOP codes that are assigned to the NF-e items. If the CFOP code does not
enable identification of a unique business process, the NF-e is not assigned.
 Requirements
Every CFOP code that is to be used must be assigned a business process.
Wildcard entries are not supported. This means if a value such as * or blank is
entered for the CFOP code, the business process is not determined.
 Activities
 Enter the CFOP codes you want to use to determine business processes and
assign the corresponding business processes to them. For more information, see
the documentation in Customizing under   Nota Fiscal Eletronica  Inbound 
Maintain Business Process Determination for Incoming NF-es  .
Maintain Control Parameter for Process Flow
 Use
In this Customizing activity, you perform certain steps to further process an
incoming document (NF-e, CT-e, or Event). These process steps are determined
from the business process to which the NF-e was assigned based on the CFOP
codes of its items (This is only true for NF-es; for CT-es and events, the CFOP
code is not used for business process determination). The process flow for this
business process is contained in table /XNFE/PROCFLOW. You can determine how
the process flow is handled, dependent upon the sender's and/or recipient's CNPJ
number in the incoming document. The Control Settings field lets you control
the processing of a process step. It has the following options:
o Manual = The process step is not processed automatically during the
process. The automatic process stops at this process step. The user performs
this step manually.
o Automatic = The process step is performed automatically during the
process - that is, without user interaction. If processing is successful, the step
status is set to OK and the process is continued.
o You can use the following options in the Inactive field to deactivate a
process step:
o " " = The process step is active and can be executed
automatically or manually, depending on the settings in the Control
Settings field.
o "X" = The process step is deactivated: The process step is not
carried out, but the status of this step is set to OK and the process
continues to the next step.
Requirements
You can maintain a blank entry for CNPJ codes. The system uses the following
search sequence to determine the valid entry:
o Search with both CNPJ numbers to find an entry
o Search with the recipient's CNPJ number to find an entry
o Search with the sender's CNPJ number to find an entry
o Search with two blank CNPJ numbers to find an entry
Make sure that at least the generic entry (blank CNPJ field) is present for each
process step.
Standard settings
Steps that are essential to the process flow cannot be deactivated.
Activities
Define the process type and process step that you want to influence. Enter the CNPJ
numbers in accordance with the criteria listed before, taking the search sequence
into account. Define the suitable control options.
NF-e: Maintain Assignment of Item Category to CFOP Code
 Use
 In this Customizing activity, you can maintain the assignment of item categories
to CFOP codes. This assignment is relevant for determining the correct business
process. The item categories represent the meanings of the CFOP codes. They
have different priorities in the determination of the business processes. If an NF-
e contains both main items and other item categories, then only the main items
are used to determine the business process.
Activities
Maintain the assignment of item categories to CFOP codes. If no entry is created for
a CFOP code, then the item category for that CFOP code is Blank, which means it is
a main item.
Example
In subcontracting cases, the NF-e can contain a final product (= main item) and the
subcontracting components (= symbolic return). To determine the correct business
process, the entries must be maintained for the final product and the
subcontracting components, to enable assignment of the corresponding item
categories:
CFOP Item Category

5124 Main Item

5902 Symbolic return of subcontracting component

Define Control Parameters for Process Steps

 Use
In this Customizing activity, you can define various activities for a specific
process step. These process steps are determined from the business process to
which the NF-e was assigned based on the CFOP codes of its items. The process
flow for this business process is contained in table /XNFE/PROCFLOW.
Your own tax number (CNPJ) is also used to distinguish the entry at a higher
level. You can use these activities to influence the outcome of the selected
process flow.
The Activity field describes the available activity that is assigned to the feasible
process steps in the table/XNFE/PROCACT. The Value field can have various
values and meanings, depending on which activity is chosen.
Requirements
If no activity is defined in table /XNFE/PROCCTRL for your own tax number or for a
process step, the system automatically uses the standard value for the
respective process step.
Likewise, the system also uses the standard settings when the Value field is
blank for a given activity.
Activities
Define the process type and process step that you want to influence. Reduce your
selection by the tax number (CNPJ).
Example
In this way, for example, three variants for entering goods receipt quantities are
available:
 Include Default Values (the fields for the received quantity and unit are filled
with the quantities and units from the NF-e)
 Exclude Default Values (the fields for the received quantity and unit are not
filled)
 Exclude Default Values, quantities from the NF-e are not displayed
CT-e: Maintain Business Process Determination for Inbound CT-es
 Use
In this Customizing activity, you assign specific business processes to incoming
CT-es for further processing. Determination of the business process is carried out
using the CNPJ of the service taker (FieldCNPJ_DERIVED_TOM in
table /XNFE/INCTEHD) and the indicator for the service taker (Field TOMA in
table/XNFE/INCTEHD).
Activities
Assign a process type to the combination of CNPJ (number of the service taker) plus
indicator of the service taker. Permitted values for the indicator of the service taker
are:
 '0' = goods sender
 '3' = goods receiver
You can also use a blank entry for the CNPJ number. During business process
determination, a matching entry for the relevant CNPJ number is searched first. If no
matching entry is found, then the blank entry is used.
Example
CNPJ (service taker) TOMA (indicator for service taker) Process Type

Blank 3 A

74.544.297/0004-35 0 B

If the service taker with CNPJ 74.544.297/0004-35 acts as goods sender (TOMA = 0),
then process type B is determined for the incoming CT-e. If a service taker with a
differing CNPJ acts as goods receiver (TOMA = 3), then process type A is determined
for the incoming CT-e.
Control Parameters for Process-Independent Actions
 Use
In this Customizing activity, you can define parameters for process-independent
actions. You can define the parameters depending on your own tax number
(CNPJ). The available action can be selected with the corresponding parameter.
Various values are available for the parameter.
Requirements
If no value is defined for an own tax number and an action, the system
automatically uses a default value. Likewise, the system also uses the standard
settings when the Value field is blank for a given activity.
Activities
Define the action you want to influence. You can limit your selection by the tax
number (CNPJ). You can define a blank entry for the CNPJ codes. The system always
searches an entry with the CNPJ number first. If none is found, the system searches
an entry with a blank CNPJ number.
Example
If an NF-e or CT-e is received more than once, you can choose the following values:
 Exception; Visible as an application error in PI
 This is the default setting. The corresponding XML message is displayed in the PI
message monitor with an application error.
 Ignore; Entry in history table.
The corresponding XML message is displayed in the PI message monitor
as successfully processed. Only an entry in the document history indicates that
the document was received several times.
If an NF-e is received with a receiver-CNPJ that is not maintained in Customizing as
an own CNPJ, you can choose the following values:
 Book in NF-e without assigning a business process
 Exception; Visible as an application error in PI
NF-e: Define Reasons for Rejection; Assign to Events
 Use
In this Customizing activity, you specify the reasons for rejecting processing for
incoming NF-es. Only the texts defined in this activity can be selected as reasons
for rejection. If vendor notification is active (in the rejection case), the selected
rejection text can be sent to the business partner as part of an e-mail.
Activities
Enter the abbreviation for a rejection and enter a descriptive text.
Example
Rejection Rejection Text

AUTHORIZ The NF-e is not authorized

SIGNATUR The signature is not valid

CT-e: Define Reasons for Rejection

 Use
In this Customizing activity, you specify the reasons for rejecting the processing
of inbound CT-es. Only the texts defined in this activity can be selected as
reasons for rejection. The selected rejection text can be sent to the business
partner as part of an e-mail.
Activities
Enter the abbreviation for a rejection and enter a descriptive text.
Example
Rejection Rejection Text

AUTHORIZ The NF-e is not authorized

SIGNATUR The signature is not valid

Maintain Mail Sender Parameters for Own Tax Numbers

 Use
In this Customizing activity, you assign an e-mail address to incoming NF-es for
your own tax number (CNPJ). This e-mail address is used as the sender address
for e-mail communication. If you do not define this entry, the system tries to use
the e-mail address of the currently active user. You can enter the e-mail text with
the rejection in the Rejection Text Name field. You can enter the e-mail text with
the acceptance in the Acceptance Text Name field. You can maintain these texts
using transaction code SO10; the text ID must be NFE. You can use the following
fields from structure /XNFE/NFE_COM_TEXT to create the texts:
o NFEID - Access key
 o TYPE - NF-e type
o FINNFE - Issue function
o CNPJ_EMIT - CNPJ number of the NF-e issuer
o C_XNOME - Company name of the NF-e issuer
o CNPJ_DEST - CNPJ/CPF number of the NF-e recipient
o E_XNOME - Company name of the NF-e recipient
o SERIE - Series
o NNF - NF-e number
o NOTIFICATION - Rejection text
Activities
Enter a valid e-mail address as sender address for your tax number. Optional: Use
transaction code SO10 to enter a user-defined rejection text for your tax number.
Example
Your tax number Sender mail address Rejection text name Acceptance text name

74544297000435 John.Q.Public@SAP.COM NFE_REJECTION_TEXT NFE_ACCEPTANCE_TEXT

Maintain Communication Parameters for Partner Tax Numbers

 Use
In this Customizing activity, you define the communication parameters for a
business partner. The business partner tax number must be entered. Optional:
You can also enter your own tax number and link it with the business partner tax
number. The recipient e-mail address determines where notifications are sent
during e-mail communication. If no recipient e-mail address is entered for a
business partner tax number, then e-mail notification is not possible for that
business partner.
Required-entry fields:
o Business partner tax number
o Recipient e-mail address (rejection or acceptance, depending on the
scenario used)
o Your own tax number (optional)
Activities
Enter a recipient e-mail address for a business partner tax number (CNPJ) for
communication purposes.
Example
Business partner tax number Own tax number Recipient e-mail address for rejection/acceptance

74544297000192 34274233026675 John.Q.Public@sap.com

5- CT-e Basic Process

 
The CT-e basic process covers the minimum requirements for processing incoming
CT-es (technical nameCTEBASIC):
Process
CT-e Basic Process (CTEBASIC)
This process consists of the following steps:
1. CTESIGNA (Auto)
Check Business Partner's Signature
2. CTEAUTHO (Auto)
Check Authorization After CT-e Receipt
CTE Basic Process contains the following technical steps:
Steps 1–2: Check Business Partner's Signature; Check Authorization after
CT-e Receipt

Step 1: Check Business Partner's Signature

(Technical name: CTESIGNA)
The system checks if the signature is OK.
 Signature OK: The CT-e has passed the signature check and can proceed to
the next processing step. For more information, see the documentation in
Customizing under   Nota Fiscal Eletrônica  Signature  .
 Signature Not OK: The process stops. The user can manually reject the CT-e
and notify the vendor.
Step 2: Check Authorization After CT-e Receipt
(Technical name: CTEAUTHO)
The system checks the CT-e's authorization status received from the SEFAZ tax
authority's Web service. This communication is carried out using an asynchronous
call.
 XML Authorized: The authorization check was successful and the CT-e can
proceed to the next processing step.
 XML Not Authorized: The user can manually reject the CT-e.
 6- CT-e Cancellation Process
 
You use the CT-e cancellation process to cancel a CT-e (technical name: CTECANCL).
The cancellation process consists of the following steps:
 Check Business Partner's Signature
The process type is Check Business Partner's Signature (technical name:
CTESIGNA), the corresponding cancel process type is Cancellation of CT-e,
general process (technical name: CTECANCL).
 Check Authorization After Cancellation CT-e
The process type is Check Authorization After Cancellation CT-e (technical name:
CTEAUTHC), the corresponding cancel process type is Cancellation of CT-
e (technical name: CTECANCL).

Process
If a canceled CT-e arrives, the system carries out the following steps. If the
automatic process fails, then the user can manually carry out individual follow-on
actions in the workplace.
 Assign Business Process Cancellation of CT-e (technical name: CTECANCL
 Step: Check Business Partner's Signature (technical name: CTESIGNA)
Check if this step was carried out correctly:
 o If yes, proceed to the next check.
o If No, then the step is not OK and either the user or the system can
decide what happens with this CT-e:
o Cancellation rejected: Go back to original process and
continue there.
o Cancellation accepted: The CT-e is canceled and the
processing finished.
 Step: Check Authorization after Cancellation CT-e (technical
name: CTEAUTHC)
Check if this step was carried out correctly:
o If yes, proceed to the next check.
o If No, then the step is not OK and either the user or the system can
decide what happens with this CT-e:
o Cancellation rejected: Go back to original process and
continue there.
o Cancellation accepted: The CT-e is canceled and the
processing finished.
 CT-e complete
If all these steps have been checked, then the processing of the CT-e is finished.

7- CT-e Flexible Process

 
In addition to the processes included in the standard shipment of SAP Nota Fiscal
Eletrônica (SAP NFE), SAP NFE also offers a flexible process that can trigger
customer-specific actions in the ERP system. Two new steps have been added to
the CT-e Flexible Process (technical name CTEFLXBL) to allow you to call your own
actions, events, or processes in the ERP system:
 BAdI Call Before DACTE Receipt (CTEBBEFD): You carry out this BAdI-based
step before the arrival of goods and the corresponding DACTE.
 BAdI Call After DACTE Receipt (CTEBAFTD): You carry out this BAdI-based
step after the arrival of goods and the corresponding DACTE.

Process
CT-e Flexible Process (CTEFLXBL)
This process consists of the following steps:
1. CTESIGNA (Auto)
Check Business Partner's Signature
2. CTEAUTHO (Auto)
Check Authorization After CT-e Receipt
3. CTEBBEFD (Auto)
BAdI Call Before DACTE Receipt
4. RECDACTE
Enter DACTE
5. CTEAUTHG (Auto)
Check Authorization After DACTE Receipt
6. CTEBAFTD (Auto)
BAdI Call After DACTE Receipt
7. DARNOTIF (Auto)
Notification about Received DACTE
CTE Flexible Process contains the following technical steps:
Steps 1–2: Check Business Partner's Signature; Check Authorization after
CT-e Receipt

Step 1: Check Business Partner's Signature

(Technical name: CTESIGNA)
The system checks if the signature is OK.
 Signature OK: The CT-e has passed the signature check and can proceed to
the next processing step. For more information, see the documentation in
Customizing under   Nota Fiscal Eletrônica  Signature  .
 Signature Not OK: The user can manually reject the CT-e and notify the
vendor.
Step 2: Check Authorization after CT-e Receipt
(Technical name: CTEAUTHO)
The system checks the CT-e's authorization status received from the SEFAZ tax
authority's Web service. This communication is carried out using an asynchronous
call.
 XML Authorized: The authorization check was successful and the CT-e can
proceed to the next processing step.
 XML Not Authorized: The user can manually reject the CT-e and notify the
vendor.
Step 3: BAdI Call before DACTE Receipt;

Step 3: BAdI Call Before DACTE Receipt

(Technical name: CTEBBEFD)
You can implement this BAdI-based step according to your requirements. For more
information, see the documentation in Customizing under   Nota Fiscal Eletrônica 
Incoming  Business Add-Ins for Incoming CT-es  BAdI: Step Implementation
before/after DACTE  .
Steps 4–6: Enter DACTE; Check Authorization After DACTE Receipt; BAdI
Call After DACTE Receipt
The vendor sends goods together with a DACTE to your company, and the goods
and DACTE arrive.
Step 4: Goods Arrived, Enter DACTE
(Technical name: RECDACTE)
The NF-e fiscal clerk notifies the vendor that the XML has been accepted, and then
sets this process step to OKor Not OK. If the status is OK, the system automatically
continues with the next step.
Step 5: Check Authorization After DACTE Receipt
(Technical name: CTEAUTHG)
The system automatically checks the authorization status of the XML via the SEFAZ
tax authority's Web service.
Step 6: BAdI Call After DACTE Receipt
(Technical name: CTEBAFTD)
You can implement this BAdI-based step according to your requirements. For more
information, see the documentation in Customizing under   Nota Fiscal Eletrônica 
Incoming  Business Add-Ins for Incoming CT-es  BAdI: Step Implementation
before/after DACTE  .
Step 7: Notification about Received DACTE;
(Technical name: DARNOTIF)
Actions in Step 7:
The sender is notified that the DACTE has been received.

8- BAdIs for Inbound CT-es

 
The following BAdIs (Incoming) are available for SAP Nota Fiscal Eletrônica (NFE):
 BAdI: Step Implementation before/after DACTE
You can implement a BAdI that is used within the business process Customer-
Specific Business Process with DACTE (technical name: CTEFLXBL) to trigger
transactions in the integrated ERP system.
 BAdI: Determine Business Process for CT-e
You can implement a BAdI that carries out a customer-specific business process
determination.
 BAdI: Determination of Logical System
You can implement a BAdI that determines the logical system for the ERP
system.
 BAdI: Provide LES Documents in ERP
You can implement a BAdI that is used in the business process CT-e for Inbound
NF-e with LES (technical name CTEINBLE). LES is the abbreviation for Logistic
Execution System.
  Note
For more information, see the documentation for the BAdIs in Customizing under   
Nota Fiscal Eletrônica  Inbound  Business Add-Ins for Inbound CT-es  .

9- CT-e Fiscal Workplace

 
A transport service provider can issue a freight document called conhecimento de
transporte eletrônica (CT-e). The CT-e Fiscal Workplace is where the fiscal clerk
processes incoming CT-es.

Queries
 Today
The Today query lists all CT-es received today with their main header data and
the status information.
 Overview
The Overview query lists all CT-es with their main header data and the status
information.

List
Based on your selection criteria, the CT-e Fiscal Workplace displays a list of CT-es
and their processing status.
The following status icons are used:
 Process Completed; CT-e Processed Successfully. This icon represents the
following statuses:
o 99 -> Process Completed; Document Successfully Processed
o 98 -> Document Manually Closed
 Process completed; CT-e rejected. This icon represents status 89.
The CT-e processing finished with a rejection by the user with no option to
continue processing.
 Process Waiting for Asynchronous Reply. This icon represents status 11.
 Technical Error in preceding Process Step. This icon represents the
following statuses:
o 02 -> Error in last process step
o 03 -> Technical error in last process step
To correct the error, go to the status overview and check the problem description
in the last activity. After correcting the problem, you can continue the process
either by using the corresponding step-specific user interface or with the
action Continue Process.
 Process waiting for user action. This icon represents status 01.
The process stopped for the user to carry out necessary actions on the
corresponding step-specific user interface.
Additional Information
Once you have selected a CT-e in the displayed table, tabs containing additional
information about this CT-e appear at the bottom of the screen:
 Status Overview
This is a description of the process with the
corresponding Status, Activity, Process, Status Description, Info
Text and Application Log fields.
 History
This is a description of the history of this CT-e containing
the Status, Process, Activity, Status Description, Info Text, Executed on, and
the User fields.
 References
The References tab is only displayed for CT-es where the XML contains electronic
or paper-based NF/CT references.
o An icon indicates whether the NF-e/CT-e is stored in the NFE system.
o The access key is a direct link to the XML of the NF-e/CT-e. To open
this link, you need the authorization to display the NF-e/CT-e.
 Events
This is an overview of all events related to this CT-e. For more detailed
information, see Events Embedded in Monitors.

 Caution
The Events tab is only visible if there is at least 1 event for a CT-e.

Actions
 Process Steps
Choose Execute Process Step to manually execute a process step.
The available process steps depend on the used CT-e process. For the CT-e
flexible process, you can manually execute the following steps:
 Select Details:
o Display Details
This action displays the entire XML content in multiple sub-screens. You can
also access the CT-e details by clicking on the access key in the list.
o Display XML
This action allows you to download/display the CT-e XML file (if existing).
o Cancellation XML
This action allows you to download/display the cancellation event XML file (if
existing).
o Enter DACTE
Choose Enter DACTE to record a DACTE manually or with a bar code reader.
 Additional Functions
Use the Additional Functions dropdown to call the following additional functions:
o Continue Process
For attempting to restart the automatic processing of a CT-e. If CT-e
processing stops, investigate the reason, then choose Continue Process to try
to continue processing.
o Set Process Step to OK Manually
 For setting the current process step to OK, despite the fact that the process
step was not carried out successfully.
o End CT-e Manually
For ending the CT-e processing in the NFE system without carrying out any
further steps.
o Reject CT-e
To reject the CT-e and to stop further processing in the NFE system.
o Send Notification
To send a notification to your business partner.

CT-e Details
You can display the details by choosing a CT-e's Access Key, or by selecting the
corresponding line and choosing Display Details. The details view displays the entire
content of the XML in several tabs and grouped according to the tags in the XML.

Navigation
You can access the CT-e Fiscal Workplace in SAP NFE via one of the following
options:
 You can call up the specific menu Fiscal Workplace from the user
role /XNFE/WP_NFE_IN_FISCAL(Menu: NF-e Inbound Fiscal Workplace).
 You can access this option from the user role by choosing   Fiscal
Workplace: Inbound Messages  CT-e  .

10- CT-e for NF-e Inbound with

LES (Logistic Execution
System)
 
The following scenario is used as an example to illustrate this process: The goods
receiver pays for the transport together with the delivery, the inbound CT-es and
NF-es are posted in the system.
  Example
1. The truck arrives and the driver hands over all the documents.
2. The DACTE and DANFEs are scanned. The inbound CT-e is processed in the
goods receiver system according to the process CT-e for NF-e Inbound with
LES (CTEINBLE).
3. Finally the invoice receipt for the CT-e is posted.

Process
CT-e for NF-e Inbound with LES (CTEINBLE)
This process consists of the following steps:
1. CTESIGNA
Validate Signature of Business Partner
2. CTEAUTHO
Check Authorization After CT-e Receipt
3. CTEILVAL
Validation
4. CTEILFCD
Provide LES Documents Through BAdI
5. CTEILIVS
Invoice Simulation
6. RECDACTE
Enter DACTE
7. CTEAUTHG
 Check Authorization
8. CTEILIVP
Invoice Posting
CT-e for NF-e Inbound with LES (CTEINBLE) contains the following steps:
Steps 1–2: Check Business Partner's Signature; Check Authorization after
CT-e Receipt

Actions in step 1–2

Step 1: Check Business Partner's Signature
(Technical name: CTESIGNA)
The system checks if the signature is OK.
 Signature OK: The CT-e has passed the signature check and can proceed to
the next processing step. For more information, see the documentation in
Customizing under   Nota Fiscal Eletrônica  Signature  .
 Signature Not OK: The process stops. The user can manually reject the CT-e
and notify the vendor.
Step 2: Check Authorization After CT-e Receipt
(Technical name: CTEAUTHG)
The system checks the CT-e's authorization status received from the SEFAZ tax
authority's Web service. This communication is carried out using an asynchronous
call.
 XML Authorized: The authorization check was successful and the CT-e can
proceed to the next processing step.
 XML Not Authorized: The user can manually reject the CT-e.
Step 3: Validation for CT-e for NF-e Inbound with LES (Technical
name: CTEILVAL)

Actions in Step 3: Validation for CT-e for NF-e Inbound with LES (technical
name: CTEILVAL)
The validation step carries out the following checks:
 Check if paper NF-es are involved
If yes, this is an error due to the fact that only electronic NF-es are accepted.
Paper-NF-es as reference cannot be processed.
 Check if all referenced NF-es exist in the system and if they are authorized
 Check if the service taker is the goods receiver.
Step 4: Provide LES Documents Through BAdI (Technical name: CTEILFCD)
Actions in Step 4: Provide LES Documents Through BAdI
This step calls a BAdI that calls the connected ERP system. This BAdI is used to find,
create, or update LES (Logistic Execution system) documents. This ensures that the
following process steps Simulation and Postingcan be carried out successfully.
The necessary LES documents must be fully available for a successful execution of
the process. Once theCTEILFCD step is successfully executed, the system requires
the availability of the service entry sheet.
For more information, see the documentation in Customizing for this BAdI under   
Nota Fiscal Eletrônica  Inbound  Business Add-Ins for Inbound CT-es  BAdI: Provide
LES Documents in ERP 
Step 5: Simulate Invoice (Technical name: CTEILIVS)
Actions in Step 5: Simulate Invoice (technical name: CTEILVS)
 The fiscal clerk can trigger a simulation using XML data, tax code, and CFOP.
This simulation serves as check on the ERP side to verify if an invoice receipt can
be posted. The fiscal clerk can visualize the simulation and comparison results
with the data of the inbound CT-e. The fiscal clerk can change tax code and CFOP
code.
o If the simulation was correct, then the CT-e can proceed to the next
processing phase.
o If the simulation is not correct, then the CT-e receives the result
Simulation Not OK. In this case, the fiscal clerk can either:
1. Reject the CT-e and notify the vendor. (Vendor notification is not triggered
automatically upon rejection; the fiscal clerk must notify the vendor
manually.)
2. Manually adjust tax code and CFOP code and rerun the simulation.

  Note
 All parameters must be saved before the status can be changed.
Step 6: Goods arrived, enter DACTE
The vendor sends goods together with a DACTE to your company, and the goods
and DACTE arrive.
Actions in step 6: Goods Arrived, Enter DACTE (Technical name: RECDACTE)
The fiscal clerk notifies the vendor that the XML has been accepted, and then sets
this process step to OK orNot OK. If the status is OK, the system automatically
continues with the next step.
Steps 7: Check Authorization
The system automatically checks the authorization status of the XML via the SEFAZ
tax authority's Web service.
Actions in step 7: Check Authorization (Technical name: CTEAUTHG)
The system automatically checks the authorization status of the XML via the SEFAZ
tax authority's Web service.
Step 8: Invoice Posting (Technical name CTEILIVP)
After the successful authorization check, the invoice is posted.
Actions in step 8: Post Invoice (Technical name: CTEILIVP)
 The invoice receipt is posted to the ERP system.
 The NFE system receives the result of the invoice receipt from the ERP
system:
1. Invoice receipt successful: In this case, the status of the step is set
to OK. The NFE process is completed.
2. Invoice receipt failed and no invoice is created: In this case, the step
is set to Not OK and you must carry out manual corrections in the ERP system.

11- CT-e for NF-e Outbound with

LES (Logistic Execution
System)
 
The following scenario is used as an example to illustrate this process: The goods
sender pays for the transport, the goods are issued and outbound NF-es are
created. The CT-e was created and the DACTE was printed by the transporter.
  Example
1. The transporter arrives at the goods sender with the DACTE.
2. The inbound CT-e is processed in the goods sender system according to the
process CT-e for NF-e Outbound with LES (CTEOUTLE).
3. The goods are issued according to the outbound NF-es referenced in the CT-
e
4. The goods are loaded to the truck and the truck leaves the company with the
DACTE and the DANFE.
The truck driver and the receiver of the transport need the DACTE as accompanying
document for the transport, but not as invoice document for the freight costs,
because the goods sender is the service taker.

Process
CT-e for NF-e Outbound with LES (CTEOUTLE)
This process consists of the following steps:
1. CTESIGNA
Validate Signature of Business Partner
2. CTEAUTHO
Check Authorization After CT-e Receipt
3. CTEOLVAL
Validation
4. CTEOLIVS
Invoice Simulation
5. CTEOLTRC
 Transport Confirmation
6. CTEAUTHG
Check Authorization
7. CTEOLIVP
Invoice Posting
CT-e for NF-e Outbound with LES (CTEOUTLE) contains the following steps:
Steps 1–2: Check Business Partner's Signature; Check Authorization after
CT-e Receipt

Actions in step 1–2

Step 1: Check Business Partner's Signature (Technical name: CTESIGNA)
The system checks if the signature is OK.
 Signature OK: The CT-e has passed the signature check and can proceed to
the next processing step. For more information, see the documentation in
Customizing under   Nota Fiscal Eletrônica  Signature  .
 Signature Not OK: The process stops. The user can manually reject the CT-e
and notify the vendor.
Step 2: Check Authorization After CT-e Receipt (Technical name: CTEAUTHO)
The system checks the CT-e's authorization status received from the SEFAZ tax
authority's Web service. This communication is carried out using an asynchronous
call.
 XML Authorized: The authorization check was successful and the CT-e can
proceed to the next processing step.
 XML Not Authorized: The user can manually reject the CT-e.
Step 3: Validation for CT-e for NF-e Inbound with LES (Technical
name: CTEOLVAL)

Actions in Step 3: Validation for CT-e for NF-e Outbound with LES (technical
name: CTEOLVAL)
The validation step carries out the following checks:
 Check if paper NF-es are involved
If yes, this is an error due to the fact that only electronic NF-es are accepted.
Paper-NF-es as reference cannot be processed.
 Check if all referenced NF-es exist in the system and if they are authorized
 Check if the service taker is the goods sender.
Step 4: Simulate Invoice (Technical name: CTEOLIVS)
Actions in Step 4: Simulate Invoice (technical name: CTEOLIVS)
 The fiscal clerk can trigger a simulation using XML data, tax code, and CFOP.
This simulation serves as check on the ERP side to verify if an invoice receipt can
be posted. The fiscal clerk can visualize the simulation and comparison results
with the data of the inbound CT-e. The fiscal clerk can change tax code and CFOP
code.
o If the simulation was correct, then the CT-e can proceed to the next
processing phase.
o If the simulation is not correct, then the CT-e receives the result
Simulation Not OK. In this case, the fiscal clerk can either:
1. Reject the CT-e and notify the vendor. (Vendor notification is not triggered
automatically upon rejection; the fiscal clerk must notify the vendor
manually.)
2. Manually adjust tax code and CFOP code and rerun the simulation.

  Note
 All parameters must be saved before the status can be changed.
Step 5: Transport Confirmation (Technical name: CTEOLTRC)
The transport confirmation is a manual step: The user has to manually confirm that
this step is OK.
Actions in step 5: Transport Confirmation (Technical name: CTEOLTRC)
The transport confirmation is a manual step: The user has to manually confirm that
this step is OK.
Step 6: Check Authorization (Technical name CTEAUTHG and CTEILIVP)
After the transport confirmation an authorization is carried out.
Actions in step 6: Check Authorization (Technical name: CTEAUTHG)
The system automatically checks the authorization status of the XML via the SEFAZ
tax authority's Web service.
Step 7: Invoice Posting (Technical name CTEILIVP)
After the successful authorization check, the invoice is posted.
Actions in step 7: Post Invoice (Technical name: CTEOLIVP)
 The invoice receipt is posted to the ERP system.
 The NFE system receives the result of the invoice receipt from the ERP
system:
1. Invoice receipt successful: In this case, the status of the step is set
to OK. The NFE process is completed.
2. Invoice receipt failed and no invoice is created: In this case, the step
is set to Not OK and you must carry out manual corrections in the ERP system.

12- CT-e for NF-e Inbound with

TM (Trade Management)
 
The following scenario is used as an example to illustrate this process: The goods
receiver pays for the transport together with the delivery, the inbound CT-es and
NF-es are posted in the system.
  Example
1. The truck arrives and the driver hands over all the documents.
2. The DACTE and DANFEs are scanned. The inbound CT-e is processed in the
goods receiver system according to the process CT-e for NF-e Inbound with
TM (CTEINBLE).
3. Finally the invoice receipt for the CT-e is posted.

Process
CT-e for NF-e Inbound with TM (CTEINBTM)
This process consists of the following steps:
1. CTESIGNA
Validate Signature of Business Partner
2. CTEAUTHO
Check Authorization After CT-e Receipt
3. CTEILVAL
Validation
4. CTEITIVS
Simulate Invoice
5. RECDACTE
Enter DACTE
6. CTEAUTHG
Check Authorization
7. CTEITIVP
Post Invoice
CT-e for NF-e Inbound with TM (CTEINBTM) contains the following steps:
Steps 1–2: Check Business Partner's Signature; Check Authorization after
CT-e Receipt

Actions in step 1–2

Step 1: Check Business Partner's Signature
(Technical name: CTESIGNA)
The system checks if the signature is OK.
 Signature OK: The CT-e has passed the signature check and can proceed to
the next processing step. For more information, see the documentation in
Customizing under   Nota Fiscal Eletrônica  Signature  .
 Signature Not OK: The process stops. The user can manually reject the CT-e
and notify the vendor.
Step 2: Check Authorization After CT-e Receipt
(Technical name: CTEAUTHG)
The system checks the CT-e's authorization status received from the SEFAZ tax
authority's Web service. This communication is carried out using an asynchronous
call.
 XML Authorized: The authorization check was successful and the CT-e can
proceed to the next processing step.
 XML Not Authorized: The user can manually reject the CT-e.
Step 3: Validation for CT-e for NF-e Inbound with TM (Technical
name: CTEILVAL)
Actions in Step 3: Validation for CT-e for NF-e Inbound with TM (technical
name: CTEILVAL)
The validation step carries out the following checks:
 Check if paper NF-es are involved
If yes, this is an error due to the fact that only electronic NF-es are accepted.
Paper-NF-es as reference cannot be processed.
 Check if all referenced NF-es exist in the system and if they are authorized
 Check if the service taker is the goods receiver.
Step 4: Simulate Invoice (Technical name: CTEITIVS)
Actions in Step 4: Simulate Invoice (technical name: CTEITIVS)
 The fiscal clerk can trigger a simulation using XML data, tax code, and CFOP.
This simulation serves as check on the ERP side to verify if an invoice receipt can
be posted. The fiscal clerk can visualize the simulation and comparison results
with the data of the inbound CT-e. The fiscal clerk can change tax code and CFOP
code.
o If the simulation was correct, then the CT-e can proceed to the next
processing phase.
o If the simulation is not correct, then the CT-e receives the result
Simulation Not OK. In this case, the fiscal clerk can either:
1. Reject the CT-e and notify the vendor. (Vendor notification is not triggered
automatically upon rejection; the fiscal clerk must notify the vendor
manually.)
2. Manually adjust tax code and CFOP code and rerun the simulation.

  Note
 All parameters must be saved before the status can be changed.
Step 5: Goods arrived, enter DACTE
The vendor sends goods together with a DACTE to your company, and the goods
and DACTE arrive.
Actions in step 5: Goods Arrived, Enter DACTE (Technical name: RECDACTE)
The fiscal clerk notifies the vendor that the XML has been accepted, and then sets
this process step to OK orNot OK. If the status is OK, the system automatically
continues with the next step.
Steps 6: Check Authorization
The system automatically checks the authorization status of the XML via the SEFAZ
tax authority's Web service.
Actions in step 6: Check Authorization (Technical name: CTEAUTHG)
The system automatically checks the authorization status of the XML via the SEFAZ
tax authority's Web service.
Step 7: Invoice Posting (Technical name CTEITIVP)
After the successful authorization check, the invoice is posted.
Actions in step 7: Post Invoice (Technical name: CTEITIVP)
 The invoice receipt is posted to the ERP system.
 The NFE system receives the result of the invoice receipt from the ERP
system:
1. Invoice receipt successful: In this case, the status of the step is set
to OK. The NFE process is completed.
2. Invoice receipt failed and no invoice is created: In this case, the step
is set to Not OK and you must carry out manual corrections in the ERP system.

13- CT-e for NF-e Outbound with

TM (Trade Management)
 
The following scenario is used as an example to illustrate this process: The goods
sender pays for the transport, the goods are issued and outbound NF-es are
created. The CT-e was created and the DACTE was printed by the transporter.
  Example
1. The transporter arrives at the goods sender with the DACTE.
2. The inbound CT-e is processed in the goods sender system according to the
process CT-e for NF-e Outbound with TM (CTEOUTTM).
3. The goods are issued according to the outbound NF-es referenced in the CT-
e
4. The goods are loaded to the truck and the truck leaves the company with the
DACTE and the DANFE.
The truck driver and the receiver of the transport need the DACTE as accompanying
document for the transport, but not as invoice document for the freight costs,
because the goods sender is the service taker.

Process
CT-e for NF-e Outbound with TM (CTEOUTTM)
This process consists of the following steps:
1. CTESIGNA
Validate Signature of Business Partner
2. CTEAUTHO
Check Authorization After CT-e Receipt
3. CTEOLVAL
Validation
4. CTEOTIVS
 Invoice Simulation
5. CTEOLTRC
Transport Confirmation
6. CTEAUTHG
Check Authorization
7. CTEOTIVP
Post Invoice
CT-e for NF-e Outbound with TM (CTEOUTTM) contains the following steps:
Steps 1–2: Check Business Partner's Signature; Check Authorization after
CT-e Receipt

Actions in step 1–2

Step 1: Check Business Partner's Signature (Technical name: CTESIGNA)
The system checks if the signature is OK.
 Signature OK: The CT-e has passed the signature check and can proceed to
the next processing step. For more information, see the documentation in
Customizing under   Nota Fiscal Eletrônica  Signature  .
 Signature Not OK: The process stops. The user can manually reject the CT-e
and notify the vendor.
Step 2: Check Authorization After CT-e Receipt (Technical name: CTEAUTHO)
The system checks the CT-e's authorization status received from the SEFAZ tax
authority's Web service. This communication is carried out using an asynchronous
call.
 XML Authorized: The authorization check was successful and the CT-e can
proceed to the next processing step.
 XML Not Authorized: The user can manually reject the CT-e.
Step 3: Validation for CT-e for NF-e Outbound with TM (Technical
name: CTEOLVAL)

Actions in Step 3: Validation for CT-e for NF-e Outbound with TM (technical
name: CTEOLVAL)
The validation step carries out the following checks:
 Check if paper NF-es are involved
If yes, this is an error due to the fact that only electronic NF-es are accepted.
Paper-NF-es as reference cannot be processed.
 Check if all referenced NF-es exist in the system and if they are authorized
 Check if the service taker is the goods sender.
Step 4: Simulate Invoice (Technical name: CTEOTIVS)
Actions in Step 4: Simulate Invoice (technical name: CTEOTIVS)
 The fiscal clerk can trigger a simulation using XML data, tax code, and CFOP.
This simulation serves as check on the ERP side to verify if an invoice receipt can
be posted. The fiscal clerk can visualize the simulation and comparison results
with the data of the inbound CT-e. The fiscal clerk can change tax code and CFOP
code.
o If the simulation was correct, then the CT-e can proceed to the next
processing phase.
o If the simulation is not correct, then the CT-e receives the result
Simulation Not OK. In this case, the fiscal clerk can either:
1. Reject the CT-e and notify the vendor. (Vendor notification is not triggered
automatically upon rejection; the fiscal clerk must notify the vendor
manually.)
2. Manually adjust tax code and CFOP code and rerun the simulation.

  Note
 All parameters must be saved before the status can be changed.
Step 5: Transport Confirmation (Technical name: CTEOLTRC)
The transport confirmation is a manual step: The user has to manually confirm that
this step is OK.
Actions in step 5: Transport Confirmation (Technical name: CTEOLTRC)
The transport confirmation is a manual step: The user has to manually confirm that
this step is OK.
Step 6: Check Authorization (Technical name CTEAUTHG)
After the transport confirmation an authorization is carried out.
Actions in step 6: Check Authorization (Technical name: CTEAUTHG)
The system automatically checks the authorization status of the XML via the SEFAZ
tax authority's Web service.
Step 7: Invoice Posting (Technical name CTEOTIVP)
After the successful authorization check, the invoice is posted.
Actions in step 7: Post Invoice (Technical name: CTEOTIVP)
 The invoice receipt is posted to the ERP system.
 The NFE system receives the result of the invoice receipt from the ERP
system:
1. Invoice receipt successful: In this case, the status of the step is set
to OK. The NFE process is completed.
2. Invoice receipt failed and no invoice is created: In this case, the step
is set to Not OK and you must carry out manual corrections in the ERP system.

14- Events for CT-e

 
SEFAZ has introduced the option to add a document to a CT-e to provide
information. This additional document is an Event for a CT-e and can carry
additional information concerning the CT-e. Events can be issued by SEFAZ,
the Tomador, or the sender. However, all events have to be authorized by SEFAZ. It
is possible to check the status for every CT-e inclusive all events on the SEFAZ
website. The following events are supported:
 CT-e Events: CC-e (Electronic Correction Letter)
 CT-e Events: Cancellation Event
Events that are issued by the NFE system are displayed in the Event Outbound
Monitor (see Event Outbound Monitor).
Events that are received by the NFE system are displayed in the Event Inbound
Monitor (see Event Inbound Monitor).
These monitors can be used to detect and solve possible issues in the event
outbound/inbound processing:

 Note
If you display a CT-e, the corresponding events are also displayed

 Note
Digital Signature Validation for Inbound Events
 You can configure signature or reference validation as in NF-e and CT-e
scenarios. For more information, see Configuration for Digital Signature
Validation.
 For events: If the corresponding NF-e is not found in the data base, signature
validation is used as default.
 For outbound CT-es in the CT-e Monitor (see CT-e Monitor (Outbound))
 For inbound CT-es in the Fiscal Workplace (see CT-e Fiscal Workplace)