3 Setting up RMS for ORFM and Brazil Localization

This chapter describes the processes you need to prepare RMS to use ORFM and Brazil localization.

Decoupling RMS and ORFM Batch

Identical processes that are performed differently in RMS and ORFM have been separated using a process called decoupling. This allows installation of RMS without installing any (or a minimal portion) of the ORFM system. This means that direct reads and writes to the ORFM tables and views from RMS are avoided.All processes involving localization are encapsulated within a localization wrapper package. The decoupling between RMS and ORFM is controlled in that wrapper package.

Dynamic Function Calls

ORFM and RMS utilize dynamic function calls to decouple. This method uses a configuration table to determine which function or procedure, either base or localized code, is dynamically executed.

Figure 3-1 Dynamically Executed Decoupling

There are five components in the dynamic call approach:

The original code – This is the base code that does the callout to the localization layer.
L10N_SQL wrapper (WRP) – This function decides whether to use the base code or the localized version of the code.
L10N configuration table – This table contains the procedure name to be executed per localized instance.
New base function (NBF) – This function contains the existing logic from the original code replaced by callouts to the localization layer.
Localized function (LF) – This contains the necessary procedures to carry out the localization tasks. This may contain actual calls to ORFM functions.

PL/SQL Package Calls

Callouts are made in the original base code where localized codes are introduced. There can be more than one callout in a base function, and every callout points to the localization layer. In scenarios in which code needs to be replaced, or the base code block is not applicable when localization is enabled, a New Base Function (NBF) exists to contain this code. The localized functionality is moved to a Localized Function (LF).The localization layer contains the WRAPPER function (WRP) - EXEC_FUNCTION, which is called by the original base code. This wrapper uses a L10N configuration table to determine if the New Base Function (NBF) or a Localized Function (LF) needs to be executed. The call to these functions is done dynamically. The configuration table may contain different function references for different localizations.Because the calls to the functions are dynamic and the parameters passed in and out may vary depending on the function called, the PL/SQL Type Inheritance approach is used to accomplish this.

PL/SQL Type Inheritance

In this approach, the in/out parameters to be passed to functions should be encapsulated in object types. The object types follow PL/SQL Type Inheritance (a supertype is created from which several subtypes will be derived). The supertype is a generic object that can be used across functions. Derived subtypes contain all the attributes of the parent type (or supertype). The subtypes can also contain additional attributes.

Localization Layer

The localization layer is made up of the following components:

The L10N configuration table
The L10N_SQL package
Country-specific localization packages (L10N_<CN>_SQL)

Figure 3-2 Localization Layer

L10N_SQL contains only the wrapper and other functions, which are generic to localized countries. L10N_BR_<FUNC>_SQL contains only the Brazil-specific functions under <FUNC> functionality area that are called by the L10N wrapper. These functions may (flow line (2) in the diagram) or may not (flow line (1) in the diagram) call ORFM functions directly.

Accomplishing Decoupling

BASE INSTALL: RMS has a dependency on L10N_SQL because it calls the wrapper directly through a callout. When RMS is installed, an L10N configuration table is pre populated with references to the New Base Functions (NBF). Because these NBF functions have no dependency on ORFM, RMS does not need the Localized Functions (LF) in the base.

LOCALIZATION INSTALL: After ORFM and country-specific localization packs (L10N_BR_<FUNC>_SQL, L10N_PE_<FUNC>_SQL) are installed, the L10N configuration table is pre populated with the localized functions for the country (BR, PE). The wrapper now calls the functions from the country-specific packages.

Note:

Dependency is created only at run time because the functions are executed dynamically.

Decoupling Batch Programs

In a batch program, decoupling is accomplished in a way that, if a base and localized process must occur (forking), the base logic will reside in the NBF and the localized process will be in the LF. A wrapper is used by the main batch program to call the LF or NBF. Only one version of the function is executed in an instance of the function call.

To decouple the functions, there are separate localized libraries for LFs per country. NBFs are declared in the main batch program.

A utility library contains all the utility functions including the wrapper function. The utility function is used by the main batch program to find and retrieve the LF or NBF it has to execute. The LF pointers are organized based on the batch program that uses them, so one batch program can only use its set of LF pointers.

The NBF pointers are declared in the main batch program.

To make the parameters of the NBFs and LFs generic, a struct is used. This struct, which is called the parent struct, resides in an object library. This is the only parameter for the NBF and LFs. If additional fields are needed, the library must be modified to create a struct within the parent struct (the child struct). These structs must be populated first before passing it to the wrapper class to call the NBFs or LFs.

Set up Fiscal Download

Fiscal Download holds data such as the Nature of Operation (NOP), ncm_codes (Nomenclatura Comum do Mercosul classifies items according to Mercosul regulations), pauta_codes, NCM exception codes, and CEST codes. This data is obtained from the Tax Engine solutions, and is maintained in RMS. This is mandatory information used in item creation and NF calculation, while making tax calls to the Tax Engine solutions.

No front-end navigation is available for this. The l10nbr_taxweb_fisdnld batch downloads data from TaxWeb solution. In case of Synchro tax engine, the download is performed by l10nbr_synchro_fisdnld batch.

Note:

The fiscal download (fisdnld) batch accepts any one of the parameters for instance, NCM, NCMCHAR, CEST and so on. You can also choose the parameter as 'ALL'.

Set up Item Fiscal Attributes

Item fiscal attributes are mandatory for any item creation. These attributes are referenced when the item is used for any kind of transaction data creation like Purchase Orders and Transfers. Item attributes include NCM code, service ind (Y/N), NCM characteristic code, ex ipi, pauta code, service code, origin code, federal service code, state_of_manufacture, pharma_list_type, Cest code, FUOM Unit, and FUOM Conversion Factor.

Navigate: From the Main menu, select Items > Country > Fiscal Attributes.

Set up Fiscal Attributes for other Entities

Fiscal attributes for other entities hold information such as address, company code, and tax contributor indicators. These are necessary for tax calls and are used by the TaxWeb Tax Rules to apply appropriate rules and return the correct taxes.

Navigate: From the Options menu, select Fiscal Attributes. You can also navigate Fiscal attributes from the Options menu of Warehouses, Stores, Outside Locations, Partners, Supplier, Transfer Entity, and Set of Books.

For more information, see the Oracle Retail Merchandising System User Guide.

Set up Utilization

All merchandise that is being fiscally accepted using ORFM must have the fiscal utilization, which determines the type of the business operation that the fiscal document supports.

The fiscal utilization determines the appropriate taxes involved by the retail operation, the impact on stocks and costs, and the type of information to be sent to other systems.

Utilization is associated with a Requisition Type and a Nature of Operation. This identifies the type of transaction for TaxWeb Tax Rules to calculate the appropriate taxes.Utilization also can be associated with a particular Document Type. Different attributes are available to be configured for utilization which gives more granular information on the kind of document and action to be applied.

The following are the various parameters you can configure for an utilization code:

Complementary NF
Complementary NF for Triangulation
Complementary NF for Cost/Tax Correction
Complementary NF for Freight
Complementary NF for Exit
ICMS-ST recovery
Automatic NF Approval
Allow Receiving
Choose NF
Item Utilization
Import Order NF
Import Order Type
Direct Import
Import on behalf of Third Parties
Import By Order
NFE Manifest

Navigate: From the Main menu, select Fiscal Management > Fiscal Configuration > Fiscal Utilization > Edit. The Fiscal Utilization Setup window opens.

Set up Document Types

You must set up at least one fiscal document type prior to using ORFM. Each Fiscal Document Type needs to be associated with a fiscal utilization. Multiple Utilization identifiers can be associated to one document type.

Navigate: From the Main menu, select Fiscal Management > Fiscal Configuration > Fiscal Document Types > Edit. The Fiscal Document Type window opens.

Set up System Options

The fm_system_options table is the control table where several parameters are stored. The system options table provides various settings such as environment type (Brazil/Non-Brazil), supplier site is on or off, and if multiple set of books are in use.

System options can be setup using the user interface or supplied through direct entries using the database. Usually system options are setup during RMS installation as part of seed data. Use the RMS user interface to update system options post installation.

You will need to setup ORFM system parameters, including the Default Utilization codes. The configuration settings control system behavior based on the values entered.

Navigate: From the Main menu, select Fiscal Management > System Setup > System Options > Edit. The System Options window opens.

Set up Reason Codes

You must set up reason codes for overage and damaged in the RMS reason code master table (inv_adj_reason) prior to using ORFM. These reason codes are interfaced to ORFM from RWMS and SIM. If these reason codes are not set up correctly, the integration to ORFM for receipt verification fails.

Set up Partner

To use ORFM, the default partner and partner type in fm_system_options must be setup in RMS.

Set Primary Country

To use ORFM, the Primary Country must be set to BR. For more information on how this can be accomplished during RMS installation, see the Oracle Retail Merchandising System with Brazil Localization Installation Guide.

Set VAT Indicator

To use ORFM, VAT_IND must be set to Y. For more information on how this can be accomplished during RMS installation, see the Oracle Retail Merchandising System with Brazil Localization Installation Guide.

Set Default Tax Type

To use ORFM, the Default Tax Type must be set to GTAX. For more information on how this can be accomplished during RMS installation, see the Oracle Retail Merchandising System with Brazil Localization Installation Guide.

Verify Localized Indicator

The Localized indicator check box indicates whether the Brazil patch is installed. It is auto-checked by the system if the Brazil patch is installed.

Use the following procedure to verify the Localized Indicator:

From the RMS Start menu, select Control > Setup. In the Content of Setup window, select Country > Edit. The Country Maintenance window appears.

Figure 3-3 Country Maintenance Window
Select BR and click the Options menu.
From the Options menu, select Attributes. The Country Attributes window opens.

Figure 3-4 Country Attributes Window
Verify that the Localized Ind check box is selected and click OK. You are returned to the Country Maintenance window.
Click OK to save your changes and close the window.

Set up Tax Codes

Tax codes must be set up in the FM_TAX_CODES table. This table holds entries for all possible tax codes that can appear on a Nota Fiscal which would be applicable on any given transaction. It also holds the matching_ind (Y/N) identifier which drives the tax discrepancy identification functionality of ORFM.

This table can only be populated by entering values directly from the back end.

Set up Flex Field Attribute

The fiscal code of the country must be set up before using ORFM.

Navigate: From the Main menu, select Control > Setup > Country > Edit. The Country Maintenance window opens.

Figure 3-5 Country Maintenance Window

Select BR and click the Options menu.
From the Options menu, select Fiscal Attributes. The Localization Flexible Attributes window opens.

Figure 3-6 Localization Flexible Attributes Window
Set the Fiscal Code to 105 and click OK. You are returned to the Country Maintenance window.
Click OK to save your changes and close the window.

Set up Fiscal Document Chunk Size

The L10N_TAX_OBJECT_CONFIG.THREAD_ITEM_LOC_COUNT column in The L10N_BR_TAX_CALL_STAGE_RMS table specifies the maximum number of item/locations that are contained in a Fiscal Document object. Location is defined as the &rsquor;From Entity' in the ORFM context. Logic in the ORFM integration package (L10N_BR_INT_SQL) uses this value to split fiscal data into logical unit of work packets or 'chunks' that are processed concurrently by RTIL.

Chunks as used in RTIL are further discussed in Chapter 7, "Integrating with TaxWeb Tax Rules– Retail Tax Integration Layer" in section Concurrent Processing in RTIL.

The value in the L10N_TAX_OBJECT_CONFIG.THREAD_ITEM_LOC_COUNT column defaults to 1000 through a script upon installation. Oracle Retail recommends that you set this value in conjunction with determining the configuration for RTIL's Maximum Thread Constraint and Capacity Constraint as they are intrinsically related.

Set up FM Tran Code

Tran codes in ORFM table fm_tran_codes are set up as a part of installation.

Set up Set Of Books

You must set up Set of Books in FM_SOB_SETUP table.

Set up Chart of Account

You must set up Chart of Accounts in FM_COA_SETUP table.

Set up GL Options

You must set up the entities that are dynamic in nature in FM_GL_OPTIONS table.

Dynamic Segments Set up for Chart of Accounts

You must set up dynamic segments for chart of accounts in FM_DYNAMIC_SEGMENT_SETUP table. You can also achieve this through the Dynamic Segment Configuration form.

Account Set up for Chart of Account

You must set up account setup for chart of account in FM_ACCOUNT_SETUP table.

Set up GL Cross Reference

You must set up GL cross reference in FM_GL_CROSS_REF table. You can also achieve this through the GL Cross reference form.

Including Balance to RTV Balance Control

When creating RTV NF with Balance Control Enabled (FM_SYSTEM_OPTIONS.VARIABLE = 'BALANCE_CONTROLE_RTV' = 'Y'), the process get balance information from the following table (FM_FISCAL_DOC_DETAIL_BALANCE) where must contain information about PO NF received.

The FM_FISCAL_DOC_DETAIL_BALANCE table will hold information about received quantity from a PO NF in order to perform balance to Item/Supplier/Location. It should include Unit Cost from PO NF and a Quantity field to Balance Control.

Table 3-1 FM_FISCAL_DOC_DETAIL_BALANCE

Column Name	Description
FISCAL_DOC_LINE_ID	Fiscal Document Line sequence number
MODULE	Sender type. Valid value for RTV: Supplier ("SUPP")
KEY_VALUE_1	Supplier ID
KEY_VALUE_2	"S"
LOCATION_ID	Location identifier (Physical Warehouse ID or Store ID)
LOCATION_TYPE	Location Type ('W' "Warehouse", "S" "Store")
ITEM	Product code
PACK_IND	It indicates if the item is a pack item or not
PACK_NO	The pack item number to which the component item belongs
RECEIPT_DATE	Receipt Date
UNIT_COST	Item unit cost
QUANTITY_NF	Quantity indicated in NF
QUANTITY_RECEIVED	Quantity Physically Received
QUANTITY_RETURNED	Quantity Returned - Balance for RTV
QUANTITY_RESERVED	Quantity Reserved for RTV NF not approved
TRIANGULATION_IND	Indication whether PO NF is a Triangulation NF/PO
TRIANG_MODULE	In case of Triangulation NF/PO: Valid value "SUPP"
TRIANG_KEY_VALUE_1	In case of Triangulation NF/PO: Supplier Delivery ID
TRIANG_KEY_VALUE_2	In case of Triangulation NF/PO: "S"
CREATE_DATETIME	Date and time when the record was created. It is only populated on insert
CREATE_ID	User ID of the user that inserted the record
LAST_UPDATE_DATETIME	Holds the date and time of the most recent update
LAST_UPDATE_ID	Holds the user ID of the user who most recently updated the record