One product, several item numbers
A supplier calls a carton SUP-204, your warehouse calls it WH-TEA-24, and a customer orders it as CUST-88. Staff need to identify the same SKU before checking quantity, price or stock. A reviewed correspondence table makes that identity explicit.
| Partner | Partner item number | Your SKU | Product |
|---|---|---|---|
| Tea supplier | SUP-204 | WH-TEA-24 | Tea, 24 units per carton |
| Grocery merchant | CUST-88 | WH-TEA-24 | The same carton |
| Another supplier | SUP-204 | WH-RICE-12 | A different product |
Wholety keeps each supplier's and merchant's mappings separate. The same partner item number can identify a different SKU for another partner. A mapping identifies a product; quantities, prices, tax and stock remain separate records to review when creating an order.
Build and review the complete mapping set
- Create the internal product and SKU first. Check the packaging and SKU code against the actual goods.
- Open Supply Chain → Supplier management → SKU mapping, or Sale → Merchant management → SKU mapping.
- Enter the partner's item number and select the matching internal SKU. Existing mappings load with their internal SKU codes.
- Review the complete mapping set. The editor loads all saved rows and displays them in pages of 20, 50 or 100. Saving includes rows on every page.
- Select Save after reviewing additions, code changes and removed rows. Deleting a row stages its removal; Save applies the complete edited set.
Partner item numbers must be unique within the chosen partner, ignoring case. Each filled row needs both codes. An inactive or missing internal SKU requires a valid replacement or removal before saving. Clearing every existing mapping requires an explicit confirmation.
Use the supplier manual and merchant manual for the entry points and related order workflows. The product manual explains internal SKU setup.
Keep a colleague's changes visible
Suppose you and a colleague open the same merchant's mapping table. Your colleague saves a new item while you edit an older copy. Wholety checks the version you loaded before applying a complete replacement. A conflict leaves your draft visible and blocks saving that stale version.
Note or copy the changes you want to keep, reload the latest table, and apply them to that version. Review again before saving. Switching to another merchant or supplier loads that partner's own table; an earlier request cannot replace the newly selected partner's rows.
Give staff and agents the appropriate access
Main accounts have separate data. A subaccount can read or change partner mappings only for visible partners and with the relevant permission. Merchant delivery addresses follow the same parent visibility rules. A failed address query remains unknown so a retry can obtain the actual addresses.
An account owner can create a read API Key to let an agent inspect a complete mapping snapshot through HTTP or MCP. A write-enabled key can submit a reviewed replacement with the snapshot revision. The server rejects stale revisions and invalid SKUs before changing the table. Owner-created API Keys cover the owner's account; they do not inherit a selected subaccount's partner restrictions.
The legacy batch-save API adds or updates specified codes, while the complete replacement API also removes omitted codes. Agents should choose the operation that matches the user's intent, particularly before clearing a table. The Agent access guide provides the Skill download and connection instructions.
Start with one supplier and one customer
Pick a small group of SKUs that your team orders regularly. Map their supplier and customer item numbers, review the correspondences, then create an order using the verified internal SKUs. Expand the table after staff have checked the product identities.
All features are free for one month after registration, with 1 hour of consultation and assistance included. Create a free account to try the workflow, or explore purchase order management and the merchant ordering portal.