So now you have created a small-sized applied solution that automates operations at Jack of All Trades maintenance company. And here comes the change-up pitch.
The staff at Jack of All Trades liked your applied solution so much that they told their neighbors at the Beauty Queen makeup studio about it. The staff at the studio saw how your applied solution works and then asked you to automate their operations as well.
Naturally, you were delighted to accept, for one simple reason: what you have created is a universal configuration, which is suitable for automation of almost any kind of service activities.
All that you need to do to adjust your confuguration for a makeup studio is simply create a new infobase with your configuration and populate it with new data, including employees, new services, and so on. All the accounting tools you have created are not tied to any specific features of a company so they can easily be used in any other company that has similar activities.
So, even if the makeup studio management wants you to add some new functionality, you can do it by editing just a few modules in your configuration. This is much more efficient that recreating an applied solution from scratch for this specific company.
But at the same time a makeup studio might not need some of the features that are already available in your configuration.
So what can you do? Do you have to delete unwanted configuration objects and script?
This can take a lot of time and effort. Real-life configurations can include a large number of configuration objects, which can refer each other in a complex way.
This is why 1C:Enterprise supports the functional options feature. Functional options serve for enabling or disabling functionality blocks during the deployment without changing the configuration itself.
Functional options allow developers to separate some applied solution functionality, so that it can be enabled or disabled during the deployment or at run time.