How to Set Up Multi-Site Configuration in SyteLine
how to set up multi-site configuration in SyteLine
Also searched as
- syteline multi-site intersite transfer setup
- how does syteline share item master across sites
- syteline single database multiple sites configuration
- csi multi-site intranet architecture
Short answer
SyteLine supports multiple manufacturing or distribution sites either as separate Site records within one shared database, or as fully separate databases linked through intersite transactions and, in CloudSuite Industrial, ION. Getting the site model right up front, shared versus separate master data, intersite transfer setup, avoids a painful data migration later.
Applies to: SyteLine 8.x/9.x and Infor CloudSuite Industrial, supporting single-database multi-site and multi-database, multi-tenant, site architectures.
Plan and configure a multi-site environment
- 1Decide between a single-database multi-site model, each site a Site record inside one SyteLine database sharing the same application instance, versus a multi-database model, typically used when sites need separate go-live dates, separate chart of accounts structures, or data residency requirements.
- 2In the single-database model, create the new Site record under System Administration and decide, IDO by IDO, which master data, items, customers, vendors, GL accounts, is shared globally versus maintained per site.
- 3Configure user default sites and site security so staff only see and transact against sites they are authorized for, since a poorly scoped multi-site setup lets users accidentally post to the wrong site.
- 4Set up intersite transfer transactions, intersite purchase orders or transfer orders, for inventory flow between sites, including intercompany accounting if the sites also represent separate legal entities.
- 5If using separate databases per site, plan the integration layer, ION BODs in CSI or custom integration on-prem, for whatever master data genuinely needs to stay synchronized, rather than assuming it will replicate automatically.
- 6Test cross-site reporting early; consolidated reporting behaves differently depending on whether you chose single-database or multi-database, and this is the requirement most often underestimated during planning.
- 7Pilot the new site with a small, real transaction set, a handful of orders and receipts, before full cutover, and confirm APS/MRP planning correctly respects site boundaries so demand from one site does not consume supply intended for another.
Single database vs separate database per site
A single database with multiple Site records is simpler to administer and supports sharing item, customer, and vendor master data natively, but every site is tied to the same SyteLine version, upgrade schedule, and downtime window. Separate databases per site give each site independence for upgrade timing and data residency, at the cost of building and maintaining an integration layer to keep shared master data consistent across them.
Intersite transactions and intercompany accounting
When inventory physically moves between sites, that movement is recorded as an intersite transfer order or intersite PO/SO pair rather than a simple inventory transaction, and if the sites represent different legal entities the intercompany accounting setup, due to/due from accounts, transfer pricing, needs to be configured before the first real transaction, not discovered afterward during month-end close.
Master data strategy: shared vs site-specific
Deciding which master data is truly global, a part number should mean the same thing everywhere, versus site-specific, a customer that only ever orders from one site, or site-specific item costing, up front avoids a painful cleanup project later. Get finance and planning involved in this decision, not just IT, since it affects costing, consolidated reporting, and how MRP and APS treat supply and demand across sites.
Multi-site reporting and BI
Consolidated cross-site reporting is straightforward when everything lives in one database, but requires an explicit consolidation strategy, a SuiteAnalytics-style connect, a data warehouse, or ION Data Lake in CSI, when sites are on separate databases. Plan this as part of the initial rollout rather than retrofitting it once site two is already live and finance is asking for a combined P&L.
Common pitfalls
- !Treating multi-site as a purely IT decision and discovering after go-live that finance needed shared chart of accounts or consolidated reporting the chosen architecture does not support well.
- !Not scoping user site security properly, so staff can post transactions against the wrong site.
- !Underestimating the integration effort required to keep item and customer master data synchronized across separate databases.
- !Letting APS/MRP planning parameters default in a way that lets one site's demand consume another site's supply unintentionally.
- !Skipping a real pilot with live-like transactions before full cutover, so intersite accounting issues surface for the first time during month-end close.
- !Assuming intersite transfers behave like a normal warehouse-to-warehouse transaction instead of setting up the correct intersite transfer or PO/SO pair and intercompany accounts.
How an ERP-grounded AI assistant handles this
For a multi-site rollout, ERPray can answer which IDOs and tables currently treat this master data as global versus site-specific by inspecting the live data dictionary, rather than someone manually checking each IDO's site-scoping property, which materially speeds up the master data strategy decision. Once live, it can also field why did this order pull supply from the wrong site questions by tracing the actual APS/MRP allocation instead of a planner reverse-engineering it screen by screen.
Frequently asked questions
Can we add a new site without downtime to existing sites?
In a single-database multi-site setup, adding a new Site record does not require taking existing sites offline, but any customization or integration testing for the new site should still happen in a non-production environment first, since a misconfigured new site can affect shared master data seen by every site.
Do intersite transfers automatically handle intercompany accounting?
The transfer transaction itself is supported natively, but the due to/due from GL accounts and transfer pricing setup have to be configured correctly for each site pair beforehand; the transaction posts to whatever accounts are configured, right or wrong, so verify the setup with finance before go-live.
Is a separate database required for sites in different countries?
Not necessarily for SyteLine functionality itself, but data residency regulations, differing fiscal calendars, or a desire for fully independent upgrade schedules are common reasons sites choose separate databases even when a single database would technically work.
How does APS handle multiple sites?
APS scheduling generally runs per site against that site's resources and constraints, so supply and demand at one site normally does not cross into another site's schedule unless intersite supply relationships are explicitly modeled, which is worth validating during setup rather than assuming.
What is the biggest planning mistake in multi-site projects?
Deciding the database architecture, single vs separate, based only on the initial two sites without asking how many sites, and how different from each other, the company expects to have in three years; that assumption is expensive to reverse once the first site is live on real transactions.
Related
How to Tune APS Finite Scheduling Performance in SyteLine
A slow APS run in SyteLine is almost always caused by an oversized planning horizon, too many resources marked as constrained, or an unindexed staging table, rather than the scheduling algorithm itself. Trimming the horizon, scoping constrained resource groups, and running incremental instead of full regenerative schedules typically cuts run time dramatically.
AdvancedHow to Improve SQL Server Performance for a Slow SyteLine ERP System
Most SyteLine performance complaints trace back to a handful of SQL Server issues: stale statistics, missing indexes on high-churn IDO tables, blocking caused by the default isolation level, and IDO Runtime connection pool exhaustion. Working through those systematically, with DMV evidence, resolves the majority of slow system tickets faster than guessing at application-layer causes.
AdvancedHow the SyteLine Event System Works for Workflow Notifications
SyteLine's Event Manager lets administrators subscribe to IDO-level events, such as a purchase order being released or a customer credit hold being set, and fire an email, a Mongoose script, or a workflow action without writing an IDO extension. Cloud tenants can extend the same triggers into ION Workflow for multi-step, cross-application approval processes.
AdvancedHow to Add Custom Business Logic to a SyteLine IDO with an Extension Class
SyteLine lets you add validation, defaulting, and side-effect logic to any IDO without touching Infor's generated code, by writing an IDO extension class in C# and hooking into the object's Before/After events. The extension assembly is compiled, deployed next to the IDO Runtime, and picked up once the runtime cache is refreshed.
Error fixFixing SyteLine's 'Object reference not set to an instance of an object' error
This is a generic .NET NullReferenceException surfacing through the SyteLine IDO Runtime, not a SyteLine-specific error code. It almost always means a form, script or IDO method referenced a field, row or object that came back null, usually after a customization, a missing related record, or a view/IDO method call before the form finished loading. Turn on detailed client logging and check the most recent customization or form event first.
Error fixDiagnosing and fixing SyteLine session timeout errors
SyteLine session timeouts come from one of three independent layers: the IDO Data Service session timeout on the app server, the IIS/application pool idle timeout for the web (Mongoose Web) client, or a load balancer/proxy idle timeout in front of a CloudSuite hosted environment. Fixing the wrong layer is the most common mistake - you need to identify which layer is actually expiring the session before changing anything.
AI for ERPOn-Prem AI for CloudSuite Industrial, Without the Multi-Tenant Cloud Move
Add generative AI to CloudSuite Industrial without moving to Infor's multi-tenant cloud. On-prem private LLM options for CSI, with governance and audit built in.
AI for ERPAI for Infor SyteLine and CloudSuite Industrial
Add grounded AI to Infor SyteLine or CloudSuite Industrial: natural-language answers, agents over IDOs and ION, on-prem or CloudSuite deployment.
Stuck on Infor SyteLine (CloudSuite Industrial)?
Talk to engineers who work inside Infor SyteLine (CloudSuite Industrial) every week, and who build private AI that answers these questions from your own ERP data.