The bug/problem:

The Accruent products with barcode readers unfortunately have a mistake going back years where they read the check digits as data. Based on this, IDs will often be set by user to the values that the Accruent barcode reader software reads. This has several issues:

• By using the error correction as data, a bad read can't be identified
• may be incompatible with hardware readers
• Impossible to fix the bug without also finding a way to fix the bad data entered through the years

Solutions if you have been using the check digits as data:

The not so good:

If you use both MCe and Accruent barcode readers MCe has settings to 'incorrectly' read barcodes to be compatible with Accruent barcode reading software.

Your hardware manufacturer may give the option to 'read incorrectly, by including check digit(s) as data'. Check the documentation that comes with your hardware barcode readers. For example as of 2022 Honeywell Dolphin CT60, documentation you must enable the Send check digit setting within the device's internal scanner profile.  This is configured by navigating to Settings > Honeywell Settings > Scanning > Internal Scanner > Default profile > Symbology Settings > UPC-A and toggling the Send check digit option to enabled

But doing this means you still have lost the safety of the check digit.

The best:

If you used to use Accruent software with barcode readers and now want to use MCe or Hardware, rather than having MCe emulate the bug, you are better to spend a couple hours and fix the data:

If you have switched to MCe or want to use hardware barcode readers, we can help you convert your IDs to properly work with the barcode standards. Typically this will cost about 4 professional support hours, 1 meeting, 2 to do it, 1 for testing and follow-up.

Then you are using error correcting barcodes so your error rate on false reads should go down and you are compatible with hardware.

Won't this cause conflicts between 2 codes if the check digit(s) aren't used as part of the ID?

No! Not if you were consistent. Because it is check digits, given any starting number, the check digit will always be the same. So if the number is 12345679 where the 9 is the check digit, there will never be a 1234567 with a number OTHER than 9. So removing the check digit still should leave you with a unique number. It is possible, and we would verify this as part of the step above, that you entered data by hand, and that could conflict. So the 1st step in conversion is to verify that it doesn't cause any collisions.

Possible future:

Accruent may fix this in the future. If so Accruent will hopefully provide a tool or solution to fix IDs, similar to our solution above.