Topic overview

In order to ensure that a desired item quantity is available at a specified time point, item quantities can be reserved. The available quantity is reduced through the reservation. Therefore, it is not available for other purposes.

The reservations have effects on all processes that change the inventory and availability of items. The following frameworks have functions related to reservations:

• Sales
• Purchasing
• Inventory management
• Production
• Planning

This article gives you an overview of reservations and their effects on the relevant processes. In addition, you will find information on the possible settings. The description of relevant fields, actions and procedures for reservations in applications can be read in the respective application articles.

Definitions of terms

Demand
A demand is a particular item quantity that, for example, is required at a certain demand date by a demand origin (element) or that must be obtained so that the inventory does not fall below the minimum inventory level.

Demand coverage (element)
Demand coverage (element) satisfies the demand originating with demand origin (element). Demand coverage (element) includes the inventory and planned receipts that arise from purchase orders, for example.

Demand coverage date
The demand coverage date describes a time point by which a planned receipt should provide an item quantity.

Demand date
The demand date describes the time point by which a demand origin (element) needs an item quantity.

Demand origin (element)
Demand origin (element) generates a demand for a demand date that is satisfied by demand coverage (element). Sales orders, for example, are included in demand origin (element).

Voucherless demand
The pseudo-voucher voucherless demand is available in order to be able to reserve a demand without having to create a voucher beforehand. A voucherless demand has an identification number and counts towards the demand origins (element).

Warehouse inventory management
Warehouse inventory management is an ongoing recording of the current warehouse inventory. The inventory management server updates these values after every inventory posting with a quantity transaction. Warehouse inventory
management is done at the lowest structural level of the warehouse and item or identifier. If the item has several parallel inventory units, then quantities are maintained for each unit. Inventory quantities can have different properties, such as subdivision into different quality statuses.

Reservation
A reservation is a guarantee that a product will be available on a specific date. A reservation presents the link of a demand origin (element) to a demand coverage (element). A reservation is only possible if both owners of inventory and items and warehouses match with demand origin (element) and demand coverage (element).

Reservation period
The reservation period is the time period that lies immediately before the demand date and in which reservations occur automatically. The reservation can thus be generated shortly before the demand date.

Availability
Availability is the forecast inventory of an item on the current or a future date. The availability is calculated using an availability rule and is made up of – the current inventory, – the planned receipts and – the planned issues. Any backorders can also be taken into account when calculating availability. If the reservation function is used, the availability is made up of – the unreserved current inventory, – the unreserved planned receipts and – the unreserved planned issues. Partial quantities are also taken into account.
The availability is the predicted supply of an item on a current or a future date. Availability is calculated by means of an availability rule and consists of:

• the current inventory,
• planned receipts,
• the planned issues.

Possible back orders can also be taken into account with the calculation of availability. If the reservation function is used, availability consists of:

• the unreserved current inventory,
• the unreserved planned receipts, and
• the unreserved planned issues.

Partial quantities are also taken into consideration in the process.

Demand origin and demand coverage

Central elements of reservations are demand coverage and origin. A demand origin is initiator for a reservation. A demand coverage covers the reserved demand of the demand origin.

Demand origins can be sales orders or their individual line items, for instance. Demand coverages can be purchase orders and also their individual line items. Demand origins and coverages are normally vouchers as well.

Demand origin vouchers:

• Sales orders
• Picking orders
• Delivery orders
• Purchae orders (only for returns)
• Production orders
• Distribution orders
• Inventory requisitions

Demand coverage vouchers:

• Sales orders (returns of goods, consignment, branch business)
• Picking orders (production, consignment, branch business)
• Delivery orders (consignment, branch business)
• Purchase orders
• Production orders (basis, line items with co-products)
• Distribution orders
• Inventory requisitions

For the following demand origins and coverages, there can be reservations but not vouchers

• Reservations for demand origin without vouchers
  • Inventory posting
    For a manual inventory issues posting, reservations are generated only if sufficiently reservable inventory is available for it. Only then can inventory posting be executed.
  • Entry in the posting error log
    For entries in the posting error log for issues, reservations are generated whenever possible. If the data for owner of inventory, item and warehouse is not saved, then no reservation can be generated.
  • Voucherless demand
    Voucherless demands are used for entering demands without first having to enter a voucher.

• Demand coverage without vouchers
  • Inventory posting
    A manual inventory receipts posting can be used as demand origin.
  • Entry in the posting error log
    For entries in the posting error log for receipts as well, reservations are generated whenever possible. If the data for owner of inventory, item and warehouse is not saved, then no reservation can be generated
  • Inventory

Effects of reservations on the availability of the inventory

Reservations influence the availability of inventory. This section uses an example to explain how reservations reduce the available inventory by the reserved inventory.

Reservations influence the availability of the inventory. In this section, an example is used to explain how the reservations reduce the available inventory to the reserved inventory.

Availability without reservations

The available inventory is the forecasted item inventory at a specified date. If reservations are not included, then the available inventory is compiled on the specified date from:

• current inventory
• plus the planned receipts and
• minus the planned issues.

Even back orders from incomplete orders are included.

To help you decide delivery dates, the availability query is available to you as basic information. The availability query is always based on the current order situation. Therefore, a delivery date can be decided, but it cannot be guaranteed if the item quantity will not be reserved.

Two availability queries at different time points give different results if between the two queries sales order line items for the same owners of inventory, item and warehouse with the previous shipping date are entered, changed or deleted. In order to prevent it, the item quantity can be reserved while entering the sales order.

Availability with reservations

If the customizing function Reservations is active, planned issues with their availability data are also demand origins and planned receipts in terms of availability management are also demand coverages.

With the help of reservations, demand origin and coverage are linked. Item quantities are reserved for the demand origin and they are no longer available for other purposes anymore. Inventory and planned receipts are reservable. If not all inventory characteristics are defined for an inventory issue in the demand origin voucher, the inventory is temporarily reserved. Otherwise, the inventory is permanently reserved.

The reserve quantity reduces the available quantity. The availability query becomes more accurate and the delivery dates can be better adhered to.

The availability query reports an exactly available inventory (from example 20 pcs.) by using the reservations. If there is no adequately available inventory, then you have several options while entering sales order line items. For instance, you can:

• create the sales order line item and order, produce the missing quantity before the shipping date to the supplier or relocate it to the issues warehouse via distribution order,
• agree upon a later delivery date or a quicker shipping term with the customer,
• agree upon a partial delivery with the customer and reduce the sales order line item to the available quantity,
• offer a substitute item reservable on shipping date or
• change existing reservations and re-divide the inventory.

Shortfall

If not all inventory characteristics are defined for an inventory issue in the voucher that creates the demand, the inventory is temporarily reserved. If all the inventory characteristics are defined in the voucher creating the demand, the inventory is permanently reserved. If an inventory cannot be reserved, the system carries out the following:

The system determines temporarily reserved inventories and removes them so that a reservable inventory becomes available for the person who created the demand. Temporary inventory reservations are determined in the evaluation of the inventory characteristics in the following sequence:

1. Identifier

Reservations for demand origins for which no identifier has been defined are considered before the reservations for demand origins for which a specific identifier has been defined.

2. Inventory owner sequence

If the customizing function Multiple inventory owners is activated, reservations are considered according to the inventory owner sequence.

3. Binding unit

Reservations are considered in the following binding unit sequence: Nonbinding, Included in packaging structure and Binding.

4. Packaging size

Reservations are considered in ascending order of packaging size.

5. Demand date

Reservations are considered in descending order of demand date.

Preferred reservations

If necessary, the reservations can be changed so that selected demand origins that could not initially be reserved or only partially reserved by the automatic reservations can still be fully reserved. This changes the reservations of other demand origins. The preferred reservation can be made automatically or influenced by the user.

Further information can be found in the Reservations article.

Customizing

You can set in the customizing function Reservations, whether and how you wish to reserve item quantities. If the customizing function Reservations is deactivated, then there are no changes. You only have identifier and storage
location reservations.

If the function is activated, then it affects the availability query and processes that change the inventory. For instance, item quantities from order line items are picked only in the amount they are reserved.

Whether and how the reservation will take place can be set in varoius applications. Please refer to the relevant application articles. You can find an insight under:

• Reservation settings in the Customizing application
• Reservation settings in the Warehouses application
• Reservation settings in the Items application
• Reservation settings in voucher type applications

Reservation settings in the Customizing application

You can carry out settings in the Reservations functions for OLTP clients and individual inventory management organizations in the Customizing application. Downstream inventory management organizations can use the Reservations function only if you activate it for the OLTP client.

You can also specify for the client whether planned receipts can also be reserved. You can also increase or decrease the reservation scope that can be set for all inventory management organizations.

However, this setting is only considered if the Customizing and Warehouses applications and the reservation scope is set to According to customizing setting according to the warehouse data of the inventory item or according to the inventory item itself. In all other cases, this setting is not considered.

The reservation scope can be:

• No reservations – the selected inventory logistics organization works without reservations.
• Inventory – only inventory is reserved for the selected inventory logistics organization.
• Inventory and planned receipts – both inventory and receipts are reserved for the selected inventory logistics organization.

You can also set the extent to which demand origins and demand coverage are automatically reserved or subsequently reserved, for example whether planned receipts should be automatically reserved immediately by demand origins that are not fully reserved when the demands coverage is increased.

You can use a date tolerance limit to define how the dates of planned receipts and issues are viewed and how a receipt reservation can be generated. Depending on the positive or negative entry, the following situations arise:

• The number of days is positive
  A planned receipt is also reserved if the demand coverage date is after the demand date of the demand origin. You therefore specify the maximum number of days that the demand coverage date may exceed the demand date.
• The number of days is negative
  A planned receipt is only reserved if the demand coverage date is before the demand date of the person creating the demands. You therefore specify the minimum number of days that the demand coverage date must be less than the demand date.
• The number of days is zero
  A planned receipt is reserved if the demand coverage date is before or identical to the demand date.

The deadline tolerance limit applies to both manual and automatic reservations.

Over-reservation can also be counteracted. An over-reservation occurs when the reserved inventory exceeds the current inventory. If the Automatic selection on reservation removal function is activated, an automatic attempt is made to remove reservations in full or in part until the over-reservation is removed. When determining the reservations to be removed, the system does not take into account any demand generators that require reservations. In particular, no reservations from delivery orders or sales orders with a procurement or production link are removed.

Furthermore, an over-reservation can be controlled. There is an overreservation if the reserved inventory exceeds the current inventory. If the function Automatic selection in reservation removal is activated, then it is attempted automatically to completely or partially remove the reservations until the over-reservation is removed. No demand origins are considered while determining the reservations to be removed; the reservations are imperative. No delivery order reservations or sales order reservations with purchasing or production connection are removed.

More information on the individual setting possibilities can be found in the article Customizing: Warehouse logistics.

Reservation settings in the Warehouses application

With the help of Reservations parameter in the Warehouses application, you can specify whether reservations are to be generated for the warehouse. The setting is applicable for all inventories and inventory owners in the warehouse. If the parameter is deactivated, then it takes precedence over the settings in the item master data. No reservations are  generated either if it is specified for the item that it can be reserved.

More information on this and other setting options can be found in the article Warehouses.

Reservation settings in the Items application

In the Inventory management view of the Items application, you can specify the reservation scope and categories for an item.

For additional information refer to the article Item,Inventory management view.

Reservation scope

With the help of the reservation scope, you can specify whether an item can be reserved and whether planned receipts of the item can be used as demand coverage. The following can be set as reservation scope:

• As per Customizing settings
• No reservations
• Inventory
• Inventory and planned receipts

The inventory and planned receipts of the item can be reserved with the setting Inventory and planned receipts. This setting is possible only if in the Customizing application it has been specified for the OLTP client that the planned receipts can be reserved.

Reservation category

With the help of the reservation category, you can determine type of the reservations. Reservation categories can be:

• According to voucher type settings
• Manual
• Automatically with reservation term
• Automatically without reservation term

Reservation term

The reservation period is the time period that lies immediately before the demand date and in which reservations occur automatically. The reservation can thus be generated shortly before the demand date. The field Reservation term can only be edited if Automatic with reservation date reservation category has been selected. The reservation date is entered in working days.

The delay in the generation of reservation using the reservation dates can lead to a better inventory conversion and a better delivery efficiency. In doing so, it must be kept in mind that up to the time point of the generation of reservation, the available inventory is available to other demand origins. This results in a level of uncertainty about the adherence to agreed delivery dates.

Reservation settings in voucher types applications

Some voucher categories represent the beginning of a reservation relevant process such as a sales order. In the following voucher type applications, you can set the reservation categories for it:

• Purchase order types
• Production order types
• Distribution order types
• Sales quotation types
• Sales order types

Possible values for reservation categories are:

• Manual
  Item quantities must be reserved manually using an action in the voucher application or using the Reservations application.
• Automatically with reservation term
  The reservation is automatically executed when the voucher has the status Released. You can also use this category to specify a reservation period: the reservation is executed at the earliest when the duration (calculated in working days) between the current date and the required date is equal to the specified reservation period or is shorter than the specified reservation period. See this chapter if required: Reservation term.
• Automatically without reservation term
  The reservation is automatically executed immediately if the voucher has the status Released. A reservation term cannot be specified.
• Automatically while starting Inventory management processes
  The reservation is automatically executed when a follow-on voucher is generated as part of the inventory management process. This can be a picking order or a delivery order, for example.

For purchase order types, the reservation category can only be determined for return transfers. The inventory must be
immediately reserved for return of goods. Therefore, only the following reservation categories are available:

• Manual
• Automatic without reservation term

With regard to the available selection of the reservation category depending on the respective voucher category, please refer to the relevant article for the corresponding voucher type application.

Identifier reservations

Identifier reservations are carried out if the customizing function Reservations is not active or reservations are not executed in a concrete context.

The quantity of planned issues of identifiers at a specific warehouse is specified through identifier reservation. The identifier reservation means that a specific identifier can only be picked or withdrawn up to the existing inventory quantity at a specific warehouse. An identifier is reserved only if an issue form the warehouse is involved. Neither put-aways nor warehouse-internal relocations of items managed in identifiers result in identifier reservations.

In contrast to reservations, identifier reservations do not contain any demand dates and therefore no information on the reservation origin. This is one of the most important differences from reservations. Items managed in serial numbers are exceptions. If a specific serial number is reserved, then the reservation origin is indicated directly on the serial number.

Further information can be found in the article Identifier reservations.

Storage location reservations

Storage locations can be reserved for future receipts and issues. Inventories in unstructured warehouse zones (except inventory count difference zone) are also reserved for issues and receipts. If the warehouse includes more than
one storage unit, slots will be reserved. Storage location reservations originate when inventory orders are generated or when a warehouse or an unstructured warehouse zone is explicitly specified in an inventory requisition. It is ensured that the sum of the real inventory and all open reservations is negative.

Further information can be found in the article Storage location reservations.

Reservation status

The reservation status gives information such as:

• Does a demand origin need to be reserved?
• To which level is the demand covered?
• Will a planned receipt be used to cover demands?
• Does a demand origin need to be reserved manually?
• Is a demand origin excluded from automatic reservation due to their status?

The reservation status is managed for demand origins and demand coverages.

The following icons represent the demand originator and demand decker status:

[no icon] – reservation not required or no open demand or no open demand coverage

– not reserved

– partially reserved

– completely reserved

The following icon is displayed if a demand is also covered through planned receipts:

– at least one of the reserved demand coverers is a planned receipt (only for demand origins).

The following icon is displayed if automatic reservation is excluded from a demand origin or a demand coverage:

– The demand origin or the demand coverage cannot be reserved automatically due to their status. In the respective voucher type, the Reservation exclusion field is used to define the status values for which automatic reservations are not made.

The following icon is displayed if a demand cannot be covered through automatically generated reservations:

– The reservation must be generated manually. Possible causes can be:

• The reservation type for the demand origin is set to Manual.
• A reservation has been entered for the demand origin manually.
• An automatically generated reservation has been changed.
  (only for demand origins)

You get the following reservation status:

– The demand is reserved in entirety. At least one of the reserved demand coverages is a planned receipt.

– The demand is not reserved. The uncovered demand must be reserved manually.

– The demand is reserved in part. Only inventory is reserved, not planned receipts. The uncovered demand must be reserved manually.

– The demand is completely reserved by the inventory. If, for example, the demand increases, then there is no automatic re-reservation, the status then changes to Reserved in part.

– The demand is reserved in part. At least one of the reserved demand coverages is a planned receipt. The uncovered demand must be reserved manually.

The following additional icon is displayed for demand origins if the relevant inventory is overreserved:

! – Inventory is overreserved.

If a reservation is forwarded from a voucher to the subsequent voucher in the voucher references chain, then a new reservation is generated and the old reservation gets the reservation status Completed. The completed status is not
shown through an icon, since no other reservation is necessary. For example, no reservation status icon is displayed for completely picked sales order line items.

Display of reservation information

In the following sections, you will come to know about the applications in which reservation information is displayed.

• Reservations application
• Voucher applications
• Query applications

Reservations application

With the help of the Reservations application, you can query reservations as well as create and edit them. If something is to be reserved without voucher, then you can create voucherless demands and reserve.

Further information can be found in the article Reservations.

Voucher applications

For the demand origin or coverage, the reservation status and reserved quantity are displayed in the line item view of the corresponding voucher application. Following voucher applications provide this information:

• Sales quotations
• Sales orders
• Picking orders
• Purchase orders (only for returns)
• Production orders
• Distribution orders
• Inventory requisitions

Delivery orders and inventory postings

In the Delivery orders application, the reservation status is not displayed, since the delivery order generation is possible only if the demand is covered through inventory and the reservations cannot be removed. For the same reason, no reservation status is displayed for inventory postings.

Picking orders

If no automatic identifier allocation takes place or it was not successful, then the identifiers for identifier managed items must be allocated through the reporting of the picking order manually. Reservations for the allocated identifiers are generated automatically. If the identifiers are not adequate in inventory, then a maximum of reserved quantity can be reported. In order to simplify the reporting, the reserved quantity is displayed in the Delivery order and Picking order views. The reservation status is not displayed.

Query applications

Reservation information can be queried and displayed in relevant applications. Below is an excerpt of applications with reservation information:

• PurchasingCockpit:
  • Purchase orders/line items
• Inventory management
  • Cockpit: Inventories
  • Cockpit: Inventories/items
  • Cockpit: Inventories/identifiers
  • Cockpit: Planned receipts and issues
  • Cockpit: Inventory requisitions/line items
  • Availability query
  • Edit logistic units
• Production
  • Cockpit: Production orders/material line items
• Sales
  • Cockpit: Sales quotations/line positions
  • Cockpit: Sales orders/line items
  • Cockpit: Distribution orders/line items

For more information, see the respective documentation for the application.

Use of the Workflow Management

Reservations can be changed manually or automatically, or deleted or made invalid. In order to, for instance, inform the responsible employee of the demand origin about the changes, the workflow management and the events available for it can be used.

The respective events and parameters are described below.

Further information on workflow events can be found in the article Introduction: Workflow management.

Workflow events for voucher categories

For the following voucher categories, workflow events are available since their reservations are not adequate sometimes. It can, for instance, happen due to the reduction of planned receipts quantities that are reserved as demand coverage by preferentially reserving selected demands origins:

• Sales orders
• Purchase orders (returns of goods)
• Production orders
• Distribution orders
• Inventory requisitions

In all other categories of demand origins, existing reservations cannot be changed by external influences. Therefore, there are no corresponding workflow events. This is also applicable for the picking and delivery order whose demands for each definition must be completely covered by the inventory. The deletion of such a reservation would lead to an inadmissible status.

For each of the abovementioned voucher categories, exactly three workflow events are available, whose technical names have been taken from the voucher categories and the action to be initiated.

Sales order:

SalesOrderReservationChanged
SalesOrderReservationDeleted
SalesOrderReservationInvalidated

Production order:

ProductionOrderReservationChanged
ProductionOrderReservationDeleted
ProductionOrderReservationInvalidated

Purchase order:

PurchaseOrderReservationChanged
PurchaseOrderReservationDeleted
PurchaseOrderReservationInvalidated

Distribution order:

DistributionOrderReservationChanged
DistributionOrderReservationDeleted
DistributionOrderReservationInvalidated

Inventory order:

WarehouseOrderReservationChanged
WarehouseOrderReservationDeleted
WarehouseOrderReservationInvalidated

Each workflow event has the following parameters of business object category:

order – hyperlink to demand origin voucherorderDetail – hyperlink to demand origin voucher line itemdemandOrigin – hyperlink to changed, deleted or invalid demand origin

The permitted values of the parameter order and orderDetail parameters depend on the respective voucher categories. For example, for the parameter order of the workflow event SalesOrderReservationChanged, an instance of the business object SalesOrder is a valid value.

Workflow event for over-reservation

In the following exceptional situations, the existence of a reservation cannot guarantee availability:

• if there is an over-reservation
• if the QA status of a partial inventory has deteriorated after a reservation has been created

These states are possible if the inventory is either written off, blocked or posted to quarantine inventory after a reservation.

As users should be made aware of such situations, a workflow event is triggered as soon as an over-reservation occurs for an item.

The following processes are relevant:

1. Inventory postings
2. Manual material postings (write-offs, transfer postings)
3. Transfer postings to quarantine inventory
4. Transfer postings to blocked inventory
5. Change in the QA status of the identifier, the warehouse zone or the warehouse

The following events must be distinguished:

1. If an over-reservation of an item without an identifier occurs in processes 1 to 4, this event is triggered: com.cisag.app.inventory.reservation.OnhandOverreservationThe following parameters are transferred for this workflow event:

• quantity = the quantity of the item in inventory
• quantityReserved = reserved quantity of the item
• inventoryOnhandRes = instance of the business object cisag.app.inventory.obj.InventoryOnhandReservation
• transaction = instance of the business object cisag.app.inventory.obj.InventoryTransaction

2. If an over-reservation of an item with an identifier in processes 1 to 4 occurs, this event is triggered: com.cisag.app.inventory.reservation.OnhandOverreservationIdentifierThe same parameters are transferred for this workflow event as for the com.cisag.app.inventory.reservation.OnhandOverreservation event, plus this parameter:

• identifieridentifier = instance of the business object cisag.app.inventory.obj.InventoryIdentifier

3. If an over-reservation of an item without an identifier occurs as a result of a change in the quality status of the warehouse zone or warehouse in process 5, then this event is triggered: com.cisag.app.inventory.reservation.QcUpdateOnhandOverreservationThe following parameters are transferred for this workflow event:

• quantity = the quantity of the item in inventory
• quantityReserved  = reserved quantity of the item
• inventoryOnhandRes = instance of the business object cisag.app.inventory.obj.InventoryOnhandReservation

4. If an over-reservation of an item with an identifier occurs as a result of a change in the quality status of the identifier, the warehouse zone or the warehouse, then this event is triggered: com.cisag.app.inventory.reservation.QcUpdateOnhandOverreservatio
nIdentifierThe same parameters are transferred for this workflow event as for the com.cisag.app.inventory.reservation.QcUpdateOnhandOverreservationevent, plus this parameter:

• identifier = instance of the business object cisag.app.inventory.obj.InventoryIdentifier

If, for example, you would like to send an email to a responsible employee when an item is overreserved, you can create an activity definition for this. An email with the following text as an example can be generated using the following script.

An over-reservation has occurred for the item {item} and the identifier {identifier} at the warehouse {storageArea} (inventory owner {owner}) due to inventory changes (material posting {transaction}). Inventory {quantity} {uom} – Reservations {quantityReserved} {uom}. Please check e.g. sales orders etc. with regard to their delivery reliability.

Script:

var item as CisObject(com.cisag.app.general.obj.Item); 
var inventoryOnhandRes as CisObject(com.cisag.app.inventory.obj.InventoryOnhandReservation); 
var transaction as CisObject(com.cisag.app.inventory.obj.InventoryTransaction); 
var identifier as CisObject(com.cisag.app.inventory.obj.InventoryIdentifier); 
var quantity as Number; 
var quantityReserved as Number; 
var warehouseUomIndex as Number; 
var uom as String;
 
transaction:=parameters.transaction; 
item:=parameters.inventoryOnhandRes ->Item; 
warehouseUomIndex:=item:warehouseUomIndex; 
inventoryOnhandRes :=parameters.inventoryOnhandRes; 
identifier := parameters.identifier; 
quantity := parameters.quantity:amount; 
quantityReserved := parameters.quantityReserved:amount; 
uom:=loadUom(parameters.quantity:uom):code; 

formatDescription("item", item:number); 
formatDescription("storageArea", inventoryOnhandRes->StorageArea:code); 
formatDescription("quantity", round(quantity, loadUom(parameters.quantity:uom):scale)); 
formatDescription("quantityReserved", round(quantityReserved, loadUom(parameters.quantityReserved:uom):scale)); 
formatDescription("uom", uom); 
formatDescription("transaction", transaction:number); 
formatDescription("owner", transaction->Owner:number); 
formatDescription("identifier", identifier:number);

Workflow events for changing the reservation setting and the reservation scope

Changing the Reservations function in the Customizing application, changing the reservation scope in the Customizing application or in the item master data, or changing the reservation function in the Warehouses application may result in demand data no longer being up-to-date. In some situations, however, it is advisable to ensure that the demand data corresponds to the settings mentioned. To update the demand data, the background application Update demand data is available, which can be called up after changing the settings. Workflow events are available to react to the changes mentioned, which are described in the following chapters:

• Workflow event for changing the Reservations function in the Customizing application
• Workflow event for changing the scope of the reservation in the Customizing application
• Workflow event for changing the reservation setting in the Warehouses application
• Workflow event for changing the reservation scope in the Items application in the inventory management data
• Workflow event for changing the reservation scope in the Items application in the item warehouse data

Workflow event for changing the Reservations function in the Customizing application

If the Reservations function is activated or deactivated in the Customizing application for a specific inventory management organization or for the client, this event is triggered: com.cisag.app.inventory.reservation.CustomizingReservationFunctionChanged

The event has the following parameter, which is of Business Object type:
organization – the partner associated with the inventory management organization(com.cisag.app.general.obj.Partner) for which the function has been activated or deactivated.

Workflow event for changing the scope of the reservation in the Customizing application

If the reservation scope is changed in the Reservations function in the Customizing application, this event is triggered: com.cisag.app.inventory.reservation.CustomizingReservationSupportLevelChanged

This event has the same parameter as the event that is triggered when the Reservations function is changed in the Customizing application. See parameter organization.

Workflow event for changing the reservation setting in the Warehouses application

If the reservation function is activated or deactivated in the Warehouses application, this event is triggered: com.cisag.app.inventory.reservation.WarehouseReservationsChanged

The event has the following parameter, which is of Business Object type:

warehouse – warehouse (com.cisag.app.inventory.obj.StorageArea) for which the changes were made.

Workflow event for changing the reservation scope in the Items application in the inventory management data

If the reservation scope is changed in the Item application in the inventory management data of the item, this event is triggered: com.cisag.app.inventory.reservation.ItemReservationSupportLevelChanged

The event has the following parameters, which are of the Business Object type:

item – item (com.cisag.app.general.obj.Item) for which the changes were made.

organization – the partner associated with the inventory management organization (com.cisag.app.general.obj.Partner) that manages the inventory management data.

Workflow event for changing the reservation scope in the Items application in the item warehouse data

If the reservation scope is changed in the Item application in the item warehouse data, this event is triggered: com.cisag.app.inventory.reservation.ItemWarehouseReservationSupportLevelChanged

The event has the following parameters, which are of the Business Object type:

item – item (com.cisag.app.general.obj.Item) for which the changes were made.

warehouse – warehouse (com.cisag.app.inventory.obj.StorageArea) for which the item warehouse data has been changed.

Calling up the Reservations application via the workflow task

If the Reservations application is to be linked with a workflow activity, then correct values must be saved for the  application parameter in the activity definition. The Reservations application has the following parameters relevant for
the workflow management:

CustomerProposal – sales quotation

CustomerProposalDetail – sales quotation line item

DistributionOrder – distribution order

DistributionOrderDetail – distribution order line item

InventoryIdentifier – identifier

Item – items

Partner – inventory owner

ProductionOrder – production order

ProductionOrderDetail – production order line item

PurchaseOrder – purchase order

PurchaseOrderDetail – purchase order line item

SalesOrder – sales order

SalesOrderDetail – sales order line item

StorageArea – warehouse

View – view of the Reservations application:

• 1 (issues)
• 2 (inventory)
• 3 (receipts and inventory)

WarehouseOrder – inventory requisition

WarehouseOrderDetail – inventory requisition line item

The parameter View decides the view in which the application is opened. The remaining parameters are the query criteria for the application. Maximum one of these parameters must be forwarded to the application. For the workflow event SalesOrderReservationChanged, the parameters View and SalesOrderDetail must be transferred.