Story 47.1.2 Update SKU Handling for Drop-Ship Bags

General info

Currently, external partner SKUs (long IDs like LAVG6W574CT9K955) are imported but hidden on the product page, leaving customers without a clear reference. Internally, we already generate sequential SACLÀB SKUs (e.g. 6910) for tracking. To improve customer experience while still keeping external partner SKUs for operational flows, we need to introduce a dedicated field, retrofit existing drop-ship items, and update syncing logic.

User story

As a Creator on Saclab Airtable,

I want imported external SKUs to be stored separately from our internal SKUs,

So that customers always see a clean, short internal SKU on the product page, while external SKUs remain available for drop-ship partner sync, order flows, and communication.

Acceptance criteria

#

Scenario / Gherkin

Visuals / Notes

01

New field in Product Inventory

Given I am a Creator on Saclab Airtable bases

When I add or import a new bag via the Import table

Then the system should generate an internal SKU (sequential number, e.g. 6910)
And copy any provided SKU into a new field called ESKU (external SKU)

New Airtable field:
ESKU

Internal SKU uses existing rising number logic

02

Website visibility

Given a bag exists in Product Inventory with both an internal SKU and ESKU

When the bag is displayed on the product detail page

Then only the internal SKU is shown to customers
And ESKU (external) is never displayed

Example frontend: “SKU: 6910”

03

Retrofit existing drop-ship items

Given there are existing bags in Product Inventory with O/C = Drop-Ship and no internal SKU

When the system is updated

Then each of these bags should automatically receive a new internal SKU following the rising number logic

And the current partner’s SKU should be copied into ESKU

And if the bag already has an internal SKU, it must remain unchanged (no overwriting) And this process should run once at rollout across all live inventory

04

WooCommerce sync

Given a bag is synced to WooCommerce

When the SKUs are transferred

Then the internal SKU is synced as the WooCommerce product SKU

And the ESKU is stored as a WooCommerce but not visible on frontend but queryable via API/admin

Ensures both SKUs are available in WP, but only internal shown for customers

05

HubSpot + Slack sync

Given a bag is imported into the system

When it is synced to HubSpot

Then the internal SKU should be stored in the HubSpot deal for consistency with customer-facing SKU

And ESKU should also be synced into HubSpot as a separate property for reference in partner-related workflows

When a sale notification is posted to #bag-sales Slack

Then only the internal SKU is used in the message “Bag sold: DROP-SHIP [InternalSKU] [Bagname] Order ID: [OrderID] ([Status])”

Example HubSpot: Deal fields = {Internal SKU: 6910, ESKU: LAVG6W574CT9K955}

Example Slack: “Bag sold: DROP-SHIP – 6910 – Bag name”

06

Drop-ship sale flow

Given a bag has O/C = Drop-Ship

When the bag is sold

Then emails sent to the external partner must include the ESKU in subject and body

07

Removal scenario

Given: an email “Item Status Update” is received at sales@saclab.com with ESKU + bag name

When the ESKU matches a ESKU in the system

Then the bag should be moved to Removed by seller as per current logic

Uses ESKU for partner-triggered removals

Comments

Leave a Reply