Eshop integration with Epsilon Smart: workflows, prerequisites and testing

Integrate the store with Epsilon Smart around a defined workflow and the installation's available interface. Epsilon Smart can support commercial management for a smaller store when the appropriate module is enabled. The workflow needs item identifiers, balances, customer details and sales information.

Epsilon Smart can support commercial management for a smaller store when the appropriate module is enabled. The workflow needs item identifiers, balances, customer details and sales information. Distinguish the order accepted by the store from the sales document recorded in the commercial application. Agree which step triggers submission, which fields are required, and who handles rejections so that a sale is not also entered manually a second time.

The official knowledge base includes examples for authentication, retrieving items, reading inventory balances, and submitting sales documents. It explicitly requires enabling the e-shop API integration module. Epsilon Smart is not PYLON, and its API must not be presented as a shared interface for every Epsilon Net product. We check the subscription and activation of this specific service.

A cosmetics store receives an order for three items with a request for a business sales document. First it checks that every store identifier maps to a Smart item. Company details are completed before submitting the sales record. If a required field is missing, the order remains pending correction and the operator can see what is needed. After correction, only the failed step is repeated. The original event reference is retained so that a successful submission is not repeated.

An important failure scenario occurs when a required customer field is missing and the submission is rejected. Keep the external reference and confirmed destination ID before retrying. Separate access failure, business rejection and an unknown outcome. An operator must be able to inspect the relevant record and resolve its status without replaying completed steps. Agree which fields may appear in logs and who handles unresolved cases.

Test a retail sale, a sale with business details, and a retry after correcting data. For each case record the expected source data, destination record and customer-visible state. Include one denied-permission case and one interrupted response. Re-run a previously confirmed event and check that its business effect is unchanged. The acceptance record should identify the responsible team and the evidence required to close any discrepancy.

The initial discovery should confirm: Enabled e-shop API module and API user; Confirmed subscription and permissions; Sales document types agreed with the commercial administrator. Before launch, document the mapping for Items and balances → online store → Sales information → required-field validation → API submission → recorded result. Assign responsibility for access renewal, monitoring and correction. A change to product configuration or the agreed business rule should trigger targeted regression checks. Begin with this defined workflow; add another channel only after its ownership and acceptance cases are clear.