SAP: Exploring Backorders (Part 2) – Rescheduling

In Part 1 of this series, I provided a basic definition for backorders, highlighted some standard tools in ECC to report on backorders, and recommended some high-level approaches to resolving backorder problems.  In this article, I address one of the main tools for automating the process of re-balancing material confirmations:  V_V2.

What is V_V2 Rescheduling?

V_V2: Rescheduling Selection Screen
V_V2: Rescheduling Selection Screen

In a backorder situation, you typically have a dilemma:  Who gets the limited quantity of product I have on hand?  There are, of course, many answers to this question depending on who you ask.  Sales reps and Customer Service will often fight vigorously for their preferred accounts.  Unfortunately, SAP can’t resolve these disputes.  But what if you wanted to setup a policy to automatically re-schedule product confirmations based on Sales Document criteria?

If you are constantly struggling with meeting demand, SAP’s backorder re-scheduling program (transaction V_V2, program SDV03V02) can alleviate some symptoms.  There is an important distinction to make:  V_V2 should not be considered a “solution” per se; if you find yourself heavily relying on this functionality there could still be some work to do up-stream to improve production capacity, formulate more accurate demand forecasts, or optimize stock on hand.  But there are situations where sudden spikes in demand happen and decisions must be made.  Let’s look at a simple example to illustrate what can happen.

MD04: Stock Requirements showing the competing orders
MD04: Stock Requirements showing the competing orders

Throughout the day your organization is receiving orders for product.  As the orders are saved, available product is being allocated through the use of Confirmations (visible in MD04).  Let’s say you have a product with 20 PC available in inventory.  A customer places an order in the morning for all 20 EA but does not wish to take delivery for two weeks from now.  A confirmation is made and your available quantity effectively goes to 0.  Later that day, another customer places an order for 5 EA of that same product and they need it ASAP.  In this case, the availability check will fail and the item will be considered back-ordered.

V_V2: Results showing confirmations (Before changes)
V_V2: Results showing confirmations (Before changes)

How can this happen?  You have 5 EA that will sit on the shelf for two weeks while MRP will direct you to purchase or make 1 EA for the more urgent customer order.  Regardless of the customer or the urgency of their need, the pre-existing confirmation will trump the subsequent order.  The V_V2 report is designed to address this.

Backorder Rescheduling evaluates existing material confirmations and backorders and shifts confirmations based on criteria you specify in the report parameters.  You can prioritize confirmations based on 5 criteria:

  • V_V2:  Sort Order Parameters
    V_V2: Sort Order Parameters

    Document Category
    Determines whether you wish to Sales Orders or Stock Transports higher priority.  In most normal cases, you would probably specify Sales Orders, but requirements can vary.

  • Delivery Priority
    Prioritizes Sales Documents using the Delivery Priority field on the Sales Document Item (VBAP-LPRIO).  The delivery priority is a two-digit numeric field with configurable values that determine the priority of Sales Order items during delivery processing.  The Delivery Priority can be set on the customer master as a defaulted value on the Sales Order, but is typically manually adjustable on the Sales Document.
  • Date
    Choose either the date the item was created (VBAP-ERDAT) or the earliest Schedule Line Date (VBEP-EDATU).  Using the Schedule Line date will consider the customer’s requirement.
  • Document Number
    You can use the Sales Order document number to control confirmation allocation — the lower number takes priority.  This is to basically serve as a tie-breaker; since no two documents can share a number this will make sure there are no “ties”.  You must obviously consider document number ranges if you decide to seriously consider using this criteria.
  • Document Item
    This goes hand-in-hand with the Document Number.
V_V2:  Results After Sorting by Schedule Line Date
V_V2: Results After Sorting by Schedule Line Date

You simply mark each ‘Priority’ field with a value between ‘1’ and ‘5’ to designate your desired sort sequence.  In the case of backorders, you would probably want to consider ‘Date’ and ‘Document Category’ among the most important along with ‘Delivery Priority’ if used.  Of course, you don’t have to take all the criteria into consideration; you can use a ‘0’ (zero) to denote values not to be considered.  I recommend exploring the use of the Delivery Priority field to allow users to manually control which orders get priority.

V_V2:  Additional Options
V_V2: Additional Options

In addition to the criteria listed above, there are some basic parameters to allow you to restrict the report to only sales orders or only purchase orders (STO’s).  When enabled, the ‘Unconfirmed Documents Required’ option will ONLY modify confirmations for materials which have unconfirmed lines.  I recommend leaving this checked as it will only impact those items which are truly backorders.  Lastly, there is a ‘Simulation’ mode which is handy for gauging the results of your selected criteria.  Always use simulation mode before making changes.  It’s there for a reason.

The report results will show you the changes that will be made using a logical “Old Value”, “New Value” format.  If a confirmation is changed, you will see a reduction in confirmation quantity for some items and an increase for other items.

Scheduled V_V2 Jobs

As with many other processes in SAP, the V_V2 transaction (program SDV03V02) can be scheduled to run periodically in the background.  There’s not much to it.  You can use the program’s Program -> Execute in Background menu option, or you can save your program variant and setup a job directly using the program and variant name in SM36.  Just remember to un-tick the ‘Simulation’ box before saving your variant.

Excluding documents from V_V2

It’s worth noting that Sales Document items with the “Fixed date and qty” indicator activated are excluded from V_V2.  In a backorder situation, SAP’s Availability Check should provide a confirmation date in the future based on other criteria, like lead times, production schedules, or inbound PO’s.  If the customer is willing to accept the proposed confirmation date, you can “fix” the dates and quantities with that checkbox.  In that case, SAP will not try to re-schedule delivery.  Otherwise, the assumption is that an attempt will be made to expedite processes to meet the customer requested delivery date thus leaving the confirmation date and quantities somewhat flexible.

V_R2 – Rescheduling: Evaluation

A program exists that allows you to recall the last V_V2 run by plant and material.  The V_R2 transaction (a.k.a. “Rescheduling of sales and stock transfer documents:  Evaluation”) allows a user to input some basic selection criteria — material, plant, dates, etc. — and review the results from the last rescheduling run.  Report results can be quickly filtered by Improvements (confirmation quantities increase) or Deterioration (confirmation quantities decrease) by clicking on those respective buttons.  You can also jump into the document (Sales Order or PO) in change mode by double-clicking the item.

Partial Confirmations in V_V2 Rescheduling

Default Values for Availability Checking
Default Values for Availability Checking

By default, the V_V2 process will not make partial confirmations.  You may have noticed that in the above screenshot showing V_V2 results AFTER sorting by Schedule Line Date, the later order’s confirmation went from 20 to zero and not 15.  I guess SAP doesn’t want to make any assumptions about whether you wish to do a complete delivery vs one-time delivery vs multiple-shipments.  However, you can influence this by selecting the appropriate Default Values for Availability Check.  You’ll find this setting in the IMG:

SPRO -> Sales and Distribution -> Basic Functions -> Availability Check… -> Availability Check -> Availability Check with ATP Logic… -> Define Default Settings

This function is similar to the Availability Check screen you encounter in VA01 or VA02; it allows you to default an approach for the availability check:   One-time delivery, Full delivery, or Delivery proposal, for example.  But, please keep in mind that this may impact the availability check for VA01 and VA02, so be sure to test this after making changes.

Additional Information

If you’re curious to learn more about V_V2, check out these resources:

  • SAP Note 1861066 – Everything about SDV03V02 / transaction V_V2
    This SAP Note has a TON of information on the process.
  • SAP Note 1588423 – V_V2 / SDV03V02 – Unconfirmed documents required
    More information on the ‘Unconfirmed documents required’ tick box.

WRAP IT UP

While not ideal, rescheduling is a necessary evil for many organizations.  It’s a great way to re-balance your confirmations using a repeatable policy.  Are you planning to use the V_V2 rescheduling process?   What type of backorder issues are you hoping to resolve?  Let me know in the comments.  …and stay tuned for Part 3 where I will highlight some other backorder management tools.

39 thoughts on “SAP: Exploring Backorders (Part 2) – Rescheduling

Add yours

  1. Hi Michael very interesting your place….., i try to search a few transaction to view the historical back order and when is available again for periods or months but i don`t find transactions to obtain this results, you have knowladge about.

    thanks

    1. Jaime, thanks for reading my article. It sounds like you are looking for an availability check. If so, then please try Co09 or MD04 to see available quantities and planned goods receipts. I hope this helps. -Michael

    1. Hello Ria. Thanks for the comment. There definitely is a connection between MRP Areas and the ATP/Availability check process. I’m not an expert, but I think this SAP Blog post contains some great information on this relationship. Let me know if this helps.

  2. Good job Michael, congratulations.

    I can define new delivery priorities with 2 digits which can be used this whay in Customer master.
    But in V_V2 the Delivery priority field just allow 1 digit.
    I would like to reschedule groups of Customer one at a time using 2 digits here.
    Please, do you know if this is possible?

    Thank you,
    Renato

    1. Hello, Renato. Thanks for posting your comment and question. The fields in the V_V2 report for Document Category, Delivery Priority, Date, Document number, and Document item are simply a sort criteria. This is where you indicate the sequence to be used in determining which order lines get the confirmation. The delivery priority will always prioritize where the lowest number (i.e. ’01’) takes precedence over higher numbers (up to ’99’). I hope this helps. -Michael

  3. Hi Michael, This document is great, but when you get down to creating deliveries for your warehouse, the allocation gets blurred because of shipping point sequencing, how do you correct for this where you Re-scheduled successfully, but then also manage delivery generation so it aligns with the re-schedule run? As we have multiple shipping point, the first shipping point run, will consume the inventory even though you have scheduled the secondary shipping point for priority of inventory.

    1. Hi Jonathan. Thanks for the question. Please clarify: you’re saying that you have, for example, one sales order each in two shipping points and both sales orders are confirmed for the same date? But there is insufficient available quantity to satisfy both? It seems like one order should be confirmed and one should not. Am I understanding this correctly?

  4. Hi Michael,
    Thank you for the useful information on back ordering. Do you know if SAP has the functionality to calculate the customer backorder rate? If so, would it be considered standard or custom?

  5. Hello,

    i found your articles as very helpfull in some cases, for instance about cumulative update of price condition (i had to program adaption at the end). With transaction from this article i havedifferent experiences, some customers they are running V_V2 like “crazy”. With one of them i have a problem, that when they run transaction on some days in week, transaction is deleting sch. route VBEP-AULWE out of schedule lines. Is there any kind of “setup” for v_v2 to avoide this-keep route schedule as it is?

    Thank You, Slavko

    1. Hello SLavko. Unfortunately, I have not worked with any clients who use Route Schedules so I have not seen this issue. Perhaps check support.sap.com to check for notes? Incidentally, I will be implementing Route scheduling with a client in the coming months; what are your thoughts about it?

      1. Hello. We found out, what was the main reason for sheduling route deletion. In case, that shipping point is not equpied with all data (eg factory calendar, working times), scheduled lines have dates (delivery, commisioning, loading,..), but fine termination times (eg hours for loading) are “zeroed” , causing delete of scheduled route. Otherwise, route scheduling has some limitations (see note 146829 – Process flow of route schedule), that can be avoided, but quite a large amount of programming is needed (for instance frequency of scheduling not larger than a week, scheduling agreements for automotive,..) to have a solid solution for routing.

  6. This is a great article!! Thank you so much for taking your time to share this knowledge!
    Stumbled upon it while researching a weird issue, where V_V2 batch job is deleting and re-creating Production Orders that were already in place. Have you by any chance ever seen that happen before?

    1. Thanks for visiting and sharing your question. I have not seen that behavior before. I suspect that it is not the V_V2 program.that is the problem; it’s probably something to do with how the Sales Order is reacting to the new confirmation dates. I would check the transfer of requirements settings for the order. Good luck!

  7. Hi Michael,
    I created scheduling agreement with schedule lines having deliveries in future, ATP confirms all the quantities and then I create a sales order which has required delivery date today, when I run V_V2, I gave the sort criteria” Date- sort by delivery date of earliest schedule line”, I expected the system to remove the confirmation from scheduling agreement and confirm it to the sale order, however the system doesnt do anything.

    1. Thank you for the question, Neelima. It sounds like you expect a separate Sales Order to be confirmed. I think I would need to know a bit more about your process flow. I have only worked with Scheduling Agreements which create deliveries directly — without an additional Sales Order in between. I think you may need to check the Transfer of Requirements settings to see what’s being passed to MRP. You would need to find a way to get the transfer of requirements from your SA to MRP for planning purposes and then have that moved to the Sales Order for order fulfillment. Honestly, I’m not 100% sure how to do this without more research.

  8. Hello Michael,

    your articles stand apart and explains the topic in the manner no other technical articles would do! thanks!

    I have one query though as I came across this one while searching solution for one issue with my customer. There has been history of SOs of past 4-5 months where certain SO lines loose confirmation and those quantities get assigned to other orders which were created after that order. Delivery priority, credit check status, document category – everything is same amongst them. There is no justifiable reason why certain orders should suddenly have unconfirmed lines and the qty should get assigned to other orders.
    My question is – can the V_V2 program also delete the schedule lines already confirmed on existing orders or its mere job is to assign the qty to unconfirmed lines from new available stock (without touching the old confirmed orders) ?
    thanks
    Binita

    1. Hello, Binita, and thank you for the great feedback on the article. The answer to your question is this: V_V2 can result in confirmations being reduced or removed entirely. Based on the criteria used in the report, the program can shift confirmations from one Sales Order to another — or even from Sales Order to Purchase Orders in the case of STOs. For example: it is August 4th as I write this reply. Let’s say we have 10 items in stock. Today, a customer places an order for delivery on Monday, 15 August for those 10 items. The availability check is performed successfully and the confirmation of 10 is made. Later this afternoon, another customer places an order for 5 of those items and they have requested delivery of those goods on Monday, the 8th of August. Since the 10 items are confirmed to another order, the Availability check cannot make the confirmation as requested (perhaps a date in the future is proposed by SAP based on a production lead times). The V_V2 report can be run to prioritize the Customer Requested Delivery Date above all other criteria. When this is done, the first order’s confirmation will be reduced by 5 units and the second order is confirmed for 5 units on the date originally requested. Depending on business rules, this may or may not be the desired result. Close attention should be paid to the way the V_V2 criteria is specified. It’s worth nothing that there is a flag on the Sales Order Item Schedule Lines tab called ‘Fix Dates and Quantities’. This flag accepts the current dates and confirmation proposed on the Sales Order and that item will NOT be affected by the V_V2 report. I hope this helps. -Michael

      1. Hello Michael

        Thanks for your prompt help!

        I did notice this sentence in your explanation and that is where my issue lies : The V_V2 report can be run to prioritize the Customer Requested Delivery Date above all other criteria.

        If you notice the standard V_V2 selection criteria, it says ‘Date of ‘sort item by date of creation’ gets prioritized over ‘Delivery date of earliest schedule line’ (and this is how our customized background job also runs it).
        Does this mean the sales order which is created first will always get confirmed first even if the order which is created later has an earlier requested delivery date OR first schedule line date than order created before it ? if yes, the order in your example with RDD of 8th Aug will not get confirmation as per this V_V2 sort criteria – right ? (Pls note, our checking rule does not consider RLT or incoming PR or PO. only real stock sitting in plant gets allocated everyday). I basically want to know if ‘item by date of creation’ does mean earlier created order gets confirmation first ?

        thanks
        Binita

        1. Hello again. I think you are spot-on. The ‘Date of’ options allow you to prioritize line items by either the date the line item is created, or by the date of the first schedule line for the item. The date of the first schedule line will TYPICALLY be the customer requested delivery date — when the customer wants the items. If you have no RLT, then there will be only one schedule line with a confirmation quantity of zero, but the date is still considered by the V_V2 program. -Michael

  9. Hi Michael, great article. I recently had to take a company that was already ‘live’ with a convoluted mess and get checking groups synchronized and all the needed batch jobs scheduled. We are basically re-allocating everything nightly due to changing situations and chaotic workpractices. My question for you: do you have any experience or lessons learned from customizing V_V2? My company is confirming SO’s and STO’s and would like a stratification of priority: Sales Orders due 1 week out, then STO’s due 1 week out – then SO’s due 1 – 3 weeks out, then STO’s 1-3 weeks out, etc… We are also dealing with ‘Mixed MRP’ where we have reservations and dependent requirements competing for the same material confirmations. I know the program doesn’t even attempt to address these (use COMAC instead, yeah…) I know SAP intends for customers to make changes to this program, but have you seen anyone go to elaborate lengths to turn V_V2 into the ultimate gatekeeper of all confirmations?

    1. Hi, Matt. Thanks for the question. The short answer to your question is no, I have not seen any of my clients make modifications to the way V_V2 functions. So, unfortunately, I can’t offer much advice if that is the path you wish to go down. Out of the box, V_V2 allows you to include or exclude STO’s and prioritize between the two. Also keep in mind that STO’s can have a Delivery Priority value just like customer Orders, in case that allows for some added sorting. Your idea about layering requirements based on week (T-1 week, T-3 weeks, etc.) is interesting, though I’m not quite sure how you would execute it. You could always experiment with creating deliveries longer in advance to effectively firm those up sooner. I doubt any of this is helpful. LOL

  10. Hi Michael,
    Great work – thanks for this content!
    A question – let’s say I want to reschedule sales orders every 20 minutes but also want to set up different background jobs for each delivery priority at different frequencies/times (prio 1 every 30 mins, prio 2 every 1 hour and so on) . Will there be a poblem if for some reason the rescheduling job overlaps with any of the delivery creation jobs? How can we avoid that – any inputs please?

    1. Hi, Atul. Thanks for the comment and question. As you suggest, the rescheduling job is closely related to the delivery creation job. Rescheduling can impact which deliveries are included in the job. I recommend considering executing the rescheduling and delivery creation in the same job. The delivery step will be executed immediately after the rescheduling step. This way the deliveries created match exactly what was prioritized during rescheduling. Do you think that will satisfy the requirements?

What say you?

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑