What is Transfer Order
Content
• What is transfer order? A transfer order is a document used in the Warehouse Management (WM) system that contains all the information needed to carry out the physical movement of material into the warehouse, out of the warehouse or from one storage bin to another within the warehouse. A transfer requirement contains information about a planned movement of stock in the warehouse. The corresponding transfer order contains the information the system needs to carry out the movement, that is, the physical movement of a specific quantity of material from one place to another. Goods are placed into a storage bin, removed from a storage bin, or transferred from one storage bin to another within the warehouse using transfer orders. Transfer orders are also used to track the logical transfers of stock. Logical transfers of stock occur, for example, when goods are released from inspection and made available for general use. These logical transfers are called posting changes in WM. Confirming Transfer Orders You can set up your system to require that certain stock movements are subject to confirmation. When you confirm a transfer order, you inform the system that it has been processed and that the goods have arrived at the intended destination. Depending on the movement type, not all transfer orders must be confirmed. Generally, this setting is meaningful when a transfer order is created prior to the physical transfer and the movement needs to be verified. For more information, see Confirming Transfer Orders. Confirming Transfer Orders with a Difference If the planned quantity (target quantity) differs from the actual quantity of stock that is moved, a difference quantity exists. When you confirm a transfer order with a difference, you must enter the actual quantity and/or the difference quantity into the system. The difference quantity is then posted automatically to an "interim storage area for differences" (see Confirming Transfer Orders and Stock Differences). Cancelling Transfer Orders You can cancel an entire transfer order or individual items in a transfer order. Cancellation is only possible if the transfer order (or item) has not yet been confirmed. If a transfer order has already been confirmed, you can restore the original stock situation by creating a new transfer order. Control and Monitoring Once they have been carried out, transfer orders also have a control and monitoring function since they document movements in the warehouse (see Warehouse Controlling). Transfer Orders as Inventory Documents For certain inventory methods (for example, zero stock check, inventory based on stock placement), transfer orders serve as inventory documents. In this case, when the actual quantity is confirmed (after the first putaway into a storage bin), it is updated in the system as the inventory quantity. Transfer Orders used in Lean WM In Lean WM, you create and confirm transfer orders for deliveries to pick stock from fixed bins in the warehouse that are not managed by the WM system. Stock that is handled using these transfer orders has no quant numbers since these bins are not managed by WM (see Using a Transfer Order as a Pick Order in Lean WM).
General Information about Creating Transfer Orders It is possible for you to create a transfer order without referring to any other document. However, you typically create transfer orders by referring to another source document from WM or from other SAP application components. A source document can be a •
Transfer requirement
•
Delivery document
•
Material document
•
Posting change notice
When you create a transfer order manually, either from a source document or without a reference document, you normally use the tasks available from the Transfer order creation menu. From within the display tasks for transfer requirements you can access the tasks to create a transfer order. Within the display tasks, you can select as many source documents as you want and then create all the transfer orders for these documents at one time. You can also group transfer requirements together under a single group number and create transfer orders from this group (see Posting a Goods Receipt Based on a Purchase Order). For information about creating transfer orders based on posting change notices, see Stock Transfers and Replenishment. Tabstrips and Table Controls Tabstrips (tabs) and table controls have been included in most screens to improve the flexibility and ease of use of the corresponding functions. The use of tabs separates the data on each of the screens into separate "folders" (similar to card index
files) that logically organize the data into active work lists, inactive or inaccessible data and processed data. The table controls make it possible for you to organize and display only the fields you want to see on the screen and, in some cases, to sort available data into the desired order for processing. Before using these screens regularly, you need to ensure that the fields you want to see are actually displayed and deactivate the ones you do not want in the display. Pushbuttons On most screens, icons have been added as pushbuttons at the bottom of the screen. You use all of these buttons (such as Select/Deselect all, Delete or Sort) to manipulate the data in the tab lists and tables with table controls located immediately above those buttons. For the screens that use these buttons, the following applies: Select all
Selects all entries in the above table
Deselect all
Deselects all entries that are marked
Trashcan
Deletes all entries in open entry fields for the marked lines
Sort up
Sorts all items in the selected column in ascending order
Sort down
Sorts items in the selected column in descending order
Active
Moves selected items from inactive folder to active work list.
Inactive
Moves selected items from active work list to inactive folder
Fields on Transfer Order Creation Screens When you create transfer orders manually or when manual intervention is required, some fields are open for data entry and others cannot be changed. For data which cannot be changed, the fields are shaded. Some fields only appear when they are appropriate for the process (for example, the Batch field only appears during TO creation if a material is managed for batches).
What Information Does a Transfer Order Contain? Transfer orders contain the following information: •
Material number or designator
•
Quantity to be moved
•
Source and destination storage bins
The information that the transfer order needs comes from several sources: •
Material master record
•
Warehouse management movement type
•
Strategies for finding the source or destination storage bins
•
User entries
•
Source documents, such as transfer requirements and deliveries.
How is a Transfer Order Structured? The transfer order consists of a transfer order header, which contains general information about the entire order, and one or more items. Transfer Order Header The transfer order header contains the transfer order number and the date that it was created and confirmed. It also identifies the transfer requirement or delivery on which it is based and the movement type. If the transfer order has been printed, the Trfr order printed field is selected. Transfer Order Item A transfer order can have one or several items. The number of items contained in a transfer order depends on how many storage bins the system accesses in order to reach the total quantity of goods needed for the stock removal requirement or how many bins are needed to store the goods (stock placement). An item within a transfer order contains two or three subsections that indicate the direction of the stock movement. Each item has one source storage bin and one destination bin. An exception to this rule is when more stock is picked from a storage bin
than is needed. In this case, an additional subsection – a return storage bin – exists that identifies the bin to which the remaining quantity is to be returned. •
Source storage bin This subsection contains the source storage bin and the quantity of material that is being transferred. It indicates the storage bin from which goods are to be picked (goods issue) or an interim storage area (such as the goods receipt area) from which goods are taken to be putaway in the warehouse.
•
Destination storage bin This subsection contains the quantity of material that is being transferred and the storage bin into which the goods are to be placed. For example, it may contain a storage bin in reserve storage that has been selected for a putaway or an interim storage area (the goods issue area) for a stock removal.
•
Return storage bin The system generates a return subsection when a quantity remains after the material needed is removed from a storage bin. This can happen if, for example, when a complete pallet is removed from which only a portion of the stock is picked. In this case, the remaining quantity can either be returned to its original storage bin or transferred to another one.
Process: Transfer order Flow
Objective Transfer an order to a distributor's store.
Description For each order specified by the orders parameter:
•
Transmit a transfer request by calling order transfer or shopping cart transfer policy command (from the Referral Interface TC in the store default contract) depending on the value of the transferMode parameter. Each request should include at least the following information.
•
The OrderId. (This number should be returned with the transfer aknowledgement message.)
•
The DistinguishedName of the Organization of the Order, if any. (Normally, this is the parent Organization of the Order creator at the time the Order was created.)
•
Authentication information, such as a userid and password if required by the transfer policy method.
•
The currency of the Order.
•
The payment information such as payment method, payment device, expiry date if transferring a purchase order.
•
For each OrderItem in the Order, include the following information:
•
- The OrderItemId.
•
- The memberId and partNumber of the SpecifiedItem.
•
- The supplierPartNumber and supplierData, if known.
•
- The neededQuantity multiplied by the BaseItem.quantityMultiple.
•
- The externalUOMCode mapped from the QuantityUnit of the BaseItem of the SpecifiedItem.
•
- The comments attribute of the OrderItem.
•
- Shipping Address information.
•
Update order status to 'F'.
Features •
Transfer an order to an external system
Customization •
Integration with back-end systems
•
Support for different transfer modes or additional options in the Referral TC.
Edition Professional, Business Edition
Subprocesses •
Update order status
Tasks Task Confirm order transfer
Description Confirm that the order that was transferred has been received and that the order is pending remote processing.
Role
Distributor
Send order Send order status as appropriate based on the status (external) processing of the order by the distributor.
Distributor
Transfer order
System
Transfer the order to the distributor's store.
What are the fields in pricing procedure ? Define Pricing Procedure •
Select the pricing procedure which is the standard and copy it and create our own pricing procedure.
•
Highlight it and double click the Control icon in the LHS screen.
•
We can see that there are 16 columns in the pricing procedure, these are going to be used by the system to control the condition types.
• Step:
The detail description of each column is given below.
•
Number that determines the sequence of the conditions with in a procedure.
•
It indicates the position of the condition type in pricing procedure.
•
Ex.: 10, 15 etc.
Counter:
•
System uses the counter to count the steps and also it can be used to count mini steps of same condition types. So that number of steps can be reduced in the pricing procedure and hence enhancing the system performance.
•
Access number of the conditions with in a step in the pricing procedure.
•
During automatic pricing, the system takes into account the sequence specified by the counter.
Condition Type: •
It represents pricing element in pricing procedure as a base price, discount, freight and tax.
•
The condition type is used for different functions. In pricing, for example, the condition type lets you differentiate between different kinds of discount; in output determination, between different output types such as order confirmation or delivery note; in batch determination, between different strategy types.
•
Ex.: PR00 - Price
K004 - Material Discount K005 - Customer/Material Discount K007 - Customer Discount. Description:
•
System copies description of condition type from its description (V/06).
From and To: 1. From: This can be used as a base to the condition type for calculating further value. 2. From and To: The range between the steps from and to can be used to specify the range between same condition types. So that depending upon the condition type, the system deducts or adds the total value of those condition types from specific common source. Manual: •
This indicator specifies whether the specific condition type can be determined manually during sales order processing.
•
If we check the box then the entry is going to be manual, if we uncheck it, it is going to be automatic.
•
For Base Price and Taxes, the entry should be automatic.
•
For Discounts and Freights, The entry should be manual.
•
If we check the box, in VA01 when we go to conditions at the header/item level, the condition type will not be listed. If we require we will have to manually enter it.
•
If we uncheck the box, in VA01 when we go to conditions at the header/item level, the condition type will be listed.
Mandatory:
•
This indicator specifies that particular condition type is mandatory in the pricing procedure.
•
If we check the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the condition type and try to save the document then system will not allow us to do it and throws an error.
•
If we uncheck the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the condition type and try to save the document then system will allow us to save it, without giving any error.
•
Mandatory check box should be checked in condition types which are compulsorily required in pricing procedure. Ex.: PR00, MWST.
•
If the condition type is checked with mandatory option, then value should be maintained for that condition type, otherwise the system will not allow the user to process the document.
Statistical: •
This indicator if it is activated will not allow the value of the condition type to be taken into net value calculation.
•
It is used only for information purposes only.
•
This indicator causes a surcharge or discount to be set in the document statistically (that is, without altering the value).
•
This is commonly used for condition types
○
SKTO - Cash Discount
○
VPRS - Cost (Moving average price/Standard Price).
Print:
•
The value of this field specifies whether line item can be printed or not in the sales document and at what level it is to be printed.
Subtotal: •
The value of this field determines where the values of subtotals to be captured i.e. in which table and which field.
•
Controls whether and in which fields condition amounts or subtotals (for example, a customer discount or the cost of a material) are stored.
•
If the same fields are used to store different condition amounts, the system totals the individual amounts.
•
These condition amounts or subtotals are used as a starting point for further calculations. You may, for example, want a subtotal of all the discounts included in the pricing of a sales order.
Requirement:
•
It is a routine that is written by an ABAP consultant according to the business requirement.
•
By defining Requirement in condition technique we can restrict the access of condition type.
•
To understand the concept, we will take the example of the Rebates. Rebates are to be included during the billing document processing and not in the sales document processing. As rebates are given on the delivered quantity and not on the ordered quantity (in case of cut-off period for rebates).
•
For rebates we use the condition types BO01 to BO05, and in the Requirement column we give the value 24 which is "Only in Billing Document".
•
This Requirement will ensure that these condition types will appear only during the billing document processing.
•
If new Requirements are to be defined we follow the procedure given below.
○
Go to T.Code: VOFM. - Maintain Requirements & Formulas
○
Click on the "Requirements" in the top menu and then click on "pricing".
○
We have a list of requirements, we can ask ABAP consultant to create new requirement based on the client requests.
○
And we assign the application type like V - Sales/Distribution etc.
AltCty - Condition formula for alternative calculation type:
•
It is again a Routine that is written by ABAP Consultant.
•
It is an alternative formula for the condition type that can be used instead of standard formulas.
•
For example, let us take the Profit Margin which can be both + / - , so here this routine will help us in generating the value which can be either + or -. Profit margin is not a condition type so it cannot be classified as +ve or -ve in the V/06.
•
Ex.: 950 0 Profit Margin 11.
•
So we assign 11 - Profit Margin.
•
If new routines are to be defined we follow the procedure given below.
○
Go to T.Code: VOFM. - Maintain Requirements & Formulas
•
○
Click on the "Formulas" and then on the "Condition Values".
○
We have a list of routines, we can ask ABAP consultant to create new routines based on the client requests.
○
And we assign the application type.
AltCBV - Alternative formula for condition base value:
•
Formula for determining the condition basis as an alternative to the standard.
•
It is again a Routine that is written by ABAP Consultant.
•
It is used as a basis to calculate value of the condition type instead of using it from the "FROM" column.
•
Ex.: Freight - KF00.
•
Freight is calculated based on weight, volume etc. and not on the base price. In pricing there is no entry of weight from which the value can be referred like we do for discounts using base price. We have to get the value from the Material master.
•
In this column we can mention the value as 12 - Gross Weight or 13 - Net Weight.
•
During pricing, the system will consider the value that is mentioned in this column and determine the freight based on this value.
•
Suppose we have Net weight: 100 kgs and Gross Weight: 150 kgs. And if we mention 13 in this column then the Freight condition KF00 will be calculated using the weight as 100 kgs.
AcyKy - Account Key/ Accrls - Accruals:
•
The values of the Sales Revenues, Sales Deductions, Freight Revenues, Tax Revenues, and Rebate Accruals etc. are going to be posted in the respective G/L accounts in Fi Module.
•
In order to do this we assign account keys/ accruals to the different condition types based on their classification. The classification shown below.
•
○
ERB Rebate sales deduct.
○
ERF Freight revenue
○
ERL Revenue
○
ERS Sales deductions
○
ERU Rebate accruals
For Ex.,
○
For all Price condition types like PR00 etc. we assign ERL - Revenue.
○
For all Discount condition types like K004, K005 etc. we assign ERS - Sales Deductions.
○
For all Freight condition types KF00 etc. we assign ERF - Freight Revenues.
○
For all Rebates condition types BO01 to BO05 we assign in Account key ERB - Rebates Sales deductions and for Accruals ERU - Rebate Accruals.
•
This account keys and accruals are in turn assigned to respective G/L accounts. So the system posts respective values in respective G/L accounts in Fi-Co Module.
•
This also one of the areas of SD - Fi Integration. SD consultants assign the account keys and Fi Consultants assign the respective G/L accounts in T.Code:VKOA
1) What are the Standard output types in SD? Standard Output Types in SD are as under: 1. Sales Order Confirmation: BA00 2. Outbound Delivery Note: LD00 3. Billing Document: RD00 4. Inquiry: AF00 5. Quotation: AN00 6. Contract: KO00
What are the issues u have faced in training ? We can say during the implementation the challenges which we faced are * high expectations from the system * lack IT awareness among employees * End user training * lot of complex business processes wich lead to highly customised product etc..
What is difference between delivery document & scheduling ? A delivery document is similar to the sales order document in that the settings control how a delivery is to be carried out at the highest level and has a delivery item category assigned to it. The SAP System can only copy items of a sales document to a delivery if they have schedule lines. The control of the schedule lines depends on the schedule line category which is determined by the Item Category and MRP type.
Do you mean to ask the difference between delivery doc & delivery scheduling? Delivery doc is the actual delivery that we create in VL01N for the sales order. Delivery scheduling is the process by which system proposes the confirmed delivery date when a sales order is loaded. For eg consider that the customer has placed an order on 8th Sep & requested delivery RDD on 12th. Consider that you have maintained 2 days as transit time, 1 day as loading time & 1 day as pick pack time. Then the system initially carries backward scheduling from the RDD. So from 12th, it will calculate backwards. So your goods should leave your shipping point by 10th, loading should start by 9th, pick pack should start on 8th. System will see is material is
available on 8th. If yes, then it will confirm the requested delivery date RDD. If not, system will check for the material availability date MAD. If MAD is on 10th, then system will do forward scheduling from 10th. So items can be picked by 11th, loading done on 12th & goods will reach customer on 14th (2 days transit). So confirmed delivery date is 14th. System will propose this date as delivery date in shipping view of sales order main screen. This process is called delivery scheduling. What's the difference between schedulling agreement with normal order? What's the condition for us to choose schedule line or order? Both of them contains schedule line, price, quantity. There are a couple major differences: (1) - Schedule agreements allow you to have 2 different sets of schedule lines (VBEP-ABART). Standard SAP you should have two sets of tabs - of schedule lines. One Forecast & the other JIT. Forecast forwards the schedule lines to planning (seen in MD04) and JIT passes them to shipping (VL10). They can be identical or different. Typically these are used for component supplier customers (namely Automotive). The customer will provide you 4-10 weekly buckets (usually a Monday date) of future forecast qtys. Also send you 1-2 weeks of individual FIRM ship dates - which are entered on the JIT. It comes down to the customer not knowing exactly what they need next week, but they don't want to suprise you with a large order qty, where your lead times are 5+ days. The forecasted qtys they sent last week should account for this. (2) Cumulative Quantities are tracked and influence how the schedule agreement passes requirements to both forecasting and shipping. These qtys are sometimes requested by the customer on ASNs. Cumulative qtys reset at year end unless you've got a customer calendar or you've modified standard SAP userexits to not reset. Schedule agreements are very nice when the customer sends EDI data (830s = forecast or 862s = JITs). Outside of that they can really cause trouble regarding daily maintenance, missing requirements, cum qty corrections, year end processing, etc. One alternative would be to use customer independent requirements - entering the weekly, monthly forecasting qtys and entering standard sales orders (with or without multiple schedule lines) to represent the true firm qtys.
How is item category determined ? Item category is determined based on the following rule Sales doc. type + item cat. grp + Usage + Higher level item category + Default item category In this rule usage + higher level item cat will applicable @ Free goods / bill of materials. But where as sales doc. type + item cat. grp = ( or + NORM ) based on this two parameters default item category TAN will determine based on IMG configuration. Where as ( Usage + Higher level item cat ) means Usage = free ( R100 = 100 % discount ) higher level item cat. ( Main item or std item ) as TAN With all this usage rule is as follows: OR + NORM + TAN = MAIN ITEM OR + NORM + FREE + TAN + TANN = FREE ITEMS
• What is Extract used in condition tech. in pricing? In pricing the condition technique refgeres to the method by which the system determine prices from information stored in condition records in sales and distribution. During sales document processing the system uses the
condition thechnice to determine a variety of important prices information
General Information about Creating Transfer Orders It is possible for you to create a transfer order without referring to any other document. However, you typically create transfer orders by referring to another source document from WM or from other SAP application components. A source document can be a •
Transfer requirement
•
Delivery document
•
Material document
•
Posting change notice
When you create a transfer order manually, either from a source document or without a reference document, you normally use the tasks available from the Transfer order creation menu. From within the display tasks for transfer requirements you can access the tasks to create a transfer order. Within the display tasks, you can select as many source documents as you want and then create all the transfer orders for these documents at one time. You can also group transfer requirements together under a single group number and create transfer orders from this group (see Posting a Goods Receipt Based on a Purchase Order). For information about creating transfer orders based on posting change notices, see Stock Transfers and Replenishment. Tabstrips and Table Controls Tabstrips (tabs) and table controls have been included in most screens to improve the flexibility and ease of use of the corresponding functions. The use of tabs separates the data on each of the screens into separate "folders" (similar to card index
files) that logically organize the data into active work lists, inactive or inaccessible data and processed data. The table controls make it possible for you to organize and display only the fields you want to see on the screen and, in some cases, to sort available data into the desired order for processing. Before using these screens regularly, you need to ensure that the fields you want to see are actually displayed and deactivate the ones you do not want in the display. Pushbuttons On most screens, icons have been added as pushbuttons at the bottom of the screen. You use all of these buttons (such as Select/Deselect all, Delete or Sort) to manipulate the data in the tab lists and tables with table controls located immediately above those buttons. For the screens that use these buttons, the following applies: Select all
Selects all entries in the above table
Deselect all
Deselects all entries that are marked
Trashcan
Deletes all entries in open entry fields for the marked lines
Sort up
Sorts all items in the selected column in ascending order
Sort down
Sorts items in the selected column in descending order
Active
Moves selected items from inactive folder to active work list.
Inactive
Moves selected items from active work list to inactive folder
Fields on Transfer Order Creation Screens When you create transfer orders manually or when manual intervention is required, some fields are open for data entry and others cannot be changed. For data which cannot be changed, the fields are shaded. Some fields only appear when they are appropriate for the process (for example, the Batch field only appears during TO creation if a material is managed for batches).
What Information Does a Transfer Order Contain? Transfer orders contain the following information: •
Material number or designator
•
Quantity to be moved
•
Source and destination storage bins
The information that the transfer order needs comes from several sources: •
Material master record
•
Warehouse management movement type
•
Strategies for finding the source or destination storage bins
•
User entries
•
Source documents, such as transfer requirements and deliveries.
How is a Transfer Order Structured? The transfer order consists of a transfer order header, which contains general information about the entire order, and one or more items. Transfer Order Header The transfer order header contains the transfer order number and the date that it was created and confirmed. It also identifies the transfer requirement or delivery on which it is based and the movement type. If the transfer order has been printed, the Trfr order printed field is selected. Transfer Order Item A transfer order can have one or several items. The number of items contained in a transfer order depends on how many storage bins the system accesses in order to reach the total quantity of goods needed for the stock removal requirement or how many bins are needed to store the goods (stock placement). An item within a transfer order contains two or three subsections that indicate the direction of the stock movement. Each item has one source storage bin and one destination bin. An exception to this rule is when more stock is picked from a storage bin
than is needed. In this case, an additional subsection – a return storage bin – exists that identifies the bin to which the remaining quantity is to be returned. •
Source storage bin This subsection contains the source storage bin and the quantity of material that is being transferred. It indicates the storage bin from which goods are to be picked (goods issue) or an interim storage area (such as the goods receipt area) from which goods are taken to be putaway in the warehouse.
•
Destination storage bin This subsection contains the quantity of material that is being transferred and the storage bin into which the goods are to be placed. For example, it may contain a storage bin in reserve storage that has been selected for a putaway or an interim storage area (the goods issue area) for a stock removal.
•
Return storage bin The system generates a return subsection when a quantity remains after the material needed is removed from a storage bin. This can happen if, for example, when a complete pallet is removed from which only a portion of the stock is picked. In this case, the remaining quantity can either be returned to its original storage bin or transferred to another one.
Process: Transfer order Flow
Objective Transfer an order to a distributor's store.
Description For each order specified by the orders parameter:
•
Transmit a transfer request by calling order transfer or shopping cart transfer policy command (from the Referral Interface TC in the store default contract) depending on the value of the transferMode parameter. Each request should include at least the following information.
•
The OrderId. (This number should be returned with the transfer aknowledgement message.)
•
The DistinguishedName of the Organization of the Order, if any. (Normally, this is the parent Organization of the Order creator at the time the Order was created.)
•
Authentication information, such as a userid and password if required by the transfer policy method.
•
The currency of the Order.
•
The payment information such as payment method, payment device, expiry date if transferring a purchase order.
•
For each OrderItem in the Order, include the following information:
•
- The OrderItemId.
•
- The memberId and partNumber of the SpecifiedItem.
•
- The supplierPartNumber and supplierData, if known.
•
- The neededQuantity multiplied by the BaseItem.quantityMultiple.
•
- The externalUOMCode mapped from the QuantityUnit of the BaseItem of the SpecifiedItem.
•
- The comments attribute of the OrderItem.
•
- Shipping Address information.
•
Update order status to 'F'.
Features •
Transfer an order to an external system
Customization •
Integration with back-end systems
•
Support for different transfer modes or additional options in the Referral TC.
Edition Professional, Business Edition
Subprocesses •
Update order status
Tasks Task Confirm order transfer
Description Confirm that the order that was transferred has been received and that the order is pending remote processing.
Role
Distributor
Send order Send order status as appropriate based on the status (external) processing of the order by the distributor.
Distributor
Transfer order
System
Transfer the order to the distributor's store.
What are the fields in pricing procedure ? Define Pricing Procedure •
Select the pricing procedure which is the standard and copy it and create our own pricing procedure.
•
Highlight it and double click the Control icon in the LHS screen.
•
We can see that there are 16 columns in the pricing procedure, these are going to be used by the system to control the condition types.
• Step:
The detail description of each column is given below.
•
Number that determines the sequence of the conditions with in a procedure.
•
It indicates the position of the condition type in pricing procedure.
•
Ex.: 10, 15 etc.
Counter:
•
System uses the counter to count the steps and also it can be used to count mini steps of same condition types. So that number of steps can be reduced in the pricing procedure and hence enhancing the system performance.
•
Access number of the conditions with in a step in the pricing procedure.
•
During automatic pricing, the system takes into account the sequence specified by the counter.
Condition Type: •
It represents pricing element in pricing procedure as a base price, discount, freight and tax.
•
The condition type is used for different functions. In pricing, for example, the condition type lets you differentiate between different kinds of discount; in output determination, between different output types such as order confirmation or delivery note; in batch determination, between different strategy types.
•
Ex.: PR00 - Price
K004 - Material Discount K005 - Customer/Material Discount K007 - Customer Discount. Description:
•
System copies description of condition type from its description (V/06).
From and To: 1. From: This can be used as a base to the condition type for calculating further value. 2. From and To: The range between the steps from and to can be used to specify the range between same condition types. So that depending upon the condition type, the system deducts or adds the total value of those condition types from specific common source. Manual: •
This indicator specifies whether the specific condition type can be determined manually during sales order processing.
•
If we check the box then the entry is going to be manual, if we uncheck it, it is going to be automatic.
•
For Base Price and Taxes, the entry should be automatic.
•
For Discounts and Freights, The entry should be manual.
•
If we check the box, in VA01 when we go to conditions at the header/item level, the condition type will not be listed. If we require we will have to manually enter it.
•
If we uncheck the box, in VA01 when we go to conditions at the header/item level, the condition type will be listed.
Mandatory:
•
This indicator specifies that particular condition type is mandatory in the pricing procedure.
•
If we check the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the condition type and try to save the document then system will not allow us to do it and throws an error.
•
If we uncheck the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the condition type and try to save the document then system will allow us to save it, without giving any error.
•
Mandatory check box should be checked in condition types which are compulsorily required in pricing procedure. Ex.: PR00, MWST.
•
If the condition type is checked with mandatory option, then value should be maintained for that condition type, otherwise the system will not allow the user to process the document.
Statistical: •
This indicator if it is activated will not allow the value of the condition type to be taken into net value calculation.
•
It is used only for information purposes only.
•
This indicator causes a surcharge or discount to be set in the document statistically (that is, without altering the value).
•
This is commonly used for condition types
○
SKTO - Cash Discount
○
VPRS - Cost (Moving average price/Standard Price).
Print:
•
The value of this field specifies whether line item can be printed or not in the sales document and at what level it is to be printed.
Subtotal: •
The value of this field determines where the values of subtotals to be captured i.e. in which table and which field.
•
Controls whether and in which fields condition amounts or subtotals (for example, a customer discount or the cost of a material) are stored.
•
If the same fields are used to store different condition amounts, the system totals the individual amounts.
•
These condition amounts or subtotals are used as a starting point for further calculations. You may, for example, want a subtotal of all the discounts included in the pricing of a sales order.
Requirement:
•
It is a routine that is written by an ABAP consultant according to the business requirement.
•
By defining Requirement in condition technique we can restrict the access of condition type.
•
To understand the concept, we will take the example of the Rebates. Rebates are to be included during the billing document processing and not in the sales document processing. As rebates are given on the delivered quantity and not on the ordered quantity (in case of cut-off period for rebates).
•
For rebates we use the condition types BO01 to BO05, and in the Requirement column we give the value 24 which is "Only in Billing Document".
•
This Requirement will ensure that these condition types will appear only during the billing document processing.
•
If new Requirements are to be defined we follow the procedure given below.
○
Go to T.Code: VOFM. - Maintain Requirements & Formulas
○
Click on the "Requirements" in the top menu and then click on "pricing".
○
We have a list of requirements, we can ask ABAP consultant to create new requirement based on the client requests.
○
And we assign the application type like V - Sales/Distribution etc.
AltCty - Condition formula for alternative calculation type:
•
It is again a Routine that is written by ABAP Consultant.
•
It is an alternative formula for the condition type that can be used instead of standard formulas.
•
For example, let us take the Profit Margin which can be both + / - , so here this routine will help us in generating the value which can be either + or -. Profit margin is not a condition type so it cannot be classified as +ve or -ve in the V/06.
•
Ex.: 950 0 Profit Margin 11.
•
So we assign 11 - Profit Margin.
•
If new routines are to be defined we follow the procedure given below.
○
Go to T.Code: VOFM. - Maintain Requirements & Formulas
•
○
Click on the "Formulas" and then on the "Condition Values".
○
We have a list of routines, we can ask ABAP consultant to create new routines based on the client requests.
○
And we assign the application type.
AltCBV - Alternative formula for condition base value:
•
Formula for determining the condition basis as an alternative to the standard.
•
It is again a Routine that is written by ABAP Consultant.
•
It is used as a basis to calculate value of the condition type instead of using it from the "FROM" column.
•
Ex.: Freight - KF00.
•
Freight is calculated based on weight, volume etc. and not on the base price. In pricing there is no entry of weight from which the value can be referred like we do for discounts using base price. We have to get the value from the Material master.
•
In this column we can mention the value as 12 - Gross Weight or 13 - Net Weight.
•
During pricing, the system will consider the value that is mentioned in this column and determine the freight based on this value.
•
Suppose we have Net weight: 100 kgs and Gross Weight: 150 kgs. And if we mention 13 in this column then the Freight condition KF00 will be calculated using the weight as 100 kgs.
AcyKy - Account Key/ Accrls - Accruals:
•
The values of the Sales Revenues, Sales Deductions, Freight Revenues, Tax Revenues, and Rebate Accruals etc. are going to be posted in the respective G/L accounts in Fi Module.
•
In order to do this we assign account keys/ accruals to the different condition types based on their classification. The classification shown below.
•
○
ERB Rebate sales deduct.
○
ERF Freight revenue
○
ERL Revenue
○
ERS Sales deductions
○
ERU Rebate accruals
For Ex.,
○
For all Price condition types like PR00 etc. we assign ERL - Revenue.
○
For all Discount condition types like K004, K005 etc. we assign ERS - Sales Deductions.
○
For all Freight condition types KF00 etc. we assign ERF - Freight Revenues.
○
For all Rebates condition types BO01 to BO05 we assign in Account key ERB - Rebates Sales deductions and for Accruals ERU - Rebate Accruals.
•
This account keys and accruals are in turn assigned to respective G/L accounts. So the system posts respective values in respective G/L accounts in Fi-Co Module.
•
This also one of the areas of SD - Fi Integration. SD consultants assign the account keys and Fi Consultants assign the respective G/L accounts in T.Code:VKOA
1) What are the Standard output types in SD? Standard Output Types in SD are as under: 1. Sales Order Confirmation: BA00 2. Outbound Delivery Note: LD00 3. Billing Document: RD00 4. Inquiry: AF00 5. Quotation: AN00 6. Contract: KO00
What are the issues u have faced in training ? We can say during the implementation the challenges which we faced are * high expectations from the system * lack IT awareness among employees * End user training * lot of complex business processes wich lead to highly customised product etc..
What is difference between delivery document & scheduling ? A delivery document is similar to the sales order document in that the settings control how a delivery is to be carried out at the highest level and has a delivery item category assigned to it. The SAP System can only copy items of a sales document to a delivery if they have schedule lines. The control of the schedule lines depends on the schedule line category which is determined by the Item Category and MRP type.
Do you mean to ask the difference between delivery doc & delivery scheduling? Delivery doc is the actual delivery that we create in VL01N for the sales order. Delivery scheduling is the process by which system proposes the confirmed delivery date when a sales order is loaded. For eg consider that the customer has placed an order on 8th Sep & requested delivery RDD on 12th. Consider that you have maintained 2 days as transit time, 1 day as loading time & 1 day as pick pack time. Then the system initially carries backward scheduling from the RDD. So from 12th, it will calculate backwards. So your goods should leave your shipping point by 10th, loading should start by 9th, pick pack should start on 8th. System will see is material is
available on 8th. If yes, then it will confirm the requested delivery date RDD. If not, system will check for the material availability date MAD. If MAD is on 10th, then system will do forward scheduling from 10th. So items can be picked by 11th, loading done on 12th & goods will reach customer on 14th (2 days transit). So confirmed delivery date is 14th. System will propose this date as delivery date in shipping view of sales order main screen. This process is called delivery scheduling. What's the difference between schedulling agreement with normal order? What's the condition for us to choose schedule line or order? Both of them contains schedule line, price, quantity. There are a couple major differences: (1) - Schedule agreements allow you to have 2 different sets of schedule lines (VBEP-ABART). Standard SAP you should have two sets of tabs - of schedule lines. One Forecast & the other JIT. Forecast forwards the schedule lines to planning (seen in MD04) and JIT passes them to shipping (VL10). They can be identical or different. Typically these are used for component supplier customers (namely Automotive). The customer will provide you 4-10 weekly buckets (usually a Monday date) of future forecast qtys. Also send you 1-2 weeks of individual FIRM ship dates - which are entered on the JIT. It comes down to the customer not knowing exactly what they need next week, but they don't want to suprise you with a large order qty, where your lead times are 5+ days. The forecasted qtys they sent last week should account for this. (2) Cumulative Quantities are tracked and influence how the schedule agreement passes requirements to both forecasting and shipping. These qtys are sometimes requested by the customer on ASNs. Cumulative qtys reset at year end unless you've got a customer calendar or you've modified standard SAP userexits to not reset. Schedule agreements are very nice when the customer sends EDI data (830s = forecast or 862s = JITs). Outside of that they can really cause trouble regarding daily maintenance, missing requirements, cum qty corrections, year end processing, etc. One alternative would be to use customer independent requirements - entering the weekly, monthly forecasting qtys and entering standard sales orders (with or without multiple schedule lines) to represent the true firm qtys.
How is item category determined ? Item category is determined based on the following rule Sales doc. type + item cat. grp + Usage + Higher level item category + Default item category In this rule usage + higher level item cat will applicable @ Free goods / bill of materials. But where as sales doc. type + item cat. grp = ( or + NORM ) based on this two parameters default item category TAN will determine based on IMG configuration. Where as ( Usage + Higher level item cat ) means Usage = free ( R100 = 100 % discount ) higher level item cat. ( Main item or std item ) as TAN With all this usage rule is as follows: OR + NORM + TAN = MAIN ITEM OR + NORM + FREE + TAN + TANN = FREE ITEMS
• What is Extract used in condition tech. in pricing? In pricing the condition technique refgeres to the method by which the system determine prices from information stored in condition records in sales and distribution. During sales document processing the system uses the
condition thechnice to determine a variety of important prices information
