Purchasing >  Orders >  Delivery requests  

Display all Hide all

Use this function to manage the delivery requests sent in the framework of an open order. A open order is a long term commitment with a supplier concerning one or several products, for a global quantity to be delivered with delivery call-offs that are performed based on the demand. An open order consists in a contract and a delivery schedule.

The contract (see Contract documentation) is used to define:

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

The delivery schedule defines:

  • Firm delivery requests
  • Provisional delivery requests

This option is used to create, modify, delete, copy, view, and print delivery requests.

Specificities linked to the inter-company: 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 and consists in:

  • 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, it is necessary to select from the left list on the screen the contract line under the terms of which the delivery request must be made. The top section displays the main information on the contract line and entries must be done in the table.

Entry screen

Presentation

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, sites must be referenced as customer BPs and/or supplier BPs. Requesting sites are referenced as Customers and reordering site as Suppliers.

When creating a purchase contract and entering a supplier of the inter-site type, the contract is considered as an inter-site contract. When creating the purchase contract, the corresponding sales contract will be created automatically. 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

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

The lines can be initialized using the contextual menu "Requirements". Purchase requests can indeed be consumed by means of the requirements picking.

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 quantity taken into account;
  • Various information such as the BP, type and the order number in the WIP, etc.

After entering the unit, the user is automatically in entry mode for the quantity to be taken into account, which is the only information that can be entered on this screen. If the user wishes to sort the list proposed by requirement date or by site, they must exit the entry mode, then use the contextual button in order to choose the sort required.

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

You can enter several lines as the entry of delivery requests is carried out in a grid. 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 contextual button 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 window for the taking into account of requirements (if any);
  • Close the request line;
  • Enter text.

In the case of a planned request, you can:

  • Return to the window for the taking into account of requirements (if any);
  • Enter text;
  • Close the line if a daily request is concerned;
  • 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 into daily requests and a monthly request into 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 be a simple warning according to the choice made at general setup level (see the BUDCNTCMM setup). A message of the same type can appear at the time of the final save.

In addition, when the update of commitments is active, it is carried out automatically upon activation of button [Create] that enables 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 contextual button provides the user with possibilities identical to those available upon creation: 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 appear according to the fields that you are in the process of modifying:

  • If you attempt to modify a received delivery request, a blocking message is 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.
  • Update 8.0.0 and higher: if you modify the quantity suggested after taking into account requirements with multiple purchase requests, an error message is displayed if the entered quantity is lower 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 appears on activating of the Delete button. Similarly, for each order line, modification is possible as long as the line is not received. In addition, deletion is impossible when the delivery request is closed.

Close

 

Fields

The following fields are present on this tab :

Block number 1

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 a purchase order is copied, and it has an order date different from the current date, the user will be asked whether they wish to 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)

 

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)

Once the supplier has received the order, enter the acknowledgement ID provided by the supplier.
After entering this information, the contract lines which have not been assigned an acknowledgement ID are automatically updated with this number.

Inter-company specificities: For inter-company or inter-site contracts, the Order acknowledgement ID and date cannot be accessed and are initialized, when the sales contract has been generated, with the date and the number of the sales order. You can use the Actions icon available on the Ack. ID field to jump to the generated sales contract, provided you are granted the proper authorizations.


This field picks up the Order Acknowledgement number specified in the original purchase contract.

Inter-company specificities: for inter-company contracts, the order acknowledgment number of the purchase contract matches the number of the corresponding sales contract. In the case of an inter-company delivery request, it is the same sales contract number that is picked up in the Order Ackn. number field.

 

Product

The product code is initialized from the selected product line in the contract.
  • field ITMDES

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

 

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.

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)

 

 
  • Early/Late date (field XEARDAT)

 
  • 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 simply displayed and 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:

Prior to update 8.0.0:

  • The quantity is modified after requirements are taken into account and when the entered quantity is less than the quantity considered.
  • 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).

Update 8.0.0 and higher:

  • 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 taken into account only apply to one purchase request, then 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 Quantity field, the contextual button is used to carry out the different stock inquiries.

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 chosen receiving site. This address will be printed on the order document sent to the supplier.
From this field, you can select another address for the receipt site if multiple sites are defined.
  • 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.

Close

 

Action icon

Account Search
Picking of Purchase Requests
Standard Rerouting Action
Split Delivery Request
Text
Base Product Management
PR Inquiry

Functions accessed by right-click on the grid

Budget

Use this function 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).

Requirements

This function is used to initialize the delivery request lines by making it possible to consume purchasing requests or purchasing suggestions.

Close

Use this function 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 function to reactive the delivery request.

In the case of an inter-site or inter-company delivery, the closure of the purchase delivery requests will automatically lead to the closure 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.

Delivery request distribution

This function is used 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

This function is used to enter text on a deliver request line.

Commitment

This function is used to access by tunnel the commitment generated from the delivery request when the commitments management is activated (PURCMM - Update commitments parameter - ACH chapter, CMM group).

 

Close

 

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

This button is used to access the contract for which delivery requests are saved.

This button is used to view receipts saved for this delivery request.

Note concerning the receipt of a delivery request: When there is a partial receipt of a delivery request, the latter 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, at the time of the receipt, you indicate that you want to close the delivery request (see the POHCLE setup), then the second delivery request, generated by the split, will be automatically closed.

Menu Bar

Option / Shipment Request Inquiry

This menu is used to access the GESPOV function in order to view the delivery requests made under the terms of the open order contract under progress.

Options / Journal traceability

Error messages

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 is displayed when entering the reception site and 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 lower than 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 appears 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 is displayed when attempting to modify a request line but all request lines have been closed.

Order line closed: Modification or deletion prohibited

This message appears when trying to modify a closed request line. To correct this problem, you must cancel the line closing, 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