It’s not uncommon for me to receive questions regarding date fields on SAP Sales Orders. That should not be surprising considering that users will be confronted by no less than 10 date fields during normal order maintenance. That number can rise to more than 15 depending on how you slice the numbers. In this article, I will explore these date fields and how they impact other activities. Read on for more on Sales Document Date Fields.
NOTE: To simplify things, I’m going to only address the standard Sales Order screens — VA01, VA02, and VA03 — though, many of these dates will also appear on other document classes.
Since sales document date fields appear on all three layers of the Sales Order — Header, Item, and Schedule Line — and since there is a lot of overlap between many of these fields, it makes sense to organize this discussion by function.
Basic SAP Sales Document Date Fields
Let’s get s a few basic ones out of the way. The Created On date is the date that the sales order was saved to the database. Not much else to say on that one. It’s worth noting that there are also Changed On dates available in the header table (VBAK) and line item table (VBAP), though these aren’t available in VA01/2/3.
The Document Date is found on the header -> Sales tab. The primary function of this date is to control when a sales document appears in management reports. In SAP’s own words, the document date is “the date on which you want the sales document to become effective for sales management purposes”. Typically this date is set to the Creation date.
SAP Customer Reference Date Fields
The PO fields are typically some of the first fields entered during order entry. PO Date fields exist at both the header and item levels. Why? SAP doesn’t assume that you have a strict 1-PO-per-order structure.
You are allowed to group multiple PO’s into the order by maintaining separate PO numbers and dates on each line item. In most cases, SAP will still expect you to have a PO number and date on the header, but you can change the item-level dates on the Item Overview, Sales, or Procurement tabs.
Traditionally, the PO date will correspond to the date that the customer created the PO in their system. When it comes to the actual functionality behind the PO date field, there’s really not much to it. You input the date and SAP saves it. It may appear on some standard output such as Order Acknowledgements, but I am unaware of any other use for it.
You do have the option to default the PO Date to the current date; this setting is located on the Sales Document Type configuration screen in the IMG.
SAP Pricing Date Fields
The Pricing Date is used by SAP to determine pricing conditions and exchange rates for the document. You can think of this date as a “Pricing Valid On” date — only those pricing conditions valid on this date will be adopted on the document.
In most cases, the document’s pricing date will default to the Requested Delivery Date (more on that field later). But the default pricing date can be changed on the document type configuration screen to use either today’s date or the Requested Delivery Date. Alternatively, Sales Documents with validity periods can also use the Valid-from Date or the Contract Start Date. In any event, the user can manually overwrite the default pricing date on the order. This, however, should probably be discouraged unless a valid reason exists for making this sort of manual change.
The Pricing Date is automatically adopted by the invoice in the billing process. However, you can specify a new Pricing Date manually in both VF01 and VF04 transactions. Keep in mind that this could impact pricing; changing the pricing date from the original document will trigger repricing for that billing document.
SAP Logistics and Delivery Date Fields
Here’s where things get interesting. One of the more complicated date-related functions on the sales order involves determining when your customer receives their deliveries. It’s complicated due to the amount of integration: material master values, MRP, ATP, the factory calendar, customer calendars, shipping point settings, etc. I’ll try to break this down into bite-sized chunks for easy absorption.
It all starts with the Customer Requested Delivery Date — labeled as “Req. deliv.date” on most screens. In most cases, this should default to the current date, but controls exist to change that proposal. First, you can opt NOT to have a default date at all. This is located on the order type configuration screen in the IMG. On the same screen, you can also specify a lead time in days that will act as a buffer. In other words, a lead time of ‘1’ will propose tomorrow’s date (or the next business day) as the customer’s requested delivery date.
SAP will attempt to confirm all shippable items for the Customer Requested Delivery Date. A schedule line is created for each line item with the CRDD maintained. As each item is entered, the ATP process will run to see whether or not the date can be met. If so, the single schedule line is confirmed. If not, then secondary schedule lines are created with dates on which the product CAN be confirmed. These proposed dates are dependent upon several factors. I won’t go into detail on each item, but here’s a short list:
- ATP Configuration – Determines, among other things, what sources you consider when looking for incoming inventory.
- Material Lead Times – Expected lead times when purchasing or manufacturing a product. Also includes goods receipt lead times and QA lead times.
- Shipping Lead Times – Time required for picking, packing, loading, etc. I’ll discuss those in the next section.
SAP considers all of the above and then determines one or more product availability dates. It is possible for SAP to determine several additional schedule line dates. For example, if the customer requested delivery for this week (SL #1), but 1/2 of the product will not be available until next week (SL #2) and the remainder will be available the week after that (SL #3). In this example, you would see three separate schedule lines with three different dates.
SAP First Date
I’ve been getting a lot of questions about the ‘First Date’ field. The ‘First Date’ column appears on the main Sales Order screen in the item list. This value simply corresponds to the first schedule line date for the item. In most cases, the values in this column will equate to your Customer Requested Delivery Date (CRDD). As you may have guessed, changing the First Date value on the main sales screen will just change that schedule line date. Nothing too magical.
SAP Sales Order Scheduling Dates
Since we’re on the topic of Schedule Lines, it makes sense to dive a bit deeper. You can double-click a schedule line to pull up the schedule line details. The Shipping tab reveals some additional dates used for logistics planning. These dates and times all deal with lead times for the performing of specific shipping tasks. Let’s discuss them one at a time starting with the bottom one.
The Transportation Planning Date is the date by which the planning must be completed in order to ensure the delivery is received/shipped on-time. This date can be based upon a lead time in the route which is useful when, for instance, a carrier requires notification ahead of time. A basic example would be a trucking company that requires at least 5 days notice before committing to a pick-up.
The Material Availability Date can also be considered the Picking Date. This is the date on which picking should begin in order to meet the subsequent deadlines. Similar to the Loading Date, the amount of time estimated for picking is controllable through the Shipping Point configuration and can consider several criteria: Shipping Point configuration and Route settings are two examples.
The Loading Date is the date/time on which loading should begin. The amount of loading time can be determined from a combination of the Shipping Point configuration, the Loading Group of the material, and the Route. Picking and Packing must be completed by this date/time. Since the route is a major input to this date, SAP will assume zero lead time if a route is not specified.
The Goods Issue Date is the date on which the goods must physically leave the shipping point. This primarily takes into consideration the customer requested delivery date and the transit time required for the delivery. The latter of which is dependent upon the route. If no route is determined on the sales order, SAP assumes zero transit time.
Lastly, you arrive at the Delivery Date. This is the date and time that the customer expects the item(s) to arrive at their desired location. This date, of course, must take into account the transit time between the point of origin and the destination. The most common way to take this time into account is by using settings on the Route.
SAP Sales Order Billing Dates
In common terms, the Billing Date is the date on which the billing document is to be generated. Of course, there are several places you will find a “Billing Date” field. The most common Billing Date you will see is on the ‘Billing Document’ tab in the header of the sales order. This billing date is then copied to the item level where it can be freely maintainable if you wish to maintain the date manually. This would make the most sense in an Order-related billing process in which the billing document is generated directly from the Sales Document.
For a Delivery-related process, the actual date of the invoice typically depends upon the delivery’s Post Goods Issue date. That being the case, the Sales Order ‘Billing Date’ fields are pretty much moot.
If you are billing for a Service without a delivery, there is a separate date field called the Service Rendered Date which is located just below the Billing Date. In standard SAP processing, the system will propose the service rendered date instead of the sales order billing date for this scenario. Just to complete the loop, if a service is delivered alongside physical products on a delivery then the PGI date will be proposed for the Services Rendered date.
Finally, you will also commonly see Billing Dates on a Billing Plan. I won’t delve into Billing Plans in this post — we would be here forever — suffice it to say that a Billing Plan is a schedule of billing dates on which billing documents are to be created. Billing plans are commonly found on certain types of contracts, or sales orders intended to structure larger projects which are invoiced in a particular way. Let’s talk about these date fields:
Start Date and End Date fields are fairly self-explanatory. They determine the duration of the billing plan. In the case of contracts, this will normally correspond to the validity period on the contract header.
The Dates from and Dates Until fields can be used to adjust the billing schedule for a single line item. This would most often be used in conjunction with a Header-level Billing Plan.
The “Dates” portion of the screen contains individual line items with Settlement, To, and Billing Date fields. The Settlement and Settlement To dates represent the billing period for the item. The Billing Date will correspond to one of these dates depending on whether the billing is to be performed In Advance or not.
See Also
If you’re interested in SAP Sales Document date fields, you may also be interested in…
- My infographic on SD Logistics Scheduling.
- More information on SAP Scheduling in SAP Note 1644765 (Link)
Summary
Sales Document date fields are really easy to gloss over. Most users just stick to the ones they need for their own purposes. With as much integration as there is in SAP, it’s difficult to talk about dates without jumping around from object-to-object. I hope that this nicely summarizes what’s going on in the background and can at least act as a starting point for exploring date-related scheduling options to improve your process.
Hi Michael,
The business which I work at is in the process of getting the entire organisation to use SAP. One of the major issues I have come across so far, in my role within the orgnisation is in relation to accrual/pricing condition trigger points.
According to your page, you mentioned that the pricing date is the date which will trigger any accruals or discounts which are set up. Is this true for all versions of SAP? Can the date which triggers these conditions be changed by default to the requested delivery date?
I ask, as this appears to be the current situation where I am employed, and both myself and a colleague, based in Australia, having been arguing with our IT department based in Europe about this, but are told that it is a SAP setting that cannot be changed?
Would be great to hear what you have to say on this matter.
Regards,
Russell
Hi Russell,
YES! The Pricing Date that is proposed can be defaulted to:
o Today’s Date
o Requested Delivery Date
o Valid-from date (Agreements)
o Contract Start date (contracts)
To make this configuration change, you just need to change the Sales Document Type configuration setting for the “Prop.f.pricing date”. This is located in the section titled “Requested delivery date/pricing date/purchase order date”.
…and fire your IT department. 😉
Michael
Hi Michael, I recently joined a new company but doing almost the same tasks. However, I was surprised to find out that they are not keen into changing or updating the required delivery date even if the new delivery date is the one requested and agreed upon with the customer (can be due to receiver’s WH space availability or supply issue). I am aware that the tracking of OTC KPI also uses the required delivery date as basis – please correct me if I am wrong. Can you shed light on the importance of having the sales order updated accordingly and accurately?
Hi Michael, I created 2 date determine rules in OVBS .
– ZI Annual Billing on First of Month
– ZJ Annual Billing on Last of Month
My client wants to make ZI as a default by either specific customer or Sales item category. Our billing is driven by milestone billing plan.
Is there a standard way to make ZI as a default?
Thanks. for you help.
That was an awesome explanation, and great effort. Could you pls throw some light on What’s the first date and the relation of it to RDD field in initial SO screen .
Your explanation about transportation dates let me to resolve an issue here. Really thankful with you.
Thanks for your message! I’m glad you found some value. -Michael
Hi, We are trying to figure out what is the “first delivery date” is on the line items of a quote. By default, it is the Req. del. Date but it is a changeable field. Any ideas?
We want to know what drives the Org. Del date on the Sales Order.
Michel, thank you for the comment and apologies for the delayed response. I assume you are referring to some values that are displayed on a Quote output; please correct me if I’m wrong. The “first date” will most likely refer to the first date that SAP can commit some quantity of the respective item. If product is available, this will probably match the customer’s requested delivery date. If a customer requests delivery today but product is not available, the “First Date” will be the date that SAP calculates the product can be made available (via Purchase, Production, or Stock Transfer) to ship. For more information on this, you can research ATP. Does this make sense?
Thanks Michael. Your article is very insightful. I did understand one thing. In some of the cases First Date is before Requested Delivery Date. What does it mean then?
Hello, Dhananjay. Thanks for your question. In standard terms, the “delivery date” in SAP represents when the customer wishes to take receipt of the goods at their location. The ‘First Date’ represents the scheduled ship date or planned Goods Issue date. If there is any transit time factored into the delivery (via a route, for example) then the First Date will occur before the requested delivery date. I made this infographic to explain these logistics dates which can be found on the Sales Order schedule line.
Hi Michael
Your article is very insightful, could you clarify this question for me
Regarding RDD, when you said “In most cases, this should default to the current date”
But as per my understanding RDD is the date on which customer wishes to receive goods. How can we deliver a product on the same day the order is created.
We have a very dynamic delivery processing, where in we try to upgrade carrier to overnight shipping when the RDD is 1 day (if the material is available), so am trying to understand these subtle nuances.
Thanks
Bramra, Thank you for your question, and my apologies for the late response. You are correct! The Requested Delivery Date (RDD) is intended to be the date on which the customer would like to take receipt of the goods or services. Typically, a Customer Service / Order Entry person will get that date from the customer and manually make adjustments to the Sales Order field. However, in many cases the customer wishes to have the goods as soon as possible (or “Yesterday” in some cases). If this is the case, you can leave the RDD as Today’s Date. It all has to do with scheduling. SAP will first attempt to perform Backwards scheduling — start from the RDD, factor in transit times, loading time, pick/pack time, etc. If the “start date” is in the past, SAP will then switch to forward scheduling and propose dates based on this same information starting “Now” and progressing forward. Does that answer your question?
Good morning. I understand that the required date and first date change the schedule line dates. From there, isn’t the schedule line date connected to when POs are placed in purchasing and when production orders are released?
Hello Linda and thank you for the comment. I believe the most important schedule line date for MRP / Purchasing is the Material Availability Date. This is the date that goods must be in stock and freely available. Purchasing should take this date into consideration; procurement lead time, delivery time, and goods receipt time must all occur by the Material Availability Date on the Schedule Line. I hope this helps.
Thank you. From what I can see, the first day drives that material availability date. I will look into it further. Thank you again for your help.
The first date is simply the schedule line date on the first schedule line. Without the lead times maintained for all those steps, it can be difficult to know what’s driving what. You’re on the right path! Good luck!
Hi Michael, Our company wants the price on the sales order and subsequently on the invoice to be equal to the ship date of the order which equals the planned PGI date. How would you suggest to make that occur? I see in the configuration almost every option EXCEPT the planned PGI date. Appreciate any suggestions. Thanks!
Hi, Stephanie. I think the problem with the ‘planned GI date’ is that it is a line item date. You could have 10 line items each with its own planned GI date. While it’s possible to have item-level pricing dates, this would make pricing a bit unpredictable and, in my opinion, tougher to manage. You can do this with some custom code on the Sales Order; that’s the only way I can think to achieve this type of solution. The dates proposed in config for the default are all header dates. The closest one to your requirement is probably the Customer Requested Delivery Date. This would calculate pricing based on the date the customer wishes to take receipt of the goods. Regarding the invoice, you can influence the pricing date during invoice creation and you have the option to perform pricing re-calculation during invoice creation too. The assumption for re-pricing is that you’re ok with potentially a different price than what’s on your Sales Order.
Hi Michael, is it possible to prevent the schedule line’s [Material Availability Date] from not getting automatically updated when the user changes the schedule line’s [Delivery Date]? It seems to always recalculate backwards and any manually maintained [Material Availability Date] is wiped out irrespective of whether the shipping point is configured to have “No loading time determination” and “Pick/pack time not determined”. I’d like to keep the manually set [Material Availability Date] as long as the [Delivery Date] is only moved around and remains later or requal to [Material Availability Date].
Hello, Pierre. Is there a particular reason why you wish to manually select the Material Availability Date? This field is calculated by SAP based on system lead times to ensure that the materials is available when needed. I have never heard of someone wishing to manually have control over that specific date. You can try to use the “Fix Dates and Quantities” flag on the Schedule Lines tab which should allow for greater manual control over those dates, but just be aware that this checkbox will prevent SAP from making any automated adjustments. I don’t recommend that unless you truly want to have manual scheduling for that line item.
The “fix date and qty” flag doesn’t appear to change the fact that the [Material Availability Date] is recalculated / overwritten every time the [Delivery Date] is changed. The use case here is project specific equipment which has a clear deadline by when to be produced by, e.g. [Material Availability Date], in order to host a factory test witnessed by the customer. However, the unit may then be sent to an external warehouse for packaging and variable storage duration. Hence, the [Delivery Date] might move around quite a bit depending on conversations with the customer, but the [Material Availability Date] should remain constant. Since the time difference between [Delivery Date] and [Material Availability Date] varies by project, we do not use any Route or defaulted time shifts. Consequently, the manually maintained [Material Availability Date] gets overwritten every time someone moves the [Delivery Date].
By default, most sales orders have delivery scheduling active. According to SAP: “When you specify delivery scheduling, the system automatically determines the pick/pack time and the loading time for each schedule line, according to shipping point from which an item is shipped. The system uses the pick/pack time and the loading time to help determine the material availability date and the loading date respectively.” This means that, with delivery scheduling active, the sales order will always try to determine those dates automatically. This explains the behavior you’re seeing. In a reference system, I’ve tried switching off Delivery Scheduling, but I am unable to maintain the MAD separately. I don’t think this is a viable solution to meet your needs. I don’t recommend trying to use custom logic to affect those dates. What are you using to capture production activities? Production Order? Project Systems? I recommend trying to use those objects to capture activities relating to interim production steps (i.e. customer test) and only use the Sales Order to capture the final delivery to the customer. In fact, Project Systems may be a good option if there are various types of milestones relating to delivery of the final product.