--- type: "blog" id: 39 url: "https://prestadev.pl/en/blog/news/prestashop-dispatch-delivery-dates-calendar-availability" markdown_url: "https://prestadev.pl/en/markdown/blog/39.md" title: "Dispatch and delivery dates in PrestaShop: calendar and availability" description: "Separate dispatch from delivery in PrestaShop: cutoff times, working days, unavailable goods and example messages, without a delivery guarantee." language: "en" published: "2026-10-06 23:23:39" updated: "2026-10-06 23:23:45" author: "Patryk Marek" category: "News" --- # Dispatch and delivery dates in PrestaShop: calendar and availability How do planned dispatch and estimated delivery differ in PrestaShop? Examples explain cutoff times, working days and product availability, without promising guaranteed delivery. **The dispatch date is when the parcel is expected to be sent, while the delivery date describes when it is estimated to reach the customer.** In PrestaShop, it is worth separating these two pieces of information and making the message depend on stock availability, the cutoff time and the store's working days. A single “delivery within 24 hours” message does not explain what happens to an order placed on a Friday after dispatch has finished, or to one containing an unavailable product variant. ## What should customers see: dispatch, delivery or a choice of date? These are three different needs. Dispatch information tells customers when the store plans to hand the goods over for transport. The delivery range accounts for the time from that dispatch. Letting customers choose a date, on the other hand, means providing a form where they select a suitable day and sometimes a time slot as well. The [conditional delivery time module for PrestaShop](https://prestadev.pl/en/multilingual-delivery-method-name-conditional-delivery-time-for-prestashop.html) adapts carrier names and messages about dates. It is not a calendar for customers to book a delivery date. The calculated range remains an estimate based on the store's settings, not confirmation of delivery by a courier company. ## First, check availability for the entire shipment The message should reflect the products assigned to a particular shipment within a delivery option. Checking just one product is not enough, and neither is treating the whole cart as a single parcel if PrestaShop has split it into several shipments. The module distinguishes between shipments that are entirely available, entirely unavailable and mixed. How stock is assessed matters. If two units are in stock and three are ordered, the mode that compares quantities considers the product unavailable. The mode that checks only for zero or negative stock still considers it available. Choose the mode that matches how the store actually prepares and dispatches orders. - **Available goods:** the message can use a shorter range of days from dispatch. - **Unavailable goods:** a separate message and range are needed to reflect the store's assumptions about order fulfillment. - **Mixed shipment:** the calculator uses the range for unavailable goods. If no separate message has been entered for this state, the module uses the message for unavailable goods. Virtual products do not affect the assessment of a physical shipment. When stock management is disabled, physical products are treated as available, so the module itself will not flag shortages based on quantities. ## The cutoff time and calendar change the dispatch date Set a cutoff time that matches how the warehouse operates. On a working day before that time, the calculator can allow for same-day dispatch. At the cutoff time itself and afterwards, it moves dispatch to the next permitted day. A carrier rule can override the shared cutoff setting. The calendar lets you select weekdays and your own one-off or annual days off; an optional built-in calendar of Polish public holidays is also available. The same configured calendar determines dispatch and counts the days until delivery. These are not separate calendars retrieved from individual carriers. ### Example: an order before and after the cutoff time The dates below illustrate how the calculator works, not an actual promise from the store. The assumptions are: working days from Monday to Friday, a cutoff time of 14:00, no additional days off, the built-in holiday calendar disabled, and delivery 1–2 working days after dispatch. The calculation time is given in the Europe/Warsaw time zone. | Calculation time | Planned dispatch | Estimated delivery | | --- | --- | --- | | Friday, October 9, 2026, 13:30 | October 9 | October 12–13 | | Friday, October 9, 2026, 14:00 | October 12 | October 13–14 | | Friday, October 9, 2026, 15:00 | October 12 | October 13–14 | The range of days in a rule means the time from dispatch to delivery. Variables showing the number of working days remaining also account for dispatch moving later than the calculation day. Setting the value to zero gives a delivery date equal to the dispatch date in the calculator; it should not be used as shorthand for “unknown”. ## What about a product that will only become available later? When availability dates are taken into account, the module can move the earliest dispatch to the latest future date among the unavailable products. For a variant, it first uses that variant's valid availability date and, if there is none, the product's date. This information must come from data saved in the store. For example, with a calculation on Friday, October 9, unavailable goods becoming available on Wednesday, October 14, and a range of 3–5 working days from dispatch, the calendar described above gives dispatch on October 14 and delivery on October 19–21. This is the result of the supplied data, not a check of the wholesaler's delivery schedule. A missing date does not trigger contact with the supplier or retrieval of their schedule. If the calculator cannot determine a date, the module keeps the standard carrier message instead of displaying text with empty date variables. A product block that requires such a calculation is hidden in this situation. Availability assessment only makes sense with reliable stock data. If you update it using wholesaler files, [updating stock from CSV in PrestaShop](https://prestadev.pl/en/blog/news/available-in-the-store-at-the-supplier-no-stock-quantities-from-csv-in-prestashop) is a separate subject. Current stock levels and a delivery date confirmed by the supplier are not the same thing. ## How can you write a clear delivery message? Separate planned dispatch from the estimated delivery range. An example of a rule text template is: `Planned dispatch: %dispatch_date%. Estimated delivery: %date_range%.` Dates are inserted when the calculation is made, so there is no need to rewrite the message manually every day. For a mixed shipment, you can add an explanation: `The shipment contains a product awaiting availability. Planned dispatch: %dispatch_date%. Estimated delivery: %date_range%.` The text should reflect how orders are actually fulfilled. The module itself does not arrange partial shipments or reserve goods. Messages are entered separately for each store language. The module does not translate them automatically. An empty message for a particular state may mean that the carrier message is kept, so it is worth preparing all the language versions you need rather than assuming the Polish text will also appear in other markets. ## Information on the product page and in the order The optional product block shows an estimate based on a single rule. It does not compare all carriers or confirm that a particular delivery method is available for the customer's address. Keep this in mind when writing the text: product-page information should not present itself as the final choice made in the cart. When retaining information for new orders is enabled, the module can save the modified carrier name and message. This is conditional and takes place when the order is validated. It is not a copy of a particular earlier cart screen; if payment confirmation is delayed, the calculation may happen later. Saved messages are not recalculated every day using current stock levels. The feature does not automatically fill in old orders and does not apply to an order without its own carrier. It is therefore important to distinguish the current estimate before purchase from the information saved for a particular order. ## Frequently asked questions about delivery dates in PrestaShop ### Does a date range guarantee delivery? No. The calculator uses the calendar, day ranges and availability saved in the store. It does not confirm transport fulfillment or a delivery date in the courier's system. ### Does a mixed shipment have a third day range? No. It can have its own message, but its dates are calculated using the range for unavailable goods. Separate texts do not mean three independent calculation ranges. ### Does the module change delivery prices or stock levels? No. It adapts names and messages and uses existing data for its calculations. It does not change transport costs, reserve products or generate labels. ### Will the product block show the date for a carrier selected later? No. It uses a single configured rule. Only the list of delivery options relates the message to the products assigned to a particular shipment. ## Where should you start with configuration? Decide how stock should be assessed, set the cutoff time and configure the working calendar. Then enter day ranges for available and unavailable goods and prepare messages in all the languages you use. Compare the three shipment states in the module preview, and check in the actual purchase flow whether your theme and ordering process use the modified list of delivery options. If you use a custom checkout, also read [what to check before switching to a one page checkout](https://prestadev.pl/en/blog/news/one-page-checkout-prestashop-what-to-check). Previewing a rule alone does not confirm that customers will see its message in the purchase flow you use. The [module listing for delivery method names and conditional delivery times](https://prestadev.pl/en/multilingual-delivery-method-name-conditional-delivery-time-for-prestashop.html) describes its features and integration limits. Start with accurate data and a clear estimate, not a promise of a date that the store or carrier has not confirmed.