Many things can be approached with simple and direct ways including business and especially business. We have enterprise resource planning, our very own SAP to make business more accountable, less prone to human errors and therefore easier. The integration in SAP is what makes it much sought after, whereas thorough dependencies and good standard reports make it a business savvy product.

Nevertheless, Z-developments attract companies, organizations and individual users to an amazing extent. It can be attributed to business needs, custom requirements of each industry and business vertical; which can definitely be addressed with Z-developments in SAP. And some of them are absolutely essential to allow for uniqueness of a given business and to create value for the users.

  That said I have come across users who do not want to go to multiple transaction codes in standard SAP to create subsequent documents. They expect a single window where many buttons will create multiple documents and the zapping part is that they do not want to see the created document. Well, when SAP was not there, documentation still happened and nobody ever expected not having to see a document they were creating!

The maintenance of these Z-developments is time-consuming and expensive to say the least. Imagine the scale of expenses both operational & financial on both sides of business. Each time there is a change in personnel; huge time has to be spent on training and user ease for these multitasking Z-developments. Each time a new business scenario is mapped in the system, apart from standard configuration and Z-screen; ten other Z-reports have to be revamped to accommodate data from new scenario. While it seems good business for consulting, there is no actual consulting involved where simply individual user wants are accommodated, with no regard to overall business & core activities which the software was intended to support.

ERP must be used to simplify & standardize business documentation while allowing for focus on core business competencies and the same must be the goal of consulting & consultants. The whole idea is to not forget the underlying simplicity of processes & maintenance while looking at the overall complexity which is but a result of various simple processes linked together to create something of more value.

***

Number of customers may run in to tens of thousands in certain industry verticals like retail of various consumer products. It is very tedious not to mention time-consuming to maintain master data for each customer. SAP has provision of one time customer which provides good functionality to minimize dependence on permanent master data.

Just like normal customer master creation, you create one-time customer by using account group ‘CPD’ and maintain general data, company code data & ales area data.

When you create a sales order, specify your one-time customer (ID) as sold-to-party and system will prompt to enter new customer details as shown under:

Enter one time customer id & change customer name, address & contact details in pop-up screen and proceed.

Details for one time customer will appear on the sales order. Proceed with sales order

Similarly, we can use one-time customer id and enter new customer details for another sales order.

***

Karuna Ravuri

Access Sequence – Tax Classification:

Whenever, more than one tax condition type (with the table field – “Tax Classification” remaining the same) is involved as part of the pricing procedure then there could be issues in determining the condition records.

Consider the following scenario as an example:

For the material and customer master, we have three tax condition types namely ZIVC, ZIVP, ZIVV (sequentially) maintained under the tax classification. This is based on the OVK3 and OVK4 settings in SPRO.

Now the Tax Classification value that we maintain in the material master / Customer master for the first condition type (ZIVC) is also getting considered for the other two condition types. (IF the table field used is "Tax Classification" for all the  condition types).

In order to avoid this incorrect determination of the tax classification, we need to change the access sequence in such a way that the table field - "Tax Classification" is being used for the First condition type - ZIVC ;  "Tax Classification 2" is being used for the Second condition type - ZIVP and "Tax Classification 3" is being used for the third condition type - ZIVV. In short, the following access sequence has to be followed:

Access Sequence - combination change:

Whenever we are copy standard SAP Sales order/delivery/billing document types/Item and Schedule line categories as per the Business Requirement in SD below standard tables got updated.

Sales document Type(Ex:OR to ZOR)

Item categories: (Ex:TAN to ZTAN)

Schedule line categories:(Ex: CP to ZP)

Delivery Document Type:( LF to ZLF)

Billing Document Types:

I hope it will be helpful to the others.

comments and suggestions are welcome.

Regards,

Krishna.

This is not a simple subject. But it is yet another project very worthwhile doing right. However, it requires people hanging out on the same deck.

Here is my personal take on the topic: First; I believe in making a difference between MTS and MTO! Why? Because if you are planning for it, you should have it and if you make it to a specific request you should not expect your production planner to have it readily available.

Therefore we call the service level for MTS items a 'fill rate'. The MTO performance I call 'Service Level'. It does measure if we can stick to what we promise. Because we can't fill, we have to promise; after the replenishment lead time.

Now that we know that we have to distinguish we can start figuring out how to measure. For MTS products I would simply say that we take the availability checks result. If it found inventory, all is well; if it failed, the fill rate degrades. How can you measure this? Look at the availability check and if the material availability date is the same as todays date you are good, if not, your fill rate declines.

In an MTO scenario you have to work with the total replenishment lead time. There should not be any inventory. Therefore, your service level is good if you adhere to the result of the availability check (which should tell the customer that they can have the product after that time).

Bottom line: make a difference between MTS and MTO when it comes to service level. Standard SAP doesn't really have a good report for this. Global Software Inc. out of Raleigh, NC has a cool solution. But more about that later...

Hello SCN members,

We all have faced the prospect of uploading Sales Documents  into SAP. The  most common approach to do so is via a BDC program. The LSMW recording  cannot be preferred if the order has multiple line items. More so, if the number of line items are not fixed.

In such cases, we can use the Direct Input Program  option in LSMW.  SAP has made available standard Direct Input programs for uploading a variety of Documents, viz Sales Documents,  Material Movement Documents,  Financial Accounting Docs.

In the first step of  LSMW, ie In Object Attributes, select Standard batch / Direct Input Option.

Then  you can select 0090 as  object and 0000 as method,

Automatically  RVINVB10 program gets selected.

Using this Program, you can finish  the remaining regular steps of the LSMW.

In Specify Files step, you will be asked to provide a logical path and a Logical File name.

These can be created in Tcode : FILE.

Double click on the Converted data file and assign the logical Path and Logical File name.

Note: The logical File should have the phuysical file  of the same name as the converted data file (*.lsmw.conv)

Have Created a detailed Document with all steps,  Kindly find the link to the same ,

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

Do share your comments and questions if you have faced any problems with this Direct Input program.

To measure service with SAP software is not a simple task. Mostly because there really isn't a standard report, but also because there are so many factors that play a role in the calculation of a service rating and if these are not all lined up correctly and used properly... then it is nearly impossible to correctly determine if the service was ok or not.

One of the most important decisions to take is the MTO versus MTS one. If an item is designated to be replenish by MTS, the customer order (or stock transport order) has to check for stock and incoming receipts, whereas in an MTO scenario the availability check uses the Total Replenishment Lead Time to determine the confirmed date for delivery. If you don't classify your products by MTO or MTS on a regular basis, you simply can't set a reasonable confirmation date against which you would measure your service. And that will result in an incorrect report.

Another important feature is whether or not you fix dates and quantities in the delivery proposal. I've dealt elaborately with this issue in my video on YouTube http://www.youtube.com/watch?v=TWq_sxJsZ8M&feature=c4-overview&list=UUcNy4oxKL3pwqDNSbN3tvCg and you can see there what happens when you leave the the fixing indicator unchecked and what happens when you do not (broken down into four possibilities for MTO and four for MTS). The video also explains functionality around confirming delivery dates and that leads me to talk about what we should actually measure against...

SAP has created an Add-On tool called the "Service Level Monitor" which measures three KPIs:

- Delivery Service which measures whether or not the requested quantity was delivered in ful on the customer's requested delivery date

- Delivery Ability which measures if the requested quantity was confirmed on the customer's requested delivery date

- Delivery Reliability which measures against the confirmed date and shows what proportions was delivered in full to that date.

These measures work for both MTO and MTS since they go after the confirmed dates. The Delivery Ability then measures how good we produced to a forecast and therefore works well for MTS products. In a way you can also derive a measure for forecast accuracy on that KPI.

It should become obvious now that if the MTS versus MTO decision hasn't been done properly or if the availability check result is not saved correctly, the resulting KPI's and measures are not very meaningful. It is therefore imperative to fix the process first, before you start measuring the result.

SAP offers Add-On tools that can help you with a number of things that aren't available in the standard suite. The MRP Monitor helps you calssify your products for a a segmentation by consumption variability, replenishment lead time and more... so that you can periodically check whether your product should be setup for MTS or MTO. It also helps you set that policy in an automated way...

Once all factors are lined up you can use the Service Level Monitor to evaluate your orders by the three KPIs we discussed before:

feel free to contact me to discuss more....

Business Requirement

Our customer need to transfer project stock(Q) from cross company.

Challenge

But Standard CC STO can not support it, because movement 643&645 do not allow Q stock business.

Question Analysis

1. SAP  EHP5 provides a new solution for cross-company  valuated stock transfer.
2. And SAP provides new delivery types NCCR&NCC2&NCC3 and new movement types  681&683&685 to support the business process.
3. SAP provides three solutions for the Valuated stock transfer.
   1. Plant (1000) -[VL02N:681]-> v.CST (1000) ----------[VLPOD:685 + 101]-------> Plant (0001)
   2. Plant (1000) -[VL02N:681]-> v.CST (1000) -[VLPOD:685+107]-> v.CST (0001) -[MIGO:109]-> Plant (0001)
   3. Plant (1000) ------------------[VL02N:683+107]-> v.CST (0001) -[MIGO:109]-> Plant (0001)

Solutions

1. Active the LOG_MM_SIT business function with SFW5
   1. 
      
2. Check out the cross company configuration, you will find new delivery type ,new  schedule line category   and new movement types.

          3. Check out STO configuration( created new transfer order type  and assign new delivery type to it  )

                    4.Set POD-Relevance Depending on Delivery Item Category &Change customer master da

          5.Test the three business solutions

Plant (1000) -[VL02N:681]-> v.CST (1000) ----------[VLPOD:685 + 101]-------> Plant (0001)

Plant (1000) -[VL02N:681]-> v.CST (1000) -[VLPOD:685+107]-> v.CST (0001) -[MIGO:109]-> Plant (0001)

Plant (1000) ------------------[VL02N:683+107]-> v.CST (0001) -[MIGO:109]-> Plant (0001)

Related links:

http://scn.sap.com/thread/3406017

http://help.sap.com/erp2005_ehp_05/helpdata/en/ee/045184edf24e15928397fc12b6296e/content.htm?frameset=/en/e9/858c53589749e997a12742570b6b91/frameset.htm

Thanks for Vinod's help.

Alex Ding

From shanghai

2013.09.04

Dear Fellows

I have been continuously contributing in SD forums from last year and I have seen many threads about Sales BOM. Sometime users want to modify sales BOM as per their own business scenarios so here I am going to explain how sales BOM helps us to meet different requirements.

Here, I assume that you know how Sales BOM, item category, schedule line category and copy control works in SD process.

If you google with search term "Sales Bom in SAP SD" system will give you a lot of information about standard settings of sales BOM by using item category group ERLA and LUMF. This information can be found on following link.

http://help.sap.com/saphelp_erp2004/helpdata/en/dd/560234545a11d1a7020000e829fd11/content.htm

In standard settings you can control pricing, inventory and delivery related indicator either on main item level or sub item level. If you use ERLA item category group in finished goods material master data, it will control pricing and inventory at header level and sub items will work as text items. For sub item level control you use item category group LUMF.

A very common and easy to understand example which SAP's standard documents have used is sale of a computer. In a computer sale, we sell it with brand name and specification. For instance if we sell a Dell pentium 4 desktop computer, it will have a mouse, keyboard, monitor and speakers but as a whole this is a Dell pentium 4 PC. So we will enter only one material in sale order with material description DELL Pentium 4 Desktop PC and system will determine all compnents automatically.

Sometime we get some requirements which SAP standard item categories and schedule line categories cannot meet. So we need to understand the basic concepts of item categories and schedule line categories and change them to fulfill our requirement. Let me explain with some real business scenarios.

Scenario 1:     In SAP free goods standard settings we can maintain 1 free good material against 1 main item i.e. there is 1:1 combination. We can play with material's quantity but not with number of materials. If we get a requirement from client that if customer buys 5 quantity of material A then he will get 1 quantity of material B then it can be fulfill with standard free goods by maintaining it in VBN1. But if customer will get 1 quantity of material B and 1 quantity of material C on buying 1 quantity of material A then we can get this done by using Sales BOM.The settings for main item and sub item will be as follows. I am assuming that you want to cumulate cost prices of sub items in main item at the time of billing. If you don't want this then simply dont mark the check box in copy control from delivery to billing at item level for cumulate cost. Also maintain BOM for master data in CS01 with usage 5.

Main Item Settings

Standard Shedule line category (CP) is used and Item Category Group in Material master sales view is Z001 which is customized for free goods main item materials. I will be using same material group for other scenarios as well.

Sub Item Setting

Standard Shedule line category (CP) is used and Item Category Group in Material master sales view is NORM.

Item Category Assignment

Here ZMZM is my order type and Z001 is material group which I have maintained only in main item material's sales view field Item category group from material master (MVKE-MTPOS). Here no need to maintain in General item category group (MARA-MTPOS_MARA). ZTS1 is main item and ZTS2 is sub Item.

Scenario 2:     Lets take another example of a split air conditioner. We are selling split air conditioners to customers and producing them in our plant. In split air conditioner Indoor, outdoor and Remote control are three separate materials. We sell split air conditioner in finished goods with capacity and brand name like 1 Ton Samsung AC 2 Ton Mitsubishi AC and we can also sell components individually. So we need to maintain prices at both level header and item. Here we will maintain stock at item level and price at item and header both. If we are selling a whole package of split air conditioner then it will be at header level and if we are selling only one component then there will be individual price of component.

When we are selling a whole package

Main Item

For this You have to use schedule line CT with no movement type and relevant for delivery if you want to use delivery related billing and copy the main item in delivery document. If you dont want to copy it in delivery then you can simply use CD shedule line category for main item but for this you have to use order related billing. It is good to copy main item in delivery just like a text item.

Sub Item

For Sub item we can use CP or CN as per your requirement.  

Item Category Assignment

When we are selling a component

When you will enter compnent material in order, system will determin normal item category TAN and with billing and pricing activated and price will be determined from condition record which you have maintained for it. So you can sell a whole package or component in same order type.

Scenario 3:      If you are dealing with some business process in which you need to maintain multi level BOMs then you can achieve this by changing item category settings of main item and assignment of item categories. I don't have any real business scenario but lets assume we are selling comupters and in our company we are maintaining BOMs for computers and CPU separately. If we are selling a desktop computer then system will explode BOM of Dell 780 Computer in which we have maintained Monitor, CPU, Key Board, Mouse and Speakers materials and for CPU we have another BOM with Mother Board, Power Supply, Hard Drive and Super drive etc. Now when we enter Dell 780 material system will explode two BOMs. Prices will be maintained for Computer (Exluding CPU). For CPU we will maintain seprate price. Stock and deliveries will be maintain at sub item level.From configuration point of view there will two differences from scenario 2.

Main ITem

With this you can sell whole package and also compnents separately.

Note:    

These are some basics and most common business processes and I have shared these just to give you an idea. You can modify them as epr your scenario. It is all about playing with item category and schedule line settings. If you have some other BOM related business scenario or process which you are not able to configure with sales BOM, you can post your scenario in comment and let me help you in that.

There are many other controls like not to change quantity or material of sub items, copy whole package in delivery or allow single items too, creating automatic PR (third party sale) and maintain prices for compnents and whole package etc. I am not going in detail of these as we can find a lot of links in SCN describing these controls.

Value addition comments and suggestions will be highly appriciated. T W if there is any other business scenario or example in your mind please share with me.

Thank$ 

The purpose of this blog post is to show how you can analyze and overcome such a problem.

During condition maintenance a syntax error occurs in the corresponding condition info report, that leads to the problem that the report can not be generated.

Some affected reports: RV13ANAA, RV13ANAB, RV13ANAC, RV13ANAD, RV13ANAE, RV13ANAF, RV13ANAG, RV13AAEA, RV13ANBT, etc...

Steps

1. Enter a condition in transaction VK11 / VK12 / VK13
2. Click on button 'Condition Information'

As a result the following error is shown:

- System error: Report RV13AAEA could not be generated (Message no. VK759)
- Report RV13AAEA has a syntax error (Message no. VK806)

To see which condition table is affected it is necessary to carry out a syntax check in the mentioned report (In this case RV13AAEA).

As you can see the syntax error is caused by the non-existing field KBSTAT in condition table A385.

The problem is usually due to an inconsistency in the access sequence. To get to know which access sequence is assigned to the condition type (8PR0) you need to open transaction V/06.

To see which access of this access sequence uses the condition table A385 you need to open transaction V/07.

The corresponding access (90) contains the field KBSTAT, however this field is not part of the table A385.

This is the root cause of the problem.

Solution

SAP Note 902296describes how such an inconsistency can occur. It provides a source code correction that prevents the system from such an error in the future.

- The incorrect access has to be deleted from the access sequence.
- Then the access sequence has to be saved.
- After these steps you can re enter the previously deleted access with the correct fields.

Make sure you navigate to the field level when entering the new access.

As we know, we have 5 parameter help us to determine batch determination procedure for SD module within SAP system. (for instance : Sales organizaiton/ Distribution channel/ Division/ Sales order document  --  Batch Search procedure)

when we create a STO delivey document, we are referecen puchase order instead of sale order; According the batch search procedure rule, we cannot to use the purchase order document type replace sale order document type as the parameter to determine batch search procedure.

solution:

In this circumstance, we have a concept of default sale document type to solve this situation.

1. we will assign a default sale document type to STO delivery document type, eg. NLCC or NCR (as figure 1 & 2)

2. and then use the default salt document type as we peremater to determine Batch Search procedure (as figure 3)

3. at the end we activate automatic Batch determination in SD for item category NLC and NCRN

when we finished all activity that mentiond as above, then the system will automatic determine batch within STO business scenario.

Hi All,

We all know Google as a Search Engine and how it does job effectively. But many of us doesn't know how to do it very precisely.

Here are few tips which are helpful

• If you are looking for an exact Phrase use quotation marks like "Condition Update" which will narrow the result.
• Expand Search with synonym Use "Tilde" Eg: "~SAP" lists out all the URL where SAP is present.
• If you are looking for a downloadable files like PDF's DocX, ppt, etc Eg: "condition update sap" filetype:pdf

Apart from above here is a customized link which search the entire SAP Wiki and SDN websites

https://www.google.com/cse/home?cx=013447253335410278659:k8ob9ipscwg

Credits to the creator of the link

Happy Google

Thanks,

Sriram.

Sales & Operations Planning! Execution to the Commanders Intent

Every good leader has a good strategy. And every efficient organization knows their leader's intent. All employees at Southwest Airlines know and act to the CEO's intent. Herb Keleher says to his people: "We are THE low cost airline. Once you understand that fact, you can make any decision about this company’s future as well as I can.” Just check it out... next time you fly from Austin to Denver ask your flight attendant why Southwest doesn't have First Class seats, Foie Gras for dinner or luggage fees. Yes, I am sure, his answer will be the same as the person who checked you in. Because they all work towards the same goal: to be THE low cost airline, and because it's not that hard to make decisions on problems like 'expensive or cheap food?', 'expensive seats or more seats?', 'expedited boarding process or first class waiting lounge?'. It's all crystal clear and to the point!

So it should be with your Sales & Operations Plan. The S&OP is your commander's intent. So, first of all... you better have one!

For some the S&OP is simply the forecast; for others it's financial budgeting. Many companies, however, integrate their financial planning with a sales forecast on product group level and the real good ones also roughly check if the plant's capacity suffices and then subsequently ensure a proper transfer of demand. They also re-evaluate their product strategy (MTS vs. MTO vs. FTO vs. ATO) and make the appropriate adjustments in the master data. Is all of that done inside SAP functionality without the use of external applications? Mostly no, but that should be discussed in another blog post.

And here lies the crux of the matter. If you don't integrate finance with sales... if you don't connect the production department with a feasible plan... if you don't make the proper distinction between MTS and MTO... and you work in various, different systems; you will have a very hard time communicating the commanders intent; and have everybody putting their nose in the same direction.

A Sales & Operations Plan carries information about what products do we stock and how much of it? what do we need to invest - resources and capital? what's going to be our profit? what lead times will we promise for which product? What's going to be our supplier make-up? and what is our Plan B in case of variability (which is part of our life). Yes, it's the strategy, policy and general direction everybody should work towards to. For short: The Commanders Intent!

In my mind an isolated look at how you plan your finished goods does not suffice. S&OP is impacted by, and has an impact on, many areas within the supply chain. We all know that... but do we also live by it?

To fulfill special requirements in text processing, it is possible to create customer own specific data transfer routines in transaction VOFM. The customer specific name space in this case is from 50 until 99.

An example for a created routine would be number 91, which then has as technical include name RV45TE91:

All created routines are inserted into the Include RV45TENN, which functions as the object holder of all:

Now of course after the creation of such an own text data transfer routine, it should be transported to the productive system. At this step you will face the problem that the include RV45TENN can not be transported.

This is due to its development class, the include belongs to package $TMP, which is for temporary objects:

As temporary objects can never be transported, the transport of RV45TENN will fail with an error message.

To be able to solve the problem, the procedure described inKnowledge Base Article 1922260 should be followed. In the transport organizer tool (transaction SE03) the attributed package will have to be changed from $TMP to VMOD:

With VMOD the transport will become possible.

Further information:

• Knowledge Base Article:

        1922260 - Include RV45TENN can not be transported

• CSS SAP Notes:

------

Read about intended audience / purpose / approach towards these posts => Additional info

This my recent initiative. Give me feedback how I could improve it further, any topic you would like me to discuss in particular, change my writing approach / style etc.

------

In this post I touch various controls, objects that are in action during item pricing and interplay between them(form order document down all the way to to billing / invoicing). It is assumed you are already aware of concepts like - pricing condition technique, condition type, copy controls. item category etc.

ITEM CATEGORY CONTROLS:

(Remember "item category" == "document type" + "item cat. grp." + "high lvl. item cat." + "usage")

As soon as you enter the material in sales order, SAP runs through item category determination rules. Identifying appropriate item category for an item with-in the context of this transaction. Item category has 2 configuration settings that are highly relevant in pricing context:

• Pricing :: Whether the item is to be priced at-all or not (with-in the context of this transactions). An item may be relevant for pricing in one transaction and may not be relevant for pricing in other transaction. This is controlled though th is setting of the item category identified for an item in the transaction. Because the other transaction (free-of-charge subsequent delivery, FD for example) may result in different item category (KLN) not relevant for pricing, and so the item is never priced in that transaction

As you can see standard item category (TAN) is relevant for standard pricing (‘X’). and so normal pricing is carried out when TAN is identified as material’s item category in standard order (OR)

whereas, free-of-charge material category (KLN) is not relevant for pricing (BLANK). and so no pricing is carried out for the material in free-of-charge subsequent order type (FD)

• Billing Relevance :: The billing / invoice document is to be based on sales order or based on delivery documents or based on pre-defined billing plans? Most literature do not elaborate much upon that but in practical terms it means what types of copy control settings to use when data flows into billing document.

• For order related billing, data flow is based on order => billing copy controls (VTFA)
• For delivery related billing, or, data flow is based on delivery => billing copy controls (VTFA).

COPY CONTROL SETTINGS

More detailed discussions on copy controls in later posts, but basically with-in pricing context the copy control settings (at item-level) control

(condition value are copied from source to target document at item-level only. Never at header level. and so for time being I only discuss item-level copy controls in pricing context)

• Billing quantity :: what quantity to be copied to billing / invoice documents - should it be (ordered qty.) or (delivered qty.) or (ordered - invoiced qty.) etc. If you set it C (order quantity), SAP will always bill total ordered quantity (irrespective how many quantities were actually delivered)

• Price source :: Which source document the billing / invoice fetches condition values from - should it be order or delivery or both?

NOTE-1 :: Pricing source set to ‘E’ (delivery / order) for standard item category (TAN) in source document. This meansfor every condition type included in billing document’s pricing procedure, SAP tries to copy value from delivery document. Only, if billing document does not find condition value in delivery document will it try to access condition value from sales order. This is particularly useful when freight conditions are entered in delivery document and other conditions are n sales order. Make sure the condition type being copied is also included in order / delivery  pricing procedure. (remember order / delivery / billing - each have their own pricing procedures, more on that towards the end of this post)

NOTE-2 :: If an item category is order related (Billing relevance = order related) the system gives error if you choose Price Source as delivery (B / D / E / F. why?

• Pricing type :: While copying  condition values from source to target document, should condition values, scales etc. be re-determined or should they be copied as-is. For example billing document may be created months after order was created or delivery was made and meanwhile item prices / discounts etc. might have changed. or, the scales for Freight charges may have changed as per weight of the actual delivery (vs planned delivery in sales order). Being highly configurable system SAP allows the flexibility to selectively choose what set of condition types to be re-determined (for ex. taxes, freight etc condition categories) and which ones to be copied as-is (for example manually entered values).

NOTE :: remember "Billing date" in billing document is always "actual GI date" from the delivery (Delivery document => Item overview screen). This can be different form planned GI date, which is copied form sales order)

PRICING PROCEDURE:

Coming back to sales order, as soon as you enter the material in sales order and SAP finds the item to be price relevant, it runs trough pricing procedure determinations rules and determine the relevant pricing procedure.

This pricing procedure controls what all condition types constitute overall item pricing. Each condition type can be

• Automatically determined :: if the condition type has an access sequence assigned to it and the valid condition records exists.
• or, if no condition record is found, the condition type can still be added manually. In that case make sure you further set up the condition type to be manually editable (condition type settings, V/06 => “Changes which can be made” section). Set “Manual Entries” as either BLANK, A or C.

Depending upon business needs, it is also possible that a condition type be only added manually (not automatically!) to an item pricing. Despite relevant condition records existing. For example one-off special discount discussed case-by-case with customers. In order to achieve that, check the “Manual” check-box against the relevant condition type in the pricing procedure (V/08). In such situation, as-soon-as condition type is added manually, automatic  determination kicks-in whereby SAP automatically picks the relevant condition records if there is one that exists. Or you just have to enter “Condition Amount (rate)” or “Condition Value” manually. Again make sure condition type shoudl still be set to be manually editable as described above.

**********************VERY IMPORTANT*******************************

*************************************************************************

Condition Amount (rate) and Condition Value are two different things

and,  Condition value == Condition amount (rate) * Condition base

where,

• Condition base :: is determined by condition type settings => “Calculation type” (Fixed amount or item’s quantity / volume / weight or it could be % based
• Condition amount :: is simply the condition’s rate card and originating from condition records

(This is very important concept esp. when it comes to distributing header level "group condition" to various items or condition types that are % based. I have met even semi-experienced consultants alien to this concept!

*************************************************************************************

*************************************************************************************

SALES / DELIVERY / BILLING PRICING PROCEDURE

Now that we are on sales order stage, all condition types that comprise item price have been determined (or added manually). Next step is to make a delivery document, followed by billing / invoice document. How the prices / condition values flow from document-to-document?

It is a common myth that conditions types and respective amount (rate) and values are copied from sales document => delivery document and from there on => billing document. That’s not what happens exactly. In-fact if you look sales => delivery copy control, VTLA, there exist no controls for copying pricing data

Sales, delivery and billing document each has its own pricing procedure assigned to it

• Sales and billing pricing procedure is determined as per determination rules = (Sales org.) + (dist. ch.) + (div.) + (cust. pricing proc.) + (document pric. proc.)
• For delivery, the pricing procedure is directly assigned to delivery document type. Normally delivery pricing procedure only contains delivery related condition types (for example freight charges).

During billing / invoicing phase, SAP copies condition values from order document or from delivery document or both. Based on “price source” setting in delivery => billing copy controls, VTFL (Or, for order related billing relevance, order => billing copy controls, VTFA). Make sure all the condition types you want to include in billing / invoice exist in both

• the target document's pricing procedure (billing pricing procedure)
• as-well-as in source document you are copying from (order or delivery or both)

Because condition values are copied only if the condition type exists on both source and target document. In order to test that, try to leave out PR00 pricing condition type from billing pricing procedure. Then try to bill the delivery. In the billing document you wont notice PR00 condition anymore.

In practice though we can

1. Create one pricing procedure
2. Assign this pricing procedure to all three documents (sales / delivery / billing)
3. Selectively hide any condition type from irrelevant document. For example freight conditions only relevant in delivery and not in sales order. This is achieved through “requirement” routine assigned to relevant fr eight condition(s) in pricing procedure where-in requirement routine hides the condition in sales order and displays it in delivery document.

Many times being at Functional side having some technical knowledge is a great way to make a big skills move in SAP. When you've a real passion for some particular area then I believe it’s equally important to start focusing on development efforts against your particular module along with functional role so sharing this document which I’m sure will be helpful for many of us.

WHY SUCH REQUIREMENT??

Question arises that why there’s a need to modify F1 documentation for any Data Element/Keyword and the answer is sometimes you need to display a Custom message for that particular field, sometimes you want to display the F1 help in Multi-languages and sometimes it’s just that more Documentation is required according to the user level.

SAP provides its own documentation for each of the data elements which we can view as an F1 help for screen fields based on the particular Data Element. This documentation can be enhanced via T-code CMOD.

STEPS:

First we need to get the data element of the corresponding field for which we want to change F1 Help and the 1^st step is knowing the data element. Suppose in Customer Master, I want to change the F1 help for ‘Data Line’ Text box and in order to get the Data Element the same press F1 and then click on Technical Information Icon.

Execute T-code CMOD

Now click on Goto-->Text Enhancements-->Data Elements-->New DE cust. docu.

You’ll get the below mentioned screen, copy the data element that you've got after clicking Customer Master ‘Data Line’ field.

Click on the Mark icon or press enter, following screen will appear.

Give unique name in Modification Name Text box while creating the same. It depends upon you as if what starting point you want will it be the Original Text or as a Template. This will be copied into the modification screen which can further be changed accordingly.

In below mentioned screen I've defined customized usage of this field as I don’t want other fields to be displayed so deleted them. Moreover, you can use other features like formatting, paragraph style etc. Don’t forget to activate this Modification after saving.

After activating it, click on F1 help of ‘Data Line’ field in Customer Master and you can see the changes in below mentioned screen.

Now this ‘Data Line’ field name might be confusion for many of the End users who are responsible for maintaining Customer Master Record hence we can also change the keyword as per our requirement using CMOD once again.

Click on Goto-->TextEnhancements-->Keywords-->Change; mention the Data Element once again as shown in below screenshot.

This is the default description that you will be going to see after clicking on the Mark icon.

You can make the changes in above mentioned text fields as per your requirement.

Go to XD02/XD03 and you will see the changes that you've made are reflecting against that particular field.

We can cross verify the done changes in SE11 by entering the structure name as ADDR1_DATA, press F7 for the view and you can clearly see the changed short description like in below mentioned screen shot.

WHERE TO USE CMOD:

This enhancement technique mentioned above can be used to fulfill business requirements however before applying such changes we need to be careful as changes made through CMOD are directly linked to the dictionary object and the same will be reflected at all those places wherever that particular field is available.

I hope it will be helpful for those who always are ready to meet client's requirement at any cost or where there's a Top Management demand to fulfill wishes like that for their reporting purpose. Fruitful comments of all valuable members are most welcome. Thanks.

General path:

SPRO > Sales and Distribution > Basic Functions > Pricing

.

At a major FMCG organization we are implementing Oracle transport management  and integrating with SAP landscape. However in the initial discussion it's coming to the light that many data points needed for optimization are not available or maintained in SAP. It's too early to say what's the glitch but I am curious to understand and understand the experience/inputs from  larger SAP community.

I intend to keep this blog updated as we progress through various stages of this implementation.

Please feel free to share your comments

In third-party process the delivery of the goods required by the customer is not done by sales organization where customer orders. Instead, the request of the goods is forwarded to an external vendor who sends the material directly to the customer.

Here is what happens in third-party process:

1. Customer orders goods and a sales order is created in a sales organization
2. Purchase requisition is created automatically when sales order is saved.
3. Purchase order is created at the vendor in the MM purchasing application (manually or automatically)
4. If the vendor does the outbound delivery to the customer, the goods receipt can be posted in the system
5. Invoice receipt is created (invoice from vendor)
6. Invoice to customer is created (order based invoice)

SALES ORDER

Third-party process is triggered when the sales order with third-party item is created. Depending on settings done in customization third-party item categories can be automatically determined by the system (automatic third-party processing) or they can be changed from standard item to third-party item category in sales order (manual third-party processing).

Sales order type used for third-party – OR (standard order)

Item category for third-party – TAS

Schedule line category for third-party – CS

Let’s look deeper into the settings in the system done for automatic and standard third-party process:

ITEM CATEGORY TAS:

Create PO Automatic indicator is not marked in TAS. ALES is an item category for third-party processing where this indicator is marked.

ITEM CATEGORY DETERMINATION

Item category TAS will be determined automatically for standard order (OR) and item category group BANS (third-party item). Item category group can be found in material master, Sales: Sales org.2 view.

SCHEDULE LINE CATEGORY CS

Data: Order type = NB, Item Category = 5 and Acct.AssgntCat  = X is the data for Purchase requisition. If it is filled like above the purchasing requisition will be created automatically as standard purchasing requisition (NB), with item category S and acc.assign cat X. The mapping of item category (from 5 to S) can be found in IMG:  MM->Purchasing->Define External Representation of item categories. The definition of account assignment category can be found in IMG: MM->Purchasing->Account assignment->Maintain acc.***. categories

SCHEDULE LINE CATEGORY DETERMINATION  

THIRD-PARTY PURCHASE REQUISITION

After saving sales order with item category TAS the purchase requisition is automatically created. In order to see the document go to: Environment -> Status overview and expand data for item, then expand data for purchase requisition as well:

Double click on the requisition number and you will be taken to the purchase requisition document. The other way is to go to schedule line where you can find the purchase requisition number.

If third-party item has more than one schedule line with confirmed quantity > 0, then purchase requisition is created for each schedule line.

It is wise to have the vendor determined in source of supply at this stage of the process (i.e. source list)

MANUAL PURCHASE ORDER

The purchase requisition needs to be converted into purchase order in MM (t-code me21n). The purchase order document type is NB (standard order), item category S, that must be assigned to account. Thus account assignment category needs to be given. In this example it is X (automatically taken during conversion from purchase requisition, as it was defined in item category CS).

The definition of acct assignment category can be found in IMG: MM->Purchasing->Account assignment->Maintain acc.***. categories:

Note: There is also a third-party account assignment category created in the system and its definition looks as follows:

The mapping of item categories: IMG:  MM->Purchasing->Define External Representation of item categories:

AUTOMATIC PURCHASE ORDER

As it was written before – the purchase requisition is created automatically when sales order is saved. It is possible to automatize the next step, the creation of purchase order, as well. The ALE function is used for that purpose.  The indicator for the automatic creation of purchase order is not set for TAS item category. However, there is a special item category – ALES which can be used instead in third-party process. The indicator for the automatic creation of purchase order is marked in ALES by default.

Prerequisites for the automatic creation of purchase order are as follows:

• The indicator automatic purchase order needs to be marked in item category definition (item category ALES has it by default)
• Unique source of supply needs to exist for third-party item
• At least the document type for the purchase order must be assigned for Sales organization in customizing under Enterprise structure->Definition->SD->Define, copy, delete, check sales organization

If all above prerequisites are set up correctly, purchase order will be created when sales order is saved. Then, it can be found in document flow in sales order.

GOODS RECEIPT

Since during third-party processing goods are moved directly from the vendor to the customer, inventory management is not affected by this event. However, if sales department would like to document and enter delivery to the customer in the system it is possible depending on settings in customization. If account assignment category 1 is used in item category definition, goods receipt is not possible, as the goods receipt indicator is not set for this account assignment cat. If account assignment category X is used, goods receipt is possible.

The goods receipt posting (t-code migo) would have the following effects:

• The warehouse stock is not updated
• The goods receipt is posted directly to consumption and the consumption quantity is updated
• The order value is posted to a GR/IR clearing account for invoice verification purposes
• The goods receipt can be traced in the purchase order history

The goods receipt posting should happen when the vendor reports that outbound delivery was executed or customer confirms that delivery arrives.

Since no flow of goods occurs in the enterprise, the goods receipt posting results in updates on value basis.

INVOICE RECEIPT

The invoice verification with reference to purchase order needs to be created when invoice from vendor arrives to enterprise (t-code miro). The value and, if goods receipt was done earlier, the quantity are proposed by the system. When the incoming invoice is posted following are updated:

• Purchase order history
• G/L  accounts
• The vendor account in subledger accounting, as well as the liabilities account (general ledger)

CUSTOMER BILLING DOCUMENT

Once invoice receipt has been entered, the customer can be billed as well (t-code vf01). Since an outbound delivery doesn’t exist for the third-party the invoicing will be order based. In the item category TAS definition, the billing relevance indicator is set to F by default. That means: relevant for order-related billing document: status according to invoice receipt quantity. That is, the system allows invoicing the order only when vendor’s invoice has been processed in invoice verification.

The customer invoice is created for the quantity specified in the vendor invoice. The setting in the copy control for the third-party item category from sales document to billing document specifies that the quantity from the invoice receipt is transferred to the billing document instead of the order quantity (billing quantity indicator in copy control is F)

Hi Folks

During my time when I was getting trained for SD, the most complex topic I had encountered with was Pricing in SD.

Due to the nature of processes in SAP, it took me sometime to understand and memorize the process involved, the connections between different entries of Master data in tables or entities and the sequence of events.

Today, I would like to describe this process step-by-step so that those who have issues in understanding this interesting topic and its process sequence, will feel better and perform this process with confidence once they read and perform the mentioned steps in an SAP ECC 6.0 system.

There are few concepts involved in this process which I will describe very  briefly here as our main focus is the process.

1. Condition Table - Define a combination of key field by which a pricing element is setup.
2. Access Sequence - Provide a search strategy for finding a valid condition table.
3. Condition Type - It defines the pricing element
4. Pricing Procedure - It defines the sequence of calculation.

Now we can start our master data creation and configuration.

Step 1 : Creating a Condition Table

Go to  SAP Reference IMG ---> Sales and Distribution ---> Basic Functions ---> Pricing ---> Pricing Control --> Define Condition Tables

Choose a number between 501 and 999, based on the availability in system and press enter.

Using the "Previous Page" and "Next Page" button, scroll between the fields and select the following four fields by double clicking on each one.

• Sales Organization
• Company Code
• Incoterms
• Destination Country

Click "Generate" button to generate the table.(see image below)

If system show a warning, press Enter to proceed.

If system ask to save this in a package, use $tmp directory.

System will show this message :

Step 2 : Creating an Access Sequence

Go to  SAP Reference IMG ---> Sales and Distribution ---> Basic Functions ---> Pricing ---> Pricing Control --> Define Access Sequence

Click on "Maintain Access Sequence"

System will show the following dialog box :

Click Enter.

System will show "Access Sequence" as below.

Click on "New Entries".

Enter values in this screen and press enter, the click save.

Step 3 : Creating a Condition Type

Go to  SAP Reference IMG ---> Sales and Distribution ---> Basic Functions ---> Pricing ---> Pricing Control --> Define Condition Types

Click on "Maintain Condition Types"

Select Condition type "PR00" and click the "Copy as" button.

Change values of "Condit type" and "Access seq" as per your values and press enter, then save.

Step 4 : Creating Pricing Procedure

Go to  SAP Reference IMG ---> Sales and Distribution ---> Basic Functions ---> Pricing ---> Pricing Control --> Define And Assign Pricing Procedure

Click on "Maintain Pricing Procedure"

Select "RVAA01" pricing procedure and click "Copy As" button.

Enter values in "Procedure" column and press enter.

System will show the copy object dialog box, click "copy all".

Press Enter for all subsequent messages and at the end, save the screen.

Step 5 : Adding new Condition Type to Pricing Procedure

Go to  SAP Reference IMG ---> Sales and Distribution ---> Basic Functions ---> Pricing ---> Pricing Control --> Define And Assign Pricing Procedure

Click on "Maintain Pricing Procedure"

Select your newly created pricing procedure, in this case, it is 70STTP.

Click on Control Data

Replace "PB00" with "70PR" and click save.

Step 6 : Creating a new Customer Pricing Procedure key for your group

Go to  SAP Reference IMG ---> Sales and Distribution ---> Basic Functions ---> Pricing ---> Pricing Control --> Define And Assign Pricing Procedure

Click on "Define Customer Pricing Procedure"

Click "New Entries"

Enter values and save it.

Step 6 : Creating a new Customer Pricing Procedure key for your group

Go to  SAP Reference IMG ---> Sales and Distribution ---> Basic Functions ---> Pricing ---> Pricing Control --> Define And Assign Pricing Procedure

Click on "Define Pricing Procedure Determination"

Click "New Entries"

Enter values as per your configuration and save it.

This screen creates a link between your Sales Organization, Distribution Channel & Pricing Procedure.

Step 7 : Changing your customer to use the new pricing procedure.

Go to  Logistics --> Sales and Distribution  --> Master Data  --> Business Partner  --> Customer  --> Change  --> Sales and Distribution

Enter the customer number and sales area and press enter.

Click "Sales Area Data"

Change the "Customer Pricing Procedure" to the value you created.

Save your data.

Step 8 :Creating Condition Records

Go to  Logistics --> Sales and Distribution  --> Master Data  --> Conditions  --> Select Using Conditions Type  --> Create 

Choose Condition Type 70PR

Enter appropriate values and save the record.

To test this configuration, create a standard order.

Conclusion :

Pricing is a vast topic in SD and same concept applies to SAP IS-Oil.

I will try to post more information from SAP IS-Oil as it is my main area of interest.

Pls comment on this post, any comments to improve this post are most welcome.

Cheers,

Salman Haleem