{"id":128,"date":"2026-10-07T09:00:00","date_gmt":"2026-10-07T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=128"},"modified":"2026-10-07T09:00:00","modified_gmt":"2026-10-07T07:00:00","slug":"verzendmethode-post-bezorging-afhalen-classificeren","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/reliably-identifying-parcel-delivery-own-delivery-or-collection\/","title":{"rendered":"Reliably identifying parcel delivery, own delivery or collection"},"content":{"rendered":"

Classify an online store order as parcel delivery, own delivery or collection using a fixed source hierarchy: use stable method IDs where their meaning is unambiguous, then apply a managed title mapping, and block unknown values. Words such as \u2018free\u2019 or \u2018standard\u2019 say nothing reliable about the operational process that needs to follow.<\/p>\n

Classification directs the entire order flow<\/h2>\n

A wrong choice affects more than a shipping label. Parcel delivery may go to Sendcloud, own delivery requires a zone, date and route planning, and collection needs a location or time slot. The point at which an order counts as complete differs too. Fulfilment classification therefore belongs early in the workflow and needs to be stored against the order as an explicit, explainable outcome.<\/p>\n

Start with technical identifiers that a plugin consistently supplies. Known semantic methods such as local pickup can be recognised by ID. Commercial or custom methods require a configuration table linking the source shop, method ID or exactly normalised title to one fulfilment type. Avoid free substring rules: \u2018collect or have delivered\u2019 contains both words and is therefore not a safe basis.<\/p>\n

Source hierarchy for the decision<\/h2>\n
\n\n\n\n\n\n\n\n\n
Priority<\/th>\nSource<\/th>\nUse<\/th>\n<\/tr>\n<\/thead>\n
1<\/td>\nStable WooCommerce method ID<\/td>\nDirectly, when the meaning is technically established<\/td>\n<\/tr>\n
2<\/td>\nShop-specific configuration mapping<\/td>\nFor custom methods and plugins<\/td>\n<\/tr>\n
3<\/td>\nExactly normalised title<\/td>\nOnly as a managed and tested fallback<\/td>\n<\/tr>\n
No match<\/td>\nUnknown<\/td>\nStop before subsequent logistics actions<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Also record which source determined the outcome. Operations can then see that \u2018Avondroute Noord\u2019 was treated as own delivery through the shop configuration. In Connect<\/a> this classification can select the appropriate configurable workflow.<\/p>\n

Fictional example: free is not a fulfilment type<\/h2>\n

Fictional example: delicatessen Smaakloods displays \u2018Free shipping from \u20ac75\u2019. For light parcels, this still means parcel delivery; for chilled products, the same marketing wording activates an own-delivery route. Classifying by the word free would treat both orders identically.<\/p>\n

The team therefore uses the underlying method ID and a shop-specific mapping. The fictional code `free_shipping:parcel` becomes parcel delivery; `cold_route:north` becomes own delivery. A new plugin unexpectedly supplies `weekend_special`. That order is not automatically sent to the default carrier; it appears as an unknown method with order context. After checking the process, an administrator deliberately adds the correct mapping and has only the blocked step reassessed. This example is fictional and shows why a commercial title is not the operational truth.<\/p>\n

A test set for every checkout change<\/h2>\n