Use this function to validate the sales orders integrated in the database through a 'mutation' using the GraphQL API.
After they are integrated, these orders are saved as drafts: they can no longer be accessed from the Orders function and cannot be run through any functional processing. To manage these drafts orders as you would standard orders, you need to validate them, which means subjecting them to a series of controls, initialization and valuation processes.

At the end of the processing, some orders will be validated, but others may be rejected. In this case, you need to use the Rejected draft orders function to either delete the rejected orders, or reinstate them in the validation circuit after correcting the errors in the setup and common data.

Prerequisites

SEEREFERTTO Refer to documentation Implementation

Screen management



Entry screen

In this screen:

  • Enter the selection criteria for the draft orders to be validated.
  • Click OK to launch the processing.

Selection

Company (field CPY)

Enter the company for which the process needs to be completed. This information is mandatory.

It is initialized by default with the site associated with your function profile.

Sales site (field SALFCY)

Enter site for which the process needs to be run. This information is mandatory.

By default, the sales site linked to your function profile is displayed.
From customer (field BPCORDFROM)

Enter a start and end range to apply a filter to the customer codes selection.
To only select one customer, enter the same code in the From and To fields.


 
To customer (field BPCORDTO)
Start date (field ORDDATFROM)

Date from which the draft orders are selected. This date is optional.
End date (field ORDDATTO)

Date until which the draft orders are selected. This date is mandatory. Today's date is displayed by default.
From order no. (field DRAFTORDFR)

These fields are optional. You use them to select a range of draft orders to be processed.
To order no. (field DRAFTORDTO)

Prerequisites to the process

The following conditions must be met for the validation process to be successful:


Prerequisites:

  • The sales Order type is not supported and communicated by the API. The sales order type used is the one defined in the SOHTYPAPI - Draft order type parameter (VEN chapter, ORD group). This parameter must be entered. The order type must be linked to the 'Normal' category.

The following information must be communicated by the API:

  • Order number. This number is mandatory, even if it has been replaced with the sequence number of the order type defined by the SOHTYPAPI - Draft order type parameter.
  • Sales site
  • Sold-to customer
  • Product
  • Ordered quantity in sales units. This quantity must be higher than zero.
  • At least one line must be entered.
  • Line number. This number is reassigned upon validation, by applying the standard rules.

The following information can be communicated by the API, but it is optional:

  • Shipment site
  • Bill-to customer
  • Currency
  • Payment term
  • Tax rule
  • Delivery address
  • Date of the order
  • Sales unit
  • Gross price If this information is not communicated, or if the communicated value is zero, the price will be determined through the price list search launched upon validation.

Limit

  • The GraphQL API does not manage sales BOM in details: only the parent product is integrated. Components cannot be included. They are generated when validating the draft order.

Validation processing description

  • Selecting orders

    The sales draft orders integrated in the application are recorded in the tables of sales orders: SORDER, SORDERP, SORDERQ. These orders are identified in the SORDER table by the DRAFTSTATUS field whose value is different from zero.
    The processing only applies to the identified draft sales orders that meet the entered selection criteria.
  • For each processed order:
    • The missing information is added, based on the mandatory information entered on the draft order.
    • All the processes required for the creation of a sales order are run:
      • Generation of the BOM components
      • Generation of the free products
      • Tax determination
      • Price list search: determines the charges and discounts, and the discount reasons.
      • Grouped prices
      • Invoicing elements management and distribution on the lines
      • Tax calculation
      • Order valuation
      • Signature management
    • The same functional control apply than when creating an order.

Reminder:

  • The order number uses the sequence number of the order type defined by the SOHTYPAPI - Draft order type parameter.
  • The considered gross price is the price communicated on the draft order, if different from zero. If it is not specified or equal to zero, its value is loaded by the price list search run during the validation process.

Once the processing is complete, a log file displays the list of validated sales orders.

You can inquire the non-validated or rejected orders from the Rejected draft orders function. You can also use this function to manage the rejected orders, by either deleting them or reinstating them in the validation circuit after correcting the errors in the setup or common data.
Non-validated orders can be identified by the value '2' displayed in the DRAFTREJ field and by the rejection reason displayed in the DRAFTREJREN field of the SORDER table.

Batch task

This function can be run in batch mode. The standard task SOHDRAFT is provided for that purpose.

Specific actions

Click this action to save the current settings to a Memo code to be reused later. The memo is linked to your user profile, not to the function or the screen.

The STD memo code is associated with the screen and is loaded immediately when you open the function.

For more information on the advanced use of the Memo action, refer to the documentation on the General ergonomics of SAFE X3 software.

Click this action to enter a Memo code to load the settings associated with the code.

Click this action to delete a Memo code.

Local menus

The only error messages are the generic ones.

Tables used

SEEREFERTTO Refer to documentation Implementation