[Feature Request]: Change how Consumable are tracked/act to be more like a general ledger or create a new category (resources, commodity stock) of items to represent how consumables are tracked.

[jrainone]

Is your feature request related to a problem? Please describe.

Currently the Consumable items are treated/tracked as a grand total of items when they should be tracked similar to how an accounting ledger tracks cash and have similar functionality.

Describe the solution you'd like

• we should have a total on hand (not a grand total) as a starting stock. (could be Zero, could be thousand, its just a row on the ledger). Ideally we can track other stuff like location, cost, where we purchased it from or who it was given out to as well as time of event.
  • The total on hand now reflects the new total. The total is NEVER directly changed but goes off what the ledger shows.
• we want to deduct from the total, we would have the function to do the following
  • either an item was used and checked out to a person
  • checked out to a location (as a deployment)
  • device like an asset
  • STOLEN/MISSING - checked out as shrink, missing, stolen, damaged. this would happen when running a physical inventory -We want to ADD to the total
  • We add to inventory, either a purchase, gift, found after missing
  • list total added, track cost, location manufacture supplier ect.
  • list total added (NEVER CHANGE THE TOTAL AMOUNT DIRECTLY) if (5) are in stock and you order (2) then you would add to the inventory (2) and the total gets updated.

Describe alternatives you've considered

There are a few ways to implement this but the best would be

• a single table (ledger) that just tracks all consumables changes when each instance of a consumable is changed
  • columns that show the quantity it was changed by, who made the change, where the item is going (if deducted) or where it came from (if ordered and found), time date, ect.

The total field can be tracked several different ways,

• either snipe goes through ALL rows, adds or subtracts for the specific item being looked for and gives a total. This might not be the best since this could be a lot of work depending on how big the table gets and could be inaccurate if data is deleted from the table.
• After each journal entry the new total is calculated and gets its own column. SnipeIT then just looks up the last entry in the table for that item to get the total. This will preserve the total even if somthing happens to rows in a table.

Additional context

No response

[snipe]

Yes, we're already working through this on our end.

[jrainone]

wow this is really great to hear and I appreciate the fast response, if there is a way to help implement let me know I have a background in Accounting and Computer Science.

[snipe]

@jrainone That's good to know :)

We're looking at sort of dovetailing this into an "order" system (possibly purchase order system down the line), since the "replenish" option will always have some sort of order attached to it. Even if there isn't a formal order number (for example, you ran out of printer ink and went to the local office supply store instead of running it through a normal delivery cycle). We're hammering out how we handle those unofficial-but-definitely-happen types of things now. Lots of people have asked for this (or something very much like it before), so we have a lot of user feedback to work with, but any additional comments or context is always welcome.

[TShiremanLCOG]

I'm sure it's already considered but linking POs to specific items would be awesome. So one copy of the PO is reflected in the Files tab of all associated items. These 10 laptops were purchased with this PO and five of the laptops were for the following people. Something super helpful for us would be custom fields for the POs to allow for accounting codes or GL codes to be used. Browsing by PO or GL number the same way that you can everything else in SnipeIT would be great.

[snipe]

@TShiremanLCOG - thanks for the feedback! I think POs won't be a thing we tackle for the first version of this, but it's always helpful to know people's workflows. We obviously try hard to accommodate everyone, but we can't build what we don't know about :) Once we're done fleshing out the orders side of things, the next step from there would be to add in PO capabilities.