In Business Intelligence as in real life, everyone is different, has his or her own ideas, needs and requirements. A software that supports controlling sustainably has to take this into account - you can't lump everything together. On the other hand, if you take a closer look and break down the overall requirement into individual parts, it becomes clear that it is recurring components that are necessary.
Like the whole world can be decomposed into atoms and their combinations (a piece of carbon consists of the same atoms as a diamond, only the arrangement is different), applications in CoPlanner are created from a finite set of different objects. The CoPlanner framework provides these: tables, dimensions, hierarchies, masks, shapes, SQL scripting etc. The combination of these elements can cover (almost) every imaginable requirement. The structuring of the requirement must specify a calculation path for how data is to be processed. Even if - current hype - self-learning systems are to be implemented, a specification must be made as to what is to be achieved and how.
Creating solutions from these elements is not difficult, but you will save time if basic functions are already available as building blocks that can be reused. These building blocks then provide a basic framework to create applications faster. In every project we attach importance to identify such elements and, if such a building block does not yet exist, to extend the building set by another facet. A few randomly selected examples of such building blocks:
A workflow is a predefined path, regardless of whether it requires several release levels or not, whether the workflow criterion is the user, the cost center, the customer group, something else or a combination of several of these criteria. Thus, we have abstracted the "workflow" module from concrete customer models as a generic module: A workflow is a collection of tasks which are to be presented to the user according to his rights and the process situation, whose execution is monitored and which can process a status and sequences.
An object that links quantities and prices to calculate a monetary amount can be found in almost every BI project. Be it sales planning (quantity * price = sales), production planning (quantity to be produced * raw material quantity * price = cost of goods) or personnel planning (months * salary = annual salary) - it can be traced back to a basic function. This performs the calculation, ensures the correct aggregation (weighted average for prices!) and allows alternative entry: Entry in price, in sales and also in quantity should be possible and the data should still be consistent.
The question of whether a measure may be added for the year as a whole or whether a (weighted) average or the key date amount should be used for the annual value arises again and again - once properly implemented as a building block, this can be used in various application scenarios (balance sheet, headcounts).
The application of a seasonal distribution is trivial at first glance - it becomes somewhat more complex if the sample seasonal distribution and the period for which it is to be applied differ. If we have defined the seasonal distribution for 6 months (e.g. a project intensity curve), how do we apply this pattern to a period of 11 months instead of 6 months? A project from the mechanical engineering sector led to the fact that we have the corresponding module.
A concrete application insists on the combination of these (and other modules) so that the functionality of the target application is fulfilled (for example a planning application, a contract management, a travel expense report etc).
For some applications, the degree of freedom of the requirement is less, namely when the logic and functionality is externally or technically specified. An obvious example is legal consolidation, which must basically function according to the specifications of the legislator, or financial planning, where the connection between the profit and loss statement, cash flows and the balance sheet must be made according to generally accepted rules.
Therefore, CoPlanner offers prefabricated modules as functional modules: a predetermined combination of building blocks that solve the requirements in their interaction:
Assemblies and modules are not static - they can be adapted to individual requirements using the objects of the framework. However, they remain compatible with each other, analogous to a Lego building set, with which the new generation produces the most varied results from the same basic population.