How to Schedule Price Changes in PrestaShop: Products, Categories & Automation Limits

Last updated: July 1, 2026. Reviewed against native PrestaShop pricing behavior and the shipped mypresta.rocks modules mprdynamicscheduleddiscounts 1.1.0 and mprmasspriceupdate 1.1.0.

Author: mypresta.rocks editorial team. We build PrestaShop modules and run PrestaShop stores ourselves, so this guide is based on native admin behavior and shipped module code, not only on pricing theory.

"Can I schedule all my prices to change on the first of next month?" Sometimes yes. Sometimes no. The mistake is treating every price change as the same job.

In PrestaShop, scheduled pricing splits into three different cases: a temporary discount, a permanent base-price edit, and a trigger rule based on sales or stock. Use the native tool for the first case. Use a bulk editor for permanent price changes. Use automation only when the rule depends on stock age, sales history, or a cron check.

Quick comparison

Start by naming the job

• Scheduled promotion: a temporary price reduction with a start and end date. The original price returns when the date window closes.
• Permanent base-price change: the stored product price moves and stays moved. This is common after supplier cost changes.
• Trigger automation: the price reacts to sales or stock state, such as no recent sale and stock still sitting in the warehouse.

We run PrestaShop shops ourselves. The pricing mistakes that cause trouble are usually small: a catalog rule left active too long, a volume break misread as a lifetime sales trigger, or a base-price update done without rollback data. That is why this guide separates discount layers from stored price edits.

Native method 1: schedule one product with Specific Prices

For one product and one date window, do not install anything. Use the product pricing screen.

1. Open Catalog > Products.
2. Edit the product.
3. Open the Pricing tab.
4. Add a Specific price.
5. Set From quantity to 1 unless this is a volume discount.
6. Choose a fixed price or reduction.
7. Set the From and To dates.
8. Save and test the product page during the date window.

Specific Price example
Product: Example Jacket
From quantity: 1
Available from: 2026-08-08 00:00:00
Available to:   2026-08-11 23:59:59
Reduction:      20 percent

Use this for:
"This product is 20 percent off next weekend."

So what? This is the lowest-risk native path when the discount belongs to one product. PrestaShop already checks the date range during price calculation.

Native method 2: schedule a category discount with Catalog Price Rules

When the discount covers a group of products, use a catalog price rule. The exact admin wording moves between PrestaShop 1.7, 8 and 9, but the feature is the same idea: define the price rule, then define the conditions.

1. Open Catalog > Discounts.
2. Create a Catalog price rule.
3. Name it clearly, including the campaign or season.
4. Set From quantity to 1 unless you want a cart-volume break.
5. Set the date range.
6. Choose the reduction type and value.
7. Add conditions such as category, manufacturer, attribute, feature, supplier, or price range depending on your PrestaShop version and screen.
8. Save the rule and check one product inside and outside the condition set.

Catalog Price Rule example
Name: Weekend Outdoor 15 percent
From quantity: 1
From: 2026-08-07 00:00:00
To:   2026-08-10 23:59:59
Reduction: 15 percent
Conditions:
  Category = Outdoor

Use this for:
"Everything in Outdoor is 15 percent off this weekend."

The important part: a catalog price rule is still a discount layer. It does not rewrite your stored product base prices.

The "from quantity" trap

PrestaShop uses from quantity during the current price calculation. In plain English: how many units are in the current cart or order line. It is not a lifetime sales counter.

• "Buy 5 or more, save 10 percent": native Specific Prices can handle this.
• "After we have sold 100 units total, raise the price": not native.

Do not read this as a feature claim for our current modules. An "after the 100th cumulative unit sold" trigger is not shipped in the modules discussed here. It belongs to a later automation phase because refunds, returns, combinations and multishop state all affect the count.

-- Concept only: a cumulative sales trigger needs order history,
-- not the current cart quantity used by from_quantity.

SELECT
  od.product_id,
  SUM(
    od.product_quantity
    - COALESCE(od.product_quantity_refunded, 0)
    - COALESCE(od.product_quantity_return, 0)
  ) AS net_units_sold
FROM ps_order_detail od
INNER JOIN ps_orders o ON o.id_order = od.id_order
WHERE o.valid = 1
  AND o.id_shop = 1
  AND od.product_id = 123
GROUP BY od.product_id;

Real automation should check which refunded/returned quantity columns exist on your PrestaShop version before running a query like that. The shipped dead-stock evaluator does that kind of version-aware column check for its own last-sale logic.

Permanent base-price changes are a different job

If your supplier raises costs and you want every product in a category to go up by 8 percent from August 1, a catalog price rule is the wrong tool. You do not want a temporary discount layer. You want the stored base price to change on a schedule.

Mass Price Updater 1.1.0 handles that as a scheduled job. In code, the module creates a row in mprmasspriceupdate_job, waits until run_at, then updates product and product_shop price fields through cron. Before it changes price rows, it writes rollback data to mprmasspriceupdate_job_snapshot.

1. Choose the scope: all products, category, manufacturer, or supplier.
2. Choose the field: base price or wholesale price.
3. Choose the formula: increase percent, decrease percent, increase fixed, or decrease fixed.
4. Preview the products and new prices.
5. Set the schedule date and time.
6. Let cron run the job, then use the Scheduled Jobs screen for status and rollback.

Scheduled base-price job example
Module: mprmasspriceupdate 1.1.0
Scope: category
Scope ID: 12
Field: price
Formula action: increase_percent
Formula value: 8
Run at: 2026-08-01 00:05:00
Preview required before scheduling: yes
Rollback table: mprmasspriceupdate_job_snapshot

Dead-stock automation needs more than dates

Dead stock is not just "discount product X between two dates." The rule merchants usually mean is conditional:

IF product has no valid sale for 30 days
AND stock quantity is greater than 3
AND no active discount already applies
AND the final price stays above the floor
THEN apply a clearance discount

Native PrestaShop does not combine those checks for you. Smart Dynamic & Scheduled Discounts 1.1.0 adds dead-stock automation with rule records, scope records, application records, run records and logs in these tables:

mprdsd_automation_rule
mprdsd_automation_rule_scope
mprdsd_automation_application
mprdsd_automation_run
mprdsd_automation_log

The module does not write native ps_specific_price rows for this automation and does not overwrite base product prices. It generates internal campaign targets, then the discount is applied during PrestaShop price calculation through actionProductPriceCalculation. That keeps rollback cleaner: removing generated targets stops the automated discount without trying to reconstruct native prices.

Dead-stock rule example
Rule name: Warehouse clearance - slow movers
Active: yes
No Sale Days: 30
Stock Threshold: 3
Discount Type: Percentage
Discount Value: 15
Price Floor: Minimum margin percent
Floor Value: 20
Exclude Already Discounted Products: yes
Scope:
  Include category: Clearance candidates
  Exclude product: protected-margin SKU

Dry-run preview shows:
  scanned
  would discount
  would expire
  eligible
  skipped
  base price
  discount
  floor
  final price

Dry-run writes: 0

What the cron side looks like

The dead-stock automation task registered by Smart Dynamic & Scheduled Discounts is evaluate_dead_stock_automation, scheduled as every:1800 in the module. The shared MPR cron runner executes due tasks. Use the cron entry point generated in your shop and keep the token private.

# Example MPR cron runner. Use the cron entry point generated in your shop.
*/5 * * * * php /var/www/html/modules/YOUR_MPR_CRON_MODULE/cron.php --token=YOUR_CRON_TOKEN --context=cron --max-tasks=20

# Registered task checked by the runner:
module=mprdynamicscheduleddiscounts
task_key=evaluate_dead_stock_automation
schedule=every:1800

Which path should you choose?

• Temporary discount on one product: use native Specific Prices.
• Temporary discount across a category or catalog segment: use native Catalog Price Rules.
• Permanent bulk base-price change: use Mass Price Updater or another controlled bulk-edit process with preview and rollback data.
• Future permanent base-price change: use scheduled jobs in Mass Price Updater.
• Dead-stock clearance based on no recent sale and stock level: use Smart Dynamic & Scheduled Discounts.
• After N cumulative units sold: treat it as custom automation. It is not native PrestaShop and is not a shipped trigger in these modules today.

FAQ

Can PrestaShop schedule price changes natively?

Yes, for temporary discounts. Use Specific Prices for one product and Catalog Price Rules for groups of products. Native PrestaShop does not give you the same one-screen flow for scheduling a future permanent bulk edit of base prices.

Does "from quantity" mean lifetime units sold?

No. In Specific Prices and Catalog Price Rules, "from quantity" is tied to the quantity in the current cart or order line. It is not a historical sales counter.

Can I schedule a category discount without a module?

Yes. Use a Catalog Price Rule with a date range and category condition. That is the native path for a temporary category discount.

Can PrestaShop automatically discount dead stock?

Not natively. A dead-stock rule needs order history, stock quantity, scope, price-floor checks, preview, cron and expiry. Smart Dynamic & Scheduled Discounts adds that automation.

Does Smart Dynamic & Scheduled Discounts change my base prices?

No for the dead-stock automation described here. It applies the discount at runtime through PrestaShop price calculation and generated internal campaign targets. It does not write native specific prices or overwrite product base prices for this automation.

Which module should I use for permanent base-price changes?

Use Mass Price Updater when you want to change stored base or wholesale prices with a formula, preview the affected products, schedule the job, and keep rollback snapshots.