CMS Inventory Module
In addition to the Weight field, there should also be fields for Cubes and Unit of Measure (U.O.M). Weight can also be two fields, Gross Weight and Net Weight. A field for UPC would be useful as well. These fields are helpful to companies who ship products using outside carriers.
-
David W Parvin commented
Everything I said here is the same in both systems. Like I said thou, Pro does have functionality for weight, I am just not sure if it has all the functionality for that you are looking for. Currently Denali does not have functionality for weight.
I am not sure why your windows 7 would not see the other 4 gigs of ram on your machines. That is not an area I know well. I know that Denali will run fine on 32 bit operating systems.
-
Robert Curioso commented
You mentioned Denali, that's a whole different game. I have several work stations and they are all loaded with 32 bit software. They all have 64 bit capability, but CMS will not work on 64 bit. My systems have eight gigabit of memory, but windows seven will only allow me to use four because that is the maximum for 32 bit. Switching to Denali would mean reloading all of my systems, including the server in order to take advantage of 64 bit technology. Denali also comes at a higher a price and the payroll module doesn't work with it yet. Besides, I am not familiar with Denali and don't know if the added features are worth it.
I'll be posting a new inventory situation for you to evaluate soon.
-
Robert Curioso commented
If two stock numbers for the same item are used for full cases and units, there would also be two unit on hands. The only feasible way to link these would be to increase the units by the amount that is in a full case and decrease the full case by one for every full case amount transferred. At the same time all the cost fields could be adjusted by dividing them by the case quantity. This should include: alternate 1 & 2, standard and last cost. All this could be done when orders are being posted or by doing it manually. Profit margins and variances should remain the same.
Again, using kits means purchasing another module and paying to upgrade it every year. This is a feature that can be incorporated into the existing inventory module. Besides, if a customer pays for software assurance every year, they should be getting more for their money. If they don't, then why upgrade?
-
David W Parvin commented
I thought about what it would take to have a common on-hand quantity field for two stock items and the question for me is how would that effect something like the profit margin report or the variance report or something else like that. You do not want the same physical item being counted more then once in the reports. There are some reports that this would not matter in, but there are a lot of them that it could make your inventory look different then it actually is if this happened. I think using kits as is will do what you are looking for without messing up your reports or anything else. You can go in and do a once a week conversion of items from your case item to your each item to get your each item count up to where it currently is, or you can do one every time you open a new case.
I think that the Denali product can do everything you are looking for except weight and I know that is planned for sometime in the future, just not when.
-
David W Parvin commented
hmm. I can see that adding a field or two might give you what you are looking for. I can also see that even when not using sales or specialty shop, the kit feature could be all you need. With that turned on, you make your case item a bill of materials item and in the kit you say that it is equal to 12 of the can item. You get all of the other things you talk about here except a common on-hand quantity that when you look at the case item it shows an on-hand quantity of 30 and when you look at the each item, you see 360 and when you sell a case then the inventory goes down in both.
The inventory record actually has unit of measure fields on the Sales Info tab of the window.
-
Robert Curioso commented
Dave, You haven't sold me on your suggestions yet. I am not using this software in a retail environment and don't want to pay for another module that only fixes a few of the issues. Even then it is more complicated then just linking two or more item numbers together. My business is wholesale distribution and many times our customers use product numbers to place orders. It appears multi-pack codes may handle some of the issues, but with a lot of extra work as well as confusion. Here are some of the advantages of using separate item numbers: 1) Five price brackets available for every stock number. 2) Unit of Measure (Important on pick tickets and invoices. 3) The ability to supersede. 4) Separate shipping weights and separate cubes. 5) Separate on hand 6) Separate alternate prices 7) Separate standard cost. 8) Separate history 9) Separate Cost/Quantity. 10) Separate committed and available. Basically these are two different items and should be handled that way, not manipulated to make it work. Another factor is reports and invoicing, many fields would have to be added, changed or re-calculated. My industry has many different situations then an average retail store. This feature and others are being offered by many software venders that cater to distributors.
-
David W Parvin commented
One of the ways of dealing with the UPC part of this one is to make a stock alias for your item that is the UPC code. You can have a stock item that has a stock number of BEAN SOUP and then put in an alias to the UPC code that is on the can. When you scan the can, it will put in the UPC code in sales and then change it to BEAN SOUP and load all the relevant data into the screen.
-
David W Parvin commented
I know that in the Specialty Shop add-on you can setup multi-pack codes and set the pricing and quantity for each of them on the stock item. When you go into OE or POS, you can either use the stock number and multi-pack code when selling it, or you can setup a stock alias in inventory that will give you both the stock item and multi-pack code.
Stock Alias' can give you multiple ways of pointing to the save stock item from different types of values.
The Pro product does handle weight, but Denali does not do that yet. I know that it is planned, but when it will be implemented is currently unknown.
One of the other ways I can see doing this would be to make your case a kit containing 12 of the units. When you sell the kit item on OE, it can automatically take 12 out of the units type stock item. You can have separate pricing for the kit and do the discounting in that way. That can also help with giving the customer the lower price for a full case.
-
Robert Curioso commented
Buy/sell conversion does not allow you to use separate items numbers if you sell both by the case and by the unit. As I mentioned before "Many factors make it necessary to have separate SKU’s for these items, Price, UOM, On Hand, Weight to mention a few". Also, higher markups for broken cases, separate UOM for picking (To avoid selection errors), enhanced description and the unit size or pack (example: UOM case=Pack 12, UOM each, pkg, etc.=1) Separate item numbers are important in order entry and on invoices to enter and describe the item correctly.
-
David W Parvin commented
I am not sure if you know this, but Inventory has buy/sell conversion factors so you can tell it that I buy the items in cases of 12 and sell them by the unit. It also automatically adjust the prices and costs with that factor and if you are using multi-pack codes you can even make it more complicated.
You can setup a stock item which you purchase by the pallet, store by the case and sell by the each and so when you order 1 pallet your inventory goes up by 25 cases (just saying this pallet comes with 25 cases) and then when you sell one in sales it is by the unit.