From tyre selection to order acceptance by the wholesaler

The specification connects tyre selection, pricing rules and orders with wholesaler integration requirements, defining data flows and future verification scenarios.

One description of the store and its dependencies on the wholesaler

A technical specification was prepared for a planned tyre store based on WordPress and WooCommerce. The document brought together requirements for product search, pricing, orders and communication with the wholesaler in one description of the future system.

Connect product selection with fulfilment

The store’s offer was to use supplier data: tyre specifications, wholesale prices and availability. It was necessary to define how this information would reach the buyer and how their selection would be passed on for fulfilment. A feature list alone would not explain the dependencies between the store, payment and the partner’s warehouse.

Tyre size or vehicle data

We described two ways to find tyres: by size and by vehicle specification. The first used parameters such as width, profile and diameter. The second assumed a database linking vehicle data with tyre sizes, followed by a search for products available from the supplier. The document connected the way a product is selected with the data needed to handle the query.

The wholesaler defines availability. The store records the order.

In the proposed integration, the wholesaler was the authoritative source for wholesale prices and stock levels. The store was to retrieve product information through an API, with the option of temporarily caching responses. Orders, client accounts and pricing rules remained on the store side. This division defined where each area would receive its data from and where changes should be recorded.

Three connected parts of the proposed operation

Supplier data
Specifications, wholesale price and availability from the API form the basis of the offer shown to the buyer.

Store decisions
Markup rules determine the final price. WooCommerce records the order and its payment status.

Fulfilment response
Order acceptance by the wholesaler, unavailable stock or a communication error require separate responses described in the specification.

From wholesale price to the buyer’s price

We separately described rules for applying a markup to wholesale prices. The administrator was to assign them to categories, brands or other product parameters and edit them in the panel. The specification separated the supplier’s base price from the final store price and identified when the rule would be applied as the product was retrieved.

Payment and wholesaler acceptance are separate steps

The order flow covered recording the order in WooCommerce, payment confirmation and transferring data to the wholesaler. The partner’s response was to confirm acceptance or identify a problem. Updates on shipping were described as an option dependent on the features available through the supplier’s API.

The order is paid, but the product is no longer available

The document also covered a situation where the client had paid for an order but the product was no longer available. It described feedback from the wholesaler and notification of the buyer. For communication problems, it provided for error logging, retrying a request or notifying the administrator. The requirements therefore also covered handling exceptions between purchase and fulfilment.

What to check from search to fulfilment

For the presentation, we select three criteria related to planned sales and order handling.

### Selection accuracy

**Whether results match the tyre size or vehicle parameters** will allow checking whether search leads to suitable products.

### Price consistency

**Whether product, basket and order prices follow the defined markup rule** will allow the calculation to be assessed throughout the purchase journey.

### Transfer outcome

**The share of paid orders confirmed by the wholesaler and cases requiring intervention** will show whether transfer for fulfilment ends with a clear status. These are proposed criteria for future checking, without measurements, targets or a claim that the store launched.

Managing orders, content and settings

The administrative scope connected order handling, integration configuration, content management and pricing rules. We also described requirements for a knowledge base, newsletter and reporting. The document thus covered both the buyer’s journey to the product and the tasks of the team operating the future store.

Key functions identified for prototyping

In the section on prototypes, we identified functions to check before full implementation: retrieving products, searching for tyres, payment and order transfer. The specification defined the scope of that verification; it was not a report on completed tests.

Define how the store should work with its partners

We translate sales assumptions into requirements for the store, integrations and everyday operations.

• Explore our web and e-commerce services

The sales concept translated into requirements

The result was a shared description of functions, data flows and dependencies on the supplier. It could support discussions of implementation scope and preparation of scenarios for checking the future store. The value of this documentation lay in translating the sales concept into specific requirements for the system and its operation.