Ubercart doesn't require unique skus

I have seen on a few forum posts that they will enforce it at some point. A UPC field wouldnt work for attributes though? (see http://drupal.org/node/603024).

Not sure when I'll get to it, but some notes:

Ideally I think we're going to want a new UPC/PLU field which only allows number (so they don't collide with uberpos commands which should only be letters). This field would have to go on the /node/add/product and edit pages, but it would have to also be added to the ubercart attributes adjustments page because we're now supporting skus declared there as well.

Hey,

If you are adding a UPC, would it be feasible to add a "supplier", "supplier ref" and "reorder level" to the product/attributes at the same time? I have a bounty I am planning on issuing to get those added. This could then be utilized by the ubercart reports to give 'per supplier' short falls (with how many to actually order) and the supplier reference not our own internal one which is useless for ordering with. Just throwing it out there if you are already adding another field it might be easy to do as a bonus?

p.

Any reason that displaying a list of products for which stock is short, by supplier, can't be generated using a view? That's what I was planning on doing anyway.

As regards UberPOS (great work guys), and other modules, I'd far rather see discrete functions related to the till, than duplicating functionality (eg stock control) that is found (and probably in many circumstances, if not all, better used) in other modules. In simple terms, keep uberPOS solely as a till system.

Just my opinions, of course!

Jon - I hadn't considered that method but as I have a supplier ref etc that makes perfect sense. Of course, I still don't get a attribute manufacturer code, but it will certainly help! i can then utilize a minimum order figure stored against the supplier ref. cool :)

It makes sense to me to add a barcode function to uc_stock but also allowing uberpos to benefit from it too.

p.

I think it'd be great if another module can step in to provide the UPC/PLU field we need. I'm not aware of any work being done in this direction. Using the SKU field seems wrong in my opinion.

For UberPOS it's crucial that we get a field that:

1. Only accepts numbers (so it doesn't conflict with UberPOS commands)
2. Is unique (or we need a way in the interface to let the cashier to decide which product to select when two UPCs are entered)
3. Shows up on the product ediit page as well as the attributes adjustments page (where you can enter skus), and probably anywhere else a sku can be entered

Now, an Ubercart UPC/Barcode module, upon which UberPOS would be dependent, could accomplish all this. It could give a couple options like "enforce unique UPC numbers" and "only allow numeric characters" which would be helpful for UberPOS. It could also produce a barcode, although I'm not sure that's necessary.

Or we could just throw something into UberPOS. Hopefully not a huge amount of code, but it seems to be something we need.

What do you guys think?

2. would mean you could just use the barcode field in cck per product. If there are attributes available, then ask which one. That would be a simpler method as far as the database etc is concerned...? Personally, I think it would be better to mod the uc_stock module to add a couple of extra fields, but then I am biased for other reasons (reorder levels etc need to be added too!).

p.

General comment guys. Do your attributes not have separate SKU's? In that way there should be no problem using the SKU.

1. Only accept numbers. No way: we have a large number of products which do not come with ean's and we create (semi) human readable alpha numeric codes for them.

A much simpler solution is just to exclude the text command from appearing in your SKU's - like that's going to happen anyway?

I agree that a separate PLU (perhaps exclusively numeric) may be a good idea, but it's yet another field, which doesn't really have any discrete function compared with sku. It's also fine if you are dealing with a few hundred products, but when you're dealing with 1000's of lines, it becomes a bit of a time consuming issue. Now if it's optional to install, I'm all for it ;-)

"1. Only accept numbers. No way: we have a large number of products which do not come with ean's and we create (semi) human readable alpha numeric codes for them."

In my experience supermarkets tend to use short, human-readable, numeric PLUs for things like apples rather than "APPLE" as a SKU.

"A much simpler solution is just to exclude the text command from appearing in your SKU's - like that's going to happen anyway?"

Seems to have already happened:
#599570: New version from yester day

I think it's a lot to expect people to remember every command UberPOS accepts, especially when a lot of them will be relying on the touch screen interface, and never actually typing the commands.

Also, if we don't have a set standard separating commands from PLUs, what happens when we add a command to UberPOS? Then everybody has to look through all of the skus to make sure nothing is going to go wrong.

"like that's going to happen anyway?" is pretty unacceptable in my opinion and isn't going to lead to uberpos being taken seriously.

As I remember it, there are a relatively small number of commands required for UberPOS. That being the case, it shouldn't be too difficult to ensure that whoever (single or multiple person) is responsible for populating the database has it in front of them.

I know that Tesco have a very long sku / plu, and I suspect that the others ( I WILL be looking the next time I'm in :-) ) are similar. Most supermarkets allow for different varieties or product at different prices. Hence Tescos bringing in mushroom bags, mostly paper, but with a transparent plastic strip so the checkout assistant could see that nobody was hiding the more expensive large open cap mushrooms under a layer of cheaper button mushrooms!

I like the new look of UberPOS where the commands are mapped to buttons on screen, just like the very expensive POS systems, meaning that nobody should have to remember many, if any, of the commands.

Lastly, I'm still confused as to why you can't use SKU for PLU? Use all numbers if you wish?

Didn't mean to sound flippant with my last remark, but I do believe that UberPOS should have no problem being taken seriously, having read the intentions of the development team, since at the moment, it's the only solution of it's sort, integrated with Drupal / Ubercart.

Jon

Marking as won't fix.

Basically this is still a concern of mine and should be remedied at some point, but I don't see a clean solution at the moment and it's pretty minor. For now people need to just make sure their barcodes/PLU #s don't conflict with POS commands. They can do this by only using numbers and lowercase letters.

Hi. Is sku field important? I write anything there. Plz tell how user download file after purchase. Main problem, how i add download file in product. There no option. There only image upload option. When i add then image display. Tell how to add.

Catx,

For normal ubercart use SKU is not incredibly important.

For information on selling downloads set:
http://www.ubercart.org/docs/user/3345/selling_files

Please note, this thread relates to uberpos specifically and not general ubercart topics like file downloads. Please direct general ubercart questions to the ubercart project issue queue or the ubercart site at ubercart.org.