BAS/1C: Platform vs Configuration vs Information Base — A Diagnostic Protocol Before Automation

A request such as “We need to automate accounting in BAS” sounds concrete, but it often mixes three different technical layers:

1. the platform that executes the system;
2. the configuration that implements business behavior;
3. the information base where a particular organization’s application state and data live.

That ambiguity is expensive. A team can spend days modifying application logic when the real issue is a platform-version mismatch, migrate a database while forgetting configuration extensions, or test a feature on an information base whose settings do not match production.

Before estimating an ERP change, troubleshooting an incident, or planning a migration, identify which layer is actually involved.

The three layers

1. Platform: the execution environment

The BAS/1C platform is the runtime and development environment. It provides the mechanisms used by configurations:

• client and server execution;
• database access;
• metadata execution;
• managed forms and user-interface services;
• query and reporting engines;
• scheduled and background jobs;
• integration interfaces;
• security and session mechanisms;
• development, debugging, and administration tools.

The platform knows how to execute a document, register, report, or form. It does not, by itself, know what a goods receipt means for a particular company or which postings a sales document must create.

A platform issue usually affects mechanisms shared by many functions. Typical symptoms include:

• behavior changed after a platform update although the configuration did not change;
• the same configuration behaves differently on two servers;
• a client cannot connect because its version differs from the server version;
• background jobs fail across unrelated business processes;
• a database driver, cluster, web client, or integration transport behaves incorrectly;
• a language feature or platform API is unavailable in one environment.

The first diagnostic question is not “Which document is wrong?” but “Are all nodes executing the same supported platform build?”

2. Configuration: the application model

A configuration is the application implemented on the platform. It defines the metadata and code that express business behavior:

• catalogs and reference data structures;
• documents and their attributes;
• accumulation, accounting, and information registers;
• posting rules;
• reports and data-composition schemas;
• roles and access logic;
• forms, commands, and workflows;
• integrations and scheduled operations.

“BAS Accounting,” a trade-management solution, and a custom industry solution may run on the same platform while implementing completely different processes.

Configuration-related symptoms are normally repeatable in different information bases that use the same release and the same relevant settings. Examples include:

• a document produces an incorrect posting under a reproducible scenario;
• a report formula omits a specific register movement;
• an extension overrides a standard handler;
• an update changed metadata or business rules;
• a role cannot access a command that should be available;
• a custom integration fills the wrong document field.

The key question is: “Can the behavior be reproduced with the same configuration version and the same input conditions?”

3. Information base: a concrete operational instance

An information base is the working instance used by an organization or environment. It contains business data and the applied application state: documents, catalog entries, register records, users, settings, accounting policies, functional options, exchange states, and other instance-specific values. It also contains the configuration state deployed to that base.

Two information bases may nominally use the same configuration release but behave differently because their data, settings, extensions, permissions, history, or update path differ.

Information-base symptoms often include:

• the problem occurs only for one organization, warehouse, counterparty, or period;
• a report differs because filters, accounting policy, or functional options differ;
• duplicate catalog entries split balances;
• one document was posted before a required reference value was corrected;
• an exchange left partial or duplicated data;
• a scheduled job last ran successfully in one base but not another;
• production fails while a clean demonstration base works.

Here the key question is: “What data, settings, permissions, extensions, or history distinguish this base from the comparison environment?”

A concise Ukrainian explanation of the platform/configuration distinction is also available in this Stimul learning material.

A compact comparison

The layers interact, so the goal is not to assign blame prematurely. The goal is to establish the smallest layer where the observed difference begins.

A diagnostic protocol

Step 1: State the observable failure

Avoid descriptions such as “BAS is wrong” or “the report does not work.”

Record:

• the exact operation;
• the information base and organization;
• the user or role;
• the period;
• the input document or record;
• the expected result;
• the actual result;
• the earliest known occurrence.

A good incident statement is: “In the production information base, posting purchase invoice PI-1045 for Organization A on 31 October creates no VAT register movement, while the accounting posting is created.”

Step 2: Capture layer identifiers

Before changing anything, record:

• platform version on client and server;
• configuration name, release, and support state;
• enabled extensions and their versions;
• information-base identity and environment;
• functional options and accounting policy relevant to the scenario;
• user roles;
• last relevant update or migration;
• scheduled-job and exchange status.

This snapshot prevents a comparison between environments that only appear equivalent.

Step 3: Reproduce with controlled inputs

Use the smallest safe reproduction:

1. repeat the operation with the same document in a disposable copy or test base;
2. create a minimal equivalent document;
3. repeat under a known administrative or diagnostic role;
4. compare with another information base using the same configuration release;
5. compare on the same platform build where possible.

Change one variable at a time. If platform, configuration, data, and permissions all change simultaneously, the result proves almost nothing.

Step 4: Locate the first divergence

Follow the transaction chain rather than starting at the final report:

source evidence → document fields → validation → posting algorithm → register movements → balances → report query and presentation

The first incorrect state is usually closer to the cause than the final visible symptom.

• If document fields are wrong, investigate input, defaults, integration, or reference data.
• If fields are correct but movements are wrong, inspect configuration logic and settings used by that logic.
• If movements are correct but balances differ, inspect period boundaries, dimensions, duplicates, or later corrections.
• If balances are correct but the report is wrong, inspect report parameters, query logic, access restrictions, and presentation rules.

Step 5: Classify the layer using counterfactual checks

Ask what would have to remain unchanged for the failure to disappear.

Platform hypothesis

• Does switching only the platform build change the outcome?
• Do unrelated operations fail through the same runtime mechanism?
• Do logs show a platform, cluster, driver, or client/server error?

Configuration hypothesis

• Does the same input fail in another base on the same configuration release?
• Did a release or extension change the responsible metadata or handler?
• Can the problem be reproduced with clean reference data?

Information-base hypothesis

• Does the issue disappear in a clean base with the same platform and configuration?
• Is the failure limited to particular data, settings, users, or periods?
• Does correcting a reference value or policy remove the discrepancy without code changes?

Keep more than one hypothesis alive until evidence eliminates it.

Worked scenario: document to report

Suppose a supplier invoice is visible in the document journal, but the supplier balance in the trial balance is lower than expected.

1. Verify the report

Check the period, organization, account, currency, and analytical filters. If correcting a filter fixes the result, this is primarily an information-base or user-parameter issue, not a posting defect.

2. Drill down to movements

Open the report line and identify the registrars that form the balance. If the invoice is absent, inspect whether it is posted and whether it belongs to the selected organization and period.

3. Inspect the source document

Compare the source invoice with entered fields:

• counterparty;
• contract;
• organization;
• posting date;
• amount and tax;
• settlement account;
• operation type.

Assume the contract was accidentally assigned to a duplicate counterparty record. The document is posted, and the configuration executed exactly as designed, but the balance appears under another analytical dimension.

4. Classify correctly

This is not automatically a configuration bug. The platform executed normally. The posting algorithm used the document’s selected analytics. The first divergence is the information-base data: duplicate reference entries and an incorrect document selection.

5. Correct and verify

Use the authorized correction process:

1. select the correct counterparty or contract;
2. repost the document;
3. confirm the expected register movements;
4. regenerate the report with identical parameters;
5. ensure unrelated balances did not change;
6. add a control to prevent or detect duplicate reference entries.

Changing report code would only hide the data-quality problem.

Implications for rollout and testing

Layer separation should shape the deployment plan.

Platform changes

Test:

• client/server version compatibility;
• cluster and background-job behavior;
• web and thick/thin client paths;
• database-driver compatibility;
• performance-sensitive operations;
• external components and integrations.

A platform rollback plan is different from an application rollback plan. Record the exact build and infrastructure prerequisites.

Configuration changes

Test:

• metadata migration;
• posting algorithms;
• permissions;
• extensions and overridden handlers;
• standard and customized reports;
• integration contracts;
• update behavior on a production-like copy.

Use scenarios based on business outcomes, not only “the form opens.”

Information-base changes

Test:

• data conversion and reconciliation;
• opening balances;
• reference-data deduplication;
• organization-specific settings;
• scheduled jobs;
• exchange checkpoints;
• access rights;
• totals before and after migration.

A configuration that passes on a clean demonstration base may still fail during rollout because production contains years of history and exceptional states.

A pre-estimation checklist

Before estimating an automation task, answer:

• Which platform builds are in scope?
• Which configuration release and extensions are actually deployed?
• How many information bases and organizations are affected?
• Is the requested behavior standard, configurable, or custom?
• Which data and policies drive the decision?
• What is the first incorrect state in the transaction chain?
• Can the issue be reproduced outside production?
• Which layer must be changed?
• Which other layers must only be regression-tested?
• What evidence will prove the result after deployment?

If these questions are unanswered, the estimate is mostly a guess.

Conclusion

Platform, configuration, and information base are not competing names for one system. They are interacting layers with different responsibilities, evidence, failure modes, and rollback strategies.

A reliable diagnostic process starts with an observable discrepancy, captures the identity of all three layers, follows the transaction from source evidence to report, and locates the first divergence. That discipline prevents unnecessary customization, makes tests more meaningful, and turns “the ERP is wrong” into a small set of verifiable technical hypotheses.

Disclosure: AI assisted with drafting and editing; the final structure, technical claims, examples, and publication were reviewed by a human.