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 you copy a purchase order and its order date is different from the current date, a messages suggests that you 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)

The supplier code entered must meet particular conditions: be active and not of the prospect type. From this field, you can:

• directly enter the supplier code whose existence is checked in the Suppliers file,
• click the quick Supplier selection from the Actions icon to:
• Select a supplier from the file;
• Create a supplier in the file (according to the user's access rights);
• View the notes linked to the supplier.

When the supplier entered is of the type "Miscellaneous", a window automatically opens for the entry of the address. When the entered supplier is of the 'Normal' type, you can view and potentially modify the address from the Actions icon, since the supplier code has been entered.

Following the entry of the supplier, a message is displayed when the supplier is declared "on-hold". This can be a blocking message or a simple warning according to the value given to the dispute code in the supplier record. 

In order duplication, changing suppliers is not authorized.

Case of inter-site reorder contracts: You can create inter-site contracts to manage reorders between sites:
Record the sites as customer BP and/or supplier BP. Requesting sites are referenced as Customers and reordering site as Suppliers.

When you create a purchase contract and enter a supplier of the inter-site type, the contract is considered as an inter-site contract. This means that when creating the purchase contract, the associated sales contract is automatically created. This contract is identical to the purchase contract. The customer for this sales contract will be the Customer associated with the requesting site that has issued the purchase contract.

The master contract is the purchase contract. A delivery call-off entered on the purchase contract automatically creates the delivery request in the sales contract. Any modification carried out on a delivery call-off is automatically duplicated on the delivery request of the sales contract (modification of the quantity, delivery call-off balance, deletion of the delivery call-off). At the level of the delivery request of the sales contract, no modification is possible, everything is managed by the purchase contract.

There is a case where the purchase delivery call-off can be modified by the sales delivery request. If a delivery request is partially delivered, the delivery request of the sales contract is split into two delivery requests. The first part applies to the delivered amount, the second to the remainder. In fact, the purchase delivery call-off will also be split into two delivery call-offs corresponding to the sales delivery requests.

Inter-company specificities: Within the framework of an inter-site or inter-company open order, the supplier needs to be declared as being of the inter-site type and the site associated with this supplier must be a sales site (it defines the sales site in the mirror sales contract). The purchase site at the origin of the open order must be able to identify an inter-site customer that will serve to define the reciprocal customer sales open order.

When the supplier is identified as being an inter-site supplier, the inter-site check box in the open order is automatically selected. If the site associated with the supplier belongs to another company than the purchase site of the order, the inter-company check box is also selected.

A warning message can be displayed in this context, if the customer linked to the purchase site is blocked. The generated sales order will display a blocked status. The inter-site orders are not themselves concerned with this operation. The WIP order book is not managed for the internal flows.

• 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 the value is No, it may be a code selected freely.
• When its value is Yes, an existence check is systematically applies to the entered project code.
  You can use the Selection icon to display the list of available project codes.

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

• When this parameter is set to Yes, the management of multiple projects 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 order project code: 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.
  
• When this parameter is set to Yes, the management of multiple projects 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.

When an analytical dimension type is used in the Project management tracking, any modification of the project code on the document header leads to reinitializing the dimension code of this dimension type on the document header and on the invoicing elements, based on the Default dimensions setup. If the project code is used onto the lines, the dimension code of impacted lines is also reset.

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)

When the BUYFLT - Filter by buyer parameter (ACH chapter, AUZ group) is set to Yes, the Buyer code is set to the user code and its entry is mandatory.

Depending on the entry transaction used, this field may be hidden. In this case, it is the user code that is used as default value.

From this field, the Actions icon gives you 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 analytical dimensions are initialized in compliance with the Default dimensions setup (POH dimension code). These dimension codes can be modified manually if authorized by the transaction.

When an analytical dimension type is used for the Project management tracking, any modification of the project code leads to the dimension code of this dimension type being reset based on the Default dimensions setup. If the project code is used onto the lines, the dimension code of impacted lines is also 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.

In addition, you cannot create several lines for the same product and the same receiving site. If this is the case, a blocking error message will be returned: "Product-site contract line already exists. Addition impossible".

Inter-company specificities:

On an inter-site or inter-company open order, you can only enter products of the 'Received / Deliverable' type.

From the Product field, there are many possibilities. You can directly enter a product reference or use the Actions icon to:

• Select a product from the file.
• Select a product from the list of supplier products.
• Select a product from the list of supplier-site products. From this selection window, the cursor is set by default on the first product referenced by the supplier for the chosen receiving site. You can select a different product from any other site, if it belongs to the same legal company.
• Create, according to the user's access rights, the product in the file.

The entry of the product is used to load the Description field, which can be modified.

After entering the product, the following messages may display:

• When the product is not referenced by the supplier.
• This message can be blocking or a simple warning according to the choice made at the level of the ITMBPS - Supplier referencing parameter (ACH chapter, REF group).
• When the product-site is not referenced by the supplier.
• This message can be blocking or a simple warning according to the choice made at the level of the ITMBPSFCY - Supplier-site referencing parameter (ACH chapter, REF group). If this message is blocking, you can still proceed with your entry but the Receiving site field must be set as available for entry for the entry transaction. In this case, the Receiving site field is emptied. You must then enter a site where the product-supplier is referenced, or for which the ITMBPSFCY - Supplier-site referencing parameter is not defined as blocking.
  The control linked to the ITMBPSFCY - Supplier-site referencing parameter does not apply to inter-site orders.
• When the order for the product is blocked for this supplier, or for this supplier on this particular receiving site. This can be a blocking message or a simple warning according to the value of the blocking code in the Product or Product-site record.
• When the product cannot be directly ordered but must previously have been the object of a Purchase Request.
  This message is blocking.
• When the filter by buyer is active and the product is not managed by a buyer specified in the contract header.
  This message is blocking.

• 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.

• Product type (field ITMKND)

This field indicates if the product is of type: Standardor Service.

A product of the Standardtype is a 'physical' product, whether managed in stock or not. A product of the Servicetype is a product not managed in stock and of the Servicecategory.

The presence of this field depends on the entry transaction used.

• Major version (field ECCVALMAJ)

The major version number can only be accessed if the tracking of major versions is activated at product setup level (in the Management section of the Product function, the value of the Stock version field is set to 'Major'). If the versions preloading is activated at the Product-supplier 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 can still be modified.

• Minor version (field ECCVALMIN)

The minor version number can only be accessed if the tracking of the major and minor versions is activated at product setup level (in the Management section of the Product function, the Stock version field is set to 'Major and minor'). If the version preloading is activated at Product-supplier level, or at least, at Product-Order level, the last minor version is preloaded automatically. It can still be modified.

• Receiving site (field PRHFCY)

• Address (field FCYADD)

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

• 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 combination, or for products that do not exist in the product-supplier record.
This product has two purchase units:

• Purchase unit defined on the product record.
• Purchase unit linked to the supplier.

This purchase unit cannot be modified. It is used as the default value when entering an order, subcontract order or receipt. The supplier purchase unit is suggested by default when the product-supplier record exists.

The purchase units are accessible depending on the type of category assigned.

 Upon invoicing a product, the product purchase unit 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 ones.

• Firm horizon (field FIMHOR)

• Period (field FIMHORUOM)

• Planning horizon (field FRTHOR)

This is the period, expressed in number of days, weeks or months, during which the provisional delivery requests can be completed.

• 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 the value is No, it may be a code selected freely.
• When its value is Yes, an existence check is systematically applies to the entered project code.
  You can use the Selection icon to display the list of available project codes.

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

• When this parameter is set to Yes, the management of multiple projects 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 order project code: 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.
  
• When this parameter is set to Yes, the management of multiple projects 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.

When an analytical dimension type is used in the Project management tracking, any modification of the project code on the document header leads to reinitializing the dimension code of this dimension type on the document header and on the invoicing elements, based on the Default dimensions setup. If the project code is used onto the lines, the dimension code of impacted lines is also reset.

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

The analytical dimensions are initialized in compliance with the Default dimensions setup (POC dimension code).
When an analytical dimension type is used for the Project management tracking, any modification of the project code on the document line leads to the dimension code of this dimension type being reset based on the Default dimensions setup.
According to the setup of the transaction, the analytical dimensions can be modified. The different analytical dimensions entered in the order line will be transferred to the receipt or to the purchase invoice control. STOP

• QC (field QUAFLG)

This code is used to define whether this product must be controlled on receipt into stock.
The assigned product Category determines the initial control value for the product-site record and the supplier-stock record. The supplier-stock record value provides the default value for purchase orders.

• No control. The control is based on the management rules. It can be modified manually.
• Non-changeable control. Quality control is mandatory for stock receipts. Q is the only valid status.
• Changeable control. For a miscellaneous receipt into stock, the quality status is initialized to the value Q. This status can be changed to A or R.
  The quality control code can also be defined at the purchase order level.
  • If in the order quality control is set to "Yes", quality control is mandatory and the receipt has one of the sub-statuses Q* defined in the product management rule for receipt movements.
    If no sub-status is defined, the status cannot be entered at the time of receipt.
  • If in the order quality control is set to "No", quality control is not mandatory.
    At the time of receipt, A is suggested as the default status. This can be changed to one of the statuses defined in the receipt movement rule for this product.
• Periodic control. This control is automated according to the number of receipts for this supplier and this product. The stock status can still be modified during entry.
  
  

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 conversion factor 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 either the increase conversion factor entered on the product-supplier record or 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

These are the analytical dimensions of the invoicing element.

The analytical dimensions are initialized based on the Default dimensions setup (POCV dimension code), linked to the management of invoicing elements. These dimension codes can be modified manually if the transaction allows it. In order to modify the dimension codes of the various dimension types, click the Actions icon.

When an analytical dimension type is used for Project management tracking, any modification of the project code on the document header will lead to reinitializing the dimension code of this dimension type, except if a distribution key has been entered.

• 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 example: 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 sender or the recipient to ensure transport continuity when the goods need to undergo several successive transports. The forwarding agent is controlled in the Carriers table.

The forwarding agent and their address are used in the Intrastat file to declare the flows of goods between the forwarding agent’s address and the sender’s address, or between the forwarding agent’s address and the recipient’s address.

For example, this situation applies to the shipment of goods abroad, since customs formalities are performed by a forwarding agent in another EU country. An Intrastat declaration needs to be submitted for the transfer of goods to 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 submitting an Intrastat document is necessary 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 performed transaction. The nature of the transaction is used in the Intrastat.
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 transaction nature is initialized according to the setup of the correspondence table for the Movement rules and natures. This table is used to associate an EU rule and an EU transaction nature to each flow type. This setup can be adjusted by rule, country and group of companies.

• Statistical rule (field EECSCH)

The EU or statistical rules are used to specify the nature of the EU transaction from a tax or statistical point of view. The EU rule is used in the Intrastat.
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 parameters of the comparison table for the Movement rules and natures, which is used to associate an EU rule and an EEU transaction nature to each type of flow. This setup can be adjusted by rule, country and group of companies.