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
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
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.
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
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
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
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
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”
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.
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
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.
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?
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
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.
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?
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?
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?
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?
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.
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?
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!
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.
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.
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
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
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 ?
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
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?
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
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?
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?
Great job!
Thanks for the feed back!
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
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
Nice Article with deep insights
Thank you so much for the feedback.
Hello Michael,
Would you please help me, how does V_V2 work for those materials with MRP Areas.
Thank you,
Ria
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.
Good explanation Michael.
Thanks for visiting, Rosh.
Good reading thanks. Looking fwd to part 3.
Thanks for commenting, Tom. Not sure when part three will be out. Will take a look and see.
Hi Michael, great job indeed
Thank you for the feedback, Claudio.
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
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
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.
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?
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?
Thanks for the comment. If you’re talking about KPI’s or metrics, I feel that this would be a custom calculation or report.
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
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?
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.
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?
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!
Fantastic. This really helped me in my PPT. Would love to learn more about this.
Thank you for the feedback. I’m glad you found it useful.
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.
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.
Easy to understand and very well written.
Thank you for the great feedback!
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
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
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
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
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?
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
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?
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?