Procurement on Product Documentation

MDA-VEN - Vendor Master Data Management

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

The master data management process cannot be viewed separately; instead, the individual instances belong to the corresponding subprojects. Therefore, this instance is handled here and linked to the meta process MDA - Master Data Management.

graph LR;

%% Nodes
A(MDA-VEN<br>Vendor Master Data<br>Management)

%% Flow

%% Classes
class A btProcessTitle

Instances

MDA-VEN - Vendor Master Data Management

graph LR;

%% Nodes
A(MDA-VEN<br>Vendor Master Data<br>Management)

%% Flow

%% Classes
class A btProcessTitle

The management of vendor master records for the purpose of handling accounting and merchandise management business processes. As a rule, the vendor is created manually and maintained in the area of financial accounting. Among other things, payment terms, currencies and exchange rates, as well as delivery terms are stored.

ORP - Order Proposal

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

With the help of the order proposal, demands from sales orders and component provision can be determined and planned. Based on gross demand (remaining order quantity/remaining quantity to be provided), available inventory, and expected goods receipts (remaining purchase order quantity), the system determines the net demand and, if necessary, generates purchase orders from it.

graph LR;

%% Nodes
A(ORP<br>Order Proposal)
B(ORP-0010<br>Create order proposal)
C(ORP-0020<br>Create proposal)
D(ORP-0030<br>Edit proposal)
E(ORP-0040<br>Create procurement documents)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

ORP-0010 - Create order proposal

The document is created. The type of calculation determines whether models for sales orders, components for provision, or both at the same time are to be planned. The parameters “Orders up to Goods Issue Date”, “Orders up to Goods Receipt Date”, and “Order Components up to Provision Date” define the time horizon for the calculation. Additional filters can be used to restrict planning: sales order season filter, item number filter, item category filter, location filter, vendor filter (relates to the vendor on the item card).

POP - Purchase Order Processing

Mon, 01 Jan 0001 00:00:00 +0000

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.

POS - Order Split

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

Order split is an auxiliary process of purchase order processing. It is used to split purchase quantities by date. Order split therefore makes it possible to divide purchase orders according to different delivery dates, for example due to date-related partial deliveries. Quantities from the original purchase order are transferred into additional purchase orders. These are grouped by delivery date and transport type.

graph LR;

%% Nodes
A(POS<br>Order Split)
B(POS-0010<br>Open purchase order)
C(POS-0020<br>Modify order split)
D(POS-0030<br>Edit quantities)
E(POS-0040<br>Create split purchase order)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

POS-0010 - Open purchase order

The purchase order to be split is opened and the status is reset. Using the ‘Create Order Split’ function, the schedule distribution is opened, in which all color-size combinations are shown as individual lines.

HRD - Delivery Difference Handling

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

The process describes the handling of delivery differences and possible responses to under- or overdelivery. This process is an analysis process at a point in time when the purchase order and invoice are already completed. The differences are formed from receiving goods and closing advice notes.

Items that were advised but not received are treated as underdelivery (negative differences). Items that may not have been advised or were advised with a smaller quantity are treated as overdelivery. Overdeliveries are determined during goods receipt posting. Underdeliveries are recorded when the advice note is closed.

ROS - Vendor Return

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

In this process, purchase complaints with the corresponding complaint reasons are recorded. They are used to announce returns to the vendor and can be processed by logistics through goods issues.

graph LR;

%% Nodes
A(ROS<br>Vendor Return)
B(ROS-0010<br>Create complaint header)
C(ROS-0020<br>Insert complaint lines)
D(ROS-0030<br>Edit complaint)
E(ROS-0040<br>Post complaint)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

ROS-0010 - Create complaint header

The purchase complaint is created and header data such as the vendor number is entered in the document. Further data is derived from the master data stored on the vendor. For comparison with the vendor, a vendor credit memo number or processing number can be stored.

POC - Component Provisioning

Mon, 01 Jan 0001 00:00:00 +0000

Meta Process

This process describes how components can be provided to a producer.

graph LR;

%% Nodes
A(POC<br>Component Provisioning)
B(POC-0010<br>Adjust model purchase order)
C(POC-0020<br>Determine component demand)
D(POC-0030<br>Create component<br>provisioning)
E(POC-0040<br>Complete component<br>provisioning)
F(POC-0050<br>Post model goods<br>receipt)

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E
E ==> F

%% Classes
class A btProcessTitle
class B,C,D,E,F btProcessActive

POC-0010 - Adjust model purchase order

A purchase order is created for one or more models. When the model lines are created, component lines per purchase order line are written based on the bills of materials stored on the model. Only the components from the bills of materials that are to be provided to the vendor are taken into account. Quantities in the model lines can be changed at any time. The component lines can then be added, deleted, or changed. It is possible to copy one component to all SKUs of the model. In the component lines, the quantities of the respective bill of materials are specified per component.