SOURCE: Discovery task #29796 — SellerCloud and Plex Integration Migration to NetSuite. Requirements gathered from call with Tony Powell (Vornado) on 4/7/26 and Tony's order mapping documentation. PREREQUISITES: #29796 BACKGROUND: Vornado Web Properties are migrating under the ThreeSixtyGroup umbrella. Their SellerCloud OMS currently connects to the Plex ERP via a custom PHP integration (built by Jenna Brin, hosted on InMotion). This task replaces Plex with NetSuite (account 33375 — same environment as the existing PowerBoost/TechMarbles integration) for order sync. The core challenge is that NetSuite does not have native tax enabled in this environment, so tax must be passed via custom fields (matching the existing custbody_powerboost_order_tax pattern from TechMarbles). REQUIREMENTS: - Provision a cloud VPS (DigitalOcean/Linode or similar), set up Node.js environment, SSL, and deployment workflow - Implement SellerCloud API authentication with bearer token reuse (not per-request like current integration) - Poll SellerCloud for orders in "Processing" or "On Hold" status with pagination and deduplication - Create Sales Orders in NetSuite via SuiteTalk REST API with OAuth token-based auth - Map ~30 order fields per channel across 5 active channels: — Vornado Shopify (Company 163, prefix ZVS) — Steamfast Shopify (Company 165, prefix ZSS) — McCulloch Shopify (Company 166, prefix ZMS) — Poulan Shopify (Company 167, prefix ZPS) — Vornado Walmart Marketplace (Company 163, prefix ZWM) - Implement single NetSuite customer per brand/channel with ship-to addresses per order (matching PowerBoost pattern, customer ID TBD by Accenture) - For Walmart orders: all orders under single "Vornado Air LLC - WM" equivalent NS customer with per-order ship-tos - Pass tax as custom field (e.g., custbody_vornado_order_tax) — NOT native NetSuite tax - Pass discount as custom field (e.g., custbody_vornado_order_disc) - Populate SPS Commerce fields for Koerber/GADC fulfillment: custbody_sps_routingkey, custbody_sps_carrieralphacode (FEHD/FDXE), cancel date in enddate field - Map shipping methods: FedEx Ground → shipMethod TBD, FedEx Home Delivery → shipMethod TBD, FedEx 2Day → shipMethod TBD (Accenture to provide NS IDs) - Handle on-hold orders: flag in NetSuite with internal note stating order is on hold in Shopify and to check status there - Handle subscription orders: append *S suffix to customer PO field for consumer service team searchability - Populate internal note with SellerCloud order ID and Shopify/SellerCloud customer number for traceability - Implement error handling with retry logic for transient API failures - Implement structured logging for each sync run (order ID, channel, status, success/failure, timestamp) APPROACH: - Node.js application with modular architecture — separate modules for SC API client, NS API client, field mapping engine, sync orchestrator, and logging - Cron-based scheduling: poll every 15 minutes (matching current SC→Plex cadence) - Field mapping engine uses channel-specific configuration (company ID, prefix, customer pattern) so adding future channels (eBay, Tanga, Temu, Best Buy) requires only config, not code changes - Reference the existing TechMarbles field mappings (14 fields) as the NetSuite SO template — extend with Vornado-specific fields - Token management: cache SellerCloud bearer token and NetSuite OAuth token, refresh on expiry - Idempotency: track synced order IDs to prevent duplicate SO creation on retry TEST CASES: - TC1: Vornado Shopify order syncs to NetSuite SO with correct field mapping, tax in custom field, SPS fields populated - TC2: Steamfast/McCulloch/Poulan Shopify orders sync with correct channel-specific prefixes and customer IDs - TC3: Walmart Marketplace order syncs under single customer with per-order ship-to address - TC4: On-hold order creates SO with hold flag and internal note - TC5: Subscription order creates SO with *S suffix on customer PO field - TC6: Duplicate order detection prevents double SO creation ESTIMATED TIME: 38 to 46 hours ESTIMATE INCLUDES: Production (21h), Test Cases (6), Quality Assurance (3.6h), BETA Testing (2.1h), Deployment: STAGING (1.05h), Deployment: PRODUCTION (1.05h), Technical Management (3.03h), Project Management (4.55h) ESTIMATE NOTES: Estimate Valid Until: 05/23/2026. Due to the dynamic nature of web applications, this estimate is valid only until 05/23/2026, after which time the proposed work will need to be re-estimated to account for any application changes influencing the original scope or approach. CI: 80% - This work contains pre-existing intellectual property including architecture, designs, code, know-how, trade secrets, trade dress, patents, and copyrights that have been used in other projects and will be used in This project and any other project. The non-exclusive license terms for use of This pre-existing, intellectual property and original work products can be found in The Services Agreement. - In the event that an approved estimate is cancelled, the remaining unworked hours will be billed up to the approved total estimate. - Estimates provided do not include travel time or accommodations and will be billed separately if requested and approved by customer.

SOURCE: Confirmed at Blake meeting 5/19/2026 as a standalone task to cover general project management and weekly status meetings across the entire SellerCloud NetSuite Integration build, separate from the per-task project management overhead already baked into individual development tasks. BACKGROUND: The SellerCloud NetSuite Integration project runs approximately 12 weeks from 5/19/2026 to a working target of mid-August 2026, with a hard deadline of 9/1/2026. Over that span, ongoing coordination is needed across multiple stakeholders: Blake Gillan (MerchSource DTC Technology), Tony Powell (Vornado Web Manager), Cale Ostby (Vornado), the Accenture NetSuite team (Neil Young, Chris Craddock, Viswa Teja), Jenna Brenn (existing PHP integration), and Joanna Camardo at Descartes/SellerCloud. This task budgets the time required for that coordination at a roughly weekly cadence. REQUIREMENTS: - Weekly status meeting with Blake Gillan covering progress, blockers, dependencies, and upcoming milestones (~30 minutes per week) - Weekly status email or written update to Blake + Tony + Cale summarizing the week, hours burned, and what is on deck (~15 minutes per week) - Ad-hoc coordination with Accenture regarding NetSuite custom fields, sandbox setup, TBA token provisioning, and downstream script behavior - Ad-hoc coordination with Tony Powell on integration SME questions, edge cases, and channel-specific behavior - Coordination with Jenna Brenn on questions about the existing Plex integration as the migration reference - Project tracking and Intervals task hygiene — keeping task status, time entries, and notes current throughout the project lifecycle - Risk and dependency management — proactive identification and escalation of items that could affect the mid-August target - Final go-live coordination and parallel-run oversight during the Phase 6 cutover window APPROACH: - Weekly cadence Tuesdays — status meeting + weekly summary email aligned with the existing RICO weekly project summary system - Ad-hoc coordination handled as needed throughout the week - Project tracking via Intervals dashboard and the existing customer dashboard at /reports/d/m3rch7x9k2p5w8a1q4v6n0z/ - Risk escalation channel: direct to Blake by email, with Eric Barone copied for significant issues ESTIMATED TIME: 13 hours over the ~12-week project ESTIMATE BREAKDOWN: Weekly status meetings (12 × 30 min = 6h), Weekly written updates (12 × 15 min = 3h), Ad-hoc stakeholder coordination (4h) ESTIMATE NOTES: Estimate Valid Until: 06/19/2026. This task covers project-level management across the entire integration build and is separate from the per-task project management hours already included in #29802, #29803, #29804, and #29805. Hours are budgeted across the project duration and burned incrementally each week. - This work contains pre-existing intellectual property including architecture, designs, code, know-how, trade secrets, trade dress, patents, and copyrights that have been used in other projects and will be used in This project and any other project. The non-exclusive license terms for use of This pre-existing, intellectual property and original work products can be found in The Services Agreement. - In the event that an approved estimate is cancelled, the remaining unworked hours will be billed up to the approved total estimate. - Estimates provided do not include travel time or accommodations and will be billed separately if requested and approved by customer.

SOURCE: Discovery task #29796 — SellerCloud and Plex Integration Migration to NetSuite. PREREQUISITES: #29802 BACKGROUND: When the existing DTC sites (PowerBoost, siRevel, siVacuums) migrate from TechMarbles to SellerCloud as their integration layer, the refund path currently handled by TechMarbles (Shopify refund to NetSuite Credit Memo) will need to be handled by our custom integration instead. For Vornado brands, the same pattern applies: refunds initiated in Shopify flow to SellerCloud via the native Shopify connector, and our integration picks them up and creates the corresponding Credit Memo in NetSuite. The flow is one-way — refunds always originate from Shopify. Orders are cancelled and re-created rather than updated, so there is no order amendment flow to handle. REQUIREMENTS: - Poll SellerCloud for orders with refund/return status — detect when a previously synced order has been fully or partially refunded - Create Credit Memo in NetSuite linked to the original Sales Order, with correct refund amounts per line item - Handle full refunds — entire order refunded, all line items credited - Handle partial refunds — single line item refunded, or reduced quantity on a line item - Handle refund amount discrepancies — cases where refund amount differs from original line price (e.g., restocking fee, partial credit) - Map refund back to correct NetSuite customer and original SO using the order reference fields (SellerCloud order ID or Shopify order number stored on the SO) - Implement idempotency — do not create duplicate Credit Memos for the same refund event - Structured logging: original order ID, refund amount, line items affected, Credit Memo ID created APPROACH: - Add refund sync module to the existing Node.js application from #29802 - Cron schedule: every 30 minutes (refunds are less time-sensitive than order creation) - Query SellerCloud orders API filtered by refund/return status changes since last sync run - Use NetSuite SuiteTalk REST to create Credit Memo records — these are linked to the original SO via the createdFrom field - Match the TechMarbles pattern: Credit Memo with line items mirroring the refunded items from the SO - For partial refunds: only include the specific line items and quantities being refunded - Track synced refund IDs locally to prevent duplicate Credit Memo creation TEST CASES: - TC1: Full refund — Shopify refund for entire order results in Credit Memo in NetSuite with all original line items - TC2: Partial refund (single line) — one item refunded out of multi-item order, only that line appears on Credit Memo - TC3: Partial refund (quantity) — 2 of 3 units refunded on a single line item, Credit Memo reflects correct quantity and amount ESTIMATED TIME: 10 to 12 hours ESTIMATE INCLUDES: Production (5h), Test Cases (3), Quality Assurance (1.25h), BETA Testing (0.5h), Deployment: STAGING (0.25h), Deployment: PRODUCTION (0.25h), Technical Management (0.8h), Project Management (1.2h) ESTIMATE NOTES: Estimate Valid Until: 05/23/2026. Due to the dynamic nature of web applications, this estimate is valid only until 05/23/2026, after which time the proposed work will need to be re-estimated to account for any application changes influencing the original scope or approach. CI: 80% - This work contains pre-existing intellectual property including architecture, designs, code, know-how, trade secrets, trade dress, patents, and copyrights that have been used in other projects and will be used in This project and any other project. The non-exclusive license terms for use of This pre-existing, intellectual property and original work products can be found in The Services Agreement. - In the event that an approved estimate is cancelled, the remaining unworked hours will be billed up to the approved total estimate. - Estimates provided do not include travel time or accommodations and will be billed separately if requested and approved by customer.

SOURCE: Discovery task #29796 — SellerCloud and Plex Integration Migration to NetSuite. PREREQUISITES: #29802 BACKGROUND: When orders are fulfilled at the Koerber/GADC warehouse, shipment data and tracking numbers flow back to NetSuite via SPS Commerce EDI, creating Item Fulfillment records. This task builds the sync that picks up those fulfillments and pushes tracking data back to SellerCloud, which in turn pushes tracking to the sales channels (Shopify, Walmart). Currently, the Plex-to-SellerCloud tracking sync runs every 15 minutes via Jenna Brin's PHP integration. A known issue is that on-hold orders in SellerCloud must be changed from "On Hold" to "Processing" status before tracking will propagate to the sales channel. REQUIREMENTS: - Poll NetSuite for Item Fulfillment records with tracking numbers, filtered by relevant customer IDs and locations (matching the Vornado brand customers set up by Accenture) - Match fulfillments back to SellerCloud orders using the SellerCloud order ID or Shopify order number stored on the NetSuite SO - Push tracking number to SellerCloud via API, updating the order's shipping package with carrier and tracking information - For orders that were synced as "On Hold" in SellerCloud: automatically change status from "On Hold" to "Processing" before pushing tracking, so that SellerCloud propagates the tracking to the sales channel - Handle partial shipments — orders where only some line items have been fulfilled, with remaining items still pending - Handle multi-package shipments — orders with multiple tracking numbers across separate packages - Map carrier codes from NetSuite/SPS format (FEHD, FDXE, FDXG) back to SellerCloud carrier format (FedEx Home Delivery, FedEx 2Day, FedEx Ground) - Implement idempotency — do not push the same tracking number twice to SellerCloud - Structured logging: fulfillment ID, order ID, tracking number, carrier, status change, success/failure APPROACH: - Add a new sync module to the existing Node.js application architecture from #29802 - Cron schedule: every 15 minutes (matching current cadence) - Query NetSuite Item Fulfillments using a saved search or SuiteTalk REST filter — look for fulfillments created/modified since last sync run - Maintain a local state file or database table of already-synced fulfillment IDs for idempotency - The on-hold to processing status change mirrors what Jenna's integration does today: if tracking comes in from the warehouse, the order is cleared to ship regardless of prior hold status - Carrier mapping table as configuration (easy to extend when new carriers are added) TEST CASES: - TC1: Standard fulfilled order — tracking number from NetSuite Item Fulfillment syncs to SellerCloud and propagates to Shopify - TC2: On-hold order — status changes from On Hold to Processing, then tracking pushes successfully to SellerCloud and channel - TC3: Multi-package shipment — multiple tracking numbers on a single order all sync correctly ESTIMATED TIME: 15 to 18 hours ESTIMATE INCLUDES: Production (8h), Test Cases (3), Quality Assurance (1.55h), BETA Testing (0.8h), Deployment: STAGING (0.4h), Deployment: PRODUCTION (0.4h), Technical Management (1.19h), Project Management (1.79h) ESTIMATE NOTES: Estimate Valid Until: 05/23/2026. Due to the dynamic nature of web applications, this estimate is valid only until 05/23/2026, after which time the proposed work will need to be re-estimated to account for any application changes influencing the original scope or approach. CI: 80% - This work contains pre-existing intellectual property including architecture, designs, code, know-how, trade secrets, trade dress, patents, and copyrights that have been used in other projects and will be used in This project and any other project. The non-exclusive license terms for use of This pre-existing, intellectual property and original work products can be found in The Services Agreement. - In the event that an approved estimate is cancelled, the remaining unworked hours will be billed up to the approved total estimate. - Estimates provided do not include travel time or accommodations and will be billed separately if requested and approved by customer.

SOURCE: Discovery task #29796 — SellerCloud and Plex Integration Migration to NetSuite. PREREQUISITES: #29802 BACKGROUND: Inventory currently syncs from Plex to SellerCloud once daily, taking approximately 4 hours for ~1,300 SKUs because the current PHP integration pulls the entire inventory set every time and requests a new API token for each call. SellerCloud manages all channel-level inventory allocation — safety quantities (default 20 units for Shopify), max quantities, and replacement product priority (revision hierarchy where newer revisions ship first). This task builds an optimized inventory sync from NetSuite to SellerCloud that runs multiple times daily. In the current PowerBoost/TechMarbles integration, NetSuite inventory is read with a 95% buffer for DTC allocation. Tony indicated Vornado would prefer full inventory sent to SellerCloud, letting SellerCloud handle allocation — eliminating the need for the buffer. REQUIREMENTS: - Read available inventory from NetSuite by item and location — equivalent to "OK status" inventory in Plex (finished goods, not on order, not being reworked, not in transit) - Filter inventory to relevant NetSuite locations (Koerber/GADC warehouse location, TBD by Accenture) - Match NetSuite items to SellerCloud products by SKU — handle the revision/part number structure where SellerCloud base SKUs may differ from NetSuite item IDs - Push inventory quantities to SellerCloud via API, updating product physical inventory counts - Implement incremental/delta sync — only push inventory that has changed since the last sync run, rather than pulling the entire catalog each time - Target sync completion in under 30 minutes for the full ~1,300 SKU catalog - Handle SKUs that exist in NetSuite but not in SellerCloud (log warning, skip) and vice versa - Structured logging: SKU, previous qty, new qty, location, sync status - Configurable schedule — default to 4x daily but adjustable APPROACH: - Add inventory sync module to the existing Node.js application from #29802 - Use NetSuite SuiteTalk REST API to query inventory — either via saved search on Item records with inventory fields, or via the Inventory Balance endpoint filtered by location - Delta detection: maintain a local cache of last-known quantities per SKU. On each run, compare current NS quantities to cache, only push changes to SellerCloud. Full refresh on configurable interval (e.g., daily) as a safety net - Batch SellerCloud API calls where possible to reduce total API requests and avoid the token-per-call problem from the current integration - SKU mapping configuration: if NetSuite uses different SKU formats than SellerCloud (e.g., with or without revision suffixes), maintain a mapping table. Start with direct SKU match and add translation if needed - SellerCloud handles all downstream allocation: replacement priority, safety quantities, channel-specific max quantities — we just provide the raw available inventory number TEST CASES: - TC1: Standard SKU inventory syncs from NetSuite to SellerCloud with correct quantity, SellerCloud channel allocation reflects update - TC2: Replacement/revision hierarchy — base SKU with multiple revisions receives combined inventory from all child revision SKUs in NetSuite - TC3: Incremental sync — only changed quantities are pushed; unchanged SKUs are skipped (verify via API call count) ESTIMATED TIME: 15 to 18 hours ESTIMATE INCLUDES: Production (8h), Test Cases (3), Quality Assurance (1.55h), BETA Testing (0.8h), Deployment: STAGING (0.4h), Deployment: PRODUCTION (0.4h), Technical Management (1.19h), Project Management (1.79h) ESTIMATE NOTES: Estimate Valid Until: 05/23/2026. Due to the dynamic nature of web applications, this estimate is valid only until 05/23/2026, after which time the proposed work will need to be re-estimated to account for any application changes influencing the original scope or approach. CI: 80% - This work contains pre-existing intellectual property including architecture, designs, code, know-how, trade secrets, trade dress, patents, and copyrights that have been used in other projects and will be used in This project and any other project. The non-exclusive license terms for use of This pre-existing, intellectual property and original work products can be found in The Services Agreement. - In the event that an approved estimate is cancelled, the remaining unworked hours will be billed up to the approved total estimate. - Estimates provided do not include travel time or accommodations and will be billed separately if requested and approved by customer.