Open orders

• Contract site (field POHFCY)

Code of the site issuing the order (request for quote, purchase request, order, subcontract order etc.).
This field is mandatory. It is initialized by default by the purchase site associated with your function profile.
You can modify this code by selecting a code from the list of authorized sites.

• Contract no. (field POHNUM)

Each order has its own order number. It is used to identify it.

If the order sequence number is to be manually assigned, the user must also enter an order number. Where the order number sequence assignment is automatic, a number will be assigned at the end of the creation.

When a purchase order is copied, and it has an order date different from the current date, the user will be asked whether they wish to recalculate the prices and discounts according to the new order date.

• Revision no. (field REVNUM)

This is the last revision number entered for the open order. When a signed, printed order is modified and the PURREV setup activates the revision management, the user will be asked whether they wish the modification to generate a revision.
If this is the case, the previous values of the modified elements in the order will be added to the history and the revision number will be incremented.

• Supplier (field BPSNUM)

• field XBPRNAM

• Intercompany (field BETCPY)

This information cannot be modified and specifies whether the open order has the type inter-company. When the order concerns an inter-company supplier (site in a different company), an invoice can be generated.

• Intersite (field BETFCY)

This information cannot be modified and specifies whether the open order has the type inter-site. When the order concerns an inter-site supplier (site in the same company) it cannot be invoiced.

• Internal reference (field ORDREF)

Field used to stipulate the reference of the contract at the supplier's (not controlled in a table) or to mention a free internal reference.

• Date of contract (field ORDDAT)

It is initialized by default to the current date

• Sales site (field SALFCY)

This is the sales site associated with the inter-site supplier.

• Bill-by supplier (field BPSINV)

This field is used to enter the invoicing supplier code, initialized by default to the supplier code entered in the header.
The supplier can be another supplier chosen from the supplier table.

• field BPAINV

This field used to indicate an invoicing address code for the invoicing supplier.
By default, this is the address code defined in the order supplier record for the invoicing supplier. It is possible to choose another address code for the invoicing supplier.

• Pay-to (field BPRPAY)

This field is used to enter the paid supplier code, initialized by default to the supplier code entered in the header. The supplier can be another supplier chosen from the supplier table.

• field BPAPAY

This field used to indicate a payment address code for the paid supplier. By default, this is the address code defined in the order supplier record for the paid supplier. It is possible to choose another address code for the paid supplier.

• Project (field PJTH)

Use this field to enter a project code.
The management of this code depends on the value of the CTLOPPCOD - Mandatory project control parameter (TC chapter - MIS group).

• When it is set to No, the code can be selected freely.
• When it is set to Yes, an existence check is systematically applied to the entered project code.
  You can use the Selection icon to display the list of available projects.

The management rules of this field are based on the PJTSNGDOC - One project by document- parameter (TC chapter, MIS group).

• If the value of this parameter is Yes, the multi-project management is prohibited.
  The project code is always the same on the document header and on the lines.
  The project code you enter in the header is always used on the document lines and cannot be modified.
  In case of a document transformation, it is loaded with the project code of the lines of the first selected document and cannot be modified.
  Additional lines must have the same project code.
  If you do not enter a project code but the conditions are met for the automatic opening of the requirements window, then this window will display all the requirements that match the entered criteria. The requirements can relate to various project codes. If you click Include all, the project code of the first line is used to load the project code of the order: only the lines having the same project code as the first line are selected.
  If you modify the document header project code, this code is automatically used on all the lines.
  
• If the value of this parameter is No, multi-project management is authorized.
  In direct creation, the project code you enter in the document header is used to initialize the project code of the document lines.
  You can only modify the project code of lines when the following conditions are met:
  - the entry of this field is authorized by the entry transaction being used,
  - the product line is not subject to a delivery request.
  
  If you modify the header project code, a dialog box opens and suggests to transfer this code to the lines of the document, according to the following options:
• Yes : the project code is used on all lines, except from the ones that have already been subject to a delivery request.
• No : the project code is not transferred to the lines.
• Yes if same value : the project code is only used on the lines that have already been subject to a delivery request.

In creation mode, when no order line is entered, analytical dimensions are reinitialized according to the setup of default dimensions when the project code is modified.
In creation mode as well as in modification mode, if an order line has already been entered and the project code is modified, analytical dimensions are not reinitialized.

Inter-company specificities: : for an inter-site open order, the project code is automatically sent to the generated sales order line. However, it is not sent for an inter-company open order.

• Validity start date (field STRDAT)

Start date for the contract validity.

• Validity end date (field ENDDAT)

End date for the contract validity.

• Payment term (field PTE)

This information is initialized to the supplier entered in the order header. It is used to identify the supplier's payment method as well as the payment scheduling.
This information remains modifiable but is mandatory. When managing this table, it is possible to simulate the calculation rules that will be applied in entry mode.

• Settlement discount (field DEP)

The discount code is used to identify a series of discount and charge rates to be applied to a payment according to a number of early or late days with respect to the due date.
The discount code is initialized using the discount code of the invoicing supplier. It can still be modified.
Only a discount code consistent with the legislation and company group of the document site can be entered.
The general principles linked to the multi-legislation setup are detailed here.

Specificities linked to inter-companies: for an intercompany invoice generated from a sales invoices, the payment condition is intialized from the one of the sales invoice.

• Currency (field CUR)

Code of the currency in which the invoice prices and amounts are expressed. This field is initialized by default with the currency code of the BP record. This field is only modifiable in creation or copy mode.

• Rate type (field CHGTYP)

• Buyer (field BUY)

The buyer code is initialized by the user code and must be entered if the BUYFLT Filter by buyer parameter (chapter ACH, group AUZ) is set to Yes.

According to the transaction entry used, this field may be hidden. In this case, the user code is used as the default value.

From this field, the Actions icon gives access to the supplier's detailed address and can be used to select an alternative address for the supplier if necessary. This is the address to which the order document will be sent.

• Receiving site (field RCPFCY)

• Invoicing site (field INVFCY)

• Shipment site (field STOFCY)

This is the storage site code from which the customer is generally delivered. This site, which is controlled in the site table, must be identified as a warehouse.

This information can only be accessed if the order is of the inter-company or inter-site type. It is used to indicated which shipping site will be used by the sales company that the inter-site/inter-company supplier identified. It will then serve to initialize the shipment site for each line of the purchase order. It is mandatory in this context.

The shipment site is initialized by order of priority, as follows:

• usual shipment site defined in the delivery address identified by the receiving site previously calculated is used. It must belong to the supplier's company,
• site identified by the supplier if it is a warehouse site.

If after this search, the site is still not identified, you must then manually enter it. A control is applied to check if the entered site belongs to the same company as the supplier site and if the site is a storing site. The Actions icon is used to view all the sites available for selection.

Specificities linked to automatically-generated purchase orders: if the shipment site is still not identified after the execution of the previous steps, the shipment site is initialized using the first warehouse site found, in alphabetical order, in the list of storage sites for the company identified by the supplier.

When generating the corresponding sales order, the shipping site of the sales order header is equal to the site defined here.

• Delivery mode (field MDL)

This mandatory information is initialized by default to the supplier entered in the order header. It describes how the goods are transported. This information is used namely in the Exchange of goods declaration (Intrastat).
The transport method determined by the delivery method is shown on the order document.

From this field, you can directly enter a delivery method whose existence is controlled in the delivery method table or you can use the Actions icon to:

• select a shipment method from the table,
• create, according to the user's authorizations, a shipment method in the table.

Inter-company specificities In the case of an inter-company or inter-site order, the delivery method of the generated sales order is initialized to the delivery method entered in the purchase order if the delivery method is not entered in the ship-to customer. The ship-to customer for the sales order is determined by the delivery address identifying the receipt site for the purchase order.

• Carrier (field BPTNUM)

This is the carrier in charge of transporting the goods. It is initialized to the supplier's carrier entered in the order header. A selection window is used to choose another carrier.
It is also possible to access the carrier table if the user's authorizations allow it.

• Tax rule (field VACBPR)

This information is mandatory and is initialized to the tax rule associated with the supplier entered in the order header. It is used to define the tax rule to be applied to the order and is used to determine the tax codes to be used for the product lines. This information is controlled by the miscellaneous table "BP tax rules".

• Dimension type (field DIE)

This grid is used to enter or view the analytical allocations, based on the setup of the entry transaction of the contracts.

• Description (field NAMDIE)

This field repeats the title of the dimension type.

• Dimension (field CCE)

The setup determines whether the analytical dimensions can be modified. These are initialized in compliance with the default dimension setup.

In creation mode, if no order line has been entered and the project code is modified, analytical dimensions are reset based on the setup of the default dimensions.

In creation mode, as in modification mode, if an order line has been entered and the project code is modified, analytical dimensions are not reset.

• Signed (field APPFLG)

• Printed (field PRNFLG)

This information is used to identify if the open order has been printed. It cannot be printed until it is totally signed, or if there is no signature management or if the signature is automatic.

• Closed (field CLEFLG)

This information is not used in the open orders. An open order is due or not (validity date).

• Received (field RCPFLG)

This information is used to identify the situation of the open order from the perspective of the receipt of goods. The possible values are: 'No', 'Partially'.

• Invoiced (field INVFLG)

This information is used to identify the situation of the open order from the perspective of the receipt of goods. The possible values are: 'No', 'Partially'.

• Product (field ITMREF)

The entry of a product is mandatory, but it is possible to choose between entering the internal reference of the product in this field and entering the supplier reference in the next field. In these two cases, the existence of this reference is controlled in the Product record.
The entered product:

• must belong to a purchased product category,
• must be declared as active in the corresponding product record,
• must be managed by the buyer if the value of parameter BUYFLT - Filter by buyer (chapter ACH, group AUZ) is set to Yes.
  If a buyer code is not entered for the product or product-site, it means that this code applies to all potential buyers.
  

• Supplier product (field ITMREFBPS)

• Description (field ITMDES)

Main description of the product coming from the product record and that can be modified during entry.
In the case of a call for tenders, if the product does not exist in the product table, the description must be entered directly.

• field ITMDES1

This is the description translated into the supplier's language. This description will be transmitted with any modifications on the receipt to stock or on the supplier invoice. When an order comes from a purchase request or a request for quote, the translated description will be inherited from the original line.
This description will be printed on the order document. The product record can be accessed from this field using a tunnel.

• Major version (field ECCVALMAJ)

The major version number can only be accessed if the tracking of major versions is active at the level of the product setup (in the Management tab of the Product function, the Stock version field is set to 'Major'). If the versions preloading is activated at the product/suppliers level, or otherwise, at the product/order level, the last active major version is preloaded automatically. Otherwise, the last major version with the 'Stopped' status will be preloaded. It remains modifiable.

• Minor version (field ECCVALMIN)

The minor version number can only be accessed if the tracking of major and minor versions is active at the level of the product setup (in the Management tab of the Product function, the Stock version field is set to 'Major and minor'). If the versions preloading is activated at the product/suppliers level, or otherwise, at the product/order level, the last active minor version is preloaded automatically. It remains modifiable.

• Receiving site (field PRHFCY)

• Address (field FCYADD)

This is the default address code for the chosen receiving site. This address will be printed on the order document sent to the supplier.
From this field, you can select another address for the receipt site if multiple sites are defined.

• Location reference (field USEPLC)

Use this field to specify the consumption place for the carrier or to define an address complement.

Examples: Dock xx or Hall yy.

The place of consumption is written on the order document.

Inter-company specificities: for inter-company or inter-site orders, the consumption location is transferred to the generated sales order line.

• Shipment site (field LINSTOFCY)

This is the storage site code from which the customer is generally delivered. This site, which is controlled in the site table, must be identified as a warehouse.

This information can only be accessed if the order is of the inter-company or inter-site type. It is used to indicated which shipping site will be used by the sales company that the inter-site/inter-company supplier identified. It will then serve to initialize the shipment site for each line of the purchase order. It is mandatory in this context.

The shipment site is initialized by order of priority, as follows:

• usual shipment site defined in the delivery address identified by the receiving site previously calculated is used. It must belong to the supplier's company,
• site identified by the supplier if it is a warehouse site.

If after this search, the site is still not identified, you must then manually enter it. A control is applied to check if the entered site belongs to the same company as the supplier site and if the site is a storing site. The Actions icon is used to view all the sites available for selection.

Specificities linked to automatically-generated purchase orders: if the shipment site is still not identified after the execution of the previous steps, the shipment site is initialized using the first warehouse site found, in alphabetical order, in the list of storage sites for the company identified by the supplier.

When generating the corresponding sales order, the shipping site of the sales order header is equal to the site defined here.

• Validity start date (field XSTRDAT)

It is the validity start date for the product line. This date cannot be prior to the contract start date.

• Validity end date (field XENDDAT)

It is the validity end date of the product line. This date cannot be later than the end date of the contract.

• Purchase unit (field PUU)

This is the purchase unit defined for the product-supplier pair or for the products that do not exist in the Product-supplier record.
The product has two purchase units:

• purchase unit defined at the level of the unit product record,
• purchase unit linked to the supplier.

The purchase unit cannot be modified.

This unit is used as the default value when entering an order, subcontract order or receipt, with the supplier unit suggested in priority when the product-supplier record exists.
The purchase units are accessible depending on the type of category.
 Upon invoicing of a product, the product PUR is used.

• Planned quantity (field EXTQTYPUU)

This quantity cannot be less than the minimum quantity of the product - supplier record.
It will not be possible to request deliveries for quantities in excess of those o nes.

• Firm horizon (field FIMHOR)

• Period (field FIMHORUOM)

• Planning horizon (field FRTHOR)

Horizon for which the planned delivery requests must be carried out (based on a week, month or other unit).

• Period (field FRTHORUOM)

Unit of time in which the planning horizon will be expressed.

• Project (field PJT)

Use this field to enter a project code.
The management of this code depends on the value of the CTLOPPCOD - Mandatory project control parameter (TC chapter - MIS group).

• When it is set to No, the code can be selected freely.
• When it is set to Yes, an existence check is systematically applied to the entered project code.
  You can use the Selection icon to display the list of available projects.

The management rules of this field are based on the PJTSNGDOC - One project by document- parameter (TC chapter, MIS group).

• If the value of this parameter is Yes, the multi-project management is prohibited.
  The project code is always the same on the document header and on the lines.
  The project code you enter in the header is always used on the document lines and cannot be modified.
  In case of a document transformation, it is loaded with the project code of the lines of the first selected document and cannot be modified.
  Additional lines must have the same project code.
  If you do not enter a project code but the conditions are met for the automatic opening of the requirements window, then this window will display all the requirements that match the entered criteria. The requirements can relate to various project codes. If you click Include all, the project code of the first line is used to load the project code of the order: only the lines having the same project code as the first line are selected.
  If you modify the document header project code, this code is automatically used on all the lines.
  
• If the value of this parameter is No, multi-project management is authorized.
  In direct creation, the project code you enter in the document header is used to initialize the project code of the document lines.
  You can only modify the project code of lines when the following conditions are met:
  - the entry of this field is authorized by the entry transaction being used,
  - the product line is not subject to a delivery request.
  
  If you modify the header project code, a dialog box opens and suggests to transfer this code to the lines of the document, according to the following options:
• Yes : the project code is used on all lines, except from the ones that have already been subject to a delivery request.
• No : the project code is not transferred to the lines.
• Yes if same value : the project code is only used on the lines that have already been subject to a delivery request.

In creation mode, when no order line is entered, analytical dimensions are reinitialized according to the setup of default dimensions when the project code is modified.
In creation mode as well as in modification mode, if an order line has already been entered and the project code is modified, analytical dimensions are not reinitialized.

Inter-company specificities: : for an inter-site open order, the project code is automatically sent to the generated sales order line. However, it is not sent for an inter-company open order.

• Price list code (field PLI)

• Costing price (field PRIVLT)

• If a price list code is entered, this field is automatically loaded by the price list search with the price in use.  
  If no price list can be applied, the field is loaded based on the base price entered on the Purchase tab of the Product record. If this base price is not entered, the standard cost is applied, provided that the PURPRICE - Price by default standard cost parameter (ACH chapter, PRI group) is set to 'Yes'.
  
• If no price list code has been entered or if it has been deleted, this field recovers the price of the first line in the price list terms. If no line has been entered, the valuation price is set to 0.

• Description (field NAMCOA)

• Account (field LINACC)

These fields indicate the purchase accounting accounts. The charts of accounts that can be accessed depend on the account core model associated to the company of the movement. If these fields are not entered the account will be automatically determined by the accounting code for the product as a function of the setups for the PORD automatic journal.
The presence of this field depends on the entry transaction used.
If the field is not assigned the account will be determined automatically (upon invoice posting) by the accounting code of the product according to the setup of the PIHI automatic journal.

• Purchase type (field LINPURTYP)

The presence of this information depends on the transaction setup. The different product types are: 'Purchasing', 'Fixed assets' and 'Services'. The purchase type is initialized on the basis of the tax posting type associated with the GL account previously entered. The purchase type will be transmitted to the receipt or to the purchase invoice control.

• Validity start date (field POPSTRDAT)

This is the validity start date for the price list line.
If a price list code is entered, as soon as this field is accessed, a price list search is conducted with, as reference date, the price list end date + 1 of the previous line. If a price list is found, the corresponding line is generated.

• Gross price (field GROPRI)

This field contains the ex-tax unitary gross price. This field is loaded via a price list search or it is entered manually.

• field DISCRGVAL1

• Net price (field NETPRI)

• field CCE1

According to the setups, the analytical dimensions can be modified. They are initialized as defined in the default dimensions setups.

• QC (field QUAFLG)

This code is used to define whether the product must be controlled on stock receipt.
The setup defined in the Product category is used to initialize the level of control of the Product-site record and Supplier-product record.The level of stock control on the Supplier-product record represents the finest level of setup and is used to initialize the level of control by purchase order. 

• No control
  The control is defined according to the management rules. It can be modified manually.
• Non modifiable control
  The quality control is mandatory in stock receipt: only a 'Q' status can be entered.
• Modifiable control
  In a miscellaneous receipt into stock, the quality status is initialized to the value 'Q', modifiable by 'A' or 'R'.
  The quality control code can also be defined at the purchase order level.
  • If in the order the quality control is set to 'Yes', the quality control is mandatory and the receipt is made with one of the sub-statuses Q* defined in the product management rule for movements of receipt type.
    If no sub-status is defined, the status cannot be entered upon receipt.
  • If in the order the quality control is set to NO, the quality control is not mandatory.
    At the time of receipt, the default value of the suggested status is 'A' and it is possible to enter or select all the statuses defined in the rule for the management of the receipt type movement for the product.
• Periodic control 
  The control is automated according to the number of receipts for this supplier and this product. In that case, the stock status can still be modified upon receipt.

When the quality control code associated with the product or with the product-supplier combination has the Non-changeable control value, the field that corresponds to the order line cannot be accessed in entry mode, irrespective of the transactions setup.

This information will then be used at the receipt and cross-checked with the management rule defined for the product category and associated with the movement type Supplier receipt to determine the product status and to generate, if necessary, an analysis request.

• Intrastat increase (field EECINCRAT)

This field is subject to the Exchange of goods declaration (Intrastat).

This increase coefficient is used in the Intrastat declaration for the exchange of goods. It is used in supplier invoices and applied to the fiscal value of the product line to obtain the statistical value.
It is initialized by the increase coefficient entered on the Product-supplier record; otherwise, by the one of the Supplier record.

• Country of origin (field ORICRY)

The country code for the origin of the goods, initialized to the country code associated with the order supplier.
This field is used to indicate the country where the goods originated in the sense of EU customs rules on the origin.
For the INTRASTAT exchange of goods declaration, the EU country code field associated with this code in the country table is used.
For supplier returns this will be the destination country.

• No. (field INVDTA)

Number of the invoicing element identifying the associated amount (Charges, freight, packing, discount, etc.). The list of the invoicing elements is drawn up by cumulating the lists of the invoicing supplier and their price list structure. Other elements can be added to this list. Only those elements added to the initial list can be deleted

• Description (field INVDTALIB)

This is the short title for the invoicing element.

• % or amount (field INVDTAAMT)

These is the information related to the invoicing footer. This information comes directly from the invoicing elements present in the supplier record concerned by the order for those that are declared as present in the order footer
See the documentation on invoicing elements for further information.
It is possible to modify the values of the various invoicing elements already present and to add new ones.
Special features linked to the inter-company option
In the case of an inter-site or inter-company order, if the user wishes to use invoicing elements, it will be necessary to establish a correspondence between the Sales invoicing elements and the Purchasing invoicing elements. It is also possible to specify if the value of the invoicing elements initialized in the sales order comes from the invoicing elements of the customer record matching the purchase site for the order for the invoicing elements entered in the purchase order and inherited from the supplier invoicing elements matching the sales site.
 For further information, see inter-company setup.

• field AMTCODLIB

The system specifies whether the invoicing element is a percentage or an amount.
If it is an amount, the document currency is displayed.

• field ACC1

These fields indicate the purchase accounting accounts for the invoicing elements. The charts of accounts that can be accessed depend on the account core model associated to the company of the movement.
If these fields are not entered the accounts will be automatically determined by the accounting code for the invoicing element as a function of the setups for the automatic journal.
 The presence of these fields depends on the entry transaction used.

• Distribution (field DSP)

The allocation processing key entered in this field is used to load the associated dimension types. It is constituted of one to ten alphanumerical characters.
The allocation processing keys are used to automatically distribute the amount of a financials posting line on several analytical lines. This distribution is carried out according to weighting coefficients.
It can be modified directly in the invoicing element line.

• field PFICCE1

The setup determines whether the analytical dimensions can be modified. They are initialized as defined in the default dimensions setups.

In creation mode, when no order line is entered, analytical dimensions are reinitialized according to the setup of default dimensions when the project code is modified.

In creation mode as well as in modification mode, if an order line has already been entered and the project code is modified, analytical dimensions are not reinitialized.

• Minimum order (field WORDMINAMT)

This is the tax excl. amount below which supplier orders can be subject to a control (blocking, warning or no control).

The level of control for this amount is defined by the parameter POHMINAMT - Order min amount control (ACH chapter, AUZ group).

• Expected total (field TOTVLT)

• Ack. date (field OCNDAT)

Date of acknowledgement of receipt of the order by the supplier.

• Ack. ID (field OCNNUM)

Once the supplier has received the order, enter the acknowledgement ID provided by the supplier.
After entering this information, the contract lines which have not been assigned an acknowledgement ID are automatically updated with this number.

Inter-company specificities: For inter-company or inter-site contracts, the Order acknowledgement ID and date cannot be accessed and are initialized, when the sales contract has been generated, with the date and the number of the sales order. You can use the Actions icon available on the Ack. ID field to jump to the generated sales contract, provided you are granted the proper authorizations.

• Ack. notes (field OCNREM)

You can add two lines of comments on the acknowledgment of receipt.

• Incoterm (field EECICT)

The Incoterm codes, set by the International Chamber of Commerce, seek to standardize the terms the most used in the international commerce by defining the respective responsibilities of the seller and the buyer agreed upon on establishement of the sales contract by a unique word similarly understood throughout the world.

The Incoterm code, controlled in Incoterm table is used in the INTRASTAT file (Exchange of goods declaration). It can also be used to define the price lists.

• Incoterm town (field ICTCTY)

It is the city associated to some types of incoterm. For instance: FOB Le Havre. A selection window is used to choose a city listed in the system. It is however possible to enter a city that is not listed.

• Freight agent (field FFWNUM)

The forwarding agent field is used to identify a BP appointed by the consigner or the consignee to ensure the continuity of the carriage when the goods must undergo several successive carriage steps. The forwarding agent is controlled in the carriers table.

The forwarding agent and their address will be used in the Customs document file to declare the flows of goods between the address of the forwarding agent and that of the consignee or between the address of the forwarding agent and that of the consignee.

This can especially be the case when goods are exported and the customs statements are handled by a forwarding agent from another EU country. Customs documents must be filed for the good to be transferred in this other EU country.

• Forwarding agent address (field FFWADD)

This is the address code of the forwarding agent. It is initialized with the default address of the BP corresponding to the forwarding agent. This address is used to determine whether a Customs document must be filed for this flow.

• EU VAT no. (field EECNUM)

This is the VAT identification number of the BP. 

This European VAT number must be entered on all the invoices destined to or coming from the European Union. This number starts with two letters identifying the business partner country followed by a number depending on the country.

In France the number is comprised of FR, then 2 numbers identifying the tax office of the place where the company conducts its activities, followed by the Company tax ID no.(SIREN) of the company.

This information must necessarily be entered if the Company Registration number is set up as being mandatory for the country of the company.

• Intrastat transp. location (field EECLOC)

A transport location must be specified in the EU exchange declaration. It is combined with the Incoterm code in order to determine the delivery conditions referring to the sales contract terms that specify the respective obligations of the buyer and seller.

This information is not used in the French declaration.

• Intrastat transport mode (field EECTRN)

The transport method by which the goods are presumed to leave their national territory on shipment (export) or to have arrived in on receipt (import). This information is used in the Customs document file.

• Transaction nature (field EECNAT)

This is the economic information on the transaction carried out. The nature of the transaction is used in the Intrastat declaration.
This information is initialized using the physical flows where it can be modified. This information can also be accessed from some financial flows (sales invoices and credit memos).
The initialization of the nature of the transaction is carried out according to the setups of the comparison table for the Movement rules and natures, which is used to associate an EEC rule and an EEC transaction nature to each type of flow. This setup can be adjusted by rule, country and group of companies.

• Statistical rule (field EECSCH)

The EEC or statistical rules are used to specify the nature of the EEC transaction from a tax or statistical point of view. The EEC rule is used in the Intrastat declaration.
This information is initialized using the physical flows where it can be modified. This information can also be accessed from some financial flows (sales invoices and credit memos).
The initialization of the nature of the transaction is carried out according to the setups of the comparison table for the Movement rules and natures, which is used to associate an EEC rule and an EEC transaction nature to each type of flow. This setup can be adjusted by rule, country and group of companies.