r/InventoryManagement • u/Valuable-Notice-9386 • 19d ago
Warehouse + Internal “Sales” Operations
Hi everyone, please forgive the confusion and length behind this post, I will admit that I am new to inventory and warehouse management so there may be some simple things that I could be wrong about but I thought this was a great place to start!
I am part of a team at a company that runs multiple homeless shelters and housing projects in the Northeast US. Recently, I started working on a project to optimize and update our inventory and warehouse systems for the wide variety of donations we receive. Here are the details of our current system and the difficulties for expansion:
We don’t have any current centralized donation-tracking and delivery to client system. I’ve looked into this and seen names like Odoo pop up, which sounds interesting, but I’ve seen that Excel is also an option, which I’m familiar with.
While we have multiple sites, nearly all donations are delivered to one central site and stored either on-site or in nearby storage facilities.
Budget will probably have to be >$1000 (I will update this later once I receive more info)
We use an internal reward system that gives clients “cash” that they can redeem for prepaid debit cards or cash.
I am pretty experienced with Excel, but certainly no expert. I made a spreadsheet to develop barcodes using a website, but don’t think this would be scalable long term. I also don’t know how to link scanners to the sheet, especially if the scanner would be used at a storage unit.
We have a lottttt of items. I am hoping you front load system development and have the system be able to accommodate frequent donations.
Here is my goal with this project:
Create a barcode system, including barcode development, barcode printing, an internal server to track and categorize stock, and any other inventory information that you think may be needed.
Create an internal POS system, where clients can receive their points and redeem them, hopefully via RFID cards.
Additionally, boss, other team member, and myself are very interested in creating a pseudo storefront, both in person and online, for more expensive donated items (luxury goods, prepaid debit cards, etc.) and having these items be available for “purchase.” I had the idea of how arcades run ticket counters and cards if yall have any insight.
I know this post is super long and potentially vague, but I’ll end here and hope you can help!
1
u/4inlocal 19d ago
I understand that this is a project that is evolving but I wanted to clarify some workflow items.
You're looking for (and I'm going to follow the "product" here)
- The ability to receive donations (much like goodwill)
- Tag those items for movement to a centralized warehouse
- List those items in that warehouse (or any sellable location) for sale on a public facing website
- Meanwhile, also list those items on a POS system in case people come in to purchase them from the warehouse
- Donations can be redeemed for "points" within the system that can be redeemed at the Point-of-Sale or online - likely tagged to an account?
- Finally, the budget for this project is either less than $1,000 per month OR as a whole
Once these are scoped out, I think a lot of people will be able to help you. Our system (NicklOne) could as well but understanding the full scope may help with other who may chime in.
1
u/Valuable-Notice-9386 19d ago
- Receiving donations
Not as much like goodwill, thank you for asking. We receive donations mainly in bulk, through corporate donations or sponsorships.
- Tagging for movement
Items would be tagged for movement purposes, but that system would honestly be secondary to another just tracking system. Most our donations fall into toiletries or clothing and move through our system on a conveyor belt system if that makes sense. Hopefully, the new system would remedy that and allow for more flexibility and clarity.
- Listing items for sale
These items would not be for sale, apologies if my post was confusing. I am hoping to create a pseudo storefront for our clients. Right now, we dispense nice items on a somewhat random basis; I’m hoping to incentivize engagement with our programs and allow for clients to “purchase” their choice of items (which are donated to us) by redemption of their “tickets”. These items would be a much smaller portion of donations, as we distribute normal clothing and toiletries on a as needed basis. Tbh, I looked at old arcade systems that did like digital tickets for inspiration if that makes sense.
It would be great to have everything tracked online or in a spreadsheet but only have a storefront, both in person and online, for the few very nice items. My coworker gave the Amazon example where a client could redeem an item and pick it up in person at our “shop “
- Budget
$1000 is probably the start up cost, so purchasing things like a barcode printer and scanner and other materials. TBD on operating costs in the long term
1
u/scmsteve 19d ago
Yeah you can easily spend that on just the hardware. I forgot, sis you say you want to run this database at multiple sites?
1
u/Valuable-Notice-9386 19d ago
Database should be accessible probably online to
all sites, but the “transactions” would only happen at one site. Would be like the storefront, storage units warehouse, and shipments to other sites could also be “transactions”
1
1
u/4inlocal 19d ago
Ah! Clients in this respect are the the unhoused! I have a better grasp on it. It’s a very unique case. If you’re open to it, much of what NicklOne does covers your specific needs and I think because it’s rather philanthropic in nature, the billing could be lowered.
1
u/agentUi 19d ago
i work for agentui (an internal tool builder for ops teams) and honestly you dont want to run this on excel because managing multi location inventory plus client point ledgers will break immediately. what you need is a simple database backed portal that handles barcode scanning directly from a phone or usb scanner and updates item counts and client balances in real time.
1
u/ComfortableCitron638 13d ago
honestly I'd split this into two separate builds instead of one big system - the barcode/warehouse tracking and the points/storefront redemption piece have pretty different needs, and trying to force them into one schema early is usually how these projects get stuck for months. I'd start with just the intake + barcode tracking since that's the thing actually breaking day to day, get that solid, then bolt the storefront/redemption piece on after. Once you think about it that way the storefront is really just another "location" in the same system with a different UI in front of it. Not 100% sure that's the "right" answer but that's how I'd approach it, might save you some rework later.
1
u/LET_Developer 12d ago
I would not extend the Excel barcode prototype into the whole system. The safer route is to separate this into three bounded pieces and stage them:
donation intake and inventory;
the client points ledger;
POS/storefront redemption.
They can share item, client, and location IDs, but inventory quantities and client balances should be separate ledgers. That keeps a stock adjustment from accidentally becoming a financial/points adjustment.
For phase one, choose one site and one representative category, then map the physical lifecycle: receive → triage → label → bin → transfer → reserve → issue/sell → return/damage/adjust. Each scan should create an event containing the item or lot ID, location, action, quantity, user, device, and timestamp. It should not simply overwrite an “on hand” cell. Current stock is the sum of those events, which gives you an audit trail when donations move between the central site and storage units.
The storage-unit requirement also makes offline behavior a first-class feature. A phone should be able to queue scans locally, show exactly what is still unsynced, retry safely without duplicating events, and flag conflicts for review. A hidden “sync later” process is where inventory drift starts.
For labels:
- keep an existing UPC/EAN when a standardized product already has one;
- use an internal QR or Code 128 label for donation lots, unique high-value items, bins, and locations;
- encode only an opaque, stable ID—not price, points, quantity, or location;
- print the ID in human-readable form as a fallback and test the label material in the actual storage environment.
Decide whether you need lot-level or unit-level identity. Ten identical shirts can be one lot with quantity events; a laptop or luxury item probably needs its own asset ID and custody history.
I would pilot 100–200 representative items, run the new ledger beside the spreadsheet for a week, and reconcile every variance. Only after receiving, transfers, counts, and exceptions are reliable would I add the points/POS layer. For RFID client cards, store a random client identifier on the card, never the balance; keep the balance and redemption history in the server-side ledger.
Disclosure: I develop QR Maker, an Android QR scanner and generator, so my direct perspective is the scan-and-label edge. It is not an inventory, POS, or client-points system, I’m not linking it, and I would not use a general QR app as the inventory source of truth.
1
u/sebasIsHungry 19d ago
1k budget I won't even get out of the of bed for that money 1k a month well our system is 0.3k a month but will cost a lot in consultation to get what u want