Many of you would not be aware that if you execute standard TCodes like VL06G or VL23, it will not list all DAs that are saved.   In normal circumstances, you would know that all DA related data will get stored in LIKP and LIPS tables; but apart from these two tables, there is one more table which is SHP_IDX_GDSI. 

DA related data in Table SHP_IDX_GDSI  will get stored only if the corresponding line item have value in field BWART in LIPS table.  In other words, if the material type is VALUATED, then only, the related DAs will get stored in the above table.  If the material type is NON-VALUATED, then it will not store the delivery related data.  Needless to mention, this control is in OMS2.

Solution

If you want to populate those NON-VALUATED data also in VL06G or VL23, you have to implement note 681639 so that system will populate those non-valuated deliveries also.

Thanks

G. Lakshmipathi

Have you ever heard about mis-communication between the production scheduler and the sales department? The availability check with its rules and conditions is the link. I am mainly talking about order entry here, but, of course, the forecast and setup of MTO vs. MTS are two more areas of friction between sales and production - unnecessary if the right strategies and configuration to support those are in place (an educated user who can execute the functions well, must be the most important part of the whole). 

Now when you enter a sales order into your SAP system, it represents a demand for a sellable product. The sales order is looking to get product from somewhere, so as to fulfill a customers desire to increase your revenue. The sales representative can not possibly understand why the company s/he works for would not deliver the product right away or wouldn't do anything to fulfill the request asap. But there are other goals: a supply chain that is as waste-less as possible, low finished goods inventory, high production utilization, low production cost and a smooth, undisturbed production program. Unfortunately these goals - and the Sales Reps mission - are usually not in line. 

In SAP the availability check is using a rule and may be different depending on the business transaction you perform. In other words: a Sales Order may check differently than a Production Order. The rule by which the check is performed can be assigned in the material master and therefore can differ from one product to another.  This rule, together with the fact that you create a Sales Order, form the framework within which delivery dates with the customer are agreed upon. 

As an example: if a customer wants 50 pieces but there are only 30 in inventory, the availability check finds out for you when the company is able to deliver the goods. In its simplest sense the additional 20 may be delivered after the time it takes to bring them back or at the date when we receive the next batch from production. This is the difference between checking with or without replenishment lead time. 

In the checking rule you can identify what stocks - safety, blocked, restricted - are to be included in the check. It is also possible to specify whether planned orders (firmed or all), production orders, requisitions and/or purchase orders are used to determine the availability date. 

As you can see the choice is ours what we let SAP automatically determine as the date we tell our customer, when they can expect the goods.  But there seems to be a problem. At least I see that quirk everywhere I look: the sales rep is on the phone with the customer entering an order and the availability screen says "you can have 30 pieces today and 20 pieces next week Tuesday." "Great" the customer says and the sales rep saves the order without fixing the date. 

Not fixing the date has no meaning for the sales rep but in MD04 the entire order of 50 pieces stands with a requirements date of today. That means a red light and a signal to the production scheduler to make 20 pieces... NOW ! And tomorrow it means Now! And the day thereafter too. And the customer does not expect the 20 pieces before next Tuesday and is quite happy with that (in the end he won't get them before next Tuesday anyway). 

Would the sales rep have checked on the fixing, we would have seen a delivery for today and another one for Tuesday in MD04 and production would have executed that order, which the availability check saw. The customer would have received what they were promised and the world would have been a little bit better place to live. 

It is incomprehensible to me why companies don't have a policy in place that supports better practices when it's so easy to do. Instead people fight you to the end to not fix the date. I have no clue why but I have customers with whom I have been discussing this issue for years and they still don't do it or only with much reluctance. "What if I have it available earlier ?" they ask. So you really want to have hundreds (if not thousands) of false delivery days per week disturbing your production program, in exchange for that one time chance to deliver on Monday instead of Tuesday? And even then... it's an exception... and those are meant to be handled manually - not the rule. 

Of course, if your availability check produces false results because your basic data setup is incorrect or you mix up MTS with MTO, then you have to do something else and can't fix the date. However, in that case we have to take a couple of steps back and are not ready yet to have production and sales sing to the same song...

Current Scenario:-

Users generating deliveries both via VL04 and VL01N which should be controlled in such a way that they should ONLY execute VL01N.

Options:-

In normal cases, this can be achieved with the help of basis team by having different authorisation roles to their user id.  But do you know that from functional side also, this can be achieved ??

Solution:-

Execute OVLS where you can see various standard Delivery Blocks.  Select any one, copy that and rename it.  Now check the box ONLY for "DDueList" and save as shown below.

Next assign this Delivery Block to your order type in VOV8. Finally, create a transaction variant for this.  Now try to create a sale order and execute VL04 where you cannot see this order.  Instead, if you try to execute VL01N, system will allow you to do PGI, subject to stock availability.

Thanks

G. Lakshmipathi

This blog describes the steps to configure Price Point Group for Sell Price calculation. This blog also provides a brief overview about the functionality of price point group.

Price point

In Retail, most price points consist of amounts that are fractionally lower than a round number e.g. 1.99 AUD. Price points are used because consumers perceive them to be cheaper. Wholesalers, on the other hand, tend to use round numbers.

The sales price calculation function uses price points as targets for rounding, e.g. rounding a price calculated from planning data as 1.92 AUD to 1.99 AUD

Price point group

Price points are first grouped into price point groups by price point area.These price point groups are assigned to a combination of distribution chain and merchandise category. A rounding rule is also defined for the price point group, which defines how the price calculated in the sales price calculation function is to be rounded to the set prices of the price point group (rounded up or down, or to the nearest whole number).

In short, the price point group controls which price points are used during sales price calculation.

Configuration Steps :

Transaction : SPRO

SAP IMG Path :  Logistics – General -> Retail Pricing -> Sales Price Calculation -> Price Point Group

There are two steps involved :

1. Define Price Point Group and Assign Price Point Ranges
2. Assign Price Point Group to Organizational Level/Merchandise Category

1. Define Price Point Group and Assign Price Point Ranges

            In this step you define price point groups and assign price point ranges to them.

Price point range :

A price point range is used in Pricing to define price points within a particular price range.

Price point ranges are assigned to a price point group in which a rounding rule has been defined, according to which sales prices determined in the sales price calculation function are rounded either up or down.

Each price point range will comprise of :

• a lower limit
• an upper limit
• an increment

Price points for the price point range are determined by repeatedly adding the increment to the lower price point.

Example:

The following price point range could be defined for the price range 9.99 AUD to 19.99 AUD:

• Lower limit: 9.99
• Upper limit: 19.99
• Increment: 0.50

Adding the increment to the lower limit would create the following price points for this price point group: 9.99 AUD; 10.49 AUD; 10.99 AUD; 11.49 AUD, and so on.

a. Define Price point group

SAP IMG Path :  Logistics – General -> Retail Pricing -> Sales Price Calculation -> Price Point Group-> Define Price Point Group and Assign Price Point Ranges

Click on New Entries. Enter the details as shown below :

b. Assign price point ranges

Select the defined price point group and click on ‘Assign price point ranges’

Enter the price point ranges

The price points for the first price point range will be 0.09, 0.19, 0.29…..9.89 and the price points for second price point range will be 9.99, 10.99, 11.99……999,999.99

Now the price point group is defined and the price point ranges are assigned to it.

Rounding rule for price point group

Rounding rule indicates how the price calculated in Sales Price Calculation is to be rounded to the price points in a price point group.

A price point interval is the gap between two neighbouring price points. The rounding rule value is expressed as a percentage of this interval; it defines a portion of the interval that starts at the point from which prices start to be rounded up and ends with the upper limit of the price point interval.

In the price point group defined above,

Lower Limit (First price) – 0.09

Upper Limit (Last price) – 9.89

Increment – 0.10

This will form the price point intervals as below:

Interval 1 : 0.09 to 0.19

Interval 2 : 0.19 to 0.29

Interval 3 : 0.29 to 0.39

.

.

.

Interval n : 9.79 to 9.89

Let us take Interval 3 (0.29 to 0.39) for understanding the rounding rule, Interval span is 0.10

If Rounding rule – 25

The price will be rounded down if it lies between 0.29 – 0.365 and it will be rounded up if it lies between 0.365-0.39 (25% of the interval).

If Rounding rule – 75

The price will be rounded down if it lies between 0.29-0.315 and it will be rounded up if it lies between 0.315-0.39 (75% of the interval).

If Rounding rule – 50, the turning point will be at 0.34. In other words, the rule Rounding rule = 50.00 means that prices are always rounded to the nearest interval limit.

Note : If Rounding rule = 0, prices are rounded down to the nearest whole interval; if Rounding rule = 100, they are rounded up to the nearest whole interval.

A simplified formula for turning point can be

Turning point = Upper limit – (rounding rule/100)*interval span

Turning point = 0.39-(25/100)*0.1=0.365

2. Assign Price Point Group to Organizational Level/Merchandise Category

SAP IMG Path :  Logistics – General -> Retail Pricing -> Sales Price Calculation -> Price Point Group-> Assign Price Point Group to Organizational Level/Merchandise Category

Click on New Entries

Enter the details as shown below :

The Price point group Z00001 defined in step 1 is assigned to MC 102010202 for sales org 1005/10.

The Sales price calculation for the MC 102010202 will follow the rounding as per price point group Z00001.

Sales Price Calculation

Article belonging to MC 102010202 (e.g. 701877)

Transaction VKP5

Sales price is 12.99 rounded as per second price point range under Z00001

To check the other price point range, adjust the purchase price of article to 5 and run VKP5 again, to see sell price calculation

Sales price is 6.49 rounded as per first price point range under Z00001

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...

Assume you have a distribution network around the globe and use SAP's intra stock transport order process for movements from plant to plant (inside a company code) and the inter stock transport order process for movements between plants from different countries. Your DCs most likely have a VSF forecast that creates demand for product. The MRP run then generates stock transport orders so that the product gets shipped from the plants and that there is enough inventory to sell to the customer quickly from stock.

Just recently I found out that for those stock transport orders the same availability checking screen can pop up as it does for Sales Orders. This is new functionality that came with EHP4 or 5 (I'm not quite sure).

This opens up a number of opportunities!

But first you need to set up the master record correctly. What's important is that there are:

- procurement type

- special procurement type

- planned delivery time

- GR processing time

- total replenishment lead time

- availability check

...all on the MRP2 and MRP3 screens of the MMR.

Here is my suggested setup for the demanding plant (the DC / Warehouse that has the VSF and sells to customers) and its implications:

1. The checking rule: set it up so it includes safety stock and available stock and check WITH replenishment lead time. Include Purchase and Production orders but not planned orders or requisitions.

This means: when the DCs STO finds stock in the delivering plant, it confirms the shipping date after the Planned Delivery Time + GR processing Time.

When there is no available stock in the delivery plant but there is a fixed receipt (like from a production order), it will confirm the shipment date to the date the receipt is confirmed + Planned Deliveyr Time + GR processing time.

When there is no stock and no receipt, it will use the Total Replenishment Lead Time in MRP3 to confirm the shipment date (but only if the procurement type in MRP2 is set to E).

2. Total Replenishment Lead Time: this is the estimated timespan it takes to replenish the product from scratch through the entire supply chain. Set it to a value that you feel comfortable quoting to your customer when you have no stock.

3. Planned delivery time (and GR processing time): represents the time to transport the product from the delivering plant to the warehouse when its freely available to transport.

4. Special Procurement Type: points the demand to the specific delivering plant. When MRP runs it covers open demand by generating stock transport requisitions pointing to the plant defined in the special procurement type. These STOs are offset by the planned delivery time.

Procurement Type: this is the tricky part. You would think it should be set to 'F' for external procurement so it generates requisitions. In that case the TRLT would not be considered. Therefore you need to set it to 'E' (because you set a special procurement indicator it will still create a requisition) and in that case the TRLT is used in case there is no stock or fixed receipt in the delivering plant.

Note that MRP works with the Planned Delivery Time to plan for transport whereas the availability check looks for stock or else, uses the Total Replenishment Lead Time to meet demand.

as you probably know, there is no functionality in SAP ERP to perform a multi-level availability check throughout your supply chain. If you have a network of multiple DCs and manufacturing plants and a customer order needs to check where in the network there is inventory, then the ERP check can look from a specific DC back to the source for that DC... and no further.

The Global ATP Check in APO can do it, but if you have no APO, you have to resort to other means.

A valid solution to the problem is using the special procurement indicator 'Direct Production'. Assume you have a DC in Ohio, a Warehouse in Texas and the manufacturing plant also in Texas. If the warehouse is close enough to the plant, you don't need stock transport orders to move the product to the warehouse but you can use direct production. That means that the Production Order is visible in the Warehouse.  Now if the DC in Ohio receives a customer order asking for more than what is in inventory, the availability check looks in the warehouse in Texas and if there is no inventory either, it can check whether a future production order would provide enough quantity to fulfill the order in Ohio.

Note that this only works because the production order is visible in the Warehouse's MD04 through direct production. The availability check can not look into the manufacturing plant - it stops at the warehouse.  This solution is not nearly as sophisticated as the Global ATP in APO, but, at least it gives you one more entity for the scope of check

Have you ever wondered whether or not you should fix the quantity and date after the availability check in the Sales Order? Because of the integrated nature of the availability check and because very often SAPs sales aand Distribution modul is implemented by a different team than the one who cares about production scheduling, this is a point of contention and a very possible source of mis-communication.

Usually when a sales representative enters a customer order into the system, an availability check is carried out and a screen that looks like this, pops up.

This screen is the result of the availability check and gives insight on whether a customers desired delivery date can be kept and, if not, what other possibilities there are. In the example above a customer wanted 840 lbs delivered on the 20th of August 2012. However, a full delivery to 8/20 was not possible and the availability check produced three options: first, on time delivery of 840 lbs is not possible (and the customer could decide to go elsewhere). Second, a complete delivery can be made on January 7th or, third, two partial deliveries can be made whereas 240 lbs can be delivered January 3rd and the remaining 600 lbs on January 7th.

It is now up to the customer what they want to do and up to the customer sales representative to communicate what the customer wants, to the rest of the supply chain. And that must be done using the right settings in your SAP. Following I describe the options you have and what's most important to note is that first and foremost a decision will have to be made whether an item is planned ahead of time (Make to Stock) and therefore is produced to stock driven by a forecast or if we plan the item not at all and wait until a dicrete demand come up. That decision has a profound impact on the availability check and the option that needs to be taken.

Typically, one analyzes past variation in sales to decide if a product is 'planable' at all but even more important is the replenishment lead time. If a customers accepted wait time to get the product delivered is longer than the time it takes to produce or replenish it, then we can wait until the customer orders before we spring in action. If, however, that is not the case, then we need to plan ahead and put the product in inventory using a forecast.

Once the decision for MTO vs. MTS has been made, we can look at the four options we have for materials that are not planned beforehand - typically MTO.

a (MTO). The delivery proposal is confirmed (to confirm the delivery proposal you click on the check mark) and the field Fix qty/date is checked on. With that option the two lines (one with 240 lbs and the other with 600 lbs) become MRP relevant and the two material availability dates (3rd of January and 7th of January) are displayed in MD04.

b (MTO). The delivery proposal is confirmed and the field Fix qty/date is NOT checked. In that case the delivery proposal is ignored and the required quantity still shows with the required delivery date in MD04. Therefore the original date when the customer wanted it is what's told production to deliver it by. Should that day fall into the past, then the system keeps showing today's date.

c (MTO). The customer request is not confirmed. To do this right one would have to click on [Continue]. If the field Fix qty/date is checked on, the demand disappears and does not show in MD04 anymore

d (MTO). The customer request is not confirmed again (clicking on [Continue], however the field Fix qty/date is left unchecked, which means that the demand remains in the system (in MD04) to the requested delivery date by the customer. A new MRP run will generate a planned order to cover the demand.

what does all of this mean for our customer, the sales rep and the production scheduler? for MTO products option a would mean that the customer accepts two deliveries on dates later than what the customer wanted. This also means that with fixing the dates, the production scheduler is informed about when the goods will have to be delivered and what was agreed upon with the customer. Option b, however, would mean that even though the customer agreed to the new dates, the sales rep tells the production scheduler to make the product immediately and to the old requested delivery date. Options c would mean that the customer does not want the product anymore and option d means that the demand is handed over to MRP which will generate and schedule a planned order to make the requested quantity. As soon as that happened the sales order would fall into 're-scheduling' functionality and the new availability check would promise the customer a date consistent with the planned order's supply date.

now on to the other case where we have a forecast and produce to inventory - MTS:

a (MTS). you click on the check mark to confirm the delivery proposal and fix the quantity and date. This implicates that the customer order schedule line items are displayed in MD04 and are consuming the respective forecasts.

b (MTS). the delivery proposals are confirmed but the fix qty/date indicator is NOT checked on. Therefore, even though the availability check couldn't confirm enough material to the date that was required by the customer, the demand from the customer order will still be displayed to the requested delivery date in MD04 and MRP will try to supply to that demand. A consumption of forecast also takes place, scheduling from the requested delivery date.

c (MTS). The order is NOT confirmed (we click on [Continue] but the fix qty/date indicator is checked on (fixed). No demand will show in MD04 and therefore no consumption of forecast takes place and no planned order is generated. The demand is simply gone.

d (MTS). The order is NOT confirmed and the Fix qty/date indicator is NOT checked on. Even though the demand can currently not be confirmed to the requested date, the demand remains intact to the requested delivery date by the customer and is shown in MD04. Even though the customer order is not confirmed it will still consume the forecast and the new MRP run will generate a planned order to fulfill the demand.

option a would correctly communicate the customer's acceptance of a new delivery schedule, whereas option b would drop a new demand into the production schedule (a new planned order would probably be generated - with exception message 30). Option c again will assume that the customer does not want the product anymore and goes elsewhere. For an MTS item this is a very likely situation since the customer only accepts very short lead times and, even though, we could try to make it as soon as possible, it would probably still take too long for the customer. If you are making to stock with a forecast, you can simply not always deliver. This situation is what degrades your fill rate in MTS. That is why you should probably never use option d in a MTS environment. That option drops demand into production that can mever be fulfilled and isn't even desired by the customer.

I hope this helps to clarify at least to some degree. There is so much disconnect between the sales order demand and the production program that a focused effort to align the two is necessary in most SAP installations I have seen. Get started with the decision for MTO and MTS but then look into the availability check and its setup and ability to automate. It's an effort worth taking on.

First step:
Create two number ranges for business requirement
path: Spro->Sales and Distribution->Sales->Sales Documents->Sales Document Header->Define Number Ranges For Sales Documents
TCODE: VN01

Second Step:
Configure the number ranger of sale document type.
path: Spro->Sales and Distribution->Sales->Sales Documents->Sales Document Header->Define Sales Document Types
TCODE: VOV8

Third Step:
modify the source code to control use different number range for different sale organiztion
3.1 you can use se38 to open source code MV45AFZZ and find the form userexit_number_range.
*---------------------------------------------------------------------*
*       FORM USEREXIT_NUMBER_RANGE                                    *
*---------------------------------------------------------------------*
*       This userexit can be used to determine the numberranges for   *
*       the internal document number.                                 *
*                                                                     *
*       US_RANGE_INTERN - internal number range                       *
*                                                                     *
*       This form is called from form BELEG_SICHERN                   *
*                                                                     *
*---------------------------------------------------------------------*
form userexit_number_range using us_range_intern.

* Example: Numer range from TVAK like in standard
* US_RANGE_INTERN = TVAK-NUMKI.

endform.

3.2 change the source code as the following
*---------------------------------------------------------------------*
*       FORM USEREXIT_NUMBER_RANGE                                    *
*---------------------------------------------------------------------*
*       This userexit can be used to determine the numberranges for   *
*       the internal document number.                                 *
*                                                                     *
*       US_RANGE_INTERN - internal number range                       *
*                                                                     *
*       This form is called from form BELEG_SICHERN                   *
*                                                                     *
*---------------------------------------------------------------------*
form userexit_number_range using us_range_intern.

* Example: Numer range from TVAK like in standard
* US_RANGE_INTERN = TVAK-NUMKI.
*{   INSERT         TASK912652                                        1
  IF us_range_intern = '13'.
    CASE vbak-vkorg.
      WHEN '0029'.
        us_range_intern = '13'.
      WHEN '0143'.
        us_range_intern = '14'.
    ENDCASE.
  ENDIF.
*}   INSERT

endform.

I am now providing online video courses on a channel on YouTube, so I can better transmit the experience, I gather at various customer sites. Have a look and send me requests for subjects, that I should cover in future online courses.

http://www.youtube.com/watch?v=TWq_sxJsZ8M

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?

In this blog I want to cater user exits in detail. I will try to answer Wh questions like what, How & Where? There are several instances where client have requirement which cannot be fulfilled through standard SAP functionality means it cannot be achieved through standard configuration. Then in order to cater client requirement, SAP have given provision of user exits.

User exits are blank forms/space provided within standard SAP code in which we can write our own code with the help of ABAP consultant to achieve functionality required by client which cannot be catered by standard SAP.  With the help of this code we can bring deviation in standard SAP behavior.  User exits allow developers to access and modify program components and data objects in the standard SAP System.

User Exits for SD are found in IMG under

Sales & Distribution --> System Modifications --> User Exits 

To see user exit, use T-Code SE38 then enter program name MV45AFZZ & click on radio button –> source code & click on display button. In that code only purpose of that user exit is given. If you read that description only, we will come to know utility of that user exit.

For each module, SAP has given list of user exits. Here I would like to give few examples of SAP SD user exits& its application through a simple example:

Client was having STO process.  Process is very commonly used & consists of steps -

ME21N – Create purchase order

ME29N – Release purchase order

VL10B – Outbound Delivery w.r. to purchase order

VL02n – PGI

VF01 – Proforma Invoice (Billing Document Type – JEX)

J1IIN – Excise Invoice

Standard SAP behavior is that you can generate multiple  number of proforma invoices with reference to single outbound delivery Here client came up with the requirement that system should allow only one proforma invoice from outbound delivery. If you try to create another one system should give error message. This was one of the requirements that could not be catered through standard SAP. At that time we used user exit RV60AFZC & prevented proforma invoice creation.

Few of the very popular SD user exits are –

Invoice – RV60AFZZ, RV60AFZC, RV61AFZB, RV60AFZD

Delivery –MV50AFZ1, MV50AFZZ

Sales Orders – MV45AFZZ

Regards,

Balaji

Table: VBKD Sales Document: Business Data

When change business date in sales document sometime we will meet pop up message: V1 403: The header business data does not apply to item xxxx,

VOV7 define item category, check box "business item",

1.If it is blank, business data fields (table VBKD) in item level will become unchangable, you only can change business data in header level and item level will be changed at same time, so header data and item data will be same whatever.

2.If it is ticked, then you can change business data in both sales document header level and item level.

(we use VBKD-VSART Shipping Type as example)

when you change shipping type in header level, system will check both header and item shipping type before you change shipping type in header level,

2.1 if shipping type in item level is same as header level, item value will be changed also.
2.2 if shipping type in item level is different with header level, you will get message V1 403, and item value will not be changed.

Program: FV45KFKD_VBKD_FUELLEN_KVBKD

IF KVBKD-VSART NE *KVBKD-VSART.
    IF *KVBKD-VSART = VBKD-VSART.
      VBKD-VSART = KVBKD-VSART.
    ELSE.
      DA_ABWEICHENDE_DATEN = CHARX.
    ENDIF.
  ENDIF.

KVBKD-VSART: the header level value which you want to changed into.
*KVBKD-VSART: original header level shipping type value.
VBKD-VSART: original item level shipping type value.

With best regards

Liu jian

When this note is implemented, the business area is no longer placed in
the customer line item in the interface for accounting. The function is
not affected since a substitution or derivation of a business area is
carried out for uniqueness in financial accounting.

SE38 -> LV60BF00
FORM ACCOUNTING_HEAD_LINE

...
   MOVE-CORRESPONDING xaccit_deb TO xaccit.
enhancement-point accounting_head_line_01 spots es_saplv60b.
...
   CLEAR xaccit-gjahr.
*>>>> START OF DELETION <<<<<
   xaccit-awtyp = con_awtyp_vbrk.
*>>>> END OF DELETION <<<<<<<
*>>>> START OF INSERTION <<<<
   CLEAR xaccit-gsber.                                   
   xaccit-awtyp = con_awtyp_vbrk.
*>>>> END OF INSERTION <<<<<<
...

Resolution

To avoid the error F5808 you could consider the uses of
userexit EXIT_SAPLV60B_002 (member of enhancement SDVFX002).

Steps to implement the userexit:

1. Open the transaction CMOD
2. Create a project in the Enhancement SDVFX002
3. Implement the userexit, so that the field GSBER will be filled in
   include ZXVVFU02
4. Save and activate the project.

Please check the following note for reference:
301077 - User exits for the interface for accounting

Hi,

We can use two materials and two pricing condition in one sales pricing procedure by configuration process:

See sales order 5000000000 Material is Finish Goods & it has a BOM.  3000000001 and 2000000000 Materials are BOM sub Item. We can sales this 5000000000 material in SO & 2000000000 materials also in SO. For both materials we can use one sales order pricing procedure.

1. First extend both materials sales view for the sales order.

   2.  For 2 materials create different two item category (ZMSO & ZMTA) and two price condition ZMP0 & ZBP0. Assign condition in sales order pricing procedure (SPRO => Sales & Distribution => Basic function => Pricing Control.)

  3. Create ZMSO copy from TAN & ZMTA copy from TANN. (SPRO => Sales & Distribution => Sales => Sales Documents=>value Contract =>Define Item categories for value contact and contract rel.) Assign Item category (SPRO => Sales & Distribution => Sales => Sales Documents=>value Contract.)

    4. Assign Item category ZMSO & ZMTA under sales order type.

5. Price condition ZMP0 for Item Category ZMSO and price condition ZBP0 for Item Category ZMTA.

  6. If ZMP0 & ZBP0 price condition has same GL then use same account key or GL are not same then create different account key for 2 price condition to assign GL.

  7. ZMP0 & ZBP0 assign in pricing procedure keep option blank for Mandatory, Required & statistic.

  8. In ZMSO item category ZMP0 price condition should be maintain & in ZMTA item category ZBP0 price condition should be maintain.

  9. sales order type pricing procedure:

10. BOM item

11. sales line item

12. ZMSO item category pricing condition

13. ZMTA item category pricing condition

in this way we can add one more price condition for one material in SO

thanks

Md. Enayet Hossain

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)

Reproducing the Issue

                     or

Have you ever heard about mis-communication between the production scheduler and the sales department? The availability check with its rules and conditions is the link. I am mainly talking about order entry here, but, of course, the forecast and setup of MTO vs. MTS are two more areas of friction between sales and production - unnecessary if the right strategies and configuration to support those are in place (an educated user who can execute the functions well, must be the most important part of the whole). 

Now when you enter a sales order into your SAP system, it represents a demand for a sellable product. The sales order is looking to get product from somewhere, so as to fulfill a customers desire to increase your revenue. The sales representative can not possibly understand why the company s/he works for would not deliver the product right away or wouldn't do anything to fulfill the request asap. But there are other goals: a supply chain that is as waste-less as possible, low finished goods inventory, high production utilization, low production cost and a smooth, undisturbed production program. Unfortunately these goals - and the Sales Reps mission - are usually not in line. 

In SAP the availability check is using a rule and may be different depending on the business transaction you perform. In other words: a Sales Order may check differently than a Production Order. The rule by which the check is performed can be assigned in the material master and therefore can differ from one product to another.  This rule, together with the fact that you create a Sales Order, form the framework within which delivery dates with the customer are agreed upon. 

As an example: if a customer wants 50 pieces but there are only 30 in inventory, the availability check finds out for you when the company is able to deliver the goods. In its simplest sense the additional 20 may be delivered after the time it takes to bring them back or at the date when we receive the next batch from production. This is the difference between checking with or without replenishment lead time. 

In the checking rule you can identify what stocks - safety, blocked, restricted - are to be included in the check. It is also possible to specify whether planned orders (firmed or all), production orders, requisitions and/or purchase orders are used to determine the availability date. 

As you can see the choice is ours what we let SAP automatically determine as the date we tell our customer, when they can expect the goods.  But there seems to be a problem. At least I see that quirk everywhere I look: the sales rep is on the phone with the customer entering an order and the availability screen says "you can have 30 pieces today and 20 pieces next week Tuesday." "Great" the customer says and the sales rep saves the order without fixing the date. 

Not fixing the date has no meaning for the sales rep but in MD04 the entire order of 50 pieces stands with a requirements date of today. That means a red light and a signal to the production scheduler to make 20 pieces... NOW ! And tomorrow it means Now! And the day thereafter too. And the customer does not expect the 20 pieces before next Tuesday and is quite happy with that (in the end he won't get them before next Tuesday anyway). 

Would the sales rep have checked on the fixing, we would have seen a delivery for today and another one for Tuesday in MD04 and production would have executed that order, which the availability check saw. The customer would have received what they were promised and the world would have been a little bit better place to live. 

It is incomprehensible to me why companies don't have a policy in place that supports better practices when it's so easy to do. Instead people fight you to the end to not fix the date. I have no clue why but I have customers with whom I have been discussing this issue for years and they still don't do it or only with much reluctance. "What if I have it available earlier ?" they ask. So you really want to have hundreds (if not thousands) of false delivery days per week disturbing your production program, in exchange for that one time chance to deliver on Monday instead of Tuesday? And even then... it's an exception... and those are meant to be handled manually - not the rule. 

Of course, if your availability check produces false results because your basic data setup is incorrect or you mix up MTS with MTO, then you have to do something else and can't fix the date. However, in that case we have to take a couple of steps back and are not ready yet to have production and sales sing to the same song...

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)

Dear All,

As below process we know how can maintian amendment process for Sales during transit.

what is Amendment?

Ans.: Company sales some quantities of product to customer and then customer again want to change this sales option with company. Like On transit first customer want to change delivery qty with second customer by negotiate process. Then this types of process call amendment sales with company.

why is Requirements for Amendment?

Ans.: At present company delivery to customer some product as sales. After delivery during transit customer wants to change some qty with another second customer but challan & VAT already declared for first customer. So Amendment solves this type process issue.

what is the Purpose for Amendment?

Ans.: Delivery challan & VAT challan already declared against first customer. So if second customer wants to take few quantities from first customer, then amendment help to change the delivery & customer balance adjustment process

In below process we can complete an amendment in sales during transit.

Stapes 1:- Standard Sales Order for First Customer

1. Using T-Code: VA01, to create a standard sales order

2. Using T-Code: VL01N, to create a standard delivery order

3. Using T-Code: VL02N, to complete a standard delivery order PGI

4. Using T-Code: VF01 or VF04 to create standard invoice or billing document.

5. Print out: Delivery Loading Advice, Delivery Challan, Gate Pass and Vat Challan for first customer.

First customer take the delivery and come out from company but any reasons now second customer should take the delivery or partial delivery qty from first customer.

Stapes 2:- Amendment Sales Order for First Customer

6. Collect the first customer delivery’s invoice or billing document number.

7. Using T-Code: VA01, to create an Amendment sales order against first customer, then put the billing document number in Billing reference document dialog box and click copy to open the amendment sales order. Then put only amendment qty on the sales order line item, check document date, pricing date and save the amendment sales order.

8. Using T-Code: VL01N, to create a standard delivery order for Amendment Goods qty received. Using T-Code: VL02N, to complete a delivery order for PGR (Post Goods Received).

9. Using T-Code: VF01 or VF04 to create standard invoice or billing document. (Here invoice or billing document creates under Amendment Sales Order), so customer balance should be directly credit from customer GL.

Stapes 3:- Standard Sales Order for Second Customer

10. Using T-Code: VA01, to create a standard sales order

11. Using T-Code: VL01N, to create a standard delivery order

12. Using T-Code: VL02N, to complete a standard delivery order PGI (Post Goods Issue)

13. Using T-Code: VF01 or VF04 to create standard invoice or billing document.

This way we can easily amendment sales delivery qty from one customer to another customer on transit or during shipment.

With the best regards

Md. Enayet Hossain