Best Before Date BBD Expiry | expired products go offline by themselves

About the Extension

Friday lunchtime, a customer orders six jars of chutney. The best before date falls in four days, DPD needs three. You find out when the complaint lands in your inbox. For food, cosmetics, pet food and medicines that is not a slip, it is a legal matter.

The problem

The best before date is printed on the pallet, written on the delivery note and stored in your warehouse manager's head. It is nowhere in your shop. Shopware ships no field for it, so it ends up in a property, buried somewhere in the product description, or nowhere at all.

Pulling expired stock out of the range stays manual work. Run a list, find the product, untick the box. Do that once a week and you have spent six days selling goods you were not allowed to sell. Do it daily and you spend a quarter of an hour every morning on a job that earns nothing.

The solution

The plugin adds three custom fields to every product: a switch, the date and a lead time in days. Product detail page and cart show the date to your customer before the purchase. A scheduled task walks through your range every hour and switches off every product whose date minus lead time has been reached.

No import, no second system, not a single line of code. The fields sit exactly where your product maintenance already happens.

What's in it for you

You stop selling expired goods. The check runs hourly, not weekly and not when somebody remembers. At most one hour passes between expiry and deactivation.

The lead time includes your delivery time. Enter three days and the product goes offline three days before the date. Anything that would expire while it is still in transit never gets sold. The value sits on the product, because soft cheese needs a different lead time than tinned food.

Every batch carries its own date. Variants inherit the value from the parent product and may overwrite it. One variant per delivery, one date per variant: the older batch goes offline, the fresh one stays on sale.

Your customer sees the date before buying. It appears below the buy box on the detail page and again on every cart line. That saves support tickets and returns that start with "this expires next week already".

You control every sales channel separately. The switch in the plugin configuration is bound to the sales channel. Your B2B shop shows the date, your B2C shop stays untouched, and you do not have to uninstall anything for that.

How the plugin works

After installation you find three new fields on the product, in the Specifications tab, Custom fields card: Active, Best before date and Deactivate days before. Set the switch, pick the date, done. Products without the switch stay exactly as they are.

The storefront prints the date in full on the product detail page, for example "Tuesday, 15 December 2026". In the cart it appears in short form on each line. Both only if switch and date are set on the product and the plugin is active for that sales channel.

Deactivation is handled by a scheduled task. It runs every hour, reads your products in pages of one hundred and writes all deactivations in a single operation. For tests and immediate runs there is the console command bin/console mhd:cron.

Typical use cases

Fine food retail with batches. Three deliveries of the same olive oil, three shelf lives. Each delivery is a variant with its own date, and the oldest one disappears from sale on its own.

Natural cosmetics. Creams without preservatives and six months of shelf life. Lead time set to fourteen days, so no jar is in transit when the date falls.

Pet food and animal feed. Large packs, long storage times, mandatory labelling. The date sits visibly on the product without you typing it into the description.

Chemist and pharmacy supplies. A range where expired goods are not merely annoying but bring a warning letter with them.

Technical facts for your IT team

Shopware 6.7, PHP 8.2 or newer. The plugin creates no table of its own and changes no Shopware table. It uses a custom field set on the product entity, which is the route Shopware intends for this. It builds no separate area into the administration and adds no menu entry.

The plugin sends no data to external servers. It processes no personal data: only date, switch and lead time are stored on the product. No GDPR relevant data flow arises.

The storefront output reads only fields Shopware has already loaded for the product. No extra database query on the detail page, none in the cart, none in the checkout. The hourly task runs in the background through the message queue and needs a running worker or the admin worker for that.

On uninstall you decide in the plugin manager whether your data survives. The box reads Remove all app data permanently: ticked, the plugin clears its custom fields and settings completely; left alone, fields and maintained dates stay in place.

To be honest

The plugin sends no warning email before something expires, and it does not switch deactivated products back on by itself. When a new batch arrives, you set date and tick again by hand. It is not a batch management system either: it keeps no stock levels per batch, you need an ERP for that. And the date never shows up in category listings, only on the detail page and in the cart.

If that is enough for you, install it and try it on one product. Five minutes and you will know.

Legal notice

We accept no liability for legal requirements. Please check the use of this plugin with a qualified legal advisor.