Beauty brands selecting or replacing a retail system often already operate enterprise resource planning (ERP), order management (OMS), warehouse management (WMS), customer relationship management (CRM) or a dedicated loyalty platform. A new store system must work within the brand's existing arrangements for products, inventory, customers, orders, payments and finance.
In a typical architecture, the PEKON Smart Retail System handles store sales, returns and exchanges, store inventory operations and payment result records. ERP handles enterprise resources and financial processing; OMS manages online orders and fulfillment coordination; WMS manages warehouse operations; and CRM or a loyalty platform manages customer identity and benefits. The final allocation depends on the brand's existing systems, data sources and organizational responsibilities.
The example below follows a beauty store sale and a partial return to explain what each system records, how results are exchanged and how processing continues after an interruption.
Brands evaluating a new system can also consult the Retail System Selection and Replacement topic hub for related guidance on business coverage, system coordination and migration.
Why one sale appears in several systems
A customer buys a bottle of foundation and a lipstick in a store, applies a RMB 60 loyalty voucher and pays the remaining amount. A few days later, the customer returns to the store to return the lipstick.
This process creates several types of records. The retail system records the store sale and return. The payment system executes the charge and refund. CRM or the loyalty platform processes vouchers and points. ERP receives sales and inventory results for subsequent financial processing. If the product later needs to go back to the warehouse, WMS records its receipt there.
Several systems holding data about the same sale does not automatically mean their responsibilities overlap. Each business result needs a defined source, an agreed set of data for receiving systems, and a record that teams can use to continue processing when discrepancies arise.
Typical responsibilities by system
The following allocation is common in beauty retail projects. The actual scope depends on the brand's architecture, product versions, interface capabilities and project agreement.
| Data or business result | Typical responsible system | How PEKON and other systems coordinate |
|---|---|---|
| Product codes, shades, specifications and units | ERP or product master platform | PEKON, OMS and WMS use common product identifiers, adding store display and sales information within their assigned permissions |
| Store sales, returns, exchanges and inventory operations | PEKON retail system | Retains store transaction documents and sends relevant results to ERP, CRM and other systems |
| Online orders, order splitting and fulfillment allocation | OMS | Assigns fulfillment tasks to warehouses or stores and receives preparation, collection or delivery results |
| Warehouse receipts and dispatches, batches and quantities actually received | WMS | Supplies records supporting store replenishment and confirms warehouse receipt of goods returned by stores |
| Customer identity, points, vouchers and tier benefits | CRM or loyalty platform | PEKON queries customers and benefits, submits usage or adjustment requests and retains linked records |
| Execution of charges and refunds | Payment system | Executes the movement of funds; PEKON retains payment methods, transaction references, provider results and their links to sales or return documents |
| Accounting entries and adjustments | ERP finance module or finance system | Processes accounting based on sales, refunds, inventory and settlement records |
Responsibility cannot be assigned solely by software name. Inventory, for example, includes physical warehouse stock, physical store stock, order reservations and available-to-sell quantities. WMS manages warehouse operations, while PEKON records store receipts, sales, returns and the resulting store inventory movements. The project must also define how consolidated enterprise inventory, goods in transit and financial inventory records are handled.
From warehouse replenishment to a store sale
Before goods reach the store, the warehouse uses WMS to dispatch them against a replenishment instruction, recording the actual products, quantities and batches sent. Store staff locate the corresponding replenishment document in PEKON, count the goods and confirm the quantity received.
If the warehouse sends 20 units but the store receives 18, each side retains its actual quantity and the difference enters a follow-up process. Warehouse dispatch and store receipt are separate actions at different times. A single completed status cannot adequately represent a quantity discrepancy.
When the customer buys the foundation and lipstick, PEKON handles product scanning, customer identification, promotion calculation and the store transaction record. CRM or the loyalty platform supplies customer identity and available benefits and receives voucher usage and points processing results. The payment system executes the charge, while PEKON retains the transaction reference and provider result.
Suppose the foundation is priced at RMB 400 and the lipstick at RMB 200. The order uses a RMB 60 voucher. Under the brand's proportional allocation rule, the final line amounts are RMB 360 and RMB 180, with a total payment of RMB 540. The original sales document must retain each line's final amount and allocated discount for subsequent partial returns.
After the sale, PEKON records the transaction and deducts the corresponding store inventory. CRM or the loyalty platform processes benefits, and ERP receives sales and inventory results. Although the payment system executes the charge, the retail system retains the sales document, item details, payment method, transaction reference and provider status for store enquiries and after-sales service.
OMS coordinates online orders; the store system records local execution
OMS primarily participates in online order scenarios. For an online order collected in store, OMS manages the original order, any splits and fulfillment allocation, then assigns the task to the designated store. Store staff prepare the goods and confirm collection through PEKON, which returns the execution result to OMS.
If the customer has already paid online, collection must not become another store payment transaction. The systems need to retain the link between the original online order and the store execution record. The project must also specify which system initiates stock reservation and final deduction to prevent duplicate reservations or deductions.
For online orders shipped from a warehouse, OMS passes dispatch tasks to WMS and receives delivery results. Whether fulfillment takes place in a store or warehouse, execution records must remain traceable to the original online order.
Partial returns require separate product, refund and loyalty processing
When the customer returns the lipstick, store staff retrieve the original sales document in PEKON and check the item line, quantity sold and any previous returns. The system creates a return document linked to the original line and determines the refund using the original transaction and the brand's after-sales rules. In this example, the lipstick's final line amount was RMB 180, so the refund record is for RMB 180.
After accepting the item, the store records the returned quantity and condition in PEKON. The product may remain pending assessment until inspection is complete. If it meets the conditions for resale, it can move into the appropriate sellable store inventory. If it must be sent back to the warehouse, the store creates a separate return-to-warehouse document, and WMS confirms the actual receipt when it arrives. A customer return and a store return to the warehouse are related but distinct actions.
The store initiates the refund through PEKON, which submits it to the payment system through the agreed interface. Refund requested, processing and successful are retained as separate states, with the provider's result recorded against the corresponding return document.
CRM or the loyalty platform adjusts points, vouchers and other benefits using the return record. Whether a voucher is restored or discounts on the remaining items need adjustment depends on the brand's loyalty and promotion rules. ERP and finance receive sales, return, refund and inventory results for reconciliation and accounting.
Interface interruptions should preserve the original business record
When an interface has not returned a result, the first step is to establish whether the underlying action has already occurred. A payment timeout does not prove that a charge failed, and ERP not yet receiving sales data does not mean the store failed to complete the sale. Charging again, creating a new sale or issuing another refund can duplicate the business action.
PEKON projects typically use the following principles when designing exception handling:
- Confirm the outcome first: query the receiving system or payment provider to determine whether the action has already been executed.
- Resend the original record: after the interface recovers, continue transmitting the original sale, return or customer record instead of creating a new transaction.
- Retain processing states: distinguish completed, processing and pending steps and identify the team responsible for follow-up.
- Prevent duplicate execution: ensure that the receiving system recognizes results already processed when the same request arrives again.
- Escalate exceptions to a person: stop automated handling where duplicate charges, excess refunds or duplicate shipments are a risk, and retain a record of manual intervention.
The specific query, retry, retransmission and compensation mechanisms depend on the PEKON product version, the capabilities of connected systems and the agreed project scope.
Acceptance testing covers normal transactions and interruptions
A successful interface response alone does not demonstrate that system responsibilities work in practice. During project design and acceptance, PEKON checks whether store, warehouse, loyalty, payment and finance records correspond along the actual business process, and whether processing can continue from the original document after an interruption.
| Acceptance scenario | Result to verify |
|---|---|
| Store sales data reaches ERP more than once | The original sale is recognized without duplicate sales or inventory entries |
| The store has completed the sale, but ERP has not received it | The original record can be tracked and resent without creating another sale or charge |
| The warehouse has dispatched goods, but the store lacks dispatch details | The original dispatch information can be supplied without sending the goods again |
| The customer return is complete, but the store has not returned the item to the warehouse | Only the store product status changes; warehouse inventory does not increase prematurely |
| The return is complete, but loyalty benefits have not been adjusted | Return and benefit processing show separate states, and processing continues after the interface recovers |
| The refund has been executed, but finance has not received the original sale | The refund remains linked to the original sale, allowing processing to continue once the missing data arrives |
Beyond back-office records, store screens need to show staff the current outcome and next action. Project teams need to find unfinished items, the latest handling time and the responsible team, so exceptions do not remain unattended in interface logs.
Connecting store operations with enterprise systems
The PEKON Smart Retail System handles beauty store checkout, promotions, returns, exchanges, store inventory and loyalty coordination. It can connect with a brand's existing ERP, OMS, WMS, CRM or loyalty platform. The implementation objective is to give each result an identifiable source and make it traceable through sales documents, item lines, payment references and inventory records.
In the partial-return example, the store can check refund progress and the condition of the returned item. The warehouse can confirm receipt if the store later sends it back. The loyalty team can explain benefit adjustments, and finance can connect the sale, refund and accounting records. Any unfinished step retains its own state so processing can continue.
Brands can contact PEKON to discuss retail system responsibilities, interface scope and an implementation approach based on their existing systems, store operations and future requirements.
FAQ
Which system should record transactions made in a beauty store?
PEKON records store sales, returns and exchanges, item details, store inventory movements and payment results. It passes the relevant results to ERP, CRM and other systems according to the project agreement.
What inventory do WMS and the retail system each manage?
WMS primarily manages warehouse receipts, dispatches and physical warehouse stock. PEKON manages store receipts, sales, returns and the corresponding store inventory movements. Consolidated enterprise inventory and financial inventory records are handled according to the brand's architecture.
Does OMS manage sales made at the store checkout?
OMS primarily manages online orders and fulfillment allocation. PEKON handles sales made in store. For an online order collected in store, the store system receives the OMS task and returns its execution result.
How do the payment system and retail system divide responsibilities?
The payment system executes charges and refunds. PEKON retains sales and return documents, payment methods, transaction references and provider results, with links between these records.
Are the responsibilities of ERP, OMS, WMS and CRM fixed?
No. A brand may combine several capabilities in one platform or use a separate product master or loyalty platform. PEKON defines the final allocation according to existing systems, data sources, organizational responsibilities and project scope.