15 Oracle Retail Invoice Receiving Layer

Currently the ORFM provides an interface for automatic generation of the fiscal document, the RFM/EDI, but it does not have a mechanism that generates the fiscal document based directly on the NFe XML file. To use this interface the customer has to customize process and transform the data from XML to the expected data by the RFM/EDI, considering all the complexity of the rules of deduction and transformation.

To simplify this process, Oracle Retail Receiving Layer (IRL) was conceived to enable the generation of fiscal document in RFM directly from the NF-e XML file. This process provides the capture (when using IRL OSB integration), processing and fiscal validation of the NF-e, transforming it in the expected data for EDI. It supports the entire cycle of processing the NF-e in the RFM, reporting any problems that may occur and through the reporting of progress status of the receiving.

Valid NF-e document models for this process are:

• 55 - Nota Fiscal Eletrônica

• 57 - Conhecimento de Transporte Eletrônico

This following topics are covered in this chapter:

• Transport-Level Security

• Message-Level Security

• Access Control Security

• Implementing Web Service Security

IRL Architecture

The architecture has been designed in three distinct layers with focus in performance, extensibility, and flexibility:

1. File capture and transformation: Using OSB and staging directories this process reads the NF-e XML file, transforms it in IRL data structure and calls the Invoice creations service. This process does not capture the XML file directly from SEFAZ

2. Data receiving Services (rfm-service): Using RSE (Retail SOA Enabler) a set of services are exposed to receive the NF-e XML data in a simplified structure. There is also a service to provide the status of the receiving process.

3. Data validation and Fiscal Document creation: PL/SQL packages were created to validate the received information and create the NF in RFM (trough EDI process). If the process was not able to deduce data (item id for example) a set of forms were created to enable data edition, revalidation, and refusal.

Integration Overview

Figure 15-1 IRL Architecture Overview

IRL Web Services

A set of services are available to receive the NF-e data in a simplified structure and provide status of the receiving. The following services are available through rfm-service.ear:

• createBrIrlInvoiceDesc: This service validates the received data, deduce values based on system configuration, inserts the validated data into RFM EDI tables and creates the Nota Fiscal in ORFM.

• lookupStatusBrIrlStatusCri: This service provides the status of the NF processing.

• createStatusBrIrlStatusDesc: This service create a status in IRL tables. It's used by OSB process to identify NF's that are not successfully validated during file capture process.

Note: To deploy the rfm-service.ear, see the Oracle Retail Fiscal Management Installation Guide.

IRL Data Model

The data model for IRL was designed to simplify the transformation of NF-e XML data into RFM data. It's not necessary to search for id's in RFM in order to create the NF, instead of that only a structural transformation is necessary from NF-e model to IRL model.

Note: IRL OSB component already contains this mapping.

Figure 15-2 Data Model for createBrIrlInvoiceDesc Service

Figure 15-3 Data Model for lookupStatusBrIrlStatusCri Service

Figure 15-4 Data Model for createStatusBrIrlStatusDesc Service

Object Structure Overview

The object structure overview are as follows:

• BrIrlInvoiceDesc: This object represents the header of the fiscal document with main attributes such as document model, number, series, and so on.

• BrIrlItemDesc: This object represents the detail of a fiscal document. It includes the taxes at item level.

• BrIrlIPayDesc: This object represents the list of payments of a fiscal document.

• BrIrlComplDesc: This object represents a list of complementary fiscal document information.

• BrIrlErrorLog: This object is represents a de details of an error found during IRL processing.

• BrIrlErrorLogCol: This object is a list of BrIrlErrorLog object.

• BrIrlStatusDesc: This object represents the detail of the status of IRL processing for a giving document.

• BrIrlStatusColDesc: This object is a collection is BrIlrStatusDesc.

• BrIrlStatusCri: This object represents a criteria for finding IRL documents.

• BrIrlStatusLog: This object represents the status log of IRL process. Every time a status is updated the previous status is recorded for log tracking.

• BrIrlStatusLogCol: This object is a collection of BrIrlStatusLogCol.

Configuration

Before using the IRL integration some mandatory Fiscal Management System Options should be set. Ensure they are all set before using the integration.

Table 15-1 Fiscal Management System Options

System Option	Description
IRL_AUTO_REFUSAL_DESCRIPTION	It indicates the default reason description to Automatic Refusal.
IRL_REASON_DESCRIPTION	It indicates if IRL Receipt Refusal requires reason description.
IRL_SEFAZ_VALIDATION	It indicates if IRL SEFAZ validation is required.
IRL_ALLOWS_WORKSHEET	It indicates if WORKSHEET option will be available for IRL.
IRL_ALLOWS_MULTISITE	It indicates if IRL Monitor allows multisite treatment.
IRL_XML_DATABASE_BKP	It indicates if IRL allows storing XML into database.
IRL_REASON_DESCRITPION	It indicates if IRL Receipt Refusal requires reason description.
IRL_PURGE_DAYS	It indicates the number of days for purge the IRL tables.
IRL_AUTO_REFUSAL	It indicates if IRL allows automatic refusal in Pre-validation.