This chapter covers the following topics:
Setup and implementation of Oracle's movement statistics solution is only possible through one of the two following Oracle applications:
You only need to setup Movement Statistics in either Oracle Inventory or Purchasing. You do not need to perform the setup in both applications.
See: Oracle Inventory User's Guide or Oracle Purchasing User's Guide for additional information.
The general process flow for setting up Oracle Movement Statistics. This process flow may be used in either Oracle Inventory or Oracle Purchasing. Once you have implemented movement statistics, you will be able to track movement of material across borders, including INTRASTAT and EXTRASTAT.
Define Category Set: Define a Commodity Code Category Set and assign commodity codes to items.
Define Economic Zone: Define the economic zones in which you conduct business and where you want to track movement transactions.
Define Validation Rules: Define Validation Rules to validate the entry of movement transactions and to properly report the information.
Define Parameters: Define Movement Statistics Parameters to specify the rules for gathering movement statistics.
One of the requirements of movement statistics is to group goods into commodity codes. For example, the European Union requires that you classify your goods by using the appropriate commodity code in the INTRASTAT Classification Nomenclature (ICN). The INTRASTAT commodity codes are predefined codes which uniquely identifies a class of products. The Commodity Codes are taken from the INTRASTAT Classification Nomenclature (ICN) which is common to all EU countries.
With Oracle's movement statistics solution, you use categories and category sets to group the goods you will be transacting into the correct commodity codes. Oracle defines a category as a logical classification of items that have similar characteristics. A category set is a distinct grouping scheme and consists of categories. You may set up categories and category sets in either Oracle Inventory or Oracle Purchasing.
Using either Oracle Inventory or Oracle Purchasing, you must define the flexfield structures, categories and category set for the commodity codes (refer to the respective user guides for additional information on these topics). Once you have completed this, use the Movement Statistics Parameters form to assign the category set to an economic zone (refer to the Define Movement Statistics Parameters section of this chapter).
Define Categories / Category Sets
Define Flexfield Structure
Define a Validation Set flexfield structure for Intrastat.
Define Category Codes
You should be using the flexfield structure name that you created in Step 1. Enter the Intrastat Classification Nomenclature (ICN) commodity codes that you will be using. Each commodity code will be a separate category.
Define Category Set
Create the Intrastat category set:
Name: Intrastat
Description: Intrastat Commodity Codes
Flexfield Structure: Intrastat
Controlled At: Master Level
Default Category: Select one of the Category Codes you created in Step 2.
Assign Items to Category Codes
Assign your items to the Category Codes. Click Assign to do this.
Note: You should assign your items to category codes in the Master Item Organization only.
Assign Category Set to an Economic Zone
The Category Set that you have defined must be assigned to the Economic Zones that you will be using. You assign the Category Set in the Movement Statistics Parameters form.
You use the Economic Zones form to define the economic zones where you conduct business. The Economic Zone form enables you to add and remove the countries that make up an economic zone. You may create any number of economic zones. For example, the European Union and the North American Free Trade Association (NAFTA) are economic zones.
Economic zones are used for gathering, reviewing, and reporting statistical information associated with material movements within the specified zone. Oracle's movement statistics solution uses this information to determine which material movement transactions take place in a reporting jurisdiction.
Oracle's movement statistics solutions provides a pre-seeded (pre-loaded) Economic Zone:
European Union (EC)
Movement Statistics Economic Zone Window
Economic Zone Definition Process
Verify economic zone: Movement Statistics provides a pre-seeded (or pre-loaded) Economic Zone. This step verifies that the European Union Economic Zone has been loaded.
Add additional economic zones: Add additional economic zones (other than the pre-seeded zones) as required.
Note: You can associate a country with more than one economic zone.
Update economic zones: Update an existing economic zone (add or remove countries) as required.
You use the Movement Statistics Validation Rules form to define and maintain the following rule types:
Attribute Property Validation Rules: used to validate movement transactions in order to properly report transaction information
Alternate Unit of Measure (UOM) Rules: used to set up alternate units of measure to the default unit of measure
Oracle's movement statistics solution provides a pre-seeded (pre-loaded) attribute property validation rule set called Standard_Validation. You may also define you own validation rule.
There is no pre-seeded Alternate UOM. If you require Alternate UOM Rules, you must define your own.
Whether you define your own validation rules or use the pre-seeded one, you use attribute property validation rules to specify what data is required for your specific reporting needs.
Oracle's Validation Rules and Exception Report work together: if required data is missing or incorrect (as specified by a validation rule) an exception will be raised and listed on the Movement Statistics Exception Report.
Movement Statistics Validation Rules Window (for Attribute Property Rules)
Movement Statistics Validation Rules Form (for Alternate UOM Rules)
Define the Attribute Property Rule Set: Optionally, define a new attribute property rule set.
Note: A pre-seeded Attribute Property rules Set name : Standard_Validation is provided.
you do not need to perform this step if you plan to use the pre-loaded rule set.
Define the Alternate UOM Rule Set: Define the Alternate UOM Rule Set.
Note: There is no pre-seeded Alternate UOM rule Set.
You use the same window to define the Attribute Property and the Alternate UOM
Use the Movement Statistics Parameters form to define and maintain the parameters for gathering movement statistics. The parameters that you define are used by the Movement Statistics Processor to collect movement transaction data and create movement statistics records.
The Movement Statistics Processor captures and report movement statistics by legal entity. You are required to define Movement Statistics Parameters for every legal entity to capture statistics.
You use two forms for defining and maintaining Movement Statistics parameters:
Movement Statistics Parameters form
Movement Statistics Parameters Form
Statistics Type Usages form
Movement Statistics Statistical Type Usages Form
Define Movement Statistics Parameters Process
Define the legal Entity Economic Zone Assignment (required): You must assign the Economic Zones to the Legal Entities where you plan to capture movement statistics data.
Note: You must assign an economic zone to every legal entity you use.
Define the Legal Entity Economic Zone parameters: Define the specific usage types, statistical types, and other parameters for the Legal Entity Economic Zones.
Note: You must assign parameters for all Legal Entity Economic Zone pairings you define.
Select a value for the Returns Processing field. Returns processing determines if you want to aggregate return movement transactions within a reporting period:
Aggregate Returns: If you select this option, the movement statistics processor will:
Aggregate sales order shipments with customer returns within a period (if the sales order shipment has not been declared). If the sales order shipment has been declared, customer returns will not be aggregated.
Aggregate purchase order receipts with return to vendor (if the purchase order receipt has not been declared). If the purchase order receipt has been declared, returns to vendor will not be aggregated.
Separate Returns (default value): If you select this option, the movement transactions will not be netted. A separate movement record will be created for all source types, including purchase orders, return to vendor, sales orders, and customer returns.
Note: Additional Notes for Aggregate Returns
For Customer Return (RMA) transactions, unless you enter the sales order reference number and order line number information on the return order line, the RMA and corresponding Sales Order will not be aggregated. A separate movement record with negative movement amount, quantity, and invoice of type dispatch adjustment will be created for the customer return movement transaction.
Arrival movement records (with a source type of purchase order) and a movement status of Open, Verified, or Ignore will be aggregated with return to vendor transactions that occur within the same period.
Movement records with a status of Frozen, Export, or EDI will not be aggregated. For example, if the arrival movement record has a status of Frozen and a return to vendor transaction is processed, the return will not be aggregated with the arrival movement record. The processor will create a separate dispatch movement record.
Dispatch movement records (with a source type of sales order) and a movement status of Open, Verified, or Ignore will be aggregated with customer return transactions that occur within the same period.
If the return transaction does not occur in the same period as the original arrival or dispatch, a separate adjustment movement record with negative movement amount, quantity, invoice amount and invoice quantity will be created
Example of Aggregate Returns
The following example illustrates the consequence of aggregating movement transactions:
Within the same reporting period, the following movement transactions take place:
A movement based on a receipt transaction of ten units of item A, priced at $6/each and invoiced at $60 is processed by the movement statistics processor.
A movement based on a return to vendor transaction of one unit of item A and invoiced (credit memo) at $6 is processed by the movement statistics processor. Theses transactions are aggregated resulting in: one movement record with a net movement amount of $54 and a net movement quantity of nine units and net invoice of $54.
Example of Separate Returns
In separate reporting periods, the following movement transactions take place:
A movement based on a receipt transaction of 10 units of item A, priced at $6/each and invoiced at $60 is processed by the Movement Statistics Processor in Period 1.
A movement based on a return to vendor transaction of 1 unit of item A and invoiced (credit memo) at $6 is processed by the Movement Statistics Processor in Period 2
The Movement Statistics Processor will not aggregate these transactions:
One arrival movement record with a movement amount of $60, and a movement quantity of 10 units and invoice of $60 in Period 1.
One dispatch movement record with a movement amount of - $6 and a movement quantity of -1 units and credit memo of -$6 in Period 2.
Note: The amount, quantity, and invoice will be negative.
The Economic Zone parameter defines the behavior of Oracle's movement statistics solution. You must define the parameters for every Legal Entity - Economic Zone pairing you have defined. The following parameters must be set:
Parameter | Possible Values | Comments |
---|---|---|
Usage Type | Internal External |
Internal: Movement of goods within countries of the specified economic zone External: Movement of goods from a country of one economic zone to a country outside the economic zone |
Statistical Type | Intrastat Extrastat |
Intrastat: Declaration of imports and exports within EC Extrastat: Declaration of import and exports between EC and countries external to EC |
Period Set | Period Set Name | Select a Period Set (from LOV) that reflects your reporting frequency (monthly, quarterly) |
Period Type | Period Type | Select a Period Type (from LOV) to use for reporting. Note that the calendar you use for statistical reporting purposes is independent of the accounting calendar for your organization's set of books. |
Start Period End Period |
Start Period End Period |
Assign the first period for which the Usage / Statistic type assignment is valid. Optionally, enter the last period for which this assignment is valid. |
Weight UOM | Weight Unit of Measure | Enter the default UOM. Note: INTRASTAT requires weight (mass) to be reported in KG |
Precision | 0 to 5 | Enter the number of decimals the total weight should be rounded to. The default value is 0 (zero) meaning the weight will be rounded to the nearest digit. |
Report Rounding | Possible values:
|
Set up how the calculated weight will be rounded:
|
Dispatch KIT Method | Possible values:
|
Indicates how movement records should be created for KIT dispatches:
|
Entity Branch Reference | Entity Branch Reference | Enter the name of the legal entity branch. Note: this reference is printed on the European Union INTRASTAT and EXTRASTAT declaration. |
Conversion Type | Conversion Type | Select the currency conversion type (from LOV) to use to convert foreign currency amounts to the functional currency of your organization's set of books. |
Conversion Option | Conversion Option | Select the conversion option (daily or last day of the period) to convert foreign to functional currency. |
Category Set | Category Set | Select the category set that you defined for the INTRASTAT Commodity Codes. Note: you must define category sets (see: Commodity Codes using Category Sets in this guide). |
Tax Office Code | Tax Office Code | Enter the Tax Office Code of the tax office to which your legal entity reports. |
Tax Office Location Code | Tax Office Location Code | Enter the Name for the tax office to which your legal entity reports. |
Attribute Rule Set | Enter the validation rule set code. | The default rule set is ‘Standard_Validation'. You may define your own rule set. |
Alternate UOM Rule Set | This parameter is optional. | You will need to define an Alternate UOM Rule Set. |
Triangulation Mode | Invoice Based Shipment Based |
Triangulation Mode determines how the Movement Statistics Processor will process Triangulation (drop-shipments): Invoice Based: the processor will process movement transactions based on the flow of the invoice Shipment Based: the processor will process movement transactions based on flow of goods See: Triangulation Support in the following section of this chapter. |
Reference Period | Shipment Based Invoice Based |
Shipment Based: the date that the transaction took place Invoice Based: the date the transaction was invoiced Refer to the Reference Period section in this chapter |
Advance Invoice Days | User Defined | The number of days the processor should look for an advance invoice |
Pending Invoice Days | User Defined | The number of days the processor should look for an invoice in the period following the movement transaction |
Oracle's movement statistics solution supports triangulation. This section will:
Review Oracle's movement statistics solution support of triangulation
Define triangulation using examples to illustrate triangular trade transactions
Describe the setup for making triangular trade declarations
Oracle's movement statistics solution supports triangular trade with the concept of ‘triangulation mode.' Triangulation mode specifies how the Movement Statistics Processor analyzes and generates movement statistics records when it encounters a triangular trade transaction. You must determine how you will report triangular trade transactions by setting this parameter. There are two possible values for the Triangulation Mode parameters:
Invoiced Based
Shipment Based
The default Triangulation Mode parameter is invoiced based.
Invoiced Based - the Movement Statistics Processor creates movement statistics records based on the issue of an invoice only. A movement record will be created for the invoice and not for the physical movement of goods.
Shipment Based - the Movement Statistics Processor creates movement statistics records based on the movement of goods only. The invoice will not result in a movement record.
This section will define triangulation using the following examples:
Transaction between three trading partners in three countries
The resulting movement records created, based on both Shipment Based and Invoiced Based Triangulation Modes, will also be described.
The example used here is a simple triangular trade transaction. Many variations are possible, including, but not limited to:
Transactions involving trading partners in countries within an economic zone
Transactions involving trading partners in countries outside an economic zone
Transactions between trading partners in two countries
Transactions between four trading partners in three countries
Note that the countries used in the examples are for illustration purposes only, you may substitute any country of your choosing.
For the purposes of defining triangular trade the following triangulation example will be used:
Your Company is located in Italy and using Oracle's movement statistics solution
Your Supplier is located in Spain
Your customer is located in France
The following triangular trade takes place:
Your customer in France places an order with you in Italy.
You source the order from Spain.
Spain ships directly to your customer in France (goods are not shipped to Italy but directly from Spain to France).
The triangular trade results in the following transactions:
You send a sales order to your customer in France
You invoice your customer in France, creating the receivable
You create a purchase order for your supplier in Spain
Supplier in Spain sends you an invoice, creating the payable
Spain creates a shipment to France, satisfying the sales order
Two movement records are generated by the Movement Statistics Processor, when run in Italy, based on the Invoiced Based Triangulation Mode parameter, as follows:
Sales Order (dispatch) record from Italy to France
Movement Amount: zero (no movement of goods took place between these countries
Movement Quantity: zero (no movement of goods took place between these countries
Extended Value: calculated as the invoice quantity multiplied by invoice price
Dispatch Country: Italy
Destination Country: France
Triangulation Country: Spain
Purchase Order (arrival) record in Italy from Spain
Movement Amount: calculated as the receipt quantity multiplied by unit price
Movement Quantity: zero (no movement of goods took place between these countries
Extended Value: is calculated as the receipt quantity multiplied by unit price
Dispatch Country: Spain
Destination Country: Italy
Note: France is required to declare an arrival of goods from Spain, however, running the movement statistics processor in Italy will not generate the arrival record in France.
No movement records are generated by the Movement Statistics Processor, when run in Italy, based on the Shipment Based Triangulation Mode parameter.
Since no physical movement of goods occurred in Italy, a movement record will not be created.
Note: France is required to declare an arrival of goods from Spain, however, running the movement statistics processor in Italy will not generate the arrival record in France.
You define which triangulation mode to use in the Triangulation Mode parameter. This parameter is located on the Oracle Movement Statistics Parameters form.
During initial setup, you specify the Triangulation Mode to use, either Invoice Based or Shipment Based. The default Triangulation Mode is Invoiced Based. Once this parameter has been set, it is strongly suggested that you do not modify it.
It is strongly suggested that once you have set the Triangulation Mode parameter that you do not modify it.
If it is necessary for you to modify the Triangulation Mode parameter, you should consider the following:
modifying the Triangulation Mode parameter will not modify existing movement records. The parameter selected takes affect from the moment it is selected and is not retroactive to movement records previously created.
consider that changing parameters during an open reporting period will result in a mix of movement records: some records will be created using the ‘Invoiced Based' Triangulation Mode parameter and other set of records will have been created using the Shipment Based parameter.
This section reviews the concept of Reference Period as it is implemented with Oracle's movement statistics solution, including:
Overview and Definition of Reference Period
Overview of Oracle's Reference Period Functionality
Reference Period Process Flow
Implementing Reference Period
Using Reference Period Rules and Expected Results
The European Union has defined reference period as “the calendar month during which value added tax has become due for the intracommunity transactions to be recorded. The Member States may adapt this definition of the reference month to the particular tax rules applicable.” (Article 2 of Commission Regulation (EEC) No 3590/92)
“In those Member States where the periodic statistical declaration is the same as the periodic tax declaration, the provision relating to the transmission of the statistical declaration shall be drawn up in line with Community or national tax regulations” (Commission Regulation No 3046/92).
Since, tax regulations differ between Member States, the interpretation of the reference period is not consistent and varies throughout the European Union.
For example, in the UK, the rules for assigning the reference period are as follows:
No invoice is issued (or received) - Reference date is the 15th of the month following the movement of the goods.
A tax invoice is issued more than one month prior to the dispatch of the goods - Reference date is the date of arrival / dispatch.
An invoice is issued less than one month prior to the dispatch of the goods and before the 15th of the month following arrival / dispatch - Reference date is the date of invoice.
If the invoice is not received by the 15th of the following month - Reference date becomes 15th of the month following arrival / dispatch.
From: Notice 60, The Intrastat General Guide UK
In France, the general rule for reference period is:
for shipments, the month during which VAT becomes due for payment in the other member State as a result of the corresponding arrival
for arrivals, the month during which VAT becomes due for payment in France. Tax becomes due on the 15th day of the month following the movement of goods or the invoice date if the invoice is issued before the 15th of the month following the movement of goods. Only invoices issued after the movement can determine the eligibility date.
From: La Periode de Reference, Texte n 01-12/o.14 (French Intrastat Guide)
And in Denmark,
the reference period is generally the month in which the goods are received or shipped - regardless of the invoice date.
If the invoice is not received or sent until after the deadline for the submission of the INTRASTAT declaration, the declaration of the specific movement of goods may be postponed until the following month.
From Danmarks Statistik Intrastat Guide
Oracle's Reference Period solution is based on setting the Reference Period Rule Parameter. With the Reference Period Rule Parameter, you select one of the following Reference Period Rules:
Shipment Based: the Movement Statistics Processor will use the date that the transaction took place as the reference period (note this is the default Reference Period Rule):
For a sales order, the date the order was shipped is the reference date.
For a purchase order, the date the PO was received.
Invoice Based: the Movement Statistics Processor will use the date that the transaction was invoiced as the reference period.
Reference Period Process Flow
The general process flow for implementing and using Oracle's Movement Statistics Reference Period solution.
Set the Movement Statistics Reference Period parameters
Using the Movement Statistics Parameters form, select a Reference Period Rule:
Shipment Based
Invoiced Based
Shipment Based Reference Period Rule Parameter
This is the default Reference Period Rule. To use this rule, select it from the LOV on the Movement Statistics Parameter form.
Invoiced Based Reference Period Rule Parameter: To use this Reference Period Rule you must also set two additional parameters:
Advance Invoice Days
Pending Invoice Days
Run the Movement Statistics Processor: Based on the Reference Period Parameter, the Movement Statistics Processor will create records with the following status:
Shipment Based Reference Period Rule: Shipment Based Reference Period Rule: the reference date is based on the date of the transaction and the record is assigned a status of OPEN
Invoiced Based Reference Period Rule: Invoice Based Reference Period Rule: the reference date is based on the date of the invoice and if the invoice is missing, the record will be assigned a status of PENDING; if an invoice is available, the record is assigned a status of OPEN. All records with a status of PENDING will be reprocessed every time the Movement Statistics Processor is run (until the status is updated to OPEN).
Run the Exception Report
Run the Movement Statistics Exception Report to validate your records in OPEN status and update the status to VERIFIED
This section reviews the setting up Reference Period Rules using the Movement Statistics Parameters form.
Note: please review and be familiar with the specific reporting requirements of your country when implementing Reference Period Rules.
You must set the Reference Period Parameters using the Statistical Type Usages form.
Statistical Types Usages Form
The Reference Period Parameter values determines how the Movement Statistics Processor assigns the reference date. There are two possible values for this parameter:
With this rule, the Movement Statistics Processor assigns the reference date based on the date the transaction took place (for both dispatches and arrivals). Note: this is the default Reference Period Rule.
With this rule, the Movement Statistics Processor assigns the reference date based on the invoice date (for both dispatches or arrivals).
The Invoice Based Reference Period Rule requires that two additional parameters be set:
Advance Invoice Days: this parameter specifies the number of days the Movement Statistics Processor and the Exception Report should search for an advance invoice (in the case where a transaction was invoiced before the movement transaction). The default value is 30 days, you may enter any whole number for this parameter. When the Advance Invoice Days parameter is set to 30, the Movement Statistics Processor will search for an advance invoice for 30 days prior to the date of the movement transaction.
The general rule for default Advance Invoice Days: if there is less than a 30 day difference between invoice date and transaction date, the invoice date becomes the reference date for declaration purposes.
For example (using the default Advance Invoice Days value):
Transaction Date | Invoice Date | Reference Date |
---|---|---|
June 25 | No Invoice | July 15 |
June 25 | June 1 | June 1 |
June 25 | June 20 | June 20 |
June 25 | May 1 | June 25 |
Pending Invoice Days: this parameter specifies the number of days the Movement Statistics Processor and the Exception Report should ‘wait' for an invoice after the start of the following period, if there is no invoice on the date of the movement transaction. The default value is 15 days, you may enter any whole number for this parameter. When the Pending Invoice Days parameter is set to 15, the Movement Statistics Processor will ‘wait' for an invoice for 15 days from the start of the period following the movement transaction.
The general rule for Pending Invoice Days if using the default of 15 days: if an invoice is not received by the 15th day of the month following the movement transaction, the reference date is the 15th day of that month.
For example (using the default Pending Invoice Days value):
Transaction Date | Invoice Date | Reference Date |
---|---|---|
June 25 | No Invoice | July 15 |
June 25 | July 16 | July 15 |
June 25 | July 10 | July 10 |
To change the Reference Period Rules, the status of all movement records in all periods must be set to FROZEN. You will not be permitted to change Reference Period Rules if this condition has not been met. A message on the Movement Statistics Details form will be displayed if you attempt to change Reference Period Rules before this requirement is met.
This section reviews the results you should expect, in terms of transaction date and movement record status, of using both the Reference Period Rules. The results are based on the following scenarios:
Advanced Invoice: transaction is invoiced in advance, prior to actual shipment or receipt transaction
Invoice after Transaction: transaction is invoiced after the shipment or receipt transaction takes place
This section describes the results of using the Shipment Based Reference Period Rule to determine the Reference Period.
The general rule governing Shipment Based Reference Period Rule: the date of the movement transaction is the date used to determine the period in which the transaction is reported on Intrastat Declarations.
The Reference Period is displayed as the Transaction Date on the Movement Statistics Details form.
When the Movement Statistics Processor creates movement records under the Shipment Based Reference Period Rule, the status of the movement record will be OPEN.
In a case where the transaction was invoiced in advance, the reference date is the date of the actual movement transaction. The reference period will always be the date of the movement transaction, with or without an invoice. For example, if a purchase order was received on June 10, but invoiced on June 2, the Reference Period is June 10 for Intrastat Declarations.
In the case of an invoice arriving 10 days after the movement transaction takes place, the reference date is the date of the actual movement transaction. The reference period will always be the date of the movement transaction, with or without an invoice. For example, if a purchase order was received on June 10, but invoiced on June 20, the Reference Period is June 10 for Intrastat Declarations.
This section describes the results of using the Invoiced Based Reference Period Rule to determine the Reference Period.
The general rules governing Invoiced Based Reference Period Rule (using the default Advance and Pending Invoice Days values) are as follows:
If no invoice is issued (or received), the reference date will be assigned based on the Pending Invoice Days parameter value. Using the default Pending Invoice Days value of 15 days, the reference date is the 15th of the month following the month in which the movement of goods took place.
If an invoice is issued prior to the movement transaction by more than 30 days (the default Advance Invoice Days parameter value), the reference date is the date on which the movement transaction took place.
If an invoice is issued prior to the movement transaction by less than 30 days (the default Advance Invoice Days parameter value), the reference date is the date of invoice.
If an invoice is received after the movement transaction, but less than 15 days (the default Pending Invoice Days parameter value) in the month following the movement transaction, the reference date is the date of the invoice.
If an invoice is received after a movement transaction, but more than 15 days (the default Pending Invoice Days parameter value) in the month following the movement transaction, the reference date is the 15th of the month following the month in which the movement of goods took place.
The reference date of a movement record is displayed on the Movement Statistics Details form as the Transaction Date.
This section reviews the movement status of records governed by the Invoice Based Rule parameters.
If there is no invoice, the Movement Statistics Processor will create a movement record with a PENDING status.
The status of the movement record will remain PENDING until one of the following conditions are met:
The movement transaction is invoiced. When the invoice is received, the status of the record will be updated to OPEN and the reference date will be determined by the Movement Statistics Processor based on either the Advance Invoice Days or the Pending Invoice Days parameter.
The time frame specified by the Pending Invoice Days parameter expires without the transaction being invoiced. When this occurs, the status of the record will be updated to OPEN. The reference date will be determined by the Movement Statistics Processor based on the Pending Invoice Days parameter.
Every time the Movement Statistics Processor is run, it will reprocess every movement record with a status of PENDING and continue to do so until either the movement record is invoiced or the Advance Invoice Days or the Pending Invoice Days criteria have been satisfied. Once all the criteria have been satisfied, the status will be updated to OPEN and the reference date updated appropriately.
In a case where the transaction is invoiced in advance, the Movement Statistics Processor will use the Advance Invoice Days parameter value to determine for how many days to search for an invoice prior to the date of the movement transaction.
To understand the use of the Advance Invoice Days parameter with advance invoices, please review the following example scenarios:
Scenario 1: Invoiced more than 25 days prior to movement transaction
The Advance Invoice Days parameter is set to 25 days
An advance invoice is created on June 1
A movement transaction occurs on July 15
The Movement Statistics Processor will search for an invoice between the dates of June 20 and July 15
The invoice does not fall within the Advance Invoice Days parameter value of 25 days but the transaction was invoiced
The reference date becomes the date of the transaction (July 15) and the movement record status is OPEN
In this case, because there was an invoice (although outside the Advance Invoice Days parameter value), the reference date becomes the date of the movement transaction
Scenario 2: Invoiced less than 25 days prior to movement transaction
The Advance Invoice Days parameter is set to 25 days
An advance invoice is created on June 30
A movement transaction occurs on July 15
The Movement Statistics Processor will search for an invoice between the dates of June 20 and July 15
The invoice is within the Advance Invoice Days parameter value of 25 days
The reference date becomes the date of the invoice (June 30) and the record status is OPEN
Scenario 3: No invoice
The Advance Invoice Days parameter is set to 25 days
No invoice is created
A movement transaction occurs on July 15
The Movement Statistics Processor will search for an invoice between the dates of June 20 and July 15
No invoice is found, either outside or within the Advance Invoice Days parameter value of 25 days
The reference date can not be determined at this time and the movement record status is PENDING
In this case, because there is no invoice, the Movement Statistics Processor will ‘wait' for an invoice based on the Pending Invoice Days parameter value
In the case of an invoice arriving after the movement transaction takes place, the Movement Statistics Processor will use the Pending Invoice Days parameter value to determine how many days to search for an invoice in the month following the month the movement transaction occurred.
To understand the use of the Pending Invoice Days parameter with invoices, please review the following example scenarios:
Scenario 1: Invoiced after the movement transaction, within the time frame specified by the Pending Invoice Days parameter
The Pending Invoice Days parameter is set to 20 days
An invoice is created on August 2
A movement transaction occurs on July 15
The Movement Statistics Processor will search for an invoice between the dates of July 15 through August 20
If the Movement Statistics Processor is run between July 15 and August 1, the status of the movement record will be PENDING' When the Movement Statistics Processor is run on or after August 2, the status of the movement record will be updated to ‘OPEN' and the reference date is the date of the invoice (August 2)
In this case, because the movement transaction was invoiced within the Pending Invoice Days value, the reference date becomes the date of the invoice
Scenario 2: Invoiced after the movement transaction, outside the time frame specified by the Pending Invoice Days parameter
The Pending Invoice Days parameter is set to 20 days
An invoice is created on August 25
A movement transaction occurs on July 15
The Movement Statistics Processor will search for an invoice between the dates of July 15 through August 20
If the Movement Statistics Processor is run between July 15 and August 20, the status of the movement record will be PENDING
When the Movement Statistics Processor is run on or after August 21, the status of the movement record will be updated to OPEN and the reference date becomes August 20
In this case, because the movement transaction was not invoiced within the Pending Invoice Days value, the reference date becomes the 20th of the month following the month of the movement transaction
Scenario 3: No invoice
The Pending Invoice Days parameter is set to 20 days
No invoice is created
A movement transaction occurs on July 15
The Movement Statistics Processor will search for an invoice between the dates of July 15 through August 20
If the Movement Statistics Processor is run between July 15 and August 20, the status of the movement record will be PENDING
When the Movement Statistics Processor is run on or after August 21, the status of the movement record will be updated to OPEN and the reference date becomes August 20
In this case, because the movement transaction was not invoiced, the reference date becomes the 20th of the month following the month of the movement transaction (as specified by the Pending Invoice Days parameter)
The following required setups directly impact the functioning of Oracle Movement Statistics. You should verify that the following setups have been performed in their respective Oracle Applications:
Item Weight
Exchange Rate
Delivery Terms
Note that these setups can not be performed from within Oracle's movement statistics solution. They must be performed in specific Oracle Applications, as defined below.
Intrastat regulations require that net weight (net mass) be reported. To report net weight correctly with Oracle's movement statistics solution, you must setup your inventory items with the net weight (not gross weight).
In Oracle Inventory, item weight is a Physical Attribute.
See: Oracle Inventory User's Guide.
Note: INTRASTAT requires net weight (or mass) to be reported in KG. If you define the item weight in a unit of measure other that KG, you must define a conversion between KG and your item's net weight unit of measure.
You must set up an exchange rate between every currency you transact in and your local currency.
See: Oracle Payables User's Guide or the Oracle Receivables User's Guide.
Within the EU, delivery terms (sometimes referred to as Incoterms by the International Chamber of Commerce (ICC)) are used to determine when the transfer of title takes place in a transaction where goods are bought or sold.
Delivery terms are required to perform Intrastat reporting. The current set of valid EU delivery terns are pre-seeded in Oracle's movement statistic solution. Additional delivery terms may be added as necessary.
Oracle's movement statistics solution determines the delivery term for a movement transaction from the Freight on Board (FOB) point of a transaction. If you enter a value for freight on board for a sales order, purchase order, or inventory transaction, the value entered will be validated by the Movement Statistics Exception Report.
Note: Oracle movement statistics automatically inserts the delivery term in the movement record based on the value that you entered in the FOB field in the Oracle Purchasing Supplier form or in the FOB field in the Oracle Order Management Customer form. You may also modify the delivery term on-line using the Movement Statistics Details form.
The following are the Delivery Terms used by Oracle's movement statistics solution:
EXW - ex works
FCA - Free Carrier
FAS - Free Alongside Ship
FOB - Free on Board
CFR - Cost and Freight (C&F)
CIF - Cost, Insurance, Freight
CPT - Carriage Paid to Agreed Destination
CIP - Carriage and Insurance Paid to Destination
DAF - Delivered at Frontier
DES - Delivered ex Ship
DEQ - Delivered ex Quay
DDU - Delivered Duty Unpaid
DDP - Delivered Duty Paid
XXX - Delivery terms other than the above
Any value that you enter will be validated against this list of Delivery Terms. If your Delivery Terms do not match one of the listed terms, an exception will be listed by the Exception Report.
Oracle's movement statistics solution enables you to adapt certain setup parameters in order to meet country specific reporting requirements. With this functionality, you are able to customize certain features to adapt to local regulatory rules. This flexibility permits you to:
Define customized Attribute Property Validation Rules
Define Alternate UOM Rules
Use the Call Out Program
Define additional Economic Zones
Define Attribute Property Rule Set
Oracle's movement statistics solution provides a pre-seeded Attribute Property Rule Set called ‘Standard_Validation.' The Standard_Validation Rule Set validates (and creates an exception) for following data fields for every Source Type:
If the ‘Standard_Validation' rule set does not meet your requirements, you may define your own Attribute Property Rule Set. Defining your own rule set will enable you to specify what movement statistics data you require, by Source Type, for your country's reporting needs. The rule set that you define will validate only the fields that you specify. Additionally, all the movement statistics attributes that you choose to validate will be displayed on the Movement Statistics Exception Report when an exception occurs.
To define Attribute Property Rules using the Validations Rule form:
Name your Attribute Property Rule Set.
For Rule Number assign a unique, non-repeating rule number.
Select a Source Types from the LOV.
Select an Attribute Name to associate with the Source Type from LOV.
Assign one of the following Attribute Rule Set Property combinations:
required / not updateable
not required / updateable
required / updateable
not required / not updateable
Select the Lookup Type from the list of values associated with your Attribute Property. A Lookup Type is defined using the using the Lookup form (refer to the Oracle Inventory User's Guide for additional information regarding defining Lookup Types).
Note: Once you have defined your new Attribute Property Rule Set, you will have to update the Movement Statistics Parameters with your new rule set. Refer to the 'Movement Statistics Parameters' section of this guide for additional information.
Please refer to the Appendix for a complete listing all Source Types and Attribute Names that may be used in a user defined validation rule set.
Copying an Attribute Rule Set
If you decide to use a ‘user defined' Attribute Property Rule Set, you may copy an existing Attribute Rule Set using the Copy Tool. The Copy Tool will copy any existing rule set. You may then modify the copied rule set to meet your requirements.
Using the Movement Statistics Validation Rules form, query an existing rule set.
Select the Tools option locate the Toolbar.
Select ‘Copy Rule Set.'
Enter the Rule Set Code and Rule Set Name for your rule set.
Save your rule set.
You may modify any rule as your requirements dictate.
Save your rule set and all modifications.
Assign your rule set to the Attribute Rule Set Parameter located on the Movement Statistics Parameter form. For your rule set to take affect, you must perform this assignment step.
Define Alternate UOM Rule Set
Alternate UOM rules permit you to report specific commodity code transactions in a unit of measure other than the default UOM.
Alternate unit of measure rules are used in conjunction with the default Weight UOM. You define a default weight UOM when you set up Movement Statistics Parameters. Every transaction will be reported in the default UOM you have specified.
If your reporting needs require that you report movement transactions in a unit of measure other than the default unit of measure that has been specified, you will have to define one or more alternative UOM in which to report. For example, your default UOM is kilograms. However your movement of goods declaration includes the transportation of diamonds. Instead of reporting diamonds in KG, you want to report them in carats. Using the Movement Statistics Validation Rules form, you would specify an alternate UOM for the commodity code in which diamonds falls.
Note that you define an alternate UOM for a commodity code and not an item.
Note: If you define an Alternate UOM rule set, you must assign the rule set in the Movement Statistics Parameters form.
Change the Rule Set Type to Alternate UOM.
Assign a rule number.
Select a Commodity Code from the LOV.
Select a UOM from LOV.
Update the Movement Statistics Parameters form with your new Alternate UOM Rule Set.
The Call Out program enables you to enter your own data values and overwrite any default value for fields in movement statistics records. It works like this: the Movement Statistics Processor 'calls' the call out program just before creating a movement statistics record. The data you have provided in the call out program will overwrite the specified data in the movement statistics record. The movement statistics record will then be created with the values that you specified in the Call Out Program.
Note: due to the technical nature of the Call Out Program, it is suggested that you work with your System Administrator when using this feature.
You may use the Call Out Program with the following attributes:
Transaction Nature
Delivery Terms
Statistical Procedure
Area
Port
CSA Code
Oil Reference
Container Type
Flow Indicator
Affiliation Reference
Taric Code
Preference Code
You may not use the Call Out Program with the following attributes:
Weight
Quantity
Monetary Amounts
The Call Out is a package, INV_MGD_MVT_DEF_ATTR, that enables you to overwrite any default value for any attribute of the movement statistics record. It is called by the Movement Statistics Processor before creating a new movement statistics record. The package is shipped with an empty procedure, Default_Attr. You customize the procedure Default_Att by replacing the empty procedure in the package body to introduce logic that allows to overwrite the default.
Using the Call out
The following outlines the procedure for using the Call Out. For the purposes of this example, the field 'Transaction Nature' will be used.
Use an editor to update the package 'INV_MGD_MVT_DEF_ATTR.'
Insert the value you require by replacing '<replace transaction_nature>' with your value in single quotes.
Remove the "--" in the beginning of the line you will be using.
Save your work.
In this example, you will use the Call Out to insert the value ‘10' for Transaction Nature (in every case).
First, locate the line ‘- - x_transaction_nature:= <replace transaction_nature>;
Second, update this line to read as follows:
‘- - x_transaction_nature := ‘10'
This code will result in the Transaction Nature being set to the value ‘10' in every movement statistic record created.
In this example, more complex logic is added to modify the value of Transaction Nature. The logic used in this example determines the Transaction Nature value based on a transaction type.
SELECT RCV.TRANSACTION_TYPE INTO l_txn_type FROM RCV_TRANSACTIONS WHERE TRANSACTION_ID = p_movement_transaction.rcv_transaction_id; IF l_txn_type= 'RECEIVE' THEN x_transaction_nature := '11'; ELSIF l_txn_type = 'RETURN TO VENDOR' THEN x_transaction_nature := '40'; ELSE x_transaction_nature := '99'; END IF;
This logic will result in the following:
You may define additional economic zones, other than the ones provided by Oracle's movement statistics solution.
Using the Economic Zone form, you can define additional economic zones where you conduct business. Once defined, new economic zones work the same as the pre-seeded economic zones.
Economic zones are used for gathering, reviewing, and reporting statistical information associated with material movements within the specified zone. Oracle's movement statistics solution uses this information to determine which material movement transactions take place in a reporting jurisdiction.
If you define new economic zones, you will be required to assign them to a legal entity. Refer to the Movement Statistics Parameters section of this chapter.