9 Understanding NF-e and SPED

This chapter provides details about NF-e and SPED and covers the following sections:

NF-e Solution
Sistema Público de Escrituração Digital (SPED) Solution

Note:

ORFM 14.2 supports integration with fiscal partners for the issuing of NF-e (model 55), NFC-e (model 65). The NF-e integration uses a standard layout that can be leveraged by any specialist solution. For SPED, RFM provides a set of tables and views that have data from the entities managed by RFM (mainly NF related data). This integration is also standard; that is, not specific to any fiscal partner.

NF-e Solution

The overall solution landscape considers that ORFM works with a third-party solution for NF-e generation and transmission to the government.

Figure 9-1 NF-e Issuing Solution Approach

This new approach has the following steps:

External-System request new NF by calling web-service operation nfeIn-foBrNfeRequest of FmNfeService.
RFM builds response with NF XML (not in Sefaz standard).
External-system builds NF-e XML and sends to SEFAZ.
External-system gets NF status with SEFAZ.
External-system calls web-service operation publishFiscDocApprCreateUsing-FiscDocApprDesc of FiscDocApprPublishingService.
RIB/IGS inserts new consume record into queue.
RIB/IGS builds response for service call.
RFM subscriber consumes new record and starts approval flow.

NF-e Options

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.

NF-e Events

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

The user needs 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.

Webservices

In RFM NFe Integration, there are two synchronous Web-Services to communicate with the external systems and they attend the following specifications:

All services are SOAP/HTTP based.
All services comply with the JAX-WS specification.
All services are WS-Addressing enabled.
WS-Security can be plugged into these Web services without any code change.
All Web services are Document Literal Wrapped.

They are deployed in different places since they have different functionalities.

FmNfeService: This service is deployed within the rfm-service.ear. It will be responsible for finding available NFs that should be sent to SEFAZ and provide a complete XML payload (with NF information) in the response for the calling system. The service has the following operations:

nfeInfoBrNfeRequest: Provides the NF payload that should be sent to SEFAZ
ping: It responds with the same data sent on the request. This service is used to check server availability.

Valid values for tipo_integração attribute

Attribute	Description
NFE_P	NF-e Approval request
NFE_C	NF-e Cancelation request
NFE_N	NF-e Nullification request
NFE_P_CO	NF-e Contingency Approval request
NFE_F	Contingency Approved NF-e waiting for Final SEFAZ Approval
NFE_S	NF-e Status Information request
NFE_A_P	NF-e event request - "Confirmation of Operation"
NFE_C_P	NF-e event request - "Operation not Performed"
NFE_U_P	NF-e event request - "Unknown Operation"

FiscDocApprPublishingService: This service is deployed with igs-service.ear (RIB). It will be responsible for enqueuing the payload sent from the calling system. The payload contains all necessary information for NF status consume process. This service has the following operations:

publishFiscDocApprCreateUsingFiscDocApprDesc: This service will enqueue the payload in the request into etFiscDocAprrFromRfm queue.
ping: It responds with the same data sent on the request. This service is used to check server availability.

Attributes Description for FiscDocApprDesc

Attribute	Description
integration_id	Unique id of the integration process. This id was sent during FmNfeService.
fiscal_doc_id	Internal. Optional tag.
irl_doc_id	Internal. Optional tag.
sefaz_processing_date	SEFAZ processing date
status	Status of the SEFAZ processing
nfe_access_key	NFe Access key.
nfe_protocol	SEFAZ protocol.

Attributes Description for FiscDocApprDesc

Status	Description
A	NF-e Approved
DN	NF-e Denied (Denegado)
E	Request Processing Error: data or transmission errors (in any situation; emission, cancel or nullify)
A_C	NF-e Approved in Contingency mode
E_CO	Request new NF-e sequence
N_A	NF-e is successfully Nullified
C_A	NF-e is successfully Canceled
C_E	Cancel processing Error
A_F	The NF-e issued in Contingency is Approved
NFE_I	Intermediate flag that is updated by fiscal partner while the document has been sent to SEFAZ, just in case of emission.

Sistema Público de Escrituração Digital (SPED) Solution

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 filling the mandatory 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.

Figure 9-2 SPED Integration

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, 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.

SPED interfaces are updated by batch import_SPED.ksh. More details about this batch, see about it in this document.

Block K - Stock Position

There is another type of information that will affect the Retailers Companies also related to stock of all the merchandise available to resale/commercialize. This info will take place in SPED accessory obligation (EFD-ICMS/IPI) and it is called Block K.

The Block K should be informed monthly and must cover the information about stock Position of all items type, a snapshot, right after the end of the month.

Until now, about the stock, only the Block H existed. This Block is different because in it should be informed the physical count quantity related to the stock of the Retailer and it is mandatory to inform once a year.

As a solution to fulfill this new legal requirement this document will detail a proposal of a new batch process that should cover most of the information required in the Block K. It is important to say that the main target of this Block K, are the Manufacture Industry. Hence, the Retailers will be affected in a specific point basically in one register called K200 (stock position).

In this register K200, is expected the Retailer inform not only the stock quantity owned by the Retailer, but also the stock owned by retailer that possession of this stock is in a third-party (External Finisher).

Main Flow

Performance Optimization for SPED

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.