Textile & Garment Manufacturing for Business Central

Key Features

`Style` master table with independent size and colour axes, size-ratio setup, and per-style size charts stored as records rather than convention-encoded item numbers

Matrix order entry page that turns a buyer PO grid (colour x size x quantity) into Business Central sales order lines against variant-tracked items in one post

Cut plan document with lay length, marker efficiency and fabric-width inputs computing fabric requirement per colour, with a shortfall check against available fabric lots

Numbered bundle generation from the cut plan - size, colour, layer count, ply and destination line printed as barcoded bundle cards

Bundle movement posting through codeunits that write standard item ledger and capacity ledger entries, so WIP reconciles in native Business Central ledgers

Line-wise production output entry with operator, operation and hour capture, posted against Routing operations rather than a parallel shadow table

Size-dependent BOM consumption - fabric quantity per component scaled by size, so a 2XL consumes what it actually consumes

Order costing rollup gathering fabric issue, trim consumption, CMT, subcontracted processes and freight back to the style and buyer PO using standard cost objects

Export document set: commercial invoice, packing list with carton-level size breakdown, and a configurable declaration / certificate-of-origin layout per destination market

Carton and assortment packing model, including solid-colour and ratio-pack cartons, with gross/net weight and volume carried to the shipment

Subcontractor (CMT / job-work) tracking for issue and receipt of cut parts, with per-unit process rates feeding the costing rollup

API pages published on REST API v2.0 / OData v4 exposing styles, cut plans, bundles and output entries for CAD, marker-making and buyer EDI integration

Job queue entries for nightly cost rollup, WIP revaluation and export-document pre-generation

Named permission sets for merchandising, cutting floor, production and costing roles, plus Dataverse-ready entities for Power BI and Power Apps shop-floor capture

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

A garment order is never one item. A single buyer PO is a style, in four colourways, across six sizes, with a ratio per pack — 24 SKU-equivalents that the merchandiser thinks about as one line and that Business Central insists on treating as 24 unrelated items. Teams work around it: item numbers built by string convention, a spreadsheet holding the real size ratio, cut plans and bundle cards written by hand on the cutting floor, and export paperwork retyped from the sales order into Word. The cost of that workaround shows up at the end of the season, when nobody can say what a style actually cost to make, because the fabric issue, the trim consumption, the CMT charge and the freight all landed in different places.

Business Central out of the box has the pieces but not the shape. Item Variants exist, but they are a single flat dimension — there is no native concept of a size axis crossed with a colour axis, no size ratio, and no way to enter a buyer PO as a matrix. Production BOMs and Routings are solid for discrete manufacturing but assume a bill per item, not a bill per style with size-dependent fabric consumption. Item Tracking handles lots and serials, not cut bundles moving between cutting, stitching, finishing and packing. And the export side — commercial invoice, packing list with carton-level size breakdown, certificate of origin — has no home in the standard document set. Every one of those gaps is a place where the truth leaves the system.

What we build is an AL extension that adds the garment model to Business Central rather than beside it. A Style master carries the size and colour axes as real records, with a size ratio, and a matrix entry page that lets a merchandiser key a buyer PO in one screen and generate the underlying sales order lines against variant-tracked items. A cut plan is a first-class document: it takes the order matrix, applies marker efficiency and fabric width to compute lay length and fabric requirement, and issues numbered bundles with a size, colour, layer count and destination line. Bundle movement is posted through codeunits that write to standard item ledger and capacity ledger entries, so line-wise output and WIP stay reconcilable in the native ledgers instead of a parallel table. Order costing rolls fabric issue, trim consumption, CMT and outsourced processes back to the style and to the buyer PO, using the standard cost object structure so your existing Business Central reports keep working. Export documents are report objects driven from the shipment, producing a commercial invoice and a packing list that shows cartons with the actual size breakdown inside them, plus a declaration set matched to your destination markets. Integration follows the platform rules: table and page extensions rather than modified base objects, event subscribers instead of forked code, API pages on REST API v2.0 / OData v4 so your CAD, marker-making or buyer EDI systems can read the style and cut plan without a file drop, job queue entries for nightly costing rollups, and named permission sets for merchandising, cutting-floor and costing roles. It targets current Business Central release waves on SaaS and runs on-premises where you need it, delivered as a per-tenant extension or shaped for AppSource validation if you intend to publish.

This is build-to-order, not a download. There is no AppSource listing to install today. We start with a scoping call, walk your actual buyer POs, size charts, cut-plan practice and export destinations, and write a specification that names the tables, pages, codeunits and reports we will add and — just as importantly — what we will not add in version one. Typical delivery is two to four weeks from confirmed scope, longer if you need buyer-specific EDI or a multi-unit subcontracting model. You get the AL source, a signed extension built against your Business Central version, deployment on a sandbox for UAT before anything touches production, a rollback plan, documentation, a training session for merchandisers and costing staff, and a support window after go-live. The repository is handed to you, so nothing about your production model is locked behind us.

What you get

Complete AL source for the extension, built and tested against your specific Business Central version and release wave

Signed extension package with installation and configuration on your environment (SaaS per-tenant extension or on-premises deployment)

UAT deployment to a sandbox environment with a documented test script and a written rollback plan before production release

Technical documentation: object ID ranges, table and page extensions, codeunit and event-subscriber map, API page endpoints, permission sets

User guide covering style setup, matrix order entry, cut planning, bundle tracking, output entry and export document generation

Live training session for merchandising, cutting-floor and costing users, recorded for later staff onboarding

Git repository handover with full commit history, branch structure and build pipeline configuration

Post-go-live support window for defect fixes and configuration adjustments on the delivered scope

Who this is for

Owner or Director, export garment unit

Runs a cutting and stitching operation shipping to overseas buyers. Wants one system where a buyer PO, the cut plan and the export invoice are the same record, and wants a defensible per-style cost at the end of the season instead of a spreadsheet reconstruction.

Merchandiser / Order Management lead

Owns the buyer relationship and enters the orders. Needs to key a colour x size matrix in one screen with the buyer's size ratio applied, see the fabric requirement immediately, and answer 'can we ship the full set by the date' without walking to the cutting floor.

Production / Cutting Floor Manager

Issues cut plans, tracks bundles between cutting, stitching, finishing and packing, and reports line output daily. Needs bundle cards that survive the floor, and output entry that posts to the real ledgers so WIP is not a guess.

Costing and Finance Manager

Answers what a style cost and whether the order made margin. Needs fabric, trim, CMT, subcontract and freight rolled to the style using standard Business Central cost objects, so existing financial reporting and audit trails continue to work.

How Textile & Garment Manufacturing for Business Central Compares

Criterion	ECOSIRE	Custom Build	Competitor	Dynamics 365 Business Central Native
Size/colour matrix model	Style master with real size and colour axes plus size ratio, built to your buyers' size charts	Achievable, but the axis model is the hardest design decision and is usually got wrong on the first attempt	Fixed matrix shape that may not match your buyers' size charts or ratio-pack practice	Item Variants only - a single flat dimension, no size axis, no ratio
Cut plan and bundle tracking	Cut plan document with marker efficiency and lay calculation, issuing barcoded numbered bundles	Buildable, but bundle-to-ledger posting is where in-house builds typically drift into a shadow table	Varies widely - many apps stop at cut quantity and leave bundles on paper	No cut plan or bundle concept; Item Tracking covers lots and serials only
Order costing accuracy	Fabric, trim, CMT, subcontract and freight rolled to style and buyer PO through native cost objects	Depends entirely on whether the developer used standard cost objects or invented a parallel structure	Usually present, but often in its own tables so it does not reconcile to the GL	Standard manufacturing costing per item - no style-level or buyer-PO-level view
Export documentation	Commercial invoice, packing list with carton-level size breakdown, configurable declarations per market	Report objects have to be written from scratch for each document and market	Often generic export docs not built around garment carton and assortment packing	Standard sales invoice and shipment; no packing list with size breakdown, no origin documents
Fit to your process	Scoped against your actual buyer POs, size charts and export destinations before any code is written	Fits exactly - you are paying for every requirement discovery cycle yourself	You adapt your process to the app's assumptions, or pay for customisation on top	You adapt entirely, usually via spreadsheets outside the system
Upgrade safety across release waves	Table/page extensions and event subscribers only - no base-object modification, recompile-and-test per wave	Safe if disciplined; in-house builds under deadline pressure often are not	Vendor handles it, but you wait on their release schedule to unblock your upgrade	Microsoft handles it; nothing of yours to break
Time and cost to reach production	Typically 2-4 weeks from confirmed scope, at a fixed quoted price	Months of hiring, discovery and iteration before the first usable version	Install in days - then weeks of trying to bend your process to fit	Immediate, but the gap moves onto spreadsheets and never closes
Ownership and lock-in	Full AL source and Git repository handed over; any AL developer can continue it	You own it, and you own the maintenance and the bus factor	Licensed binary - no source, no exit path except re-implementation	Nothing to own; nothing to extend

Frequently Asked Questions about Textile & Garment Manufacturing for Business Central

How long does delivery take?

This is build-to-order - there is nothing to download today. Typical delivery is two to four weeks from confirmed scope, measured from the day you sign off the specification, not from the first call. Simple deployments (single unit, standard export document set, no EDI) land at the shorter end. Buyer-specific EDI, multi-unit subcontracting or a heavily customised costing model extend it, and we will tell you that during scoping rather than after.

Does this work on Business Central SaaS, or only on-premises?

Both. We build it as a standard AL extension using table extensions, page extensions, codeunits and event subscribers - no base-application modification - so it installs as a per-tenant extension on Business Central online and deploys equally on-premises. It targets current release waves, and if you intend to publish it to AppSource we can shape the object model and code to meet AppSource technical validation from the start.

What happens to support and Business Central updates after go-live?

You get a defined post-go-live support window for defect fixes and configuration adjustments on the delivered scope. Because the extension avoids base-object modification and uses event subscribers, Microsoft's twice-yearly release waves are normally a recompile-and-test exercise rather than a rewrite; we can cover that under a support agreement, or you can handle it yourself - you own the source and the repository, so you are never blocked waiting on us.

Will this break our existing Business Central setup, or conflict with other extensions?

We work in a reserved object ID range, extend rather than replace, and subscribe to published events. Before anything reaches production we deploy to a sandbox, run UAT against your real data with your users, and hold a written rollback plan. If you already run other extensions, we check for object-range and event-subscription conflicts during scoping and tell you before we start building.

How does the costing actually reconcile with Business Central financials?

The costing rollup uses standard Business Central cost objects - item ledger entries, capacity ledger entries, value entries and dimensions - rather than a parallel costing table. Fabric issue, trim consumption, line hours, subcontract charges and freight post through the native ledgers, so the style cost you see reconciles to the general ledger and your existing financial reports and audit trail continue to work unchanged.

Can it integrate with our CAD, marker-making system or buyer EDI?

Yes. We publish API pages on REST API v2.0 / OData v4 exposing styles, size matrices, cut plans, bundles and output entries, so a CAD or marker-making system can read and write without file drops. Buyer EDI is scoped per buyer - the format and transport differ by customer, so we quote it as a named work item rather than assuming it. Dataverse connectivity is available where you want Power Apps for shop-floor capture or Power BI for line-efficiency dashboards.

Do we own the code?

Yes. You receive the complete AL source and a Git repository handover with full commit history and build configuration. Your production model, size charts and costing logic are not locked behind us, and another AL developer can pick it up from the documented object map.