Ages ago (~15+ years?), I designed a "donation tracking system" for a nonprofit. It allowed donor, type of donation (almost always material goods), weight (how else do you account for "inventory" and "shrinkage" to your donors?), triage information, storage location, date/time, etc.
I did this by affixing barcode labels to everything -- scales, ID badges, shelving, identifying tags (labeled pieces of polycarbonate that could be tossed onto a pile of donated goods as it was tracked through the process), carts/conveyances, etc.
A staff member (volunteer, developmentally disabled occupational therapy, someone doing time for community service, etc. -- folks that you don't place a lot of reliance on) would scan labels and my software would bind the associated data accordingly.
E.g., scan their own badge and, hereafter, any activity associated with THIS barcode scanner would be tagged with their identity (in case they screwed up and needed more training; or, in case you wanted to ask them questions about a particular donation...). Scan the ID card from the donor (frequent/corporate donors only; everyone else, scan "Anonymous" barcode printed on poster by door)
Pile donated items onto a cart. Toss a labeled "tag" on top just to track THIS donation. Scan label on cart (so you can lookup its weight). Scan label on scale so you can figure out the gross weight of the "donation with cart".
Scan an image on a poster that categorizes the types of materials being donated (food, clothing, medical supplies, electronics, pet supplies, school supplies, cash, etc.). Scan label on shelf/bin where the donation is being held for triage/processing. Scan a display terminal to review he data associated with the donation. Scan receipt printer to generate a receipt for the donor. etc.
These activities don't happen in a strict sequential order. E.g., loaded carts may end up queuing at scales until someone has time to weigh them. Carts may queue in hallways waiting for disposition. etc. The schema is designed to allow for individual fields to be added/altered in records in a very tolerant manner so you aren't constrained to do this, then this, then that.
[Remember, quality of "staff" is dubious. And, they aren't employees so you can't/won't fire them -- you'll THANK them for their time...]
I received a letter from the new ED at one such place using this toolchain. She wants to port everything over to smartphones (!). "Wouldn't this be great??"
No, there are many reasons why not:
- how do you keep folks from walking off with the phones (even if they have "no service")?
- software has to be written to run IN the phones (are they android phones? iPhones??)
- wireless infrastructure so the phones can remain in contact with the rest of the system
- scanning a barcode is considerably easier and quicker (laser vibrating mirror) than "posing for a photograph" of a QR code
- the focus shifts from disjoint activities to "tracking A donation with A phone"
I've pushed aside paying customers for some time now (no desire to work on OTHER peoples' projects). But, have a soft spot for non-profits. And, realize that no one is likely to donate the hundreds of hours it would take for such efforts (it took me ~1200 hours to build the first system).
And, of course, this is actually "my" project. <frown>
But, I *really* don't want to take this on. So, would prefer refering her to "someone" who is skilled in "(phone) app design" and let her (and "them") sort out the issue -- fully expecting it to either cost too much, take too long, of not find a qualified developer.
I suspect there are barcode/QRcode apps that can be leveraged. But, no idea how much pain is associated with developing the rest of the mechanisms.
"It (already) works; why dick with it?"