Barcode scanning in backflushes

[dmccloskey]

Curious if anyone utilizes barcode scanning to do backflushes other than using RF Express. If you are, I'm interested in learning what scanners you use and if there are any things I should know to avoid any potholes that might develop.

 

[kishorchari]

My clients use various customised programs including barcoding for backflush. In Europe Intermec is popular & widely. Even for RF Express I use Loftware label server opposed to Blacbird since loftware offers label reprinting.

I highly recommend RF Express since custom solns are not tried & tested. Lack of source leads to using CIM, custom DB etc which can be eliminated.

We pride ourselves in RF Configuration & Customisation.

 

[JeffCook]

We're using RF Express at most of our plants. But it's too entangled with MFG/Pro (i.e. if the QAD database is down, you barcoders can't do anything).

We've just implemented Error Proof by Freedom Technologies at one plant. It uses it's own SQL database that allows transactions to be stored there (preferably local to the plant). This give you the ability to continue working with the scanners if the ERP system goes down and then it will process the stored transactions against QAD in the order they occured. It uses screen mapping to fill in screens instead of CIM loads. We're hoping to replace Eagle with it over the next few years.

We're also feeding it out shipping transactions (XML format) that happen on a completely different system to load into QAD. It's nice.

 

[dmccloskey]

Bear with me on this as I'm a former user turned administrator (ie: the IT guy left and I got the job). How do you have QAD set up in multiple facilities? Do you have one main database that information is fed to it or multiple databases? I'm asking because we're looking to possibly set QAD up in another facility. We use the GUI client in our main facility, the character client in an outlying facility, but this new facility is about 60 miles away.

 

[kishorchari]

Database distribution entirely depends on ones req

a) One central DB where other Plant dials in
b) Two DB's at Central where other Plant dials in
c) Have DB at each Plant

If consolidated set of a/cs is required then Consolidation can be done.

I totally disagree with Jeff, I dont understand why MFG/PRO be "Down" so much that you need a separate DB to manage it.

 

[JeffCook]

dmccloskey: Kishorchari is correct, there are serveral ways to configure things to support your plants. We were toying with an idea that would have the individual plants hosting their own QAD db's with replication back to a central hot site. The economy slowdown has put that on hold for now.

kishorchari:I didn't say that the ERP system should be down that often. It is called Disaster Recovery. We've had problems where our WAN provider (AT&T, of all companies) had 20-30 minute outages at 12:30 AM and I get called because they think the databse is down when it's not. The people using the scanners would have been able to keep working while the WAN was down if they had Error Proof.

For the 17 years I've been supporting QAD installations I have never really liked Eagle as it's been a pain (in my opinion) to support.

I take it that you are a reseller of QAD and Eagle. That's different than being an end user/internal MIS support. I don't like single points of failure and avoid them if I can. That's why we have seperate DB's for each of our plants. Things happen in the real world that can cause a db to go down. Maybe you could add Error Proof to your offerings. It would give your clients more options.