Advice for Creating an Inventory Control Program
Background: I work for a warehouse that interacts with a retail/salvage store. I am a nursing major, but am switching to either CS or CE and will graduate in around 3 years. I have been learning C++ for about 8 months, and have been studying and learning from LearnCPP.com & C++ Primer. I took a short break during those 8 months, and was introduced to HTML and JAVA.
I have an opportunity to create an inventory program for the company I work for that they could actually use, although it wasn't requested of me. I see this as a great opportunity to add something noteworthy to my portfolio, and genuinely would like to create something helpful for the business.
I went through most of LearnCPP.com, and I am having some difficulty starting the program. I have also looked through some open source inventory programs, but I am having a great deal of difficulty applying them to the needs of the program. I am seeking additional resources, advice, and links to topics that would help me create this program. I hope this post in no way comes off as a lack of diligence. I am honestly looking for direction and advice.
Needs of the program:
1) To be able to store information such as distributors/suppliers, locations, expiration dates, cost, retail value, and so on.
2) Interact with a scanner to create/read a barcode that would contain this information. Interact with the printer to print stickers with the barcodes for certain boxes, and be able to "scan out" the item from active inventory, and then be placed into a inventory history database of some type. This part of the program seems particularly difficult with the understanding I have right now.
3) Have a user interface that the retail store would work with the be able to create "Pick lists" or "lists", which would would automatically deduce inventory, create a list history, and create a printable list which would contain the location, the item description, the date the list as made, etc.
Any resources, help, or advice would be greatly appreciated. There is more to the program than just these 3 needs... but I see these 3 postulates specifically hard for me to visualize in C++ code. We actually use a list right now that is purely Excel... and it has many drawbacks. I am amazed that Excel can do what it can, but I really see this as an opportunity to optimize the list with a new, updated program.
I have an opportunity to create an inventory program for the company I work for that they could actually use, although it wasn't requested of me. I see this as a great opportunity to add something noteworthy to my portfolio, and genuinely would like to create something helpful for the business.
I went through most of LearnCPP.com, and I am having some difficulty starting the program. I have also looked through some open source inventory programs, but I am having a great deal of difficulty applying them to the needs of the program. I am seeking additional resources, advice, and links to topics that would help me create this program. I hope this post in no way comes off as a lack of diligence. I am honestly looking for direction and advice.
Needs of the program:
1) To be able to store information such as distributors/suppliers, locations, expiration dates, cost, retail value, and so on.
2) Interact with a scanner to create/read a barcode that would contain this information. Interact with the printer to print stickers with the barcodes for certain boxes, and be able to "scan out" the item from active inventory, and then be placed into a inventory history database of some type. This part of the program seems particularly difficult with the understanding I have right now.
3) Have a user interface that the retail store would work with the be able to create "Pick lists" or "lists", which would would automatically deduce inventory, create a list history, and create a printable list which would contain the location, the item description, the date the list as made, etc.
Any resources, help, or advice would be greatly appreciated. There is more to the program than just these 3 needs... but I see these 3 postulates specifically hard for me to visualize in C++ code. We actually use a list right now that is purely Excel... and it has many drawbacks. I am amazed that Excel can do what it can, but I really see this as an opportunity to optimize the list with a new, updated program.
You're describing a system rather than just a program. In much the same way as you've described the things peripheral hardware that it must interface to, you should do that with all aspects of the system. For example,
1. Who will use the Pick Lists? How will they get them? What will they do with them?
2. Who orders stock? How will they use the information your system has?
3. How is the data stored? Does it need to interact with any other existing systems (like a stock control system)?
Once you've decided who will use the system and how, and what peripherals the system will use (printers, and so on), you can set out designing how your system will work. You'll eventually come up with a number of programs that possibly run on different computers in different places. Then you can think how these programs will interact. And only then can you decide on language and physical things like that.
You don't build the whole system in one go. You build a small part that will do one useful business function. You review how that went, and possibly revise your design before going on to the next step, or deciding to stop.
1. Who will use the Pick Lists? How will they get them? What will they do with them?
2. Who orders stock? How will they use the information your system has?
3. How is the data stored? Does it need to interact with any other existing systems (like a stock control system)?
Once you've decided who will use the system and how, and what peripherals the system will use (printers, and so on), you can set out designing how your system will work. You'll eventually come up with a number of programs that possibly run on different computers in different places. Then you can think how these programs will interact. And only then can you decide on language and physical things like that.
You don't build the whole system in one go. You build a small part that will do one useful business function. You review how that went, and possibly revise your design before going on to the next step, or deciding to stop.
Topic archived. No new replies allowed.