When you order a BAS enhancement, the contractor rarely asks how exactly to implement it. And that's a mistake: this choice affects not only the cost of the enhancement itself but also the cost of all subsequent updates. The difference can amount to hours each month throughout the system's lifetime.
Let's analyze both paths so that you can ask the right questions before starting the work.
Two roads for one task
Let's imagine a common task: a printed form is needed that is not available in the standard configuration. It can be implemented in two ways.
The first way is an extension. The programmer creates a separate extension file (.cfe), in which only the new form is described. The standard configuration remains untouched, as if no one has approached it.
The second way is changing the configuration. The programmer opens the standard configuration in the configurator, removes the necessary object from support lock, and writes code directly into the program body.
The result for the user is the same: the print button has appeared, the form works. The difference lies in what happened to the program itself.
What is "vendor support"?
The standard BAS configuration is supplied under the developer's support. This means that the program knows: this object is standard, its author is the vendor, and when a new release comes out, it will be updated automatically.
When you change an object in the body of the configuration, you are essentially stating: "I am now responsible for this piece." The object is partially or completely removed from support. The program can no longer update it on its own because it does not know which of your changes need to be preserved and which can be overwritten.
Key thesis: deprecation — is not a failure or a mistake. It is the transfer of responsibility for a part of the code from the developer to you.
How it feels during an update
This is where choice turns into money.
Updating the typical configuration. Standard procedure. Comparison, application, verification. Time-predictable and almost risk-free.
Updating the configuration with changes. The procedure turns into separate work:
- compare the changes of the new release with your modifications;
- determine if the release affected the same objects you modified;
- transfer and adapt the code where conflicts arose;
- test the modified functionality;
- check related documents and reports;
- transfer changes to the working database.
The main issue here is not the volume, but the unpredictability. If the release affected the same mechanisms as your modifications, the work may take significantly more time than planned. And regulated reporting must be updated on time, regardless of whether it is a convenient moment or not.
Updating the database with an extension. Follows the standard procedure. The extension needs to be checked after the update, but it lives separately, and in most cases continues to work without edits.
Why extensions are cheaper to own
| Extension | Configuration change | |
|---|---|---|
| Configuration under support | Yes | Partially or completely no |
| Update procedure | Standard | Separate work every time |
| Predictability of update costs | High | Low |
| Risk of conflict with the new release | Low | Increases with each enhancement |
| Separation of your code from the standard | Complete | None |
| Ability to quickly disable the enhancement | Yes, with one switch | No, work in the configurator is needed |
| Transfer of the system to another contractor | Simple | Complex |
The last line should be read carefully. The extension is essentially documentation of your changes: it shows what exactly and where has been changed. In the configuration with changes, the new contractor will first have to compare your base with the standard to understand what they are dealing with. This is time that you will pay for.
When the extension is not suitable
It would be unfair to claim that the extension solves everything. There are tasks where it is difficult or unjustifiably expensive to do without changing the configuration:
- deep reworking of standard mechanisms — for example, changing the logic of document processing at a level where the extension would have to redefine half of the module;
- old configurations, where the extension mechanism is implemented limitedly;
- large-scale industry enhancement, when the accounting model itself changes, not just individual sections;
- bases that have long been discontinued — here the discussion is often pointless, the configuration has already been changed by previous contractors.
In the last case, there is a separate solution: to return the database to support. This is a standalone project — to transfer existing modifications to an extension, update to the current release, and then maintain the system according to standard procedures. The work is one-time, but it pays off in updates, especially if the database is planned to be used for years.
Questions to ask the contractor
Before agreeing to the modifications, ask:
- How exactly will the modification be implemented — as an extension or a configuration change? An answer of "as it turns out" means that this has not been thought through.
- If we are changing the configuration — which specific objects are being removed from support? The list must be specific.
- How will this affect the cost of future updates? The estimate may be approximate, but it must be provided.
- Can the task be solved with an extension, even if it is a bit more expensive now? Sometimes a difference of two hours at the start saves dozens of hours over the year.
- In what form will I receive the modification? A .cfe file or a configuration comparison file — this is your asset that you can transfer to another contractor.
Our position
If the task can be technically solved with an extension, we choose the extension. Even if it takes a bit longer during the development stage.
The reason is simple: we see the system not at the moment of delivering the modification, but over the years of maintenance. A database that has been changed in the configurator every few months for five years turns into a system where each update of regulated reporting becomes a mini-project with unpredictable timelines. Moreover, this hits the client the hardest precisely when there is no time — during the reporting period.
Therefore, in our tariffs for configurations that have been removed from support, there is a surcharge to the subscription fee, and code adaptation during updates is assessed separately. This is not a penalty, but a reflection of the actual volume of work: such a base truly requires more attention.
Briefly
- Extension leaves the configuration under support, updates proceed as standard, your code is separated and documented.
- Changing the configuration removes it from support, and each subsequent update becomes a separate job with unpredictable costs.
- Each modification in the body of the configuration increases the cost of all subsequent updates — the effect is cumulative.
- There are tasks where changing the configuration is unavoidable, but this should be a conscious choice, not a consequence of what was quicker for the programmer.
- A base that has been removed from support can be returned to support. This is a separate project that pays off with updates.
If you do not know the state of your configuration, start with an audit: we will look at which objects have been removed from support, how many modifications are in the base and in what form they are implemented, and we will tell you whether it makes sense to return the system to support.