Order Status Mapping: From 'Processing' to 'Shipped' (PrestaShop)

A practical guide to mapping PrestaShop order lifecycle states to warehouse management milestones, with a focus on automating customer notifications and pushing tracking numbers from the WMS back to the PrestaShop storefront.

This entry explains how to map PrestaShop order statuses (with emphasis on the transition from 'Processing' to 'Shipped') to warehouse milestones, and how to automate pushing tracking numbers and shipping confirmation emails from a WMS back into PrestaShop. It is written for beginners and focuses on pragmatic implementation, customer communication, and robust automation practices.

Why a clear mapping matters

A consistent mapping ensures accurate customer communication, prevents shipment delays, keeps inventory synchronized, and enables reliable analytics. Customers expect immediate tracking updates and confirmation emails when an order leaves the warehouse. Without automation, manual updates are slow and error-prone.

Typical lifecycle mapping overview

At a high level, you map PrestaShop order states to warehouse milestones. Example mapping (common defaults):

• PrestaShop 'Payment accepted' or 'Processing' → WMS: Order released for picking
• PrestaShop 'Processing' (or 'Preparation in progress') → WMS: Picking/In progress
• PrestaShop 'Ready to ship' → WMS: Packed and awaiting carrier pickup
• PrestaShop 'Shipped' → WMS: Carrier scanned and tracking assigned (final shipment event)

The critical automation step covered here is: when the WMS marks a shipment as 'Shipped', it should: (1) send the carrier and tracking number to PrestaShop, (2) update the order status to 'Shipped' in PrestaShop, and (3) trigger the shipping confirmation email to the customer.

How the automation flow typically works

1. Order placed in PrestaShop and reaches a configured state (e.g., 'Processing') that allows fulfillment.
2. PrestaShop sends the order to the WMS via API, EDI, or a file export. The WMS creates a work order and tracks picking/packing progress.
3. Warehouse operations proceed: picking → packing → manifesting. The WMS updates its internal status to 'Ready to Ship' once items are packed and labeled.
4. Carrier pickup or label creation occurs. When the WMS receives an actual carrier scan or finalizes shipment, it marks the order 'Shipped' in the WMS.
5. WMS calls PrestaShop API (or pushes via middleware) to: update the order state to 'Shipped', attach the carrier code and tracking number, and request PrestaShop to send the shipping confirmation email to the customer.

Technical considerations for pushing 'Shipped' into PrestaShop

• API endpoints: Use PrestaShop's webservice or REST API to add an order history entry that sets the new order state. Many PrestaShop integrations use the 'add order history' endpoint which accepts parameters to set state and optionally trigger the email.
• Tracking number storage: PrestaShop stores tracking numbers associated with carriers/orders. Ensure the WMS supplies carrier id or code and the tracking number so the storefront can display it and include it in emails.
• Email triggering: When adding an order history record via API, include the flag that tells PrestaShop to send the shipping confirmation email. Confirm the email template used contains a placeholder for the tracking number and carrier.
• Authentication and security: Use secure API credentials, TLS, IP allow-listing where possible, and rotate keys periodically. Limit the WMS account to only the operations it needs (principle of least privilege).
• Idempotency and retries: Design the integration so repeated webhook or API calls do not create duplicate emails or duplicate tracking entries. Implement idempotency keys and retry logic for transient failures.

Sample automation payload and action (conceptual)

When WMS marks shipment complete, it sends a request to PrestaShop like: order_id=12345, new_state='Shipped', carrier_code='UPS', tracking_number='1Z999AA10123456784', send_email=true. PrestaShop updates order history, stores the tracking number, and sends email using the shipping confirmation template.

Handling common real-world cases

• Partial shipments / multiple tracking numbers: For split shipments, push each parcel's tracking number and create separate order history entries or carrier records. Ensure email templates support multiple tracking entries or send incremental shipment notifications per parcel.
• Multiple carriers: Map WMS carrier codes to PrestaShop carrier IDs. Maintain a small lookup table in middleware to translate carrier identifiers reliably.
• Manual overrides: Allow warehouse supervisors to mark exceptions (e.g., address issues, lost items). When an override occurs, record an explanatory comment in order history and prevent automatic 'Shipped' updates until resolved.
• Backorders and partial inventory: If items are backordered, do not transition to 'Shipped' for the whole order until all shippable items are fulfilled, or use partial shipment states and push a notification that some items will ship later.

Best practices

• Map statuses conservatively. Only mark PrestaShop 'Shipped' when the carrier has accepted the parcel (carrier scan or confirmed label creation).
• Use the PrestaShop email flag when adding order history so the storefront handles templating, localization, and unsubscribe logic centrally.
• Log every API request/response from the WMS to PrestaShop with timestamps and correlation IDs for troubleshooting.
• Test end-to-end in a staging environment that mirrors your production PrestaShop instance and WMS configuration before going live.
• Monitor key KPIs: time from 'Processing' to 'Shipped', email delivery rates, and discrepancy counts between WMS and PrestaShop order states.

Common mistakes and how to avoid them

• Sending 'Shipped' too early: Avoid marking shipped at label generation if the carrier hasn't accepted the package. Prefer carrier scan events as the authoritative trigger.
• Not handling partial shipments: Treat each parcel as an independent shipment record; failing to do so causes incorrect customer expectations and support contacts.
• Duplicate emails: Poor idempotency leads to multiple shipping emails. Use unique shipment IDs and check if an order history entry already exists before sending.
• Mismatched carriers: If WMS uses free-form carrier names, normalize them to PrestaShop carriers to ensure tracking links and label attachments work in emails.
• Lack of monitoring: Without alerts, failures in the push-from-WMS process go unnoticed. Implement retries, dead-letter queues, and alerting for persistent failures.

Implementation checklist

1. Document your PrestaShop order states and their IDs in your store.
2. Define the WMS milestones and exact triggers that will call PrestaShop.
3. Create a carrier mapping table between WMS carrier codes and PrestaShop carrier IDs.
4. Implement API calls with authentication, idempotency, and retry logic.
5. Ensure the shipping email template includes tracking placeholders and is tested in multiple locales.
6. Test partial shipments, failed deliveries, and manual overrides in a staging environment.
7. Deploy monitoring and logs; run a pilot before full rollout.

Following these guidelines will create a reliable, customer-friendly flow where a WMS 'Shipped' event automatically pushes tracking numbers and triggers PrestaShop shipping confirmation emails, keeping customers informed and reducing manual effort and support inquiries.