FAQ

• Check that OTG is turned on in your device's system settings. Some devices have it off by default, and won't recognize external devices until you turn it on;
• Connect the scanner directly to your device if possible. Avoid using a dock or hub to charge the device while using the scanner—some devices have compatibility issues when charging and using an external device at the same time, and the scanner may not be recognized.

Check the scanner's own user manual, reset the scanner to factory settings, and then test again.

• Tap the status button itself first—it will try to reactivate scanning;
• If that doesn't bring it back, try restarting the app or restarting your device.

This is the operating system's default behavior and is perfectly normal. Once a scanner is connected, the operating system treats it as a physical keyboard, so it no longer pops up the on-screen keyboard automatically.

• If you need to type by hand (without the scanner), most devices show a small floating widget on screen (usually a small icon button) for switching to or bringing up the on-screen keyboard—tap it to force the keyboard to appear;
• If you can't find this floating button, it depends on how the device maker customized the system; please contact the seller's customer support.

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.

This only happens in one specific combination: every item in the order was given away (all 100% discount / complimentary) and the order also had a fixed-amount surcharge. In that case, even a full refund can't return the fixed surcharge or its tax.

Why: when a refund is issued, order-level charges (discounts, surcharges, service charge, tax) are allocated back in proportion to each item's amount. When every item is free—amount zero—there's nothing for the surcharge to attach to, so it can't be sliced out and returned.

This isn't a bookkeeping error: the customer did pay the surcharge, and the report reflects it. If you need to return that fixed surcharge to the customer, handle it outside DodorPos (for example, refund it in cash). As long as the order has at least one normally-priced item, the surcharge refunds proportionally as usual.

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.

They're the same period's takings, calculated step by step from the "rawest" to the "most actual":

• Gross sales—the total of all items at the list price and quantity from when they were originally ordered; it's unaffected by whether an order was later refunded or how much of it was refunded.
• Net sales—starting from list price, apply discounts and surcharges, then subtract the refunds that have actually happened (for a partial refund, only the refunded portion is subtracted; the rest still counts)—the amount actually sold.
• Total Amount—net sales plus service charge and tax; in theory, what you should collect for the period.
• Payment Total—the total amount after rounding and change; the money you actually took in.

In short: gross sales is "how much was sold" (regardless of refunds), net sales is "how much is left after refunds," the total amount is "how much should be collected," and the payment total is "how much actually came in."

It's about whether the item's listed price already includes tax:

• Tax-inclusive—the listed price already includes tax; customers pay exactly what they see.
• Tax-exclusive—the listed price excludes tax; tax is added on at checkout.

A shop only uses one of these, so one row in the report is usually 0. They're listed separately so you can clearly see whether the tax collected in the period was "tax within the price" or "tax added on," making filing and reconciliation easier.

No. The tax amount is not derived from pre-tax sales. The two columns come from different sums, and both are accurate:

• Tax amount—the tax actually collected from customers on each transaction in the period, grouped by rate. Each transaction was rounded to the smallest currency unit at checkout, so this column matches the tax printed on your customers' receipts (less any tax returned on refunds).
• Pre-tax sales—the taxable base for those same transactions.

Rounding each transaction and then adding up differs by a few minor units from adding up first and applying the rate. That is normal and does not indicate an error. Which basis you may use to report output tax, and whether such rounding differences must be reconciled, depends on your local tax rules—please confirm with your accountant. DodorPos gives you both source figures: the total tax actually collected, and the matching taxable base.

Both are correct—they measure different things:

• Net sales is a cash-flow figure: item subtotal − order-level discounts + surcharges, less refunds issued in the period; the service charge is shown separately and isn't included here. Whether it includes tax depends on your pricing—with tax-exclusive pricing it doesn't (tax is listed separately); with tax-inclusive pricing, unit prices already contain tax, so this figure does too.
• Pre-tax sales is a filing figure: the taxable base per rate. It includes the service charge and excludes tax—with tax-inclusive pricing, the tax is stripped out of it.

So if you use tax-inclusive pricing or charge a service charge, the two are not expected to match—the gap is the service charge and the tax, not an error.

If you use tax-exclusive pricing with no service charge—where the two should agree—they can still differ by a few minor units while a transaction has been only partially refunded. This comes from allocation rounding and resolves automatically once that transaction is fully refunded.

Average transaction value is "how much a customer spent per order on average" (they may buy several items at once).

Average item price is "how much each item sold for on average," regardless of how many were bought at once.

The two numbers answer different questions—don't treat one as the other.

It's everyday "rounding." When you've set the shop not to take small denominations (like 1- or 5-cent coins), the amount collected has to be rounded, and that small difference is recorded here.

It only affects "Payment Total"; every other figure is calculated from the exact pre-rounding amount, so rounding never throws the numbers off.

No. Gross profit here is only the "selling price (after apportioning order-level discounts/surcharges, but excluding service charge and tax) minus purchase cost" layer. It does not include rent, utilities, labor or equipment—your day-to-day overheads—and it only counts items that have a cost price.

So it's good for roughly gauging "what's left after covering the purchase cost of these goods," but don't read it as "how much I made this month"—your true net profit still needs rent, labor and other costs subtracted yourself.

These fields track this payment method's activity for the period from different angles:

• Sales Count—the number of sales transactions under this payment method for the period; once a transaction is fully refunded, it's no longer counted.
• Net Amount—this payment method's total sales for the period minus its refund amount; refunds are counted by whichever payment method was actually chosen at refund time, not necessarily the order's original payment method (for example, an order paid via WeChat but refunded in cash counts against the cash channel).
• Refund Count—the number of refund operations that used this payment method.
• Refund Total—the total amount refunded through this payment method; already factored into "Net Amount," not an extra deduction on top of it.

These two groups look at different things: Sales Count tracks whether a transaction has been fully refunded, while Net Amount, Refund Count and Refund Total track how much money has actually moved through this payment channel. So a payment method can show a Sales Count of 0 alongside a non-zero Net Amount—for example, a transaction might be fully refunded, but if the refund was split across several different payment methods, the channel the sale originally went through can still show a net inflow or outflow. Likewise, a payment method with no sales of its own that was only used as a refund channel can show a negative Net Amount.

Once generated, a report is a "snapshot": it stays exactly as it was at the moment of generation. Refunds that happen later, or new stats added by an App update, are not automatically added to that old report.

This is deliberate—a report is a record for bookkeeping and reconciliation, and if it changed every time you opened it, you'd never be able to confirm what a given day's figures actually were.

This splits into two cases:

The report is "Incomplete"—it shows a red "Incomplete" tag in the list. When this happens: the report was generated before its period actually ended—for example, generating today's daily report before today is over, so transactions and refunds that happen later naturally aren't included. In this case, just tap the "Regenerate" button next to that report right in the report list; or go back to the list and tap "Generate" again for the same date range—the app will detect that the existing report is incomplete and automatically delete and rebuild it.

The report is "Complete" (generated after its period had already ended)—this kind of report doesn't get an "Incomplete" tag, and there's no "Regenerate" button in the list either; tapping "Generate" again for the same range just opens the existing report without recalculating. To force a refresh, open that report's detail page—there's always a "Regenerate" button below the title (it's there whether the report is complete or not); confirm it and it deletes the old data and re-tallies the latest data for the original date range. You can also delete the report manually and generate a new one instead—it has the same effect as tapping "Regenerate".

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.

A "calendar day" is a day on the calendar, running from midnight to just before midnight the same day.

A "business day" uses your business start time as the dividing line instead: a new day begins at that moment and runs until the same time the next day.

Say you run a stall that opens at 6pm and stays open until 2 or 3am. Going strictly by the calendar, midnight marks the start of a "new day"—except you're still in the middle of the same night's business. The result: one night's revenue gets split across two days, and neither day's report looks right.

Transactions after midnight also get filed under the "next day" on their own, separated from the rest of that same night's orders. However you add up each day's totals, they never quite match.

Set your business day start time to 6pm, and the app understands: everything from 6pm that evening to 6pm the next day counts as the same business day, and the midnight in between is no longer a dividing line. So sales made in the early hours before you close still count toward the day you opened.

For example, with the start time set to 6pm, "August 29th's sales" means the full stretch from 6pm on August 29 to 6pm on August 30—an order sold at 2am on August 30 is counted under August 29.

If your shop doesn't operate past midnight, just leave this at the default of midnight; nothing changes.

Daily, Weekly, Monthly, and Yearly Reports all start counting from whatever time you set.

For example, with the start time set to 6am, the "August" Monthly Report actually runs from 6am on August 1 to 6am on September 1—six hours later than the calendar month.

Transactions are also regrouped by day, with each day's count and subtotal immediately reflecting the new dividing line.

If you have a fixed opening time, or your hours run past midnight, it's worth setting this up early.

How to set it: "Store Settings" → "Business Day Start" → choose your opening time or the nearest hour before it → save.

Setting it back to midnight returns the app to calendar-day-based reporting.

Yes, though we don't recommend changing it often.

After you set or change it, new reports use the latest start time as their business-day unit. Changing it creates a mismatch between old and new reports' reporting periods, and some transactions may end up double-counted or missing from any report.

No—Daily, Weekly, Monthly, and Yearly Reports are locked to business-day reporting and can't be changed.

If you need strict calendar-day figures (for tax filing or reconciling with someone else, for example), use a Custom Period Report instead:

• Choose "Custom" under "Create Report" (it's listed as "Custom Period Reports" in the report list);
• As long as your business day start time isn't the default of midnight, you'll see a "Business day / Calendar day" option—pick "Calendar day";
• Pick your "Start Date" and "End Date," then tap "Generate."

Business day (the default): each day you pick runs from your set start time to the same time the next day, matching how Daily and Monthly Reports work.

Calendar day: each day you pick is a day on the calendar, from midnight to just before midnight the same day.

No, it doesn't.

If your region observes daylight saving time and you've set a business day start time, a handful of orders placed near the midnight boundary on the two days each year when clocks change may get counted into the report for the neighboring day.

It corrects itself the next day—no orders are lost or duplicated.

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.
• It needs Bluetooth permission to connect to the printer; check that this hasn't been turned off in system settings.