| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.1.3.1 E91382-02 |
|
 Previous |
 Next |
| Oracle® Retail Fiscal Management/RMS Brazil Localization Implementation Guide Release 14.1.3.1 E91382-02 |
|
Previous |
Next |
This chapter provides an overview of Oracle Retail Fiscal Management (ORFM).
The following topics are covered in this chapter:
ORFM manages Nota Fiscal (NF) processing through integration with Oracle Retail Merchandising System (RMS), Oracle Retail Warehouse Management system (RWMS), and Oracle Retail Store Inventory Management (SIM). In Brazil, before shipping any inventory out of the warehouse or store, it is mandatory to generate a Nota Fiscal to accompany the inventory movement. Similarly, prior to receiving physical inventory in a warehouse or store, it is mandatory to match the NF.
ORFM is integrated with RMS, RWMS, and SIM. Since ORFM and RMS share the same instance and database schema, ORFM can look up the RMS database tables and vice versa. For example, a purchase order (PO) or transfer created in RMS is directly accessible to ORFM while a supplier, location, or item level fiscal attribute that is set in RMS can be accessed by ORFM through direct database lookup. ORFM also integrates with SIM and RWMS using the Oracle Retail Integration Bus (RIB).
ORFM foundation data is divided into following sections:
System Setup
Fiscal Configuration
The ORFM System set up involves the following tasks:
System Options
Fiscal Number
Tolerances
Set up the ORFM system parameters, including the Default Utilization codes. The configuration settings control system behavior based on these values.
Navigate: From the Main menu, select Fiscal Management > System Setup> System Options > Edit. The Fiscal Management System Options window appears.
Use the Fiscal Number to set up minimum and maximum fiscal numbers allowed at a particular store or warehouse location.
Navigate: From the Main menu, select Fiscal Management > System Setup > Fiscal Numbers > Edit. The Location Fiscal Number window appears.
Specify the amount of cost and quantity variance allowed on a fiscal document when compared to actual requisition. You can add tolerances at the system level or at the supplier level.
Navigate: From the Main menu, select Fiscal Management > System Setup > Tolerances > Edit. The Tolerances window appears.
This functionality supports NF creations corresponding to various transaction types. For instance, PO, PO for Rural Producer, Transfer, Repairing, InterCompany Transfers, RTV, Return NF, Return Merchandize Authorization, Inventory Adjustments (Stock Out), Direct NF, Free Form NF, Sales NF, and Transfer Return NF.
Fiscal Configuration involves the following:
Fiscal Document Type
Fiscal Utilization Code
In Brazil, the movement of items need a document called fiscal document which is basically a financial document that details items, quantities, cost, retail, and taxes. Create and attach a Fiscal Doc Type (FM_DOC_T YPE_UTILZATION and FM_FISCAL_DOC_TYPE) to the fiscal document.
Navigate: From the Main menu, select Fiscal Management > Fiscal Configuration > Fiscal Document Types > Edit. The Fiscal Document Type window appears.
Use the Fiscal Utilization Code to identify the type of fiscal operation that is being carried out by fiscal document.
Navigate: From the Main menu, select Fiscal Management > Fiscal Configuration > Fiscal Utilization > Edit. The Fiscal Utilization Setup window appears. Click Add and enter fields such as Utilization ID, Description, Requisition Type, Nature of Operation, and Mode. Click Options menu to enter details for Doc Types, Parameters, and Reason Codes. Click OK. The Fiscal Utilization Setup window closes. The nature of operation codes are exported by Tax Rules.
For Brazil localized users, some of the RMS functionalities are not restricted by the system. Oracle Retail assumes that you will not use RMS specific functionality. For example, the RTV and Inventory Adjustment RMS features are not available for Brazil localized users.
ORFM/RMS Brazil localization has the following functional assumptions:
When you install ORFM, the RMS system indicator, AUTO_RCV_STORE, available on the RMS Supplier screen must be set to 'N'.
The Location-level security is not enabled in ORFM.
For EDI NF, if there are observations related to recoverable Imposto sobre Circulação de Mercadorias e prestação de Serviços (ICMS) and Imposto sobre Circulação de Mercadorias e prestação de Serviços-Substituição Tributária (ICMS-ST), they should appear as different fields. The system cannot parse the observations.
During discrepancy identification and resolution, the system always assumes the cost components on the Nota Fiscal are correct.
During discrepancy identification, the system compares discounted cost on the purchase order and discounted cost on the NF. Unit cost (non-discounted) and the discount values are not compared separately.
For triangulation purchase order flow, the NFs from both the suppliers should match in cost and quantity and should be entered in the system at the same time.
The taxes on the main NF and the delivery NF (complementary NF for triangulation) are mutually exclusive.
The system generates correction documents for both main and delivery suppliers.
If the purchase NF has taxes such as Imposto sobre Produtos Industrializados (IPI) and ICMS-ST that are added to the NF total, these taxes are embedded in the return to vendor (RTV) cost on the RTV NF.
Freight or any other cost component is not reversed on an RTV NF.
For triangulation purchase order flow, both the delivery and main supplier should be known when the purchase order is created.
If the stock being returned from a location was received at that location through a transfer, the system cannot track the last purchase NF and hence the RTV happens at Weighted Average Cost (WAC).
In Brazil, all movements of products from one location to another, or from a supplier to the retailer's location and vice versa, must be accompanied by a fiscal document called Nota Fiscal (NF). This document contains all the information related to the transaction such as, items, quantities, costs and retail values. It can be compared to a bill of lading (BOL) because it has the items and quantities. NF also has financial information such as the cost, so it can be compared to the invoice too. In addition, this document has all the taxation and fiscal information, which make the NF a unique document with all the related information. The management and processing of this document is closely linked to the business process flows of receiving, shipping, and all types of transactions that affect the inventory.
Once NF is created, it is validated and submitted for receipt. Once items are received, receipt information flows to Oracle Retail Management System (RMS). NF is validated against this receipt information and approved if there are no discrepancies. Possible discrepancies include cost, quantity, and tax. If there is any discrepancy in receipt it needs to be validated as either system purchase order (PO) or NF. Inventory and transaction updates are done in RMS only after NF is approved.
Nota Fiscal Eletrônica (NF-e) is a Brazilian government project tasked with the objective of implementing a national model of electronic fiscal documentation to replace the current system of issuing the fiscal documents in paper. The virtual document will have juridical validity guaranteed by the digital signature of the issuer. It will simplify the fiscal obligations of the taxpayers and will allow the follow-up of the commercial operations by the tax authority.The NF-e issuer will generate an electronic file with all NF information in a more detailed level than the regular NF. This file must be digitally signed to guarantee the integrity of the data and the authorship of the issuer. This electronic file that corresponds to the NF-e is transmitted by the internet to the Secretaria da Fazenda - Brazilian Tax Authority (SEFAZ) of the origin state of the issuer. The SEFAZ provides a pre-validation of the file and returns a receiving protocol (Authorization for Use), that will be necessary to the traffic of the goods.To follow the goods, a graphic representation of the NF-e will be printed. The Documento Auxiliar da Nota Fiscal Eletrônica - Auxiliary Document of the Electronic Invoice (DANFE) will be printed in a common paper, one copy that will have highlighted the access key for consultation of the NF-e in the internet, and a bidimensional bar code which will facilitate the capture and confirmation of information of the NF-e by the fiscal units.
The DANFE is not a Nota Fiscal, and does not replace the NF. It is an auxiliary document for consultation of the NF-e. It has the access code of the NF-e, which allows its owner to confirm the real existence of the NF-e in the Receita Federal Brasileira - Brazilian Federal Tax Authority (RFB) environment or the SEFAZ web site.
The Retail Tax Integration Layer (RTIL) is implemented as a Java Enterprise Edition application that exposes a Retail Tax Data Model API for calculating tax and hosts the associated tax service provider adapter(s). This layer forms the conduit between the Oracle Retail applications and the tax service provider. The Retail Taxation Integration Layer is responsible for the assembling and disassembling of the vendor specific data model to retail tax data model based on the configuration. RTIL is envisioned to host vendor-specific connectors which can communicate to the external third-party services with various protocols such as Enterprise JavaBeans (EJB), Java Message Service (JMS), Simple Object Access Protocol (SOAP), Hypertext Transfer Protocol (HTTP), or native Plain Old Java Object (POJO) based on the configuration. The subscribing application is not aware of the tax service provider. RTIL acts as a bridge between the subscribing application and third-party tax service provider.
The Tax Web Tax Rules aids retailers with multiple state operation, with a high level of complexity and large number of transactions, items and locations.
ORFM is integrated with the Tax Web Tax Rules to address all of the Brazilian tax legislation with a high level of exception treatments. For all flows in ORFM that need to have tax calculations, the Tax Web Tax Rules verifies that all taxes are applied considering the input parameters.
The following processes in ORFM/RMS use the tax calculation integration:
Inbound Nota Fiscal validationOutbound Nota Fiscal issuingPO tax breakdownItem creation
Refresh tax
Item fiscal reclassification
The Synchro Tax Engine aids retailers with multiple state operation, with a high level of complexity and large number of transactions, items and locations.
ORFM is integrated with the Synchro Tax Engine which is PL/SQL architecture to address all of the Brazilian tax legislation with a high level of exception treatments. For all flows in ORFM that need to have tax calculations, Synchro Tax Engine verifies that all taxes are applied considering the input parameters.
|
Note: ORFM Release 14.1.3 does not support Synchro tax engine integration. |
The following processes in ORFM/RMS use the tax calculation integration:
Inbound Nota Fiscal validationOutbound Nota Fiscal issuingPO tax breakdownItem creation
Refresh tax
Item fiscal reclassification
|
Note: You can configure the tax integration either with TaxWeb or Synchro during installation. |
Sistema Público de Escrituração Digital (SPED) or Public System of DigitalBookkeeping is the result of several efforts from the Brazilian government to modernize and increase the level of control over the fiscal transactions for all companies. It is based on a digital file that is transmitted periodically to the government through the internet. Similar to the NF-e, the file is digitally signed through specific programs that validate its format and content.The strategy adopted to address this requirement was to keep the transaction features in ORFM and the interface to the Fiscal Authority in Oracle's fiscal partners.To support this strategy, views and tables make available all information to the fiscal partner based on the fiscal movements.
