Use this function to manage the delivery requests sent in the framework of an open order. You can thus create, modify, delete, copy, view, and print delivery requests.

An open order contract is a long-term commitment with a supplier for one or multiple products and for a global quantity to be delivered, where delivery requests are sent based on the demand. An open order is made of:

  • a contract, managed in the Open order function,
  • and a delivery schedule, managed in this function.

In the contract, you need to define:

  • the supplier and sales conditions,
  • the open order validity start and end dates,
  • the list of products with a global quantity, price and validity date range for each product.

In the delivery schedule, you define:

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

Inter-company specificities: The purchase delivery requests made under the terms of an inter-company contract generate sales delivery requests at the supplier site. These delivery requests cannot be modified in sales.

The reference date used in the calculation of delivery requests is taken from the requested delivery date.

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

The entry screen of delivery requests cannot be set up. It is composed of:

  • a selection panel displaying the contract lines,
  • a section displaying information on the contract line concerned,
  • a table used to enter the delivery schedule through firm and/or planned requests.

To enter a delivery request, select the line of the contract that the delivery request corresponds to in the selection panel of the screen. The top section displays the main information on the contract line and entries must be done in the table.

Entry screen

Displayed information

The information displayed come from the selected contract line. This is essentially made up of the fields used to identify the contract (Site, Supplier and Contract date), as well as the product selected in this contract (Product, Receiving site, Validity end date, Planned quantity, Inter-site, Inter-company etc.).

Header information

Case of the inter-site reorder contracts: You can create inter-site contracts to manage reorders between sites. To do so, you need to register the sites as customer BPs and/or supplier BPs. Requesting sites are referenced as Customers and reordering sites as Suppliers.

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

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

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

Information related to the product line

This information comes from the product line associated with the purchase contract, and it is not modifiable from the delivery request management.

Besides, other fields are updated automatically and make it possible to know the early/late quantity (for all firm lines) and its date of calculation.

Request lines table

Use this table to enter all request types included in the delivery schedule. Enter at least the period and quantity.

You can initialize the lines by clicking Requirements from the Actions menu. Purchase requests can indeed be consumed through the picking of requirements.

Request period

In this field, enter the date or period related to each delivery request. The format of the entered values is controlled as follows:

  • DDMMYY or DDMMYYYY for a daily request,
  • WWWYY or WWWYYYY for a weekly request,
  • MMYY or MMYYYY for a monthly request.

The weekly or monthly requests are automatically considered as planned (status non modifiable), whilst the daily requirements are proposed by default with the status firm/modifiable.

Firm requests and planned requests must be included, respectively, in the firm horizon and planned horizon defined at the contract level.

Delivery request lines must be entered in chronological order.

For products managed in stock, it is possible to take into account the suggestions arising from the MRP processing or those from the reorder or planned requirements calculation (purchase requests).

When there are purchase suggestions for the product, a window automatically opens to propose the taking into account of the requirements. If you do not want to take into account the requirements, exit this window to return to the line entry.

If you wish to take into account the requirements, a date range can be entered in order to limit in time the suggestion: the suggested maximum date is calculated according to the firm and planned horizons defined in the contract and no date later than the suggested date can be entered. You must then enter the unit in which the requirements quantities must be expressed: by default the stock unit is suggested. It can be modified provided the new unit is selected from the unit list suggested in the selection. Requirement lines are then displayed with, for each one:

  • the requirement date, the site, the buyer's code,
  • the requirement quantity as well as the considered quantity,
  • various information such as the BP, type and the order number in the WIP, etc.

Only the requirements of the receiving site are suggested. No control is applied based on the product-supplier or product-supplier-site referencing.

After entering the unit, you can automatically enter the quantity to be taken into account, which is the only information that can be entered on this screen. If you wish to sort the suggested list by requirement date or by site, you must exit the entry mode and use the Actions icon in order to choose the required sort.

The suggested quantity taken into account can be modified on the condition that the quantity entered is less than or equal to the requirement quantity, which can be the case if, for instance, you wish to take into account only part of the requirement. If you wish to exclude requirement lines, enter a null quantity.

Notes

The entry of delivery requests is made in a grid, the user can enter several lines. At the end of a line entry, you can automatically enter the next line. At this stage, you can return to the entered line and use the Actions icon that will offer various choices depending on the order status.

In the case of a firm request, you can:

  • view the budget detail,
  • return to the requirement consideration window (if requirements exist),
  • close the request line,
  • enter text.

In the case of a planned request, you can:

  • return to the requirement consideration window (if requirements exist),
  • enter text,
  • close the line in the case of a daily request,
  • split the request with respect to the splitting rule entered at the contract level, while still having the possibility to modify this rule in contextual mode. This option is used to distribute a weekly request over n daily requests and a monthly request over n weekly requests. This type of process on the planned requests must be carried out in chronological order of the requests.

According to the defined setup, the budget control can be carried out at the level of each line or at the end of the entry.

At the end of a line entry, a warning is given when the budgetary control on the line has been activated and a budget has been exceeded. This message can be blocking or constitute a simple warning according to the choice made for the parameter BUDCNTPRP - Commitment control type (chapter BUD, group CMM). A similar message can be displayed on final recording.

In addition, when the update of commitments is active, this is carried out automatically by clicking Create to enable the delivery schedule to be saved.

Modification

A delivery request can be modified whilst it is not yet totally complete and whilst it has not been received. Similarly, for each delivery request line, the modification is possible whilst the line has not been closed.

On each line, the Actions icon provides options similar to the creation options: view the budget detail, take the requirements into account, split the request, close the line or modify the associated text.

Different warning or blocking messages can be displayed depending on the fields you are modifying:

  • If the user attempts to modify a received delivery request, a blocking message will be displayed.
  • If you attempt to close a line that is already closed and not received, a message appears suggesting you cancel the closing of this request line.
  • If you modify the suggested quantity after taking into account requirements for more than one purchase request, and the quantity entered is less than the considered quantity.
    However, if the requirements taken into account only apply to one purchase request, then the quantity can be reduced.

Inter-company specificities: In the case of an inter-company contract, any modification to the purchasing delivery request will be transferred to the sales delivery request. In this way, when a firm or planned delivery request is added to the purchase side, the reciprocal on the sales side will be created.

Deletion

A delivery request can be deleted provided it has not been received. Otherwise, a message is displayed when you click Delete.Similarly, for each order line, deletion is possible while the line has not been received. In addition, the deletion is impossible once the delivery request is closed.

Block number 1

Contract site (field POHFCY)

The site code for the contract is initialized by the purchase site associated with the function profile of the user. It can be modified provided it is chosen from the list of authorized sites.
Contract no. (field POHNUM)

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

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

When you copy a purchase order and its order date is different from the current date, a messages suggests that you recalculate the prices and discounts according to the new order date.

This is the contract number used in the creation of the delivery requests.
Line (field POPLIN)

This is the purchase order line.

For an open order, the purchase order line corresponds to the product line.
Revision no. (field REVNUM)
Supplier (field BPSNUM)

Enter the supplier at the origin of the receipt. The selection lists specific to the intersite and intercompany orders and deliveries available for receipt are filered to those related to the entered supplier.

From the Selection icon, you can:

  • select a supplier from the list of active suppliers.
  • access, based on your authorizations, the supplier record, and create a new supplier if necessary.

This field is loaded according to the supplier specified in the contract.

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

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

A warning message can be displayed in this context if the customer associated with the purchase site is blocked. The generated sales order will display a blocked status. The inter-site orders are not themselves concerned with this operation. The WIP order book is not managed for the internal flows.
field XBPRNAM
Internal reference (field ORDREF)

The internal reference matches the one entered in the contract header.
Date of contract (field ORDDAT)

The contract date matches the one entered in the contract header.

Intercompany (field BETCPY)
Intersite (field BETFCY)
Order ack. no. (field OCNNUM)

This field uses the acknowledgement of receipt number indicated on the source purchase contract.

Inter-company specificities: within the framework of an inter-company contract, the purchase contract acknowledgement number matches the mirror sales contract number. In the case of an inter-company delivery request, this sales contract number is loaded in this field.
Sales site (field SALFCY)

Product

Product (field ITMREF)

The product code is initialized from the selected product line in the contract.
field ITMDES
Product type (field ITMKND)

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

A product of the Standard type is a 'physical' product, whether managed in stock or not. A product of the Service type is a product not managed in stock and of the Service category.

The presence of this field depends on the entry transaction used.
Major version (field ECCVALMAJO)

This field displays the major version of the product.
Minor version (field ECCVALMINO)

This field displays the minor version of the product.
Supplier product (field ITMREFBPS)
Receiving site (field PRHFCY)

This field is used to specify the site where the goods must be delivered by the supplier. The receiving site comes from the original purchase contract.

Inter-company specificities: when the purchase contract is of inter-site or inter-company type, the receiving site in the purchase contract is initialized with the receiving site entered in the default delivery address for the order customer associated with the purchase site of the purchase contract.
If the default delivery address associated with the customer defined by the purchase site does not specify the receiving site, then the first delivery address is used, in alphabetic order, to identify the receiving site.
Ship site (field STOFCY)

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

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

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

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

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

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

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

Advance/Delay

Early/Late qty. (field XEARQTY)

This quantity is incremented by the quantity of the delivery requests that meet the following criteria:

  • The order status is 'Firm'
  • The delivery requests are not received and not closed
  • The requests planned receipt date is earlier than the current date

The quantity is decreased when a delivery request is received, closed or when the order status is no longer set to 'Firm'.
Unit (field PUU)
Early/Late date (field XEARDAT)

This date corresponds to the earliest of the two following dates:

  • Current date
  • Validity end date of the open order line.
Time (field XEARHOU)

Block number 4

Expected PUR quantity (field EXTQTYPUU)

The planned quantity corresponds to the planned quantity entered in the product line at the level of the original purchase contract.STOP
Validity end date (field ENDDAT)

This field contains the validity end date for the product in the contract.

Grid

Demand period (field WRCPDAT)

This information is used to fill the request date. This date can be entered in various ways:

  • Date: DDMMYY or DDMMYYYY
  • Week: WWWYY or WWWYYYY
  • Month: MMYY or MMYYYY

If commitment management is activated for delivery requests and if the request is a firm one, the commitment date will be equal to this date if general Purchase parameter PURCMMDAT - Commitment date (chapter ACH, group CMM) is set to Order.

When a delivery request had been recorded, it remains possible to modify this date from the moment that it is not prior to the previous delivery request and later than the next delivery request. If this date is modified, the commitment date will also be updated.

The entered date can be prior to the current date provided it is later than the contract date. A warning message will signal this.
Status (field LINSTA)

This field is displayed only. It is used to identify the line status that can be pending, closed etc. 

Order status (field WIPSTA)

This field controlled by a local menu contains the status of the order associated with the delivery request:

  • firm
  • planned
    A weekly or monthly request is always of planned type.
Major version (field ECCVALMAJ)

The version numbers remain modifiable on the lines as long as the delivery request has not been received.
Minor version (field ECCVALMIN)
PUR quantity (field QTYPUU)

Specify the quantity for the product to be ordered in purchase unit. This information must be entered.
In effect, an error message appears immediately if the order quantity is blank.

The user will also obtain an error message when:

  • The user modifies the suggested quantity after taking into account requirements including more than one purchase request and the quantity entered is less than the quantity taken into account.
    However, if the requirements consideration only applies to one purchase request, the quantity can be reduced.
  • The quantity entered is less than the minimum quantity demanded by the supplier, as stated in the product record. The level of control is defined by the POHMINQTY - Minimum order qty control parameter (ACH chapter, AUZ group).

From the Quantityfield, use the Actions menu to run specific stock queries.
Receiving site (field XPRHFCY)

The receiving site is initialized to the receiving site defined at contract level and it can be modified except in the inter-company cases where the receiving site corresponds to the receiving site in the product line.

From the Receiving site, the user can:

  • Directly enter a site code, on the condition that this belongs to the same legal company as the order site and that it is listed in the site table.
  • Use the contextual button to select a site from the list proposed or carry out different stock inquiries.
Addr. (field XFCYADD)

This is the default address code for the receiving site chosen. This address will be printed on the order document sent to the supplier.

From this field, you can select another receiving site address if several exist.
Location reference (field USEPLC)

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

Examples: Dock xx or Hall yy.

The place of consumption is written on the order document.

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

Account Search
Picking of Purchase Requests

Click this action to initialize the delivery request lines from the requirements, i.e. by consuming purchase requests or purchase suggestions.
Split Delivery Request

Use this action to split a weekly or monthly delivery request line into 'N' delivery requests. The statuses of these requests can either be planned or firm.
Text

Click this action to enter text at the level of the delivery request line.
PR Inquiry

Other actions available

Budget
Click this action to view the budget details. According to the setup defined, a budgetary control can be blocking, can be carried out at the time of the creation or modification of the delivery requests entered (see the BUDCNTCMM - Commitments control type and BUDCTLPOH - Order management control parameters).
Closing

Click this action to close a delivery request line. Only daily delivery requests can be closed.

  • If a commitment has been generated for this line, it will be reversed automatically.

  • If the line has been closed, use this action to reactive the delivery request.

In the case of an inter-site or inter-company delivery, the closing of the purchase delivery requests will automatically lead to the closing of the reciprocal sales delivery request line. The closing of the purchase delivery request can only take place if the mirror sales delivery request line is neither allocated, delivered nor invoiced.
Commitment

Click this action jump to the commitment generated from the delivery request when the management of commitments is activated (PURCMM - Update commitments parameter - ACH chapter, CMM group).

Reports

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

  • BONDLOUV2 : Requests for purchase orders

  • PSUIVOUV : Open orders tracking

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 Destination printer is chosen. If the number of copies is not specified for the destination printer, then a single copy is printed by default.

Specific Buttons

Click this action to access the contract for which delivery requests are saved.

Click this action to view the receipts saved for this delivery request.

Note on the receipt of a delivery request: When you partially receive a delivery request, it is split into two distinct requests having the same characteristics except for the quantities. The first half corresponds to the received part (automatically closed), the second one is the remainder. If, during the receipt, you indicate that you want to close the delivery request (see the POHCLE - Order line closing parameter (ACH chapter, REM group)), then the second delivery request, generated by the split, is automatically closed.

Specific actions

Click this action to access the Contract order inquiry function in order to view the delivery requests made for the open order contract in progress.

Limitations

Landed costs (cost structure, landed cost coefficient, fixed cost per unit) are not managed in open order or delivery orders. These costs are managed at the level of Receipts.

Local menus

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

The site is not in the same legal company

This message appears during the entry of the receiving site when the site code entered does not belong to the same legal company as the order site. To correct this problem, it is necessary to select a site from the list suggested.

Insertion not possible

This message is displayed when an attempt is made to insert a line when the maximum number of lines for an order, defined by the appropriate activity code, has been reached.

Entry format incorrect

This message is displayed when entering the period and the entered value does not match the excepted format:

  • DDMMYY or DDMMYYYY for a daily request
  • WWWYY or WWWYYYY for a weekly request
  • MMYY or MMYYYY for a monthly request
Date prior to today's date

This message is displayed when the period entered is lower than the current date.

Date prior to the validity start date

This message is displayed when the date or period entered is lower than the product validity start date specified in the contract.

Date greater than the validity end date

This message is displayed when the date or period entered is greater than the product validity end date specified in the contract.

Periods must be recorded in ascending order

This message is displayed when attempting to enter:

  • A daily request when the previous line is a weekly or monthly request;
  • A weekly request when the previous line is a monthly request and the next line is a daily request;
  • A monthly request when the next line is a daily or weekly request;
  • A daily, weekly or monthly request lower than the request of the previous line or greater than the next line.
Processing not possible: Former periods were not processed

This message is displayed when attempting to split a weekly request into N daily requests or a monthly requests into N weekly requests but one of the previous planned requests has not been processed yet. To solve this problem, process requests in chronological order.

The quantity is less than the minimum quantity ####.## XXX

This message is displayed when a quantity that is entered is less than the minimum quantity required by the supplier, as specified in the product record.

Quantity is greater than global quantity

This message is displayed on entering the quantity, when the total of the requests quantities is greater than the overall quantity defined in the contract.

Contract partially signed: change or deletion prohibited

This message is displayed when attempting to enter a request but the contract has not been fully signed yet.

Order closed. Modification prohibited

This message appears when an attempt is made to modify the request line when all the request lines are closed.

Order line closed: Modification or deletion prohibited

This message appears when an attempt is made to modify a closed request line. To correct this problem, the user must cancel the line closure, if this is still possible, then return to line modification mode.

You cannot modify the status of this line:

This message is displayed when trying to modify a request line though one or more receipts have been recorded for this line.

Tables used

SEEREFERTTO Refer to documentation Implementation