| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.2 F29404-01 |
|
 Previous |
 Next |
| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.2 F29404-01 |
|
Previous |
Next |
This chapter describes the processes you need to prepare RMS to use ORFM and Brazil localization.
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.
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.
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.
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.
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.
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)
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.
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. |
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.
Item fiscal attributes are mandatory for any item creation. These attributes are referenced when the item is used in any kind of transaction data as Purchase Orders and Transfers. Item attributes include: NCM code, service indicator, NCM characteristic code, IPI exception code, pauta code, service code, federal service code, state of manufacture, pharma type list, CEST code, FUOM Unit, and FUOM Conversion Factor.
Navigate: From the Main menu, select Items > Country > Options > Fiscal Attributes when Country ID is 'BR'.
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.
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.
Navigate: From the Main menu, select Fiscal Management > Fiscal Configuration > Fiscal Utilization > Edit. The Fiscal Utilization Setup window opens.
More detail about Utilization Code setup, see it in Oracle Retail Fiscal Management User Guide.
It is mandatory to have 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.
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.
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.
To use ORFM, the default partner and partner type in FM_SYSTEM_OPTIONS must be setup in RMS.
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.
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.
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.
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.
Select BR and click the Options menu.
From the Options menu, select Attributes. The Country Attributes window opens.
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.
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.
More information about Discrepancy, see Oracle Retail Fiscal Management User Guide.
This table can only be populated by entering values directly from the back end.
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.
Select BR and click the Options menu.
From the Options menu, select Fiscal Attributes. The Localization Flexible Attributes window opens.
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.
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 ’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.
ORFM Transaction codes are set up as a part of installation. A list of existing ORFM tran codes:
| Tran Code | Description |
|---|---|
| 100 | Total merchandise cost exclusive of taxes |
| 101 | Total non-recoverable taxes |
| 102 | Total recoverable taxes |
| 103 | Total non-merchandise cost exclusive of taxes |
| 104 | Variance merchandise Cost |
| 105 | Variance recoverable taxes |
| 106 | Variance non-recoverable taxes |
| 107 | Calculation Tolerance Cost |
| 108 | Calculation Tolerance recoverable tax |
| 109 | Calculation Tolerance non-recoverable tax |
| 110 | Return NF - total merchandise cost exclusive of taxes |
| 111 | Return NF - total non-recoverable taxes |
| 112 | Return NF - total recoverable taxes |
| 113 | Return NF - total non-merchandise cost exclusive of taxes |
| 114 | Correction NF - total merchandise cost exclusive of taxes |
| 115 | Correction NF - total non-recoverable taxes |
| 116 | Correction NF - total recoverable taxes |
| 117 | Correction NF - total non-merchandise cost exclusive of taxes |
| 118 | Complementary NF - total merchandise cost exclusive of taxes |
| 119 | Complementary NF - total non-recoverable taxes |
| 120 | Complementary NF - total non-merchandise cost exclusive of taxes |
| 121 | Complementary NF non-merchandise taxes |
| 122 | RTV NF - total merchandise cost exclusive of taxes |
| 123 | RTV NF - total non-recoverable taxes |
| 124 | RTV NF - total recoverable taxes |
| 125 | Complementary NF for Freight - total Non-merchandise cost exclusive of taxes |
| 126 | Complementary NF for Freight - total recoverable taxes |
| 127 | Complementary NF for Freight - total non-recoverable taxes |
| 128 | Complementary NF Request - total non-merchandise cost exclusive of taxes |
| 129 | Non-recoverable Taxes for transfers for source location |
| 130 | Recoverable Taxes for transfers for source location |
| 131 | Non-recoverable Taxes for transfers for destination location |
| 132 | Recoverable Taxes for transfers for destination location |
| 133 | Positive Deal Income for merchandise fixed and complex deals |
| 134 | Negative Deal Income for complex deals |
| 135 | Deal Income for non-merchandise fixed deals |
| 136 | ICMS non-recoverable Taxes when product moves into ICMSST regime |
| 137 | ICMSST And ICMSSTE taxes when product moves into ICMSST regime |
| 138 | ICMS non-recoverable Taxes when product moves out off ICMSST regime |
| 139 | ICMSST And ICMSSTE taxes when product moves out off ICMSST regime |
| 140 | Complementary NF for Cost/Tax - tax exclusive cost correction |
| 141 | Complementary NF for Cost/Tax - total recoverable taxes correction |
| 142 | Complementary NF for Cost/Tax - total non-recoverable taxes correction |
| 143 | Recoverable Taxes for NEGATIVE Inventory Adjustment |
| 144 | Non-Recoverable Taxes for NEGATIVE Inventory Adjustment. |
| 145 | Total merchandise cost exclusive of taxes for NEGATIVE Inventory. |
| 146 | Recoverable Taxes for POSITIVE Inventory Adjustment. |
| 147 | Non-Recoverable Taxes for POSITIVE Inventory Adjustment. |
| 148 | Total merchandise cost exclusive of taxes for POSITIVE Inventory Adjustment. |
| 150 | Total de imposto FCP - ICMS-ST - retido em operação anterior. |
| 151 | Total de imposto FCP - ICMS - retido em operação anterior. |
| 152 | RTV NF - total non-merchandise cost exclusive of taxes. |
| 161 | Total merchandise retail exclusive of taxes |
| 162 | Total tax values on the transfer for customer order delivery |
| 163 | Total non-merchandise cost exclusive of taxes (Delivery charges) |
| 164 | NF-RTV Non-recoverable taxes not included in RTV NF |
| 165 | NF-RNF Non-recoverable taxes not included in Return NF |
| 166 | Tax Variance posting for RMS-RFM balance |
| 167 | Reduced ICMS Tax Value for sales or transfers done to a free zone |
| 168 | Recoverable values posting for Simples Supplier |
| 169 | Recoverable values posting for RTV to a Simples Supplier |
| 170 | Total merchandise cost for Direct Import NF exclusive of taxes |
| 171 | Total non-recoverable taxes for Direct Import NF. |
| 172 | Total recoverable taxes for Direct Import NF. |
| 173 | Total non-merchandise cost exclusive of taxes for Direct Import NF. |
| 180 | Total merchandise cost exclusive of taxes for RMA. |
| 181 | Total recoverable tax values for RMA. |
| 182 | Total non-recoverable tax values for RMA. |
| 183 | Total non-merchandise cost exclusive of taxes for RMA. |
| 192 | Value of ICMS-DIFAL to be paid for the Addressee State. |
| 193 | Value of ICMS FCP to be paid for the Addressee State. |
| 194 | Value of ICMS-DIFAL to be paid for the Sender State. |
| 200 | Total merchandise retail exclusive of taxes for sale NF future delivery customer order (backorder = Y). |
| 201 | Total tax values for sale NF future delivery customer order (backorder = Y). |
| 205 | Total merchandise retail exclusive of taxes for sale NF future delivery customer order (backorder = N). |
| 206 | Total tax values for sale NF future delivery customer order (backorder = N). |
| 210 | Total merchandise retail for shipment NF future delivery customer order. |
| 211 | Total tax values for shipment NF future delivery customer order. |
| 212 | Total non-merchandise cost exclusive of taxes for shipment NF future delivery customer order (Delivery charges). |
| 213 | Recoverable Taxes for SALES for source location (Future Delivery only). |
| 214 | Recoverable Taxes for SALES for source location. |
| 215 | Return TSF Non-recoverable taxes not included in RTSF NF. |
| 220 | Cost exclusive of Taxes - Difference between nominal and received weight for Catch Weight items. |
| 221 | Non-recoverable Taxes - Difference between nominal and received weight for Catch Weight items. |
| 222 | Recoverable Taxes - Difference between nominal and received weight for Catch Weight items. |
The system administrator must set up Chart of Accounts in FM_COA_SETUP table.
The system administrator must set up the entities that are dynamic in nature in FM_GL_OPTIONS table.
The system administrator 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.
The system administrator must set up account setup for chart of account in FM_ACCOUNT_SETUP table.
The system administrator must set up GL cross reference in FM_GL_CROSS_REF table. You can also achieve this through the GL Cross reference form.
When creating RTV NF with Balance Control enabled (FM_SYSTEM_OPTIONS.VARIABLE = 'BALANCE_CONTROLE_RTV' = 'Y'), the process gets 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.
The system can be configured to manage the moment when the transferred inventory changes ownership during transit inventory in transfers, including allocations. This moment would occur at "Time of Shipment" or "Time of Receipt".
The ownership is characterized by the definition of where the stock is in two aspects: physical and financial, that is, whether the in-transit inventory is part of the total inventory of location A or B, as well as the financial postings that will reflect, from an accounting perspective, where the inventory is.
In "Time of Shipment", when shipment occurs, the inventory is moved from the 'on hand' bucket at source to an 'in transit' bucket at destination and the financial postings happen to change ownership. At this point, this inventory already belongs to the destination location which justifies the recalculation of WAC for the transfer at that point in time. Being part of inventory at destination, it is also considered for WAC calculations in other receiving that may happen while the transfer is not yet physically received.
In "Time of Shipment", when shipment occurs, the inventory is moved from the 'on hand' bucket at the source to an 'in transit' bucket at the destination, keeping the view of in-transit currently posted for the destination location, but without posting the trancodes that would change ownership. In this case, the 'in transit' stock presented at the destination location will be taken as expected inventory to be received at some point, but not being part of destination location's total inventory from an accounting perspective. This 'expected' inventory will continue being considered in replenishment processes.
While the 'in transit' view will continue demonstrating what is expected at the destination location, it is necessary to have a new bucket created for the source location with the information of 'shipped' inventory, keeping the stock ledger position in-sync with the perpetual inventory.
With the proposed change, the in-transit bucket will continue being displayed for the destination location and considered for replenishment processing. However, it will NOT be considered for WAC updates as, in this scenario, it still belongs to the source.
In the same way, the 'shipped' bucket will be displayed for the source location but will also not be considered for WAC updates. The expectation in this case is that this is an inventory not expected to return, and hence shouldn't be accounted for WAC updates.
From an accounting perspective at source, at time of shipment, trandata will be posted, demonstrating the inventory moving from source 'on hand' bucket to source 'shipped' bucket.
This behavior is controlled by system option that can change the system behavior of change ownership at shipment or at receiving.
This system option is located in the System Parameter Maintenance Window, in tab Inventory.
When this option is selected, it indicates that WAC updates will happen after receiving a transfer.
At the time of shipment, trancodes 30/32 (for regular transfers) or 37/38 (for intercompany) are posted, considering the quantity shipped and the transfer cost. These codes represent the transfer of ownership of the inventory in a transfer.
At the time of receiving, these trancodes will be posted only at time of receiving. During the time the transfer is in-transit it is necessary to have the accounting system aware that inventory is not on-hand, but it is in the 'shipped' bucket still belonging to the source. For this specific transaction, codes exist to handle it.
Tran Code 45 - Data warehouse outbound transfer shipment. This trancode is posted for the source location at the time of shipment, with the item quantity shipped and the transfer cost used (WAC of source). This trancode is informational and represents the movement of inventory from the 'on hand' to the 'shipped' bucket.
Tran Code 46 - Data warehouse outbound transfer shipment received. This trancode is posted for the source location at the time of receiving with the same values posted for destination location with trancode 44. This trancode is informational and will represent the movement from 'shipped' bucket out of source location's inventory.
