Retail system selection requires translating feature names into practical business scenarios. Based on PEKON’s presales discussions, these 30 questions cover store transactions, inventory operations, membership and channels, and implementation and expansion. They distinguish existing capabilities, project customizations, and requirements needing further confirmation.
For example, manual pricing involves both discount limits and authorization levels; inventory management includes product conversion, stocktaking, and channel allocation. For the broader context of product fit, replacement, and ongoing service, see the retail system selection and replacement topic hub.
Store Transactions and Product Management
Retail systems need to record products, prices, promotions, and transaction outcomes. PEKON incorporates these into store workflows so that transactions can be traced in subsequent enquiries.
Can promotions differ by store?
Yes. PEKON’s retail system allows promotions to be configured centrally for selected stores and executed at the store frontend. Headquarters determines which stores participate in each campaign.
Can headquarters enforce a minimum price when staff apply a manual discount?
Yes. A minimum discount threshold can be configured, with store manager authorization required for manual price changes. For example, if headquarters permits a maximum discount of 20%, a price below 80% of the original price cannot be submitted even with manager authorization.
Can manual discounts follow multiple approval levels?
Currently, price changes have one authorization level: the store manager. Approval tiers based on discount size are not supported as a standard capability. A workflow involving store managers, regional managers, and headquarters would require separate evaluation.
Can headquarters review historical price changes made by stores?
Yes. The system retains price-change records and related operation logs for subsequent queries, traceability, and auditing.
Therefore, when evaluating price-control capabilities, enterprises should not only ask whether price changes can be restricted. They should also verify whether the system can reconstruct who performed an action, when it happened, which business object was affected, and exactly what was changed. Permissions provide preventive control, while logs provide post-event traceability. Both are necessary.
How are returns linked to the original sale?
A return is initiated by finding and linking the original sales transaction. Both full-order and partial-item returns are supported. Where gifts or discounts are involved, the applicable original-order and discount-allocation rules must be followed, with returned goods and amounts reconciled. Complex promotion orders require confirmation of the applicable return procedure; refunds should not simply use the current selling price.
How are same-store exchanges for items of equal or higher value handled?
For a same-store exchange, an equal-value item can be exchanged, while an item of higher value requires an additional payment. A lower-value replacement that requires refunding a difference is handled separately through the applicable return process. The original transaction, returned item, and replacement should remain traceable.
How does inventory differ between physical and virtual kits?
A physical kit is shipped, stocked, and sold as an independent SKU. A virtual kit holds no separate inventory; selling it deducts inventory from its component SKUs. The choice depends on how products are packaged, shipped, and sold.
Is a promotional bundle the same as BOM inventory management?
No. Promotions can create a bundle offer, but their primary role is calculating discounts. BOM management defines the inventory relationship between a kit and its components. Confirm both how the bundle price is calculated and which SKUs are deducted after a sale.
How is inventory handled when a box of face masks is sold as individual sheets?
A product conversion reduces box inventory and increases individual-sheet inventory according to the defined conversion quantity. Subsequent sales deduct the individual-sheet SKU. Dividing the box price by the number of sheets does not by itself resolve inventory units or SKU relationships.
If a store creates a temporary gift bundle, does it need to create the product in the ERP first?
A temporary bundle product can be created directly at the POS, with inventory deducted from the original component products contained in the bundle. After the transaction is completed, component sales data and settlement data can be transmitted back to the ERP.
Whether the “temporary bundle product” itself also needs to be synchronized to the ERP cannot be generalized. It depends on the product master data governance model and integration architecture agreed by both sides. This scenario reflects a common system-responsibility issue: the frontend may need a certain degree of flexibility to complete sales quickly, but responsibility for maintaining official product master data must still be clearly defined in advance.
Must promotion rules be distributed from the ERP?
Usually not. In the PEKON Smart Retail System, promotional campaigns are generally configured directly in the backend and executed by the frontend. The system also does not typically integrate with promotion rules maintained internally within the ERP.
The reason is that retail promotions may include discounts, threshold-based reductions, bundles, and various complex promotional calculation rules. If two systems maintain promotion logic simultaneously, integration complexity increases significantly. The existing system already includes an independent promotion engine, so promotions can be centrally configured in the retail system and then called by POS, mini programs, and other frontends.
Currently supported promotion types include gifts with qualifying purchases, threshold-based discounts, add-on purchases, buy-one-get-one-free, 50% off the second item, buy A get B, and multi-item promotions where one item is discounted or waived according to predefined rules. Campaign thresholds, eligible products, gift ranges, and discount calculation methods can all be configured in the backend, while POS and mini programs can execute the same set of promotion rules.
In a department-store concession model, what happens if the store cannot enter all transactions on the day of a major promotion?
The system supports back-entry of historical transactions and allows users to select the actual transaction date. This capability is suitable for scenarios such as department-store centralized payment collection, where the transaction has already taken place but the store cannot complete data entry in the system on the same day.
However, the permissions for historical transaction entry, the permitted date range, and the specific impact of backdated transactions on inventory and financial day-end closing still need to be confirmed according to project-specific rules. These rules should be agreed before go-live, with the corresponding business records checked after back-entry.
Inventory and Multi-Store Operations
Sales, transfers, and stocktaking continually affect inventory records. PEKON manages these movements and provides data access and operating permissions appropriate to headquarters and store roles.
If damaged or missing goods are found during receiving, can the store simply enter the actual received quantity?
Technically, this can be implemented. However, this type of process is currently a project-specific customization rather than a unified standard workflow. In existing projects, stores can enter the actual quantity received. The system compares the shipped quantity with the received quantity, automatically generates a discrepancy return document, and pushes it to the ERP.
In practice, however, many customers still prefer a two-step process: first complete normal receiving, and then use a separate discrepancy workflow to record photos, reasons, and approval information. The reason is straightforward. The same situation — “10 units were shipped, but the store received only 9” — could mean that the supplier shipped one unit short, one unit was damaged during transportation, or the item was damaged after the store received it. If the system simply changes the inventory quantity from 10 to 9, the stock figure may be correct, but the responsibility and event history are lost.
Therefore, during system selection, it is not enough to ask whether the actual received quantity can be changed. Enterprises should also ask: How are discrepancy reasons recorded? How is responsibility distinguished? Where is supporting evidence stored? Is approval required?
Can photo-based attendance completely prevent proxy clock-ins?
No. It can reduce the risk, but it cannot eliminate it completely. The current system requires employees to take a photo on site and does not allow existing photos to be uploaded directly from the phone gallery. This prevents employees from simply using an old photo to clock in. However, if another person is physically present and takes the photo on behalf of the employee, photo-based attendance alone cannot fully prevent this behavior.
The system also does not currently enforce Wi-Fi binding or geofencing. Therefore, if strict prevention of proxy attendance is an important management objective, the existing photo-based attendance mechanism alone is not sufficient. This is a typical issue during system selection: the existence of a feature does not mean that the feature eliminates every risk associated with the underlying business problem.
Can the system report exactly what each employee did during the day?
There is currently no standalone employee activity report or labor productivity report. However, the backend records relevant operation logs, including employee login time, operation time, operation details, business objects, and modification history. For example, the system can trace which product or storage location an account operated on at a specific time, as well as how a quantity was changed from one value to another.
These data are already sufficient for auditing and issue investigation. However, if an enterprise wants to answer questions such as “How many tasks did an employee complete today?” or “How does productivity differ between employees?”, additional reports and KPI frameworks would need to be built on top of the underlying operation data. Therefore, “having operation logs” and “having employee productivity analytics” are two different capabilities and should not be treated as the same thing during system selection.
Which business data can inform suggested order quantities?
Existing projects typically consider sales over the previous 60 days, store inventory, central warehouse inventory, transit time, upcoming promotions, store sales targets, and pack-size rules. The factors and calculation method depend on the brand’s sales cycle and replenishment policies.
How do replenishment data and order documents connect with ERP?
Supply-chain data such as central warehouse inventory usually comes from ERP, while store sales and promotion data comes from the retail system. Sources for targets, transit information, and pack sizes must be agreed in the system responsibility and interface design.
After customization, creating an order can generate suggested products and quantities. Following the configured approval process, the order is sent to ERP, which creates a shipment document and returns it for store receiving. Data preparation, interfaces, and approval rules need to be confirmed together.
What if the system suggests ordering 10 units, but store staff believe they need 15?
The suggested quantity can be made adjustable, while headquarters can restrict the permitted adjustment range. For example, if the system suggests 10 units and headquarters allows an upward adjustment of 20%, the store can increase the quantity to a maximum of 12 units. Quantities beyond the permitted range cannot be submitted directly.
Whether stores may create separate manual orders in exceptional circumstances, and whether those manual orders require additional approval, depends on the specific project rules. The objective of this design is to leave room for store-level operational judgment while preventing suggested ordering from ultimately becoming a completely unrestricted manual process.
What if the system calculates a requirement of 10 units, but the warehouse can only ship full cartons of 24?
The “business demand quantity” calculated by the replenishment algorithm does not necessarily need to become the final order quantity. The system can first calculate demand and then round the order quantity according to predefined carton or pack-size rules.
For example, if a product is packed 24 units per carton and the system calculates a replenishment requirement of only 10 units, the configured rule may decide not to place the order during the current cycle and instead carry the requirement forward to the next cycle. If the calculated requirement is already close to a full carton, the system may round the quantity up to 24 according to the defined rule. Therefore, evaluating a replenishment algorithm is not only about whether the forecast is accurate. It is also necessary to determine whether actual supply chain constraints are incorporated into the final ordering logic.
Can a store count 10,000 units of inventory without closing?
Yes. For stores with large SKU counts and inventory volumes, headquarters can issue stocktaking instructions and generate tasks. Stores count by product category and submit completed categories separately. SKUs with no discrepancies, or differences within the permitted range, can be completed; larger discrepancies are recounted.
Phased stocktaking can be coordinated with ongoing trading, provided the project defines how sales and other inventory movements during the count are reconciled. Confirm counting scope, timing, and recount rules as part of the operating process.
If four or five people count inventory in the same store at the same time, how are the results consolidated?
The system supports collaborative stocktaking by multiple employees. Work can be divided by store area or task scope, and each employee can use a PDA to complete their assigned stocktaking task. Once completed, the results from the individual tasks are consolidated into the same master stocktaking document, where discrepancies can be reviewed and recounts can be performed.
If duplicate scans occur or different task scopes overlap, the exact handling rules need to be confirmed according to the actual stocktaking process. If products are managed using unique identifiers such as QR codes or RFID, stocktaking devices with infrared scanning or RFID recognition can also be used to improve batch identification efficiency.
When an online order comes in, should staff pick from the backroom first or take products from the sales floor?
The system can configure an inventory allocation rule such as “backroom inventory first, front-of-store inventory as a supplement.” After an order enters the system, it first checks whether usable inventory is available in the backroom. If the backroom quantity is insufficient, front-of-store inventory can then be used.
However, two concepts need to be clearly distinguished: inventory allocation priority is not the same as planning the employee’s actual picking route. The current capability can determine which inventory pool the system uses first, but automatically planning an employee’s walking route on a PDA according to store storage locations is not currently a standard feature. During a Demo, asking only whether the system “supports backroom-first picking” can therefore easily lead to different interpretations.
For related store and inventory capabilities, see PEKON Smart Retail. Specific workflows and configuration scope should be confirmed against the brand’s requirements.
Membership and Channel Coordination
Member identity, benefits, and transactions need to connect within actual service workflows. Implementation should account for the brand’s existing membership and channel systems and clearly define their respective responsibilities.
If a customer returns a product but does not want a cash refund, can the amount be returned to the member account?
The refund can be credited to the member’s stored-value account, allowing the customer to use the balance for future purchases. Alternatively, an electronic coupon can be issued and redeemed during a subsequent transaction. However, the system currently does not support converting the refund amount directly into membership points.
Therefore, when discussing “refund to account,” it is important to clarify whether this refers to stored value, coupons, or points. These are different business objects within the system.
How do pre-orders record demand and reserve inventory?
The system can be configured to determine whether pre-orders reserve inventory. Available stock can be reserved according to the configuration. When stock is unavailable, demand is recorded first, with allocation and reservation following the applicable rules after arrival. Reports distinguish total, reserved, and available inventory.
Can VIP customers receive priority when inventory is reserved?
Currently, reservation order cannot be prioritized by customer tier or order priority. Supporting inventory reservation for pre-orders does not imply VIP priority or priority-based stock allocation. These capabilities must be evaluated separately.
If a store has only 10 units, how can inventory be reserved separately for Taobao, Meituan, and in-store customers?
Virtual warehouses can separate inventory allocations by channel without requiring separate physical warehouses. For example, ten units could be allocated as three for Taobao instant retail, two for Meituan, and five for in-store sales.
Whether each channel can read its allocation, how orders reach the store, and how after-sales records are returned depends on the OMS or omnichannel platform, channel interfaces, and retail system working together. Inventory reallocation also needs defined rules and ownership. Configuring virtual warehouses alone does not automatically connect every channel.
Can online orders be automatically grouped into waves and pushed to PDAs for picking?
This is not currently supported as a standard feature. In projects with the required channel and order-system integrations in place, after an online order reaches the store, the POS prints an order slip. Store employees prepare, pick, and pack the goods according to the slip and then confirm “Preparation Completed” in the system. Depending on the order fulfillment method, the store can then notify the customer for in-store pickup, hand the order to a delivery rider, or ship the order through an integrated courier service.
Wave consolidation, PDA task distribution, and location-based picking guidance are currently customization requirements subject to further evaluation. Whether they can be implemented and how they should be implemented depends on the actual order sources, task-allocation model, and device integration requirements.
This distinction is particularly important during system selection because “supporting online order fulfillment” does not automatically mean that the system already includes warehouse-level wave-picking capabilities.
For identity, tiers, points, and benefits, see PEKON CRM Membership Center. Stores apply brand rules and retain transaction records, while channel fulfillment also requires coordination with order systems.
Implementation and Future Expansion
PEKON includes data preparation, training, and business cutover in implementation planning, while considering future store, channel, and organizational changes. Feature discussions should also establish product versions, interfaces, and customization scope.
Does every customer use the same standard replenishment algorithm?
No. The suggested ordering capability described here is customized to the brand; it is not one fixed algorithm shared by every customer. It typically requires store data accumulated after go-live, followed by customization based on the brand’s inventory strategy, sales cycle, and replenishment rules.
During retail system selection, distinguish standard features from existing project customizations and requirements still awaiting evaluation. Confirm data preparation, implementation, and ongoing maintenance responsibilities.
If a retailer already has a POS system and does not want to replace it, can it use only the promotion engine?
This type of deployment is possible. A small number of existing customers retain their original POS or mini program frontend while using the existing promotion backend only for campaign configuration. During checkout, the customer’s existing frontend calls the promotion engine through an API, obtains the promotional calculation result, and then continues to complete the sale and settlement through the original frontend.
This approach is more suitable for scenarios where the existing frontend can continue to be used but its promotion capabilities are insufficient, while the cost of replacing the entire frontend is relatively high. It should be noted that this deployment model currently exists, but the number of customers using it remains relatively limited.
Can one overseas system accept both USD and AUD at the same time?
Currencies can be configured according to different operating entities or operating structures. For example, an Australian operating entity can use AUD as its base currency. However, within the same operating entity, the system currently supports only one base currency and does not support mixed settlement in multiple currencies such as USD and AUD at the same time.
Therefore, brands operating across multiple countries and regions need to further clarify how their organizational and operational structures are divided, rather than simply asking whether the system “supports multiple currencies.”
When replacing an existing system, the scope for migrating products, inventory, members, and unfinished transactions should be planned alongside training, store cutover, and post-launch reconciliation. See the five-step approach to retail system replacement and migration.
The purpose of retail system selection is to connect each requirement with a demonstrable workflow, a data source, and an implementation scope. Clear distinctions between standard functionality, existing customizations, and requirements awaiting evaluation help both parties agree on how the system will operate after launch.