As i understood, some things depend on the location type code (like if it can hold actual items, if it can be parent or child of other location etc) and other things depend on extra options governed by activities. NB: it seems to be logical to move ALL this logic to be activity based probably?
There are more Location Type Codes than described in the documentation, what are they for?
CONSUMER
DISPOSAL
What is actually the difference between WARD and DISPENSARY?
What is the difference between BIN_LOCATION and INTERNAL?
Now for activities
dynamic creation - i suppose this is what enables the buttons like “add destination” on the Outbound shipment form etc?
allow over-pick
And while exploring all this stuff i managed to damage the data in some way - i would consider this as a bug:
i have noticed that while editing default Zone (Location type which comes “out of the box”) it`s Location type code in the upper box was not set to ZONE, but was set to “select an option”. After clicking Save Location Type code was actually cleared and what is more interesting i can not get it back since there is no ZONE Location Type Code in the list.
A this point it is not possible to add or see zones for depots, in Bin locations tab zones created earlier are displayed for the bins, but Zone locations tab is empty etc.
I’m not sure about all of these but will answer what I know:
I have never used any other location type code, but my assumption is that these additional codes have the exact same functionality and activity codes as WARD. Likely they were added to be descriptive of what the location is but they do not work differently from other destination locations
Similar to above, WARD and DISPENSARY have no functional difference. Two location types exist if the user wanted to easily distinguish their wards from their dispensaries in a list or in custom reporting/documents. Personally, I use WARD for every single destination location regardless of what it actually is. However, I did work on an implementation where they needed to generate custom shipping documentation depending on the type of location they were sending to, and then I used the location types as a reference for the custom documentation
INTERNAL locations are bin locations that have special behaviors built into the code, not dictated by supported activities. Receiving bins, Hold bins, and Cross-docking (which does not actually have any functionality but was added with the intention of building that eventually) are INTERNAL. If you want to create a custom location/location type, I would strongly suggest using BIN_LOCATION as INTERNAL is not designed to be used for custom location types (although the system probably allows it)
Activities:
Dynamic creation - you are exactly right. Put it on a location type to allow the user to create a new location of that type within the outbound movement workflow. Shouldn’t be added directly to location supported activities as it wont do anything - only on the location type
allow-over-pick - I have never seen this one before, and am not sure what it would do as the system already allows manual over-pick. Maybe it’s available in some versions not others
Probably you could give some advise based on your experience: what we do is servicing different hardware and for that matter we use field technicians.
We need to keep track of the parts:
1 which have been diven to them from depot for particular repair under some ticket (with the reference to this ticket)
2 which have been given them for their mobile in-car depot
3 which of the above parts they have eventually used for the customer repairs
3.1 parts used for the repairs need to be tracked and somehow “confirmed/completed” after some external administrative activities have been performed.
3.2 repairs may result in customer`s defective part being returned - it should be tracked and in some cases returned to the external party (producer).
Technician should be able to request the part from depot (but not “take” it by himself) and confirm the reception once the part has been provided.
He should be able to initiate return of the unused part to the depot.
PS: and what is important - somehow we must track the state of the part (it could be dead on arrival, damaged etc so it will requre further processing). I have not found any “status” of the stock items yet, probably i must go deeper into openboxes documentation.
I would be very grateful if you could share some thoughts on to what extent this is achievable within openboxes?
Yes, this is most certainly a bug. We’ll create a ticket for it. If you haven’t run that reset, I can provide the SQL statement to fix the zone location type.
NOTE: Since you’re just getting started, let me know if you would like to start with the most recent version (v0.9.3) of OpenBoxes instead of v0.8.x.
There are more Location Type Codes than described in the documentation, what are they for?
CONSUMER
DISPOSAL
We wanted the user to be able to define consumption endpoints that provided more nuance than just “location where stock was consumed”. The idea was that we could use the different consumer endpoints to understand how stock is being consumed by the supply chain system (wasted, consumed, damaged, shrinkaged). We have the same concept at the Transaction Type level (i.e. each transaction to an endpoint can include this type of classification) so you can decide which method makes more sense to track that metadata.
What is actually the difference between WARD and DISPENSARY?
This is another example of the “nuanced” location type. A WARD represents an in-patient hospital ward where stock would likely be stored in a closet or cabinet and consumed via an administration event. The DISPENSARY might represent an out-patient pharmacy within a hospital or independent of the hospital system. Sending stock to either of these locations has the same effect on the warehouse that is fulfilling the request (i.e. stock is effectively consumed), but the location type provides metadata about what is consuming the stock which might be used to understand the events that might occur at those locations (dispensed 30 pills to patient, administered one dose every day for a week). Whether that distinction is important to you depends on your use cases.
The following FHIR documentation provide a bit more context for the events that might occur within the consumer location.
There’s a good chance you don’t need to make a distinction between your consumer location types, in which case CONSUMER probably makes the most sense. There’s also a good chance that we don’t have a location type code that best represents your particular use case (for example we might not include the concept of a STORE where POS transactions occur). So just let us know and we can add them.
Aside: One underlying assumption that should be discussed is that OpenBoxes is not designed to track the transactions that occur at a consumer endpoint (i.e. point of sale / point of service). Those use cases would need to be supported by other systems like a POS terminal and potentially communicated back to OpenBoxes or a separate reporting system like DHIS2.
Having the data from both systems (WMS and POS) would allow us to reconcile the consumed signal from the warehouse (sum of all outbound transfers to consumer) with the consumed signal from the consumer (sum of all dispensing/shrinkage transactions to actual consumer i.e. patients) so that we could calculate and understand the efficiency of the entire supply chain. At the moment, a warehouse that sends 1000 EA of Ibuprofen tablets to a consumer endpoint ASSUMES that all stock is being dispensed to patients efficiently. However, what is happening inside the pharmacy might tell us a completely different story (820 EA dispensed, 80 damaged/disposed, 100 EA expired).
Reconciling these stories is an important part of effective supply chain analysis. And eventually I would like to bridge that gap by integrating systems (OpenBoxes, OpenMRS, dispensing systems, POS) together using OpenHIE and creating a reporting layer using DHIS2 to communicate and marry the different signals being emitted by each system. The same type of integration should be possible with non-healthcare use cases like retail/sales.
What is the difference between BIN_LOCATION and INTERNAL?
BIN_LOCATION was added first and represents internal locations that serve as bin locations within a warehouse racking system i.e. pickface, reserve racking, etc. INTERNAL was added to represent internal locations where stock might be stored temporarily before being putaway or shipped i.e. dock doors, staging, receiving, hold locations for returns, etc.
They are essentially the same with some nuance. I realized after adding BIN_LOCATION that it would have been better to create a single location type code (i.e. INTERNAL) to represent all internal locations of a warehouse and to allow the supported activities to distinguish between them i.e. a picking location would use PICK_STOCK/PUTAWAY_STOCK, a receiving location would use RECEIVE_STOCK, hold locations whether bin locations or staging areas for returns would use HOLD_STOCK.
For the most part that is how the system should work, and is working. But there might be places where that refactoring hasn’t occurred we’re still pulling just locations with location_type_code = BIN_LOCATION, instead of location_type_code IN (BIN_LOCATION, INTERNAL).
VIRTUAL is used as a way to record transactions to “virtual” states that might not have a physical location (e.g. Borrowed, In Repair, Deployed, Scrapped, Flushed, Destroyed, Incinerated, Stolen).
Let’s take Incinerated as an example. The concept of “stock has been incinerated” could be implemented in multiple ways within OpenBoxes:
Transfer to Physical Location destination (Incinerator) on the premises
Transfer to Virtual Location destination as a state (Incinerated)
Transfer to Blackhole destination with Transaction Type = Incinerated
Consumption transaction (no destination) with Transaction Type = Incinerated
And you could even add internal locations to store stock ahead of it being incinerated.
Internal Location (Ready to Incinerate)
So this is one of those cases where you would need to decide which approach makes most sense for your implementation.
There are a number of ways to do this within OpenBoxes, but it’s not going to be streamlined to your wofklows. In fact, this is going to require heavy data entry. Whether OpenBoxes is suitable, depends on an analysis on the use case breakdown between consumption of parts/goods and tracking of assets. If you’re more interested in the deployment/usage of parts and tools, then I might recommend an asset tracking systems like snipeitapp.com (asset tracking of IT equipment devices) or even a more general ERP with asset tracking feature or module like Odoo and ERPNext. Or the system you have in your saved links from the screenshot (inventree.org).
Technician should be able to request the part from depot (but not “take” it by himself) and confirm the reception once the part has been provided. He should be able to initiate return of the unused part to the depot.
I could also see a case where you could you use the OpenBoxes API, but build a separate UI to handle the workflows that you’re describing. This would allow you to build streamlined workflows for each of the use cases you’re describing. If you don’t have any developers but you do have a budget for development, we could work with you on a project to build an application to handle these workflows.
I have performed the reset already, but probably posting the SQL statement to recover from such an issue would be nice if anyone else encounters this issue.
i`m on release/0.9.2 currently, is this not the latest version?
Frankly speaking i have not looked into Transaction types yet and quck search in the Administration guide gave me zero results
Sure, but what is the actual difference between being transferred to the VIRTUAL location and to any other “consuming” location be it CUSTOMER, DISPOSAL, WARD or DISPENSARY? I mean, besides that you could later get some analytics based on the location type is there any technical difference between those options baked into the program logic?
Sorry for asking, but i would like to understand their intended role/usage to make the right choice - probably additional functionality is planned to be implemented at a later point.
At this point it looks like combination of only CUSTOMER for real consumption and VIRTUAL for anything else would make most sense for us.
so for now it is better to use BIN_LOCATION for any custom bin types, got it.
Inventree - Imported data for one of our depots, our part catalogue. They have very simple add/remove stock item process, min/max/reorder levels and related replenishment reporting/process is very basic (we have print service projects where consumption statistics, planning are critical because of greater parts/consumables usage rates than general server hardware support).
Nice features are serialization and stock item statuses (which impact “availability” of the said item), possibility to nest locations indefenitely with the ability to customize which of them may hold items and which are purely “structural”, same goes for part categories - you may customize which are just for grouping and which are assignable to the parts. They have extensive API and use python which is far more usual than grails nowadays
General simplicity is a downside aswell - outside of purchasing and sales process there is amost no concept of the “document” as envelope for the item movements. Transfers between depots are one-stage process, there is no picking etc. Has emphasis on the build/manufacturing process.
Odoo and Dolibarr - well… i have briefly tested both of them. They are big, but doing a lot more than warehouse management they do it less deep in most aspects and/or require significat amount of side activities like actvating “shipments” activates “sales orders” etc and all it grows like a snowball. And they still lack most specifics openboxes/inventree have.
I have even touched Tryton but got frustrated by its UI/UX and fled in terror.
We use SAP R/3 as our main system so “we have ERP system at home, son”
SnipeIt - that was the second one i have tried, as expected and declared by creators it is mostly cmdb/it support tool, it has almost nothing for proper warehouse management. Is seems to be more or less the same as GLPI (which one of our regional departments was using for their local activities)
I would like to avoid building new frontend (which could be possible both with openboxes and inventree). We have no such luxury unfortunately - so i have to try to squeeze our processes into the frames provided by the existing apps. At least for now.
