Share this article
Introduction
Today’s article will discuss the topic of calculating receipt dates (for goods or services) that appear on purchase documents. Using a Purchase Order document as an example, I will explain the relationships between various dates, i.e., how changing one affects the values of the others. I will also highlight which field values and settings in the application influence the calculation of purchase receipt dates.
At first glance, the topic seems quite simple – just the dates in the header and lines of the purchase document showing when the goods (items) will be received. However, the multitude of parameters that influence the application’s automatic calculation of these dates and the interesting relationships between dates mean that when we delve deeper into this issue, we discover an extremely useful functionality for the user’s daily work that can serve, not hinder.
The functionality is described in the BC documentation: Calculate Dates for Purchases ↗. A training module on estimating purchase order receipt dates is also available: Estimate purchase order receipt dates in Dynamics 365 Business Central ↗.
Purchase receipt date fields
Let’s start by standardizing the nomenclature used by Business Central to define receipt dates on purchase documents (and purchase lines). The following descriptions are based on the example of a Purchase Order document and lines in the context of ordering items, which is when receipt dates are most applicable.
- Order Date (mandatory) – the date when items were ordered (or should be ordered) from Vendor; on this day, the order should be sent to the Vendor and in most scenarios, we consider this as the date when Vendor received the order
- Requested Receipt Date (optional) – a date set by us as the customer for the Vendor; on this day, we want Vendor to deliver items to our warehouse doorstep (the actual process of receiving items by the warehouse starts only afterward, so a better name would be Requested Delivery Date, but well… it is what it is)
- Promised Receipt Date (optional) – a date filled in when Vendor is unable to deliver items on the date specified in the Requested Receipt Date; on this day, Vendor commits to delivering items to our warehouse doorstep – it is usually a later date than the Requested Receipt Date and, once filled in, becomes the binding delivery date
- Planned Receipt Date (resulting) – the date when items will be delivered by Vendor; it accounts for the lead time from the moment the order is placed (specified in the Order Date) to the moment items is delivered to the warehouse doorstep; the date considers optional receipt dates (Requested Receipt Date or Promised Receipt Date), if provided (thus here too, as in the previous two cases, we are talking more about the delivery date rather than the receipt date)
- Expected Receipt Date (resulting) – the date when items will be received and processed by the warehouse (completion of the inventory inbound process by the warehouse) and thus available for pick from the warehouse; to Planned Receipt Date (i.e., delivery to the warehouse doorstep) the time warehouse needs to complete the inbound process is added
Planning based on expected receipt date
It’s also worth to note (and remember) that the date shown in the Expected Receipt Date field is the one application uses to calculate inventory availability. All Item Availability by functions are based on the value from this field.
In Purchase Orders we surely also have other date fields, such as: Document Date, Posting Date, Invoice Received Date, Due Date, Payment Discount Date, and within localization packages, even more… However, these do not affect the calculation of the receipt dates on the document, nor do they participate in the receipt process in any way, which is why I am not discussing them in this article.
The fields involved in the calculation and estimation of receipt dates, which I listed and described above, are found both in the purchase header and in the purchase lines (the exception being the Planned Receipt Date, which only appears in the lines). The system behavior here is standard for BC, meaning it is analogous to other areas where fields are duplicated between the header and the document lines. Specifically, the values in the header fields primarily serve the appropriate presentation of the entire document, whereas the values in the line fields participate in the system logic and are used by most functionalities and retrieved for line-by-line document calculations. To ensure the presentation aligns with the logic, any change in a header field value triggers a standard dialog box asking the user if the system should apply the change to the document lines as well.
Default visibility of purchase receipt date fields
If you do not see any of the fields listed above in the document header or document lines and you want to use them, as a user you can add them to your view using Personalization, and if you are an administrator, you can add them for users of a given profile using Customization.
Calculating without requested receipt date
The default calculation method, which requires no additional actions from the user, is the calculation of the purchase receipt dates without entering the Requested Receipt Date, which is the date we would impose on the Vendor as the date we want to receive the delivery.
So, this is the method that is suitable for scenarios where we usually order the items in advance (against the demand), and the exact timing of reception moment is not a priority. I recommend using this method for purchasing items with regular deliveries, inventory that is consistently replenished (suggested replenishment and planning settings: Replenishment System = Purchase, Reordering Policy = Fixed Reorder Quantity or Maximum Quantity on the Item Card or Stockkeeping Unit Card), and we don’t need to handle any planning warnings like emergencies or exceptions.
The calculation of the Planned Receipt Date and the Expected Receipt Date is primarily based on the Order Date, using a forward method, and takes into account parameters related to lead time, safety lead time (buffer time), and warehouse processing time (time needed to handle inbound operations by warehouse employees). The automatic calculation of the appropriate values by the system is carried out according to the following operations:
- Order Date = automatically takes on the value of the Work Date when creating the document; the user can edit the date to specify the day the order will be sent to the Vendor for processing
- Planned Receipt Date = Order date (calculated/entered above) + Lead Time Calculation (see lead time parameters explanation ↓)
- Expected Receipt Date = Planned Receipt Date (calculated above) + Inbound Warehouse Handling Time + Safety Lead Time (see explanation of lead time parameters ↓)
Implementation procedures in AL code
The calculation of the Planned Receipt Date field value is executed by the UpdatePlannedReceiptDateFromOrderDate procedure in table object 39 – Purchase Line. It is called when the OnValidate trigger is run on the Order Date field (in which the value is either entered automatically or manually edited by the user). Then, the calculation of the Expected Receipt Date value continues on the same trigger.
Lead time parameters explanation
- Lead Time Calculation – specifies the order fulfillment time for an item or items, measured from the Order Date to the date the item is delivered by the Vendor; you enter how long the standard delivery time is; the field specifies the time formula, for example: 5D for 5 days, 1W for 1 week, etc.; the value can be defined for an item or items in several places, according to the priority order:
- Item Vendor Catalog
- Stockkeeping Unit Card
- Item Card
- Vendor Card
Where to fill in the lead time
If the delivery time for a given Vendor is always the same, regardless of which item we order – we assign the standard delivery time to the Vendor, so let’s fill it in on the Vendor Card. If the delivery time for a given item does NOT depend on the Vendor for some reason and is always the same, no matter who we order it from – we assign the standard delivery time to the item itself, so we should fill in the Lead Time Calculation field on the Item Card or on the Stockkeeping Unit Card (if there are SKU with different locations, variants, and different replenishment methods). However, if the delivery time varies for a given item depending on which Vendor we order it from, or if the given item is an exception to the standard lead time already entered in the Vendor Card or Item Card, then we should enter the lead time in the Lead Time Calculation field in the Item Vendor Catalog.
- Safety Lead Time – defines the tolerance for the standard lead time of delivery, which will be treated as an additional buffer for delivery delays; the field specifies the time formula, for example: 5D for 5 days, 1W for 1 week, etc.; the value can be defined in several places with priority order:
- Stockkeeping Unit Card
- Item Card
- Manufacturing Setup – Default Safety Lead Time field
- Inbound Warehouse Handling Time – specifies the time needed by the warehouse to complete the process of receiving the items, from the moment it is delivered to the warehouse by the Vendor until the inventory is made available for picking from the warehouse; the field specifies the time format (unfortunately, in this case, only accurate to 1 day), for example: 1D for 1 day, 1W for 1 week, etc.; the time required for the warehouse to receive the goods is defined for a given warehouse on the Location Card.
All the mentioned lead time parameters are copied onto the purchase document, so manually changing the values for any of these fields by the user in the purchase document header or purchase document line will automatically have the highest priority – overwriting the value retrieved according to the priority order from the settings. Therefore, the user can handle situations where there are exceptions to the standard lead times by defining (overwriting) the field values directly on the header or lines of the Purchase Order to which the exception pertains.
Changing the order date
The calculations described above take place not only when creating a new order or adding additional lines. Each manual change of the Order Date value will automatically trigger a recalculation of the values in the Planned Receipt Date and Expected Receipt Date fields.
Backward calculation of the order date
Although the Planned Receipt Date and Expected Receipt Date fields store the results of the aforementioned operations, these fields remain editable. Manually changing the date value in one of these fields by the user will cause backward calculation of the remaining dates (date calculation using the backward method).
In the described scenario, it is not a frequent case, but it is certainly feasible. If a user wants to check for a single order when they should place the order so that (according to the lead time parameters entered into the system) the items will be available to pick from the warehouse on the specified date, they can enter that date in the Expected Receipt Date field, and the system will calculate (by subtracting the Inbound Warehouse Handling Time and Safety Lead Time) the value in the Planned Receipt Date field, and then (by further subtracting the value of the Lead Time Calculation) the value in the Order Date field. The Order Date calculated this way is the date on which the user should place the order with the Vendor so that the inventory will be delivered on time and available to pick from the warehouse on the specified date.
Implementation procedures in AL code
Calculating the value of the Order Date field using the backwards method is done through the UpdateOrderDateFromPlannedReceiptDate procedure in table object 39 – Purchase Line. It is called during the execution of the OnValidate trigger on the Planned Receipt Date field, which in turn is called during the execution of the OnValidate trigger on the Expected Receipt Date field (where the value is manually entered by the user) using the ValidatePlannedReceiptDateWithCustomCalendarChange procedure.
Calculated order date only on purchase line
The back-calculated Order Date is updated only in the Purchase Order line, while the Order Date in the header remains unchanged. This way, the Order Date in the header can be used as the date of officially placing/sending the order to the Vendor, and the Order Date in the line, which is visible only to BC users (not visible on the order printout), informs the user of the date on which the order should be placed/sent to meet their specified receipt date.
Calculating with required receipt date
Another way to calculate purchase receipt dates is by using the optional field Requested Receipt Date (and naturally also the Promised Receipt Date), which allows us to impose on the Vendor the date by which we would like them to deliver the items.
Thus, this method is suitable for scenarios where we order items according to the JIT method, replenishing supplies only upon order (suggested replenishment and planning settings: Replenishment System = Purchase, Reorder Policy = Order on the Item Card or Stockkeeping Unit Card) or supplies that we replenish ad-hoc for emerging demands exceeding stock levels that we do not regularly replenish (suggested replenishment and planning settings: Replenishment System = Purchase, Reorder Policy = Lot-for-Lot on the Item Card or Stockkeeping Unit Card), as well as in cases where planning warnings like emergencies need to be handled.
In this method, after entering the value for the Requested Receipt Date, the standard calculation for the Planned Receipt Date (see in ¶ Calculating without requested receipt date) no longer applies. The Planned Receipt Date simply takes the value of the entered Requested Receipt Date. The automatic calculation of the appropriate values by the system occurs according to the following operations after entering the value in the Requested Receipt Date field:
- Order Date (only in the purchase line) = Requested Receipt Date (entered manually or automatically from the requisition) – Lead Time Calculation
- Expected Receipt Date = Requested Receipt Date (entered manually or automatically from the requisition) + Inbound Warehouse Handling Time + Safety Lead Time
The calculation is therefore based on the entered Requested Receipt Date, and by using the backward method, the Order Date (in the purchase line) is calculated, which is the date when the user should order items from the Vendor to ensure they have enough time to fulfill the delivery by the specified deadline.
Implementation procedures in AL code
Calculating the value of the Order Date field with backward method is done by the UpdateOrderDateFromRequestedReceiptDate procedure in table object 39 – Purchase Line. This procedure is called when the OnValidate trigger is run on the Requested Receipt Date field (where the value is automatically entered from the requisition or manually entered by the user). Subsequently, the calculation of the Expected Receipt Date value takes place when the OnValidate trigger is run on the Order Date field by the same procedure.
Passed order date
Due to the fact that the Order Date is calculated backward, users can relatively easily create situations where the calculated Order Date (in the purchase line) points to a past day! Although in business, orders for yesterday are quite normal ;). This often happens during handling planning warnings for emergencies. The entered or calculated Requested Receipt Date is simply too close to the current date, and the time from today to the Requested Receipt Date is shorter than the standard lead time (from the Lead Time Calculateion field).
Of course, it may happen that this is a deliberate and intentional act by the user – a desire to force Vendor to deliver supplies faster than usual.
The most important thing, however, is that as users, we are able to control such cases. We will see in the Order Date in the purchase lines that it is earlier than the Order Date from the header (the date the order was sent to the Vendor). Additionally, we will receive a message if, after entering the Requested Receipt Date, the calculated Order Date is earlier than the current date (in this case, the Working Date):
Vendor negotiates the delivery date
Naturally, it may happen that the Vendor, upon receiving our order with specified Requested Receipt Dates, is unable to meet them. This is especially true in situations where the time until the Requested Receipt Date is shorter than the standard or previously agreed upon lead time for that Vendor (see ¶ Passed order date above).
When Vendor responds with a proposal to change the delivery date (to a later date) and assuming we agree to the new date, the user should enter it into the Promised Receipt Date field. Note that there is a separate field designated for this purpose, meaning we do not have to change the original value in the Requested Receipt Date field. This way, we maintain a complete set of information in the order – the original date when we wanted to receive the delivery and the date ultimately negotiated by the Vendor, which is now and should be the binding date.
When you enter a value in the Promised Receipt Date field, it takes over the role of the Requested Receipt Date field. The Planned Receipt Date field adopts the value of the Promised Receipt Date, and now it is the Promised Receipt Date that serves as the basis for calculating the value of the Expected Receipt Date field.
Base calendars
There’s one more thing I haven’t mentioned yet that’s crucial for the functionality of calculations and estimating the receipt dates. These are Base Calendars or Customized Calendars (base calendars with additional exceptions introduced for a given location or Vendor), which can be set on the Location Card and/or the Vendor Card or in Company Information (as the default calendar).
In calendars, we can define working days and holidays, which, when using the calendar functionality for receipt dates calculation and estimation, significantly affect all date calculations and lead time parameters. They are calculated only within the working days of the calendars applicable to a given order, and the delivery date will never be calculated on a holiday. Therefore, it is mandatory to set up Base Calendars or Customized Calendars so that the system can estimate receipt dates according to the working schedules of our warehouses and/or our Vendors.
Conclusion
I believe that understanding the significance of each field related to the dates of purchase receipt and the relationships between them will enable proper use of the highly useful functionality of the Business Central system responsible for the automatic calculation and estimation of delivery and receipt dates or order dates.
Personally, I have encountered cases where BC users – employees in purchasing and procurement departments – did not pay attention to the values in the date fields on Purchase Orders, because they often all showed the exact same date (lack of lead time settings) or the date calculation and updates were unclear and perceived by users as random (lack of knowledge about the significance of each date and how the system calculates them). Completing the settings with the users and explaining to them how the system works in terms of date calculation and estimation consistently resulted in a significant increase in their work efficiency within the system.
Finally, I would like to add that in the area of Sales, the dates responsible for determining the shipment date and the delivery date of items to the Customer under a Sales Order follow a similar logic and have analogous functionality to what is described in this article. I will try to describe the dependencies of the shipment and delivery date fields for sales documents in a separate article.
I wish you on-time deliveries! 🚚
