I need to be able to have multiple nodes with the same SKUs. Everything in Ubercart handles this correctly, but the stock module has the SKU as a primary key. If I change the primary key to use both the nid and SKU fields, it works properly.

ALTER TABLE `streichersportal`.`uc_product_stock` 
DROP PRIMARY KEY 
, ADD PRIMARY KEY (`sku`, `nid`) ;

Comments

mertskeli’s picture

mertskeli commented

Sku should be unique. It is not a "model". Mixing these two was the primary uc mistake.
Nothings wrong with that in uc_stock.

tr’s picture

tr commented
Status: Active » Closed (won't fix)

Yes, Ubercart should force SKU to be unique. It does not, currently. I don't think we should support sharing SKUs between nids - that's getting us further away from unique SKUs at a time we should be getting closer. Marking this as "won't fix".

will_in_wi’s picture

will_in_wi commented
Status: Closed (won't fix) » Active

Unless UC is going to be adding features that depend on SKUs being unique across nids, I think that stock should be changed to be consistent with the rest of UC. The rest of the stock code appears to be fine with this change, and it enables edge cases that I would have a very difficult time dealing with otherwise.

My specific case is an ecommerce portal for a client who wants to be able to sell a specific list of items to specific agencies. So agency one has items 1, 2, and 3 with one set of attributes, and agency two has items 3, 4, and 5 with a different set of attributes. I use organic groups to distinguish between customers from different agencies on the site. All of this syncs with a backend ERP system. In the case of item 3, I create a node with the same SKU for each agency and assign it different attributes. If I had to use one node for both agencies, I would need to write a module to limit attribute option availability by organic group; difficult, and I would have to modify other modules which extend the attribute subsystem.

Changing the primary key is a very simple solution which keeps the feature of multiple nodes per sku.

Setting to active for discussion.

tr’s picture

tr commented
Status: Active » Closed (won't fix)

You're welcome to continue the discussion as a feature request on ubercart.org, but as I said I think this is the wrong direction to take. uc_stock has a lot of problems and making the change you request will take us further away from fixing them. I'm not going to commit the patch. If you want to come up with a comprehensive fix that can address your needs as well as handle all the other uc_stock bugs caused by non-unique SKUs, I'd be happy to evaluate that fix. I believe "closed, won't fix" properly describes how this issue is being handled by the maintainers in this issue queue.

mertskeli’s picture

mertskeli commented

@will_in_wi

Please read http://en.wikipedia.org/wiki/Stock-keeping_unit

In short, SKU is like a serial number, unique as your body's DNA. It is like a nid for a node (well, should be). It is not a model. It does not describe a product.

In the case of item 3, I create a node with the same SKU for each agency and assign it different attributes.

Different attributes = different products = different SKUs.

(also http://drupal.org/node/840786#comment-3150226)

micheleannj’s picture

micheleannj commented

I'm using ubercart for a multilingual site -- products can be displayed in French or English. Since Drupal creates one node for each language I'm relying on SKU to relate the two nodes to a single products. Everything works fine for this *except* Views stock level field and the Store Stock report because they rely on nid instead of SKU. I could work around this if SKU wasn't a unique for the table...

I assume you're just going to say it's not your problem, but I at least want to put the scenario out there. Any suggestions would, of course, be appreciated.

mertskeli’s picture

mertskeli commented

micheleannj, probably the default Drupal multilingual concept of making different nodes for different languages is not the best choice for an e-commerce site.
As a possible solution, you could give a try to Language Sections module http://drupal.org/project/language_sections
It would allow you to have multiple languages within a single node.

Anonymous’s picture

Anonymous (not verified) commented
Status: Closed (won't fix) » Needs work

@mertskeli I do not think this suggested solution is accepted practice with modern Drupal multilingual sites. To begin with, it is only available for small sites. It does not even mention if it integrates with i18n or Views. I would be very reluctant to roll this out.

The setup @majoona is using is the standard for translation in Drupal. The Übercart team should at least acknoledge this. You may want to consider looking at the usage statistics for the i18n module if you do not believe me.

Reading back through the thread I see you have written "Nothings wrong with that in uc_stock." While I can understand that you are passionate about your work and the work that has been done by your team I believe that this is a poor response to a legitimate (and well articulated) concern. These requests are not coming from end-users, they are coming from other developers who are also passionate about Übercart.

Anonymous’s picture

Anonymous (not verified) commented

Sorry @majoona is @micheleannj.

Anonymous’s picture

Anonymous (not verified) commented

I keep re-reading this thread and I want to offer some better suggestions and I'm not getting very far. I want Übercart to support multi-language functionality in a way that works. The thing that bothers me about this SKU thing is that my clients use this field like a barcode, which is unique to a product.

The label on the product does not matter. Here in Canada, and certainly in other countries with populations of dual- or multi-language regions and cities, most packaging comes printed in two languages but with only one barcode. Manufacturers know that it is one product so does a consumer picking up the package. Can you imagine going to a checkout at a grocery store and having a different barcode on each side of the package? That's crazy, especially if they are different barcodes. Clients put their barcodes in the SKU field. They do it because it is a unique number for the product.

Übercart does work when you re-use SKUs but stock cannot be synchronized across nodes just like any other content can be with i18n. Due to this one bug, Views is not usable with Übercart. So what to do?

We could write custom queries and put them into a Views Customfield. That's all fine and dandy but you lose the ability to sort anything. So we would need a custom Views handler for this data. Now this begs the question, why can the Views handler not just work with the translated data and substitute the translated NID for the original when dealing with translated content? Allowing Views to support multiple products on one SKU makes sense. It doesn't require a DB change.

When dealing with multi-language sites even a small store of 100 products would become difficult to manage if you had it translated in 10 different languages. With the proposed solutions here we would end up with 100*10 = 1000 products, no way to link them, no way to tell if something has been translated. TONS of administration work. I can't recommend that process to a client nor can I use something that is intended for small sites only.

Edit: had not defined stock sync well

Anonymous’s picture

Anonymous (not verified) commented

For those hitting a dead end on this thread the solution that seems to work here is to create yet another node, only for the product, non-translatable, then node_reference it onto the real product page... then somehow deal with translations in the shopping cart. *facepalm* I don't even want to think about integrating that all in Views.

How embedded is the stock sku unique identifier stuff? I see the module is only 882 lines of code (and clean code at that)... maybe a patch wouldn't be that hard since the rest of Übercart seems fine with reusing the sku. That seems to be what was suggested in #3.

giorgosk’s picture

giorgosk
Location Chios, Greece 🇬🇷
commented

YOu can read my approach which it comes with some flows too
#618150: Stock level for views filters of translated products

Anonymous’s picture

Anonymous (not verified) commented

This bug and related issues will be discussed at Montréal Drupal Camp if my session is approved: http://www.drupalcampmontreal.com/sessions/%C3%BCbercart-vs-i18n-get-duc...

gundara’s picture

gundara commented

subscribing

RachelIsland’s picture

RachelIsland commented

My client needs to add products with the same SKU both in French and in English. It worked fine for the first 50 or so products: all the French and English nodes were properly linked, no errors.

But now she can enter a new product in French or in English with no problem, but she's unable to translate the product node to the other language because she gets an error message saying the SKU is already used:

PDOException : SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '81631' for key 1: INSERT INTO {uc_product_stock} (sku, nid, active, stock, threshold) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => 81631 [:db_insert_placeholder_1] => 435 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => 0 ) dans uc_product_power_tools_node_insert() (ligne 296 dans /home/promoti/public_html/uniformecouture.com/sites/all/modules/uc_product_power_tools/uc_product_power_tools.module).

I thought about telling my client to just add an underscore in the translation's SKU.

Is this a good way to go or is there a better solution?

(Also, it is so time consuming to have to enter all the information twice -SKU, price, and a ton of options. A better multilingual integration would be appreciated! ;)

DanZ’s picture

DanZ commented

Can't you use one of the translation modules so you just have one node, but it appears in a different language depending on the language of the customer? Then, you just have one node, one product, and one SKU.

I haven't used the translation features, but I would be surprised if this weren't possible.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Needs work » Closed (works as designed)

This has been open a long time, we realise the design for uc_stock is far from perfect, but as it stands this currently works as designed. There are several other open issues regarding bugs in stock, but I don't think we are currently in a place to change the primary key on this table.