Information Structures

Information Structures

In an information system, data aggregation is necessary in order to ensure that the user has a clear overview of key interrelationships. Since the requirements which need to be satisfied by data aggregation are determined by many different user groups, it is absolutely vital that aggregation functionality is flexible. Experience shows that various user groups need to view aggregated data from many different perspectives.

The SAP system makes these different views possible by providing self-defined information structures.

In the information structures, you can define your own view, by selecting the information from the operative application that you consider worthy of aggregation.

A distinction is made between three types of information:

• Characteristics

You can define a maximum of nine characteristics for each information structure. These characteristics form the table keys of the database table.

• Key figures

The key figures refer to values with significance to business, which are aggregated by means of the characteristics (e.g. invoiced sales, quantity of incoming orders, order quantity, lead time).

• Period split

The periodic cumulation of data is a further criterion for aggregation. The key figures are thus aggregated on a daily, weekly or monthly basis, or on the basis of a variable period split that is determined by the fiscal year variant.

Information structures can be classified according to certain structure characteristics. The standard information structures have the same basic structure (for example, they all contain four period fields). Information structures with the same indicator have the same structure type.
The following types of information structures can be used in LIS:

• Type '': Standard

Information structure with periodic transaction data. This is the normal type of information structure.

• Type 'C': Without period

Information structure containing no period data. It contains current stock values, for example the indicator "Stock".

• Type 'D': Without update

This information structure contains no actual data (or planning data, as applicable). It is therefore not possible to create an update for this information structure. This structure is necessary to ensure the periodic display of stock values. The actual data can be found in an assigned information structure, type 'standard' and 'without period'. The corresponding standard analysis reads the data from the assigned information structures and carries out a back calculation of stock.

• Type 'E': Standard (with stock values)

Information structure which contains periodic key figures including periodic stock values. These stock values must be included in the information structure at the end of the period (or any point) using a batch program.

• Type 'F': Document evaluation

Information structure used to display document data. These information structures are subject to various performance measures due to the volume of data expected (for example, planning is not allowed). Additional functionality exists within the standard analysis (for example, total document analysis). Implementation area: Shopping Basket Analysis IS-R.

• Type 'T': Transfer to SAP-BW

Special information structure for transfers to the Business Information

Warehouse (BW). This information structure cannot be used in Reporting. These information structures are subject to performance measures (for example, planning not allowed) due to the volume of data expected.

Use of these different types is dependent on the application in which they are to be created:
Type ' ': All applications (default)
Type 'C': Application 01 (Sales & Distribution), 03 (Inventory Controlling) and 40 (Retail)
Type 'D': Application 03 (Inventory Controlling) and 40 (Retail)
Type 'E': Application 03 (Inventory Controlling) and 40 (Retail)
Type 'F': Application 40 (Retail)
Type 'T': All applications

When creating a customer-defined information structure using the attribute Planning possible, you must decide whether this is relevant or not. An information structure of type 'C' or type 'F' cannot be relevant to planning.

It is important to consider whether the information structure to be created is to be used in planning, as information structures that cannot be used in planning significantly increase the speed of the evaluation during reporting. Information structures not relevant to planning have their existing key fields in the table converted, so that non-relevant fields (SSOUR, period fields not required) can be positioned at the end of the key fields.

This speeds up the database search. If the self-defined information structure is to be populated with data, the primary index checks each table key. Version 000 is always used as the search criteria. The client is the first position in the database key, as otherwise each table in the data dictionary is interpreted as client-independent. The characteristics are positioned directly after the clients in the database key.

The sections of the database key appear as follows:

Client - characteristics - version - ...

When the update is activated, the database key is converted again, so that the period selected for the update appears earlier in the key.
Example:

Client - month - characteristics - version - ...

In order to avoid an accidental loss of data, key fields from an information structure not relevant to planning are only converted if there is no data in the accompanying database table.
It is important to note the following:

• An information structure not relevant to planning can be used and updated with just one period (day, week, month, or posting period) in all clients of a system.

• Changing a period results in the key fields being converted. It is only possible to change a period if none of the clients have any data in the database table anymore.

The self-defined and the standard information structures form the basis for all of the subsequent functions in the information system (e.g. analyses, planning).

Note 439596 - Notes on Customizing planning processes

Note 439596 - Notes on Customizing planning processes

Summary

Symptom

This note provides advice about customizing planning processes. The note attempts, in particular, to provide answers to the following questions:

• Which planning processes correspond to the old options 'Immediate automatic planning' and 'Automatic planning in the planning run'.

• When must events be taken into account from the CIF and when must they not be taken into account.

• How does the action 'Cover Dep./Stk Tr. Requirement immediately' differ from the action 'Start Product Heuristic Immediately'.

• What do I need to take into account when customizing the planning process 'Cover dependent requirements immediately'.

• Why is there a difference between creating and changing planned orders, but not between creating and changing purchase requisitions, for example.

• How is the reuse mode determined.

Other terms

Planning process, Customizing, Documentation

Reason and Prerequisites
Immediate automatic planning and automatic planning in the planning run

The 'immediate automatic planning' was replaced by the planning process 'Cover dependent requirements immediately'.The 'automatic planning in the planning run' was replaced by the planning process 'Planning in the planning run'.
With the Customizing for planning processes, two types of immediate planning are now possible.The system can either execute a heuristic directly after saving or the algorithm in Release 3.0 known as 'Immediate automatic planning' can be executed.We have therefore decided to rename the planning processes.
Details on the planning process 'Cover dependent requirements immediately' are provided later on in this note.

Including changes from the CIF

Customizing of the planning processes allows it to respond to changes transferred via the CIF interface to the APO system differently to changes originally made by the user or the system (for instance in the form of a heuristic) in APO.In each case, there is an event for a change in APO and one for a change transferred to the APO system via the CIF interface.
Certain objects are therefore usually changed in exactly one system, either in the APO system or in a R/3 System (or a CRM system or another OLTP System).Despite this, these objects are frequently replicated in other systems.The APO system therefore requires complete information on the development of requirements a product.The APO system needs the data for this from the sales orders.The sales orders themselves are managed in an R/3 or CRM system.However, they need to be replicated in the APO system.
Conversely, planned orders are only changed in the APO system, for example (this depends on which processes you want to support with APO).The change sent to the APO system as part of key completion of R/3 is exactly the same as the change that was already executed in APO itself.The change which is sent to the APO system by R/3 within the framework of the key completion is exactly the same change which was carried out before in the APO itself.This change does not need to be taken into account in the planning again. Set the events 'Create or Change Planned Order in OLTP System' and 'Create or Change a Dependent Requirement in OLTP System' in such a way that no action is to be carried out.
Your process may make provision for changing production orders in the OLTP system (in a R/3 system, for example). These changes can cause changed reservations. The planning in APO must react to this. The resources there must be adjusted accordingly. Set an action (for example, 'Create Planning File Entries') for the events 'Create or Change Production Order in OLTP System' and 'Create or Change a Dependent Reservation in OLTP'.
Try to avoid making simultaneous changes to the same objects in different systems.

How does the action 'Cover Dep./Stk. Tr. Requirement Immediately' differ from the action 'Start Product Heuristic Immediately'.

The planning process 'Cover Dependent Requirements Immediately' ensures that the system reacts to the event 'Create or Change Dependent/Stock Transfer Reqmt in PP/DS' with the action 'Cover Dep./Stk. Tr. Requirement Immediately'.
If a planned order P changes (planned order is recreated or the quantity is changed or there is a new explosion for the planned order), the dependent requirements A for the planned order P are also changed, of course.The system then creates one or more receipt elements B1, B2, ... to cover the dependent requirement A. The action 'Cover dependent requirements immediately' has the following individual features:
The action 'Cover Dep./Stk. Tr. Requirement Immediately' has the following features:

• When calculating the quantities for the receipt elements the system takes into account the receipt elements Bn maximum and maximum lot size, fixed order quantity and rounding quantities.Other lot size parameters are ignored.

• If the receipt element Bn cannot be provided in time and the scheduling strategy allows forward scheduling, the planned order P can be shifted to the future in order to create a feasible production plan.This can also occur in several stages. In addition, you can only shift the user P to the future in the case of an overdue component if you use the action 'Cover Dep./Stk. Tr. Requirement Immediately'.

• The planning process 'Cover Dependent Requirements Immediately' also works for stock transfers if the stock transfer is scheduled via resources (Handling resource and/or transport resource).

• If, for example, a planned order P is changed interactively in the product view or product planning table, the system implements the required planning steps for the components immediately online so that the results are immediately visible from the component planning.

• The planning process 'Cover Dependent Requirements Immediately' is a precondition for the CTP check.All products that are supposed to participate in a CTP check must have the planning process 'Cover dependent requirements immediately'.

• You cannot call a heuristic to cover the dependent requirement.

• A planning process with the action 'Cover Dep./Stk. Tr. Requirement Immediately' can only react to a limited number of events. For details, see the next section.

A planning process that carries out the action 'Start Product Heuristic Immediately' has the following features:

• Using the heuristic, you can implement any lot size procedures.

• In the event of non-availability or late availability of a component, there is no change in the higher-level production level.The planned order with dependent requirements that can only be covered late cannot be automatically postponed.Where necessary this can be achieved by an additional call of one the heuristics SAP_PP_008 or SAP_PP_009.

• The heuristic is only started after the last change is saved.If changes are made online, the results of the heuristic are not immediately visible.

• The heuristic can react to any events, so it is not limited to changes of dependent requirements.

What should be considered during Customizing of the planning process 'Cover dependent requirements immediately'?

The action 'Cover Dep./Stk. Tr. Requirement Immediately' needs the connection between the planned order P and the resources Bn that resolve a dependent demand A of the planned order P. This connection is only known in the case of changes of P in APO. If one of the resources Bn is changed independently of P, the connection is not known. P cannot be changed.This applies to the change in resources Bn in APO and particularly to changes in the resources Bn that are transferred to APO by R/3 via CIF. If you call a heuristic when you make the changes to Bn (or set a planning file entry so that the heuristic is called later), this heuristic can destroy the planning result from the action 'Cover Dep./Stk. Tr. Requirement Immediately'. We therefore recommend that you only respond to the following events as part of the planning process 'Cover Dependent Requirements Immediately':

• Creation/change of dependent requirements or stock transfer requirements in the APO

• Change of a plan.Here we can re-explode the existing planned orders for the product.

• Changes of sales orders.Sales orders cannot be shifted to the future in any case.You should respond to a change in sales orders by immediately executing a heuristic.This heuristic is only executed when the sales order is saved, not during the ATP check.To adjust the resource elements of the sales order when the quantity of the sales order is reduced or when the sales order is postponed.When sales orders are created, or the number of sales orders increases or sales orders are shifted towards the present, the ATP check takes over the task of generating resources.The heuristic is therefore not suited for lot sizing.It should be based on the algorithm /SAPAPO/HEU_PLAN_DEFICITS, particularly in 'Reduce surpluses' (the corresponding check box is set in the heuristic Customizing).The heuristic SAP_PP_003 is set like this in the standard system.

• If there is a subassembly planning for the product of the dependent requirement A then you should also react to the event 'Create or change a planned independent requirement' by immediately calling a heuristic.

• If there is subassembly planning for the product of the dependent requirement A and if the consumption mode in the product master only allows backward consumption, then the system may react to the event 'Reduction of Planned Independent Requirement w. Consumption' by calling a heuristic immediately, however, this does not have to happen. If the SAP_PP_002 standard lot size heuristic reacts to the result, then the replenishment elements originally intended for covering the planned independent requirement are adjusted to the new dependent requirements.If there is no reaction to the event, the original replenishment elements remain.Since in the case of backward consumption the original replenishment element always appears before the new dependent requirement, this does not cause any constraint violation.If there is a reaction to the event, the plan is adapted better to the requirements.However, this has the disadvantage that the receipt elements are changed more frequently.If the receipt elements should not be changed if possible, use the SAP_PP_003 heuristic.

• If there is a subassembly planning for the product of the dependent requirement A, and if the consumption mode in the product master also allows forward consumption, a planned independent requirement that is behind the dependent requirement can be reduced through the consumption.An access element for this planned independent requirement may represent an excess coverage after the consumption.In this case, we would advise you to respond to the 'Reduction of planned independent requirement through allocation' event by immediately calling the SAP_PP_002 standard lot size heuristic.

Why is there a difference between creating and changing planned orders, but not between creating and changing purchase requisitions, for example.

In addition to defining the activity on an event, the Customizing of the planning processes also allows you to define the desired planning status.A popular scenario creates new planned orders so that they are always deallocated. Scheduling then occurs manually in the planning table.Once a planned order has been scheduled, it should either retain its planning status or be deallocated again if there are changes in the quantity. You can adjust this using the scheduling status settings for the event 'Change an In-House Production Order in PP/DS'. In exactly the same way, you can set planned orders to be created as soon as they are scheduled.
Purchase requisitions do not have a planning status.You therefore do not have to distinguish between creation and changing.

How is the reuse mode determined

For every event, you can specify exactly which reuse mode is required.For changes to the quantities or dates of product requirements or product receipts, you can always obtain existing non-fixed product receipts (planned orders, purchase requisitions) as long as the quantity and date for the particular planned order still correspond to the requirement situation.
In the case of changes to plans (PPM, LZO), all planned orders must be exploded again unless the explosion of the planned order is frozen.The planned order is then re-exploded if the output of the planned order is fixed (and of course properly when the planned order is not fixed).If there is a change in the goods receipt processing time in the product master, the planned orders of the product must also be exploded again.
The maintenance dialog for the Customizing of the planning processes is generated.The generating tool only allows certain changes to the maintenance dialog.It was therefore not possible to fill the reuse mode automatically, even if only one entry was always allowed for each event.Use the permitted entry.

Solution

Find the Customizing for planning processes as follows:
Call transaction SPRO in your APO system.
Click on the SAP Reference IMG pushbutton
Open the following menu path:
SAP APO Implementation Guide
SAP Advanced Planner and Optimizer
Supply Chain Planning
Production Planning and Detailed Scheduling
Maintain Planning Processes

Header Data

Release Status:	Released for Customer
Released on:	07.05.2003 10:28:24
Master Language:	German
Priority:	Recommendations/additional info
Category:	Consulting
Primary Component:	SCM-APO-PPS Production Planning and Detailed Scheduling
Secondary Components:	SCM-APO-PPS-SCF Scheduling Functions

Affected Releases

Software Component Release From Release To Release And subsequent SAP_APO 310 310 310 SCM 400 400 400 SCM 410 410 410

Related Notes

	557731 - Planning file entry + reuse mode (documentation)
	480292 - Multilevel ATP (documentation)
	441102 - Consulting notes in PP/DS
	426563 - CTP: Settings, system behavior and performance (docu)

PP Planning Procedures

PP Planning Procedures

Definition

Setting in the location product master that:

· Determines the Production Planning and Detailed Scheduling (PP/DS) reactions to planning-relevant events

· Determines the pegging-relevant quantity of customer requirements across all applications

Use

Determining the reactions to planning-relevant events

This usage is specific to PP/DS. In the PP planning procedure, for each planning-relevant event that can occur for a location product, you specify which action Production Planning and Detailed Scheduling (PP/DS) should automatically execute when this event occurs. A planning-relevant event is, for example, a goods movement for a product in an OLTP system or a change to the product master in the SAP APO system. As possible actions, PP/DS can, for example, immediately call the product heuristic or create a planning file entry for the product.

SAP delivers standard planning procedures that it recommends you to use in certain scenarios. However, you can also define your own planning procedures. You should reconcile these carefully with your planning processes, because only certain event-action combinations can be used effectively within a planning procedure.

To be able to plan a product using PP/DS, you must have entered a planning procedure in the location product master. You define planning procedures in Customizing for Production Planning and Detailed Scheduling (PP/DS).

Determining the pegging-relevant quantity for customer requirements

You define in the planning procedure whether the desired quantity or the confirmed quantity of customer requirements is relevant for pegging. This setting is relevant for all planning applications in SAP APO.

For more information, see Defining the Pegging-Relevant Quantity for Customer Requirements.

Structure

The PP planning procedure contains the following elements:

· Planning-relevant event

SAP provides a selection of events that are typical in production planning. The events can be divided into the following groups:

¡ Changing master data in the SAP APO system (such as product, plan, or transportation lane)

¡ Changing stock in the OLTP system

¡ Creating or changing requirements elements of orders (customer requirements, planned independent requirements, dependent requirements, and stock transport requirements) in PP/DS or in the OLTP system

¡ Creating or changing receipt elements for in-house production orders or external procurement orders in PP/DS or in the OLTP system

· Action

If an event occurs, PP/DS automatically executes the action that you specified in the planning procedure for the event. The following actions are available:

¡ Do nothing

¡ Cover dependent and stock transfer requirements

There are three different actions that PP/DS uses to react to dependent or stock transfer requirements being created or changed for a product. PP/DS tries to cover a new or changed dependent or stock transfer requirement by - depending on the action - using existing receipts, creating new receipts, or rescheduling the superordinate pegged requirement.

¡ Start product heuristic immediately

PP/DS schedules the product immediately with the product heuristic defined for the product.

¡ Create planning file entry

PP/DS creates a planning file entry for the product. You can use net change planning to plan products with planning file entries. The advantage of planning in the production planning run is that you can control when and how often products are planned. To avoid overloading the system performance, you can execute the production planning runs at night, for example.

PP/DS only executes an action if you have set the PP/DS: net change planning active indicator in the planning version. It is only then that you can use the planning version for PP/DS.

· Reuse Mode

The reuse mode is relevant to the actions Create Planning File Entry and Start Product Heuristic Immediately. The reuse mode determines how a procurement planning heuristic processes existing procurement proposals. SAP has configured a fixed reuse mode is configured for each event-action combination. For more information, see Reuse Mode for the Planning File Entry.

Scheduling status

You can specify which scheduling status an in-house production order is given,

¡ If a receipt element from an in-house production order is created in PP/DS or in an OLTP system

¡ If a quantity-related or product-related change is executed for a receipt element from an in-house production order

PP planning procedure in an integrated system landscape

For planning-relevant events, a distinction is made between events that occur in an OLTP system and events that occur in PP/DS. PP/DS may react differently to planning-relevant changes that were originally made in an OLTP system and were transferred to the SAP APO system, than to changes that were originally made in PP/DS. Since integration means that an event in the SAP APO system is often linked to a corresponding event from the OLTP system (and the opposite), you must take your planning procedure into consideration when you decide to which event PP/DS should react. You should try to avoid a situation where PP/DS reacts to a planning-relevant change several times or in different ways.

· For example, you manage customer requirements for critical products that you are planning in SAP APO in an OLTP system, and then transfer them to the SAP APO system. PP/DS can react to new or changed customer requirements by executing the product heuristic planning shortage quantities, for example. The product heuristic can create a planned order for the product. This triggers events in PP/DS for the creation of receipt and requirements elements of the planned order, to which PP/DS, in turn, must react. The subsequent transfer of the planned order to the OLTP system causes corresponding events for the creation of receipt and requirements elements in the OLTP system. These events are based on the same planning-relevant changes to which PP/DS has already reacted. You should therefore specify that PP/DS should not execute any actions for the events creating or changing a planned order in an OLTP system, creating or changing dependent requirements in an OLTP system, and creating or changing stock transport requirements in an OLTP system.

· Changes to manufacturing orders in the OLTP system can result in changed reservations, to which PP/DS must react by adjusting the relevant receipt elements. You should therefore set an action in the planning procedure for the corresponding event (change a manufacturing order in the OLTP system, change a dependent reservation in the OLTP system) such as, for example, create planning file entry.

See also

SAP note 439596

Forecast Consumption and Requirment Strategy

source: http://help.sap.com/saphelp_scm2007/helpdata/en/e6/28dadc939241469dd64f0eb925f328/frameset.htm

Forecast Consumption:
The purpose of consumption is to ensure that requirements are not duplicated in the system and that the most detailed requirements are used. Forecasts and sales orders are for instance both requirements. Since a forecast is less specific than a sales order, it is reduced when other more specific requirements, such as sales orders, exist for the same product. In this way if both forecasts and sales orders are used to generate receipt elements, for example planned orders, the correct quantity is always generated.

The customer requirement consumes the planned independent requirement quantity that lies either directly before it or directly after it. You specify whether the system checks against planned independent requirements in the future or in the past by setting the Consumption Mode field on the Demand tab page of the location-specific product master. The assignment of customer requirements to planned independent requirements is carried out dynamically. This means that if requirements are rescheduled, the assignment is deleted and redefined.

There are four quantities that are important in connection with planned independent requirements in SAP APO and that enable the system to administer consumption dynamically:

· Planned quantity

This is the original forecast amount for which the forecast was created.

· Assigned quantity

This is the quantity in the forecast that has been consumed by other order categories, for instance sales orders. Note that this quantity is not stored, it is calculated at runtime.

· Open planned quantity

This is the planned quantity that has not been assigned or withdrawn from stock.

· Withdrawal quantity

This is the quantity that has produced/procured and for which a goods issue has been posted in SAP R/3.

Requirements Strategy:

Basically, the requirements strategy assigns an (ATP) category for the forecast (such as FA or FC) to an (ATP) category group that can consume the forecast. The category group can consist of one or more categories. Therefore, in the above example, forecast order category FA can be consumed by the following:

· Reservations (AM)

· Dependent demand (AY)

· Sales orders (BM)

· Customer requirements (BS)

The requirements strategy is equivalent to the planning strategy in SAP R/3. However, the functionality is simpler than that in SAP R/3.

Assignment Mode

The assignment mode determines how sales orders consume the forecast, and whether final assembly is taken into account. It corresponds to the allocation indicator in SAP R/3. This indicator is assigned to the sales order via the requirements class (requirement class corresponds to Check Mode in APO).

There are four allocation indicators:
No consumption with customer requirements
1 Consume planning with assembly
2 Consume planning w/o assembly
3 Consume planning material (w/o assembly)

SAP provides four strategies in the standard system:

10 Anonymous make-to-stock production

20 Planning with final assembly

30 Planning without final assembly

40 Planning product

If these are not sufficient for your needs, you can create your own requirements strategies in Customizing for SAP APO under Master Data ® Specify Requirements Strategies

ATP Category

Cat	Cat. Text	Category Description	Sort	Typ	ME	Rel.SL	R/3 Object
AA	PrcOrd (C)	Process Order (Created)	25	1	BR		6
AB	PrcOrd (R)	Process Order (Released)	25	1	BR		6
AC	PrdOrd (C)	Production Order (Created)	25	1	FE		6
AD	PrdOrd (R)	Production order (released)	25	1	FE		6
AE	PrjOrd (C)	Project Order (Created)	25	1	NE		6
AF	PrjOrd (R)	Project Order (Released)	25	1	NE		6
AG	PurRqs	Purchase Requisition	20	1	BA		1
AH	PO memo	Advanced Shipping Notification	20	1	LA		2
AI	PlOrd.	Planned order (not firmed, unconfirmed)	23	1	PA		5
AJ	PlOrd. (F)	Planned order (firmed, unconfirmed)	23	1	PA		5
AK	PlOrd.(NC)	Planned order (not firmed, confirmed)	23	1	PA		5
AL	PlOrd.(CF)	Planned order (confirmed, firmed)	23	1	PA		5
AM	ProdRes	ProdRes. not withdrawable, location-rel.	30	2	MR		7
AN	PrdRes (W)	MatRes. withdrawable, location-relevant	30	2	MR		7
AO	PrdRes (N)	MatRes. not withdrawable, not locn-rel.	30	2	MR	X	7
AP	MatRes(WN)	MatRes withdrawable, not location-rel.	30	2	MR	X	7
AQ	ProdRes	ProdRes. not withdrawable, location-rel.	30	1	MR		7
AR	PrdRes (W)	MatRes. withdrawable, location-relevant	30	1	MR		7
AS	PrdRes (N)	MatRes. not withdrawable, not locn-rel.	30	1	MR	X	7
AT	MatRes(WN)	MatRes withdrawable, not location-rel.	30	1	MR	X	7
AU	OrdRes	Order reservation not withdrawable	31	2	AR		7
AV	OrdRes (W)	Order reservation withdrawable	31	2	AR		7
AW	OrdRes	Order reservation not withdrawable	31	1	AR		7
AX	OrdRes (W)	Order reservation withdrawable	31	1	AR		7
AY	DepDmd	Dependent demand	32	2	SB		7
AZ	DepDmd	Dependent demand	32	1	SB		7
BA	SubReq	Subcontractor requirements	33	2	BB		7
BB	SubReq	Subcontractor requirements	33	1	BB		7
BC	StkTrfRes	Stock transfer reservation	34	2	UL		7
BD	StkTrfRes	Stock transfer reservation	34	1	UL		7
BE	SchLne	Scheduling Agreement Schedule Line	40	1	LE		2
BF	PchOrd	Order item schedule line	40	1	BE		2
BG	PORet	Purchase order returns item	40	2	RP		2
BH	PReqRel	Stock transport requisition	41	2	U2		1
BI	ConRel	Stock transport order	42	2	U1		2
BJ	SchAgrReq	Suppliers' SchdlngAgrmtRqmt	43	2	U4		2
BK	Inquiry	Customer inquiry	20	2	VA		3
BL	Quotation	Customer quotation	20	2	VB		3
BM	SalesOrder	Sales order	20	2	VC		3
BN	SchAgr	SD scheduling agreement	20	2	VE		3
BO	SA ExS	Scheduling agreement w/external services	20	2	VF		3
BP	Contr.	Contract	20	2	VG		3
BQ	FreeDeliv	Delivery w/o charge	20	2	VI		3
BR	Deliv.	Delivery	20	2	VJ		B
BS	CusReq	Independent requirements	20	2	VW		3
BT	ReturnsDel	Returns delivery	50	1	VT		B
BU	QM lot	Inspection lot	30	1	QM
BV	SAgRel	Scheduling Agreement Release	40	1	LE		2
BW	SAgRelReq	Suppliers' Release Order Reqmt	40	2
BX	DelivReq	Delivery Request	20	2	VZ		B
BY	SD RetDel	SD Returns Delivery	20	1	VH		B
BZ	SD Returns	SD Returns	20	1	VH		3
CA	Stock/tsfr	Stock in transfer (location to location)	1				0
CB	SafetyStck	Parameter-Dependent ATP Safety Stock	1				0
CC	Stock	Valuated, unrestricted-use stock	1				0
CD	ConsiStock	Valuated, unrestr.-use consignment stock	1				0
CE	SubconStck	Valuated, unr.-use subcontracting stock	1				0
CF	InspctnStk	Stock in quality inspection	1				0
CG	InspConStk	Consignment stock in quality inspection	1				0
CH	InspSubStk	Subcontracting stock in qual. inspection	1				0
CI	BlockedStk	Blocked stock	1				0
CJ	BlckConStk	Blocked consignment stock	1				0
CK	RstrUseStk	Restricted-use stock	1				0
CL	RsUseCnStk	Restricted-use consignment stock	1				0
CM	RsUseSbStk	Restricted-use subcontracting stock	1				0
CN	TsStkSb	Stock in transfer (subloc. to subloc.)	1			X	0
CO	MntOrd(C)	Maintenance order (created)	25	1	IH		6
CP	MaintOrd	Maintenance order (released)	25	1	IH		6
CQ	QueryPlnd	Query process planned	20	1			1
CR	QryPblshd	Query process published	20	1			1
CS	StkInTrnst	Stock in Transit	1				0
DD	Stock	Stock	1				0
DN	Dep:SubReq	Dep: Requirement from Substitution	35	2			8
DO	Dep:SubRct	Dep: Receipt from Substitution	35	1			8
EA	SNP: PReq	SNP: Purchase requisition	20	1	BA		1
EB	SNP:Rel.PR	SNP: Release for stk transp. requisition	41	2	U2		1
ED	SNP:VMI-SO	SNP: VMI sales order		2
EE	SNP:PL-ORD	SNP: Planned order	23	1	PA		5
EF	DEP: PReq	Deployment: Purchase requisition	20	1	BA		1
EG	DEP:ConRl	Deployment: Release for stk transf. req	41	2	U2		1
EH	DEP:VMI-SO	Deployment: VMI sales order		2
EI	In Transit	In Transit	40	1	BE		2
EJ	TLB:Rel.PR	TLB: Release for purchase order	42	2	U1		2
EK	TLB:VMI-SO	TLB: VMI sales order	20	2	VC		3
EL	SNP:DepDmd	SNP: Dependent demand	32	2	SB		7
EM	SNP:PL-JP	SNP: Receipt from manuf. of co-products	32	1	SB		7
EN	SNP:ReqSub	SNP: Requirement from substitution	35	2			8
EO	SNPSubRcpt	SNP: Receipt from substitution	35	1			8
EQ	StkTrsfDel	Replenishment delivery	20	2	VJ		B
ER	VMI dely	VMI delivery	20	2	VJ		B
ES	SNP:PL-ORD	SNP: Planned Order (Subcontracting)	23	1	PA		5
ET	SNP: PReq	SNP: Purchase Requisition (Subcontract.)	20	1	BA		1
EU	SNP:PReqRl	Stock Transport Requisition (Subcontrc.)	41	2	U2		1
FA	FC req.	Planned independent requirements		3			4
FB	VMI:PROMO	VMI: Demand for promotions		3			4
FC	Forecast	Forecast Sales Demand		3			4
FD	VMI-FCST	ICH: VMI Forecast		3			4
FE	IntFrcDesc	Internal Forecast f. IntFrcDesc. in SNP		3
GA	Subst.ord.	Substitution Order	35	1			8
GB	Subst.req.	Substitution Requirement	35	2			8
GC	CmbOrd	CmbOrd - Combined Order	99	1
GD	FSUBSTAUF	Extended Substitution Order	35	1			8
GE	FSUBSTBED	Extended Substitution Demand	35	2			8
GF	ExF CP Rct	Forwarding of Excess to CP Receipt	36	1			8
GG	ExF CP Dmd	Forwarding of Excess to CP Demand	36	2			8
GH	ExF SubRct	Excess Forward. Subst. Receipt(1:1,FFF)	40	1			8
GI	ExF SubDmd	Excess Forwarding Subst.Demand (1:1,FFF)	40	2			8
HA	SA-ConfRel	Comfirmation in Plant - SA	40	1	LE		2
HB	SA-CRelReq	Confirmation at Vendor - SA	57	2
HC	SD SA Rel.	Release from Customer in Plant - SD SA	57	2			8
HD	SA-ConfRel	Release at Customer - SD Sched. Agrmt.	40	1
HE	SA Conf.	Confirm. for Customer in Plant - SD SSA	57	2	VE		3
HF	SA-CRelRec	Confirmation at Customer - SD SA	40	1
HG	SNP SA SL	SNP: Sched. Agreement Sched.Line - SA	40	1
HJ	SNP SA Dmd	SNP: Suppliers Sched.Agrmt Demand - SA	53	2
HV	SNP SA Rel	SNP: Scheduling Agreement Release - SA	40	1
HW	SNP SA Dmd	SNP: Suppliers Release Demand - SA	57	2
HX	SNP SACnfI	SNP: Confirmation for SA Issue	57	2
HY	SNP SACnfR	SNP: Confirmation for SA Receipt	57	1
IA	Temp. Req.	Temporary Requirement for Char. Eval.		3			8
IB	ICH:VMI SO	ICH: VMI Sales Order	20	2	VC		3
IC	ICH:VMI DL	ICH: VMI Delivery	20	2	VJ		B
ID	Temp. Req.	Temporary Requirement Subassembly Plng	32	2	SB		7
IW	ShpNotPlnt	Shipping Notification in Plant	19	1	LA		2
KA	SPP FCST	SPP Forecast		3
KB	SPPSTR IN	SPP Stock Transfer (Receipt)		1
KC	SPPSTR OUT	SPP Stock Transfer (Demand)		2
KD	SPPSTR-VR	SPP Stock Transfer VCL (Receipt)		1
KF	SPPSTR-VD	SPP Stock Transfer VCL (Demand)		2
KG	SPPLIESCRT	SPP Scrapping (Delivery Requirement)	45	2	VJ		B
SR	SStk Req.	Safety Stock as Requirement	10	2