During the retail system selection process, the questions customers truly care about are often far more specific than what can be covered in a standard feature checklist.
This article presents real questions and answers from actual system selection discussions between PEKON presales consultants and customers, organized without changing the original business scenarios or product capability boundaries. These questions come from customers’ detailed inquiries into store management, inventory, fulfillment, promotions, system integration, and other operational scenarios. They are also much closer to the issues enterprises need to verify once they enter the solution discussion and Demo stages.
Can promotions be configured differently by store? If store staff temporarily change a price, can headquarters enforce a minimum discount? If two units are missing during receiving, should the store simply change the received quantity, or should the discrepancy go through a separate process? Can a store count 10,000 units of inventory without closing for business? When an online order comes in, should stock be picked from the backroom first, or should front-of-store inventory be used directly?
Once a retailer enters the system selection and Demo stage, questions quickly move beyond “Does the system have POS, inventory, promotions, and membership?” and become much more scenario-specific. The same phrase, “supports promotions,” may mean centralized configuration by headquarters, or it may also involve store-level permissions, manager authorization, and minimum discount limits. Likewise, “supports replenishment” may refer only to manual ordering, or it may include suggested order quantities. Even then, the replenishment algorithm may still need to be customized according to the brand’s business rules.
Therefore, determining whether a retail system is suitable for a business requires more than checking a feature list. Three questions need to be explored further: How much control can headquarters retain? How granular can inventory and fulfillment processes become? And what does the system explicitly not support? The following sections use these real system selection Q&As to examine the actual business boundaries behind different capabilities.
1. Can Headquarters Maintain Control Over Stores? Permissions, Receiving, Employee Operations, and After-Sales Processes
One of the first challenges for a chain retail system is balancing standardization with flexibility. Headquarters wants promotions, discounts, inventory, and business processes to remain controlled, while stores still need to deal with real-world situations such as damaged goods, returns and exchanges, and temporary price changes. Therefore, during system selection, the real question is not simply whether “permission management” exists, but rather: What can stores do independently? At what point is authorization required? And can headquarters later trace exactly what happened?
1. Can different stores run different promotions? How granular can price-change permissions be?
Different promotional campaigns can be configured for different stores. Promotion rules are centrally configured in the backend and executed by store frontends, allowing headquarters to determine which stores participate in which campaigns.
For temporary price changes, the current approach uses store manager authorization. When a staff member changes a price, the store manager must enter an authorization code. Headquarters can also configure a minimum discount threshold in the backend. For example, if headquarters sets the minimum allowable price at 20% off, even an authorized store manager cannot submit a price below that threshold.
One important boundary should be noted: the current price-change control supports only one level of store manager authorization and does not support multi-level approvals based on the depth of the discount. In other words, if a company requires a workflow such as “10% off approved by the store manager, 20% off approved by the regional manager, and 30% off approved by headquarters,” this would need to be evaluated separately.
2. 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.
3. 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?
4. 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.
5. 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 complete 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.
6. How are standard returns handled? Is an exchange a separate process?
A standard return must be linked to the original sales order and initiated by locating the original transaction. The system supports both full-order returns and partial-item returns. If the original order includes free gifts or discounts, the return is processed according to the original sales order and the amount allocated after promotional discounts.
Exchanges are handled according to the price difference between products. Items of equal value can be exchanged directly. If the replacement product is more expensive, the customer pays the difference. If the replacement product is less expensive and the customer needs to receive the difference back, the lower-priced item is handled through a separate return process.
For retailers, the key point to verify is whether returns and exchanges remain part of a closed loop around the original transaction, rather than creating a separate transaction that can no longer be traced back to the original order.
2. Why Does Inventory Keep Failing to Reconcile? Replenishment, BOM, Stocktaking, and Omnichannel Inventory
Inventory is one of the modules most easily summarized during a retail system Demo with the phrase “inventory management supported.” However, the actual challenges faced by different brands can vary significantly. Stores with large SKU counts and inventory volumes may care most about completing stocktaking without closing the store. A brand that orders by full cartons may calculate a requirement of 10 units, while the warehouse can only ship cartons of 24. Another retailer may operate stores, instant retail channels, and online platforms simultaneously and must decide how the same pool of inventory should be allocated across channels.
Therefore, inventory capabilities should be evaluated separately across several processes: how much to order, how inventory changes, how inventory is counted, and how inventory is allocated.
7. How is the suggested order quantity calculated?
The calculation logic differs from brand to brand. In existing projects, suggested ordering typically takes seven categories of factors into account: sales over the previous 60 days, current store inventory, central warehouse inventory, lead time, upcoming promotions, store sales targets, and carton or pack-size rules. The system combines expected sales demand, currently available inventory, and replenishment constraints to calculate a suggested order quantity.
These data do not necessarily come from the same system. For example, supply chain data such as central warehouse inventory usually comes from the ERP, while store sales and promotion data comes from the retail system. Which system provides store targets, lead-time information, pack-size rules, and other data depends on the agreed system responsibilities and integration architecture.
There is also an important system selection boundary here: suggested ordering is currently customized according to each brand’s requirements rather than provided through one fixed algorithm shared by all customers. Sales cycles, inventory strategies, and replenishment logic can differ significantly across brands. In most cases, the system first needs to go live and accumulate a period of actual store data before replenishment logic can be customized around the brand’s real business rules.
Once the customization is completed, when a store creates a new purchase or replenishment order, the system can automatically calculate which products should be ordered and in what quantities, rather than requiring store staff to add items one by one. The order itself can also be configured with an approval workflow. Once approved, it can be pushed to the ERP, where a delivery document is created and then returned to the store for receiving.
8. 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.
9. 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.
10. If a box of facial masks is opened and sold sheet by sheet, how is inventory deducted?
This scenario involves BOM and product conversion. Strictly speaking, a forward BOM mainly supports two inventory models. The first is a physical bundle, where the bundle itself is treated as an independent SKU, shipped, stocked, and sold as such. The second is a virtual bundle, where the bundle itself does not hold separate inventory. When the bundle is sold, the system directly deducts inventory from each component SKU.
Promotion rules can also be used to create a similar “bundle sale” experience. However, the distinction should remain clear: a promotional bundle is a promotion rule and is not the same as BOM-based inventory management.
A reverse BOM can be used when a larger package needs to be broken down into smaller packages or individual units for sale. For example, if inventory is originally managed by “box of facial masks” but a store needs to sell individual sheets, product conversion can first reduce the boxed inventory and then increase the inventory of individual mask-sheet SKUs according to the predefined component quantity. When an individual mask is sold later, inventory is deducted from the individual-unit SKU.
11. 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.
12. Can a store count 10,000 units of inventory without closing?
Yes. For stores with large SKU counts and inventory volumes, headquarters can issue a stocktaking instruction and generate stocktaking tasks. The store can count inventory in batches by product category and submit each category after it is completed. SKUs with no discrepancy, or with discrepancies within an allowed range, can be closed for the current stocktaking cycle, while SKUs with larger discrepancies can be recounted.
This means the store does not need to suspend business in order to complete a full-store stocktake, and normal sales can continue. For large stores, the key question during system selection is not simply whether the system “supports stocktaking,” but whether it can handle real operating conditions such as batch counting, discrepancy recounts, and continuously changing inventory while the store remains open.
13. 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.
14. 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.
15. If a store has only 10 units, how can inventory be reserved separately for Taobao, Meituan, and in-store customers?
Virtual warehouses can be used to separate inventory for different sales channels. A virtual warehouse is essentially a channel-specific inventory account within the system and does not require a physically separate warehouse in the real world.
For example, if a store physically holds 10 units of a product, 3 units can be allocated to Taobao Instant Retail, 2 to Meituan, and 5 to offline retail in the store. Taobao orders read only the Taobao virtual warehouse, Meituan orders read only the Meituan virtual warehouse, and the store POS reads the store retail warehouse. This means different channels do not all see the same pool of “total store inventory,” reducing the risk of overselling when multiple channels sell the same stock simultaneously. The system can also dynamically adjust inventory allocation ratios based on the sales performance of different channels.
3. Where Are the System Boundaries? Promotions, Pre-Orders, Fulfillment, and the Division of Responsibilities with ERP
Mature retail brands rarely operate only one system. POS, ERP, membership systems, mini programs, third-party platforms, and various fulfillment tools often coexist for a long time. Therefore, having more capabilities in one system does not necessarily mean that every business process should be placed within that system.
During system selection, it is more important to clarify in advance: Which system calculates promotions? Where does the ERP’s responsibility begin and end? When is inventory locked? How are online orders distributed? Which requirements are existing standard capabilities, and which still require further evaluation?
16. 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.
17. 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.
18. 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.
19. Can VIP customers receive inventory-locking priority over regular customers?
The system does not currently support prioritizing inventory locking according to customer tier or order priority. The existing capability allows the system to configure whether pre-orders lock inventory, but it does not currently extend to allocation rules such as “VIP customers first” or “high-priority orders first.”
If inventory is currently available, a pre-order can lock the corresponding quantity according to system configuration. If the product is temporarily out of stock, the system records the pre-order demand first and allocates and locks inventory according to the applicable rules once the product arrives. Inventory reports separately show total inventory, locked inventory, and available inventory.
Therefore, “supporting inventory locking for pre-orders” and “supporting inventory allocation according to customer priority” are two different capabilities.
20. Can online orders be automatically grouped into waves and pushed to PDAs for picking?
This is not currently supported as a standard feature. Under the existing process, 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.
21. 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.”
22. 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. The original source material does not provide a complete conclusion on these points, so no additional assumptions are made here.
4. Why Are These Questions More Useful for System Selection Than a Standard Feature Checklist?
Looking at these real questions and answers together reveals that the greatest source of misunderstanding during retail system selection is often not that the system completely “lacks a feature,” but that different parties interpret the same word — “supported” — differently.
“Supports price changes” should lead to further questions: Is there a minimum discount? Who can authorize the change? Are multi-level approvals supported? “Supports ordering” should lead to questions about suggested quantities, which data the algorithm uses, whether the capability is standard, and how much stores can adjust the recommendation. “Supports stocktaking” should lead to questions about whether counting can continue during business hours, how multiple employees collaborate, and how discrepancies are recounted. “Supports online orders” still requires a distinction between inventory allocation, store preparation, and warehouse-level wave picking. “Supports pre-orders” requires further clarification on whether the system simply records demand, locks inventory, or can allocate inventory according to customer priority. Even “supports multiple currencies” requires distinguishing between different operating entities using different currencies and multiple currencies being settled simultaneously within the same operating entity.
These differences may not appear completely in a standard feature checklist, but they can directly affect how the system operates after go-live.
| Selection Dimension | What Should You Ask During a Demo? |
|---|---|
| Permissions & Control | Who can perform the operation? How many levels of authorization are supported? Are there amount, discount, or scope limits? |
| Processes & Exceptions | What is the standard process? How are discrepancies, damaged goods, shortages, and returns handled? |
| Data & Auditability | Are operations logged? Can they later be traced to the user, time, and specific changes made? |
| Standard vs. Customized | Is this an existing standard feature, an existing project-specific customization, or a requirement that still needs to be evaluated? |
| System Responsibilities | What are the respective responsibilities of the POS, retail system, and ERP? Which data require system integration? |
| Capability Boundaries | What does the system explicitly not support? Could one similar feature easily be mistaken for another capability? |
Based on PEKON’s actual presales discussions with retail customers, whether a system is suitable for an enterprise does not depend on whether it can answer “yes” to every question. In many cases, the more valuable answer is a clear explanation that: this capability currently supports only one level of store manager authorization; this is a project-specific customization; this supports inventory allocation priority but does not mean the system automatically plans picking routes; this can lock inventory but cannot allocate it according to VIP tier.
The earlier these boundaries are clarified, the easier it becomes for an enterprise to understand the actual gap between the system’s capabilities and its own business requirements. It also makes it possible to turn the Demo from simply “looking at features” into a genuine system selection and validation process.