Shopping Cart
- Patryk Marek
- News
- 0 likes
- 401 views
- 0 comments
A ready-made module is worth choosing when it supports the required process and method of data exchange. A dedicated integration is justified when you need to adapt rules that the available solution does not implement. For the quotation, prepare a description of the systems, the flow direction, responsibility for the data, and measurable acceptance criteria.
This guide helps PrestaShop store owners and people coordinating implementations prepare the scope of the discussion with the contractor. At the end, you will find a completed demonstration brief that can be treated as a template for your own request.
1. Describe the business outcome before choosing the technology
“Integration with ERP” may mean importing the catalogue, transferring orders, updating stock levels, retrieving invoices, or handling returns. These are different tasks, with different errors and acceptance criteria. A list of system names alone does not define the scope of work.
Start with a sentence describing the need: “Availability in the store should result from warehouse stock, and staff should not have to re-enter accepted orders into the ERP.” Then break it down into two flows. For each one, determine the starting point, the outcome, and the person who will make the decision in the event of an error.
If you only need periodic retrieval of a supplier catalogue, check the importer’s capabilities first. The XML import guide without duplicates helps organise identifiers and the update scope. An advanced integration is not a prerequisite for solving every problem with a product file.
2. Compare a ready-made module, customisation, and a separate implementation
| Situation | What to consider | What to confirm before making a decision |
|---|---|---|
| Standard flow, known format, and documented functions | Ready-made module with configuration. | Supported fields, system versions, identifiers, and behaviour in case of errors. |
| The process fits, but a few fields or mapping rules are missing | Customisation or a separate adapter. | Available extension points and the impact of future module updates. |
| Multiple sources, custom statuses, and arrangements between systems | Dedicated integration with a defined scope. | The owner of each field, the order of operations, and conflict resolution. |
| No documentation or limited access to the system | Technical discovery first. | Whether the data and required operations are available for integration at all. |
Compare the entire process, not the number of items on the feature list. A module may support products but not update a specific combination field. It may send orders but not transfer the pickup point used by your checkout. These details should be included in the input examples and the expected outcome.
Customisation also requires agreeing on how the changes will be maintained. If the modification is made directly in the files of a purchased module, specify how it will be recreated or transferred during an update. Do not assume that installing the next version will automatically preserve your custom code.
3. Check access to data and operations
Ask for the API documentation or file specification, system version, scope of permissions, limits, and a test environment. The sample should include representative cases: a product with variants, different tax rates, an order to a pickup point, or a cancellation. Replace customer data with demonstration data.
The official PrestaShop documentation describes the Webservice as a CRUD API, that is, an interface for operations on store resources. However, its presence does not mean that any business process is a ready-made single-request operation. You need to verify the resources, fields, and invocation method for the specific store version and on the side of the other system.
Also include in the scope who provides access and who can renew it. A separate integration account should have the permissions needed for the agreed tasks. Do not include keys and passwords in the brief or in sample logs; provide them through a separate, agreed channel.
4. Every field should have an owner
Two-way synchronisation is an incomplete description until it is clear what to do with a simultaneous change. If an employee corrects the price in the store and the ERP sends an older value, which record should apply? The answer should result from a rule, not from the accidental order of executions.
Separate data owners at the field level. The warehouse may decide the quantity, PrestaShop the descriptions and SEO, and a separate price list the price for a selected group. Also define the meaning of a missing field, an empty value, and zero. For stock level, these three cases may require completely different behaviour.
A stable key is needed to link the product and combination. The name alone is not enough, and the SKU must actually be unique within the agreed scope. Describe what will happen after a code change, the disappearance of a product from the source, and its re-addition after a break.
5. Separate sending data from processing it
Confirmation of request acceptance may only mean that it has been placed in the queue of the other system. Agree on how you will know that the order has actually been created there: by the document identifier, status readout, or return notification. Each solution requires defining the waiting state and further control.
A timeout after sending is particularly important. No response does not prove that the recipient saved nothing. Before retrying, you need to check the result by a stable identifier or use an agreed mechanism preventing multiple execution of the same operation.
In the brief, define a limited number of retries, delays compliant with the source limits, the place where error information appears, and manual resumption. Not every error is suitable for repetition: a missing required value must be corrected, while temporary service unavailability can be handled according to the agreed policy.
6. One-page brief — example to complete
The example below concerns the fictional “Warehouse A”. The figures describe demonstration requirements, not performance measurement or a guarantee of the capabilities of a specific module. Before quotation, the documentation and availability of operations in the actual system must be confirmed.
| Brief field | Example answer |
|---|---|
| Goal | Update availability and transfer accepted orders without manual re-entry. |
| Environment | PrestaShop 8.2.8, one store, PLN, catalogue of 4000 products; exact theme, modules, and PHP to be confirmed in the copy. |
| External system | Warehouse A with REST documentation and a test environment; API version and status read operation to be confirmed. |
| Direction and fields | Warehouse → store: availability of products and combinations. Store → warehouse: items, addresses, delivery, and order identifier. |
| Data owner | The warehouse determines quantity; the store retains descriptions, images, and SEO. Prices outside the scope of the first stage. |
| Links | Permanent product and warehouse variant identifier stored in the mapping. Unrecognised items go for clarification. |
| Frequency and load | Requirement: check stock changes every 15 minutes, approximately 200 orders per day. Peak size and acceptable delay to be agreed. |
| Condition for transferring the order | Agreed store status indicating acceptance; creating the cart alone does not start the export. |
| Confirmation and errors | Save the document identifier in Warehouse A. After a timeout, check the result before retrying. Report repeatable errors to the operator. |
| Acceptance | One order after retry, correct variants and addresses, control of an older message, documented resumption after failure. |
| Outside the first stage | Invoices, returns, B2B prices, new products, and additional stores. Each area requires a separate decision. |
| Responsibility | The store owner approves the rules; the warehouse provider makes the API available; the contractor delivers the mapping, acceptance procedure, and operating instructions. |
7. Enter acceptance criteria into the scope before quotation
Good acceptance covers both the successful flow and situations that require a decision. Check duplicate delivery of the same message, timeout after saving, unknown combination, missing address, older stock update, and resumption after interruption. For each case, define the outcome and the method of confirming it in both systems.
Also agree separately on the first launch: linking the existing catalogue, migrating identifiers, the first full run, and the switchover moment. An integration that works on new data does not automatically solve the problems of historical records.
In the quotation, separate API discovery, implementation, data clean-up, deployment, and maintenance. Specify who responds to an external system version change, expired access, and operational errors. If the project also includes a store version change, prepare separately the scope of the PrestaShop update.
Next step: send the brief as part of PrestaShop development and integration. Describe the systems, the direction of exchange, and the expected outcome. On this basis, it is possible to verify the fit of a ready-made solution and determine the scope requiring separate implementation.
Prepared on 13/09/2026. Technical basis: official PrestaShop 9 Webservice documentation. The brief is a demonstration example for store 8.2.8; specific API resources, versions, and limits require confirmation in the target environment. The stated volumes are not the result of a performance test.
Comments (0)