| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.1.3.1 E91382-02 |
|
 Previous |
 Next |
| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.1.3.1 E91382-02 |
|
Previous |
Next |
This chapter provides details about NF-e and SPED and covers the following sections:
|
Note: ORFM 14.1.3 supports integration with fiscal partners for NF-e (model 55), NFC-e (model 65) and SPED.In release 14.1.3, the solutions certified are:
|
Nota Fiscal Eletrônica (NF-e) or Electronic Fiscal Note is a Brazilian government project with the objective of implementing a national model of electronic fiscal document to substitute the current system of issuing the fiscal documents in paper. The virtual document has juridical validity guaranteed by the digital signature of the issuer. It simplifies the fiscal obligations of the taxpayers and allows the follow-up of the commercial operations by the tax authority.The NF-e issuer generates an electronic file with all NF information in a more detailed level than the regular NF. This file must be digitally signed to guarantee the integrity of the data and the authorship of the issuer. The electronic file that corresponds to the NF-e is transmitted through the internet to the SEFAZ (Secretaria da Fazenda - Brazilian Tax Authority) of the origin state of the issuer. The SEFAZ provides a pre-validation of the file and returns a receiving protocol (Authorization for Use), that is necessary to the traffic of the goods.To follow the goods, a graphic representation of the NF-e is printed. The Documento Auxiliar da Nota Fiscal Eletrônica-Auxiliary Document of the Electronic Invoice (DANFE) is printed in a common paper, one copy that highlights the access key for consultation of the NF-e in the internet and a bi-dimensional bar code which facilitates the capture and confirmation of information of the NF-e by the fiscal units.The DANFE is not a Nota Fiscal, and does not replace the NF. It is just an auxiliary document for consultation of the NF-e. It has the access code of the NF-e which allows its owner to confirm the real existence of the NF-e in RFB environment (Receita Federal Brasileira-Brazilian Federal Tax Authority) or the SEFAZ Web site.
The overall solution landscape considers that ORFM works with a third party solution for NF-e generation and transmission to the government.
ORFM allows the generation of NF-e depending on the setup of the fiscal document type and fiscal document model type. The System options are available to default the document type to be used in transactions that have dependency in other modules such as RWMS or SIM.
Considering that the transactions where the NF-e issuing is applicable, like transfers, are initiated in RWMS. Hence the utilization code associated to each location must be the same utilization code set in fm_system_options as default utilization for outbound transactions, such as transfers, intercompany transfers, and RTVs. The default utilization code is used by RWMS to generate the NFS. This behavior is not controlled in the system and must be defined by the user. The utilization setup will allow users to define the document type and document model which drives the creation of an electronic NF or not.
The new NF-e events will need physical receiving confirmation. The new communication events for the NF-e receiving process are mandatory to all companies, since 2012. These events consist in:
Acknowledgement of the operation
Confirmation of the operation
Information of operation not completed
Ignorance of operation
You need to create the new NF-e integration points in order to address this requirement. NF-e integration is meant only for NF issuing processes and these new points will consider NF-e receiving processes (PO receiving).
Only the PO receiving NFs that have the access key field in the ORFM tables are considered for these new flows. That means only NF-e's received from vendors must have the physical receiving confirmation.
The NFs entered manually with the access key informed are also considered. The confirmation of the physical receiving or the cancelation of the receiving itself are sent to NF-e solution. The NF-e itself that comes from the vendor are already approved by SEFAZ during its issuing process.
Once the NF-e is inserted into ORFM (with access key), in case the physical receiving process does not even start and the user decides to not continue with the process for any reason, ORFM permits the deletion of the schedule and the associated NFs. This means the receiving of this vendor was canceled. A message will be sent to SEFAZ so the Government knows that the operation associated to the NF-e was not concluded. In this way a message will be sent to NF-e integration with a reason for the rejection so it can be sent to the Government.
If the physical receiving has started, which means the operation is accepted at the retailer, the normal receiving process will continue until the physical receiving and NF approval.
After the NF approval, a confirmation will be sent to the NF-e integration. This confirmation would be required irrespective of the possible discrepancies in the receiving process.
The FM_STG_NFE staging table for NF-e contains the fiscal doc identifier and its status for the Java Adapter to fetch those records, which are in NF-e Pending or NF-e Corrected or NF-e Canceled state and submit them to the integrated fiscal partner. The EVENT_ID field contains the sequence in which the NF-e messages are published to fiscal partners. The fiscal_doc_no, series_no, cnpj and justification fields are used to allow fiscal partner's NF-e product to interface the fiscal document information to SEFAZ without scanning through the object source again.
There are 18 status codes to capture NF-e flow between ORFM, fiscal partner, and SEFAZ.
NFe_P - Fresh NF-e document waiting to be picked by fiscal partner.
NFe_X - Corrected NF-e document waiting to be picked by fiscal partner.
NFe_C - Canceled NF-e document waiting to be picked by fiscal partner.
C_A - fiscal partner updates the staging table with this status when NF-e is successfully canceled.
N_A - fiscal partner updates the staging table with this status when NF-e is successfully nullified.
NFe_I - Intermediate flag that is updated by fiscal partner while the document has been sent to SEFAZ, just in case of emission. A response to a cancel call is provided by SEFAZ immediately, whereas an emission situation does not provide an immediate call.
A - Approved NF-e from SEFAZ.
E - Erroneous NF-e from SEFAZ due to data/transmission errors (in any situation; emission, cancel or nullify).
NFe_A_P - This status indicates NF-e approval pending which is set during confirmation of physical receiving. This event is working integrated only with Synchro Electronic Fiscal Document (DFE).
NFe_C_P - This status indicates NF-e cancellation pending which is set during cancellation of NF-e receiving process.
A_C - This status indicates the NF-e approved at SEFAZ in EPEC Contingency mode. This mode is a contingency way to customers to issue the NF-e when the normal way is not working.
A_F - This status indicates the NF-e final approval protocol after the NF-e was issued in EPEC Contingency mode.
C_E - This status indicates the error when trying to cancel a NF-e. The error could be caused by several reasons and the user should check the log for more details.
DN - This status indicates the NF-e is denied when there is a problem or a legal restriction, in the SEFAZ, with the CNPJ of the Issuer or the Addressee of the transaction.
E_CO - This is an option for the DFE manager to request to ORFM a new sequential number to issue the NF in EPEC contingency mode. In this case ORFM will respond to DFE (status NFE_P_CO) with a new fiscal_doc_id and a new seq_number for the same schedule. ORFM will automatically try to nullify the first NF (seq_number, fiscal_doc_id) sending request (status NFE_N) to DFE.
NFE_F - This status will be used by ORFM to request to the DFE a Final Approval Protocol for the NF-e issued in EPEC contingency mode.
NFE_N - This is an option to submit (request to DFE) a NF-e for nullification.
NFE_P_CO - It is a response from ORFM to DFE to submit a NF-e (new fiscal_doc_id, new seq_number) for approval in EPEC contingency mode.
On the consumption side, ORFM writes the API and grants access to fiscal partner to load acknowledgments (approval or erroneous details) from SEFAZ into the respective ORFM tables.
When the NF-e gets approved successfully or processed with errors, fiscal partner makes a call to the ORFM packaged procedure FM_MS_NFE_SQL.CONSUME to update the NF-e details into the respective ORFM tables. If there are any errors then it inserts the NF-e transaction history table with error_id and error_description. The consume procedure contains the following parameters:
Table 10-1 Parameters
| Variable Name | Input/Output Designation | Data Type/Length |
|---|---|---|
|
O_status_code |
IN OUT |
NUMBER |
|
O_error_message |
IN OUT |
VARCHAR2 |
|
I_message |
IN |
OBJ_MS_RFM_NFE_REC |
I_message contains the following fields:
Table 10-2 I_Message Fields
| OBJ_MS_RFM_NFE_REC | |
|---|---|
| Name | Type |
|
fiscal_doc_id |
number10 |
|
nfe_access_key |
varchar244 |
|
nfe_protocol |
number15 |
|
nfe_danfe_url |
varchar21000 |
|
status |
varchar26 |
|
errorDtl_tbl |
OBJ_MS_RFM_ErrorDtl_TBL |
Table 10-3 Message Fields
| OBJ_MS_RFM_ErrorDtl_REC | |
|---|---|
| Name | Type |
|
message_id |
number4 |
|
message_desc |
varchar21000 |
|
transaction_date |
timestamp |
OBJ_MS_RFM_ErrorDtl_REC is used to describe the errors (if any) that occurred in the process of NF-e submission to SEFAZ.
When the NF-e is approved by SEFAZ without any errors, fiscal partner makes a call to this CONSUME procedure with status as A, along with the corresponding values in other fields like NFE_ACCESS_KEY, NFE_PROTOCOL, and NFE_DANFE_URL with appropriate data. In this case, the errorDtl_tbl will be NULL since there are no errors associated with it. The ORFM table is updated based on this input data.
If any errors occurred in NF-e processing, the status will be E. Now the errorDtl_tbl will contain the error details. Here NFE_ACCESS_KEY, NFE_PROTOCOL, NFE_DANFE_URL fields will be NULL.When the fresh document (NFe_P) or corrected document (NFe_X) or canceled document (NFe_C) is picked from the staging table FM_ STG_NFE by fiscal partner's Java integrator monitor for polling, fiscal partner makes a call to this CONSUME procedure with status as NFe_I. All the remaining fields will be NULL:
nfe_access_key
nfe_protocol
nfe_danfe_url
errorDtl_tbl (PL/SQL table type)
If the CONSUME procedure called by fiscal partner is successful, then O_status_code will be S (Success). If it is unsuccessful, it will be E (Error) with the error referenced in the O_error_message.
There could be some network transmission errors during NF-e flow between ORFM, fiscal partner, and SEFAZ. Such error codes are predefined by SEFAZ and do not require the user to correct anything. fiscal partner has provided two codes for network disruptions that can be resent without manual intervention, 286 and 296. Logic in the FM_MS_NFE_SQL.CONSUMEsubscription API automatically re-sends such rejected NFes without manual intervention.
Sistema Público de Escrituração Digital (SPED) or Public System of Digital Bookkeeping is the result of several efforts from the Brazilian government to modernize and increase the level of control over the fiscal transactions for all companies. It is based on a digital file that is transmitted periodically to the government through the internet. Similar to the NF-e, the file is digitally signed through specific programs that validate its format and content.The strategy adopted to address this requirement was to keep the transaction features in Oracle Retail Fiscal Management (ORFM) and the interface to the Fiscal Authority in Oracle's fiscal partners.To support this strategy, views and tables make available all information to the fiscal partner based on the fiscal movements.
The SPED file that is generated by the fiscal partners contains a structure organized in blocks with opening and closure registers. The information in each block is as follows:
Block 0: Opening, Identification and References
Block C: Fiscal Documents I - Merchandise (ICMS/IPI)
Block D: Fiscal Documents II - Services (ICMS)
Block E: Fiscal counting of ICMS and IPI
Block H: Physical Inventory
Block K: Stock Position
Block 1: Other information
Block 9: Control and Closing of the Digital File
The file is generic and includes information pertinent to all types of companies. The retail segment is required to fill part of the entire file. In addition, the fiscal partner will be in charge of completing the information that is not provided by Oracle Retail.
The overall solution landscape is based on the existing views that integrate fiscal and master information with Oracle's fiscal partners.
Because the SPED file has several sections corresponding to all types of transactions and fiscal data for a company, the scope of the integration (from the commercial system standpoint) was to make available all data kept within RMS and ORFM. Because of this, all types of data related to products for resale, and the fiscal transactions related to this type of product, are available in ORFM views and tables.Products used for consumption, assets, and services, and all transactions related to these types of product, are out of the scope for RMS/ORFM and are not available in the views.The views and tables created to feed SPED include only data available in RMS/ORFM. The file is generated by the fiscal partner´s solution, and fields (such as file opening and file closing), data related to the version of the SPED program, and all specific data for the file is provided by the fiscal partner. In addition, any field that can be deduced by the fiscal partner should also be provided by them.
SPED interfaces with a third-party system that shares the RMS database and opens the ports to establish network connectivity. It depends on the decision of the client to either host the SPED interfacing application (Interdados) within their environment or host it in a fiscal partner's environment. For security considerations, a separate schema should be created that contains only synonyms to as many objects required by the fiscal partner to generate the SPED information. Only the select privileges should be granted on these synonyms. No insert/update/delete should be allowed.
The anticipated volume of daily operations of a Tier 1 retailer are in the order of a few hundred thousand transactions per day. All these inbound and outbound transactions create NFs that insert records into the ORFM prime tables. The SPED reporting feeds have a monthly frequency that lead to accumulation of large volumes of data. To mitigate the performance concerns for these large volumes, the solution approach has adopted the following strategy:
Views only use all the foundation/static data tables.
For the transaction tables that are bound to be voluminous, interface tables are created and populated with the necessary data, required for SPED by a batch job.
The batch job is run on a daily basis so that the volumes are made manageable by operating on a day window instead of an entire month window.
The primary advantage of this solution is the high impact transaction tables are decoupled from direct access from the external system thereby avoiding the risk of slowing down the system during online operations. The batch job runs during the online shutdown window and the daily job operates on reduced volumes.
