Purpose of this Document
The purpose of this document is to explain the flags in the scope of check (transaction OVZ9) and to clarify which tables are read for each respective flag. It shall also give a brief logic behind each of the flags and the code where this logic is applied.
Motivation of this document
Troubleshooting ATP issues inevitably brings you to transaction CO09. The most common ATP issue is the complaint “System tells me there is 0 available but there is something available in MMBE”. CO09 will usually reveal the cause of such system behaviour. CO09 will display all the stock / receipt elements & requirements elements according to your scope of check. However, it can sometimes be difficult to know what exactly these elements are and where they are read from. An SAP consultant may have a background in SD and PP but not in MM. When that consultant sees an SD or PP element in the element list of CO09, they know immediately what it is referring to and where it came from. However, that same consultant may struggle when they see an MM element. They do not know which table it came from, how it was created in that table etc. This can be frustrating if the consultant sees an element in CO09 on their production system and wants to replicate the same on their non-production system. You arguably cannot tell the full story of the ATP overview if you are unaware of how the elements got into CO09.
Furthermore, the flags in the scope of check can be somewhat ambiguous; for example, the difference between “Incl dependent reqs” and “Incl. depen. reservat” could easily be confused. You turn one flag on, both flags on, one flag on & one flag off in a trial and error approach to see what the difference would be.
Such struggles led to the creation of a file, now manifested into this document. This document ensures that the consultant does not have to debug into CO09 every time they come across an element they might be unfamiliar with. If it is necessary to debug into CO09, the document provides a starting point for debugging analysis for each respective flag. The document is intended to provide a quick reference that allows the reader to understand where the element is coming from and why it is being displayed in CO09.
____________________________________________________________________________________________________________________________
Part 1: Stocks
1) Include Safety Stock:
Table it reads from: MARC (Plant Data for Material)
Example of how this entry gets created in table MARC: Field “Safety Stock” in the MRP2 tab of the material master (Figure 1).
Figure 1: Safety Stock field in Material Master
Figure 2: Safety Stock field in table MARC
Logic of the flag: Select on table MARC for the material and the plant. If flag is turned off, the safety stock maintained in the material master is subtracted from the available stock.
An example in CO09: There is unrestricted stock of 10 with no receipts or requirements. The safety stock is 2.
Flag turned on: Available stock = 10
Flag turned off: Available stock = 8.
Code that implements this logic:
| Include LMG22FSQ / FORM SELECT_SINGLE: |
|---|
SELECT SINGLE * FROM MARC WHERE MATNR = MARC_KEYTAB-MATNR and WERKS = MARC_KEYTAB-WERKS |
Table 1: Select the material data from table MARC
| Include LATP2FSE / FORM STOCK_READ: |
|---|
* exclude safety stock IF G_T441V-EISBP <> XFLAG. L_ATPK-MNG01 = L_ATPK-MNG01 - ATPMAT-EISBE. ENDIF. |
Table 2: Safety stock subtracted from available stock.
2) Incl. Stock in transfer:
Table it reads from: MARC (Plant Data for Material)
Figure 3: "In Transfer" field in the material master
Example of how this entry gets created in table MARC: Transfer posting in MIGO_TR updates the value in table MARC. E.G a transfer posting (movement type 303) is posted for a quantity of 5. This updates the “in Transfer (Plant)” field in the “Plant Stock” tab of the material master (for the destination plant).
Logic of the flag: When flag is turned on, the value in the “in Transfer (Plant)” field is added to the available stock of the receiving plant.
An example in CO09: There is unrestricted stock of 10 with no receipts or requirements. A goods movement of movement type 303 is posted from plant 0001 to plant 0002. This sets the stock in transfer to 5.
Flag turned on: Available stock = 15 (10 + 5) in plant 0002.
Flag turned off: Available stock = 10 (10) in plant 0002.
Code that implements this logic:
| Include LATP2FSE / Form STOCK_READ: |
|---|
* include stock in transfer between plant in receiving plant IF G_T441V-UMLMP = XFLAG AND ( ATPGSW-DBFLG = SWOFF OR CM61B-BERID = ATPGA-BERID ). L_ATPK-MNG01 = L_ATPK-MNG01 + ATPMAT-UMLMC. ENDIF. |
Table 3: Stock in transfer (ATPMAT-UMLMC) added to the available stock
3) Incl. quality insp. Stock:
I)
Table it reads from: MARD (Storage Location Data for Material)
Example of how this entry gets created in table MARD: Can occur by creating a goods receipt in MIGO of type “Quality Inspection” (See figure 4)
Figure 4: Quality Inspection Stock type in MIGO
Figure 5: Field INSME in table MARD
Logic of the flag: If flag is set, the “In Quality Inspection” (INSME) from table MARD (figure 5) is added to the available stock. If the flag is not set, the “In Quality Inspection” (INSME) from table MARD is not added to the available stock.
An example in CO09:
- There is 7 in unrestricted stock. A Goods movement with a quantity of 100 is posted into QI stock; this creates a quantity in MARD-INSME as illustrated in figure 5).
Flag turned on: Available stock = 107.
Flag turned off: Available stock = 7.
Code that implements this logic:
| Include LATP2FM3 / FORM MARD_CHECK |
|---|
IF ATPMAT-INSMK IS INITIAL OR ( ATPMAT-INSMK EQ XFLAG AND LV_XHUPF EQ XFLAG ). S_ATPK-MNG01 = S_ATPK-MNG01 + MARD-INSME + MARD-KINSM. ENDIF. ENDIF. |
Table 4: Add the quality stock (INSME) to the available stock
ii)
Table it reads from: MDQM (MRP View of the QM Inspection Lot). This is a view of tables QALS and JEST.
QALS: Inspection lot record
JEST: Individual Object Status
Example of how this entry gets created in table MDQM: An inspection lot with status SPRQ is created.
Logic of the flag: If flag is set, the system attempts to read inspection lots from table MDQM. Field INSMK must be set for the inspection lot to be selected.
An example in CO09:
- There is unrestricted stock = 7. There are 4 inspection lots in MDQM for the material. These amount to 13 (See figure 6).
Figure 6: Inspection lots for a material existing in view MDQM
- When the flag is set, the system will select the inspection lots and consider them as receipts in CO09 (See figure 7)
Figure 7: Flag is set so inspection lots are displayed and there is an available quantity of 20 (7 + 10 + 1 + 1 + 1)
- When the flag is not set, the system will not select the inspection lots and they are not considered in CO09 (See figure 😎
Figure 8: Flag not set so inspection lots not displayed and available quantity of 7.
Code that implements this logic:
| Include LATP2FM7 / FORM MDQM_READ: |
|---|
SELECT * FROM MDQM WHERE MATNR = ATPMAT-MATNR AND WERKVORG = ATPMAT-WERKS AND SOBKZ IN (SPACE, SOBKZK) AND INSMK = CHARX AND ( KNTTP = SPACE OR STAT35 = SPACE ) AND PAENDTERM < ATPMAT-ENDWZ. CLEAR MDQM-SOBKZ. |
Table 5: Select on table MDQM
| Include LATP2FM6 / Form MDQM_CHECK: |
|---|
* quantity S_ATPK-MNG01 = MDQM-LMENGEZUB. |
Table 6: Quantity of MDQM-LMENGEZUB passed to the ATP structure
| Include LATP2TM0 / HIERARCHY_FILL: |
|---|
| COLLECT S_ATPK INTO G_ATPKXR. |
Table 7: Collects the ATP data into the Receipts structure
4) Incl. blocked Stock:
Table it reads from: MARD (Storage Location Data for Material), fields SPEME & KSPEM
Example of how this entry gets created in table MARD: Can occur by creating a goods receipt in MIGO of stock type “Blocked” (See figure 9)
Figure 9: Stock type of “Blocked Stock” in MIGO
Figure 10: Field SPEME in table MARD
Logic of the flag: If this flag is on, then fields MARD-SPEME (Blocked Stock) + MARD-KSPEM (Blocked Consignment Stock) are added to the available stock
An example in CO09: There is unrestricted stock of 10 with no receipts or requirements. The blocked stock is 5.
Flag turned on: Available stock = 15. (10 + 5)
Flag turned off: Available stock = 10. (10)
Code that implements this logic:
| Include LATP2FM3 / Form MARD_CHECK |
|---|
* include blocked stock (inclusive conseignment stock) IF G_T441V-SBSTP = XFLAG. S_ATPK-MNG01 = S_ATPK-MNG01 + MARD-SPEME + MARD-KSPEM. ENDIF. |
Table 8: Blocked stock (MARD-SPEME) added to the available stock
5) Incl. restricted-use Stock:
Table it reads from: MCHB (Batch Stocks)
Example of how this entry gets created in table MCHB: Stock is created for batch managed material (e.g. through MIGO). The “Batch Restricted” flag can be set in transaction MSC2n (See figure 11)
Figure 11: Batch restricted flag in MSC3n
Logic of the flag: Flag only relevant for batch stocks. SELECT on table MCHB to get the relevant batch stocks. If the flag is set, the system will add the value of the restricted use stock (MARC-CEINM) to the available stock.
An example in CO09:
A batch has been set to “Restricted Use”.
Flag turned on: The batch will appear in CO09, the quantity of the batch will be displayed and added to the available quantity.
Flag turned off: The batch will appear in CO09, the quantity of the batch will be displayed as 0. The batch stock is not added to the available stock.
Code that implements this logic:
| Function VB_READ_BATCH: |
|---|
SELECT * FROM mchb INTO TABLE xv_mchb_dummy FOR ALL ENTRIES IN s0_mchb WHERE matnr EQ s0_mchb-matnr AND werks EQ s0_mchb-werks. |
Table 9: Selects the batch data from table MCHB
| Include LATP2FM5 / Form MCHB_READ: |
|---|
* include restricted use stock IF g_t441v-nfvbc = xflag. s_atpk-mng01 = s_atpk-mng01 + s_mchbx-ceinm. ENDIF. |
Table 10: Loop through s_mchbx (contains the batches) and add blocked stock (ceinm) to the available quantity
6) W/o subcontracting:
I)
Table it reads from: MSSL (Total Special Stocks with Vendor)
Example of how this entry gets created in table MSSL: Posting a 541 movement via MB1B can post stock into the MSSL table
Logic of the flag: If the flag is set, the system will not read table MSSL. If the flag is not set, the system will read table MSSL. When the flag is not set, The field “Unrestricted” (SLLAB) is added to the available quantity. Fields “In Qual. Insp.” (SLINS), & “Restricted-Use” (SLEIN) are added to the available quantity if the relevant flags are selected in the scope of check.
An example in CO09:
- There is 4172 (4067 + 105) in unrestricted stock in table MARD (See figure 12)
Figure 12: Unrestricted stock in MARD
- There is an entry in MSSL where unrestricted stock = 195 (See figure 13)
Figure 13: Unrestricted stock in MSSL
The “W/o subcontracting” flag is set: Available Stock = 4172 (4172)
The “W/o subcontracting” flag is not set: Available Stock = 4367 (4172 + 195)
Code that implements this logic:
| Include LATP2FMH / FORM MSSL_READ: |
|---|
* include subcontracting IF G_T441V-OLBPR = XFLAG AND CM61B-BERTY <> K_LOHNB. EXIT. ENDIF. |
Table 11: EXIT before the select if MSSL the flag is = “X”
| Include LATP2FMH / FORM MSSL_READ: |
|---|
SELECT LIFNR SLLAB SLINS SLEIN FROM MSSL INTO (MSSL-LIFNR, MSSL-SLLAB, MSSL-SLINS, MSSL-SLEIN) WHERE MATNR = ATPMAT-MATNR AND WERKS = ATPMAT-WERKS AND SOBKZ = SOBKZO. |
Table 12: SELECT on table MSSL
| Include LATP2FMH / FORM MSSL_READ: |
|---|
* valuated stock with unrestricted use P_ATPK-MNG01 = P_ATPK-MNG01 + MSSL-SLLAB. * include stock in quality inspection IF G_T441V-QMBSP = XFLAG. P_ATPK-MNG01 = P_ATPK-MNG01 + MSSL-SLINS. ENDIF. * include restricted use stock IF G_T441V-NFVBC = XFLAG. P_ATPK-MNG01 = P_ATPK-MNG01 + MSSL-SLEIN. ENDIF. |
Table 13: Values from MSSL added to the available stock
ii)
Table it reads from: RESB (Reservation/dependent requirements)
Example of how this entry gets created in table RESB: A subcontract order is created in ME21n with components. This creates an entry in table RESB where BDART = "BB".
Logic of the flag: When the flag is set, the system will not display the subcontracting requirements. When the flag is not set, the system will display the subcontracting element in CO09.
An example in CO09:
- A subcontract order exists with a subcontracting component
Flag turned on: Subcontracting element from RESB not displayed
Flag turned off: Subcontracting element from RESB displayed
Code that implements this logic:
| SAPLM61Q / FORM CHECK_NEW_KOMPONENTE |
|---|
*--> Daten in Tabelle MDPMX uebernehmen MOVE-CORRESPONDING MDPM TO MDPMX. MOVE SKBED TO MDPMX-BDART. IF MDPA-SOBKZ EQ BESKZF OR MDPA-BESKZ EQ BESKZF. MOVE BRBED TO MDPMX-BDART. MOVE MDPA-FLIEF TO MDPMX-LIFNR. ENDIF. |
Table 14: When component added to subcontract order, constant BRBED passed to MDPMX-BDART (Later stored in RESB)
| LATP2TMR / DEFINE resb_t441v_check |
|---|
* check T441V if atpgd-anwdg <> c_appl_forcast and g_t441v-resbp <> xflag " material reservation and g_t441v-skbdp <> xflag " dependent requirements and g_t441v-olbpr = xflag " without subcontracting and g_t441v-arrep <> xflag " all dependent reservations and g_t441v-arrep <> chara. " dep. reservations that can be " withdrawn exit. endif. |
Table 15: If OLBPR set, the system may exit before the SELECT (depending on other flags)
| Include LATP2FR1 / FORM RESB_DB_READ |
|---|
SELECT * FROM atp_resb INTO TABLE lt_atpresb WHERE matnr = atpmat-matnr AND werks = atpmat-werks AND xloek = space AND kzear = space AND sobkz IN (space, sobkzk) AND bdmng > atp_resb~enmng AND txtps = space AND schgt = space AND dbskz = space AND ( vorab IS NULL OR vorab = space ). |
Table 16: Select on RESB structure
____________________________________________________________________________________________________________________________
Part 2: In / Outward Movements
6) Incl. Purchase Orders:
Table it reads from: EKET (Scheduling Agreement Schedule Lines)
EKKO (Purchasing Document Header) - When the flag is set to "A".
Example of how this entry gets created in table EKET: Purchase document can be created via transaction ME21n.
Logic of the flag: System selects from table EKET. If the flag is set to “X”, the purchase order will appear in CO09 and the quantity is added to the available quantity. The quantity of the PO may be adjusted depending on what has already been delivered / receipted.
An example in CO09:
i) Flag set to “X”:
Example 1: There is stock = 10 on your system. There is a Purchase Order with a quantity of 5 that has not yet been delivered or goods posted. Available quantity is 10 + 5 = 15 on the date of the PO.
Example 2: There is stock = 10 on your system. There is a Purchase Order with a quantity of 5, of which 3 have been delivered. The Purchase order quantity will be reduced to 2 in CO09 while the 3 already delivered will be displayed as a shipping notification.
Example 3: There is stock = 10 on your system. There is a Purchase Order with a quantity of 5, of which 3 have been goods receipted. The consequence is that CO09 will display 10 + 3 (13) as stock and 2 as the quantity of the purchase order. Overall available quantity is 15 on the date of the PO.
Code that implements this logic:
| Include LATP2TME: DEFINE ekes_t441v_check. |
|---|
* check T441V if g_t441v-lavip <> xflag " shipping notification for " purchase orders and scheduling " agreements and g_t441v-bestp <> xflag " purchase order and " scheduling agreement and g_t441v-bestp <> 'A'. "1579745 exit. endif. END-OF-DEFINITION. |
Table 17: Macro that checks if the flag is set
| Include LATP2FE3 / Form EKET_DB_READ: |
|---|
SELECT * FROM atp_eket INTO TABLE lt_atp_eket WHERE matnr = atpmat-matnr AND werks = atpmat-werks AND bstyp IN (bstypf, bstypl) AND ( loekz = space OR loekz = chars ) AND elikz = space AND stapo = space AND pstyp <> pstyps |
Table 18: Selects the data from EKET (ensuring it does not select a deleted PO etc.)
| Include LATP2TME: Macro eket_check: |
|---|
if p_atpmex-delkz = retpo and atp_eket-glmng >= atp_eket-wemng. p_atpmex-mng01 = atp_eket-menge - atp_eket-glmng. else. if atp_eket-wemng > atp_eket-dabmg. p_atpmex-mng01 = atp_eket-menge - atp_eket-wemng. else. p_atpmex-mng01 = atp_eket-menge - atp_eket-dabmg. endif. endif. |
Table 19: Calculates the quantity of the PO item in CO09 by subtracting the already delivered / MRP reduced quantity etc. from the quantity of the PO.
ii) Flag set to “A”:
This means that the system will also consider the confirmed schedule lines of an STO. See SAP note 1579745
Code that implements this logic:
| Include LATP2FE8 / Form EKET_DB_READ_CONF: |
|---|
*---(2)next step: Select EKKO IF NOT lt_sel_ekko IS INITIAL. SELECT ebeln FROM ekko INTO TABLE lt_res_ekko FOR ALL ENTRIES IN lt_sel_ekko WHERE ebeln = lt_sel_ekko-ebeln AND reswk <> ' '. ENDIF. |
Table 20: Select from EKKO will only succeed when there is a value in RESWK (Supplying Plant in STO)
| Class CL_MMPUR_SCHED_STO / Method BUILD_ATP_EKET_CONF |
|---|
Table 21: Calculation of the confirmed quantity
7) Incl. Purchase Requisitions:
Table it reads from: EBAN (Purchase Requisition)
Example of how this entry gets created in table EBAN: Purchase Requisition can be created via ME51n.
Logic of the flag: If the flag is not blank, then the system will execute a Select on table EBAN for the material / plant combination.
An example in CO09:
- There is unrestricted stock of 10. There is a purchase requisition = 5.
Flag turned on: Available stock (on date of purchase requisition) = 15
Flag turned off: Available stock = 10. (Purchase Requisition not considered)
Code that implements this logic:
| Include LATP2TME: Macro eban_t441v_check: |
|---|
* check T441V if g_t441v-banfp <> xflag. " purchase requisition exit. endif. |
Table 22: Check to see if the flag is set. If not equal to X, then system does not proceed to the SELECT.
| Include LATP2FE0 / Form EBAN_DB_READ: |
|---|
SELECT * INTO TABLE lt_atpeban FROM ATP_EBAN WHERE MATNR = ATPMAT-MATNR AND WERKS = ATPMAT-WERKS AND LOEKZ = SPACE AND EBAKZ = SPACE AND BSAKZ = BATYPN AND PSTYP <> PSTYPS AND SOBKZ IN R_SOBKZ. |
Table 23: Select on the EBAN structure; ensures that a deleted purchase req is not selected etc.
😎 Incl. dependent reqs:
Table it reads from: RESB (Reservation/dependent requirements)
Example of how this entry gets created in table RESB: A planned order with a component is created (for example in MD11). The reservation of the component will have a requirements type (BDART) = “SB”.
Logic of the flag: If flag is set, the system will execute a select on RESB. These data selected from RESB will be considered requirements in the calculation of the available quantity.
An example in CO09:
- Available Stock = 100. A planned order is created with a component required quantity = 4. The component required quantity is confirmed.
Flag turned on: Available Quantity is 96 (100 - 4)
Flag turned off: Available Quantity is 100 (100)
Code that implements this logic:
| LATP2TMR / DEFINE resb_t441v_check |
|---|
* check T441V if atpgd-anwdg <> c_appl_forcast and g_t441v-resbp <> xflag " material reservation and g_t441v-skbdp <> xflag " dependent requirements <<<<<<< and g_t441v-olbpr = xflag " without subcontracting and g_t441v-arrep <> xflag " all dependent reservations and g_t441v-arrep <> chara. " dep. reservations that can be " withdrawn exit. endif. END-OF-DEFINITION. |
Table 24: Macro to check if RESB flag is set
| Include LATP2FR1 / Form RESB_DB_READ: |
|---|
SELECT * FROM atp_resb INTO TABLE lt_atpresb WHERE matnr = atpmat-matnr AND werks = atpmat-werks AND xloek = space AND kzear = space AND bdter < atpmat-endwz AND sobkz IN (space, sobkzk) AND bdmng > atp_resb~enmng AND txtps = space AND schgt = space AND dbskz = space AND ( vorab IS NULL OR vorab = space ). |
Table 25: Select that will select the data from RESB. Note how the select does not have SKBED as a selection criteria. Data Object SKBED contains a constant value of "SB". This means it will select entries where BDART = SB. This is what distinguishes the select from the other RESB selects
9) Include reservations:
Table it reads from: MDUR (Reading View of Stock Transfer Reservations); This is a view of database tables REUL & RESB.
REUL: Material stock transfer reservation index
RESB: Reservation/dependent requirements
Example of how this entry gets created in table MDUR: Could get created by manually creating a reservation (mvt type 301) in transaction MB21.
Logic of the flag: If flag is set, then the system attempts to select data from the MDUR view. There is a check to ensure that the requirement quantity is less than or equal to the withdrawn quantity. If this check fails, the element is not displayed in CO09.
An example in CO09:
- A reservation of movement type 301 is created in MB21. This goods movement is going to move a quantity of 1 from plant 0002 to plant 0001 (See figure 14):
Figure 14: Reservation created in MB21.
If the flag is set in CO09, then it should have the impact of adding a quantity of 1 to the available quantity in plant 0001 while subtracting a quantity of 1 from the available quantity in plant 0002.
Consider this example: There is available stock of 7 in plant 0001 displayed in CO09 before the above goods movement is posted. After the above goods movement is posted, an entry is created in table REUL. This is read by CO09 and an available quantity of 8 is displayed (See figure 15):
Figure 15: You can see the element “StTRes” is displayed and added to available quantity
There were 85 in stock for the material in plant 0002 before the goods movement was posted. After the goods movement was posted, this will be reduced to 84 (See figure 16):
Figure 16: You can see the element “MtlRes” is displayed and subtracted from available quantity
Note: This “MtlRes” element is read from RESB and not MDUR.
Code that implements this logic:
| Include LATP2FR4 / Form REUL_RESB_READ: |
|---|
* check T441V IF G_T441V-RESBP <> XFLAG. " material reservation EXIT. ENDIF. |
Table 26: Code that checks if the flag is set. System will exit before select if flag not set
| Include LATP2FR4 / Form REUL_RESB_READ: |
|---|
* read REUL/RESB from database SELECT * FROM MDUR INTO MDUR WHERE MATNR EQ ATPMAT-MATNR AND UMWRK EQ ATPMAT-WERKS AND XLOEK EQ SPACE AND KZEAR EQ SPACE AND BDTER LT ATPMAT-ENDWZ. |
Table 27: Code that selects from MDUR view
| Include LATP2FR3 / Form REUL_RESB_CHECK: |
|---|
* quantities |
Table 28: Code that calculates the available quantity.
10) Include sales reqmts:
Table it reads from: VBBE / VBBS
VBBE: Sales Requirements: Individual Records
VBBS: Sales Requirement Totals Record
Example of how this entry gets created in table VBBE / VBBS: When sales order is created (and requirements switched on in customising OVZG / VOV6 etc.), an entry will be created in the requirements table for the sales order.
Logic of the flag: If flag is set, the system will try to select data from VBBE or VBBS. VBBE is used if the “TotalSales” field in customising transaction
OVZ2 = A. VBBS is used if the “TotalSales” field in customising transaction OVZ2 contains a value that does not equal A.
An example in CO09:
- There is unrestricted stock of 10. There is a sales order with a required quantity = 5.
Flag turned on: Available Quantity = 5
Flag turned off: Available Quantity = 10.
Code that implements this logic:
| Include LATP2FV6: Macro VBBE_T441V_CHECK: |
|---|
* check T441V IF G_T441V-VBBDP <> XFLAG " sales requirements AND G_T441V-VBBLP <> XFLAG. " delivery notes EXIT. ENDIF. |
Table 29: Macro to ensure flag is set. If not set, then system will exit
| Include LATP2FV0 / Form VBBE_DB_READ: |
|---|
SELECT BERID LGORT CHARG VBTYP MBDAT SUM( OMENG ) SUM( VMENG ) FROM ATP_VBBE INTO (ATP_VBBE-BERID, ATP_VBBE-LGORT, ATP_VBBE-CHARG, ATP_VBBE-VBTYP, ATP_VBBE-MBDAT, ATP_VBBE-OMENG, ATP_VBBE-VMENG) WHERE MATNR = ATPMAT-MATNR AND WERKS = ATPMAT-WERKS AND SOBKZ in (SPACE, sobkzk) AND MBDAT < ATPMAT-ENDWZ |
Table 30: Select on the VBBE view
11) Include deliveries:
Table it reads from: VBBE / VBBS
VBBE: Sales Requirements: Individual Records
VBBS: Sales Requirement Totals Record
Example of how this entry gets created in table VBBE / VBBS: A sales document is created. This creates a sales requirement in VBBE. An outbound delivery is created; this should over-write the preceding VBBE entry (i.e. system will create a new VBBE where VBTYP = “J” and delete the VBBE entry where VBTYP = “C”)
Logic of the flag: Select on table VBBE or VBBS depending on OVZ2 customising.
An example in CO09:
- There is unrestricted stock = 10. A Sales order is created with a required quantity = 10. The sales order is fully delivered via VL01n.
Flag is set: Available quantity = 0 (10 in stock – quantity of 10 in deliveries)
Flag is not set: Available Quantity = 10 (10 in stock but deliveries not considered)
Code that implements this logic:
| Include LATP2FV6: Macro VBBE_T441V_CHECK: |
|---|
* check T441V IF G_T441V-VBBDP <> XFLAG " sales requirements AND G_T441V-VBBLP <> XFLAG. " delivery notes EXIT. ENDIF. |
Table 31: Macro to ensure flag is set. If not set, then system will exit
| Include LATP2FV0 / Form VBBE_DB_READ: |
|---|
SELECT BERID LGORT CHARG VBTYP MBDAT SUM( OMENG ) SUM( VMENG ) FROM ATP_VBBE INTO (ATP_VBBE-BERID, ATP_VBBE-LGORT, ATP_VBBE-CHARG, ATP_VBBE-VBTYP, ATP_VBBE-MBDAT, ATP_VBBE-OMENG, ATP_VBBE-VMENG) WHERE MATNR = ATPMAT-MATNR AND WERKS = ATPMAT-WERKS AND SOBKZ in (SPACE, sobkzk) AND MBDAT < ATPMAT-ENDWZ |
Table 32: Select on the VBBE view
Tip: If you want to debug into the read / select of VBBE, then you can manually set the data object debug_macro via the debugger. This data object can be found in function STOCK_RECEIPT_ISSUE_READ (See figure 17). This allows you to debug into the abap version of form vbbe_read rather than the macro being executed.
Figure 17: Setting “debug_macro” to “X” will allow you to debug into form VBBE_READ_ABAP
12) Incl. ship. notificat:
Table it reads from: EKES (Vendor Confirmations)
Example of how this entry gets created in table EKES: EKES record is created when an inbound delivery is created from a purchase document.
Logic of the flag: The “Incl. Purchase Orders” also has an influence on shipping notifications. If the “Incl. Purchase Orders” flag is set but the “Incl. ship.notificat.” flag is not set, then the system still attempts to select the data from EKES.
System calculates the available quantity of the shipping notification by subtracting the “MRP Reduced Quantity” from the total quantity.
An example in CO09:
- There is stock = 10. There is an inbound delivery with a quantity = 5. A goods receipt is posted for this inbound delivery in MIGO for a quantity = 3
Flag turned on: Shipping notification appears in CO09. The available stock will be 15 on the date of the shipping notification (10 + 3 + (5-3)). Shipping Notification quantity will be 2: Quantity of 5 – GR of 3 = 2.
Flag turned off: Shipping notification is not displayed in CO09. Available quantity = 10.
Code that implements this logic:
| Include LATP2TME: Macro: ekes_t441v_check: |
|---|
DEFINE ekes_t441v_check. * check T441V if g_t441v-lavip <> xflag " shipping notification for " purchase orders and scheduling " agreements and g_t441v-bestp <> xflag " purchase order and " scheduling agreement and g_t441v-bestp <> 'A'. "1579745 exit. endif. END-OF-DEFINITION |
Table 33: Checks if the flag is selected in OVZ9; note that the purchase order flag must also be set
| Include LATP2FE2: |
|---|
SELECT * FROM atp_ekes WHERE matnr = atpmat-matnr AND werks = atpmat-werks AND bstyp IN (bstypf, bstypl) AND ( loekz = space OR loekz = chars ) AND elikz = space AND kzdis = xflag AND pstyp <> pstyps AND dabmg < atp_ekes~menge AND sobkz IN r_sobkz AND estkz NE '4'. |
Table 34: Select on EKES
| Include LATP2TME: Macro ekes_check: |
|---|
| p_atpmex-mng01 = atp_ekes-menge - atp_ekes-dabmg. |
Table 35: Calculate the available quantity of the shipping notification
| Include LATP2TM0:Macro ATPMEX_CHECK_INT: |
|---|
| S_ATPK-MNG01 = P_ATPMEX-MNG01. |
Table 36: Pass the available quantity of the shipping notification to the ATP structure
13) Incl. depen.reservat:
Table it reads from: RESB (Reservation/dependent requirements)
Example of how this entry gets created in table RESB: A work order is created (for example a production order) that contains a component as part of a BOM. This is a requirement of the material in the order and an entry gets created in RESB.
Logic of the flag: When the flag is set, the system considers the dependent reservations of work orders in the calculation of the available quantity.
An example in CO09: The following example shows a quantity of 102 available for a component material (See figure 18)
Figure 18: 102 in stock
i) If the flag is set to “X”, this means that the reservation is displayed in CO09 and there will be 101 (102 – 1) available (See figure 19).
Figure 19: Reservation included so taken into account when calculating available quantity
Code that implements this logic:
| Include LATP2TMR: Macro resb_t441v_check: |
|---|
if atpgd-anwdg <> c_appl_forcast and g_t441v-resbp <> xflag " material reservation and g_t441v-skbdp <> xflag " dependent requirements and g_t441v-olbpr = xflag " without subcontracting and g_t441v-arrep <> xflag " all dependent reservations and g_t441v-arrep <> chara. " dep. reservations that can be " withdrawn exit. endif. |
Table 37: Macro that contains the code to exit if the flag is not set (to X or A)
| Include LATP2FR1: |
|---|
SELECT * FROM atp_resb INTO TABLE lt_atpresb WHERE matnr = atpmat-matnr AND werks = atpmat-werks AND xloek = space AND kzear = space AND bdter < atpmat-endwz AND bdart <> skbed AND sobkz IN (space, sobkzk) AND bdmng > atp_resb~enmng AND txtps = space AND schgt = space AND dbskz = space AND ( vorab IS NULL OR vorab = space ). |
Table 38: Selects the relevant entries from the RESB table (this select ensures that system does not select deleted reservations, or reservations that have been finally issued etc.)
ii) When the flag is set to “A”, the element is displayed in CO09 if the RESB-XWAOK (Goods Movement for Reservation Allowed) field is set.
Consider the following example:
- Available stock is 102. A production order is created with the component material for a quantity of 1. Initially, this component requirement is not appearing in CO09 (See figure 20):
Figure 20: Flag is set to “A” but reservation not appearing.
- The reason that it is not appearing is that RESB-XWAOK is not set. You can see this in the component details of the component overview in
the production order (figure 21):
Figure 21: “Movement Allowed” (RESB-XWAOK) is initial
- However, after you release the order, the RESB-XWAOK flag can get set (See figure 22):
Figure 22: “Movement Allowed” (RESB-XWAOK) is flagged
- Now, CO09 can display the “withdrawable” material (figure 23):
Figure 23: Flag is set to “A” so the reservation appears in CO09 only after RESB-XWAOK is set
Code that implements this logic:
| Include LATP2FR0 / Form resb_arbed_mrbed_check |
|---|
p_atpmex-sobkz = p_atp_resb-sobkz. p_atpmex-lgort = p_atp_resb-lgort. p_atpmex-charg = p_atp_resb-charg. p_atpmex-delkz = p_atp_resb-bdart. p_atpmex-atpif(1) = p_atp_resb-xwaok. <<<<<<<<<<<<<< p_atpmex-atpif+2(1) = p_atp_resb-dumps. |
Table 39: Passing the “Movement allowed” indicator to the ATPMEX internal table.
| Include LATP2TMR: Macro resb_delkz_atpif_check: |
|---|
* evaluation of T441V case &1. when arbed. if g_t441v-arrep is initial " without any order reservations or ( g_t441v-arrep = chara and &2(1) is initial ). continue. endif. |
Table 40: Macro that checks if the “Incl.depen.reservat” = ‘A’ in the scope of check
14) Incl.rel.order reqs:
Table it reads from: EKUB/EKPO/EKET; these are combined into a view called ATP_EKUB in SE11.
EKUB: Index for Stock Transport Orders for Material
EKPO: Purchasing Document Item
EKET: Scheduling Agreement Schedule Lines
Example of how this entry gets created in table ATP_EKUB: A Stock transfer order (document type UB) can be created via ME21n.
Logic of the flag: If flag is not blank, system will execute a Select on view ATP_EKUB and attempts to display any selected entries in CO09.
An example in CO09:
- The system calculates the quantity by considering if the STO has been delivered or goods issued.
Example 1: There is stock = 10. There is an STO with a quantity = 5. This is a requirement of 5 so the available quantity = 5 (10 - 5).
Example 2: There is stock = 10. There is an STO with a quantity = 5. A replenishment delivery has been created for the STO with a quantity = 2. Available quantity = 10 – (5-2) = 7. Note: If your scope of check included deliveries, then available quantity would be 10 – 3 (requirement of STO) – 2 (requirement of delivery) = 5
Code that implements this logic:
| Include LATP2TME: Macro ekub_t441v_check: |
|---|
DEFINE ekub_t441v_check. * check T441V if g_t441v-tbbep <> xflag " purchase order / requisition and g_t441v-tbbep <> chara. " purchase order exit. endif. END-OF-DEFINITION. |
Table 41: Table: Code that will ensure exit before doing the SELECT if the flag is not set
| Include LATP2FE4 / Form EKUB_DB_READ: |
|---|
* read EKUB/EKPO/EKET from database into internal table SELECT * FROM atp_ekub INTO TABLE lt_atp_ekub WHERE matnr = atpmat-matnr AND reswk = atpmat-werks AND reslo IN lt_mdlg "empty if no SSLOC AND bstyp IN (bstypf, bstypl) AND ( loekz = space OR loekz = chars ) "immer auch auf S pruefen??? AND elikz = space AND stapo = space AND umsok = atpga-sobkz AND uptyp <> 3 * also consider confirmed schedule lines with MENGE = 0 "WP127444 * MNG02 = MENGE if ATP is switched off AND ( menge > atp_ekub~wamng or mng02 > atp_ekub~wamng ) AND ( menge > atp_ekub~glmng or mng02 > atp_ekub~glmng ). |
Table 42: Code which ensures that only STO’s that have not been deleted / fully delivered/ fully goods issued etc. are to be selected.
| Include LATP2FE4 / Form ekub_check: |
|---|
* quantities IF atp_ekub-wamng > atp_ekub-glmng. p_atpmex-mng01 = atp_ekub-menge - atp_ekub-wamng. p_atpmex-mng02 = atp_ekub-mng02 - atp_ekub-wamng. ELSE. p_atpmex-mng01 = atp_ekub-menge - atp_ekub-glmng. p_atpmex-mng02 = atp_ekub-mng02 - atp_ekub-glmng. ENDIF. |
Table 43: System calculates the quantity based on the GI quantity or the delivered quantity.
15) Incl. planned orders:
Table it reads from: PLAF (Planned order)
Example of how this entry gets created in table PLAF: MRP run could create a planned order. Transaction MD11 is another possibility.
Logic of the flag: If the flag is not blank, then the system will execute a Select on table PLAF for the material / plant combination. System loops through the selected planned orders. The flag allows you to limit the considered planned orders to firmed planned orders (firming flag in MD12) or to limit to planned orders that contain only fully confirmed components.
An example in CO09:
- There is stock = 10. There is a planned order = 5.
Flag = “X” (Check all planned orders) : Available stock = 10 + 5 (15) on the date of the planned order (See Figure 24):
Figure 24: Planned Order quantity of 5 added to stock making available stock = 15
Flag = “ “: Available stock = 10 (the planned order is not added to the available stock)
Flag = “A”: Available Stock = 15 on date of planned order only if firming indicator set in planned order (See
figure 25)
Figure 25: Firming Indicator is set
Flag = “B”: Available Stock = 15 on date of planned order only if components of the planned order are confirmed (See figure 26):
Figure 26: Component for the planned order is not available (Confirmed Quantity = 0). Therefore, planned order is not completely confirmed and will not be selected in CO09. If the component was confirmed, then the system would select the planned order.
Code that implements this logic:
| Include LATP2FP2 / Form PLAF_READ: |
|---|
* check T441V IF G_T441V-PLAFP <> XFLAG " all planned orders AND G_T441V-PLAFP <> CHARA " only firmed planned orders AND G_T441V-PLAFP <> CHARB. " only completely confirmed po's EXIT. ENDIF. |
Table 44: Code to ensure flag is set. If not set, exit before system selects from PLAF
| Include LATP2FP2 / Form PLAF_READ: |
|---|
* read PLAF from database into internal table depending on SOBKZ CASE ATPGA-SOBKZ. WHEN SPACE. SELECT * FROM ATP_PLAF INTO TABLE S_ATP_PLAF WHERE MATNR = ATPMAT-MATNR AND PLWRK = ATPMAT-WERKS AND SOBKZ = ATPGA-SOBKZ AND PSTTR < ATPMAT-ENDWZ. |
Table 45: Select on the PLAF view
| Include LATP2FP0 / Form PLAF_CHECK: |
|---|
* accumulate P_PLAF CASE G_T441V-PLAFP. * all planned orders WHEN XFLAG. LOOP AT P_ATP_PLAF. PERFORM PLAF_EVALUATE USING P_ATP_PLAF. ENDLOOP. * only firmed planned orders WHEN CHARA. LOOP AT P_ATP_PLAF WHERE AUFFX = XFLAG. PERFORM PLAF_EVALUATE USING P_ATP_PLAF. ENDLOOP. * only planned orders that are completely confirmed WHEN CHARB. LOOP AT P_ATP_PLAF WHERE MDPBV = CHAR3. PERFORM PLAF_EVALUATE USING P_ATP_PLAF. ENDLOOP. |
Table 46: Code that distinguishes between X, A & B values of the flag. Note how when "A", flag PLAF-AUFFX is evaluated while when "B", flag PLAF-MDPBV is evaluated.
16) Incl. production orders:
Table it reads from: AFPO (Order Item)
Example of how this entry gets created in table AFPO: Creation of production order creates an entry in table AFPO. CO01 & CO40 are some of the possible transactions to create a production order.
Logic of the flag: If the flag is not blank, then the system will execute a select on table AFPO for the material / plant combination. The system will loop through the selected entries. If the flag has been set to consider only released production orders, the system eliminates the unreleased production orders in the loop by checking field STATF in the AFPO view (DFREI field in AFPO table).
An example in CO09:
Example 1:
- There is stock = 10. There is a released production order with a quantity of 5. There is an unreleased production order with a quantity of 5.
- The flag is set to "X" (Take all production orders into account)
Flag turned on: Available stock = 20 (10 + 5 + 5)
Flag turned off: Available stock = 10 (15)
Example 2:
- There is stock = 10. There is a released production order with a quantity of 5. There is an unreleased production order with a quantity of 5.
- The flag is set to "F" (Only take released production orders into account)
Flag turned on: Available stock = 15 (10 + 5)
Flag turned off: Available stock = 10 (10)
Code that implements this logic:
| Include LATP2FA1 / Form AFPO_READ: |
|---|
* check T441V IF G_T441V-FERTP <> XFLAG " all production orders AND G_T441V-FERTP <> CHARF. " only released produktion orders EXIT. ENDIF. |
Table 47: Code to check if flag is set. If not set, exit before the select on AFPO is executed
| Include LATP2FA1 / Form AFPO_READ: |
|---|
SELECT * FROM ATP_AFPO INTO TABLE S_ATP_AFPO WHERE MATNR = ATPMAT-MATNR AND PLWRK = ATPMAT-WERKS AND SOBKZ = ATPGA-SOBKZ AND ELIKZ = SPACE AND DNREL = SPACE AND WEPOS = XFLAG "note 496693 AND AFTYP <> AFTYPC AND AFTYP <> AFTYPP AND AFTYP <> AFTYPQ. |
Table 48: Select on the AFPO view to get the relevant production orders for this material / plant
| Include LATP2FA0 / Form AFPO_CHECK: |
|---|
LOOP AT P_ATP_AFPO. * only released production orders |
Table 49: Eliminates unreleased production orders by executing the loop with continue if the indicator is set to “F”.
____________________________________________________________________________________________________________________________
Part 3: Other Scope of Check Flags
Note: the flags in this part do not refer to specific elements. They are used to influence the logic of availability check rather than being used to include / exclude specific elements.
17) Check without RLT:
Table it reads from: MARC (Plant Data for Material)
Example of how this entry gets created in table MARC: In the MRP 2 tab of the material master, you have the "In-house production" (DZEIT), "GR Processing" (WEBAZ) and "Planned Delivery Time" (PLIFZ) fields. In the MRP 3 tab of the material master, you have the "Tot. repl. lead time" (WZEIT). The values maintained in these fields are used to calculate the end lead time.
Logic of the flag: If you turn the flag on, the system does not consider the end lead time. When the flag is turned on, the end lead time is considered; this means that your material is available on and after this date regardless of your available quantity.
An example in CO09:
- There is no stock (See figure 27).
Figure 27: There is no stock
In the material master, the "Tot. repl. lead time" has been set to 5 days (See figure 28):
Figure 28: "Tot. repl. lead time" maintained in the material master.
- At the time of writing this document, today's date is 7th November. The system calculates an end lead date by adding 5 days to todays date = 14th November (it is calculated according to your plant calendar so you need to consider non-working days maintained in plant calendar). This is displayed in CO09 (See figure 29):
Figure 29: End lead time appears in CO09.
With regard to the above settings, consider these two examples:
1) A sales order is created with a requirement date = 12th November.
Flag turned on: The system will not confirm the requirement (as there is no receipt or stock to confirm against).
Flag turned off: The system will not confirm the requirement for 12th November. It will propose a confirmation on the 14th November instead.
2) A sales order is created with a requirement date = 17th November.
Flag turned on: The system will not confirm the requirement (as there is no receipt or stock to confirm against).
Flag turned off: The system will confirm the requirement for 17th November. 17th November is after the end lead date of 14th November so the requirement is confirmed against the end lead date.
Code that implements this logic:
| Include LATPCFE0 / Form END_OF_RLT_CALCULATE |
|---|
* determine RLT MODIFY P_ATPMATX. |
Table 50: Code that determines the end lead date. It always uses the plant calendar ( P_ATPPLANTX-FABKL) to determine the end lead date.
18) No storage location inspection:
Logic of the flag: The availability check is executed at multiple levels; plant and storage location levels. When you turn on this flag, the system will only check at plant level.
An example in CO09:
Consider the following example:
Plant Stock = 12. Storage Location stock in 0001 = 7. Storage Location stock in 0002 = 5. (See figure 30)
Figure 30: Plant stock of 12
- A sales order is created with a requirement quantity of 12 in storage location 0001.
Flag turned on: The requirement of 12 will be confirmed.
Flag turned off: The requirement of 12 will not be confirmed, only 7 can be confirmed.
Code that implements this logic:
| Include LATP0FA1 / FORM ATP_CHECK: |
|---|
* set sloc IF NOT g_t441vx-olgpr IS INITIAL AND g_atpgd-anwdg <> c_appl_batch_det. READ TABLE p_lortx WITH KEY lgort = g_atpga-lgort BINARY SEARCH. IF sy-subrc <> 0. CLEAR: g_atpga-lgort. <<<<<<<<<<<<<<<<<<<<<< ELSEIF p_lortx-diskz IS INITIAL. CLEAR: g_atpga-lgort. <<<<<<<<<<<<<<<<<<<<<< ENDIF. |
Table 51: Code that clears the storage location field (g_atpga-lgort). When this field is cleared, ATP check is not executed in the storage location segment.
16) Receipts in Past:
Logic of the flag: Flag that allows you to specify whether CO09 should consider past receipts in calculating the available quantity.
An example in CO09:
Stock is 10. A production order with a finish date = 30 days in the past exists with a quantity of 5.
Option that includes past receipts turned on: Available Quantity = 20 (Stock of 10 + quantity of production order)
Option that does not include receipts from the past turned on: Available Quantity = 10 (The receipt from the past is not considered)
Code that implements this logic:
| SAPLATP2 / FORM RPAST_MESSAGE_CREATE |
|---|
IF ATPGSW-RPAST = SWON. CLEAR ATPMSG. ATPMSG-MSGID = 'AG'. ATPMSG-MSGTY = 'I'. IF G_T441V-RPAST = CHARA. ATPMSG-MSGNO = 31. ELSE. ATPMSG-MSGNO = 32. ENDIF. |
Table 52: Code that raises message related to receipts in the past
____________________________________________________________________________________________________________________________
Conclusion
This document is not exhaustive. There are many elements that it has not touched upon. For example, special stock, consignment stock etc. were not discussed in this document. Furthermore, the examples provided were provided without consideration to accumulation. If you come across an issue that is not discussed above and you wish to debug the problem, then function module STOCK_RECEIPT_ISSUE_READ is almost always the best starting point.
This document needs to be treated with caution. There is always the possibility that the code discussed in this document will be altered in future via correction notes or future supports packs (although the code provided here has been in the system for many years and consequently is unlikely to see further significant changes). Also, there can be instances where one flag depends on another etc. Such dependencies are not discussed here. This document should be considered a generic guide rather than a perfectly specific manual.
CO09 can be daunting when experiencing it for the first time. This is especially true when you see numerous elements on the screen. However, if you break each element down, understand where each element comes from and why each element is displayed, CO09 becomes your ally; it can become a transaction that helps you understand what is happening throughout different areas in the system. You will reach the point where you open CO09 and know immediately why it is displaying the result that you see.
- SAP Managed Tags:
52 Comments
