Setting Up Purchase Order Management

Objectives

After completing this lesson, you will be able to:

  • Set up Purchase Order Management.
  • Display a contract and create a contract release order.

Structure and Functions

There are several different ways to create purchase orders in SAP Retail, as explained at the end of the previous lesson, Performing Requirements Planning. They can be created manually, or generated by automatic or manual conversion from a purchase requisition. It's also possible to generate purchase orders through a Store Replenishment run, or using the POS Inbound Store Order function. Further options are to generate them as follow-on documents from allocation tables, or to have them created via interface, for example from SAP Forecasting and Replenishment, or SAP Replenishment Planning, and so on.

In our process, a purchase order was generated automatically from purchase requisitions, which resulted from requirements planning. In the following, the structure, and functions of purchase orders in SAP Retail will be explained.

In the Purchase Order transaction, you can see that the document is divided into three areas: Header, Item Overview, and Item Detail. All three document areas can be displayed individually, or two at a time: Header with item overview, or item overview with item details. Purchase order items are entered in the item overview, and for each item, an item detail view is available.

The Purchase Order transaction provides a Document Overview, which can be used to select documents to be processed by the user, such as purchase requisitions, contracts, existing purchase orders, and so on.

A purchase order can be an external supplier order (standard order), or an internal warehouse order. Note: Other terms for warehouse order are stock transport order, or stock transfer order.

For organizational purposes, a purchase order is assigned to one purchasing organization and one purchasing group, as well as a company code. In addition to this, a purchase order is created for a specific order type (e.g. NB = standard purchase order, UB = stock transport order) for control purposes.

A user can personalize the purchase order transaction using the Personal Setting options which include maintaining default values on header and on item level. It is also possible to adjust the item table regarding the sequence and width of columns, by defining a variant in the table settings.

A number of additional functions are available during purchase order processing. At header level, for example, you can do the following:

  • Maintain additional texts

  • Maintain partner functions and partners, if the supplier, invoicing party, and payee are not the same

  • Adjust the supplier address for this document

  • Display the document header conditions

  • Display the message(s) and a print preview

  • Access the supplier master record

Additional functions at item/item detail level in a purchase order are for example:

  • Display and maintain conditions

  • Order generic articles using a variant matrix

  • Create returns items (for example, for returns of transport equipment, empties, and standard merchandise)

  • Display the empties (such as case or crate, empty bottles) as a sub-item of the full product

  • Display the components of structured articles as sub-items of the header product

  • Display free goods items

  • Maintain schedule lines

  • Access the material master record, stocks, info record, source list, and so on

You can also add further items to purchase orders using additional planning.

In the SAP S/4HANA Retail system, it is also possible to use a monitoring function for the processes along the logistics chain for external purchase orders. It allows you to react in time to exceptions such as delays in individual transportation segments: Transportation Chains map the whole route between the source (external vendor or manufacturing site) and destination venues (distribution center or store), and describe the transport time for each segment of a transportation route. Transportation Chains are created in the application, and are then assigned to the vendor/article master data. The Datelines Workbench report can be used to identify the current status of the datelines, simulate datelines, perform corrections on a particular operational date ID, and so on. Optionally, you can have the system automatically check for deviations from the planned and monitored dates of the purchase orders in a daily background process. The deviation data is then transferred into the Reactive PO Monitor in case of determined anticipated delays.

Quantity Adjustment

One of the functions available when converting purchase requisitions to purchase orders, or when purchase orders are created manually, or via the Store Order function, and so on, is Quantity Optimizing.

Quantity Optimizing processes a specified quantity, for example the net requirement quantity in the base unit of measure of a purchase requisition item, according to rounding rules, which were defined in Customizing in a rounding profile, and which was then assigned to the article. The figures can be rounded up or down. With dynamic rounding profiles, the system can also take alternative units of measure into account, which were specified for the article in the Basic Data view. You can use a rounding profile to round up or down, and to round to multiples. Static rounding profiles don't use alternative units of measure. Rounding profiles can also be used to check whether fixed limits are observed. Limit values for quantities of a document item are specified in master data for purchasing. With that, quantity optimizing ensures that the minimum quantity is not undershot and that the maximum quantity is not exceeded.

Quantity optimizing is also available for sales transactions, so a rounding profile, a unit of measure group and minimum and maximum quantities can also be maintained in the article sales view.

Net requirement quantities from requirements planning in a purchase requisition, and for example manually specified order quantities can be rounded. The following information is taken into consideration during rounding: Minimum and/or maximum order quantity (if specified), the assigned rounding profile, and the unit of measure group (if specified).

The units of measure defined in the dynamic rounding profile, and the (optional) unit of measure group, are taken into consideration when the allowed units of measure for dynamic rounding are determined. A unit of measure group can be used to limit the possible logistical units of measure for ordering the article from that specific vendor. For example, a specific logistical unit of measure, which was defined in the Basic Data view of the article, cannot be ordered from that specific vendor (but from other vendors, so it had to be maintained in the Basic Data view). The unit of measure group would then only contain the other defined logistical units of measure, which are possible for ordering from that specific vendor.

When rounding quantities to logistical units of measure with dynamic rounding profiles, the system always attempts to place an order for the largest possible unit of measure from a vendor. This is done to ensure that the best possible conditions will be achieved. In order to allow rounding to the various logistical units of measure, the smallest allowed unit of measure for a purchase order has to be set as the explicit order unit of measure in the respective purchasing info record. Additionally, the Variable order unit indicator has to be set to Active.

Example: The units of measure defined for an article are each, case, layer, and pallet. With case being the explicit order unit of measure, the units of measure case, layer, and pallet are allowed in dynamic rounding.

The figure Rounding Profile shows examples for rounding results of unrounded order quantities, specified in the base unit of measure each (EA). Unit of measure EA is not an allowed order unit as per the assigned dynamic rounding profile RCLP, therefore quantity optimizing applies. The explicit order unit of measure is CSE, which is the smallest allowed order unit in this example.

Let's analyze the numbers for a pallet: A pallet containing 240 EA is ordered, if the unrounded order quantity is in the range from 216 to 264 EA. This is due to the rounding rule which determines that within 10% off the quantity of one pallet (as of 90%: round up, up to 10% more: round down), the system should round to one pallet. 10% of 240 EA = 24 EA: 240 - 24 = 216, and 240 + 24 = 264.

Accordingly, 2 pallets, containing 480 EA, are ordered from 480 - 24 = 456 to 480 + 24 = 504.

If the unrounded quantity for example lies between 265 and 455, the system checks if the rounding to the next smaller unit of measure is possible (LAY). If not, then the system will determine the number of CSE to be ordered. The Rounding off method specified in profile RCLP determines that a zero quantity only applies, if not even the smallest quantity can be ordered. This is the case for net requirements of 1-5 EA in our example, as the rounding down rule of 50% for unit of measure CSE applies.

Purchase Price Determination

When you create a purchase order, the system searches for existing conditions, which were maintained in the purchasing view of the article (purchasing info record), in contracts (in case of a contract release order), and in the general condition maintenance transactions. The conditions are then used to calculate the net value for each order item, and are aggregated on document level.

The article-specific condition, which is maintained in the purchasing info record, is the basic purchase price. Further article-specific conditions, such as discounts, freight conditions, and so on, can be maintained along with the basic purchase price in the same view, when a corresponding supplementary calculation schema was assigned to the basic purchase price condition type in customizing.

Price determination with the SAP condition technique consists of the following steps:

  • The relevant calculation schema (pricing procedure) is found using the schema determination with schema groups for the purchasing organization and for the vendor.

  • The condition types represent "cost factors" which are relevant for price determination, such as the article price, discounts or surcharges, freight conditions, taxes, and so on. Condition types are listed in the calculation schema, and for those, that have an assigned access sequence, the system performs a search for existing condition records. This means, one or more condition tables are assigned to an access sequence.

  • A condition table defines the key fields, which are relevant for a condition. For example, for an article-specific condition such as the basic purchase price, key fields are purchasing organization/vendor/article. A general vendor discount is agreed on the level purchasing organization/vendor. In price determination, the system uses the sequence of condition tables defined in the assigned access sequence of a condition type to search for condition records.

  • For each condition type, the search is complete when a valid condition record has been found, as per the exclusive indicator in the access sequence. The exclusive indicator controls whether the search is canceled or not canceled, as soon as a valid condition record is located. Of course, it is also possible that no condition record exists for the condition type.

The elements of the condition technique are calculation schemes, condition types, condition tables, and access sequences. They are defined in the IMG (system configuration/customizing). The same is true for the vendor and purchasing organization schema groups, which are used for the calculation schema determination.

These customizing settings are required to create condition records in application transactions. They contain the actual business figures - for example, a scaled percentage discount on vendor level (valid for all articles purchased from the vendor), for a defined time period. The figure, Condition Record in Purchasing: Example, shows such a general vendor condition with two defined scale levels.

Note

Each condition record has a validity period. When creating a condition record, the valid from- and to- dates can be defaulted as per customizing settings. For example, the defaulted start-date could be the current day, and the end-date could be 31.12.9999, or end of the current year, and so on.

Contracts

A contract is a long-term agreement with a supplier on the delivery of articles at defined conditions. These are valid for a defined period, and depending on the contract type, a specific total order quantity (quantity contract) or a specific total order value (value contract) are maintained. Contract items can relate to a single site, or to all sites in a purchasing organization (centrally agreed contract). However, it is still possible to maintain site-specific conditions in a centrally agreed contract. Due to the typically larger contract volumes of centrally agreed contracts, better conditions can be negotiated for those compared to site-specific contracts.

The contract does not contain information on specific delivery dates or quantities for the individual deliveries. The delivery date and quantity are specified in the individual contract release orders. A contract release order is a purchase order with reference to the contract.

Log in to track your progress & complete quizzes