ellovee

Hi Shameem,

Yes, you’re right—SKUs and GTINs are totally different and can’t/shouldn’t be used equivalently. I’ve submitted this as a bug in GitHub rather than a feature request since products contain both fields and and the mapping is actually incorrect; it’s not one of multiple options. This is an issue that needs to be fixed rather than a new feature to add to a long wishlist.

I’ll use the (very ill-advised) temporary workaround of replacing our SKUs with barcode numbers in the meantime since I need this to work during the holiday shopping season but I hope this can be fixed sooner rather than later.

Hi Shameem,

Thank you so much for clarifying. I’m glad to see that the export/import bug is being fixed in the next release. Is there also timeline for when barcode scanning in the app will work with…barcodes?

Having barcode scanning map to a SKU is super confusing since SKUs are internal codes rather than universal ones and typically don’t have a bar/QR visual scan form. How does this even work? Would I need to change every product’s SKU to match its barcode in order for this to function? This is not how SKUs and barcodes are meant to work in retail so none of this makes any sense to me. :/

Hi José,

Thank you for replying so quickly. I was still unable to receive the email, in spam or otherwise, but after logging out of my account and back in again, I’m now able to post a new forum topic, so I’ll move this discussion there. In the meantime,

• Yes, I’m running the latest versions of ATUM, WooCommerce, and WordPress
• Even if I disable all plugins except for ATUM and WooCommerce the problem persists

Thanks, Tobin! I’ve already jettisoned Blocks and installed the free Fluid Checkout plugin instead. It has the same flow as the Checkout Block but sits on top of the legacy structure, so I didn’t have to sacrifice conversion to switch back. And I can also now use all of the other plugins that are incompatible with Blocks without having to jury rig new connections and styles every time there’s an update. Blocks just isn’t usable enough yet and with no development timeline or plans to integrate with basic extensions like gift cards, I just can’t keep using it. Maybe next year.

OK, thanks. Abandoning Blocks now and seeing what I can do with legacy checkout to minimize the friction of that flow (which WooCommerce confirms converts 20% less than the newer Checkout Block). I’m super disappointed that these are the choices merchants are forced to make. These have huge effects on our livelihoods and families.

I’ve already read this, thanks. There are no actual timelines in this doc, just vague terms like “Next” and “Later.” The “85-90% coverage of the extensibility needs” listed under the “Now” section also doesn’t link to any concrete information and many of WooCommerce’s own popular extensions don’t appear on either the “compatible” or “incompatible” list. The only thing I can infer from this doc is that WooCommerce has no obvious plans to improve the legacy checkout flow, and no actual timeline for when Blocks will work with common extensions beyond some payment gateways and shipping services. Without an actual timeline, merchants stay in the dark and continue to lose sales for an indefinite period of time, two years and counting.