Cash Register... Might find this interesting

[TheBigBasicQ]

Why not just make a copy of the file and move the copy in the program's temp directory so that no modifications can be done to the file. Print it and then delete it. That way it will become less visible to the user and the program wont keep printing the same file over and over.

[Moneo]

Check out http://pages.prodigy.net/daleharris/pos.htm . This is a complete cash register program used in dozens of countries, written in Quickbasic 7.1.

Took a fast look at the site --- very impressive. I'm particularly happy that it was done in QuickBasic. I've done lots of work in POS since 1969, and recently I helped a friend instal a POS system for a drugstore. He insisted that it had to be done in MS Access. What a horrible language, you spend 90% of the time doing the "forms".

BTW, do you know how this system handles returns? One of the problems with returns is that if the goods are damaged in any way, you can't put them back into inventory.

Another problem I saw was an eager clerk selling merchandise that had not been "received" into the inventory yet, because it just arrived at the store and the clerk saw it.

A big question is does this system allow the inventory "on-hand-balance" for an item to go negative? My experience is that you should never allow this.

Also BTW, I had to write a quick and dirty print program in QuickBasic to print the sales-tickets, because my friend couldn't find the Windows driver for the printer.
*****

[TheBigBasicQ]

Moneo, if the protocols are good in the store then the clerk should've first entered the items into the inventory, how much would it have taken him?

[Moneo]

You're right BigBasic, but the smaller the store, the less discipline exists. Here's the scenario:
1) The clerk has a customer in front of the counter who asks for a particular item.
2) The clerk checks the physical stock and there isn't any.
3) He remembers that a shipment just arrived, so he checks the boxes and finds the item that the customer wants.
4) Does he take the extra time to record a receipt of this item? No, he just sells it.
5) Most systems will let him sell it, and as a result leave a negative value in the inventory.
6) My recomendation is to not let him sell it because the inventory is at zero, forcing him to perform the inventory receipt first.

This whole issue is very tricky. It's possible that there's nothing on the shelf but the perpetual inventory in the system says that there is one available, in which case the above scenario doesn't work right.

It all comes down to discipline:
* You should never sell something out of the goods received boxes.

* Every night you should perform a "Zero Spot Inventory", which means scan the shelves for empty slots; i.e., don't have any for these items. All these items should be "on-order". If any are not, then the systems screwed up and you better order them now. You should also check the Quantity-On-Hand on the system. If it's not zero than you should enter an adjustment to set it to zero.

* Every night you should generate a report of all active items where the Quantity-On-Hand is zero (or less if your system allows it). Then you match these to the shelves and generate purchase orders or enter adjustments to the inventory accordingly.

It's like checking the oil level in your car every time you get gas. You don't want to wait for the red "check engine" light to go on.
Discipline, discipline, discipline.
*****

[Jonathan Simpson]

Well... lets see. At present the system does not stop you from selling something that it claims to be out of (IE: 0 in stock), but neither will the count go negative. The "negative count" as an option is actually something that is going to be added as a feature, for places that are using POS to print an invoice in advance of actually ordering the product.

[Moneo]

Well... lets see. At present the system does not stop you from selling something that it claims to be out of (IE: 0 in stock), but neither will the count go negative. The "negative count" as an option is actually something that is going to be added as a feature, for places that are using POS to print an invoice in advance of actually ordering the product.

Jonathan, allowing the "negative count" as an option is extremely dangerous. It opens up a whole gammit of anomalies for the inventory.

Let me make my best points:
* Can you physically and logically have MINUS ONE one of something in your inventory?
* Can I go to the shelf or a rack in the warehouse and actually see MINUS ONE items?
* When I am costing the inventory; that is, costing my assets for accounting purposes, will I reduce my inventory value by every item that has a negative On-Hand-Balance?

Of course not. Then why do I want to create this IMPOSSIBLE situation on the perpetual inventory file on my system?

I have heard of that approach of printing the invoice for negative inventory items in order to force the purchase order. That's nonsense! What you need is a BACKORDER sub-system instead of using your inventory On-Hand-Balance as a "scratch-pad" to record abnormal situations.

I have been working with inventory systems and POS systems for more than 40 years. I have had this argument over and over again with Industrial Engineers, who favor the negative inventory approach. In the end, I have always convinced them, and the inventory systems worked fine.
*****

[TheBigBasicQ]

Moneo, you are correct to some extent but my opinion on it differs. A negative quantity should be an indicator that the item must be physically present but wasnt entered into the inventory before being sold.

But I agree with the fact that the system shouldnt allow the person to sell something that isnt present thus forcing him to record it in the system.

[Agamemnus]

Hehe, ya goons!

A negative stock of items is perfectly acceptable if the items aren't actually items but orders!

* When I am costing the inventory; that is, costing my assets for accounting purposes, will I reduce my inventory value by every item that has a negative On-Hand-Balance?

Yes! Why not? :|
Or, one can put the negative inventory into a "costs payable" section.

[Moneo]

Aga, I generally agree with your good ideas. However, on this issue I have to disagree with you. I have a feeling that you're speaking "off the top of your head" and have never actually been involved with the day by day workings of an inventory system in production.
*****

[Jonathan Simpson]

Perhaps I should explain a bit better... In this case, the stock count will NEVER be a positive number. The first request for this feature actually came from me, because my wife sells avon. Each "campaign" she recieves a new catalog. This comes in on Tuesday. Thursday of the following week, she sends the orders of all her customers in, and then the Tuesday after the stuff comes in. At that point it is delivered, and the unpurchased inventory for each item is 0. She is literally using this program for the first time this campaign, so we'll see how things work out.

Anyway, here is the situation as far as our usage would go. The inventory normally would be 0, because we don't keep anything on hand (some unusual exceptions). Thus, the normal condition is that we have a stock level of 0, and a model level (reorder level) of 0, thus if the amount on hand is less than 0 we need to order enough to reach 0. Some supply type stuff (bags and such) should be kept at higher normal levels. Thus, a negative count makes sense, since we should not have anything in stock to begin with...

Now, a little quick explanation of how POS handles things... POS allows partial stock counts, like for example . 85 . This is designed for selling things by weight, length, etc. If you had .85 in stock, and you sold 1.00, POS would set your count to 0.

Well, thats all for now.

Jonathan Simpson