Completely different product listings using same SKU
Similar questions have been asked before but closed as unclear or good answers about why don't address the "why not", or answers were posted by people who clearly have no experience to support the their reasons of "it's a bad idea". So i'm asking here with a bit more information.
A default Magento installation does not allow more than 1 product listing to contain the same SKU. Imagine the product is a custom part for a car and fits 3 different makes of cars and the sales material that has proven most optimal is very different for each listing.
In product listing A the description, diagrams, videos and title are completely tailored to one use. In product listing B the description, diagrams, videos and title are completely tailored to another use, but the SKU that the warehouse sends to the customer is the exact same.
To do this in our current ecommerce solution (not Magento), we found a work around years ago based on a flaw in the unique SKU validation logic. We've sold a lot of products for years without problems where multiple listings have the same SKU. Each row in the database has a unique ID and the SKU field is just another field that was improperly validated as unique from the UI so we are able to create different listings that have the same SKU. No big deal because the each row in the database still had a unique record id. Now we are moving to Magento to take advantage of some of its superior out of the box features.
In the Magento database, the catalog_product_entity table has entity_id as the primary index. The sku column having to be unique appears to be a UI level or stored procedure limitation that triggers something on save for validation. I've changed the SKU in the database manually, and then saved one of the duplicate SKU's (in a unique listing) from the UI to make it re-index. It increments the SKU that i saved because it's not unique (if that's one of the ones i'm saving in the UI) but i just change the SKU for that product listing again in the db and everything appears to work (still testing and working on permanent solution). Verified listings have matching stock status, matching SKU's, successful order placement, and successful removal of inventory on sale.
When selling products online, listings are needed for presenting potential customers with exactly the information they are looking for. If what is on that page/listing is what they are looking for, they click "buy" and we get a notification that a purchase was made from listing (entity_id) x for SKU y.
The warehouse database removes one of y and doesn't care what listing it came from. The marketing and inventory planning department can still search for all listings SKU x was sold in to see what people are buying x for the most often. No problems. And on the rare occasion we want to make listing A go out of stock before listing B because of demand priority, we use an alias SKU because that is a use case where we would set inventory in the database to allocate a percentage of inventory (based on qty available and min-stock level values) to an alias SKU.
Now when moving to another e-commerce solution, once again we see this issue trying to force people into this box where a SKU cannot exist in more than one listing. With the amount of volume we've moved and the number of years we've been doing things the way we do, "it's not a good idea" or "it's bad practice", or "it's gonna take a lot of work" are not credible answers.
It would be easier to accept if we were new to e-commerce and didn't have the transaction history to prove it's not a problem for tracking, inventory control and so far makes managing multiple listings that are unique but have the same SKU easier. The information I've found so far suggest it's just copied from other platforms without seriously researching the "why or why not".
In Magento, what is the purpose of the forcing SKU to be unique in every product listing when in practice the only thing required to be unique is entity_id?
Yes it's a "product listing", but most importantly, it's a "listing" of something described for sale. Forcing it to have unique SKU makes it more difficult (must create different SKU's, aliases, manage inventory level separately) to sell an inventory item as many different things when at the warehouse level they are the same.
magento2
add a comment |
Similar questions have been asked before but closed as unclear or good answers about why don't address the "why not", or answers were posted by people who clearly have no experience to support the their reasons of "it's a bad idea". So i'm asking here with a bit more information.
A default Magento installation does not allow more than 1 product listing to contain the same SKU. Imagine the product is a custom part for a car and fits 3 different makes of cars and the sales material that has proven most optimal is very different for each listing.
In product listing A the description, diagrams, videos and title are completely tailored to one use. In product listing B the description, diagrams, videos and title are completely tailored to another use, but the SKU that the warehouse sends to the customer is the exact same.
To do this in our current ecommerce solution (not Magento), we found a work around years ago based on a flaw in the unique SKU validation logic. We've sold a lot of products for years without problems where multiple listings have the same SKU. Each row in the database has a unique ID and the SKU field is just another field that was improperly validated as unique from the UI so we are able to create different listings that have the same SKU. No big deal because the each row in the database still had a unique record id. Now we are moving to Magento to take advantage of some of its superior out of the box features.
In the Magento database, the catalog_product_entity table has entity_id as the primary index. The sku column having to be unique appears to be a UI level or stored procedure limitation that triggers something on save for validation. I've changed the SKU in the database manually, and then saved one of the duplicate SKU's (in a unique listing) from the UI to make it re-index. It increments the SKU that i saved because it's not unique (if that's one of the ones i'm saving in the UI) but i just change the SKU for that product listing again in the db and everything appears to work (still testing and working on permanent solution). Verified listings have matching stock status, matching SKU's, successful order placement, and successful removal of inventory on sale.
When selling products online, listings are needed for presenting potential customers with exactly the information they are looking for. If what is on that page/listing is what they are looking for, they click "buy" and we get a notification that a purchase was made from listing (entity_id) x for SKU y.
The warehouse database removes one of y and doesn't care what listing it came from. The marketing and inventory planning department can still search for all listings SKU x was sold in to see what people are buying x for the most often. No problems. And on the rare occasion we want to make listing A go out of stock before listing B because of demand priority, we use an alias SKU because that is a use case where we would set inventory in the database to allocate a percentage of inventory (based on qty available and min-stock level values) to an alias SKU.
Now when moving to another e-commerce solution, once again we see this issue trying to force people into this box where a SKU cannot exist in more than one listing. With the amount of volume we've moved and the number of years we've been doing things the way we do, "it's not a good idea" or "it's bad practice", or "it's gonna take a lot of work" are not credible answers.
It would be easier to accept if we were new to e-commerce and didn't have the transaction history to prove it's not a problem for tracking, inventory control and so far makes managing multiple listings that are unique but have the same SKU easier. The information I've found so far suggest it's just copied from other platforms without seriously researching the "why or why not".
In Magento, what is the purpose of the forcing SKU to be unique in every product listing when in practice the only thing required to be unique is entity_id?
Yes it's a "product listing", but most importantly, it's a "listing" of something described for sale. Forcing it to have unique SKU makes it more difficult (must create different SKU's, aliases, manage inventory level separately) to sell an inventory item as many different things when at the warehouse level they are the same.
magento2
add a comment |
Similar questions have been asked before but closed as unclear or good answers about why don't address the "why not", or answers were posted by people who clearly have no experience to support the their reasons of "it's a bad idea". So i'm asking here with a bit more information.
A default Magento installation does not allow more than 1 product listing to contain the same SKU. Imagine the product is a custom part for a car and fits 3 different makes of cars and the sales material that has proven most optimal is very different for each listing.
In product listing A the description, diagrams, videos and title are completely tailored to one use. In product listing B the description, diagrams, videos and title are completely tailored to another use, but the SKU that the warehouse sends to the customer is the exact same.
To do this in our current ecommerce solution (not Magento), we found a work around years ago based on a flaw in the unique SKU validation logic. We've sold a lot of products for years without problems where multiple listings have the same SKU. Each row in the database has a unique ID and the SKU field is just another field that was improperly validated as unique from the UI so we are able to create different listings that have the same SKU. No big deal because the each row in the database still had a unique record id. Now we are moving to Magento to take advantage of some of its superior out of the box features.
In the Magento database, the catalog_product_entity table has entity_id as the primary index. The sku column having to be unique appears to be a UI level or stored procedure limitation that triggers something on save for validation. I've changed the SKU in the database manually, and then saved one of the duplicate SKU's (in a unique listing) from the UI to make it re-index. It increments the SKU that i saved because it's not unique (if that's one of the ones i'm saving in the UI) but i just change the SKU for that product listing again in the db and everything appears to work (still testing and working on permanent solution). Verified listings have matching stock status, matching SKU's, successful order placement, and successful removal of inventory on sale.
When selling products online, listings are needed for presenting potential customers with exactly the information they are looking for. If what is on that page/listing is what they are looking for, they click "buy" and we get a notification that a purchase was made from listing (entity_id) x for SKU y.
The warehouse database removes one of y and doesn't care what listing it came from. The marketing and inventory planning department can still search for all listings SKU x was sold in to see what people are buying x for the most often. No problems. And on the rare occasion we want to make listing A go out of stock before listing B because of demand priority, we use an alias SKU because that is a use case where we would set inventory in the database to allocate a percentage of inventory (based on qty available and min-stock level values) to an alias SKU.
Now when moving to another e-commerce solution, once again we see this issue trying to force people into this box where a SKU cannot exist in more than one listing. With the amount of volume we've moved and the number of years we've been doing things the way we do, "it's not a good idea" or "it's bad practice", or "it's gonna take a lot of work" are not credible answers.
It would be easier to accept if we were new to e-commerce and didn't have the transaction history to prove it's not a problem for tracking, inventory control and so far makes managing multiple listings that are unique but have the same SKU easier. The information I've found so far suggest it's just copied from other platforms without seriously researching the "why or why not".
In Magento, what is the purpose of the forcing SKU to be unique in every product listing when in practice the only thing required to be unique is entity_id?
Yes it's a "product listing", but most importantly, it's a "listing" of something described for sale. Forcing it to have unique SKU makes it more difficult (must create different SKU's, aliases, manage inventory level separately) to sell an inventory item as many different things when at the warehouse level they are the same.
magento2
Similar questions have been asked before but closed as unclear or good answers about why don't address the "why not", or answers were posted by people who clearly have no experience to support the their reasons of "it's a bad idea". So i'm asking here with a bit more information.
A default Magento installation does not allow more than 1 product listing to contain the same SKU. Imagine the product is a custom part for a car and fits 3 different makes of cars and the sales material that has proven most optimal is very different for each listing.
In product listing A the description, diagrams, videos and title are completely tailored to one use. In product listing B the description, diagrams, videos and title are completely tailored to another use, but the SKU that the warehouse sends to the customer is the exact same.
To do this in our current ecommerce solution (not Magento), we found a work around years ago based on a flaw in the unique SKU validation logic. We've sold a lot of products for years without problems where multiple listings have the same SKU. Each row in the database has a unique ID and the SKU field is just another field that was improperly validated as unique from the UI so we are able to create different listings that have the same SKU. No big deal because the each row in the database still had a unique record id. Now we are moving to Magento to take advantage of some of its superior out of the box features.
In the Magento database, the catalog_product_entity table has entity_id as the primary index. The sku column having to be unique appears to be a UI level or stored procedure limitation that triggers something on save for validation. I've changed the SKU in the database manually, and then saved one of the duplicate SKU's (in a unique listing) from the UI to make it re-index. It increments the SKU that i saved because it's not unique (if that's one of the ones i'm saving in the UI) but i just change the SKU for that product listing again in the db and everything appears to work (still testing and working on permanent solution). Verified listings have matching stock status, matching SKU's, successful order placement, and successful removal of inventory on sale.
When selling products online, listings are needed for presenting potential customers with exactly the information they are looking for. If what is on that page/listing is what they are looking for, they click "buy" and we get a notification that a purchase was made from listing (entity_id) x for SKU y.
The warehouse database removes one of y and doesn't care what listing it came from. The marketing and inventory planning department can still search for all listings SKU x was sold in to see what people are buying x for the most often. No problems. And on the rare occasion we want to make listing A go out of stock before listing B because of demand priority, we use an alias SKU because that is a use case where we would set inventory in the database to allocate a percentage of inventory (based on qty available and min-stock level values) to an alias SKU.
Now when moving to another e-commerce solution, once again we see this issue trying to force people into this box where a SKU cannot exist in more than one listing. With the amount of volume we've moved and the number of years we've been doing things the way we do, "it's not a good idea" or "it's bad practice", or "it's gonna take a lot of work" are not credible answers.
It would be easier to accept if we were new to e-commerce and didn't have the transaction history to prove it's not a problem for tracking, inventory control and so far makes managing multiple listings that are unique but have the same SKU easier. The information I've found so far suggest it's just copied from other platforms without seriously researching the "why or why not".
In Magento, what is the purpose of the forcing SKU to be unique in every product listing when in practice the only thing required to be unique is entity_id?
Yes it's a "product listing", but most importantly, it's a "listing" of something described for sale. Forcing it to have unique SKU makes it more difficult (must create different SKU's, aliases, manage inventory level separately) to sell an inventory item as many different things when at the warehouse level they are the same.
magento2
magento2
asked 6 mins ago
jtlindseyjtlindsey
1167
1167
add a comment |
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "479"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f259011%2fcompletely-different-product-listings-using-same-sku%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Magento Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fmagento.stackexchange.com%2fquestions%2f259011%2fcompletely-different-product-listings-using-same-sku%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown