Two-Way Sync for CPG Master Data: NetSuite, Postgres, and Field Ownership

What this looks like in consumer packaged goods

A CPG operations team keeps SKU aliases in spreadsheets because each marketplace and distributor calls the same product something different. The team wants a shared application backed by Postgres. If that application writes directly into mirrored ERP rows without review, a typo can become an operational change before anyone checks the affected channels.

Records, ownership, and update rules

Work through the process

1. 01
   Design the keys first

   Use stable internal IDs for ERP records and separate keys for externally visible codes. An SKU alias can change while historical orders must still resolve to the item sold at the time.
2. 02
   Separate views from commands

   Expose synchronized data for investigation through read views. Route proposed corrections through a controlled table or application path with an owner and approval state rather than treating every database update as permission to write to the ERP.
3. 03
   Check dependent relationships

   Before approving a pack or alias correction, list affected open orders and channel mappings. A valid new mapping may still be inappropriate for orders created under an older product revision.
4. 04
   Verify the accepted result

   After an approved write, read the destination record and compare the owned fields. Preserve both the proposed and accepted value if the ERP normalizes or rejects part of the request.
5. 05
   Push one approved alias correction from Postgres to NetSuite

   Change one marketplace SKU alias through the proposed-correction table in Postgres, with requester, reason and effective date. After the steward approves it, read the NetSuite item: only the alias field may change; internal ID, revision and finance-owned values must be untouched. Query an order created before the effective date: it must still resolve to the earlier alias revision. Then submit an alias already owned by a second product; the mapping must move to suspended with both items listed for the steward. Stop the rollout if a direct mirror-table update reaches NetSuite, if the old order shows the new alias, or if the overlap was applied to either product.

Handle the exceptions explicitly

Alias overlaps two products

Suspend the ambiguous mapping and ask the steward to establish scope and effective dates.

Database user edits a protected mirror

Block or disregard unauthorized write-back according to the configured ownership model.

ERP rejects an approved value

Keep the change pending with the rejection evidence; approval is not proof of acceptance.

What to verify before expanding

• Historical orders retain the correct mapping revision.
• Only approved, permitted fields can produce an ERP write.
• A protected ERP mirror field cannot be changed through an unauthorized database edit during the pilot.
• An approved correction rejected by NetSuite remains pending with its rejection detail and cannot appear as accepted.

Technical references

• Stacksync two-way sync quick start
• Stacksync NetSuite supported objects