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.

Well, this article may be a good starting point. In this article I intend to approach some general aspects of web based software development rather than digging deep into the specific technical aspects.

As with most software (whether it’s web based or standalone) the very first thing you need to do — before starting to actually punch your keyboard to death — is planning. I would suggest to take this very seriously as it is the key of a high quality web based software. Proper planning of a web based software can be achieved only after you have clear, detailed specifications of the project. Planning the unknown wouldn’t be an easy task would it?

During my ten years of web development experience, it turned out that one of the most important aspects of planning the application is to make sure you store all the data needed by your web based application. You know what data you need to store from the specifications. Also, do a good planning of how that data will be stored in the database. Storing data the wrong way may result in a heavy, not very useful application. I will provide some useful tips about how to achieve this in another article sometime.

While planning, try to put yourself in the shoes of the person who will use the web based software you develop. Try to answer questions like:

• What data needs to be visible?
• What data needs to be editable?
• What data can be deleted?
• Is it necessary to know who did what and when in the web based software?
• What level of security is required?

Answering the above questions will give you some good ideas about the database structure you need for the application. It will also provide the outline of the GUI (graphical user interface) needed for the web based software you’re developing.
It is also important to try to anticipate if the web based software you’re planning will be further developed. That should be kept in mind and pinned out over the actual development phase(s).

As a conclusion, planning the web based software you’re developing is key. Its actual development as well as its success depends on that.

Let’s see what are the pros and cons of a web based software over a desktop software (the one you install AND run on your computer only).

One of the major advantages of a web based software is that it can be used from any computer as long as both, the server and the computer on which the software is used, are connected to the same network. The largest network on earth is the internet so, as long as two computers are connected to the internet they are able to communicate to each other.

Another advantage of a web based software is the fact that they usually use the same set of data, most of the time stored in a database.

Let’s look at the following scenario: You have a set of data which you hold in an Excel file. You are working on that data but in the mean time someone else in your company needs to do the same. What you have to do in this case is to somehow update or merge each others excel files. With a web based application the data is being automatically updated in the same place while you and other people are working on it simultaneously. Depending on how the web based software is developed, it can even track who did what and when.
Now, you may ask “what if our data is being accessed and manipulated by people we don’t want to do so”? Well, that’s not so easy actually. Web based software that deal with sensitive data is usually secured behind a password protected area. So, only people who have a username and/or password can access the data. A good example is your online Email account.

Whenever a new version of a web based software is out, the updates have to be made on one computer, the server. Once an update is applied to the server, any other computer running the web based application will benefit from it automatically. That’s another positive aspect of running a web based software.

Whereas in the case of standalone, desktop software, updates have to be applied to each and every computer running the software.

What about disadvantages of using a web based software? Are there any?

You bet One of them actually derives from the main advantage, its accessibility. Given the fact that a web based software is accessible to anyone having access to the same network, it is also accessible to other people than only those who supposed to use it. All right… now you may say “didn’t you mention that it’s behind a password protected area?” That’s exactly what I said! However, the username/password can be hacked and this is one of the web based software disadvantages. However, a well developed web based software is very hard to break in. Also, there are several practices that can be used to prevent some unauthorized users to find your password. I will probably talk about this in another article.