A handheld with a built-in printer combines data capture, application decisions and paper output in one enclosure, but the business transaction still has several separate states. A scan can succeed while the record is rejected; a print command can be accepted while no usable paper output appears; a reprint can create a duplicate if the application has no transaction rule.
This guide is for field-service, delivery and retail project teams considering an integrated printer handheld. It follows one scan-to-receipt workflow, compares the evidence needed at each state and shows where an external printer changes the design. It does not claim that an AIDC GO model includes a printer, media option, status API or fiscal/payment certification.
Define the document and transaction before the device
Name the paper output. A customer receipt, route acknowledgment, shelf label and service ticket have different dimensions, durability, data and duplicate-control requirements. Specify the finished layout, required text and symbols, media type, retention period, language and any legal or business approval before choosing a printer width.
Then define the event that authorises printing. A scanned parcel might open a delivery record, but the receipt should be generated only after the application confirms the correct customer, quantity and disposition. If a business number is assigned, identify whether it comes from the server, a controlled offline range or another authorised source. The printer must not invent that identity.
Use the Rugged Handheld Terminals page to discuss the broader handheld direction, while treating the printer as an unconfirmed configuration until a model document says otherwise. The current product page does not prove an integrated printer option.
Walk through an editorial scan-to-receipt event
Consider an editorial field-service example. A technician scans an asset label, opens the assigned work order and records one replaced component. The application validates the asset and component, obtains a service-event number, builds a short receipt and submits a print job. The operator checks the job status and the actual paper before handing the document to the site representative.
If the printer reports paper out before output begins, the application keeps the event number and marks the print obligation as pending. After paper is loaded, the operator uses a controlled reprint action tied to that number. If the connection drops after the print request, the application first checks its own job record and any documented printer status before deciding whether to reissue the output.
The physical copy carries the same event number and an explicit copy or reprint rule. The application does not create a second service event merely to produce another sheet. This example is a suggested workflow, not a customer deployment, measured success rate or promise of a particular device behavior.
Keep business acceptance, print submission and paper output separate
Android's custom document printing guide separates application document layout from the print framework and print service. That architecture supports a general lesson: application acceptance and print processing are different states. It does not establish that an integrated printer handheld uses Android's system print framework.
SUNMI's printer developer documentation describes SDK access to built-in thermal printers on named SUNMI terminals and notes that different printer specifications and interfaces apply to different models. This is evidence for that vendor environment only. It is not an AIDC GO SDK or a universal embedded-printer interface.
On printed page 5, the SUNMI example distinguishes the interface execution result reported through onRunResult from the print result reported through onPrintResult in transaction printing mode. A successful interface execution result does not by itself prove that the complete paper output was produced and remained legible. The meaning and availability of either callback must still be checked for the exact model, interface and operating mode. Here, transaction printing mode is an SDK concept; it is not proof that a business transaction or payment has been accepted.
The application record should therefore retain at least the business event identity, document version, print request time, target device or service, result returned by the documented interface and reprint history. A paper observation is still necessary where the interface cannot prove that the complete, legible document left the mechanism.
Use one state table for normal and exception paths
| Workflow state | What the project should record | Decision before moving on |
|---|---|---|
| Object captured | Scanned value, symbology if relevant, operator and task context | Does the value select the intended record rather than merely decode? |
| Business record accepted | Validated fields, authoritative event number and server/offline status | Is the transaction accepted, pending or rejected? |
| Document generated | Template/version, language, required data and copy designation | Does the preview or test output contain the approved fields? |
| Print job submitted | Target printer path, request identity, time and immediate interface response | Was a job accepted by the documented interface, or did submission fail? |
| Physical output checked | Paper present, complete content, legibility and operator disposition | Is the document usable, or must the pending print obligation remain open? |
| Reprint or recovery | Original event number, reason, prior job evidence and copy marker | Can another print be issued without creating a duplicate business event? |
Do not collapse these rows into one "success" flag. A server may accept a transaction when the printer is out of paper. A printer service may accept bytes when the roll is fitted incorrectly. A complete paper copy may exist even if a response was lost. The application needs a state model that can represent those combinations.
For unconfirmed transactions, use Offline Barcode Capture and Unconfirmed Transactions to decide whether the business request should be retried. A print retry is a separate decision and should reference the existing business identity.
Compare the integrated and external printer paths
An integrated printer reduces the number of separate devices the operator carries and can give the application one vendor-defined interface. It also binds media capacity, printer service, charging and repair to the same unit. The exact paper width, effective print width, roll diameter, receipt/label capability and status methods must come from the candidate model's document.
For a bounded example, the SUNMI V2s product page lists multiple V2s configurations and gives printer and media details that vary with the named configuration. The distinction matters: a series page with several versions is not proof that every version includes scanning, NFC or label printing. Preserve the selected model identifier and datasheet with the purchase record.
An external printer adds a connection, pairing or network path, its own battery or power supply and another component to carry or mount. It can also allow a different media capacity or placement. Compare the full assembly and application path rather than assuming that external is less reliable or integrated is always simpler.
Use Bluetooth Barcode Scanner Paired but Not Working only for the idea that pairing, connection and application receipt are separate layers; a printer will have its own documented profile, service and status behavior. Do not transfer scanner settings to a printer.
Validate media, recovery and the exact interface
Test with the final template and representative data. Include the longest expected identifiers, multiple languages where required, barcodes or QR codes at the approved size, copy markers and low-paper or paper-out conditions. Confirm the manufacturer's media specification, loading method, cutter or tear method, print-head care and any restrictions for labels versus receipts.
Exercise failure boundaries deliberately. Remove paper before submission, interrupt the documented communication path at a controlled point, restart the application with a pending print obligation and attempt an authorised reprint. Record whether the interface distinguishes accepted, queued, printing, completed and error states; do not invent state detail that the SDK does not expose.
If the project prints a machine-readable code, verify the printed symbol separately from the source scan. Barcode Scanning vs Verification explains why a successful decode is not a standards-based print-quality verification. Decide which output evidence the business needs.
Bring the complete scan-to-paper packet to the purchase discussion
Provide the candidate model and region, application and OS version, business event definition, sample input labels, approved document layouts, media type and dimensions, expected daily/shift pattern, offline rule, status states, reprint permissions, charging arrangement and any external-printer alternative. Identify who owns the business number, document template and duplicate-control rule.
Ask the supplier for the exact model/option datasheet, effective print width, supported media, loading and maintenance instructions, documented status interface, SDK/package version and sample code applicable to that configuration. Ask the application team to show how accepted, pending and rejected business states map to print and reprint actions.
Use Integration & Support for the model-, interface- and version-specific questions, then contact AIDC GO with the workflow, country, quantity, sample document and open printer requirements. A complete decision links capture, business acceptance, print submission, physical output and recovery without treating a sheet of paper as proof that every upstream step succeeded.