For an international brand entering China, extending the group's existing global POS is often a reasonable choice. The product is established, headquarters is familiar with it, and financial reporting and data definitions are easier to keep consistent. As operations develop, however, China stores need to respond to local payments, electronic invoicing, promotions, the WeChat ecosystem, shopping-mall partnerships and orders from multiple platforms. These requirements can create friction with headquarters' priorities for cross-market standards, stable versions and centralized governance.
The question is whether the deployed version, modules, partner solutions and integrations can continue to support China operations. A small number of missing connections may be addressed through localization. Persistent constraints across transactions, promotions, membership and local integrations may justify redefining the China store layer. The decision should be grounded in live operational issues, ownership boundaries, the cost of change and scenario-test results.
1. Why Do Global POS Deployments Encounter Recurring Problems in China?
Global standardization and local execution serve different needs. Headquarters seeks to reduce differences between countries and control versions, permissions, data and audit risks. China teams need to respond to changes in channels, payments, marketing, shopping-mall requirements and customer touchpoints. A system serving both objectives must continually balance standardization with local change.
The friction often appears in daily work: a campaign waits for a global release window; store staff record exceptions outside the system; payments and refunds require manual reconciliation; member or order information is only available the following day; or an integration failure requires several parties to investigate. When these workarounds become routine, operating effort rises, data quality suffers and headquarters loses visibility.
| Operational symptom | Why it keeps recurring | Question to answer |
|---|---|---|
| China promotions launch slowly, with special rules handled outside the system. | The global template prioritizes stability while China marketing needs faster changes. | Can the current version support the rule through configuration? Who approves, tests and maintains it? |
| Payments, refunds, e-invoices and daily closing require manual checks. | The local transaction flow involves payment providers, invoicing and financial reporting conventions. | Can the order, payment, invoice and daily reconciliation be traced end to end? |
| Connecting WeChat, mini-programs, WeCom or local e-commerce touchpoints is difficult. | The global customer architecture differs from China's customer touchpoints. | Which system owns identity, benefits, consent and data exchange? |
| ERP, OMS, CRM, WMS and store records do not agree. | Headquarters and China teams have not clearly assigned responsibility for master data and business documents. | Which system is authoritative for each record? How are failed exchanges retried and reconciled? |
| A change requires headquarters, the vendor, regional teams and local partners. | The change process is long and accountability is fragmented. | Who owns the requirements, code, documentation and go-live decision? |
| Stores depend on spreadsheets or temporary processes to keep trading. | The system scope does not cover real exception scenarios. | Have workarounds become routine? How much re-entry and reconciliation do they create? |
Asking whether a feature is supported addresses only the first layer. Brands also need to confirm that it is available in the deployed version, works with existing hardware and interfaces, remains compatible with upgrades, and has support that meets the business's response requirements.
2. What Should You Check in an International Retail System Used in China?
Cegid Retail, Oracle Retail Xstore and Retail Pro Prism all have established international retail capabilities. Evaluation should focus on the version and scope actually deployed by the brand. Country packages, payment providers, partner extensions and historical customizations can produce different outcomes for different deployments of the same product.
| Platform | Capabilities described in official materials | What to verify for China | Evidence to request |
|---|---|---|---|
| Cegid Retail | Positioned as a global POS and unified commerce platform connecting customer data, inventory and store operations. | Whether China promotions, membership touchpoints, payments and e-invoicing are delivered by the standard product, local components or project customization; how local changes enter the global release process. | Deployed version and module list, configuration demonstration, integration responsibility matrix, upgrade compatibility documentation and support service-level agreement (SLA). |
| Oracle Retail Xstore | Xstore 24.0 covers daily transactions and store operations. The 22.0 tender documentation describes digital-wallet support for Alipay, WeChat Pay and refunds through EFTLink; actual availability depends on payment-provider and deployment configuration. | The deployed version, EFTLink and payment-provider setup; delivery of coupon, gift-card, membership, shopping-mall promotion and peripheral-device workflows. | Version documentation, end-to-end payment tests, promotion scripts, device list and failed-transaction retry records. |
| Retail Pro Prism | A modular platform with connections to ERP, loyalty and analytics systems, configurable interfaces, real-time communication and centralized control. | Who provides China localization; whether customizations and integrations are documented; whether existing extensions constrain upgrades. | Customization inventory, maintenance responsibilities, API documentation, data dictionary, upgrade tests and support ownership. |
Four practical questions matter: Is the capability included in the live deployment? Can changes be delivered at the pace China operations require? Who owns integrations and data? Will existing extensions continue to work after an upgrade?
Collect the most difficult issues from the past six to twelve months. Record frequency, affected stores, manual steps, data impact and responsible parties. Turning a broad complaint about usability into specific scenarios helps distinguish configuration, integration, customization, release-governance and ownership problems.
3. Localize the Existing System or Redefine the China Store Layer?
Within PEKON's solution for International Brands Entering China, PEKON can serve as the China store execution layer: store transactions, promotions, member identification, inventory operations and local integrations take place in the China system. Headquarters ERP, OMS, CRM or business intelligence (BI) systems retain the agreed responsibilities for group master data, order coordination, finance and analytics.
An isolated payment, invoicing or promotion issue can first be addressed through configuration and local adaptation. If several constraints persist together and affect trading or data quality, evaluate whether the China store layer should be replaced.
If member, order or employee personal information is transferred overseas, the brand's legal and compliance teams must assess the data scope, applicable transfer conditions and required procedures. Interface design does not replace that assessment. China's Cyberspace Administration sets out distinctions between security assessments, standard contracts, personal-information protection certification and certain exemptions in its Provisions on Promoting and Regulating Cross-Border Data Flows (Chinese).
Local transactions: reconcile payments, refunds, e-invoices and daily closing
The PEKON Smart Retail System supports POS, products, promotions, inventory, orders, member identification and store closing, with local payments, e-invoicing and surrounding systems connected according to project scope. Validation should include payment, cancellation, full and partial refunds, split tender, invoicing exceptions, transaction synchronization after a network interruption and daily-closing discrepancies.
In a China project for an American lifestyle brand, the local team was lean and had no dedicated IT staff. PEKON delivered local POS, payments, e-invoicing, WMS integration and bilingual implementation support, with defined data exchanges between store operations and the brand's existing systems. See the American lifestyle brand customer story.
Promotions and membership: configurable rules with traceable outcomes
Promotion complexity arises from the interaction of product scope, membership tier, store and channel, coupons, gifts, stacking and exclusion rules, and campaign timing. Before launch, use the brand's own products, member profiles and order scenarios to test promotion eligibility, benefit adjustments after a refund and what headquarters can see.
For a U.S.-based premium beauty group, a shared platform supported multiple brands and connected mini-programs, CRM and ERP. The scope included complex promotions, mobile POS, order imports and offline trading. Data exchange moved from next-day processing to real-time distribution, while membership clubs and access permissions remained separately configured by brand. See the international beauty group customer story.
Headquarters integration: assign responsibility before building interfaces
For products, prices, inventory, members, orders, payments, invoices and financial results, first document which system creates, changes and confirms each record. Then define field mappings, synchronization direction and frequency, monitoring, failure retries and reconciliation.
PEKON Jingang Low-Code PaaS supports ongoing change through visual configuration, workflow and rule extensions, API orchestration and data transformation. During evaluation, classify every requirement as standard functionality, configuration, integration, custom development or currently unsupported. Record the owner, test method and upgrade impact for each item instead of treating all differences as a generic integration promise.
Replacement and business continuity: verifiable migration and a rollback plan
In a project for a leading luxury brand, the previous POS had been used for more than 20 years and supported three store operating models. Through historical-data migration, a parallel-running strategy and repeated rehearsals, PEKON completed the transition across more than 300 stores while maintaining trading continuity.
The project illustrates why data, integrations, rehearsals, cutover and on-site support need to be managed as one coordinated implementation. See the luxury-brand POS replacement customer story (Chinese).
Local support and headquarters governance: make bilingual collaboration tangible
A China project involves stores, local operations, headquarters IT and global suppliers. Bilingual collaboration should produce architecture diagrams, scope definitions, data dictionaries, interface documentation, test evidence, training materials and issue records. These deliverables let headquarters audit changes, interpret data and trace failures.
For an international premium chocolate brand, China stores used a Chinese-language iPad POS while relevant headquarters staff used an English-language web interface. The project also covered batch and expiry management and headquarters coordination. The example shows how different user interfaces and shared project documentation can support local store operations and headquarters requirements together. See the premium chocolate brand customer story (Chinese).
4. Define the Replacement Scope and Retain What Still Works
Brands facing China localization issues generally have three options. The choice depends on whether the gaps are limited to a few connections, whether core store workflows are being constrained, and whether headquarters permits a change to the China system boundary.
| Approach | Suitable circumstances | Main work | Principal risk |
|---|---|---|---|
| Retain the current global POS and add local connections. | Core transactions are stable; issues are concentrated in a few payment, invoicing or channel connections. | Add adaptation services, monitoring, reconciliation and clear support responsibilities. | Additional connection layers can increase long-term maintenance complexity. |
| Retain headquarters core systems and replace the China store layer. | China promotions, membership, store workflows and local connections remain constrained, but headquarters ERP, OMS and BI remain suitable. | Redefine responsibilities, migrate store data, rebuild necessary interfaces and roll out in phases. | Parallel reconciliation, historical-data migration and store training require substantial work. |
| Extend the program to upstream systems. | Master-data, order, inventory or finance responsibilities must also change, and the existing architecture cannot be clearly separated. | Redesign the business architecture, data governance and implementation roadmap. | The broadest scope, with greater decision-making, testing and organizational-change requirements. |
When transaction, promotion and local-integration issues persist together but headquarters core systems remain stable, the second option deserves evaluation: retain suitable headquarters systems, let the China store layer handle frequent local changes, and exchange necessary data within the agreed scope.
Look for four kinds of evidence before starting a replacement project: key campaigns repeatedly depend on manual workarounds; stores routinely re-enter data or reconcile manually; China requirements repeatedly miss commercial windows; or historical customizations have made upgrades and support difficult. Fix individual issues where possible. Persistent problems across several areas warrant a review of system boundaries.
5. Estimate the Hidden Costs Before Approving the Project
License and implementation quotations cover only the visible costs. Internal effort and operational risk during transition can be equally important. Estimate the following six areas when comparing suppliers.
| Cost area | Commonly overlooked work | Deliverables needed before approval |
|---|---|---|
| Data migration | Quality and retention scope for products, stores, employees, members, points, coupons, stored value or card balances, historical orders and in-flight documents. | Data inventory, field mappings, cleansing rules, migration batches and reconciliation criteria. |
| Interface rebuilding | Dependencies across ERP, OMS, CRM, WMS, finance, BI, payments, invoicing and local platforms. | System map, interface inventory, authoritative-system assignments, retry and reconciliation rules. |
| Parallel operation | Differences between old and new systems for sales, payments, refunds, inventory and daily closing within the same trading period. | Parallel-running plan, variance thresholds, issue owners and conditions for retiring the old system. |
| Devices and networks | POS hardware, scanners, printers, cash drawers, payment terminals, mobile devices and weak-connectivity conditions. | Compatibility list, in-store tests and offline/recovery scripts. |
| Training and change management | Different workflows for headquarters, regional teams, store managers, sales associates, finance and customer service; continued use of old habits. | Role-specific materials, training records, rehearsal results and go-live support arrangements. |
| Cutover and rollback | Failed store cutovers, delayed data, inventory discrepancies or critical transaction failures. | Cutover runbook, rehearsal records, store rollout batches, rollback criteria and emergency contacts. |
Design the migration scope first. Business, IT, finance and compliance teams should agree whether historical orders remain read-only, whether customer permissions allow the intended migration, how outstanding benefits are reconciled, and which system will complete open orders.
Before parallel operation begins, define comparison rules, acceptable variances and the criteria for shutting down the old system. Without them, maintaining two systems can continue unnecessarily and the final cutover decision becomes harder.
6. Divide Responsibilities Between the Global and China Layers
The following matrix assigns responsibilities; it does not rank the two layers. Consistent global governance and responsive local operations can coexist when each business object has a clear authoritative system and cross-system results can be reconciled.
| Area | Global layer | PEKON China store layer | Boundary to agree |
|---|---|---|---|
| Main objective | Cross-country standards, group control, consistent data and long-term stability. | China store trading, local channel connections and delivery of business changes. | Which rules are global and which are maintained by the China team? |
| Typical responsibilities | Group master data, global finance or supply-chain coordination and regional analysis. | POS transactions, promotion execution, store inventory operations, member identification and local daily closing. | Who creates, changes and finally confirms each data object? |
| Customer touchpoints | Receive necessary outcomes or retain the group customer architecture. | Connect WeChat mini-programs, payments, coupons and local service entry points within project scope. | Identity, benefits, consent and permitted data use. |
| Payments and invoicing | Receive aggregated or financial results. | Handle China store payments, refunds, e-invoicing and exceptions. | How are orders, payments, invoices and daily closing linked and reconciled? |
| Promotion changes | Maintain global principles, approval and audit requirements. | Configure and test China campaign rules and store execution. | Configuration scope, approvals, refund treatment and promotion stacking. |
| Integration | Group ERP, OMS, CRM, BI and other systems. | Local POS, WMS connections, payments, invoicing and China platforms. | Fields, direction, frequency, monitoring and retry ownership. |
| Release governance | Coordinate releases and limit differences across regions. | Respond to China requirements and test within agreed boundaries. | Does a local change affect global upgrades? Who approves go-live? |
| Operational support | Global service desk and group vendor management. | Chinese-language store support, on-site coordination and bilingual issue tracking. | Support hours, escalation paths, severity levels and SLAs. |
7. Complete a Six-Step Fit-Gap Assessment Before Replacement
Step 1: Map the current architecture
List the POS, ERP, OMS, CRM, WMS, finance, BI, payment, invoicing and customer-touchpoint systems used by headquarters and China. Identify master-data sources, critical interfaces and maintenance teams. Without this map, the replacement scope is easily underestimated.
Step 2: Turn pain points into executable scenarios
Translate statements such as “promotions are inflexible” or “synchronization is unreliable” into test scripts. For example, a specific member buys a product bundle in a specific store, applies a channel coupon and later requests a partial refund. Another scenario might test a transaction completed offline and how order, payment and inventory records are transmitted after connectivity returns. Each script needs expected results and a verification method.
Step 3: Confirm global and local responsibilities
Assign responsibility for products, prices, inventory, members, orders, payments, invoices and financial results. Include retained headquarters systems in the test scope and verify the end-to-end data produced by a China POS transaction.
Step 4: Classify capabilities and confirm gaps
Suppliers should identify each requirement as standard functionality, configuration, integration, custom development or currently unsupported. For configuration, integration and custom work, confirm delivery ownership, acceptance evidence, upgrade impact and long-term maintenance.
Step 5: Run a proof of concept or detailed demonstration with representative data
Prioritize local payments and refunds, complex promotions, member identification and benefits, e-invoicing, offline trading, daily reconciliation and failures in exchanges with core systems. Representative products, roles, documents and peripherals provide more useful evidence than a generic feature demonstration.
Step 6: Rehearse migration and cutover before approving wider rollout
Use a subset of anonymized or authorized data for a trial migration. Reconcile counts, amounts, statuses and relationships. Then rehearse cutover, parallel operation, exceptions and rollback in representative stores. Resolve outstanding issues before turning the process into a repeatable phased-rollout plan.
8. Make System Boundaries the Starting Point for the Decision
Persistent friction in China often means local changes have outgrown what the deployed version, integrations and governance process can accommodate. Extending the existing arrangement, adding local connections or replacing the China store layer can each be appropriate when supported by operational evidence and clear responsibilities.
A responsible replacement assessment answers three questions: What should headquarters retain? What should the China layer own? How will stores keep trading, with reconcilable data, during migration and parallel operation? Establish those answers before comparing product features.
If your China operations face recurring constraints in promotions, payments, membership or integrations, review the deployed version, system map, interface inventory and real business scenarios to determine the appropriate localization or replacement scope.
Explore PEKON's China localization and retail solution for international brands.
Frequently Asked Questions
Why assess a global POS that already offers a China version or country configuration?
Published support establishes a capability baseline. You still need to verify whether the deployed version, modules, payment providers, peripherals and project customizations meet current requirements. Confirm who delivers changes, how quickly they reach production and whether they remain compatible after upgrades. Evaluate the actual deployment.
Does using Xstore, Cegid or Retail Pro mean we need to replace it?
No. When core transactions are stable and gaps are concentrated in a few connections, local adaptation should be evaluated first. Consider replacing the China store layer when core workflows persistently depend on manual workarounds, local requirements repeatedly miss commercial windows, or historical customization materially impedes upgrades and maintenance.
Does replacing the China POS require replacing headquarters ERP, OMS and BI?
No. Suitable headquarters ERP, OMS and BI systems can continue to manage group master data, order coordination and analytics, while the China store system handles local execution and integrations. Consider a broader redesign when upstream responsibilities and data definitions must also change.
How can we explain the need for a China-local system to overseas headquarters?
Use evidence: the current system map, issue frequency, affected stores, manual steps, data discrepancies, missed business windows, candidate architectures and proof-of-concept results. Explain how global standards will be retained, how data will be exchanged with headquarters and how local changes will be audited.
Which China scenarios should a proof of concept prioritize?
Prioritize frequent, business-critical end-to-end scenarios: local payments and refunds, complex promotions and coupons, member identification and benefits, e-invoicing, offline transactions, daily reconciliation and ERP or OMS integration failures. Include normal and exception paths, expected results and reconciliation evidence.
Must all historical data move into the new system?
No. Scope depends on continued operations, customer-service queries, financial audits and regulatory requirements. Some historical orders may remain read-only in the old system or an archive. Members, points, coupons, stored value and unfinished orders need separate treatment based on permissions, balances and fulfillment responsibilities.
How can we reduce trading risk during store cutover?
Complete trial migration, integration testing, representative-store pilots and repeated cutover rehearsals before phased rollout. Define how sales, payments, refunds, inventory and daily closing will be compared during parallel operation. Prepare rollback criteria, emergency contacts and on-site support arrangements.
Does PEKON replace the global system or provide the China-local layer?
It depends on the brand's architecture. A common approach retains suitable headquarters core systems while PEKON handles China store execution and local connections, exchanging necessary data under agreed rules. Final scope depends on existing systems, contractual boundaries, data responsibilities and scenario-test results.