Robert Curioso
My feedback
4 results found
-
2 votes
An error occurred while saving the comment An error occurred while saving the comment 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?
An error occurred while saving the comment 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.
An error occurred while saving the comment 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.
Robert Curioso
supported this idea
·
Robert Curioso
shared this idea
·
-
7 votes
We are currently reviewing this functionality for development.
Robert Curioso
shared this idea
·
-
7 votesRobert Curioso
shared this idea
·
-
40 votes
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.