FAQ

Go to "Transaction records," open a transaction's details, and you'll find a "Refund" button at the top (it disappears once the whole order has been fully refunded). After opening it:

• Tick the items you want to refund this time (nothing is ticked by default, so you don't accidentally refund the whole order);
• Adjust the refund quantity if needed;
• At the bottom, choose whether it's "Items returned" and which method to refund the customer;
• When you confirm, a dialog pops up showing the refund amount, method, and whether items are being returned in large text—check it, then confirm.

Yes. A single order supports partial refunds (only some items, or part of an item's quantity) and multiple refunds (refund some now, the rest later), until everything is refunded. Fully refunded items no longer appear on the refund screen.

It records one thing: whether the customer actually gave the goods back this time. It's on by default.

• On—if inventory management is on, the quantities are automatically added back to stock.
• Off (refund only)—the money is returned but stock doesn't change; typically used when the customer wants their money back but hasn't returned the goods.

This choice also affects how the report calculates "refund cost loss" (see "Cost & profit"). Note: items sold on a backorder, or orders made in practice mode, won't actually be added back to stock even if this switch is on.

Yes. By default it uses the order's original payment method, but you can switch to any other method enabled in your shop—for example, if the customer paid by WeChat, you can hand back cash instead.

The report's "Payments" breakdown is calculated by the method actually chosen for each refund. So if you refund a WeChat order in cash, the cash column drops accordingly and the WeChat column may even go negative—this is normal.

• It can't be undone: before you confirm, it warns "This action cannot be undone." If you make a mistake, you can only make it right another way (e.g., contacting the customer).
• No refund reason is required.
• There's no separate cap on count or amount: how much you can refund each time is limited only by how much of that item hasn't been refunded yet.

It counts on the day the refund actually happens, not the day of sale. For example, something sold on the 24th but refunded on the 26th only shows up in the 26th's report; the 24th's report isn't changed retroactively.

This is standard retail practice: sales are recorded on the day of sale, refunds on the day of refund—just like a supermarket's daily books, which aren't rewritten days later because of a return.

Because besides the item's own price, an order usually carries order-level discounts, surcharges, service charges and tax, which the whole order shares. When refunding, the system apportions these to the item by its share of the order, so the refund may be a little higher or lower than the listed price—this is normal, not an error.

There's also a guarantee: refund every item in an order (whether all at once or in several batches), and the refunds add up to exactly what the customer originally paid, down to the cent.

You can't edit it by hand so that the refund total always matches what the customer actually paid and stands up to reconciliation.

When refunding several items together, each item's amount may move a cent or two—the system recalculates all currently ticked items together and splits the total across them, and since each item must round to a payable cent, individual items can differ by a cent or two. This is only display rounding per item; the total and the final amount paid out are always accurate, so you can refund with confidence.

Cost price is optional. Once you fill in a product's cost price, its sold orders get counted into profit, showing up under "Profit" > "Gross Profit" and "Gross Margin" on the report detail page.

For products without a cost price, this can't be calculated—the report shows a "cost price coverage" note telling you how many items are still missing one. To see exactly which ones, check "Items" on the report detail page—on phones, it's marked "Cost not set" under the product name; on tablets, which use a table layout, the "Cost", "Gross" and "Margin" columns for that row show "—" instead.

Leaving it blank doesn't affect ordering, checkout, stock or other features at all—you just won't get accurate profit figures.

It means: if, during this period, the product was sold in even one order without a cost price entered, then all of that product's sales for the period are left out of profit.

There's no "count this order's margin, not that one" splitting—if even one "cost unknown" order is involved, the product's profit is left out as a whole, so you're not shown a number that looks precise but is really cobbled together.

No. The system records "the cost price at the moment of the order," not the current cost price.

For example, if you sell one on March 1 without a cost price, that order is permanently recorded as "no cost"; even if you add the cost price on March 5, the March 1 order won't be counted into profit retroactively—only items sold new after March 5 count toward gross profit normally.

So the earlier you fill in cost prices, the more complete and accurate the profit in later reports.

Yes. Whether it's a change to a single item's own price (like "buy one, get one" or a per-item discount) or an order-level deal (member discounts, spend-threshold discounts), it ultimately gets apportioned into that item's net amount and shows up in its gross profit.

Service charge and tax aren't counted toward profit: service charge is an extra fee on top of the item price, not money earned from selling the item; tax is collected on behalf of the tax authority and passed along as-is, so it isn't the shop's income either.

It depends on whether you chose "Items returned" or "refund only":

• Items returned (the goods came back)—the transaction is treated as if it never happened for profit purposes, so gross profit isn't affected.
• Refund only, no return (money returned, goods not)—the item's purchase cost has already been spent and can't be recovered, so it's counted as a "refund cost loss" and deducted from gross profit, reflecting the real loss.

If your shop has "Allow ordering beyond available stock" turned on, you can still take the order and collect payment even when stock is insufficient—this order is marked as an "out-of-stock order," and the stock number isn't deducted (there wasn't enough to deduct anyway).

In plain terms: you take the money first, can't hand over the goods yet, and the books note an "owed goods" entry. Later, when you restock and adjust inventory, the App uses a "Sold X during out of stock" note to tell you how much is owed, reminding you to give incoming stock to these already-paid customers first.

Two conditions must both be met: the product has "Inventory Management" enabled, and the shop has "Allow ordering beyond available stock" enabled.

If "Allow ordering beyond available stock" is off, an order is simply blocked when stock is insufficient (you can't take it)—it won't become an out-of-stock order. So if you've never turned this switch on, you can ignore this note entirely.

It means: since you last changed this product's stock, X units have been sold while out of stock. It reminds you to set aside that many for customers who've already paid but haven't received goods, leaving the rest to sell to new customers.

If an out-of-stock order was refunded in the meantime, this number automatically deducts the refunded portion, showing only what's "still owed to customers."

No. It's just a running count of "how many out-of-stock units have sold since you last changed stock," and has nothing to do with "whether you handed the goods to customers."

Any time you change the stock number (even just fixing a stocktake), this count resets to zero and starts over. So if you adjust stock for some other reason before delivering, the undelivered owed goods "vanish" from the note—but the customers still haven't received them. The App doesn't record or remind you of this, so you'll need to keep track yourself.

• Before changing stock each time, check this note first and jot down the number (or screenshot it); make sure you've contacted and delivered to all the customers, then change the stock number.
• If part of a restock goes to out-of-stock customers and part is for new sales, handle the out-of-stock customers first, then change the stock in one go at the end—so you don't reset the count by changing it midway.

It's only a quantity reminder; it won't tell you which specific customers or orders. For the actual orders to deliver, check the transaction records yourself.

No—it just becomes temporarily invisible. Once off, stock and this note no longer show, but the amount owed to customers is still remembered and not cleared; turn inventory management back on and the note reappears as before, with the same number as before you turned it off.

So don't treat "turning it off and on" as a way to clear what's owed.

Essentially no. This note is shown alongside on-sale products, so once you delete a product there's no way in to see how much it owed (even though the order records remain in transaction history).

So if a product still has unsettled out-of-stock orders, we don't recommend deleting it—first handle the deliveries and get the note to zero, then delete.

The app starts in Practice Mode by default—it's meant for learning and trying things out, and has exactly the same features as Business Mode, not a stripped-down version. The only difference is how data is split:

• Kept separate: transaction records, and the reports generated from them—Practice Mode and Business Mode each have their own set, completely invisible to the other.
• Shared: products and categories (adding, editing, or deleting them is the same data no matter which mode you're in), stock quantities, and shop-wide settings (tax rate, currency, payment methods, etc.).

The one behavioral difference: checking out in Practice Mode never actually deducts stock, even if "Inventory Management" is turned on.

Recommended workflow: enter your shop's real products, categories, and discounts as basic data (no need to set up separate dummy data for practice—this data is shared anyway), then run through your day-to-day checkout routine in Practice Mode—ordering, checkout, refunds, reports, all of it. Once you're comfortable, switch to Business Mode and start operating for real; the product data you set up carries over unchanged, no need to re-enter anything.

In Practice Mode, a "Practice" watermark shows in the bottom-left corner of screens like ordering, checkout, payment, transaction list, and reports, and the same mark appears on the e-receipt—easy to spot at a glance.

No. Even with "Inventory Management" turned on, checking out in Practice Mode never triggers a stock deduction.

Yes, but only in Practice Mode's own transaction records and reports. Switch to Business Mode and these practice transactions are completely invisible, and vice versa—the two are separate, independent books that never mix.

Yes, the same flow as Business Mode, including partial refunds. The only difference: choosing "Items returned" won't restore any stock, since the transaction never deducted stock in the first place.

The first time you open the app, a "Select Mode" prompt appears, defaulting to Practice Mode. After that, you can switch anytime under "Settings → Feature Settings → Learning," by setting "Transaction Mode" to Business.

Under "Feature Settings → Learning" there's a "Clear Practice Data" button—tap it to wipe all Practice Mode transaction records and reports at once. Products, categories, and other basic data and settings aren't affected. This can't be undone, so you'll get a confirmation prompt first.

No. Practice Mode and Business Mode data are each kept intact—switching only changes which one you're currently viewing. Nothing gets deleted from either side unless you manually tap "Clear Practice Data."

Yes. As long as the old and new phones are signed in to the same Google account and the phone's backup is on (most phones have it on by default), reinstall Dodor POS on the new phone and use it online for a while, and the system restores your data automatically—no manual steps needed.

The timing is decided by the phone's system: usually during the new-phone setup wizard, or automatically after install when the phone is online, charging and idle.

Shop settings, product info, transaction records and reports are all restored automatically; only product photos are not.

This is a deliberate trade-off: phone backups have a size limit, and photos take up a lot of space. Including them makes it easy to exceed the limit as products pile up, and once exceeded, even more important data like transaction records could fail to restore. So we prioritize protecting your business data and leave photos for you to re-shoot or re-select after switching—this doesn't affect normal ordering and payment.

Don't use "uninstall and reinstall." On the same phone, uninstalling and reinstalling often lets the system auto-restore your data again—you think it's wiped, but it isn't.

The right way: go to your phone's "Settings → App management → Dodor POS → Clear data." Only this truly wipes it, with no system restore.

Recommended device specs—all mainstream, nothing special:

• Phone: 6.5" screen or larger
• Tablet: 11" or larger
• OS: Android 9.0 or later

The app is designed for touch, single-window use. It isn't adapted for split-screen multitasking or a desktop-style setup with an external keyboard and mouse, so we don't recommend using it that way.

Phones work best held in hand for taking orders, scanning with the rear camera. Tablets work best set flat on the counter, scanning with the front camera.

The app offers two display modes—"Phone Mode" (portrait, fixed) and "Tablet Mode" (landscape, fixed)—and picks the right one automatically based on your device when you install it.

If it picks wrong, you can switch manually under "Settings Center → Feature Settings → Display Mode."

We don't recommend switching a phone or other small-screen device to Tablet Mode—it can break the layout and make the app unusable.

Dodor POS keeps things simple in two ways that fit how most independent shops actually run:

• Offline, single device—your data lives on the device itself, with no real-time sync across multiple devices. We recommend using one device at a time for a given shop's data—if the owner's phone and a staff member's tablet both ring up sales at once, the two won't share data, and the books won't match up afterward.
• Single shop—built for one shop, one register. There's no head-office/branch structure for managing a chain of stores.

We recommend treating the app as the dedicated purpose of the device, keeping it running in the foreground:

• While running, it keeps the screen on and temporarily disables sleep, so it drains the battery faster than typical use—keep it plugged in.
• It needs notification permission to show low stock alerts; check that this hasn't been turned off in system settings.
• It needs camera permission to scan items for orders; check that this hasn't been turned off in system settings.