Mobile WMS with Barcode Scanning

Most NetSuite warehouses do not fail loudly. They leak. A picker walks the floor with a printed pick ticket, marks quantities in pen, and hands the sheet to whoever is nearest a laptop. The item fulfillment gets keyed an hour later, sometimes the next morning. In between, NetSuite is confidently wrong about what you own: sales quotes stock that already left on a pallet, purchasing reorders parts sitting in an unlabelled bin, and the quarterly count turns into a two-day shutdown to explain a variance nobody can trace back to a person or a timestamp.

The standard remedy is rugged scanning hardware plus a licensed mobile warehouse platform — device quotes, per-seat fees and a rollout plan before a single carton has been scanned. For a site with four warehouse staff and 900 SKUs, that arithmetic rarely closes.

This app takes the other route. The scanner is the phone or tablet your team already carries, and the warehouse logic lives inside your own NetSuite account as scripts you own outright.

What ECOSIRE builds for you

We build a mobile web application, served from your NetSuite account as a Suitelet, which a warehouse operator opens in a browser on Android or iOS, signs into with their own NetSuite role, and uses for the four jobs that actually consume the working day: receiving, putaway, picking and counting. Barcodes are decoded from the live camera feed in the browser. The same input fields accept a Bluetooth wedge scanner, so if you already own hardware it keeps working — the field simply receives keystrokes.

Nothing is stored in a side database. Every scan resolves against real NetSuite records through purpose-built RESTlets — item, inventory item, lot numbered inventory item, serialized inventory item, assembly item, bin, location, purchase order, transfer order, sales order, item receipt, item fulfillment, inventory adjustment, inventory count — and every posting is a native transaction carrying your standard approval routing, custom fields, classifications and subsidiary.

### Receiving against a purchase order The operator scans the PO barcode or the carrier label. A RESTlet loads the open purchase order lines, the screen shows expected against received quantity, and each scan of an item barcode increments the matching line. Lot numbers with expiry dates, or serial numbers, are captured straight into the inventory detail subrecord so the item receipt posts complete instead of being repaired by accounting later. Over-receipt tolerance, blind receiving and whether a staging bin is forced are configuration values on a settings record, not code changes.

### Directed putaway After receipt the app proposes a bin using rules agreed during scoping: the preferred bin on the item record, the last used bin for that item, or a custom putaway rule record we create for you. The operator scans the bin barcode to confirm, or overrides it with a reason. Bins are validated against the location and subsidiary, so stock cannot land in a bin belonging to another warehouse.

### Pick, pack and ship Pick tasks are generated from open sales orders using saved searches your administrator can edit without us, grouped by order, wave or zone. The screen walks the operator bin by bin in sequence, requires both the item and the bin to scan before a quantity is accepted, and refuses a line where the scanned item does not match the ordered item. Short picks are recorded against reason codes held on a custom list. On completion the app creates the item fulfillment through a RESTlet, optionally stamps package weight and tracking number, and moves the order to the status your shipping process expects.

### Cycle counting and adjustments Counts are driven from saved searches — by bin, by ABC class, by item category, by last count date. The operator scans a bin, scans each item present, keys a quantity, and the app writes an inventory count record or an inventory adjustment for the variance, tagged with the counting user and the device timestamp. Variances above a threshold you set are routed for approval rather than posting silently.

How it is engineered

Everything is SuiteScript 2.1 inside your account. The mobile front end is a Suitelet. All read and write traffic passes through RESTlets that revalidate permissions server side, so a manipulated request cannot post a transaction the role is not entitled to post. Long-running work — wave generation, bulk bin transfers, count sheet creation — runs as Map/Reduce scripts so it survives volume instead of hitting governance limits. User Event scripts enforce the rules that must hold however a record is created, including from the desktop UI. Statuses and approval hops that belong in a workflow are built in SuiteFlow so your administrator can adjust them without a developer. Configuration lives in custom records, never in hardcoded constants.

The app respects your permission model rather than working around it. Operators receive a role with the minimum permission set for the transactions they post; supervisors receive count approval and adjustment permissions. In a OneWorld account every screen is subsidiary aware, and locations, bins and items are filtered to what the signed-in role may see. Custom segments and custom fields on your item and transaction records are surfaced on the mobile screens wherever your process needs them.

Who this is for

Distributors, light manufacturers and e-commerce operations already live on NetSuite that still run the floor on paper or a spreadsheet — typically one to five locations, with bin management switched on or about to be. It suits teams who want scanning discipline without adopting a per-device subscription, and who want the code to remain theirs after the project closes.

How delivery works

Everything ECOSIRE sells is built to order. There is no download button and no trial account, because this app does not exist until we build it against your account and your data.

1. Scoping call. We walk your real flow: locations, bins, item types, lot and serial requirements, who may adjust stock, what your pick paperwork looks like today, and which devices your staff carry. 2. Fixed quote and specification. You receive a written scope listing every screen, script, custom record and role change, with a fixed price and a delivery date. Nothing starts until you approve it. 3. Build. We develop as an SDF project under source control, against your sandbox account or a NetSuite developer account if you do not have a sandbox. 4. Install in test. We deploy to your sandbox as an unmanaged bundle or SDF deployment, load representative items and open orders, and your staff test on their own devices. Change requests inside the agreed scope are included. 5. Production install. After sign-off we deploy the same objects to production, configure roles and script deployments, and run the first live receipt and pick alongside your team. 6. Support window. A defect-fix window follows go-live, covering anything that does not behave as specified. After that you hold the source, so your administrator or any other developer can extend it.

Typical lead time from approved quote to sandbox install is one working week. The listed price covers the standard scope described above; anything beyond it — wave planning, cartonization, a carrier label integration — is quoted explicitly rather than assumed.