One of the common questions asked by our visitors/customers is about how to develop a web based inventory software.
I will try to outline in this article some of the aspects that I would tag as “most important” while developing such an application.
As mentioned in my previous article about web based software, before doing anything else, you need to plan the application.
During the planning process, you want to make sure you know and understand the needs as well as the real life inventory process of your customer (the person or company that will actually take advantage of the web based inventory software). Understanding the real life inventory process is extremely important. My personal opinion is that the only way you can develop a successful, well featured web based inventory software is by understanding the real live inventory environment of the customer.
Make no mistake, there are various ways customers manipulate and need to keep track of their inventory.
Le’t take a look at some examples.
NOTE:
The techniques and the suggested table names and database structures bellow are by no means exhaustive nor do they represent the only way to develop a web based inventory software. I’m just trying to display one of the many ways you can achieve this.
Let’s say you’d like to build a web based inventory software to manage the inventory of a warehouse (or single store).
Although it may have a large number of items (every now and then I may call them products or goods), the warehouse inventory management process is actually not as complex as it may seem to be. In most warehouses the items received from various suppliers are being sold to various customer and that’s about it. From the applications development perspective this can be pretty simple or quite complex if you wish to load the web based inventory software with tons of features 
The very basic things you need to do are:
- Make sure you store the items in a database table with all other data related to them (price, item name, item code, measurement unit, etc.) so that you have it on hand for further use. I’ll call this the inventory_database_table.
- Have a — probably separate — database table where you store the items received. Whenever the warehouse receives an item, a new row will be inserted into this table containing various item related data such as item cost, item supplier, quantity received, user who received the item, etc. Let’s call this the items_database_table.
- You should have a third database table to store sales of the product. This should be quite similar to the table you use to store the items received. Whenever the warehouse is selling an item trough the web based inventory software a new row is inserted into this table containing item sale price, customer related info, quantity sold, user who processed the sale in the inventory software, etc. In this article I’ll be calling this the sales_database_table
In a nutshell, the current inventory is the difference between the cumulated item quantities received and the cumulated item quantities sold. If we have the two pieces of this operation stored in the tables above we can say we’re all set.
Of course, we can load the warehouse inventory management with numerous features such as dynamic inventory charts, sorting abilities, export to various formats but all this is outside the scope of this article.
Now, let’s take a look at what we need to develop a web based inventory software for a store chain. Things will be slightly different in this case. The inventory management process of a store chain is more complex than the warehouse inventory management process.
While in a warehouse items received from suppliers are getting sold to customers, in a chain store items are usually received by a main inventory (somewhat like a warehouse). Than the goods are being transferred from this main inventory to the inventories of the chain stores. Not only that we’re talking about more inventories here but we may also be talking about different prices for the same item in different stores. That’s right, one product may have one price at a store located in the north of the country while that same product may have a different price at one store located in the countries southern part.
You may say: “All right, this is slightly different than the first scenario”. So… how can we deal with it?
Well, long story short… we need to have some additional tables and tune the inventory_database_table a little bit.
We need at least one extra table (let’s call this one the locations_database_table for the purpose of this article) to store the different stores (inventory locations) as well as the main inventory location in it. The main purpose of this new database table is to somehow have a unique ID for each store which ID will be used to filter the data from our inventory_database_table.
Whenever the main inventory location is receiving items, the web based inventory software will insert a new row in the inventory_database_table just as described in the warehouse inventory management example above. We need to store one extra piece of information though and this is the unique ID corresponding to the main inventory location. This main ID can be pulled out from the locations_database_table. In this way we will be able to see which inventory locations actually received goods directly from suppliers.
If items are being transferred from the main (or other) inventory location to another — basically to one of the chain stores — the web based software will record a new row in the inventory_database_table. This newly inserted tow will contain the same information as described above in the warehouse inventory management example with at least one difference. Instead of storing the item supplier we need to store the unique ID corresponding to the source inventory location. By source inventory location I mean the location FROM which the goods are being transferred. By doing this we will be able to differentiate which rows in the inventory_database_table represent the items received directly from suppliers and which ones represent the items transferred from one inventory location/store to another.
Now, in order to be able to track the actual inventory quantities with our inventory software we need to somehow track the sales. The actual inventory quantities are the difference between the cumulated item quantities received and the cumulated item quantities sold, remember?
We do this as described in the warehouse inventory management example except we need to make sure we store — beside the other sale related information — the unique ID of the store. By doing so we’ll be able to filter the sales (and implicitly the current inventory) of each and every location (chain store).
To deal with different prices of the same product, you may want to have an additional table which would store the various prices of one product along with the unique location (store) ID. This way we have a relation between one item and the prices for different locations.
I hope all this makes sense
There is at least one more inventory management scenario that I would like to mention. This one is more complex than the two above. It is the web based restaurant inventory software.
Picture this:
The inventory of a restaurant is being loaded with (or is receiving) salami, pepperoni, mushrooms, olives and so forth and so on but the restaurant is selling… well, they may be selling Pizza.
That’s right! The inventory management process of a restaurant is by far more complex than the one of a warehouse or a chain store.
In my next blog post I will bring some light on how to build a web based restaurant inventory software.
