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.
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 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.
THE BASIC ONES
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.
PURCHASE ORDER DATES
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.
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.
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.
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.
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.
Date fields in Sales Documents 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.