A cashier scans one item, but the basket gains two. A stockroom worker reads a label once, yet the spreadsheet contains duplicate rows. Before replacing the scanner, find out where the second record is created: at the reader, during data delivery, or inside the application.
Quick answer: Test one deliberate scan in a plain text editor, then repeat it in your normal software. If both receive duplicates, investigate scanner settings and the input path. If only the business application duplicates the entry, inspect its event handling and quantity logic. Do not block every repeated barcode: two identical products normally share the same retail barcode.
Duplicate scan or legitimate second item?
A barcode usually identifies a product type, not an individual physical unit. Two packs of the same product can therefore produce exactly the same data. A rule that silently discards repeated values might prevent an accidental double entry, but it can also undercount genuine items.
Write down the intended behavior before changing settings: should every trigger press add one unit, should moving an item past a presentation scanner add one unit, or should a serialized item be accepted only once within a transaction? These are different requirements.
Locate the duplication with three controlled tests
1. Establish a plain-text baseline
Use a non-sensitive test label and a local text editor. Close unnecessary scanner utilities and scan once, removing the label from view immediately. Record whether you get one complete value, two complete values, or repeated individual characters. Repeat with a second label. A whole repeated string suggests a different problem from doubled letters.
2. Compare the business application
Repeat the same action in a test transaction, without completing a real sale. Compare incoming data with the resulting quantity. One received value followed by a quantity increase of two points toward application logic, not necessarily two decodes. When possible, ask your software provider to inspect timestamped input and transaction logs.
3. Isolate one delivery path
Record the connection mode and running integration services. Check whether both a keyboard-style input and an SDK or serial integration are active for the same device. In a controlled test, enable only the path your application is designed to use. Do not uninstall production integrations without a rollback plan.
Common symptoms and what to check
| Observed symptom | Check first | Useful test |
|---|---|---|
| One stationary label repeats at intervals | Continuous/presentation mode and re-read behavior | Remove the label immediately, then compare |
| Text editor is correct; checkout quantity doubles | Application listeners, suffix handling and quantity rules | Log one scan event in a test transaction |
| Duplicates appear after reconnecting | Buffered data, offline upload or application retry logic | Compare capture and upload timestamps |
| Two identical products produce only one entry | Overly aggressive same-code suppression | Present two separate units at normal working speed |
| Characters repeat inside a single value | Input software, keyboard processing or communication settings | Compare raw input with the displayed string |
Understand same-symbol timeout before changing it
Some readers offer a same-symbol timeout or re-read delay. This can reduce repeated decoding of one label, but behavior varies by model and operating mode. A reader may require the label to leave its field of view; another setting may allow another decode after a timer expires. Check your exact model's manual rather than borrowing another scanner's configuration barcode.
Manufacturer documentation illustrates these differences: see Zebra's same-symbol timeout modes. Those controls are model-specific examples, not a statement that every WODEMAX scanner provides them.
There is no universally correct delay. Increase it only enough to prevent the unwanted re-read in your workflow, then verify that two legitimate identical items still register. Keep a record of the original setting so it can be restored.
Check trigger mode, suffixes and software together
A handheld trigger workflow and a hands-free presentation workflow need different tests. Read our barcode scanner trigger-mode guide before changing how the reader activates.
If the scanner adds a carriage return, line feed or Tab, verify what the receiving application expects. A poorly configured integration may process the value on one event and again when a terminator arrives. This does not mean an Enter suffix is inherently wrong. Our Enter, Tab, prefix and suffix guide explains the settings to document.
For offline workflows, investigate how stored records are uploaded and acknowledged. Re-uploading a batch can look like repeated scanning even when every original capture was correct. See the offline storage and batch upload guide.
A practical acceptance checklist
Use this as a suggested test plan, not a published performance claim:
- Scan a single label once and confirm exactly one intended record.
- Leave that label visible briefly and check for unintended re-reads.
- Scan two separate products with the same barcode and confirm both count.
- Alternate two different barcodes at normal operator speed.
- Test the configured Enter or Tab behavior in every relevant field.
- Disconnect and reconnect only in a safe test environment; inspect pending records before retrying uploads.
- Restart the application and confirm the approved scanner configuration remains effective.
For each test, record intended captures, raw received records, final application quantity and the time of any mismatch. That small evidence set is more useful to support than “it sometimes scans twice.”
What to request when choosing a scanner
Ask the supplier to demonstrate your actual sequence with your labels and software. Discuss trigger modes, configurable re-read behavior, interface support and configuration backup. Compare handheld barcode scanners with desktop presentation scanners according to how staff handle items, not just the advertised decoding speed.
FAQ
Does a beep prove the POS added an item?
No. A decode indication and a successful application transaction are separate events. Check the received data and final record rather than relying on sound alone.
Should I set the longest possible re-read delay?
No. That can suppress valid consecutive scans of identical products. Test the shortest setting that reliably meets your workflow, if the model offers that control.
Will buying a new scanner fix duplicate entries?
Not if the application processes one input twice. First establish whether duplication occurs in a plain text test or only in the business software.
Can software safely reject duplicates?
Yes, when the business rule is explicit. A serialized-asset check differs from counting multiple identical retail items. Ask your software provider to distinguish duplicate delivery from a genuine second capture, using transaction context rather than the barcode value alone.