OPEX machines are effectively big scanners, they’re used for mass scanning (generally more than a regular scanner can handle). They scan the pages and create two different kinds of files.
Each Tiff file contains the image for each page, there is no data being picked up from the file however, so if this were imported into QSCAN the index fields e.g Barcode1 would be empty.
There should always be 1 OXI file per batch of Tiff’s. This is effectively a text file containing the data for things such as Barcode1 otherwise known as Meta Data.
OPEX EXPORTS these files to the QSCAN IMPORT Folder where they will be picked up by the QSCAN IMPORT Service. Bear in mind that different projects do not use separate import services (By this I mean the service located in Services.msc). Projects can however have different IMPORT SERVERS (This bit is a little confusing as this doesn’t refer to a server, it’s just the configuration telling the service where to look.) you can view these in the QSCAN Manager.
If you find that one project is working, and another isn’t it’s more likely to be an issue with the files coming from OPEX.
The IMPORT Service will only be able to pick up the batches as long as the Tiffs and OXI’s are valid, if not they will more thank likely sit in the import folder which can cause issues later on if there is a large build up of these dead batches slowing down the service ( The service checks the folders the same way we do, manually opening the file and looking. You wouldn’t want to have to check through 1000’s of folders every time to find a working batch to import would ya)
QSCAN now has the batches, users will now QA these batches using QSCAN Enterprise. Once given the go ahead from the user the batch will be exported using the QSCAN EXPORT Service to either DartKW or DartEDM.
If the user views these files from a different EPR then it’s most likely pulling this info from DartEDM/KW.