The problem this solves
Wholesale distribution runs on pricing rules and allocation decisions that NetSuite's native records only partly express. A distributor typically carries several hundred customers, each on a different combination of contract price, volume break, promotional allowance and freight rule. Native price levels and quantity pricing on the item record cover the simple cases; they do not cover a contract price that expires on a date, a price that is derived from landed cost plus a margin floor, or a customer who is entitled to a different price on the same item depending on which subsidiary or ship-to location the order is written against.
The same gap shows up downstream. When stock runs short, the allocation decision is made in somebody's head or in a spreadsheet — who gets the 400 units on hand when 900 are committed across eleven sales orders. Rebates owed to customers and rebates claimed from vendors accrue in a spreadsheet and get trued up quarterly, which means the margin on every open order is wrong until someone does the reconciliation. Drop-ship orders get keyed twice because the routing rule that decides ship-from-stock versus ship-from-vendor is a policy, not a field.
This pack is the set of NetSuite customisations that closes those gaps. It is not a shrink-wrapped product sitting in a download folder. ECOSIRE scopes your specific pricing, allocation and rebate rules, quotes a fixed price, then builds and deploys the customisation into your account.
What ECOSIRE builds
Customer price list engine
A custom record set — price agreement header, price agreement line, and a price-break child record — is created and indexed against customer, customer category, item, item class and effective date range. A User Event script on Sales Order, Estimate, Invoice and Cash Sale resolves the applicable price at line level using a documented precedence order (customer + item, customer + item class, customer category + item, contract fallback, item base price). The resolution result is stamped into custom line fields so that a repricing decision made six months ago is still auditable on the transaction record.
Margin floors are enforced in the same script: if the resolved price falls below the floor computed from the item's average or last purchase cost, the line is either blocked or routed into a SuiteFlow approval, depending on the rule you choose during scoping.
Rebate and allowance accrual
Custom records hold rebate programmes — customer rebates, vendor rebates, growth-tier rebates and off-invoice allowances. A Map/Reduce script accrues rebate liability and rebate receivable as transactions post, writing summary rows that feed a saved search and, where you want it, a journal entry per period into accounts you nominate. Because accrual runs as Map/Reduce rather than inside the transaction save, order entry stays fast at volume.
Backorder allocation
A scheduled or on-demand Map/Reduce script evaluates open demand against available supply by item and location, applies your allocation strategy — customer priority tier, order date, requested ship date, fill-or-kill, or a weighted blend — and writes allocation decisions to a custom allocation record plus the sales order lines. Nothing is committed silently: every allocation run produces a log record showing what was allocated, what was starved and which rule fired.
Drop-ship and special-order routing
A User Event and Suitelet pair evaluate each order line against sourcing rules (item is flagged drop-ship-preferred, quantity exceeds a threshold, ship-to region is outside the stocking location's service area, preferred vendor has stock) and set the drop-ship / special-order flags and preferred vendor accordingly. Purchase orders are generated through NetSuite's standard drop-ship mechanism, so vendor bills and item receipts continue to work the way your accountants already understand.
Integration surface
RESTlets are provided for external systems — a WMS, an EDI translator, a customer portal — to query resolved customer pricing, submit orders, and read allocation status. Where you already use SuiteTalk REST or SOAP, the custom fields and records are exposed through the same interface with no separate authentication scheme to manage.
Who this is for
Distributors running NetSuite (standard or OneWorld) with contract pricing, more than a handful of rebate programmes, or regular short-supply situations. It fits best where the pricing and allocation policies already exist in writing or in spreadsheets and simply need to be moved into the system. It is a poor fit if you have no defined pricing policy yet — the build encodes decisions, it does not make them for you.
How delivery works
1. Scoping call. We walk your existing price agreements, rebate programmes, allocation practice and drop-ship rules against your live NetSuite configuration — subsidiaries, item types, locations, roles and the saved searches you already rely on. 2. Fixed quote. You receive a written scope and a fixed price before any code is written. Anything outside the scope is quoted separately rather than absorbed silently. 3. Build. Development happens as an SDF project in SuiteCloud, using SuiteScript 2.1. You get the source. 4. Install in sandbox. The bundle is deployed to your sandbox or release-preview account first. You test with your own data, your own roles and your own approval routing. 5. Production. After your sign-off, the same tested bundle is installed in production, with a documented rollback path. 6. Support. A defect-fix window follows go-live so that anything found in the first weeks of real use is corrected under the original engagement.
Typical build and delivery time is one working week from the point the scope is signed, depending on how many pricing precedence rules and rebate programme types are in play.