POP - Purchase Order Processing
Meta Process
For procurement, a purchase order is created in the system in purchasing. Purchase orders can be created manually, from EDI messages, NOS replenishment (when there is no more stock in the warehouse), as well as from sales orders and intercompany processes. Purchase orders serve communication with the vendor and, with their integrated evaluations, the monitoring of the procurement process.
graph LR; %% Nodes A(POP<br>Purchase Order Processing) B(POP-0010<br>Create purchase order header) C(POP-0020<br>Add purchase order lines) D(POP-0030<br>Define sizes and colours) E(POP-0040<br>Edit purchase order) F(POP-0050<br>Release purchase order) G(POP-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,D,E,F,G btProcessActive
POP-0010 - Create purchase order header
By selecting the vendor, the information is taken over from the vendor master data (currency, payment terms, and delivery terms). The principle of inheriting master data into the document header (or the document lines) applies here. Changed master data in the document is not written back to the master data (vendor/item). It applies exclusively to this document.
Furthermore, the agency and, if applicable, the plant in which production will take place are derived from the selected vendor. If plants and agencies are used, they can also be maintained as vendors. This means that purchase orders can also be entered directly for the producing plant.
An order season and order type can be assigned to each purchase order, and these can be defined freely (main order, NOS, sample, clearance lots, etc.). The order season can differ from the item season.
Incoming processes:
- EIB - EDI-IN-ORDRSP
- EID - EDI-IN-DESADV
- NOS - NOS Replenishment
- SOP - Sales Order
- PRP - Procurement Plan
- ORP - Order Proposal
Outgoing processes:
POP-0020 - Add purchase order lines
The purchase order lines are created, using the stored master data. Here too, the principle of inheriting data into the document applies. Changes to master data do not result in an automatic update of document data. Exceptions exist via item correction. A purchase order can contain any items of the same producer; no explicit separation is required.
If it is a new item, it is generally entered via the vendor’s item number (vend. item no.) and provided with the corresponding information such as brand, colour, size scale, item category, and price. Before editing the sizes in the matrix, the item is then created in the system.
Incoming processes:
POP-0030 - Define sizes and colours
In matrix entry, the items are distributed by size and colour. Item lots can also be entered (see also the chapter Item Master Data/Lots) with code and quantity and distributed across sizes and colours. The data is written back to the purchase order lines by the ‘Resolve matrix’ function.
With automatic order entry, the quantities per colour and size are adopted automatically. With manual order entry, the quantities are entered at variant level (colour, size scale, size). Alternatively, sizes and colours can be entered directly in the purchase order lines. It is also possible to add the lines by scanning item barcodes.
POP-0040 - Edit purchase order
The purchase order lines can be edited individually so that, among other things, the following fields can be changed: vendor item number, brand, location, merchandise group/item category, description and colours, as well as prices (cost, sales). Under certain circumstances, it must be possible to cancel specific lines. This is done via the ‘Activate/deactivate cancellation’ functionality.
Outgoing processes:
POP-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. It is then transmitted to the vendor. This can be implemented in different ways (printed as mail, post, fax, or electronically via EDI).
Outgoing processes:
POP-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
Outgoing processes:
- WRB - Goods Receipt Book
- WRT - Goods Receipt
- VIN - Vendor Invoice Processing
- LPT - Label Printing
- KSM - Target Inventory Management
Instances
POP-MAN - Purchase Order Processing Manual
The process describes how a purchase order can be created manually in the system.
graph LR; %% Nodes A(POP-MAN<br>Purchase Order Processing Manual) B(POP-MAN-0010<br>Create purchase order header) C(POP-MAN-0020<br>Add purchase order lines) D(POP-MAN-0030<br>Define sizes and colours) E(POP-MAN-0040<br>Edit purchase order) F(POP-MAN-0050<br>Release purchase order) G(POP-MAN-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,D,E,F,G btProcessActive
POP-MAN-0010 - Create purchase order header
By selecting the vendor, the information is taken over from the vendor master data (currency, payment terms, and delivery terms). The principle of inheriting master data into the document header (or the document lines) applies here. Changes to the master data do not result in any direct update of the documents. Furthermore, the agency and, if applicable, the plant in which production will take place are derived from the selected vendor. An order season and order type can be assigned to each purchase order, and these can be defined freely (main order, NOS, sample, clearance lots, etc.). The order season can differ from the item season.
Outgoing processes:
POP-MAN-0020 - Add purchase order lines
The purchase order lines are created, using the stored master data. Here too, the principle of inheriting data into the document applies. Changes to master data do not result in an automatic update of document data. Exceptions exist via item correction. A purchase order can contain any items of the same producer; no explicit separation is required. In this step, the items to be ordered are entered manually via item number or vendor item number.
Incoming processes:
If it is a new item, it is generally entered via the vendor’s item number (vend. item no.) and provided with the corresponding information such as brand, colour, size scale, item category, and price. Before editing the sizes in the matrix, the item is then created in the system.
POP-MAN-0030 - Define sizes and colours
In matrix entry, the items are distributed in their quantity across sizes and colours. The data is written back to the purchase order lines by the Resolve matrix function. Alternatively, sizes and colours can be entered directly in the purchase order lines. It is also possible to add the lines by scanning item barcodes.
POP-MAN-0040 - Edit purchase order
The purchase order lines can be edited individually so that, among other things, the following fields can be changed: vendor item number, brand, location, merchandise group/item category, description and colours, as well as prices (cost, sales). Under certain circumstances, it must be possible to cancel specific lines. This is done via the Activate/deactivate cancellation functionality.
Outgoing processes:
POP-MAN-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. It is then transmitted to the vendor. This can be implemented in different ways (printed as mail, post, fax, or electronically via EDI).
POP-MAN-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
Outgoing processes:
POP-PRP - Purchase Order Processing from Procurement Plan
This process describes the creation of a purchase order from procurement planning.
graph LR; %% Nodes A(POP-PRP<br>Purchase Order Processing from<br>Procurement Plan) B(POP-PRP-0010<br>Create purchase order header) C(POP-PRP-0020<br>Add purchase order lines) D(POP-PRP-0030<br>Define sizes and colours) E(POP-PRP-0040<br>Edit purchase order) F(POP-PRP-0050<br>Release purchase order) G(POP-PRP-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,D btProcessInactive class E,F,G btProcessActive
POP-PRP-0040 - Edit purchase order
The purchase order lines can be edited individually so that, among other things, the following fields can be changed: vendor item number, location, description, as well as prices (cost, sales). Under certain circumstances, it must be possible to cancel specific lines. This is done via the Activate/deactivate cancellation functionality.
Incoming processes:
Outgoing processes:
POP-PRP-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. It is then transmitted to the vendor. This can be implemented in different ways (printed as mail, post, fax, or electronically via EDI).
POP-PRP-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
POP-NOS - Purchase Order Processing NOS Replenishment
NOS replenishment is used to reorder goods in the NOS (Never Out of Stock) area. In the NOS replenishment document, “Create purchase order” is specified as the replenishment type, so that purchase orders are automatically created for replenishing the items. The basis is either target inventories (for example at store or central level) or direct sales in the stores. These are therefore purchase orders delivered either directly to the stores or centrally. Decentralised delivery is generally supported by EDI processes (ORDRSP, DESADV).
graph LR; %% Nodes A(POP-NOS<br>Purchase Order Processing from<br>Replenishment) B(POP-NOS-0010<br>Create purchase order header) C(POP-NOS-0020<br>Add purchase order lines) D(POP-NOS-0030<br>Define sizes and colours) E(POP-NOS-0040<br>Edit purchase order) F(POP-NOS-0050<br>Release purchase order) G(POP-NOS-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,D btProcessInactive class E,F,G btProcessActive
POP-NOS-0040 - Edit purchase order
The purchase order lines can be edited individually so that, among other things, the following fields can be changed: location, merchandise group/item category, description, as well as prices (cost, sales). Under certain circumstances, it must be possible to cancel specific lines. This is done via the Activate/deactivate cancellation functionality.
Incoming processes:
POP-NOS-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. It is then transmitted to the vendor. This can be implemented in different ways (printed as mail, post, fax, or electronically via EDI).
Outgoing processes:
POP-NOS-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
Outgoing processes:
POP-ORP - Purchase Order Processing Order Proposal
A purchase order is created automatically from requirements determination in the order proposal. The key information is prefilled, so that an adjustment of the purchase order is only necessary in exceptional cases. The purchase order is created on the basis of requirements for existing sales orders or also for component provision.
graph LR; %% Nodes A(POP-ORP<br>Purchase Order Processing from<br>Replenishment) B(POP-ORP-0010<br>Create purchase order header) C(POP-ORP-0020<br>Add purchase order lines) D(POP-ORP-0030<br>Define sizes and colours) E(POP-ORP-0040<br>Edit purchase order) F(POP-ORP-0050<br>Release purchase order) G(POP-ORP-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,D btProcessInactive class E,F,G btProcessActive
POP-ORP-0040 - Edit purchase order
The purchase order lines can be edited individually so that, among other things, the following fields can be changed: location, merchandise group/item category, description, as well as prices (cost, sales). Under certain circumstances, it must be possible to cancel specific lines. This is done via the Activate/deactivate cancellation functionality.
POP-ORP-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. It is then transmitted to the vendor. This can be implemented in different ways (printed as mail, post, fax, or electronically via EDI).
POP-ORP-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
POP-DSH - Purchase Order Processing from Sales Order Direct Delivery
In direct deliveries, the goods are generally sent directly from the vendor to the customer without passing through the company’s own warehouse.
graph LR; %% Nodes A(POP-DSH<br>Purchase Order Processing from<br>Sales Order Direct Delivery) B(POP-DSH-0010<br>Create purchase order header) C(POP-DSH-0020<br>Add purchase order lines) D(POP-DSH-0030<br>Define sizes and colours) E(POP-DSH-0040<br>Edit purchase order) F(POP-DSH-0050<br>Release purchase order) G(POP-DSH-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,E,F,G btProcessActive class D btProcessInactive
POP-DSH-0010 - Create purchase order header
By selecting the vendor, the information is taken over from the vendor master data (currency, payment terms, and delivery terms). The principle of inheriting master data into the document header (or the document lines) applies here. Changes to the master data do not result in any direct update of the documents. Furthermore, the agency and, if applicable, the plant in which production will take place are derived from the selected vendor. An order season and order type can be assigned to each purchase order, and these can be defined freely (main order, NOS, sample, clearance lots, etc.). The order season can differ from the item season.
To link the direct delivery, the assigned customer and, if applicable, its deviating delivery address must be specified in the purchase order header.
Incoming processes:
POP-DSH-0020 - Add purchase order lines
Using the ‘Direct delivery - Get order’ function, the sales lines of the linked customer are retrieved into the purchase order. Only orders are retrieved whose purchasing codes are marked as direct delivery orders at line level. The document lines are marked with the “Direct delivery” flag.
POP-DSH-0040 - Edit purchase order
The purchase order lines can be edited individually (for example cost prices and delivery dates). Changes to quantities or locations are not permitted for purchase orders with direct delivery.
POP-DSH-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. It is then transmitted to the vendor. This can be implemented in different ways (printed as mail, post, fax, or electronically via EDI).
Outgoing processes:
POP-DSH-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
Outgoing processes:
POP-SPO - Purchase Order Processing from Sales Order Special Order
Another technical option for generating a purchase order from a sales order is special orders. Special orders are procurements carried out specifically for one customer. The difference from a direct delivery order is that the shipment to the customer must be posted separately and the purchase order is still quite free in processing. This allows, for example, cross-docking processes to be mapped. To exclude the risk of mixing the “special goods” with regular goods through availability calculation, it is advisable to use a separate location (cross-docking warehouse) or a separate item number (for example SMU - Special Make Up) for this process.
graph LR; %% Nodes A(POP-SPO<br>Purchase Order Processing from<br>Sales Order Special Order) B(POP-SPO-0010<br>Create purchase order header) C(POP-SPO-0020<br>Add purchase order lines) D(POP-SPO-0030<br>Define sizes and colours) E(POP-SPO-0040<br>Edit purchase order) F(POP-SPO-0050<br>Release purchase order) G(POP-SPO-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,E,F,G btProcessActive class D btProcessInactive
POP-SPO-0010 - Create purchase order header
If the purchase order was not created automatically from the order, the purchase order header can also be created manually. By selecting the vendor, the information is taken over from the vendor master data (currency, payment terms, and delivery terms). The principle of inheriting master data into the document header (or the document lines) applies here. Changes to the master data do not result in any direct update of the documents. Furthermore, the agency and, if applicable, the plant in which production will take place are derived from the selected vendor. An order season and order type can be assigned to each purchase order, and these can be defined freely (main order, NOS, sample, clearance lots, etc.). The order season can differ from the item season.
To link the special order, the assigned customer and, if applicable, its deviating delivery address must be specified in the purchase order header.
Incoming processes:
POP-SPO-0020 - Add purchase order lines
If the purchase order was not created automatically from the order, the purchase order lines/positions are retrieved from the sales order using the ‘Special order - Get order’ function. Only orders are retrieved whose purchasing codes are marked as special orders at line level. The document lines are marked with the “Special order” flag.
POP-SPO-0040 - Edit purchase order
The purchase order lines can be edited individually (for example cost prices and delivery dates). Under certain circumstances, it must be possible to cancel specific lines. This is done via the Activate/deactivate cancellation functionality.
POP-SPO-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. It is then transmitted to the vendor. This can be implemented in different ways (printed as mail, post, fax, or electronically via EDI).
Outgoing processes:
POP-SPO-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
Outgoing processes:
POP-SPL - Purchase Order Processing Samples
A purchase order for samples or sample parts can be created from a PDM document. This operation is part of sample management.
graph LR; %% Nodes A(POP-SPL<br>Purchase Order Processing Samples) B(POP-SPL-0010<br>Create purchase order header) C(POP-SPL-0020<br>Add purchase order lines) D(POP-SPL-0030<br>Define sizes and colours) E(POP-SPL-0040<br>Edit purchase order) F(POP-SPL-0050<br>Release purchase order) G(POP-SPL-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,D btProcessInactive class E,F,G btProcessActive
POP-SPL-0040 - Edit purchase order
The purchase order lines can be edited individually so that, among other things, prices (cost, sales) can be changed. Under certain circumstances, it must be possible to cancel specific lines. This is done via the Activate/deactivate cancellation functionality.
POP-SPL-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. It is then transmitted to the vendor. This can be implemented in different ways (printed as mail, post, fax, or electronically via EDI).
POP-SPL-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
POP-EDI - Purchase Order Processing via EDI
This process describes the creation of a purchase order on the basis of an EDI document (ORDRSP or DESADV). EDI purchase orders are generally created when there is no valid purchase order in the system for an order confirmation or a delivery advice. This often happens after trade fairs, when the buyer places an order with a vendor with EDI connection but it has not yet been recorded in the system. The vendor then sends an order confirmation (ORDRSP), which can be processed by the system into a purchase order. If the vendor sends a delivery advice (DESADV), the purchase order is created in the system at the latest before goods receipt.
graph LR; %% Nodes A(POP-EDI<br>Purchase Order Processing via EDI) B(POP-EDI-0010<br>Create purchase order header) C(POP-EDI-0020<br>Add purchase order lines) D(POP-EDI-0030<br>Define sizes and colours) E(POP-EDI-0040<br>Edit purchase order) F(POP-EDI-0050<br>Release purchase order) G(POP-EDI-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,D btProcessInactive class E,F,G btProcessActive
POP-EDI-0040 - Edit purchase order
The purchase order lines can be edited individually so that, among other things, the following fields can be changed: location, merchandise group/item category, description, as well as prices (cost, sales). Under certain circumstances, it must be possible to cancel specific lines. This is done via the Activate/deactivate cancellation functionality.
Incoming processes:
POP-EDI-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes. Purchase orders created from EDI are not transmitted again to the vendor as ORDER.
Outgoing processes:
POP-EDI-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
Outgoing processes:
POP-IC - Purchase Order Processing Intercompany
At the time the sales order is released (for example in the sales company), an IC transaction is triggered in the system based on the IC setup. Via the corresponding intercompany setup, the purchase order is created in the respective assigned company using the IC partner. The document with header-line structure is transferred.
graph LR; %% Nodes A(POP-IC<br>Purchase Order Processing Intercompany) B(POP-IC-0010<br>Create purchase order header) C(POP-IC-0020<br>Add purchase order lines) D(POP-IC-0030<br>Define sizes and colours) E(POP-IC-0040<br>Edit purchase order) F(POP-IC-0050<br>Release purchase order) G(POP-IC-0060<br>Monitor purchase order) %% Flow A -.- B linkStyle 0 stroke:#ffffff B ==> C C ==> D D ==> E E ==> F F ==> G %% Classes class A btProcessTitle class B,C,D btProcessInactive class E,F,G btProcessActive
POP-IC-0040 - Edit purchase order
The purchase order is edited through the editing of the linked sales order.
Incoming processes:
POP-IC-0050 - Release purchase order
Once editing is completed, the purchase order is set to the status ‘Released’. Releasing makes the document visible for the subsequent processes.
POP-IC-0060 - Monitor purchase order
For deadline monitoring, a supply chain can be assigned at purchase order and item level. The supply chains can be defined freely and transferred conveniently to the purchase order by means of templates. Each step can optionally depend on another step of the supply chain. Completed tasks can have their status set to completed.
Outgoing processes:
Classification
The process describes purchase order processing in procurement from creating the purchase order header through creating and editing the purchase order lines to releasing and monitoring the purchase order. Depending on the starting situation, the purchase order can originate manually, from procurement planning, from NOS replenishment, from the order proposal, from EDI documents, from sales orders, or as an intercompany purchase order.
The instances represent different business and technical variants of the same base process. The greyed-out steps in the instance diagrams show which parts of the meta process are not actively passed through or are not executed independently in the respective variant.