When selecting a retail system, the questions customers actually care about are often much more specific than anything found on a standard feature checklist.

This article brings together real questions raised by customers during retail system selection discussions with PEKON’s pre-sales consultants. The conversations have been edited for clarity while preserving the original business scenarios and product capability boundaries. These questions cover practical concerns around store operations, inventory, fulfillment, promotions, and system integration—and reflect the issues brands are more likely to examine once they move into solution discussions and system demos.

Can promotions vary by store? Can head office control the minimum discount when store staff manually adjust prices? If two items are missing upon receipt, should the store simply enter the actual quantity received, or should a separate discrepancy process be triggered? Can a store count 10,000 items without closing for the day? When an online order arrives, should staff pick from backroom stock first or take inventory directly from the sales floor?

Once a retail system selection process reaches the demo stage, questions quickly move beyond “Does the system have POS, inventory, promotions, and membership?” and into scenarios like these. Even a simple statement such as “promotions are supported” can mean very different things depending on whether rules are centrally configured, whether stores have local permissions, whether manager authorization is required, and whether minimum discount thresholds can be enforced. The same is true for replenishment: some systems support only manual ordering, while others can generate suggested quantities—but the replenishment logic itself may still need to be customized around the brand’s operating rules.

So evaluating whether a retail system fits the business requires more than checking boxes on a feature list. Three questions matter in particular: How much control can head office retain over stores? How deeply can inventory and fulfillment workflows be managed? And where are the system’s actual boundaries? The following real selection questions help make those boundaries more concrete.

1. Can Head Office Really Control Store Operations? Permissions, Receiving, Staff Activity, and Returns

Chain retail systems must constantly balance consistency with flexibility. Head office wants promotions, discounts, inventory, and operating processes to remain controlled, while stores still need enough flexibility to deal with damaged goods, returns, exchanges, and ad hoc price changes.

That means the key selection question is not simply whether “permission management” exists. What matters is what stores can do on their own, when authorization is required, and whether head office can reconstruct what happened after the fact.

1. Can different stores run different promotions? How granular can price-change permissions be?

Different promotions can be configured for different stores. Promotion rules are centrally configured in the back office and then executed at store level, allowing head office to determine which stores participate in which campaigns.

For manual price changes, the current control mechanism is store manager authorization. When a staff member attempts to change a price, the store manager must enter an authorization code. Head office can also configure a minimum allowable discount. For example, if the minimum permitted price is set at 20% off, even a manager-authorized transaction cannot be submitted below that threshold.

One important boundary should be noted: the current price-change control supports a single store manager authorization level and does not provide tiered approval based on discount depth. A structure such as “10% off approved by the store manager, 20% by the regional manager, and 30% by head office” would therefore require separate evaluation.

2. Can head office see exactly what price changes were made?

Yes. The system retains price-change transaction records and related operation logs for later review, traceability, and audit purposes.

When evaluating this capability, it is worth looking beyond whether price changes can be restricted. A complete control model should also answer who performed the action, when it happened, what business object was affected, and exactly what was changed. Permissions provide preventive control; logs provide retrospective traceability.

3. If goods arrive damaged or short, can the store simply enter the quantity actually received?

This can be implemented, but the workflow is currently a project-specific customization rather than a standard process. 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 sends it to the ERP.

In practice, however, many customers still prefer a two-step process: confirm receipt first, then record the discrepancy separately together with photos, reasons, and approval information. The reason is straightforward. If 10 units were shipped but only 9 arrived, the missing unit could be the result of under-shipment, transport damage, or damage after the store received the goods. Simply changing the inventory quantity from 10 to 9 may correct the number, but it does not preserve the responsibility trail.

So during system selection, the question should not stop at “Can the store enter the actual received quantity?” It should also cover how discrepancy reasons are recorded, how responsibility is distinguished, where supporting evidence is stored, and whether approval is 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 images to be uploaded from the photo library. This prevents employees from simply reusing an old image, but it cannot fully rule out someone else taking the photo on their behalf at the location.

The current system also does not enforce Wi-Fi binding or geofencing. If strict prevention of proxy attendance is a major management requirement, photo-based clock-in alone is therefore not sufficient. This illustrates an important selection principle: the existence of a feature does not mean it eliminates every business risk associated with that scenario.

5. Can the system show exactly what each employee did during the day?

There is currently no dedicated employee activity report or labor productivity report. However, the back office retains detailed operation logs, including login time, action time, operation type, business object, and modification records. For example, the business can trace which account changed a particular product or storage location at a specific time, including the quantity before and after the change.

These logs can already support auditing and issue investigation. But if the business wants to answer questions such as “How many tasks did this employee process today?” or “How does productivity compare across employees?”, additional reporting and metrics would need to be built on top of the underlying activity data. In other words, having operation logs is not the same as having employee productivity analytics.

6. How are standard returns handled? Is an exchange a separate process?

A standard return must be linked to the original sales transaction. The original order is retrieved before the return is initiated. Both full-order and partial returns are supported. If the original transaction included gifts or discounts, the return is processed according to the original order and the allocated promotional value.

Exchanges are handled according to the price difference between items. An item of equal value can be exchanged directly. If the replacement item is more expensive, the customer pays the difference. If the replacement is cheaper and money needs to be refunded, the refund is processed separately as a return.

For retailers, the key question is whether returns and exchanges remain connected to the original transaction rather than creating a separate, untraceable transaction flow.

2. Why Does Inventory Keep Going Out of Sync? Replenishment, BOM, Stocktaking, and Omnichannel Inventory

Inventory is one of the areas most likely to be oversimplified during a retail system demo with a statement such as “inventory management is supported.” In reality, brands face very different problems. A store with a large number of SKUs may care most about counting stock without closing. A brand ordering by carton may calculate a requirement of 10 units even though the warehouse can only ship in cartons of 24. A retailer selling through stores, instant retail platforms, and other online channels may need to decide how the same physical inventory should be allocated across those channels.

Inventory capabilities are therefore better evaluated across several separate questions: how much to order, how inventory can be transformed, how it is counted, and how it is allocated.

7. What exactly goes into a suggested replenishment quantity?

The calculation logic varies by brand. In existing projects, suggested replenishment commonly takes seven types 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 demand, available inventory, and replenishment constraints to calculate a suggested quantity.

The required data does not necessarily come from a single system. Central warehouse inventory and other supply chain data may come from the ERP, while store sales and promotion data may come from the retail system. The source of store targets, in-transit information, and carton rules depends on the agreed system responsibilities and integration design.

There is also an important capability boundary: suggested replenishment is currently customized according to each brand’s requirements rather than being based on one universal standard algorithm. Sales cycles, inventory strategies, and replenishment logic differ across brands. In many cases, the retail system first needs to operate for a period of time and accumulate sufficient store data before the algorithm is customized around actual business rules.

Once implemented, the system can automatically calculate which items should be included when a store creates a replenishment order and how many units should be ordered, rather than requiring store staff to add products one by one. The order can also follow an approval process before being sent to the ERP, where the shipment is created and subsequently returned to the store for receiving.

8. What if the system recommends 10 units, but store staff think they need 15?

The suggested quantity can be adjustable, while head office controls the permitted adjustment range. For example, if the system recommends 10 units and head office allows an upward adjustment of 20%, the store can increase the quantity to a maximum of 12. Anything above that limit cannot be submitted directly.

Whether exceptional situations allow a separate manually created order, and whether that order requires additional approval, depends on the rules defined for the project. The purpose is to leave room for store-level judgment without turning system-generated replenishment into an unrestricted manual ordering process.

9. What happens if the system recommends 10 units but the warehouse ships only in cartons of 24?

The quantity calculated by the replenishment algorithm is not necessarily the final order quantity. The system can calculate demand first and then apply the carton or pack-size rules configured by the brand.

For example, if a product ships in cartons of 24 but current demand is only 10 units, the rules may specify that no order should be placed yet and that demand should be carried forward to the next replenishment cycle. If the calculated quantity is already close to one carton, the rules may instead round the quantity up to 24. A replenishment model therefore needs to reflect not only theoretical demand but also real supply chain constraints.

10. If a box of sheet masks is sold one piece at a time, how is inventory handled?

This scenario involves BOM structures and product conversion. Strictly speaking, a forward BOM can be handled in two main ways. The first is a physical bundle, where the bundle itself is treated as an independent SKU that is shipped, stocked, and sold. The second is a virtual bundle, where the bundle itself holds no inventory and selling the bundle deducts inventory from its component SKUs.

Promotion rules can also create a similar “bundle sale” experience, but the distinction matters: a promotional bundle is a promotion mechanism, not BOM inventory management.

A reverse BOM is more relevant when a larger package needs to be broken down into smaller packs or individual units. For example, if inventory is managed by box but a store needs to sell sheet masks individually, a product conversion can reduce box-level inventory and increase the corresponding number of single-piece units. Subsequent individual sales then deduct from the single-piece SKU.

11. If a store creates a temporary gift set, does the product have to be created in ERP first?

A temporary bundled product can be created directly in the POS, with inventory deducted from the original component items. After the transaction, component-level sales and settlement data can be sent back to the ERP.

Whether the temporary bundle itself also needs to be synchronized to ERP depends on the agreed product master-data model and integration design. The broader point is that the front end can retain some flexibility for fast selling scenarios, while ownership of formal product master data still needs to be clearly defined.

12. Can a store count 10,000 items without closing?

Yes. For stores with a large number of SKUs or high inventory volumes, the back office can issue stocktaking instructions and generate stocktaking tasks. The store can count inventory in batches by category and submit each category once it is completed. SKUs with no discrepancy, or discrepancies within an acceptable range, can be closed out, while larger discrepancies can be counted again.

The store does not need to close in order to complete the entire stocktake, and normal business can continue. For larger stores, the key selection question is therefore not simply whether “stocktaking is supported,” but whether the system can handle batch counting, discrepancy recounts, and inventory changes while the store remains open.

13. Can four or five people count the same store at the same time? How are their results combined?

Multi-user collaborative stocktaking is supported. Work can be divided by area or task scope, with each employee using a PDA to complete an assigned stocktaking task. Once the individual tasks are completed, the results are consolidated into a single stocktaking master document for discrepancy review and recounting.

How duplicate scans or overlapping task scopes should be handled depends on the actual stocktaking rules used by the business. If products are managed using unique identifiers such as QR codes or RFID, stocktaking devices with barcode or RFID recognition capabilities can also be used to improve bulk identification efficiency.

14. When an online order arrives, can the system allocate from the backroom first and then use sales-floor stock?

The system can be configured with an allocation rule that prioritizes backroom inventory and uses sales-floor inventory when the backroom quantity is insufficient. When an order arrives, the system checks available backroom stock first and then draws from sales-floor inventory if required.

However, two concepts need to be kept separate: inventory allocation priority is not the same as physical pick-path optimization. The current capability can determine which inventory pool is used first, but PDA-based route planning that guides store staff through storage locations is not currently a standard feature. During a demo, asking only whether the system “supports backroom-first picking” can therefore lead to very different interpretations.

15. If a store has only 10 units, how can some be reserved for delivery platforms and the rest for walk-in customers?

Different channel inventories can be separated through virtual warehouses. A virtual warehouse is essentially a channel-specific inventory account within the system and does not necessarily correspond to a separate physical warehouse.

For example, if a store physically holds 10 units, 3 could be allocated to Taobao Instant Retail, 2 to Meituan, and 5 to in-store retail. Taobao orders would read only the Taobao virtual warehouse, Meituan orders would read the Meituan virtual warehouse, and offline sales would use the store retail warehouse. This prevents all channels from viewing the exact same pool of available inventory and can reduce overselling risk. Allocation ratios can also be adjusted according to channel sales performance.

3. Where Are the System Boundaries? Promotions, Reservations, Fulfillment, and the Role of ERP

Mature retail brands rarely operate only one system. POS, ERP, membership platforms, mini-programs, third-party marketplaces, and fulfillment tools often coexist over the long term. More functionality therefore does not necessarily mean that every process should be placed inside the same system.

A more useful selection discussion should establish where promotions are calculated, what remains the responsibility of ERP, when inventory is locked, how online orders are distributed, which requirements are standard capabilities, and which still require separate evaluation.

16. Do promotion rules have to come from ERP?

Usually not. Promotions are generally configured directly in the retail system back office and executed by the front end. ERP promotion rules are also not typically integrated into the retail promotion process.

Retail promotions can involve discounts, threshold reductions, bundles, and multiple calculation rules. Maintaining the same promotion logic across two systems would significantly increase integration complexity. The retail system already has its own promotion engine, allowing promotions to be configured centrally and then called by POS, mini-programs, or other front ends.

Supported promotion types currently include gifts with purchase, spend-and-save discounts, add-on purchases, buy-one-get-one offers, second-item discounts, buy-A-get-B offers, and rules that discount or waive one item among multiple purchased items. Thresholds, eligible products, gift ranges, and discount calculations are configured in the back office, while POS and mini-programs can execute the same promotion rules.

17. If a brand wants to keep its existing POS, can it use only the promotion engine?

Yes, this type of deployment already exists. A small number of customers retain their original POS or mini-program front end while using PEKON’s promotion back office. During checkout, the existing front end calls the promotion engine through an interface, receives the calculated promotion result, and then continues to complete the sale and payment through the original front end.

This approach can suit retailers whose current front end remains usable but lacks sufficient promotion flexibility, while a full replacement would carry a higher cost. It is an existing model, although the number of customers using it is currently relatively limited.

18. If a customer returns an item but does not want cash back, can the refund go into a membership account?

The refund can be credited to the customer’s stored-value account for use in a future purchase. An electronic coupon can also be issued and redeemed during a subsequent transaction. At present, however, the refund amount cannot be converted directly into membership points.

So when a requirement says “refund to the member account,” the business should clarify whether that means stored value, coupons, or points. These are separate account and benefit types within the system.

19. Can VIP customers receive priority when inventory is locked?

The current system does not allocate locked inventory according to customer tier or order priority. It can be configured to determine whether a reservation order locks inventory, but this has not been extended into rules such as “VIP customers first” or “high-priority orders first.”

If available inventory already exists, a reservation can lock the required quantity according to the configuration. If the product is temporarily out of stock, the demand can first be recorded and then allocated and locked according to the relevant rules once stock arrives. Inventory reports distinguish between total inventory, locked inventory, and available inventory.

In other words, “supporting inventory locking for reservations” and “allocating locked inventory according to customer priority” are two different capabilities.

20. Can online orders be grouped into picking waves and pushed directly to PDAs?

This is not currently supported as a standard feature. In the existing process, online orders arrive at the store and the POS prints an order slip. Store staff use the slip to prepare, pick, and pack the order, then confirm “preparation complete” in the system. Depending on the fulfillment method, the customer may then be notified for pickup, the order may be handed to a delivery rider, or it may be shipped through an integrated courier service.

Wave consolidation, PDA task distribution, and storage-location-based picking guidance are currently custom requirements that would need further evaluation. Feasibility and design would depend on the order source, task allocation model, and device interfaces involved.

This distinction matters during system selection because “supporting online order fulfillment” does not automatically mean the system already provides warehouse-style wave picking.

21. Can one operating entity accept both US dollars and Australian dollars?

Currency can be configured by operating entity. For example, an Australian operating entity can use AUD as its main currency. However, a single operating entity currently supports only one primary currency and does not support mixed settlement in multiple currencies such as USD and AUD at the same time.

For brands operating across multiple countries or regions, the important question is therefore how operating entities are structured, rather than simply whether the system “supports multiple currencies.”

22. In department-store concession scenarios, what if transactions cannot be entered on the same day during a major sales event?

The system supports historical transaction entry, allowing the actual transaction date to be selected when the sale is entered later. This can support department-store concession scenarios in which the transaction has already taken place but store staff are unable to complete system entry on the same day.

However, the permissions required for backdated entry, the permitted date range, and the specific impact on inventory and financial day-end processes still need to be confirmed according to project rules. The original source material does not provide a complete conclusion on these points, so no additional assumptions have been added here.

4. Why These Questions Are More Useful Than a Standard Feature Checklist

Looking across these real customer questions, many of the biggest misunderstandings in retail system selection do not come from a system completely lacking a function. They come from different interpretations of what the word “supported” actually means.

“Price changes are supported” still leaves questions about minimum discount thresholds, authorization roles, and multi-level approval. “Replenishment is supported” still requires clarification around suggested quantities, data inputs, whether the algorithm is standard or customized, and how much stores can adjust. “Stocktaking is supported” raises further questions about counting during business hours, multi-user collaboration, and recounting discrepancies. “Online orders are supported” does not tell you whether the system handles only inventory allocation and store preparation or also provides warehouse-style wave picking. “Reservations are supported” may mean that demand can be recorded or inventory can be locked, but not necessarily that inventory can be prioritized by customer tier. Even “multi-currency support” can refer either to different operating entities using different currencies or to a single entity accepting multiple currencies at the same time.

These distinctions rarely fit neatly into a standard feature checklist, but they can directly affect how the system works after go-live.

Selection Area What to Ask During the Demo
Permissions and Control Who can perform the action? How many authorization levels are available? Are there amount, discount, or scope limits?
Processes and Exceptions What is the normal process? How are discrepancies, damage, stock shortages, and returns handled?
Data and Auditability Are actions logged? Can the business trace the user, time, and exact changes later?
Standard vs. Custom Is this a standard capability, an existing project customization, or a requirement that still needs evaluation?
System Responsibilities What should be handled by POS, the retail system, and ERP? Which data requires integration?
Capability Boundaries What is explicitly not supported? Could one similar capability easily be mistaken for another?

A retail system is not suitable simply because the answer to every requirement is “yes.” In many cases, a more useful answer is a precise one: this currently supports only store manager authorization; this is implemented through project-specific customization; this supports inventory allocation priority but not automated pick-path planning; this can lock inventory, but not allocate it based on VIP tier.

The earlier these boundaries are clarified, the easier it becomes for a retailer to understand the real gap between system capabilities and its own operating requirements—and to turn a product demo from a feature presentation into a meaningful system selection exercise.