8 Integrating with Synchro Tax Engine – Integration Layer

Following the strategy of having a flexible format to fit any kind of tax scenario and also to make the tax rules setup part of a specialist solution, Oracle Retail has integrated its applications with another third-party tax engine. The ORFM system is integrated with the Synchro Tax Engine solution through the Integration Layer.

Note:

This chapter is only for customers who have Synchro as tax vendor.

Synchro is integrated with the ORFM system through the integrated layer (integration tables) with limited access to Synchro. A Synchro API with proper grants are exposed to the ORFM system which is used for making a Tax calls. The Integration Layer supports integration of RMS and ORFM with Synchro Tax Engine solution. The ORFM system is integrated with the Synchro Tax Engine solution to obtain tax calculation that supports all Brazilian tax legislation, with a high level of exception treatments.

Note:

Synchro tax engine integration is not supported for the patch release 14.1.3. Previous versions are supported normally.

For all flows in Oracle Retail that need to have tax calculation, the Integration Layer is used to have all taxes applied from the Synchro Tax Engine solution, considering the input parameters.The following processes in ORFM/RMS use the tax calculation integration:

Inbound NF validation
Outbound NF issuance
PO tax breakdown
Item creation
Refresh tax
Item fiscal reclassification

For each of these processes, the needed input information is sent to Synchro Tax Engine solution through the Integration Layer. The Integration Layer has a standard data model format that supports all possible variations for tax calls. This data model has input tables necessary to provide transaction and master data level information as well as output tables that hold all tax calculation results.

This chapter covers the following topics:

Integration Overview

The Integration Layer is responsible for the Synchro Tax Engine API call with the necessary formatting. The Synchro Tax Engine API exposed has a native Nota Fiscal format, and formatting must be sent in that way for tax calculation in Synchro Tax Engine. In Synchro Tax Engine solution, an integration layer is used for data completion. The Integration Layer in Oracle Retail is populated with the records by RMS or ORFM system before calling the Synchro API. The API triggers the Tax call in Synchro Tax Engine. Once the taxes are classified, the API with the returned values is sent back to the Integration Layer in Oracle Retail.The layout of Synchro Tax Engine solution is based on the NF layout and has the following structure:

Entities (foundation data and fiscal attributes of each entity of a NF, such as Issuer, Addressee, and Transporter)
NF header information
NF item information
Tax classification

Figure 8-1 Oracle Retail/Synchro Tax Engine Integration

Retail Tax Data Model

The Retail Tax Data model is an abstraction introduced over the Synchro Tax Engine Tax Data model with the aim of achieving semantic interoperability. The Retail Tax Data Model aims to decouple Oracle Retail Products (RMS, ORFM) from the vendor specific data model.

Figure 8-2 Retail Data Model Structure

Object Structure Overview

L10N_BR_TAX_CALL_REQ
L10N_BR_TAX_CALC_REQ_HEAD
L10N_BR_TAX_CALC_REQ_REG
L10N_BR_TAX_CALC_REQ_ITEM
L10N_BR_TAX_CALC_REQ_IT_TAX
L10N_BR_TAX_CALC_REQ_FREIGHT
L10N_BR_TAX_CALC_REQ_NV_PAIR
L10N_BR_TAX_CALC_REQ_CNAE
L10N_BR_BULK_ST_REQ
L10N_BR_FISCAL_QUERY_REQ
L10N_BR_FISCAL_REF_REQ_HEAD
L10N_BR_TAX_CALC_REQ_CONTRIB
L10N_BR_TAX_CALC_RES_HEAD
L10N_BR_TAX_CALC_RES_HD_TAX
L10N_BR_TAX_CALC_RES_ITEM
L10N_BR_TAX_CALC_RES_IT_TAX
L10N_BR_TAX_CALC_RES_FREIGHT
L10N_BR_FISCAL_QUERY_RES
L10N_BR_FISCAL_REF_RES_HEAD

High Level Integration View

The Integration Layer in Oracle Retail does the following:

Exposes a more abstracted tax data format (Retail Tax Data Model) for RMS/ORFM to populate the interface table with transaction details that require taxes to be computed
Invokes the taxation API of Synchro Tax Engine
The computed taxes from Synchro Tax Engine for the transaction details are stored in the result table of the integration layer

Figure 8-3 Synchro High Level Integration

Logging

Since this is PL/SQL Tax engine there is no default logging for the Tax call. Logging of the request and result table for a call can be enabled by setting the string to 'N' for the variable SYNCHRO_CLR_TBL_IND in FM_SYSTEM_OPTIONS table. It is customers responsibility to Flush the integration tables once the logging is disabled. Logging is implemented in a declarative manner using Spring Aspect Oriented Programming (AOP). AOP is a paradigm that addresses separation of concerns, thereby ensuring that logging and business logic are kept separate in the code, avoiding code cluttering.

Data Mapping and Expected Output Results

ORFM calls the Synchro Tax Engine API for the expected scenario. The input parameters are populated into the request table and the returned values are populated into the result tables. The request tables do not contain any tax information. In the result table, the tax calculation results are populated based on the original values in the request table.

Figure 8-4 Input x Output Parameters

Tax. Calculation Scenarios

For all scenarios, the input parameters are based on the request tables layout. The detail data mapping for the input parameters can change depending on each scenario, that is, item creation, NF calculation, PO calculation, and so on.

Scenario 1 - Inbound NF through User Entry

Enter the Inbound PO NF through the ORFM user interface. Once the NF is entered, tax call is initiated. The taxes returned by the external tax engine is compared against the informed taxes for any discrepancy.

Scenario 2 - Inbound PO NFs through EDI

NFs from the supplier could be interfaced to ORFM through EDI functionality. These NFs once generated also make a tax call through the batch provided. The taxes returned by the external tax engine is compared against the informed taxes for any discrepancy.

Scenario 3 - PO Receiving

Tax calls are made from the ORFM application during the receiving process based on the Resolution type on the Discrepancies identified during Validation of a NF.

Scenario 4 - Outbound NF Issuing

For outbound transactions like Transfer, RTV and Inventory Adjustments initiated by the Retailer, ORFM generates the NFs automatically. These NFs generated makes the tax calls and the taxes are printed on the document before approval and inventory movement.

Scenario 4 - PO Tax Calculation

The PO tax breakdown is the calculation of all applicable taxes of a PO. The PO information is similar to a fiscal document, and it is similar to the NF issuing process. The PO information utilizes the API format to have the tax calculated.

Scenario 5 - Item Creation

During the item creation process, the sales taxes applicable to each location where the item is linked are calculated. The item creation process also makes a call to the tax API to obtain the sales tax rates. The same concept is applied to the default purchase taxes used for margin calculation.

Scenarios such as primary supplier change and fiscal reclassification call the same tax integration defined for original item creation process.