It seems like "reachtech" is some kind of a special case (which I am not knowledgeable about).
In general, I want to agree with @SGaist that a barcode reader normally "presents itself" (via its driver or a generic driver) to the system as just another connected keyboard that types keyboard keys as input.
As @SGaist said, if the keyboard focus is set onto some editable control/widget, then when a barcode is scanned it should "just work" and you would see characters from the barcode typed into the editable control.
I will add one other slightly different approach that I have taken in a particular QML-based application. In my particular case, there were no editable on-screen widgets onto which to place keyboard focus. However, the requirement still existed that the application "capture" any scanned barcodes and display them.
In that application, I used QObject::installEventFilter to install an event filter on the root window of the QML app. The app only used a barcode scanner (never a QWERTY keyboard), so it was simple to just filter every QKeyEvent (QEvent::KeyPress) and assume it was input from the barcode scanner.
To better explain what I mean by "root window", the initialization looked like this:
QQmlApplicationEngine engine;
// ... other code to initialize the engine with main.qml and so forth
const QList<QObject*> objs = engine.rootObjects();
MY_ASSERT( objs.size() == 1, "if the app starts creating more than one root window, "
"please reevaluate the logic of our global event filter" );
objs[ 0 ]->installEventFilter( POINTER_TO_CUSTOM_QOBJECT_FILTER_HERE );
For QML applications that have zero editable controls, this was a successful alternative in my experience.