You are on page 1of 46

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)

You might also like