Sales > Orders > Open orders 

The purpose of this function is to manage (create, modify, delete, view, print) open order contracts.

An open order is a long term commitment with a customer concerning one or more products, for a global quantity to be delivered with delivery requests that are made according to the request. An open order is made up of a line header and a delivery schedule.

In an open order, the following elements are specified:

  • the customer and commercial conditions,
  • the open order validity start and end dates,
  • the list of products with, for each product a global quantity, a price and validity dates (start-end).

Each open order can contain several lines concerning different products whether they are managed in stock or not.

The delivery schedule (see the documentation on Delivery requests) is used to define:

  • the firm delivery requests,
  • the provisional delivery call-offs.

When the approvals management is activated (APPSOC parameter), an open order cannot be the subject of a delivery request as long as the order remains unsigned.
Management conditions linked to the approval circuit are specified at the Workflow rules level on open orders (see below).

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

The presentation of the entry screen depends on the setup of the selected transaction.

If a single transaction has been set up no choice is suggested, when more than one exist a window opens and displays the list of parameters likely to be used.

The sales open order management is carried out over two screens: the first brings together the general information (customer, discounts and charges...). The second screen brings together the information concerning the open order lines. It can be accessed by using the [Products] button.

Entry screen

Presentation

This tab is used to identify the commercial conditions that are found in the open order header such as the payment conditions, bill-to customer, the discounts and charges, etc.

Most of this information is initialized by default from the customer record and can be modified. According to the transaction used, it is possible that it is not accessible. In this case, it is the default initialization value that is automatically taken into account.

Specificities linked with the inter-site: if an open order has an inter-site open order as its origin, no information can be modified.

The information displayed in this tab is:

Order type

The order type is used to determine the order category (only the open order types can be selected) as well as the sequence number counter used. A selection button is used to select an order type from the list of open orders. This information is compulsory.

If the order sequence number is manual, it is also possible to enter an order number, if not it will be assigned automatically at the end of creation.

Sales site

The sales site code is initialized by the sales site associated to the user profile and can be modified on the condition of being selected from the list of authorized sites. This information is compulsory. It can no longer be modified once the order is saved.

Customer reference

This information is used to specify the customer order reference. This information is also used when several open orders exist concurrently for a customer for a single delivery address, when this information is loaded and when it differs between contracts, to save the identical product lines over several open orders.

Special features linked to the inter-company : In the case of an inter-company or inter-site sales open order generated from a purchase order, the purchase order number will be entered in this field and will not be modifiable, and a tunnel will allow access to the purchase open order at the customer site.

Order date

The open order date is initialized to the current date and can be modified. This information is compulsory.

Special features linked to the inter-company : In the case of an inter-company or inter-site sales open order generated from a purchase order, the order date is equal to the purchase order date. This information cannot be modified in this context.

Revision

This is the last revision number established for this open order. It is automatically incremented at each modification of the open order if the SALREV parameter (Revision management is set to Yes) and if the user confirms that the modification that they are carrying out is the object of a revision.

Sold-to customer

The selected sold-to customer must be active. From this field, a contextual button is used to:

  • select a customer,
  • access and create a customer, according to the user authorizations.

Special features linked to the inter-company : In the case of an inter-company open order automatically generated from a purchase order, the Sold-to customer corresponds to the customer associated to the purchase site entered in the purchase order. It cannot be modified in this context.

Inter-sites / Inter-companies

This non-modifiable information specifies if the open order is of the type inter-site or inter-company. When the open order concerns an inter-site customer (site in the same company) it cannot be invoiced. When the open order concerns an inter-company customer (site of a different company), an invoice can be generated from the deliveries resulting from this order.

Bill-to customer

The bill-to customer code must be active. In all cases, it is initialized by the bill-to customer code associated to the sold-to customer in the latter's record. This information is compulsory. There 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 created, this field will no longer be accessible.

During the invoicing of the delivery requests associated to this open order, the invoicing method used will be the one coming from the bill-to customer upon creation of the open order header. If the invoicing method is One invoice by complete order, then it will be considered that for open orders it corresponds to One invoice per order (in this case all the deliveries linked to the delivery requests for the open order will be grouped together), this invoicing method not being adapted for this method of management. In fact, the deliveries for this open order will only contain the delivery requests for this order.

Special features linked to the inter-company : In the case of an inter-company open order generated automatically from a purchase order, the Bill-to Customer corresponds to the customer associated to the invoicing site entered in the purchase order. It cannot be modified in this context.

Pay-by customer

The pay-by customer is subject to the same conditions as the bill-to customer. There is the possibility to modify the pay-by 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.

Special features linked to the inter-company : In the case of an inter-company open order generated automatically from a purchase order, the Pay-by customer corresponds to the customer associated to the invoicing site entered in the purchase order. It cannot be modified in this context.

Group customer

The group customer is initialized by the group customer code associated to the sold-to customer in the latter's record. This information is notably used in 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.

Validity date

This is the validity end date for the open order. The products invoiced with the open order can have a validity date different to that of the open order, but this must be less than or equal to the open order validity date.

Special features linked to the inter-company : In the case of an inter-site or inter-company open order generated automatically from a purchase open order, the Validity date corresponds to the validity end date entered in the purchase open order.

Payment terms 

The payment condition is initialized by the bill-to payment conditions, but it remains modifiable. A button accessed by right clicking on this data is used to access the different payment conditions or to carry out a simulation of the open item calculation.

Allocation type

The allocation type is initialized as a function of sales setup >ALLTYP Type allocation and can still be modified. This information is used to specify the level of detail for the allocation that will be carried out during the allocation of the delivery requests associated to the lines in this contract.

Currency

The currency is initialized by the customer currency, but remains modifiable. It can no longer be modified once the open order is created.

Exchange rate type

The exchange rate type is initialized by the exchange rate type of the bill-to customer, but it remains modifiable.

Tax rule

The regime is initialized by the tax regime of the sold-to customer, but it can still be modified. There is the possibility to access the tax regime table depending on the user authorizations.

Credit status

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

The customer credit status is Blocked, when the customer record shows that the credit status is blocked.

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

As for the allocation of the delivery requests associated to the open order, if a delivery request is allocated where the calculated customer credit level is superior to the authorized credit level, the user will get a message requesting confirmation if user parameter SCDTUNL authorizes it, if not it will not be possible to allocate the delivery request and a blocking message will be displayed.

If the customer credit is blocked, it will not be possible to allocate the delivery requests associated to the open order and it will not be possible to create new open order for this customer.

Price type

The price type is initialized by the price type of the sold-to customer (Ex-tax/Tax incl), but it is modifiable.

Dimension types

Dimension types are initialized depending on the default dimension code associated to the management of open order, but they are modifiable. This information can be mandatory if the accounting setup requires it.

Special features linked to the inter-company : In the case of an inter-site or inter-company open order, the setup of the default dimensions code SOR, will be used if required, to transfer the analytical dimensions, for certain types, entered in the purchase order header.

Invoicing elements

Information related to the invoice footer. This information can directly come from the footer elements or from the customer record concerned by the order (see the Invoicing elements documentation). The footer values can be modified.

Special features linked to the inter-company : if the open 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 Purchasing, these will be initialized with the values entered in the original purchase open order.

Close

 

Fields

The following fields are present on this tab :

Block number 1

The sales site is loaded by the default sales site associated to the user’s Function profile. 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.

  • Order no. (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.

  • field REVNUM

This is the last revision number established for this contract. It is automatically incremented upon each modification of the contract if the SALREV parameter (Revision management) is set to Yes) and if the user confirms that the modification that they are carrying out is the subject of a revision.

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

The order date is initialized to the current date and can be modified (only in creation mode). The modification of this date during the creation leads to the display of a message offering the possibility to update the prices and potential discounts calculated for the order lines already entered. This modification also leads to the update of the expected receipt date of the order lines for which no requirement has been consumed.

This field indicates the customer identifier code. 

BP

It is the code for the bill-to customer, which is initialized by default with the customer code entered in the header.
This customer can be another customer chosen from the customer table.

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.

This field is used to enter the pay-by customer code, initialized by default to the customer code entered in the header. The invoice payment schedule will be allocated to this BP.
SEEINFOThis customer can be another customer chosen from thecustomer table.

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.

  • Intersite (field BETFCY)

This non-modifiable information specifies if the contract is of the type inter-site or inter-company.
When the contract concerns an inter-site customer (site of the same company), it will not be possible to invoice said contract.
When the contract concerns an inter-company customer (site of a different company), it will be possible to generate an invoice from the deliveries coming from this order.

  • Intercompany (field BETCPY)

This flag is designed to indicate if this is an inter-site BP:

  • The inter-site customer/supplier BPs are used for multi-site exchanges.
  • A customer BP is a purchase site or a financial site,
  • a supplier BP is a sales site or a financial site.

Management

The management of the project code depends on the value of the CTLOPPCOD - Mandatory project control parameter (TC chapter, MIS group).

  • When the value is No, it may be a code selected freely.
  • When its value is Yes, an existence check is systematically applies to the entered project code.

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

The project allocation code is composed of:

  • The project sequence number for projects.
  • The concatenated project sequence number with the budget batch code for a project budget batch.
  • The concatenated project sequence number with the number of tasks for 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 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 transformation 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 dialog 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 applied to all lines, excluding lines linked to a billing plan and lines with an incompatible milestone.
  • 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 dialog box opens and suggests a recalculation of prices and discounts If you answer 'Yes', the price list search is run based on the new project code for all document lines. 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 (for standard orders) or not invoiced (for 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 this case, two orders with a distinct project code can be grouped on the same delivery note.


Deliveries linked to a task:

The header project code displays the project code linked to the first selected task.

  • If multi-project management of documents is enabled (PJTSNGDOC - One project per document parameter set to No), the delivery can include direct delivery lines and product lines linked to tasks. The header project code is used as the default value on direct delivery lines only. Product lines linked to tasks keep their project code, which cannot be modified. If the header project code is modified, the application of this code to the lines is suggested, as described above. This only applies to direct delivery lines.
  • If multi-project management of documents prohibited (PJTSNGDOC - One project per document parameter set to Yes), the delivery cannot include both direct delivery lines and product lines linked to tasks.
    • When the delivery is for direct delivery lines, you cannot enter a project code in the header that is already used on tasks.
    • When the delivery is for product lines linked to tasks, you can only enter product lines linked to the same task. The header project code can then be used to filter tasks in the selection panel.

Specific case of free items generated by the price list search after updating the header project code: The free item displays the project code of its source product but only if this code is not used on a task.

Intercompany specificities: For an intersite order, the project code automatically displays the project code of the purchase order. For an intercompany open order, the project code is not recovered from the purchase order and remains blank.
  • Validity date (field VLYDATCON)

End date for the contract validity.

Code associated by default with the current BP, used to define the payment conditions.
This code defines the payment method, open item type, as well as the payment schedule (one or several open items cash, 30 days, end of month etc.).
When managing this table, it is possible to simulate the calculation rules that will be applied in entry mode.

Code associated by default with the current BP, used to define the payment conditions.

This code defines the payment mode, open item type, as well as the payment schedule (one or several open items cash, 30 days, end of month etc.).
When managing this table, it is possible to simulate the calculation rules that will be applied in entry mode.

Only a discount code consistent with the legislation and company group of the document site can be entered.
SEEREFERTTOThe general principles linked to the multi-legislation setup are detailed here.


This information is entered in the quote and it is initialized by the discount code in the bill-to customer. It makes it possible to determine a series of early discount rates or late charges to be applied depending on whether the payment is early or late with respect to the due date.
Only a discount code consistent with the legislation and company group of the document site can be entered.
SEEREFERTTOThe general principles linked to the multi-legislation setup are detailed here.

SEEINFOIf the quote involves a prospect, this information is not initialized.

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

If this has not been specified:

Tax/Currency

This is corresponds to the currency of the order, delivery or invoice.
It is initialized by default with the bill-to customer currency and can be modified. In this case, it can only be modified in creation and duplication modes and is controlled in the currency table.

It is possible to choose the currency for the delivery transaction as well as to define (depending on the value of the 'Excl. tax and Incl. tax Prices' parameter - TC Chapter / INV/NOTATI group) if the prices are expressed excluding tax or including tax. When the delivery comes from an order, this information is automatically loaded and cannot be modified. When it is a direct delivery, this information is no longer modifiable once at least one delivery line is entered. It is inherited in this case from the invoiced customer information.

  • Rate type (field CHGTYP)

This field is initialized by the customer invoice exchange rate type.
It is controlled by a modifiable local menu and can take, amongst others, the following values:

  • exchange rate of the current day,
  • exchange rate of the current month,
  • average exchange rate.

This field is used to indicate the tax rule.

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

Rules are sorted according to rule type (in the BP tax rule, GESTVB function) in order to identify the various operating modes.

The tax rule is set up at BP level. The rule set up on the customer record or supplier record is suggested by default for all the transactions involving this BP.

As a general rule, crossing a tax rule with a tax level makes it possible to determine the tax code to be applied on the document line and as a consequence on the entry line.

In the tab BP/Company of this BP, it is possible to define different default tax rules according to the company. When a value does exist for a company, this value is suggested first.

Only a tax rule with a legislation and group that are consistent with those of the document can be entered.
SEEREFERTTO 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.
  • 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).
    SEEINFO In the last two cases, modifying some document fields (see the list of the Approval rules documentation (SQHSIGfor 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 (APPSQHAPPSOH 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).

  • Credit status (field CDTSTA)

Among the suggested selections:

  • 'Blocked': The customer credit status is Blocked, when the customer record shows that the credit status is blocked.
  • '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.

Concerning the allocation of the shipment requests associated to the contract order, if a shipment request is allocated where the calculated customer credit level is greater than the authorized credit level, the user will get a message requesting confirmation (if the user setup SCDTUNL authorizes it).
If not it will not be possible to allocate the shipment request and a blocking message will be displayed.
If the customer credit level is blocked, the delivery requests associated to the contract order cannot be allocated and new open orders for this customer cannot be created.

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

Allocation

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

Grid Analytical

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

  • Description (field NAMEDIE)

This field repeats the title of the dimension type.

Based on the setup, the dimensions care be modified since they are initialized according to the setup of the default dimensions.

Grid Invoicing elements

  • Description (field SHO)

Enter the short description.

By default the short title, the long title or the column header of a data are recorded (on creation/update) in the connection language of the user.
You can add your translation in another language using the Translation function:

  • Click Translation from the Actions icon in the corresponding field.
  • In the Translation window, add a new language code with the translation in this language.

A user who logs on with this language will view the short description, long description or column header in their connection language if a translation exists. Otherwise, these descriptions will be available in the folder language.

SEEINFOThe connection language must be defined as a default language for thefolder.

  • % or amount (field INVDTAAMT)

The values relate to the invoicing footer. This information can directly come from the parameters of the invoice footer or from the customer record.
SEEREFERTTO Refer to the Invoicing elements documentation for more information.
The values of the footer elements can be modified. The ex-tax and tax-incl. amounts of the document are directly impacted by these values.
Intercompany specificities
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.

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

Close

 

Reports

By default, the following reports are associated with this function :

 ARCCLIOUV2 : Customer open order acknowledgement

This can be changed using a different setup.

This setup is performed at the Customization level of the current object, by associating a report code or a print code to it.
It is possible to further specify this setup:

  • By specifying a given report at transaction entry level. If this report matches a print code, the list of reports associated with this print code is also submitted.
    The report entered at transaction entry level and the reports associated with the print code are automatically submitted in creation mode only.
  • At a more detailed level, by associating a print template with the BP. This template mentions the report to be used in priority for the printing of each document, as well as the expected number of copies.
    SEEINFOIf the number of copies is not specified, or if there is no print template associated with the BP, the number of copies defined for the Destinationprinter is chosen. If the number of copies is not specified for the destination printer, then a single copy is printed by default.

Menu Bar

This button is used to access the list of products making up the open order.

Menu bar

Texts/Header text

This menu is used to enter an open order header text. This text will be printed on the open order acknowledgment. The header text can be initialized, depending on the SALTEXORD setup, with the Order acknowledgment text entered in the customer record.

Text / Footer Text

This menu is used to enter an open order footer text. This text will be printed on the open order acknowledgment. The footer text can be initialized, based on the SALTEXORD setup, with the Order acknowledgment text entered in the customer record.

Option/Transaction

This function is used to view the open order entry transaction that is being used.

Option/Entry traceability

This option gives access, via tunnel, to the inquiry function Entry traceability that makes it possible to visualize and browse into the hierarchy of original entries or coming from the document.

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

Record that already exists

This message only appears when creating a record. The code that you have attempted to create exists already in the table. You can check this by using the selection window.

Record does not exist

This message only appears when searching for a record. The open order that you are searching for does not exist in the table. You can use the selection window to facilitate the search.

Problem with the recovery of the sequence number counter

This message appears if the sequence number counter has not been recovered. The sequence number counter setup does not exist.

The following messages can appear during the activation of the Create/Save/Delete buttons for the open order:

Modification with revision?

This message appears on the activation of the modification button. This is used to increment the revision number and archive the open order before modification.

This contract cannot be deleted: it contains delivery requests

This message appears if an attempt is made to delete an open order that contains delivery requests.

This contract is no longer active

This message appears if the validity date of the contract is exceeded. It is then impossible to create, modify or delete the record.

Setup of the signature rules does not exist for the company

This message appears during the entry of the order site, when the signature management is active and no setup exists for the signature rule for the legal company to which the order site is attached.

Order approved. Modification?

This message is displayed when modifying some fields whereas the document has been partially or totally approved. The posting of the modification does not trigger the update of the approval circuit. The existing approvals are kept.
The list of fields which modification has an impact on the approval circuit is given in the Workflow rules documentation SOCSIG - open order signature management.

Existing approvals canceled

This message is displayed when adding/deleting a line or when modifying some fields whereas the document has been partially or totally approved. The validation of the modification will result in the cancellation of the existing signatures and the initialization of a new circuit.
The list of fields which modification has an impact on the approval circuit is given in the Workflow rules documentation SOCSIG - open order signature management.

Taxes have not been correctly defined.

This warning or blocking message is displayed when inconsistencies are reported on:

  • the tax codes of the document lines,
  • and the tax codes of the document invoicing elements.

The consistency check on tax codes is performed based on the value of parameter CTLTAX - Tax codes control (VEN chapter, VAT group - no control, non blocking control, blocking control).

After the message is displayed, a log file details the errors that occurred during the consistency check.

Tables used

SEEREFERTTO Refer to documentation Implementation