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:

Table 1: Select the material data from table MARC

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:

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:

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 8)

Figure 8: Flag not set so inspection lots not displayed and available quantity of 7.

Code that implements this logic:

Table 5: Select on table MDQM

Table 6: Quantity of MDQM-LMENGEZUB passed to the ATP structure

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:

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:

Table 9: Selects the batch data from table MCHB

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:

Table 11:  EXIT before the select if MSSL the flag is = “X”

Table 12: SELECT on table MSSL

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:

Table 14: When component added to subcontract order, constant BRBED passed to MDPMX-BDART (Later stored in RESB)

Table 15: If OLBPR set, the system may exit before the SELECT (depending on other flags)

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:

Table 17: Macro that checks if the flag is set

Table 18: Selects the data from EKET (ensuring it does not select a deleted PO etc.)

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:

Table 20: Select from EKKO will only succeed when there is a value in RESWK (Supplying Plant in STO)

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:

Table 22: Check to see if the flag is set. If not equal to X, then system does not proceed to the SELECT.

Table 23: Select on the EBAN structure; ensures that a deleted purchase req is not selected etc.

8) 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:

Table 24: Macro to check if RESB flag is set

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:

Table 26: Code that checks if the flag is set. System will exit before select if flag not set

Table 27: Code that selects from MDUR view

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:

Table 29: Macro to ensure flag is set. If not set, then system will exit

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:

Table 31: Macro to ensure flag is set. If not set, then system will exit

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:

Table 33: Checks if the flag is selected in OVZ9; note that the purchase order flag must also be set

Table 34: Select on EKES

Table 35: Calculate the available quantity of the shipping notification

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:

Table 37: Macro that contains the code to exit if the flag is not set (to X or A)

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:

Table 39: Passing the “Movement allowed” indicator to the ATPMEX internal table.

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:

Table 41: Table: Code that will ensure exit before doing the SELECT if the flag is not set

Table 42: Code which ensures that only STO’s that have not been deleted / fully delivered/ fully goods issued etc. are to be selected.

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:

Table 44: Code to ensure flag is set. If not set, exit before system selects from PLAF

Table 45: Select on the PLAF view

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:

Table 47: Code to check if flag is set. If not set, exit before the select on AFPO is executed

Table 48: Select on the AFPO view to get the relevant production orders for this material / plant

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:

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:

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:

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.

Material Change report is based on two major tables, CDHDR and CDPOS.

CDHDR - Change document header

CDPOS - Change document items

For custom report, need to add material description with this. Material description is from MAKTX field in MAKT.

MAKT - Material Description

To achieve the Material change report, need to join the above 3 tables.

Join CDPOS, CDHDR with MARA, MAKT.

List the available columns in all the tables.

CDPOS table structure

CDHDR table structure

Join between CDHDR and CDPOS tables

MAKT table structure

Joining CDHDR & CDPOS with MAKT is the problem, we can't see any proper join except language key in SQVI. Joining is possible by identifying the table records.

Check all the above table records. CDHDR & CDPOS are huge tables so make sure to use properly.

Based on the data, we can join all the tables together.

Check the below SQL Script to join CDHDR & CDPOS tables.

SELECT TOP 10 * FROM SAPSR1.CDHDR C INNERJOIN SAPSR1.CDPOS CD

ON C.CHANGENR=CD.CHANGENR AND C.OBJECTID=CD.OBJECTID AND C.OBJECTCLAS=CD.OBJECTCLAS

Next step is to join with MAKT. Here ObjectID is matching with MATNR field. So objectID is nothing but Material Number.

SELECT TOP 10 C.OBJECTID as MaterialNo, MAKTX as MaterialDescription, C.UDATE, CD.VALUE_OLD, CD.VALUE_NEW

FROM SAPSR1.CDHDR C INNERJOIN SAPSR1.CDPOS CD

ON C.CHANGENR=CD.CHANGENR AND C.OBJECTID=CD.OBJECTID

INNER JOIN SAPSR1.MAKT M

ON M.MATNR=C.OBJECTID

Check the below output

Problem:

Open requirements in scheduling agreements maintainunderdelivery tolerance in case of underdelivery.

If the open requirement in the scheduling agreement is fewer as the tolerance, the open requirement can't be disposition relevant anymore.

However planned orders will be created for the remaining requirement.

Therefore there are many little requirements in the planning, which shouldn't be produced.

Solution:

The requirements will be reduced in the scheduling agreement based on the open quantity.

The open quantity will be calculated based on the delivered quantity in the S073.
S073 will always be updated with the actually delivered quantity from the delivery

The requirements from the scheudling agreement will be reduced in the scheduling agreement based on the open quantity.

F1 help of the field:

open quantity to be delivered, confirmed in the sales quantity unit and a quantity to be delivered of a schedule line

Usage

The system determinates the delivery quantity with the consideration of the following parameters:

confirmed quantity

already delivered quantity

whether the item has been canceled in the meantime

whether the schedule line is still delivery relevant

Example

A schedule line contains an order quantity of 100 pieces.

The availability check shows, that only 80 pieces are available.

A partial delievery of 50 pieces happened already.

The delivery quantity which has been made from it, conducts 30 pieces.

If the item would be identified as cancelled, the delivery quantity would come to zero.

The open quantity doesn't consider the underdelivery tolerance, only those qunatities will be considered which has been delivered actually.

in contrast of a normal sales order where the sales order has the 'completed' status in case of an appropriate underdelivery tolerance and the remaining quantity is no more requirement relevant.

In the scheduling agreement you can reach it via the setting of the 'reason for rejection'.

Business requirement:

• Creation of Production Order only after the approval / release of Sale Order.
• (Cost of goods sold) COGS should not post until proof of delivery is not completed.

Process Flow:                                                       

• Activate business function first LOG_MM_SIT functionality.
• Create Quotation (in my scenario I am using pro forma invoice as quotation) then create sales order with reference to quotation and in sales order credit check is activate.
• Due to credit limit sales order is blocked, as sales order is released from credit check then production orders will create automatically and while creating delivery order system determine batches automatically or manual.
• COGS will post when proof of delivery is done. For more about Stock in Transit review LOG_MM_SIT functionality.http://scn.sap.com/docs/DOC-48809

Configuration:I am supposing that you know about the basic SD Configuration. I am using strategy 82 in material master and marked POD check box in customer master under shipping tab and assigned valuation class in material master as shown in screen shot.

Copy sales order from OR to ZXLX and Copy item category TAK to ZSIT and ZSIT item category is marked as credit active as in screen shot.

Using simple credit limit check and delivery block as in screen shot.

Copy schedule line category CP to ZS screen shot. Maintain copy control settings from order to delivery.

Assign schedule line category with MRP type PD as shown in screen shot.

Using requirement type KMFA and requirement class 201 for automatic production order creation as showing in screen shot.  

Front End Process Flow

Creating sales order with reference to quotation (pro forma invoice in my scenario) and system will execute simple credit check as shown in screen shot.

System creates sales order and will not create production order until someone approves it. As you can see in screen shots of COOIS report there is no production order created against that sales order before approval of sales order.

Sales order will release by using Tcode VA14L as in screen shot.

Now again execute COOIS then you will see that production order has been created automatically with reference to sales order as shown in screen shot.

Now PP person will release production order and do confirmation and post inventory in warehouse and stock will update with reference to sales order as shown in screen shot of MMBE report.

Now create delivery order with reference to sales order and put manual batch or for auto batch determination (see auto batch determination). While creation of delivery order you will see Post Goods Issue tab is in display mode only. Put batch and other information and save delivery order. Now execute stock movement report MB5SIT as shown in screen shot, stock is in Stock TB delivered.

Again go back to delivery order and do the Post Goods Issue then system will generate one material document here and then execute MB5SIT report again, you will see stock is now shifted from Stock TB delivered to Issuing Valuated SIT as shown in screen shot, but it will not post COGS entry until we did not do Proof of Delivery (POD) as per LOG_MM_SIT functionality.

Now do the POD and then you will find that one material document is also created at this stage and also stock will transfer from Issuing Valuated SIT to Delivered Stock in report MB5SIT as shown in screen shot.

Now for complete document process flow see the document flow on screen shot.

Summary and Achievements:

• Credit control on sales order.
• Production order only created after approval / release of sales order by some authorized person.
• Production with reference to sales order.
• Inventory is according to sales order in stock report.
• COGS entry post on Proof of Delivery (POD).
• Tracking of stock while in transit.

Hoping it will help you.

Business requirement:

• Different COGS GL account for Sample / FOC order.
• Automatically assignment of different cost centers to sales order.
• One GL but report according to cost center.

Process Flow:

• Creation of FOC order and assign order reason in it.
• System will automatically assign cost center according to assignment of sales order reason with cost center in backend configuration.
• Create delivery and Post Goods Issues.
• Cost transfer to Cost center.

Configuration Steps:

• SD Document category should be “I” (Order w/o charge) in VOV8.

• Define order reasons.

• Assign order reason with cost center in OVF3.

• Maintain GL assignment in OBYC with General Modification key VAY with respect to valuation class. For more about VAY review

http://www.stechno.net/sap-notes.html?view=sapnote&id=616097

Front End Process Flow:

• Create sales order with and assign order reason as highlighted in screen shot.

• System will take automatically Cost center with respect to assigned order reason.

• Save sales order and create delivery order with reference to sales order and do the Post Goods Issue then you will find that system will take GL that has been defined in OBYC against VAY key. Following is the accounting document against that delivery order.

• Execute report S_ALR_87013611 for cost center values.

Summary / Achievements:

• COGS booked to other GL for FOC scenario.
• Cost center auto assignment.
• Report according to cost center for controlling and decision making purpose.

Hoping this process and document will help you.

The reports includes an implementation of  " VL06: Designing your own display variants". You want to add your own fields to the standard display variants of the delivery monitor when it is a quide for solution.

Related Oss Notes

128150 - VL06: Designing your own display variants

122975 - Resetting buffering of ALV field catalog

113048 - Collective note on delivery monitor

320226 - Delivery monitor: No negative quantities in returns

1144147 - Error during DIMP activation relating to structure LIPOVZ

113033 - VL06: No cancel for goods movement postings

Business Requirement

You can not modify your own display variants with customizing for this you can benefit from belowed example.

Related tables and tcodes

LIPOV , LIPOVZ , CT_POSTAB , VL06O

Solution

   Firstly , find function group like belowed or go inside of program Goto --> Attributes

   CALL CUSTUMER-FUNCTION

   Tcode : SE80 , Function group : V50Q

   Double click CT_POSTAB , find structure of internal table.

   LIPOV is our related structure , this step is related append structure.

   Go to --> SE11 tcode.

   In change mode , click append structere and give name.

   In this step , add related fields to structure. KDMAT is appended for this example.

   Check fields on structure like belowed , save and activate.

  Function module EXIT_SAPLV50Q_001 to find include. MODSAP table get relation in member.

   SAP EXTENSION NAME --> V50Q0001

  Tcode --> SMOD --> Change --> Components --> EXIT_SAPLV50Q_001 --> Go to include  ZXV50QU01

  In this example , lips-kdmat (customer material number) is assigned to ct_postab-kdmat .

  Also , kdmat is appended to LIPOVZ.

Note : BALVBUFDEL program must be run with SE38 for deletion of last buffer . Details on oss note 122975.

Result :

Problem:

Open requirements in scheduling agreements maintainunderdelivery tolerance in case of underdelivery.

If the open requirement in the scheduling agreement is fewer as the tolerance, the open requirement can't be disposition relevant anymore.

However planned orders will be created for the remaining requirement.

Therefore there are many little requirements in the planning, which shouldn't be produced.

Solution:

The requirements will be reduced in the scheduling agreement based on the open quantity.

The open quantity will be calculated based on the delivered quantity in the S073.
S073 will always be updated with the actually delivered quantity from the delivery

The requirements from the scheudling agreement will be reduced in the scheduling agreement based on the open quantity.

F1 help of the field:

open quantity to be delivered, confirmed in the sales quantity unit and a quantity to be delivered of a schedule line

Usage

The system determinates the delivery quantity with the consideration of the following parameters:

confirmed quantity

already delivered quantity

whether the item has been canceled in the meantime

whether the schedule line is still delivery relevant

Example

A schedule line contains an order quantity of 100 pieces.

The availability check shows, that only 80 pieces are available.

A partial delievery of 50 pieces happened already.

The delivery quantity which has been made from it, conducts 30 pieces.

If the item would be identified as cancelled, the delivery quantity would come to zero.

The open quantity doesn't consider the underdelivery tolerance, only those qunatities will be considered which has been delivered actually.

in contrast of a normal sales order where the sales order has the 'completed' status in case of an appropriate underdelivery tolerance and the remaining quantity is no more requirement relevant.

In the scheduling agreement you can reach it via the setting of the 'reason for rejection'.

Dear All,

In recent times SAP is continuously enhancing SAP Transportation Management

As many of us know that Transportation is integral part of SAP R/3  as LE-Transportation for shipment and cost calculation. Later SAP came up with some advancement in terms of Advance planner and Optimizer. During 2009 SAP TM emerged as Stand Alone system supporting Service providers such as DHL , LINFOX . By adding shipper business process TM now supports AIR, OCEAN and Land transportation

Now as part of Knowledge sharing, i would like to share the integration between SAP R/3  SD (Sales orders , Deliveries) and SAP TM

SAP ERP integrates with SAP TM mostly in shippers business process where all the Transportation planning and execution phases is handled by SHIPPER ( manufacturer)

Business process:

Let's assume, customer places an order with the company for a material which has to be delivered to his site. As part of Sales order process we create Sales order in R/3. Now the order has to be integrated to the SAP TM system to initiate the Transportation process for arranging transportation and execution

Now our concentration here is about how R/3 order is integrated to SAP TM and what are the prerequisites from SD stand point

Basic settings in SAP SD

we have a integration configuration inbuilt in R/3 to transfer Sales order , Deliveries and Purchase orders to support both inbound and outbound transportation process

Path:

SPRO-->INTEGRATION OF R/3 WITH OTHER COMPONENTS-->TRANSPORTATION MANAGEMENT-->ORDER INTEGRATION

1. Control Key:

This is the activity where we define which documents are required to be integrated to SAP TM. Here we have options such as Sales orders, Deliveries, Purchase order. We can choose one among them or combination of them to transfer to SAP TM.

2. Activate Sales documents

This is the activity where we assign required sales area, along with Sales document type and Shipping conditions. This way we are controlling the document types which are required to be transported. For example if we want only outbound Sales orders to be transported and not Return sales orders to be transported, in this activity we can control

3. Activate Delivery documents

As we activated Sales order, similar way we can also activate transfer of Delivery documents to SAP TM. This setting has to be activated specific to SHIPPING POINT & DELIVERY TYPE along with the CONTROL KEY

4. Activate for Purchase order

This step is required if we need to activate Purchase orders or Stock transfer order to be transferred to SAP TM

We can activate PO documents in combination with PURCHASE ORGANIZATION, PURCHASE GROUP , PO TYPE & CONTROL KEY

Transaction flow

1. Create Sales Order

Create a sales order in VA01 as normal process

2. with all the above integration in place system will create Transportation Requirement in TM which will be used for Planning and execution of Transportation of Physical goods. As part of planning in SAP TM system will populate realistic transportation dates and resource scheduling. Upon which we can plan Delivery in SAP R/3

Due to some integration Error, i could not able to put the document flow. I will update that As soon as possible

Requirement:

The below mentioned process is to make some default text should be available in sales order header every time while creation of sales order.

at the same time we can edit the text and print it on the sales order.

Configuration steps:

1. Create ID under TEXT object

SAP Easy Access>Tools>Form printout>Administration>Settings-SE75

will get a warning : These settings are valid in all clients.

click on continue

Double click on it

Create a new text ID for object TEXT same like “ST” with “Z”

Maintain details like above mentioned (Similar to “ST”)

getting an information message like Observe name ranges: Y,Z for customers, JNC for partners, A..X for SAP

Click on yes

2 Text Name creations:

SAP Easy access>Logistics>Sales and Distribution>Sales support>Sales promotions>SO10-Standard texts

Maintain a new text Name and created Text ID as per business requirement

Maintain some text as per business requirement

Click on save

3.Text determination procedure

Now the text should be appear in sales order header text screen as a default.

For this we need to configure “Text determination procedure”

SAP IMG>Sales and Distribution>Basic function>Text control>Define Text type

Define Text type:

caution: The table is cross client information will come,

click on continue.

Click on save

3.1 Create a new access sequence in Text determination procedure

SAP IMG>Sales and distribution>Basic Functions>Text control

After enter the below data press enter,

Text object: TEXT

ID: ZDHI

Text name field will be open from display mode to editable mode

Enter SO10 text which we created as per business requirement

Should be displayed at sales order level by default.

Save it.

Assign the procedure to sales document type

Now check the sales order.

Note: This document I prepared in IDES system for information purpose to share the knowledge.

before doing any changes please check with your ABAPER and business requirement.

Hope it helps for everyone.Comments and suggestions are welcome.

Thanks,

Krishna Kumar.

Like any other country Switzerland has some special legal requirement . One of  Swiss legal banking requirement is to print ISR Payment Slip from sales Invoice.

ISR Payment Slip: In-payment Slip with Reference Number (ISR) Payment Slip is a service which facilitates customer to pay Invoice in Swiss Franc or in Euro in simple manner.

This pre-printed Orange slip requires data to be printed following swiss Postfinance norm so data can be read without any error.

During working for thiis requirement, I found there are very few documents available on this local requirement. Another problem which I faced that many of these documents are not in English language.

In this document, I will try to share some information which I learned during my interaction. Hope this will be helpful for community.

In this document  main intention is to concentrate on business part specific to Switzerland Payment slip rather than discussing configuration.

Discussion of Standard output configuration is not in scope of this write-up.

This document will not cover FI configuration.

Main goal of this write-up is to provide all available information related to ISR Slip at one place.

If you find this document helpful then please do not forget to LIKE this document . Please give your rating.

Lay out of Swiss Pre-printed Payment Slip:

Data layout of ISR Payment slip change depend upon business process for example Invoice having Cash Discount requires different data layout than normal one.

Please validate requirement from business before implementing any solution. For example in our business only ISR & ISR+ scenario related to swiss currency was relevant.

Data needs to be printed in OCR-B1 character set

Please check attached URL in this write-up for further details.

Swiss Orange Slip Template :

Interesting part of Payment slip is ISR code. ISR code is combination of Invoice value, Bank account, customer number & check digit in certain order.

Check Digit:

Check Digit is a functionality used in ISR Code  to prevent reading error due to Interference factors such as soiling, excessive stamping or handwritten changes to the printed characters. As Incomplete or illegible digits can lead to rejection or incorrect reading of slips.

Hence to identify these mistakes and prevent eventual errors from being processed, check digits are added to the code line.

The digit is calculated using recursive module 10. Please check link attached to get more details on Check Digit.

Modulo 10 computing method:

We created z code to determine check digit in our business process, This code may be reuse in case if your business requirement support. (Consultant discretion require as per their business process).

Further Reading:

Manual ISR :

https://www.postfinance.ch/binp/postfinance/public/dam.M26m_i6_6ceYcN2XtAN4w8OHMynQG7FKxJVK8TtQzr0.spool/content/dam/pf/de/doc/consult/manual/dlserv/inpayslip_isr_man_en.pdf

Check Digit (Modulo 10)

https://www.postfinance.ch/binp/postfinance/public/dam.kDeM1NfdktHxsoPgqxBgbWOwXjqUmZZMUW52ZpIhfU0.spool/content/dam/pf/…

Check digit computation module 97–10:

http://www.pruefziffernberechnung.de/Originaldokumente/IBAN/Prufziffer_07.00.pdf

Printing Invoices with ISR Procedure - Switzerland - SAP Library

ISR Procedure (Switzerland) - Switzerland - SAP Library

SAP Note:

506723 - Support of Swiss ISR Procedure in EBP

956920 - Switzerland: Maintaining ISR data for mandates

Hi

I am going to explain that how we can implement authorization or any other check on SD documents display transactions.

Business Requirement

You get a requirement to put some authorization check on SD documents display/change transactions based on some field which is not available in standard authorization objects. How would you do that?

Solutions that come to your mind

First thing you get in your mind is to use some userexit for this but that is not gonna help you in display transactions. You can't do that using SD userexits available for sale order, delivery order and billing document. Usually we implement checks in MV45AFZZ for sale order, MV50AFZ1 for delivery order and RV60AFZZ for invoice. There are also many other enhancements available but these are three most commonly used.

Problem with these enhancements and userexits is that these are helpful in VA02,VL02N and VF02 but for display transactions these are not triggered and can't help you out. If you use authority check logic in these exits system doesn't check that in display transactions. So what do we do here?

Proposed Solution

There are certain enhancements which system calls on display transactions. These are not that easy to find but since we have worked on it and found these so I thought I should share here so that anyone else facing such requirement can get benefit of it.

For VA03

• Go to VA03 > System > Status and copy program name from here and see the screen number. For VA03 program name is SAPMV45A and screen number is 102.
• Now go to SE80 and enter program name in program and double click on screen 102. Here you'll see following module. Double click on that and add the authority check coding or any other code as per below screen.

Here you can see my message that I have written for testing. You can add authority check code or any other function/BAPI or check that you want to trigger on VA03. For adding this its good that you take help from your ABAPER because it requires an implicit enhancement implementation and if you don't know how to do it ask your ABAPER.

After adding this you'll get this message everytime you open VA03 > give sale order number and press enter.

For VL03N

Go to VL03N transaction code and see the program and screen number like we did in previous step.

Go to SE80 and repeat the same and double click on following module.

Here click on following perform.

Here add your logic in below section by implementing an implicit enhancement.

Following is the message which you'll see everytime you open a delivery order.

For VF03

Repeat the same steps for VF03 and copy program name SAPMV60A and note the screen number 101. Double click on following module.

Here click on following perform.

Add your code in below section after implementing an implicit enhancement.

Following is the message that I have added here and you'll see this every time you open an invoice in VF03.

This is it. Simple and easy way to trigger anything on start transaction of any SD document display transaction code. We did this only for these three transaction codes. If there is requirement for other transactions we can find triggering point for those as well.

Test this in your system and share your negative/positive feedback with me in comment section. If there is some other way to meet this requirement please share that. 

This document is related to authorization control so I'd like to tag Security here and this document includes technical information as well so ABAP Development guys can also use this for future reference. Usually this requirement comes in SAP ERP Sales and Distribution (SAP SD)SAP ERP SD Billing or in SAP ERP SD Sales so I am tagging these spaces as well.

Thank$

This type of delivery are created for non tangible delivery; for example; Services. Please refer attched file for reference.

Have been involved with Consumer Goods and Services Client based out in Germany geography. In recent times, the Client has decided to implement process change in supply chain model across all business units in Europe. With new process model, there was a business need to implement Plant Abroad functionality at Maribor location. In collaboration with SAP, pilot version of Plant Abroad functionality is implemented at Maribor to tackle consignment and replenishment delivery process at Maribor. So made an attempt to articulate the concept of Plants Abroad and co-related Sales setting.

Plants Abroad Scenario

• Comprehensive configuration solution for companies in European Union where companies have plants in another European Nation.
• This functionality helps to assign plants from different countries to one company code without a need of having sales organizations in the countries where plants are located and company needs to have VAT registration numbers in those countries where it is obligated to file VAT returns/European Sales Listings/Intrastat returns.
• This can be activated to handle tax issues for companies that have VAT registration numbers in more than one country.
• Activation ensures that VAT registration number correctly gets printed on documents like sales, purchases, invoices, correct VAT registration numbers being used for right tax calculation, stock transfers between plants get captured for intrastat reporting correctly.
• This functionality helps to process Tax returns for warehouses or sales and distribution centers abroad using domestic company codes. i.e. Tax returns to a foreign tax authority, EC sales list for another EU country.
• To enable intrastat reporting and VAT on foreign VAT registration number.
• To enable Intra-Company and cross-border stock transfer. This functionality helps to create Plant Abroad Invoice (Document type WIA) for stock transfers between foreign plant and domestic plant.

Example :- Stock transfers between foreign plant (warehouse in Maribor) and domestic plant (warehouse in GERMANY). Two VAT registered entity, GERMAN company needs to report VAT (Intra-community acquisition of goods and reverse charge) and trade statistics (Intrastat and Sales Reporting). Plants abroad invoice capture the trade statistics and VAT for German Company - both AR (Maribor Plant) and AP (German Company).

Configuring Plants Abroad Functionality:

1. The IMG path is SPRO-Financial accounting – Financial accounting global settings – Tax on sales and purchases – Basic settings – Plants abroad – activate plants abroad. Tick the box with the question: Plants abroad activated                                                                                                                                                                                                                 
2. Enter the foreign VAT numbers. The IMG path is: SPRO-Financial accounting – Financial accounting global settings – Tax on sales and purchases – Basic settings – Plants abroad – Enter VAT registration number for plants abroad                                                                                                                                                                                                                  
3. With the Plants Abroad functionality activated in SAP system, then a new field "Country Currency" and "Exchange Rate" will be available in Set Country Global Parameters configuration. Reporting Country” field will appear on the selection criteria screen on the VAT return report and EC sales list. The VAT return report gets enhanced to show country specific currency for “Reporting Country”.                                                                                                                                                                                                                   
4. Create tax codes in FTXP, where field “reporting country” in the properties of the new tax code is updated.                                                                                                                                                                                                                  
5. Related OSS Notes for in-depth configuration:- OSS note 63103: Explains logic regarding tax procedures if you are using plants abroad, OSS note 1085758: Customizing for stock transports , OSS note 850566: deactivate plants abroad for a particular company code. OSS Notes for Tax determination for plant abroad :- 10560.                                                                                                                                                                                                                                                                                 
6. When a company has a foreign VAT registration number in another country, it needs also to file Intrastat returns, Intrastat ID numbers needs to set up in transaction OBY6 - click on additional details.

Plants abroad: Sales-specific settings:

1. Billing documents needs to be created for consignment fill-ups or pick-ups and replenishment deliveries although they are not relevant for billing as INTRASTAT declarations and tax postings depends on Billing document. Pro-forma invoice can be used if the plant abroad is not in the EU.                                                               
2. Special pricing procedure (RVWIA1) is created and assigned to the new billing document (billing type WIA) defined for replenishment deliveries and consignments between EU countries.                                                                                                                                                                                                                 
3. Structure of Pricing Procedure - RVWIA1

       A:- Pricing condition (PR00)

       B:- Input tax in destination country (based on pricing condition)

       C:- Output tax in country of departure (that is, 0% on deliveries within the EU)

       D:- 100% discount R100 (based on pricing condition)

       E:- Output tax in destination country (based on the 100% discount)

5. Billing type for determining taxes for plants that are abroad defined – WIA(Standard type), The standard system contains default order type WIA which is assigned to delivery types LF (consignment fill-up), LR (consignment pick-up), and NL (replenishment), and proposes billing type WIA.

6. Copy control setting between Delivery type and Billing type

Copying requirements - 010, Billing quantity - D, Data VBRK/VBRP - 001 Inv.split (sample) Pricing type - B

7. Maintain Billing relevance for Item Category, KBN (consignment fill-up), KAN (consignment pick-up), NLN (replenishment) as indicator J

8. Assign G/L Account to Account Key

9. Maintain Declaration number :- INTRASTAT identification number for the countries of foreign plants is maintained and VAT registration number in the relevant customer master records is to be updated. The customer who has been assigned to the receiving plant must have a VAT registration number.

10. Condition records must be created for the following tax conditions type

WIA1: Input tax in country of destination, The tax code for the tax determination procedure of departure country must agree with the tax code of the country of the company code. This is because the tax code is accessed via the company code country during forwarding to FI. The field 'reporting country' (that is - country of destination) must be maintained in the characteristics of the tax code.

WIA2: Output tax in the country of departure (0 % for EU-internal deliveries)

WIA3: Output tax in country of destination, The tax code for the tax determination procedure of departure country must agree with the tax code of the country of the company code. This is because the tax code is accessed via the company code country during forwarding to FI. The field 'reporting country' (that is - country of destination) must be maintained in the characteristics of the tax code.

11. Base amount and cash discount Pricing Condition :

A: Settings in transaction OBY6 (company code) are no more relevant for calculating tax base and discount base on net amount. Instead of this the         country settings (transaction OY01, Country Global Parameters, table T005) are responsible.

B: Indicator 'Base amount for tax is net of discount’ should be used in transaction OY01. This indicator causes the base amount for the calculation of         sales tax to be reduced by the discount share. Indicator ’Discount Base Net’ in transaction OY01 should be flagged for the concerned company code if              it’s required that the sales tax is not contained in the base amount for discount calculation.

• Any Legal requirement of Countries (BE/NL/LU, ES) to have continuous Billing document number ranges can be implemented with buffer-switch-off-function via User-exit (RV60AFZZ_NUMBER_RANGE), Refer SAP Note (1524347) for more information.

• Programs/Reports for Plant Abroad scenario:-

Process flow of Intra Company Stock Transfer :-

1. Creation of Stock Transfer Order (UB type), Transfer of Finished Goods from Germany based plant to Maribor.

2. Delivery Creation and Good Issue at Germany based Plant.

3:- Goods Receipt booked at Maribor based plant. For MIRO (Invoice Verification), the default country of company code needs to be changed with change Reporting Country option, so that, this value can be posted with the respective warehouse country.

4:- Generation of Plant Abroad Invoice – WIA with respect to supplying plant – Germany Plant.

Process flow of Consignment Sales Process:-

1:- Consignment Fill-up and Pick-up with the consignee located in European country other than the Plant / Warehouse located country.

2:- After Goods movement is posted with movement type 631/632 respective consignment process, Plant Abroad Invoice – WIA is generated.

Hope you all would find the documentation useful and feel free to share your thoughts, feedback or suggestion!

Thanks,

Sarthak

Inference / Reference : -

http://help.sap.com/saphelp_erp60_sp/helpdata/en/e5/077f984acd11d182b90000e829fbfe/content.htm

http://scn.sap.com/people/praveen.kumar109/blog/2008/12/17/eu-tax-reporting-with-plants-abroad-functionality

During SAP implementation or Support project, a functional consultant receives many customizing request based on functional design document or Incident Number. And life becomes very difficult when configurational request becomes dynamic in nature due to unfreezed functional design or change in Client business decision, i.e. Functional consultant receives multiple iteration of this configurational request. So it becomes important to quickly and efficiently track and analyze changes to customizing tables whenever slippage happens. This is an articulation to demonstrate various approach of tracking configurational/customizing changes performed during project realization phase.

Approach 1:-

To give a good insight on the approach, let’s consider a simple exercise of configurational request .i.e. Define order reasons: In this menu option you define the possible order reasons. They describe the reasons which led to an inquiry, quotation or order. When processing a sales document, you can specify the order reason in the overview at header level. It then applies to all the items.

Navigate to Utilities menu and press "Change Logs" option:

Here, there is provision to enter a date range to check the change log and once the desired date range is entered, execute button is hit.

Approach 2:-

Here the catch would be to make a note of Customizing table or object (maintenance views, view cluster or individual Customizing transactions) and use it in the following report to check the table changes specifics.

Following reports needs to be executed for table log changes:

1.     Program RSTBHIST/Transaction code SCU3 or Program RSVTPROT (an ABAP/4 program)

Pre-condition to be checked in system for table to be logged:

1. In the technical settings of the table, checkbox "Log data changes" is marked. You can go to the technical settings via Transaction SE13.

2. Logging is also set in the system profile.

Approach 3:-

DBTABLOG :- Change customized table log is maintained in the table and Function Module : DBLOG_READ useful to read the change log by passing the tables that you want to read in the parameter :- OBJ_LIST.

Thanks,

Sarthak

Brief Introduction:

Recently was involved in Retro-fit activity of Project where minor bug fixes/changes made at Support system, Transport request are copied and aligned to Development system of Project stream. This activity in basic sense performed to maintain consistency between Project and Support system landscape in terms of baseline Configuration and Business process. As a matter of fact, during this transport request release process to Development and Quality system of project stream, there were some or the other factory Calendar configuration overwritten for some plant and shipping point. The defect which we came across during Integration Test phase was good motivation to document this article and illustrate on relevancy of Calendar from logistics prospective.

Concept and relevancy at SAP:

Well the concept of Calendar is important and exhaustive in nature and Calendars in SAP are basically used to define the working days for plants/warehouses, shipping points. They are also in fact assigned to routes in logistics stream area or unloading points at Customers. For the accurate calculation of date, calendar in SAP have to be maintained & assigned correctly. For all exceptions requirement, an additional factory calendar might be necessary like for example if the production produces on all days, but shipping is done only on working days. Then the plant can have a different calendar than the shipping point.

In general synopsis, a calendar consists out of three basic elements which are clear identified below for reference and through SAP transaction “SCAL”, it is defined:

• Public Holidays - Definition of the public holidays are done with following type :
  - with fixed date
  - with a fixed day from date
  - Distance to Easter
  - Easter Sunday
  - Floating Public Holiday

• Holiday calendar: This contain comprehensive list of all public holidays per country (e.g. Christmas).

• Factory calendar: This calendar defines in generic sense which days are working days. With ‘special rules’, workdays can be set as non-working days in the individual calendar. The factory calendar is defined on the basis of a public holiday calendar, weekdays that are working days must also be specified in this calendar.

Special Rules

Calendar is used in the following cases i.e. on the baseline of Organizational unit, Master Data and Transaction data of SAP:-

1. Organizational Unit

A:- Plants

B:- Shipping points

C:- Transport planning points

D:- Route definitions in Logistics

E:- Sales organizations

F:- Company code

2. Master Data

A:- Unloading points in the customer master

B:- Invoice dates in the customer master (sales views)

3. Transactional Data

A:- SD Billing plan

B:- Process orders / planned orders

Impact of Calendar on Delivery scheduling :-

In the Organization unit i.e. Plant – factory calendar maintained has no influence on the delivery scheduling process. The calendar setup in the following area has impact on the delivery scheduling process:

Properties of delivery scheduling:

1. Transit time : determined from the route –  (factory) calendar assigned to route
2. Loading time : determined from shipping point –  shipping point calendar
3. Pick and pack time : determined from shipping point or route –  shipping point calendar
4. Transportation planning time : determined from the route –  (factory) calendar assigned to route

Let us take a simple example where Customer places Sales Order for 100 unit of Material and the requested delivery date indicated by customer as 10th March 2015.

The Delivery scheduling during Order creation is as follows :-

Specifics of standard Table of Calendar:

A:- TFACD: Factory calendar definition

B:- TFACS: Factory calendar (display)

C:- TFACT: Factory calendar texts

D:- THOC: Public Holiday Calendar

E:- THOCD: Public holiday definitions

F:- THOCI: Public holiday calendar index

E:- THOCS: Public holiday calendar (display)

F:- THOCT: Public holiday calendar texts

G:- TFAIN: Calendar: Intervals for company holidays, special shifts

H:- TFAIT: Calendar: Text for factory calendar intervals

Tables having factory calendar:

A:- KNVA:  Customer Master Unloading Points

B:- KNVV:  Customer Master Sales Data

C:- T001W: Plants

D:- TVRO:  Routes

E:- TZBZ:  Company code: Additional data

F:- TVST:  Organizational Unit: Shipping Points

G:- TTDS:  Organizational Unit: Transportation Scheduling Point

Special Note:- As the delivery and invoice creation jobs are scheduled based on the SAP calendar, it's required to start these jobs manually on the last working day before holiday period.

Please feel free to share your thoughts, feedback or suggestion on this articulation!

Thanks,

Sarthak

PS :- Inference / Reference : -

http://scn.sap.com/docs/DOC-52366

http://wiki.scn.sap.com/wiki/display/NWTech/SAP+Calendar+Master

Hi

From sales point of view there are different processes that how you are managing your freight. If you are delivering some physical goods by using some vehicle and paying its transportation cost to vednor then you can have various options or requirements that how this freight should be calculated and posted. It depends on management decision and their requirement that how do they want you to configure this in system. I am listing down some scenarios and in this document I am going to explain most simplest one and after this I'll move on to others in next documents.

1. Freight is being paid to vendor/transporter and you don't have transportation module implemented. You also create accrual/clearing entry for this.
2. Freight is being paid to vendor and you have transportation module implemented. You calculate freight automatically and post it to FI. Company pays this freight and bears the expense.
3. Freight is being paid to vendor and you have transportation module implemented. You calculate freight automatically and post it to FI. Comapny doens't pay this freight but charges to customers.
4. Company has it's own transportation vehicles and it doesn't pay freight to any vendor but calculates and charges this separately to customer.
5. Company pays freight to vendor and charge this freight to material price in plant to plant transfer under same company code. This freight is calculated in shipment cost document automatically.

There could be many other scenarios but by following these and by following the configuration which I am going to explain in these you would be able to cover up most of the scenarios.

In this document I'll be covering point number one only which is how to enter freight in delivery document and copy this to billing and post in FI with accrual entry. This accrual entry will be debiting freight expense and crediting freight payable liability which will be debited later on when we will pay to vendor.

Configuration steps.

While explaining these steps I assume that you are familiar with basic configuration steps and prcesses.

Create separate pricing procedure in V/08 with only one condition in it i.e. Freight Expense. This freight expense is basically an accrual condition and you have marked it as accrual in V/06 under control data 2. Condition class A and calculation type is C. This is manual condition and no need to maintain any access sequence. If you want to make it automatic then use access sequence and maintain condition record.

Assign this pricing procedure to your delivery type. For delivery types we can't determine pricing procedure like we do for orders or billing documents.

Now maintain E in pricing source for copy control from delivery to billing document in VTFL Tcode.

Configuration is completed and you can now test your scenario. I am listing down the steps that I did for its testing.

Created sale order with VA01.

Created delivery order with VL01N and entered freight charges at header level in delivery document because this freight is for complete delivery document.

Created invoice in VF01 and here you can see that freight charges have been copied from DO to billing document.

Posted invoice to FI with VF02 and in accounting document you can view that freight expense is with debit entry and freight accrual is with credit.

This is how we control freight with most simplest and easiest way. I will continue this document by explaining key points in other scenarios I have listed above. If you have some other scenario which I have not covered in these 5 listed scenarios then I would appreciate if you share that in comments section and I will try my level best to cover that too in this document.

Positive/negative feedback will help me to improve next documents.

Continued here. . .

Thank$

INTRODUCTION

Assembly processing is one of the rarely used but extremely robust process used in various industries. This process encompasses the functionalities of receiving the order and planning all the requirements of the order by passing the requirements to various other related modules. Once all the components are received they are assembled and handed over to customer.

Based on the business requirement, a sales order can lead to any of the orders including  production order, planned order, a network or a process order. Based on this linkage configurations are to be done in the respective modules along with configurations in sales and distribution.

This chapter explains about the creation of a network in project systems while creating a sales order in SD. The functionality of assembly request can also be linked with various other functionalities like milestone billing in SD, milestone management in PS, Schedule and cost management in PS etc. However this document concentrates only on the configuration required for creating a network automatically when a sales order is created. During the course of the document, some of the obvious configurations are assumed to be known to the basic consultant and hence not dealt in much detail.

PROCESS FLOW

The process starts with the creation a sales order using a material code. The material codes in this case are very limited and are specific to every variation.

The sales order item will trigger a requirement transfer. As a result the requirement class triggers a network considering the requested delivery date of the sales order as the finished date of the network. At the same time, a project is created for the entire sales order and WBS element will be created for each of the line item.

If the network is enabled with milestones for activities, then milestone billing can be automatically triggered in sales order if the item category is also accordingly configured.

Now we have a sales order, a project for it, various line items each item having a WBS element and a network. Now it is possible to manage each of these line items in PS using schedule and milestone management. Accordingly when milestones are confirmed in PS, milestone billing can be triggered in sales orders.

At the end when all the items are delivered the project can be settled and closed. This document doesn’t deal about deliveries for project as my knowledge level in this area is minimal.

CONFIGURATION TRANSACTION CODES

Though I have the system with me, I don’t want to put the screen shots because of customer confidentiality. Hence I am trying to explain as much as information through text. In case of any doubt the same can be discussed in the comment on this content.

VOV8

VOV7

VOV6

Configuration Paths in Transfer of Requirements

CN91

CN08

CL24N

CN01

STEPS IN CONFIGURATION

The first of the configuration is the sales order type. This is the basic configuration in SD and hence I skip this configuration.

The header configuration is followed by the item category configuration. If milestone billing functionality is to be used, then the Billing plan type in the item category should have a value indicating the Milestone billing. A copy of billing plan type can be made by copying the billing plan type 01. Similarly the billing relevance can be maintained as I for billing based on billing plan and order related billing. Except this all the other settings for item category is same for assembly processing as for any other processes. Also it should be remembered that variant configuration is a robust functionality used in assembly processing to dynamically determine various project and sales parameters and hence the item category should also consider the use of variant configuration if needed.

Schedule line configuration is same as the normal schedule line configuration and hence I am not dealing much about it.

These are followed by the configuration for transfer of requirements. This is where the SD module is integrated with the PS module. It involves the following steps to determine the strategy group or the strategy type. It can be based on the normal rules for TOR. The strategy group can be determined from any one of the following methods viz…the combination of item category and MRP type,from  material master and so on.  Using this configuration either the requirement class is determined using the strategy group (if the strategy group is maintained in material master) or using the requirement type (if the MRP type is maintained in material master). The requirement class is the one which dictates the integration between SD and PS and the desired requirement class can be seen from the transaction code OVZG. The configuration at the requirement class should have the following fields filled.

The availability button should be switched off as the material availability is not enabled in assembly processing.

The field Requirements transfer should be ticked on in the requirement class

The assembly type should be 2. This will ensure that a network is created automatically if the relevant configurations are done.

The field Order type should be filled with the network type which is to be created while creating sales order.

The field Capacity check can have the value as 1 or 2 based on requirement of capacity.

The fields related to costing and configuration can be left empty here as they can also be handled in other places which will take precedence over this configuration.

The field special stock can have the value as E to make sure that stock is reserved against the sales order.

The field Account Assignment Category should be enabled with the value D. This will ensure that the project or its subordinate levels can be used as account assignment objects. Based on the configuration in PS either the network and activity number or the WBS elements can be used as the account assignment objects.

The field Consumption should be configured with the value P to ensure project based consumption.

These fields are the mandatory fields to be updated. The remaining fields are optional and can be configured based on need. The fields related to costing, settlement, and valuations are best left empty here and configured in the respective modules.

Once these configurations are done in SD the process will work as follows.

When a sales order item is put, based on its item category, schedule line category configuration, the transfer of requirements is triggered and the correct requirement class is determined. Using the requirement class the system will try to create a network. However to create a network system will need another set of data from PS module. The set of data needed after doing the basic set of PS configuration are explained here.

At first a standard project should be created in PS using the transaction code CJ91.  In order to do this the project definition, the project profile etc are needed and the PS consultant will be in the best position to configure the project profile for this activity.

A standard project should also include a standard WBS element with all the necessary set up like planning element, account assignment element, billing element and other organisational elements. The creation of standard project and standard WBS element should follow the coding mask and the coding mask should take care of the number of characters for the sales order. Because any operative project or the WBS element will have the sales order number in the project as a standard functionality in assembly processing. For example if the coding mask is enabled as A/xxxxxxxxxx/ _____ then the characters xxxxxxxxx represent the sales order and the code with 10 characters will be used to fill up the sales order number while creating the project.

This is followed by the creation of standard network in CN01. The network can have the standard WBS element at the header and item level for all the activities if necessary.

Also in parallel the material master should also be set up by the MM consultant to be used in Sales order. The material master should have all the four MRP views and the MRP type should be kept as ND or the relevant MRP type to trigger the correct requirement type and hence the correct requirement class. If the MRP type is maintained as ND, then the strategy group should be maintained as the correct group which directs to the desired requirement class for the customer requirement.

Once these set up are completed, the final set up will be in the transaction code CN08 where the material code will be linked to a standard network.  This data should have the correct network order type as maintained in the requirement class. Also the standard WBS element maintained in this transaction code should be the one which is used in the network. Generally in standard network we use only one standard network. If multiple standard WBS elements are used in standard network activities, then in CN08, this field can be maintained with empty values.  The values MRP controller and the network profile are mandatory and should be maintained by the PS consultant.

If this is done in PS the transfer of requirements while trying to search for the network will have the necessary set up in CN08 and it will create an operative network.

It is also possible to have variant configuration enabled in assembly processing. Using this for example based on the complexity of the configuration and the activities required, different standard networks can be mapped to the same material using CL24N. I will write another document on this usage of Classification in Assembly Processing soon.

Thanks for reading and your patience.........

Below is the list of standard report which i have basically consolidated that helps to check SD customizing and transaction discrepancies.

RVOCHECK / RVOCHECK_ACC: Check Report for Customizing - Organization - Sales and Distribution

This is very handy report which basically provides consultant comprehensive flexibility to check the inconsistencies for SD Customizing Objects like Sales Organizations, Distribution channel, Sales Office, Sales group, Shipping point and Plant. 

For example: - After configuring Organizational structure like Sales Organization and all the corresponding related assignment, it become very evident to do quick round of review for the configuration performed for Sales Organization with respect to address, Assignment with Company Code, Sales Area creation, Plant assignment.

For SD Organizational structure like Distribution channel, quick and short review can be performed to check whether Sales Area are created or not, Whether text are existing in logon language.

We can also check for SD organizational element like Division.

Checks for Sales Office

Checks for Sales groups

Comprehensive check features provided for plants and Shipping points.

SDCHECKT683:- Customizing check: Pricing procedures

The report as a matter helps to issue a proposal of how the condition types should be set up in Customizing, in order to ensure that there are no errors in order and billing processing.

SDCHECKT685A:- Customizing Check - Condition Types

The following condition type settings are checked:

1) The scale type 'D' should not be used for group conditions.

2) If there is no access sequence, the scale type 'D' should not be used.

3) The pricing procedure for the condition supplement should not contain more than 100 conditions.

4) If the calculation type for the reference condition is 'A' or 'H', the calculation type for the condition type must also be 'A' or 'H' or the calculation types must be identical.

RV54_CUST_CHECK:- Used to check settings in the customizing for freight costs – pricing

This report exclusively helps to check the customizing settings for freight Cost Pricing condition.

SDCHECKTVCPF:- Customizing check: Copy control

The generic purpose of this report is to verify settings in copying control.

Example e.g. in third party order processing (invoice-receipt related billing), if billing relevance 'F' is used in the item category, the billing quantity 'F' is used in copying control. Or in delivery-related billing, if the item category has billing relevance 'A' then in copying control the indicator PLMIN '+' must be used, if, for example, the billing type uses the sales document category 'M'.

SDCHECKVOFA:- Customizing check: Billing types

The following settings are checked in the report:

1) Proforma billing types: If it is a proforma billing type, (VBTYP = U), the field must be blank and the account determination procedure must be empty.

2) Cancellation billing document types: : A check is made to see if the cancellation billing document type has the right VBTYP. An F2 invoice, for example, (VBTYP 'M') can only be canceled with billing type S1 with VBTYP 'N' . A billing type with VBTYP '5' can only be canceled with the VBTYP '6' and vice versa.

3) Cancellation billing document type partner functions A check is made to see if the cancellation billing document type partner functions are empty or if those that correspond to the billing type used are empty.

REA_BILL_CUSTOM_DATA_CHECK:- Mass Check of Customizing Billing Data

Basically this report allows a mass check of all Customizing for billing and the following objects are checked:

1:- Rates

2:- Rate determinations

3:- Billing schemas

4:- The report generates statistics of how many objects were checked and how many of them are inconsistent. The log contains the statistics and the reasons for the errors. The log is then saved and can be displayed subsequently using transaction SLG1.

RV61A_ANALYSEREPORTS_PRICING:- Program Selection of Pricing Analysis Tool

Very interesting report for pricing which can be used for many analysis for pricing related to Sales Document!

SDVBUK00:- New Determination of Sales Document Status

This report recalculates the status of selected sales documents and displays changes and any errors in a report. You can select sales document numbers on a selection screen and enter whether the program should run in display or change mode. Database modifications can only be implemented in change mode. Output: - Report containing the changes of status for orders and items as well as any errors.

CHECK_CM:- Credit Management Analysis of SD document

This is very powerful report which can leverage to analyses credit management check for SD document where this is provision to see the type of credit check applied. Along with type of credit check, key fields like Credit control Area, Risk Category and Credit Group are highlighted.  In the output, we get provision to check the exact control like Maximum Document Value, Critical Fields, Next Inspection Date, and Open Items due to which credit block has happened. Last but not the least, details of Info structure - S066 or S067 is available to which document impacts.

RVKRED08:- Credit check on sales orders that reach the credit horizon

The report checks all sales documents that belong to the horizon of the dynamic credit check again. The period of the 'date of the next credit check' is proposed from today's date using the period split of the open sales order values. You should start the report for each period at the beginning of the period.

SDVBFA01/SDVBFA03:- Create Document Flow

This program corrects errors in document flow. The system not only records document flow of sales documents, deliveries and billing documents for the previous document but rather for all previous documents. Occasionally, records are missing in the multi-level update. When, for instance, a credit memo is billed which refers to a billing document and this billing document in turn refers to an order for which there is a quotation, the document flow of the credit memo billing document is not recorded for the quotation.

SDRQCR21:- Recovery of Sales and Delivery Requirements

This report essentially helps to correct inconsistency between sales order/delivery already completed/deleted but it still visible in MD04 transaction.

SDVPRSUPDATE: - Correction report VPRS and Transfer Prices

Thanks,

Sarthak

Dear All,

In recent times SAP is continuously enhancing SAP Transportation Management

As many of us know that Transportation is integral part of SAP R/3  as LE-Transportation for shipment and cost calculation. Later SAP came up with some advancement in terms of Advance planner and Optimizer. During 2009 SAP TM emerged as Stand Alone system supporting Service providers such as DHL , LINFOX . By adding shipper business process TM now supports AIR, OCEAN and Land transportation

Now as part of Knowledge sharing, i would like to share the integration between SAP R/3  SD (Sales orders , Deliveries) and SAP TM

SAP ERP integrates with SAP TM mostly in shippers business process where all the Transportation planning and execution phases is handled by SHIPPER ( manufacturer)

Business process:

Let's assume, customer places an order with the company for a material which has to be delivered to his site. As part of Sales order process we create Sales order in R/3. Now the order has to be integrated to the SAP TM system to initiate the Transportation process for arranging transportation and execution

Now our concentration here is about how R/3 order is integrated to SAP TM and what are the prerequisites from SD stand point

Basic settings in SAP SD

we have a integration configuration inbuilt in R/3 to transfer Sales order , Deliveries and Purchase orders to support both inbound and outbound transportation process

Path:

SPRO-->INTEGRATION OF R/3 WITH OTHER COMPONENTS-->TRANSPORTATION MANAGEMENT-->ORDER INTEGRATION

1. Control Key:

This is the activity where we define which documents are required to be integrated to SAP TM. Here we have options such as Sales orders, Deliveries, Purchase order. We can choose one among them or combination of them to transfer to SAP TM.

2. Activate Sales documents

This is the activity where we assign required sales area, along with Sales document type and Shipping conditions. This way we are controlling the document types which are required to be transported. For example if we want only outbound Sales orders to be transported and not Return sales orders to be transported, in this activity we can control

3. Activate Delivery documents

As we activated Sales order, similar way we can also activate transfer of Delivery documents to SAP TM. This setting has to be activated specific to SHIPPING POINT & DELIVERY TYPE along with the CONTROL KEY

4. Activate for Purchase order

This step is required if we need to activate Purchase orders or Stock transfer order to be transferred to SAP TM

We can activate PO documents in combination with PURCHASE ORGANIZATION, PURCHASE GROUP , PO TYPE & CONTROL KEY

Transaction flow

1. Create Sales Order

Create a sales order in VA01 as normal process

2. with all the above integration in place system will create Transportation Requirement in TM which will be used for Planning and execution of Transportation of Physical goods. As part of planning in SAP TM system will populate realistic transportation dates and resource scheduling. Upon which we can plan Delivery in SAP R/3

Due to some integration Error, i could not able to put the document flow. I will update that As soon as possible