Orders

• Sales site (field SALFCY)

The sales site is initialized by the sales site associated with the user. The sales site can be modified (as long as no line has been entered on the document) provided it has been chosen from the list of sales sites authorized to the user.

From this field, a contextual button is used to:

• Select a sales site in the file

• Type (field SOHTYP)

The order type is used to determine the order category (Normal (basic), Loan or Direct invoicing) as well as the sequence number used (if the sequence number is a manual counter, the order number can be entered). Contracts are not managed in this function.

Only an order type with a legislation and company group consistent with those of the company linked to the sales site can be entered.
   For further information, click here.

Case of on order creation using the Order button from a quote

If the order is created using the Order button from a quote (GESSQH), the field is loaded with the order type entered in the Order type field of the quote.

If no order type is defined in the quote, the general parameter QUOORDCAT - Order category (VEN chapter, ORD group) will be used to define the order category to apply ('Normal' or 'Direct invoicing').

• If the category defined in this parameter is 'Normal', then the order type defined in the SOHTYPNOR - Normal order type parameter (VEN chapter, ORD group) will be used.
• If the category defined in this parameter is 'Direct invoicing', then the order type defined in the SOHTYPINV - Direct invoicing order type (VEN chapter, ORD group) will be used.

If no value is defined in the QUOORDCAT - Order category from button parameter, the system takes into account the first order type in alphabetical order.

• Number (field SOHNUM)

The order number allows the order to be identified in a unique way. This number is assigned automatically or entered whenever an order is created based on the parameterization of the counter associated with the order type chosen.

If the order counter is defined with automatic allocation, the order number field is not accessible and the counter is assigned to the order creation. Conversely, if the order counter is defined with manual allocation, it is possible to enter it manually. If it is not entered at the moment of creation, the system will automatically assign an order number according to the counter.

• Revision (field REVNUM)

This field is loaded if at least one revision has been created for this order. It contains the last revision number created for this order. The management of the revisions is available if the general parameter SALREV is set to Yes. 

• Reference (field CUSORDREF)

This information is used to specify the customer order reference. In the case of an inter-company or inter-site order, generated from a purchase order of the same type, the purchase order number will be entered in this field and a tunnel can be used to access the purchase order at the customer site.

• Date (field ORDDAT)

This is the customer date. It is initialized to the current date and it can be modified. If it is modified, after at least one line has been entered or saved, a question is asked suggesting that the prices and discounts on all the lines of the document be recalculated.

• Currency (field CUR)

This is the currency in which the order is drawn up. By default, it is the Bill-to-customer's currency. The currency code mentioned in this screen cannot be modified. It is only mentioned as a reminder. The currency code can be modified in the Management tab of the order.

• Sold-to (field BPCORD)

The Sold-to customer is the order-giver for the order. This customer must be activated to be assigned to an order. You can also enter a prospect. In this case, a message suggests that the prospect be changed into a customer; otherwise the order cannot be created.
You can change the sold-to customer as long as no line has been entered on the order.

Click the Actions icon to:

• access and create, according to the user authorizations, a customer or prospect,
• modify the default address associated with this order,
• view the notes related to the customer.

Click Quick customer search to search for a customer, or several customers grouped under the same criteria. A list of matching items is generated on tabulating to the next field.
For a more advanced search, all fields present in the block can be entered. The list of matches is narrowed down with each tabulation.

Inter-company specificities: In the case of an inter-company order automatically generated from a purchase order, the Sold-to customer corresponds to the customer associated with the purchase site entered in the purchase order.

• field BPCNAM

This is the customer's corporate or company name. This information is not directly modifiable. It can be modified from the address management screen available from the Sold-to customer field or the tool bar. The corporate or company name of the customer is printed on the order acknowledgement or receipt.

• field WSOHCAT

The category cannot be modified; it is determined by the chosen Order type.

Intercompany specificities:

For intersite orders automatically generated from a purchase order, products are always Received / Deliverablefields. In this case, the order category is always: Normalfields.

For intercompany products automatically generated from a purchase order, the sales order category is defined by the product of the first line entered on this purchase order:

• If the first product is Received / Deliverable or Not received / Not deliverable, the sales order category is Normalfields. The lines described below can include products:
• of the Received / Deliverablefolder. These product lines use the Delivery/Sales invoice flow.
• of the Not received / Not deliverablefolder. These product lines are invoiced using the invoicing schedule.
• If the first product is Not received / Deliverable, the sales order category is Direct invoicingfields. All lines are directly invoiced with no delivery.
  You can only add products:
• of the Not received / Deliverable,
• of the Not received / Not deliverablefolder.

• Sequence number (field SOHNUMEND)

• Bill-to customer (field BPCINV)

The bill-to customer code must be active. In all cases, it is initialized by the bill-to customer code associated with the sold-to customer in the latter's record. These is the possibility to modify the bill-to customer if necessary. From this field, it is possible to select a customer or access customer management by tunnel if the user's authorizations allow it. Once the order is partly delivered, this information will no longer be accessible.

Special features linked to the inter-company option: In the case of an inter-company order automatically generated from a purchase order, the bill-to customer corresponds to the customer associated with the invoicing entered in the purchase order. This information is not modifiable in this context.

• field BPINAM

This is the bill-to customer's corporate or company name. This information is not modifiable.

• Pay-by (field BPCPYR)

The Pay-by BP is initialized by default by the pay-by BP associated with the sold-to customer in the latter's record. It is possible to modify the pay-by BP if necessary. From this field, it is possible to select a BP or access BP management by tunnel if the user's authorizations allow it.

Special features linked to the inter-company option: In the case of an inter-company order automatically generated from a purchase order, the pay-by BP corresponds to the customer associated with the invoicing site entered in the purchase order. This information is not modifiable in this context.

• Group customer (field BPCGRU)

The group customer is initialized by the group customer code associated to the sold-to customer in the latter's record. This information is used for the generation of statistics. It is also involved in the grouping of invoices during the automatic generation of invoices. There is the possibility to modify the group customer if necessary. From this field, it is possible to select a customer or access customer management by tunnel if the user's authorizations allow it.

It is possible to search a customer or several customer grouped under the same criteria by selecting "Quick customer search". A list of matching items is generated on tabulating to the next field.
For a more advanced search, all fields present in the block can be entered. The list of matches is narrowed down with each tabulation.

• Delivery address (field BPAADD)

The combination of the sold-to customer and this address code identifies the ship-to customer. The delivery address is initialized with the default delivery address associated with the sold-to customer in the latter's record or with the first delivery address code in the absence of any default delivery address. From this field, the contextual button allows the user to choose a delivery address. If the delivery address is not managed on the line (LINBPD setup), this address code will be picked up by each line in the order and cannot be modified. When this not the case, this address code will be picked up on each line, but it cannot be modified.

If when modifying the shipment address in the order header, when in creation more and before any line is entered, a question is posed to the user whether they want to modify the shipment date as a function of the delivery date and to enter a new delivery lead-time linked to the new address. In all cases, the information linked to the new address code is reinitialized (Shipping site, Delivery priority, Route code, Carrier, Delivery lead-time, Incoterm Code, Incoterm town, Forwarding agent and address code, EU VAT number, Intrastat Transport location, Delivery contact, Sales representatives if they are related to the ship-to customer).

If the delivery address is modified when order lines exist (in order creation), the system warns the user that the delivery date will be recalculated with respect to the requested delivery date. In all cases the information related to the new delivery address is reinitialized in the order header (Delivery priority, Route code, Delivery method, Carrier, Delivery lead-time, Delivery contact and Sales representatives if these come from the ship-to customer). This rule does not apply to the shipping site which remains unchanged. The user will also be asked whether he wants to copy the modification to the other lines in the order. Several outcomes are possible depending on the user choice:

• If the user answers Yes to this question, the order line information concerning the delivery will be modified by the delivery information in the order header (Delivery address code, Delivery priority, Delivery method, Carrier, Delivery lead-time, Delivery contact and Sales representatives if these come from the ship-to customer).
  If one or several products are prohibited for this new address, their list is displayed on the screen in a log file. If the user has no blocking control on prices (SDACLOK - Non block ctrl price, profit,qt user parameter), he may carry on regardless of the warning message.
  A dialog box opens and suggests that prices and discounts be re-calculated. The answer 'Yes' triggers a price list search for all the document lines. If the price list is defined with respect to the country code and/or new code of the geographic subdivision, prices and discounts may then be re-assigned according to these criteria.
   
• If the user answers No or End to this question, the order line information will not be modified.
   
• If the user answer Yes if same value to this question, only the order lines that refer to the initial shipment address will be modified. If one or several products are prohibited for this new address, their list is displayed on the screen in a log file. If the user has no blocking control on prices (SDACLOK - Non block ctrl price, profit,qt user parameter), he may carry on regardless of the warning message.
  A dialog box opens and suggests that prices and discounts be re-calculated. answer 'Yes' triggers a price list search for lines with a modified delivery address. If the price list is defined with respect to the country code and/or new code of the geographic subdivision, prices and discounts may then be re-assigned to these lines according to these criteria.
   
  Note : the price list re-calculation of these lines is performed only if the order is not shipped (in the case of normal orders) or not invoiced (in the case of direct invoicing orders) and no line is closed.

Specificity: If the LINBPD -Ship-to Customer on Detail(VEN chapter, MIS group) parameter is set to "No", the address code will be applied to each order line and it will not be possible to modify it on the line. If a modification is performed it will be applied to all order lines automatically and a new price list search will be suggested to the user.

Special features linked to the inter-company option: In the case of an inter-company order generated automatically from a purchase order, the delivery address corresponds to the ship-to customer associated with the receiving site entered in the purchase order.

• field BPDNAM

Il s'agit de la raison sociale de l'adresse de livraison.

• Project (field PJT)

The management of the project 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. 

When the entry is controlled, depending on the context, the user can choose a project, or one of the entities that can be allocated to the project (a budget lot or a task) using its allocation code:

• The project allocation code is composed of:
  - for projects, the project counter number,
  - the concatenated project chrono with the budget bacth code, in the case of a project budget bacth,
  - the concatenated project chrono with the number of tasks, in the case of a project task.
   
• You can only select an activeallocation code, dependent on the status of the relevant entity. If it becomes inactive after the document creation, the control is applied and prohibits the document modification.

In creation mode, the project code is systematically transferred to the document lines where it can only be modified if the multi-project management of documents is authorized (the PJTSNGDOC - One project per document parameter is set to No).

 During the conversion of a document, the project code of the header is initialized by the first selected document (if the project code of the original document header has become inactive, the one of the destination document is not loaded).

In modification, the project code modified in the header is recovered automatically in lines, except when the multi-project management is authorized in which case a dialogue box will open and requests whether to transfer this code to the document lines with respect to the following options:

• Yes : the project code is transferred to all lines.
• No : the project code is not transferred to the lines.
• Same value : the project code is only transferred to the lines associated to the previous project code.

Sales documents: quotes, orders, deliveries and invoices:
In case the project code is applied to the lines, a dialogue box opens and suggests a recalculation of prices and discounts The answer Yes triggers a price list search, based on the new project code, for all the lines of the document. Depending on the processed document, the recalculation is performed only if the following conditions are met:

• For a quote: it is not ordered.
• For an order: it is not delivered (in the case of standard orders) or not invoiced (in the case of direct invoicing) and no line is closed.
• For a delivery: it is not validated and the delivery is direct.
• For an invoice or a credit memo: it is not validated and the invoice/credit memo is not direct. 
   
   The grouping of two or more documents with different project codes in the header is only authorized if the parameter PJTSNGDOC - One project per document is set to No.In that case, two orders with a distinct project code can be grouped on the same delivery note for instance.

Inter-company specificities: for an inter-site order, the project code is automatically set to the one of the purchase order. For an inter-company open order, the project code is not recovered from the purchase order and remains blank.

• Sales rep (field REP)

The sales reps are initialized by the customer sales reps, then by those of the ship-to customer, if no sales rep exists in the customer record. If one of the two sales representatives is modified and if there are lines in the order, the system will ask the user whether to copy the modifications to the order lines and to recalculate the commission rate. The user will also have the possibility to only modify the order lines referring to the previous sales rep code (choice Yes if same Value).

• Loan return date (field LNDRTNDAT)

The planned loan return date is accessible if it is a loan order. It is initialized with the order date plus a month. This date cannot be prior to the order date.

• Closing reason (field CCLREN)

Cette information permet d'indiquer un motif de solde pour une commande ou une ligne de commande. Le motif de solde peut être alimenté si le paramètre CCLRENORD (Saisie motif solde commande) est activé. Lors du solde d'une commande ou d'une ligne de commande cette information pourra être saisie dans une liste de valeur pré-déterminée. Elle permettra de connaître le motif de la clôture de la commande. SI l'on solde entièrement la commande, la valeur saisie et la date de solde sera également inscrite sur les lignes de commandes non encore soldées.

• field CCLDAT

• Tax rule (field VACBPR)

A tax rule represents the tax territoriality principle, in other words, the calculation rules to be applied to determine the tax amount.

As a general rule, by crossing a tax rule linked to the BP with a Tax level, you can determine the tax code to be applied to the document line and so, to the entry line.

The tax rule is based on the tax rule of (in order of priority):

• the ship-to customer,
• the BP/Company,
• the customer.

Once the order is created, this information is no longer modifiable. If you modify the tax rule after entering order lines but before creating the order, then taxes are re-calculated on all entered lines.

Only one tax rule with a legislation and group that are consistent with those of the document can be entered.
See the documentation on general principles linked to the mutli-legislation setup.

The parameter CTLTAX - Tax codes control (VEN chapter, VAT group) is used to control that the BP tax rule:

• is specified,
• is activated,
• has a legislation and group consistent with the ones of the document.

• Entity/Use (field SSTENTCOD)

Enter the Entity/use code to calculate the precise tax amount for the customer. This tax code is compatible with the Avalara system and makes it possible to determine the customer type for fiscal purposes.

This field is available for all countries. The Entity/Use code can be entered for any delivery address when a document is being processed for a country that is tax-exempt. When the Calculate all documents connection with SST is set to No and an Entity/use code is entered, the document is exempt from tax and not subject to processing costs.

• Currency (field CUR)

The order currency is initialized with the customer currency. Once the order is created, this information is no longer modifiable. If however the currency is modified after having entered the order lines, but before creating the invoice, then a conversion of the prices and discounts will be carried out. it is however possible to carryout a new price list search as function of the new currency by responding Yes to the question "Do you want to recalculate the prices and discounts ?".

• Price - / +tax (field PRITYP)

The value of this field (Ex-tax or Tax-incl.) is defined by the general parameter SALPRITYP - Price/Amount type (TC chapter, INV group).

When the general parameter NOTATI - Ex-tax and tax-incl. amount/price (TC chapter, INV group) is set to No you cannot modify this information.

• Signed (field APPFLG)

This information is used to identify the document situation from the signature management point of view. The possible values are: 'No', 'Partially', 'Totally', 'No management', 'Yes automatic'.

- If the approval management is not active for the company (APPSQH setup for the quotes, APPSOH for the orders or APPSOC for the contract orders), the value will systematically be equal to "No management". It is possible to edit and change the document (change the quote into an order, deliver the order or the delivery request).
 
- If the signatures management is activated for the company, the value will depend on the signature rules and the signatures carried out:

• If the value is set to No, it means that no signature has been entered or that the signatures that have already been carried out have been cancelled by a signer.
• If the value is set to 'Partially', it means that some of the signers defined in the approval circuit have signed the document.
•  If the value is set to Totally, it means that all the signers defined in the signature circuit have signed the order. It can be edited and ordered (for the quotes) or delivered (for the orders and delivery requests).
   In the last two cases, modifying some document fields (see the list of the Approval rules documentation (SQHSIG for the quotes, SOHSIG for the orders and SOCSIG for the contract orders) can reinitialize the approval circuit and have an impact on the situation of the document with regard to the approvals.
  In the particular case of a contract order, the approval circuit is not modified as soon as at least one delivery request has been associated to it.
• If the value is set to 'Yes automatic', it means that the management of the signatures is optional (APPSQH, APPSOH or APPSOCsetups) and that no signature circuit has been determined for this contract. It is considered as approved and can be edited and ordered (for the quotes) or delivered (for the orders and delivery requests).

• Order state (field ORDSTA)

This information is used to identify the order status at any time. The possible values are: Not closed, Closed. Provided the order is not closed/completed it is possible to modify it. Otherwise the order can no longer be modified An order is considered as closed if it has been totally shipped (totally invoiced for the direct invoicing orders) or if it has been manually closed.

• Allocation (field ALLSTA)

The possible values are: Not allocated, Partially allocated, Allocated.

• Delivery (field DLVSTA)

The possible values are: Not shipped, Partially shipped, Shipped.

• Invoice (field INVSTA)

The possible values are: Not invoiced, Partially invoiced, Invoiced.

• Credit (field CDTSTA)

The possible values are: OK, Blocked, Credit level exceeded, Prepayment not made.

Blocked

The customer credit status is Blocked, when the credit status is set to blocked on the customer record or when the required pre-payment has not been totally received and the LOKORD - Block order if pre-payment not made parameter (VEN chapter, ORD group) is set to: 'Yes'.

Credit level exceeded 

The customer credit status is in Credit level exceeded when the Credit level total of the customer is higher than its Authorized credit level.

 The control on credit level excess on the order is performed for the sold-to customer and not the bill-to customer.

Prepayment not made

The order has the status Prepayment not made when the pre-payment has been sent and when the open item date for the pre-payment is exceeded and the pre-payment is still outstanding in its totality (an entered payment that is not posted is not considered).

In the case of an allocation, if you decide to allocate one or more order lines and the credit level calculated for the customer is greater than the authorized credit level, you will get a message to confirm the action if the SCDTUNL - Order unblocking authorization user parameter (VEN chapter, AUZ group) authorizes it; if not, you cannot allocate the order and a blocking message will be displayed.

• If the customer credit level is blocked, you cannot allocate the order.
• If the pre-payment is not made, you will get a confirmation message when proceeding with the allocation of one line or all of the order.

• field CDTBTN

• Hold (field HLDSTA)

This field is only displayed when the Hold code option is activated at the level of the entry transaction.
It displays the hold status of the order:

OK

The order is not on manual order hold.

Held

The order is held. The hold reason is displayed next to the lock icon.
To hold/release an order, click the Hold status lock icon.

• field HLDBTN

Click this lock icon to hold/release an order.

To put an order on hold :

• Click this icon. The order Hold/Release screen is displayed.
• Enter the Hold Codeby selecting the hold reason.
  These codes are defined in the miscellaneous table number 204 listing the Manual hold reasons. To modify or enter a new code in this table, click the Jump to icon from the Hold Code field:
  In this table, three settings determine the allocation status, the back-to-back order creation, and the access codes for higher security:
• Specify No in the Allocation field to deallocate quantities when the hold reason code is selected.
• Specify Yes in the Back-to-back order hold field to hold the creation of the back-to-back order.
• Enter an access code to give the authorization to release the order only to the user profiles attached to this code.
• Click OK.

When an order is placed on hold, activity cannot be processed against this order until the order is released from hold. Delivery, invoices, or preparation are systematically held. The allocation and back-to-back order creation depends on the manual order hold reason code settings.

When an order is released but the customer remains held, the delivery import of the order cannot be performed. However, the interactive delivery of the order can still be performed.

To release an order :

• Click this icon.
• Select Yes on the message box that opens.

This icon is not available when you do not have sufficient user rights to release the order. This is true when one or all conditions below are met:

• You do not have the proper access code assigned to your profile.
• The HLDREL - Authorize manual order user parameter (Sales chapter, AUZ group) value is set to No.

The user who created the hold can always unlock that hold even if they do not have security for the access code for the hold.

If the hold code does not have an associated access code, there is no restriction on who can release the hold.
Any user with rights on the entry transaction in progress (the Hold Code field must be active) having the SCDTUL - Authorization to unlock order parameter (Sales chapter, AUZ group) set to Yes can unlock the order.

• field HLDCOD

This field displays the manual order hold reason, entered to hold the order.

To enter this code, open the Order hold/release screen by clicking the lock icon Hold status lock.
In this screen, click Jump to from the Hold code field to modify or enter a new code in miscellaneous table 204 dedicated to Manual hold reasons. In this table, three settings determine the allocation status, the back-to-back order creation, and the access codes for higher security:

• Enter No in the Allocation field to deallocate the quantities when the hold reason code is selected.
• Enter Yes in the Back-to-back order hold field to hold the creation of the back-to-back order.
• Enter an access code to give the authorization to release the order only to the user profiles attached to this code.

• Acknowledgment printed (field OCNPRN)

This information makes it possible to see if the order acknowledgement has been printed.

• Intersite (field BETFCY)

This non modifiable information specifying that the order is of the type inter-site or inter-company. When the order concerns an inter-site customer (site in the same company) it cannot be invoiced. When the order concerns an inter-company customer (site in a different company), an invoice can be generated.

• Intercompany (field BETCPY)

• Electronic signature (field SOHCFMFLG)

• Validation date (field SOHVALDATC)

• Shipment site (field STOFCY)

The shipment site is the storage site from where the products will be shipped when the order is delivered.

The shipment site is initialized to the shipment site entered on the ship-to-customer (it corresponds to the usual shipment site for this delivery address) or, if nothing has been specified, to the user's default storage site. In both cases, the shipment site must belong to the same company as the sales site, otherwise it will not be submitted and it will have to be necessarily entered.

The shipment site can be modified under certain conditions :

• The entered site must be declared as the storage site.
• It must belong to the same legal company as the sales site.

The shipment site entered in the header is used as the default value for the order lines. In the case of orders with Complete shipment, the shipment site is not modifiable in the order lines.

If the shipment site can be modified and the order lines exist, the system will propose to the user to modify the shipment site for all the lines in the order (only not allocated or not shipped order lines can be modified).

Inter-company specificities In the case of an inter-company or inter-site order generated from a purchase order, the shipment site will be initialized by the shipment site entered in the purchase order. It can be modified to manage any changes in the shipments. However the source purchase order is not updated by this modification.

• Delivery priority (field DLVPIO)

In this field, specify the delivery priority (Normal, Urgent, Very urgent). The priority is used to classify orders during the delivery preparations.
It is initialized by the customer delivery address. It is used on the order lines by default where it can be modified if the delivery method for the order is not Complete. If you modify this information and order lines already exist, the system will suggest that you apply this modification to the order lines.
This information is used in the automatic allocation processing of orders to determine the priority of the orders.

The order lines applying to non-deliverable products are not impacted by this information.

• Required delivery (field DEMDLVDAT)

The requested delivery date corresponds to the date requested by the customer. It is initialized by the shipment date (itself initialized by the order date) increased by the delivery lead time associated with the delivery address. This date is recovered by default on the order lines when products are deliverable products. If this date is modified, it will be used to recalculate the shipment date. If the order contains lines, a message suggests that you update the requested delivery date and the maximum delivery date (if the entered date is greater) and the new shipment date on the order lines.

A control is applied to this date based on the ship-to customer's working days and their unavailability calendar. If the requested delivery date corresponds to a non-working day for the customer, the date will be automatically moved to a date that is later than the initial date. If the requested delivery date corresponds to a day that falls into the unavailability calendar of the customer, then a warning message is displayed suggesting that you modify the date or continue.

Inter-company specificities: In the case of an inter-company or inter-site order generated from a purchase order, the requested delivery date will be initialized to the earliest date in the planned receipt dates entered on the purchase order lines.

• Delivery lead time (field DAYLTI)

Lead-time in number of days required to deliver the goods to the ship-to customer. This field is initialized by the lead-time entered on the customer delivery address. This lead-time is suggested by default on the order lines corresponding to the delivery address of the order header when products are deliverable ones.

It is used to initialize the shipment date based on the requested delivery date. The modification of this lead-time triggers the recalculation of the shipment date based on the requested delivery date.

• Shipment (field SHIDAT)

The shipment date is initialized to the order date or the current date (if the order date is earlier than the current date). This date is controlled with respect the working days at the shipment site and with respect to the unavailability calendar for this site. If the calculated shipment date corresponds to a non-working day at the site, the system moves the shipment date (earlier) to the first working day. If the date corresponds to an unavailable day at the site, a blocking control is used to make you enter a new shipment date. This shipment date will be used by default on the order lines when the products are deliverable products.

A warning message can also be returned when the entered shipment date is greater than the requested delivery date.

Modifying the shipment date never updates the requested delivery date.

• Exp. delivery time (field DEMDLVHOU)

This field is subject to the EDIX3 activity code.
Use it to enter the expected delivery time of the order. The delivery time on order lines determines the delivery time slot, as defined by the Exp. delivery time and Max delivery time fields.

• Route no. (field DRN)

This code, which is controlled by a local menu, is used to generate the delivery notes according to the route code defining for example, a geographic zone. This information is defined by the customer delivery address.

• Delivery mode (field MDL)

Use this code to define the information related to the transport and delivery. The code is managed in the Delivery methods table. It is initialized from the ship-to customer.

The information describes how the goods will be sent to the customer (e.g. this information is used in the Intrastat exchange of goods declaration). The information is also used on the order lines, when the products are deliverable products. You can modify information on these lines if the delivery mode of the order is not Completeorder.

If you modify this information when order lines already exist, a message displays and suggests that you copy this modification to the order lines.

Inter-company specificities icon: In the case of an inter-company or inter-site order generated from a purchase order, the delivery method is initialized by the delivery method entered on the purchase order if the delivery method is not entered for the ship-to customer.

• Carrier (field BPTNUM)

This is the carrier normally used to transport the goods to the customer delivery address. It will be used at the time of the shipment to establish the delivery cost calculation. The carrier is also indicated on the order line, when the products are deliverable products. You (or carriers themselves) can modify this information on order lines if the delivery mode of the order is not Complete.

If you modify this information when order lines already exist, a message displays and suggests that you copy this modification to the order lines.

Inter-company specificities icon: In the case of an inter-company or inter-site order generated from a purchase order, the carrier is initialized by the carrier entered on the purchase order if the carrier is not entered for the ship-to customer.

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

When creating a quote, an order, a delivery or an invoice, the Incoterm code is initialized to the Incoterm code defined by default for the ship-to customer.

This Incoterm code can be modified. Concerning the quotes and orders, the Incoterm code is unique for the document as a whole. When transforming a document, the Incoterm code is passed on to the child document.

 The code and the Incoterm city can also be accessed via the menu Options / Informations douanières.

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

• Last delivery no. (field LASDLVNUM)

This is the number and date of the last delivery carried out for the order. A tunnel can be used to access this delivery.

• Last delivery date (field LASDLVDAT)

• Delivery type (field SDHTYP)

This field, that can not be modified, displays the Delivery type associated with the chosen Order type.

If this has not been specified:

• During an order delivery using the [Delivery] button:
  The delivery type indicated by the parameter SDHTYPNOR - Normal delivery type or SDHTYPLND - Loan delivery type (chapter VEN, group SSD) is the one that is taken into account.
• During the Automatic order delivery and Picking ticket delivery processings:
  The delivery type entered in the processing launch function is the one that is taken into account.

• Close unfilled lines (field ORDCLE)

This information, initialized by the sold-to customer, is used to authorize or not the closure of a line or the order. This information is modifiable on order entry if the transaction allows it.

• One order per delivery (field ODL)

This information, initialised by the sold-to customer, is used to prohibit the grouping of several orders in the same shipment. This information is modifiable on order entry if the transaction allows it.

• Partial delivery (field DME)

These options are initialized by the sold-to customer to specify how the order is shipped. There are three possible values:

• Authorized means that the order can be partially shipped. 
• Full delivery line means that the order can be partially shipped if the whole line is shipped.
• Full order line means that the whole order must be shipped (a single delivery). 

This also means that a partial allocation cannot be performed on an order line or order if the stock is insufficient to cover the full line or order: the Allocate partially option must be displayed on the order or in the mass allocation options. When entering the quantity to be allocated to the line or when performing a Manual allocation on the line, a warning message displays if the delivery is partial.

Note: When you select Full delivery line or Full order line, you can ignore this warning message and force the partial delivery.

• Allocation type (field ALLTYP)

The allocation type (global/detailed) is initialized to the value of general parameter ALLTYP - Allocation type (VEN chapter, SAL group). It can be modified depending on the entry transaction used. The allocation type specified in this tab serves as the default value for the order lines created later.

This information can no longer be modified once the order has allocations.

The global allocation reserves the goods without distinction by applying a global total, whilst the detailed allocation reserves specific stock objects (lot, serial number...). An order can be allocated from the order (entry of the quantity to be allocated or using the Actions icon of the line to select stock lines in detailed allocation or using the allocation button) or from the Automatic allocation or Allocation by product functions.

• Invoicing mode (field IME)

This information is initialized by the sold-to customer and is used to define the customer's invoicing mode. This invoicing mode is used subsequently to invoice the delivery notes or the direct invoicing orders by regrouping or splitting them. This information is used in the automatic invoicing processes and in the manual invoicing function (where a control is performed with respect to this information).

The available invoicing modes and their impact on the delivery invoicing are as follows:  

• 1 invoice / DN: This invoicing mode requires the existence of a separate invoice for each delivery created.
• 1 invoice / completed order: This invoicing mode only authorizes the invoicing of the deliveries associated with an order if said order is completed and all the invoices associated with this order are validated and all the deliveries belong to the automatic invoicing selection. A single invoice will then be generated grouping all the deliveries for the order.
• 1 invoice / order: This invoicing mode is used to create an invoice for all the deliveries of the order that are validated when the invoicing process is run. A single invoice will be generated grouping all these deliveries.
• 1 invoice / ship-to customer: This invoicing mode is used to create an invoice for all the deliveries concerning the same ship-to customer on a single invoice when the automatic invoicing process is run. There also is a control performed upon manual invoicing of the deliveries.
• 1 invoice / period: This invoicing mode is used to create an invoice for all the deliveries based on the invoicing frequency defined by the customer. For instance, if the frequency is weekly, all the deliveries during week 32 (relating to the shipment date or delivery date based on the INVREFDAT - Origin date for invoicing setup) are grouped on a single invoice. There is a specific feature linked to the invoicing frequency when the chosen value is upon request. Deliveries with this kind of frequency will be grouped together. A control is also carried out in manual delivery invoicing mode to only enable the grouping together of deliveries with an invoicing mode by period and a manual invoicing mode.
• Manual invoice: This invoicing mode is not considered in the automatic invoicing processes. Invoicing will be manual on invoice entry.

Impact of the invoicing mode on delivery generation: orders with an invoicing mode 1 invoice/order or 1 invoice/completed order will never be grouped on a same delivery.

Beside these invoicing modes, there are pieces of information that, if varying from one delivery to the next, prohibit the grouping together of two deliveries. Please refer to the automatic delivery invoicing.

The impact of the invoicing modes on the direct invoicing orders is as follows:

• 1 invoice / DN: This invoicing mode requires the existence of a separate invoice for each direct invoicing delivery. On the other hand, an order can be only partly invoiced by the automatic invoicing function from the moment that the order delivery mode is not Complete order. If the order delivery mode is Complete order,all the order lines will need to be invoiced (the stock-managed order lines will need to be allocated), otherwise the invoice will not be generated. On manual invoicing of an order of this type, there are no constraints with respect to the delivery mode, and it will be possible to draw up a partial invoice even if the delivery mode is Complete order.
• 1 invoice / completed order: This invoicing mode requires the existence of a separate invoice for each direct invoicing delivery. An order will have however to be fully handled in order to be invoiced using the automatic invoicing function. There will thus be only one invoice for this order. In manual invoicing it isn't necessary to follow this rule; it is possible to partially invoice an order of this type.
• 1 invoice / order: For the orders with direct invoicing, this invoicing mode corresponds to the invoicing mode previously described: 1 invoice / DN.
• 1 invoice / ship-to customer: This invoicing mode is used to create an invoice for all the orders with direct invoicing concerning the same ship-to customer on a single invoice when the invoicing process is run. If order lines concern various ship-to customers within a single order there will be as many invoices as there are delivery addresses on the lines. There also is a control performed upon manual invoicing of the orders.
• 1 invoice / period: This invoicing mode is used to create an invoice for all the orders based on the invoicing frequency defined by the customer. For instance, if the frequency is weekly, all the orders during week 32 (relating to the requested delivery date in the order header) are grouped on a single invoice. There is a specific feature linked to the invoicing frequency when the chosen value is upon request. The orders with this kind of frequency will be grouped together.
• Manual invoice: This invoicing mode is not considered in the automatic invoicing processes. Invoicing will be manual on invoice entry.

Beside these invoicing modes, there are pieces of information that, if varying from one order to the next, prohibit the grouping together of two deliveries. Please refer to the automatic order invoicing.

• Payment term (field PTE)

The payment condition is used to identify the customer's payment method(s) as well as the scheduling of payments upon order invoicing. To simulate how expected payments will be staggered, go to the payment conditions management and click Simulation.

Prepayment open items can be included in this distribution. In that case, prepayment requests will be automatically generated upon order creation depending on the order lines. These prepayment requests may be modified subsequently.

This information is initialized by the payment condition of the bill-to customer, or on the paying BP linked to the customer on the quote, based on the setup of the PAYTERMVAL - Init payment conditions parameter (TC chapter, RSK group).

The intialization is carried out according to the following order of priority:

• BP/Company record (BP function)
• Customer record.

The payment condition can be modified as long as no prepayment request has been made and the order has not been invoiced. Modifying the payment condition leads to the deletion of the already existing prepayment requests and the creation of new prepayment requests linked to the new payment condition.

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.

• Settlement discount (field DEP)

This information determines early discount or late charge rates depending on whether the payment is early or late with respect to the due date. For further information, see the documentation on Discounts.

The discount code is specified on the order. This code is initialized by the bill-to customer code of one of the following records, by order of priority:

• BP/Company (BP function)
• Customer.

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.

• Quote no. (field SQHNUM)

This is the quote number at the origin of the order. A tunnel is used to access the quote. If there are several quotes, no quote number will be displayed at this level. They will be displayed at line level.

• Proforma no. (field PRFNUM)

This is the number of the pro forma invoice associated with the document. The generated pro forma number is displayed if a pro forma invoice is created from this document. A tunnel then makes is possible to access the invoice.

• Last invoice no. (field LASINVNUM)

This is the number and the date of the last invoice associated with the order. A tunnel is used to access this invoice.

• Last invoice date (field LASINVDAT)

• Invoicing term (field INVCND)

This information is only managed with orders of the Normal category. It is not mandatory.
It is initialized with the invoicing term linked to the bill-to customer of the order, provided that this invoicing term exists. You can modify it. Only an invoicing term 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.

The invoicing term you enter here is used to reinitialize the invoicing term of each order line relating to products of the Generic or Service category, which are sold and non deliverable.
If you modify the invoicing term on the document header, a dialog box opens and proposes to apply the modification to all document lines, based on the following options:

• Yes: the invoicing term is recovered on all lines.
• No: the invoicing term is not applied to the lines.
• Same value: the invoicing term is only applied to the lines on which the former invoicing term was used.

Only the lines that have not been closed or subject to invoicing are concerned.

You can access the Invoicing terms management function from the Actions icon. In this function, use the Simulation action to simulate the scheduling of expected invoicing open items.

• Beginning due date (field VCRINVCNDD)

This is the calculation start date for the invoicing open items.
This date is loaded with the order date. You can modify it but it must remain greater than or equal to the order date. In case of modification, a message suggests recalculating dates and periods related to the schedule lines. This recalculation does not apply to order lines that have already been invoiced, partially or completely.
 The display and management of this field (hidden, displayed, entered) are linked to the Invoicing term and depend on the field setup defined at entry transaction level.

• Dimension type (field DIE)

This table is used to enter or view the dimension types, depending on the parameters of the delivery entry transaction.

• Description (field NAMDIE)

This field repeats the title of the dimension type.

• Analytical dimension (field CCE)

Based on the setup, the analytical dimensions can be modified since they are initialized in accordance with the setup of the Default dimensions.
Inter-company specificities
In the case of an inter-site or inter-company order, the setup of the SOH default dimension code will be used, if required, to transfer the analytical dimensions of certain types, entered in the purchase order header.

• Short description (field SHO)

Enter a short description for the invoicing element. 

• % or amount (field INVDTAAMT)

The values relate to the invoicing footer. This information can stem directly from the parameters of the invoice footer elements or from the record of the concerned customer or the selected quote.
 See the Invoicing elements documentation for further information.
The footer values can be modified. The ex-tax and tax-incl. amounts of the document are directly impacted by these values.

 The invoicing elements with a grouping rule based on the pro rata of weights or volumes are not taken into account in the flow for non-deliverable products.

 In the case of the modification of an invoice by deleting either a quote, or one or several lines from a quote, the amounts of the invoice elements are not recalculated by taking into account the deleted lines or quotes: the share of the invoicing elements relating to these lines or quotes is not subtracted from the modified order.
 
Special features linked to the inter-company option
If the order has been generated from an inter-company or inter-site purchase order, and the inter-company setup stipulates that the invoicing elements come from the Purchase module, these will be initialized with the values entered in the original purchase order.

• field INVDTATYP

The system specifies whether the invoicing element is a percentage or a tax excl. or tax incl. amount.

• SST tax code (field SFISSTCOD)

Enter the code to use in order to override the default SST tax code from the product or invoice element. This tax code is recognized by Sage Sales Tax and is used to identify line types for tax purposes. This field is available only if the LTA - Local taxing activity code is activated, and the USATAX - Tax system use parameter is set to Yes.

For invoicing elements designated as the SST document discount for a company, you cannot remove the SST tax code value on the document.

• Product (field ITMREF)

It is the product reference for which a document line is recorded.

You can directly enter a product reference or a Product/Customer reference. The existence of this reference is controlled in the Product/Sales and Product/Customer records. If you enter a Product/Customerreference, the system returns the internal product reference. A blocking message is displayed when entering a product:

• if price lists of the prohibitedtype have been set up for some customers (see Price list setup),
• if this product if of the Kit parent product type and cannot be delivered.

You can also use the Actions icon to do the following:

• select a product from the file of sold products,
• select a product from the list of customer products,
• create, according to the user's access rights, a product in the file,
• view the price lists for the product,
• inquire the stock for the product at the shipment site,
• inquire the available stock at the shipment site,
• select the replacement product if it has already been recorded. This function is only accessible if the original product is not available. A screen is then displayed that specifies the stock information linked to the availability of the replacement product. It is possible to accept or decline the product replacement. During line entry for an order, the Alternate product option is available from the action icon for the Ordered qty. field in the grid. It is not available if the line has been allocated or partially delivered, billed, or prepared.

The entry of the product is used to initialize the Description and Sales unit fields, which can be modified. The sales unit can be modified on the condition that it is chosen from the list proposed that contains the sales and packing units from the product and product-customer records.

At this stage, a warning message can appear that to inform the user of the replacement of the entered product by the substitute product. This automatic substitution only takes place when the following two conditions are met:

• the Substitute product field of the product record has been entered,
• the document date is greater than or equal to the substitution date.

Once the line is entered, it is no longer be possible to modify the product code. It is necessary to delete the line and recreate it to modify the code.

• Description (field ITMDES)

This is the product description translated into the customer language. It is this description that will be printed on the document. If the translation does not exist in the customer language, the un-translated product description will be used. This description is also copied to the next document.

• There is the possibility to access the product record using a tunnel from this field.

Inter-company specificities: In the event of an inter-company or inter-site order generated from a purchase order, the translated description will be initialized by the standard description of the purchase order (description translated into the connexion language, in other words, the language of the user who has created the purchase order.)

• Standard description (field ITMDES1)

This is the description entered in the product record. This description is transferred to the deliveries or invoices (case of direct invoicing orders) along with any modification made in the order.

When the order comes from a quote, the standard description is inherited from the quote line.

It is possible to access the product record by tunnel.

Special features linked to the inter-company option: In the case of an inter-company or inter-site order generated from a purchase order, the standard description is initialized by the translated description of the purchase order, and so, the translated description in the supplier's language (sales site).

The auto-completion is available in this field.
Start to enter characters from the product code, the produc description or others and tab.
A screen displays a list of results. Select the right value.

 The auto-completion is only available if the value of parameter Automatic selection (chapter Sales/group Miscelaneous) is set to 'Yes'.

• Major version (field ECCVALMAJ)

This field displays the major version of the product.

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 preloading of versions is active at the product/customer level (in the Customers tab of the Product function, the Version preloading box is checked), or by default, at the product/sales level (in the Sales tab of the Product function, the Version preloading box is checked), then the last active major version is preloaded automatically. Otherwise, the last major version with the 'Stopped' status will be preloaded.

When the line is partially allocated, prepared, delivered or invoiced, you can no longer change the version number.

When the order is converted into another document, the following actions are carried out:

• Activation of the Preparation button and Delivery button, along with the transfer and control of version numbers on the picking ticket or delivery note.
• Activation of the Invoice button, along with the transfer and control of the version numbers on the invoice.
• Quotes picking with transfer and control of versions on the order.

The Major version field display depends on the setup of the entry transaction (hidden, displayed, entered).

• Minor version (field ECCVALMIN)

This field displays the minor version of the product.

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 preloading of versions is active at the product/customer level (in the Customers tab of the Product function, the Version preloading box is checked), or by default, at the product/sales level (in the Sales tab of the Product function, the Version preloading box is checked), then the last active minor version is preloaded automatically.

When the line is partially allocated, prepared, delivered or invoiced, you can no longer change the version number.

When the order is converted into another document, the following actions are carried out:

• Activation of the Preparation button and Delivery button, along with the transfer and control of version numbers on the picking ticket or delivery note.
• Activation of the Invoice button, along with the transfer and control of the version numbers on the invoice.
• Quotes picking with transfer and control of versions on the order.

The Minor version field display depends on the setup of the entry transaction (hidden, displayed, entered).

• Ship site (field DSTOFCY)

It is the storage site from where the goods are shipped to deliver the order line. The shipping site is initialized by the shipping site entered in the order header. It can be modified provided that the selected shipping site belongs to the same legal company as the sales site and the order line has not been allocated. In the case of orders with Complete delivery, the shipping site is neither modifiable on the order lines.

It is possible to:

• select a storage site,
• inquire the stock for the product at the shipping site,
• access by tunnel the Product-site record if the user's authorization allow it.

Special features linked to the inter-company option: In the case of an inter-company or inter-site order generated from a purchase order, the shipment site is initialized by the shipment site entered in the purchase order line. It can be modified to manage any changes in the shipments. This modification does not lead to the update of the original purchase order.

• SAL (field SAU)

The sales unit is initialized by the sales unit defined in the Product-customer record, or by the sales unit of the product. It is possible to enter another unit using a selection window. The suggested units are the packing units of the product and the packing units defined in the Product-customer record. If the user has the appropriate authorizations, it is possible to access the unit table.

Once the line is entered, it is no longer possible to modify the sales unit. It is necessary to delete the line and to recreate it to modify the unit.

Inter-company specificities upon sales order entry: if the order has been generated from inter-company or inter-site purchase order, this information will be initialized with the unit entered in the purchase order and will be inaccessible. Only by modifying the original purchase contract order is it possible to modify this information.

• Ordered qty. (field QTY)

It is the quantity ordered by the customer. It is expressed in a sales unit.

It is possible to:

• Access the Product-site record
• View the stock by site
• Access the Allocation filters This option is used to further detail the information used by the detailed allocation or at the time of shipment if the line has the Global allocation type. Two exclusive filters can be entered: the lot and a combination of statuses (the combination of statuses must be included in the Issue rule of the corresponding delivery type). A preferred filter can be assigned to a location that is used to orientate the allocation. It is possible to enter wild cards "*,? " for these data in order to extend filters. These filters are also accessible in the Quantity to allocate field.
• inquire the Allocation detail. This function is only accessible if there are quantities already allocated on the order. This function is used to view the stock lines that have been reserved. See the Allocation detail button accessed by right click on the line,
• inquire the available stock,
• select the replacement product. This function is only accessible if the original product is not available. A screen is then displayed that specifies the stock information linked to the availability of the replacement product. It is possible to accept or decline the product replacement.

The ordered quantity must be entered. A warning message is displayed if:

• the quantity entered is less than the minimum quantity defined in the product record,
• the quantity entered is greater than the maximum quantity defined in the product record. These messages can be blocking ones according to the value of the SDACLOCK - Price, margin, qty non-blocking ctrl user parameter (VEN chapter, AUZ group).

If the stock is available, the quantity in stock unit and sales unit is displayed in the bar at the bottom of the screen. If the product is unavailable, the system specifies at the bottom of the screen Unavailable plus the date of the first availability if known (this information is displayed if the order transaction has the option Product availability is ticked).

Specificities linked to the inter-company: if the order has been generated from inter-company or inter-site purchase order, this information is initialized with the unit entered in the purchase order and cannot be accessed. Only a modification of the original purchase order can modify this information.

When the ordered quantity is entered a price list search process is automatically carried out. The objective of this search is to recover:

• the gross price and the associated reason,
• the charges and discounts in percentages or in amounts to be applied to the line level and the associated reasons,
• any free product(s).

The price list search process can be triggered in different ways depending on the product type entered:

• if the product entered has the Normal type, the search processing is automatically triggered.
• if the product entered has the Kit component or BOM component type, an initial price list search is triggered for the parent product. Then, the BOM file is read in order to display the different BOM codes with the Commercial type if there are any. If the product has only a single BOM code, it will be taken into account automatically.

After choosing the BOM code, different cases can occur according to the construction of the product BOM:

• If the product has the Kit component type, all the component lines are automatically generated. These lines become completely dependent on the parent product. They appear on the screen but are not accessible. The component quantity is automatically calculated from that of the parent product. If the parent product quantity is modified, the quantities of all the components are automatically recalculated. If the parent product is deleted, all the components are automatically deleted.
• If the product has the BOM parent product type, all the component lines are submitted and they can be modified (except the sales unit). They become independent from the parent product. If the parent product is modified or deleted, it is possible to transfer the modification or deletion to the components.

In both cases, a price list search for the component type is automatically triggered and for each order line generated, a value is assigned to the type of line:

• Kit option or BOM option for an Option type component
• Kit Variant or BOM Variant for a Variant type component
• Kit component or BOM component for a Normal type component

Some price list controls are carried out on exiting this price list processing:

• if the price is defined with tax included, the price without tax is calculated,
• control on the calculated net price: if the calculated net price is less than the threshold price stored in the product, a warning message is displayed,
• control on the profit margin: if the percentage margin is less than the minimum margin percentage (or margin rate) stored in the product record, a warning message is displayed.

They can be blocking messages according to the value of the SDACLOCK - Price, margin, qty non-blocking ctrl user parameter (VEN chapter, AUZ group).

Order lines for items in the Generic or Servicecategory, sold and not deliverable: these items are invoiced using a billing schedule. You can modify the quantity of the line as long as the order line has not been invoiced completely. In that case, only the open items that are not invoiced yet and that are associated with the line can be modified. The percentage is recalculated for all the lines. The total amount of the order line can be different from the schedule total.

• SAL-STK conv. (field SAUSTUCOE)

This is the conversion factor between the sales unit and the stock unit. This coefficient can be modified. It will be modifiable if the sales unit of the product or the packing unit have been checked as 'modifiable' (see the Product record). It cannot be modified if the unit used is a unit defined for the customer. If for the units used, the factor is modifiable, it is necessary to define only prices expressed in stock unit.

Once the line entered, it is no longer possible to modify the conversion factor. It is necessary to delete the line and recreate it to modify this factor.

Specificities linked to the inter-company: if the order has been generated from inter-company or inter-site sales order, this information is initialized with the factor calculated between the purchase quantity and the stock unit and it cannot be accessed. Only a modification of the original purchase order can modify this information.

• STK (field STU)

This is the stock unit for the product. This unit cannot be modified.

• Allocated qty. (field ALLQTY)

This is the quantity, expressed in sales unit, already allocated in the order. This allocation can be global or detailed.

• Shortage (field SHTQTY)

This is the shortage quantity in the order expressed in the sales unit. During the last allocation made in the order line, if part of the stock is unavailable then it is expressed in this column (if the GENSHT - Generation of the shortage quantities parameter (STO chapter/MIS group) is set to Yes).

• Qty to allocate (field WALLQTY)

It is the quantity allocated to the order line.

When the transaction authorizes it, it is possible to enter the quantity that is to be allocated on the order line.
It is always equal to the quantity already allocated in the order line (Allocated Quantity + Shortage Quantity). To increase or decrease the quantity to be allocated, this quantity must be increased or decreased.
If the INIALLORD - Initialization of quantity to be allocated in the order parameter is set to 'Yes', the quantity to be allocated is initialized by the total quantity that must be allocated on the order line (if the ordered quantity for the order must be modified, the quantity to be allocated would then be recalculated).
If the order is not Fully signed though the approval circuit is managed and the SOHAPPALL - Non-signed order allocation parameter is set to 'No', the quantity to be allocated cannot be entered and is not initialized with respect to the ordered quantity. The same behavior is applied if this SOHAPPALL - Allocation order not approved parameter is set to 'Yes'but that the WIP generation for the products managed in stock is forbidden for the orders that have not been approved (SOHAPPORD parameter set to No). The allocation of an order without WIP is not unauthorized.

The quantity entered can be greater than the ordered quantity. A warning message will signal this. The allocation is carried out on saving of the order.

If customer reservations exist for this product and if the USERERBPC - Consumption of customer reservations parameter is set to the value 'Yes', the reservations carried out by the customer are consumed during the allocation.

If the customer credit is blocked, this field cannot be accessed.
If the customer has exceeded their credit, a warning message requires the entry confirmation if the SCDTUNL - Authorization to unlock order user parameter allows it, otherwise the information cannot be accessed.

If the order status is Prepayment not settled, a warning message asks for the entry confirmation.

When entering the quantity to be allocated:

• A warning message is displayed if shortage quantities already exist in other documents for the product currently being processed.
• If the Product availability option is selected in the order entry transaction, the information is mentioned in the Available stock section under the table. When the total quantity to be allocated is not available, the quantity remaining to be allocated is mentioned. It is expressed in stock unit and sales unit.
  As for the document valuation, the display of the product availability is conditioned by the value of parameter SOHVALLIG - Order valuation on line (VEN chapter, MIS group).

In the specific case of order lines generated by back-to-back order on receipt or back-to-back production order.

When the order line is associated with this type of back-to-back order, the automatic allocation processes do not allow the allocation of this type of line. The order line is allocated at the time of the associated purchase order receipt or at the moment of the production reporting for the associated production order.
To manage certain occurrences (production delay or supplier shipment...) it is possible to manually allocate (or de-allocate) these lines if the stock is available.
During the production reporting or at the time of the purchase order receipt, if the quantity remaining to be allocated in the order is less than the quantity booked into stock, only the part remaining to be allocated is allocated. The rest of the goods is entered in stock and is available for other orders.

It is not possible to allocate an order line managed with direct orders.

The available actions are:

• Allocations filter. Use this action to specify the information used by the detailed allocation or at the time of shipment if the line has Global allocation. Exclusive filters can be entered: the lot and a combination of statuses (the combination of statuses entered must be included in the Issue rule of the corresponding shipment type). A preferential filter can be assigned to a location that is used to orientate the allocation. It is possible to enter wild cards "*,? " for these data in order to extend filters.

• Allocation type (field DALLTYP)

The allocation type for an order line has as its default value the allocation type defined in the order header. It is possible to modify the allocation type (Global/Detailed) on a line, provided that the selected order transaction allows it. A global allocation is carried out depending on the available stock total. A detailed allocation reserved the stock objects (Lot - Serial number - Status - Location).

When the order line is allocated, this information is no longer accessible.

• Quantity to deliver (field TDLQTY)

When the ordered product is not managed in stock, you can specify the quantity to be shipped or invoiced (for direct invoicing orders) for this product. If nothing is specified, the whole line is shipped.

When the product is not deliverable for a normal order, this field is not available: the quantity to invoice is defined on the invoicing schedule.

• Gross price (field GROPRI)

This is the unit gross price (in sales unit) of the product expressed tax-excluding or tax-including (depending on the price type). It comes from a price list search, or from the base price of the sales product if the price list search did not return any result.

If the sales unit is different to that of the price list line:

- The price list amount is converted if the Unit conversion is set to Yes in the Price list setup. This conversion is based on the table of unit conversion factors. If no conversion is set up for these units, the price list amounts are considered by applying a conversion rate of 1.

- The price list is not used if the Unit conversion is set to No in the Price list setup. The gross price is set to 0.

Click the Actions icon to:

• View the reasons associated with the price as well as the different discounts and charges fields;
• View the list of the last 10 order prices;
• View the price lists;
• Get an explanation on how the net price was obtained from the gross price and the different discounts.

If the entered price is null, a message is displayed to request confirmation.

This message is displayed neither for the components of a BOM nor for free items.

A processing for Free items is triggered at the end of the document line. This processing generates all the free product lines (Gross price and discounts set to 0). If the parameter FOCPRI - Free product valuation (chapter VEN, group PRI) has the value Yes, a price list search is triggered for the free item so as to assign it a gross price. The assigned price is compensated for, either by a line discount in percentage or a line discount in amount (according to the order of discounts) to obtain a zero net price.

The original line number of the free item is mentioned in each free item line generated in the quote line file (information not displayed on the screen). The Origin information is displayed on the line that created the free items in the Free field. For the free item line, this information is set to Yes. All free item lines are accessible in modification mode (except the price and discounts fields). It should be noted that the management of free items is not taken into account for components.

When creating the document, if the setup manages grouped price lists (GRPPRI - Management of grouped price lists), a question is asked about whether to carry out a new price list search (for the grouped type) that is used to determine the specific conditions linked to the whole quote. At the end of this process, you may get the following, on some product lines:

• A new gross price or new discounts or new charges for the line;
• Free products that are not associated with a specific line.

• field DISCRGVAL1

Discounts and charges columns are displayed. They depend on the setup of the Price list structure code (see the Price list structure documentation). They can be initialized by the use of the price lists (see the Price list parameters and Price list entry documentations). Access to these columns can depend on the parameters of the reasons associated with the price lists as well as the value of the reason given to the UPDPRISAL parameter for Sales and to the UPDPRIPUR parameter for Purchase.

These discounts or charges are defined in amount or in percentage and they are applied in total or as a cascade to the gross price to determine le net price of the document line.

From this information using the contextual button there is the possibility to view the reasons associated with the price as well as the different discounts and charges field.

• Net price (field NETPRI)

From this field, use the Actions icon to:

• view the reasons associated with the price as well as the different discounts and charges fields,
• view the list of the last 10 order prices,
• View the price lists;
• have a detailed explanation available describing how the net price is obtained.

When the entered price is null, a message is displayed asking for confirmation. This message is not displayed for the components of a BOM, for free items and for nonbillable deliveries.

A process for the Free items is triggered at the end of the delivery line. This processing generates all the free product lines (Gross price and discounts set to 0). If the value of the FOCPRI - Free product valuation parameter (VEN chapter, PRI group ) is set to Yes, a price list search is triggered for the free item to assign it a gross price. The assigned price is compensated for, either by a line discount in percentage or a line discount in amount (according to the order of discounts) to obtain a zero net price.

When you click Create to record the delivery, and based on the value of the GRPPRI - Grouped price lists parameter, a message can be displayed, suggesting that a new price list search is run to determine the specificities globally linked to the delivery. At the end of the processing, the following can be generated on some product lines:

• A new gross price or new discounts or new charges for the line;
• free products that are not associated with a specific line.

• Cost price (field CPRPRI)

The 'cost price' is loaded by default by the valuation of the product chosen for the margin calculation (see the valuation methods defined for the Product-Site record) at the time of the creation of the document line and is expressed in sales unit. The various possible choices for the cost price valuation are: Standard price, Revised standard price, Last price, Weighed average price, FIFO price, Lot average price and LIFO price. If the valuation method happened to return a zero value, a default value is used by specifying another valuation method contained in the list previously described. This value is stored in the "document" line.

It is possible to pre-load this information as a function of the document transaction used. Still, during the following events, the entered value is systematically replaced by the value that comes from the setup of the valuation method for the product, except if this setup determines a null value (in which case the change is saved.)

• turning a quote into an order,
• delivering an order, 
• validating a delivery,
• invoicing an order. The cost price is fixed when invoicing a delivery

In quote management, the 'lot average price' always returns a null value. A default value is used. During the delivery validation, the 'Lot average price' is used to recalculate the margin and obtain a real margin depending on the shipped lot(s).

• Margin (field PFM)

This field displays the margin in sales unit, calculated based on the difference between the net price and the cost price.

During the gross margin calculation, a control can be carried out to verify that this margin is not below the minimum threshold defined in the Sales tab in the Product record. This control can be blocked according to the value attributed to the user parameter SDACLOK - Non block. control price, prof, qty (VEN chapter, AUZ group). The calculation carried out to control the margin rate is the following:

(Ex-tax price - Cost price) / Total ex-tax price) *100 >= percentage of the minimum margin.

No control is carried out on nonbillable deliveries.

• Tax level 1 (field VACITM1)

This field indicates the tax level applied to the selected product.

The tax level, when crossed with the document tax rule, is used to determine the tax rate to be applied on the document line.

There are three tax levels for a document line.

The first level is compulsory and it corresponds to the VAT.

The other two levels concern additional and special taxes that can be submitted to the VAT or not, and be applied to the ex-tax basis or any other evaluated formula.

The tax levels for the document line will be loaded by default with the values associated with the product record (Accounting tab). These values can be modified depending on the transaction. You can also, if the user's authorizations permit it, access the tax level management.

The parameter CTLTAX - Tax codes control (VEN chapter, VAT group) is used to control that the tax codes linked to the tax level are consistent. Using this control, the system checks that the tax level:

• is specified,
• is activated,
• has a legislation and company group consistent with the ones of the document.

• Invoicing term (field DINVCND)

• SST tax code (field SSTCOD)

Enter the code to use in order to override the default SST tax code from the product or invoice element. This tax code is recognized by Sage Sales Tax and is used to identify line types for tax purposes. This field is available only if the LTA - Local taxing activity code is activated, and the USATAX - Tax system use parameter is set to Yes.

For invoicing elements designated as the SST document discount for a company, you cannot remove the SST tax code value on the document.

• Project (field DPJT)

The project code in document line is initialized by the one entered in the header or, in the case of a document transformation, by the one of the selected document lines (in picking or in mass processing, if the project code on a document line is inactive, the line cannot be selected).
It can only be modified if one of the two following conditions are met:

• the PJTSNGDOC - one project per document parameter (chapter TC - group MIS) is set to No,
• the entry of this field is authorized by the entry transaction being used.

In modification mode, the project code management depends on the value of the CTLOPPCOD - Mandatory project control parameter.

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

When the entry is controlled, depending on the context, a project or one of its entities can be picked (a budget batch or task), using its posting code:

• The project allocation code is composed of:
  - for projects, the project counter number,
  - the concatenated project sequence number with the budget batch code, in the case of a project budget batch,
  - the concatenated project sequence number with the number of tasks, in the case of a project task.
  
• You can only select one Active posting code, depending on the status of the relevant entity. If it becomes inactive after the creation of the document, the control is performed and blocks the modification of the document.

In selection, there are two possibilities:

• The Selection contextual menus (CRM projects, Projects, Budget batch or projects only linked to the BP) are used to select a project in a selection list.
• The CRM projects and Projects contextual menus are used to directly access the chosen management function and then carry out a selection or create a project.

When the project code of the document header is modified, this project code is automatically transferred to the lines, except when the multi-project management is authorized. In this case, a dialog box would open and suggest to transfer this code to the lines of the document, according to the following options:

• Yes: the project code is transferred to all lines.
• No: the project code is not transferred to the lines.
• Same value: the project code is only transferred to the lines associated to the previous project code.

Sales documents: quotes, orders, deliveries and invoices:
- In case lines were impacted, a dialog box opens and suggests to recalculate the prices and discounts. The answer Yes causes a price list search, based on the new project code, for all the lines of the document.
- In the event the project code were modified in the line, this same price list searching system is applied to the line.
Depending on the processed document, the recalculation is performed only if the following conditions are met:

• For a quote: the item line is not ordered and is not free.
• For an order: the item line is not closed, not delivered, not invoiced nor free.
• For a delivery: the item line is direct and not free.
• For an invoice or a direct credit: the document is not validated, the item line is direct and not free. For direct credits, the quantity is different from 0.

• Sales rep 1 (field REP1)

The sales reps on the document line are initialized by the sales reps entered in the document header. If the latter are not entered, the sales reps in the line are initialized by the sales reps for the customer, by those for the ship-to customer if there are no sales reps in the customer record.

If the parameter LINREP - Sales rep on detail allows it (chapter VEN, group MIS), the sales reps can be modified on the document line. It is possible, based on the user's authorizations, to access the sales representative record.

• Commission rate 1 (field REPRAT1)

The commission rate for the sales representative is initialized on the line based on the commission category for the customer and the commission rate for the sales representative by category. This commission rate can be weighted by a modifiable weighting factor that can be initialized by the price list setup. This information comes from the invoice header in the case of a direct invoice or the original document.

• Commission rate 2 (field REPRAT2)

• Comm. factor (field REPCOE)

This coefficient is used to weight the commissioning rate of the sales representatives for this document line upon commision calculation.
This information is initialized using the price list search: some price lists are used to define a weighing coefficient for the commissioning rate of the sales representatives.

• Requested delivery date (field DDEMDLVDAT)

This is the delivery date requested by the customer. This date is initially by the requested delivery date entered in the order header. The modification of this date will trigger the recalculation of the shipment date (Shipment date = Requested delivery date - Delivery lead-time) and will recalculate the planned delivery date (Planned delivery date = Shipment date + Delivery lead-time).

During the modification of this date, the system controls that this date does not correspond to a non-working day or an unavailable day for the delivery date. If this is a non-working day, the date is postponed, otherwise a warning message is displayed.
The system also controls that the entered date is lower than or equal to the Maximum delivery date entered on each order line. If it is not the case, a message is displayed suggestion to also modify the Maximum delivery date to the entered date.

Inter-company specificities: In the case of an inter-company or inter-site order generated from a purchase order, the requested delivery date will be initialized by the planned receipt date entered in the purchase order line.

• Lead time (field DDAYLTI)

This is the delivery lead-time in number of days for the ship-to customer. This lead-time is initialized by the lead-time determined in the order header. It is used to calculate the planned delivery date from the shipment date. If the delivery address is modified on the order line, the delivery lead-time will be re-initialized with the lead-time entered in the new delivery address which will also lead to the recalculation of the planned delivery date.

• Ship date (field DSHIDAT)

The shipment date is initialized by the shipment date entered in the order header. It is used to calculate the planned delivery date. It is calculated from the requested delivery date to the delivery lead-time is attached. If the shipment date is modified, the planned delivery date will then be recalculated by adding the lead-time to the shipment date entered.

During the modification of the shipment date, the system controls that:

• the date is included in the working days of the shipment site. If this is not the case, the shipment date is moved to an earlier date. 
• the date is not included in the unavailability days of the site. If this is the case a blocking message signals it.
• the date is not inferior to the date of the order. Otherwise, a blocking message signals it.

• Expected delivery date (field EXTDLVDAT)

This is the delivery date calculated by the system taking into account the shipment date and delivery lead-time.  If the planned delivery date is modified, the system will suggest that the user modifies the shipment date as a function of the delivery lead-time.

During the modification of this date, the system controls that this date does not correspond to a non-working day or an unavailable day for the shipment date. If this is a non-working day, the date is postponed, otherwise a warning message is displayed.

• Address (field DBPAADD)

The delivery address can be personalized in each order line if the general parameter (LINBPD - Ship-to Customer on Detail) allows it and if the shipment method for the order is not Complete order, in which case this information will not be modifiable on the order line.
The contextual button is used to select a delivery address for the customer and to access by tunnel this delivery address.

The modification of the delivery address of an order line has the following consequences:
- the delivery lead-time will be re-initialized by the delivery lead-time in the new delivery address. The shipment date will be recalculated taking into account the lead-time and the requested delivery address. The planned delivery date will also be calculated from the new shipment date and the delivery lead-time.
- if necessary, a message indicating that the product is prohibited for this new address, is displayed. If the user has no blocking control on prices (SDACLOK - Non block ctrl price, profit,qt user parameter), he may carry on regardless of the warning message.
- A dialog box opens and suggests that prices and discounts be re-calculated. The answer 'Yes' triggers a price list search according to the new delivery address.

Special features linked to the inter-company option: IIn the case of an inter-company order generated automatically from a purchase order, the delivery address corresponds to the ship-to customer associated with the receiving site entered in the purchase order. This information cannot be modified in the sales order. Only a modification of the original purchase order can update this information provided the order line is neither allocated nor shipped.

• Delivery contact (field CNDNAM)

This refers to the name of the contact associated with the delivery address. If the delivery address corresponds to the delivery address in the document header, the contact suggested by default on the line is the contact entered for the delivery address displayed on the header.
If the delivery address does not match the delivery address mentioned on the document header, the suggested contact is the business partner's default contact if it matches this delivery address. Otherwise, the system suggests the first contact of this address by alphabetical order on the contact code.

The quote lines applying to non-deliverable products are not impacted by this information.

• Location reference (field USEPLC)

This information is used to indicate the place of consumption or to define an addition to the address. For example: Dock x.

Special features linked to the inter-company option: In the case of an inter-company or inter-site order generated from a purchase order, the place of consumption will be initialized by the place of consumption entered in the purchase order line.

• Delivery priority (field DDLVPIO)

This information (initialized by the delivery priorities in the Delivery tab) is used to specify the priority of each line. This information is used to prioritize the preparation of certain order lines. It is used in the automatic allocation processing of orders. It is possible to allocate orders by priority level (e.g. to supply all orders when the stock is insufficient).

 If the delivery method for the order is Complete order, this information is not accessible at the order line level.

• Route no. (field DDRN)

This code, which is controlled by a local menu, is used to generate the delivery notes according to the route code defining for example, a geographic zone. This information is defined by the customer delivery address.

• Delivery mode (field DMDL)

This delivery method is used to define the information related to the transport and delivery.  It describes the manner in which the goods will be sent to the customer (this information is used notably in the Intrastat exchange of goods declaration). It is managed in the Delivery methods table. This information is initialized with the delivery method entered in the order header but it can be modified on the line if the order delivery method is not set to the value Ship order complete. If the delivery address is modified on the order line, the delivery method will then be reassigned by the value mentioned on the delivery address.

• Carrier (field DBPTNUM)

This is the carrier used to transport the goods to the customer delivery address. It is managed in the Carriers table. This information is initialized with the carried entered in the order header but it can be modified on the line if the order delivery mode is not set to the value Ship order complete. If the delivery address is modified on the order line, the carrier is reassigned by the value mentioned on the delivery address.

The carrier is used later on the delivery note in order to calculate freight in accordance with the delivery weight and volume.

• Preparation code (field PRECOD)

This field includes the preparation code. You can select this code from the Actions icon or enter it if it has not been set up.

• Packaging (field PCK)

This code is controlled in the packaging table and initialized by default by the corresponding code from the product-site record. 
It indicates the number of products, expressed in sales units, that the package can contain. The packaging code comes from the Product-Site record depending on the sales unit chosen. In the case of a line creation, if the unit chosen does not correspond to the sales unit of the product or to the customer sales unit, the packaging code and the capacity are not initialized. In this case, it is then necessary to manually enter them. This information remains modifiable and is used upon preparation or shipment of the product to carry out the packaging.
Upon declared packing, this code is specified only if it is present in the original document Deliveries or Picking tickets.
If granted the proper authorizations, the user can access the packaging record.

• Packaging capacity (field PCKCAP)

• Consumer sales price (field BPCSALPRI)

This field is subject to the EDIX3 activity code.
You use it to enter the final product price for the consumer.
On the BOM and 'free item' lines generated automatically, this amount is set to: 0

In the case of orders received by EDI, the BOM and 'free item' lines are not generated automatically. The final product price can be provided by the shipper for each line. The lines are then imported individually with the provided values.

• Exp. delivery time (field DEMDLVHOU)

The two fields Exp. delivery time and Max delivery time are initialized to the Exp. delivery time entered in the header.
The Max delivery time field is subject to the EDIX3 activity code.
As a general rule, these fields can be modified: you use them to define a delivery time slot.
In the following cases however, this information is automatically loaded and cannot be modified:

• on the automatically generated BOM lines where the values are identical to the ones on the component line,
• on the 'free item' lines where the values are identical to the ones of the product from which the free item originated.

• Max delivery date (field MAXDLVDAT)

This field is subject to the EDIX3 activity code.
It is initialized to the Requested delivery date and can be modified. The date entered must be greater than or equal to the Requested delivery date.
This information is loaded automatically and cannot be modified:

• on the automatically generated BOM lines where the values are identical to the ones on the component line,
• on the 'free item' lines where the values are identical to the ones of the product from which the free item originated.

In the case of orders received by EDI, the BOM and 'free item' lines are not generated automatically. Lines are imported individually. However, if a modification is applied to the component or source product of the 'free item', this modification will be also applied to the component and free item lines.

• Max delivery time (field MAXDLVHOU)

The two fields Exp. delivery time and Max delivery time are initialized to the Exp. delivery time entered in the header.
The Max delivery time field is subject to the EDIX3 activity code.
As a general rule, these fields can be modified: you use them to define a delivery time slot.
In the following cases however, this information is automatically loaded and cannot be modified:

• on the automatically generated BOM lines where the values are identical to the ones on the component line,
• on the 'free item' lines where the values are identical to the ones of the product from which the free item originated.

• Use-by date (field USELIMDAT)

This field is subject to the EDIX3 activity code.
If the product is managed in stock and the expiry date is also managed, this field is initialized as follows: Maximum delivery date (MAXDLVDAT) + Shelf life (SHL). The date is calculated based on the criteria of the calculation method set up in the Management field (EXYMGTCOD) at product level.
This date can be modified. This date must be greater than or equal to the Maximum delivery date.
If the expiry date is not managed, the field is blank by default.

• field CCE1

En fonction du paramétrage, les sections analytiques sont modifiables, celles-ci étant initialisées conformément au paramétrage des sections par défaut.

• Order status (field DEMSTA)

This flag is used to define the status of the order line which can be Firm or Planned. The Planned status is used to anticipate the firm orders to come because this information is used for requirement purposes in the MRP calculation. This flag is no longer modifiable if the order line has been allocated, delivered or invoiced. It cannot be modified if the line is managed with direct orders.

• If the order line has the status Firm (default value), it remains possible to allocate and deliver it.
• If the order line has the status Planned, it can neither be allocated nor delivered (its status needs to be modified manually to switch it to Firm).

• Product source (field FMI)

Use this field to choose how to cover the requirement expressed by the order line: in a normal way, using a receipt back-to-back order, a direct back-to-back order or a production back-to-back order.

Based on the product category and the setup of the product record (Sales tab), this field is initialized in the following way:

• If the product belongs to the Service , Non deliverable category, the product origin is Normal.
• If the product is not managed in a back-to-back order mode, the product origin is Normal : it is possible to deliver the order line from the available stock.

• If the product is managed in a back-to-back order mode, the default back-to-back order is dependent on the product category.

• If a product belongs to the Bought category, but not to the Manufactured category, the default back-to-back order is a receipt back-to-back order, except if the Direct quantity (Sales tab in the Product record) is populated. In that case, the default back-to-back order type is a direct back-to-back order if the ordered quantity is greater than or equal to the direct quantity.
  This type of back-to-back order (direct) cannot be used in an intercompany context.
  
  
• If a product belongs to the Manufactured category, but not to the Bought category, the default back-to-back order is a work order.
  
• If the product belongs to the Service category and its flow type is Bought, the only possible choices are Normal and Direct order.

• Back-to-back order no. (field FMINUM)

This is the purchase order number or the works order number when a back-to-back has been generated for an order line. This document is accessible from the Position function.

• Line amt. - tax (field LINORDNOT)

This is the unitary net ex-tax price for the line multiplied by the document quantity.

• Line amt. + tax (field LINORDATI)

This is the unitary ex-tax price for the line to which the different taxes entered have been applied, multiplied by the quantity of the document line.

• Line margin (field LINPFM)

This is the unitary margin multiplied by the quantity on the document line.

• Quote no. (field DETSQHNUM)

This is the quote number at the origin of the order line. To access the quote, click Quote from the Actions icon available on the order line.

• Line type (field LINTYP)

This information characterizes the line type by distinguishing a classic product from a kit or a BOM product.
It can take the following values:

• Normal,
• Fixed kit,
• Kit Component,
• Kit Option, Kit Variant,
• Flex kit,
• BOM component,
• BOM Option,
• BOM Variant.

• Free (field FOCFLG)

This information specifies whether the line concerns a free item or if the line is the origin of the generation of one or more free items.

• Closed (field SOQSTA)

This information specifies whether the order line is closed or still active. A line can be closed if it has been totally delivered (or totally invoiced in the case of direct invoicing orders or scheduled invoices) or if it has been manually closed.

A closed line is no longer available for modification. If the order is not completely closed, an order line can be un-closed if associated with a service contract.

• Closing reason (field DCCLREN)

This is the closing reason for the order line when this has been closed manually. The closing reason is loaded if the CCLRENORD - Enter order closing reason parameter is active. This reason can correspond to the order closure reason (if the order has been globally closed) or corresponds to the closing reason assigned during the closing of this reason. During the order closing this information can be entered in a list of predetermined values (see miscellaneous table Closing reason)

• Date closed (field DCCLDAT)

This is the date on which the closing of the order was manually carried out.

• To deliver excluding tax (field DLRNOT)

• To invoice excluding tax (field INRNOT)

• Margin (field PFMTOT)

Indicates the total margin of the order calculated based on the margin of the order lines.

• Lines excluding tax (field ORDNOT)

This is the aggregated tax excl. total for the lines. It is calculated by adding the quote lines. If the report DEVICLIENT is printed (Quote printed Ex-tax), the Ex-tax amount printed corresponds to the total Ex-tax amount.

• Excluding tax (field ORDINVNOT)

This field indicates the ex-tax result including the various invoicing elements entered in the order.
These information is displayed when printing the report ARCTTC2.
 The calculation detail is stored in tables SVCRVAT and SVCRFOOT.

• Including tax (field ORDINVATI)

This field indicates the tax incl. total, which includes:

• the various invoicing elements entered in the order,
• the tax calculation by tax basis.

This information appear upon printing of the ARCTTC2 report.
 The detail of the tax incl. calculation is obtained by right click on the total amount.The detail of the calculation is stored in the SVCRVAT and SVCRFOOT tables.

In order to access the 'Incl. tax Valuation' screen, click on the incl. tax field.

• Company name (field BPRNAM)

Business partner name.

• Address (field BPAADD)

• Country (field CRY)

This code is used to identify amongst other things, the Country of a BP.
This is important information, associated with a number of characteristics useful for performing controls on other linked information, in particular:

• the telephone number format,
• the format of the number used to identify a company or activity (SIRET, SIC) and whether the entry is mandatory,
• the postal code format of the town and also the code of the geographic subdivision, and whether their entry is mandatory,
• whether the VAT number of this community is mandatory,
• the Bank ID code format.

• field CRYNAM

Name of the country used in the addresses and in all the documents where the country code is entered.

• field BPAADDLIG

This table lists the various address lines. The formats of the title and of the entry are defined in the country table.

• Postal code (field POSCOD)

The postal code, whose entry format is defined in the Country table, is used to define the town/city and the geographical subdivision if it is defined for the country.
When the postal code is changed the city/town corresponding to the new code is automatically displayed. The principle is the same for the geographical subdivision if it is present for the country. 
It is also possible to manually enter the town/city name. If the town/city is already defined, the associated postal code is automatically displayed.

The control of this information and its mandatory nature depend on the setup performed in the country management. In order for the control to be applied, the POSCOD - Nonexistent postal code alert parameter (SUP chapter, INT group) must also be set to "Yes".

Specific cases:

- for ANDORRA, indicate 99130
- for MONACO, indicate 99138
- for the other overseas countries, indicate the INSEE code of the country or 99999 if not known.

• City (field CTY)

The city automatically proposed is the one associated with the postal code previously indicated. It is also possible to manually enter the name of a town/city:

• if the town/city is already defined, the associated postal code is automatically displayed, 
•  if the city does not exist and the postal code control has been set up in the Country record, a warning message is displayed but the continuation of the entry is authorized. In addition, the CTY - Nonexistent city alert parameter (SUP chapter, INT group) needs to have the value "Yes" for this control to apply.
• if the city does not exist and the postal code is not entered, a blocking message is displayed when the postal code is set up as mandatory for the country.

Notes:

• Its format is defined in the Country record setup.
• Depending on this setup, the entered town/city can automatically be converted into uppercase after it has been entered.
• In order to make selections easier without taking into account the format (accented characters/uppercase letters/lowercase letters), the selection window available on this field proposes a column dedicated to the search, where the names of the towns/cities are displayed in uppercase. The control which is carried out is case-insensitive since it is carried out with respect to the town/city name stored in uppercase.

• field ITINERAIRE

Click this icon to open a mapping site and locate the entered address.

• field SAT

This field contains the geographical SDL TEST subdivision corresponding to definition of the postal address. For example, a 'department' for France, and a state for the United-States.

The description of the geographic subdivision, as well as the control on the information entry, are defined in theCountries setup.

This field is automatically loaded after the postal code and town/city have been entered, based on the Postal codes setup.
If the field is controlled, the control is carried out according to the Geographical subdivision table.

• Site tax ID no. (field CRN)

The SIRET number of the site associated with the invoice customer is displayed if it has been entered on the BP record.
You can only modify this number when the invoice customer is a Miscellaneous one. The entered number must be compliant with the format defined on the Country record.

• Person to contact (field CNTNAM)

Contact number.

• EU VAT no. (field EECNUMX)

• Address validation (field VALADR)

Click on this button to send the entered address to the Sage Sales Tax (SST) address validation service. It is also possible to send the entered address by clicking on the [OK] button.

• If the address is found, the "Validated" checkbox is automatically checked.
• If the address is not found, the "Validated" checkbox is unchecked and cannot be accessed.

• This field is only available when the activity code Local tax (LTA) is active.
• The validation service of SST addresses is defined in the parameters related to Sage Sales Tax.

• Validated (field ADRVAL)

This box is checked automatically if the address is processed by the validation service of Sage Sales Tax (SST) addresses when the "Address validation" box is checked. The box is not checked and cannot be accessed if the address is not found.

• This field is only available when the activity code Local tax (LTA) is active.
• The validation service of SST addresses is defined in the parameters related to Sage Sales Tax

• Incoterm (field XEECICT)

• Incoterm town (field XICTCTY)

• Freight agent (field XFFWNUM)

• Forwarding agent address (field XFFWADD)

• EU VAT no. (field XEECNUM)

• Intrastat transp. location (field XEECLOC)

• Intrastat transport mode (field XEECTRN)

• Transaction nature (field XEECNAT)

• Statistical rule (field XEECSCH)

• Transaction nature (field XEECNATR)

• Statistical rule (field XEECSCHR)