This is how the Vertec architecture is structured
Cloud Suite
On-Premises
When working with Vertec, you don’t necessarily have to be interested in the underlying architecture, but for a deeper technical understanding, it’s important to know the underlying design decisions.
Vertec is designed as a multi-tier application and strictly separates data storage, business logic, and presentation. The database is pure data storage. All business logic (business logic) lives one layer higher, on the application server. And the user interface, the so-called UI, then represents the data.
Each layer has a clearly defined role – and only the business logic layer is allowed to access the database. The database assumes a deliberately passive Role: It saves structured data, but does not compute anything or enforce business rules – that is the business logic layer’s role. This separation is not a coincidence; it is the architectural foundation on which the entire consistency and reliability of the software rests.
The business logic in Vertec is object-oriented. Each class – an invoice, a project, a service – carries its own logic. An invoice, for example, calculates its VAT itself. A project knows its budget status. This encapsulation ensures that calculations are performed consistently, regardless of which client or API is accessed from.
This is supplemented by so-called Derived Attributes: calculated fields that are not saved in the database, but determine their value at run time and subscribe to all relevant dependencies. If an input value changes, all affected derived attributes are automatically recalculated, providing added value for use in List Settings or Scripts.
For a more technical description, see Vertec objects, persistent storage and connection to the ui.
The design principle has another crucial advantage: Because all clients use the same central business logic on the application server, they behave identically. Whether someone works via a Cloud App, a Web App, or a mobile Phone App – the rules are the same, the calculations the same, the validations the same. There are no “different results depending on the client.” And with Notif technology, all changes on one client are transported directly to all other clients. See also the section Save / Update Data data.
Access in Vertec is never directly to the database. The database is not an entry point – it is a pure data store. It saves structured data, but does not compute anything or enforce business rules. This is the job of the business logic layer. Access is therefore always through the business logic – even for OCL and SQL within the system.
On-Premises customers host their Vertec database locally and could theoretically access it directly. But this must not be done, because, as explained above, Vertec strictly separates data storage from business logic. Bypass this separation risks inconsistent data – and a system that no longer understands itself.
In addition, customer-specific rules can be implemented via Scripts on events, which are triggered, for example, when a field is saved or exited. This logic is an integral part of the data flow – and is also skipped during direct database access.
Separating data storage from business logic is not just a technical design decision – it is a functional necessity. The database alone does not know business rules. It does not know which fields depend on each other, which calculations must be triggered when a change is made, or which customer-specific validations apply.
For example, if an invoice amount is written directly to the database via SQL without going through the business logic, the automatically calculated sequential values – VAT, project budget progress, billing status – may be missing. The data looks consistent on the surface, but it is not. Vertec don’t know anything about this change in context the next time it queries the application server.
It is technically tempting to perform complex evaluations or data mutations directly from SQL queries on the database, but this requires knowing and replicating all Vertec object logic, derived attributes, and event scripts – an intolerable risk that sooner or later leads to data loss or inconsistency.
At the same time, this structure allows for customer-specific adjustments to the business logic to be implemented only once – and apply immediately to all users and all platforms. No parallel maintenance of logic in different layers or clients.
Vertec is a consistently multi-layered business software. The database is deliberately designed as a passive data store – the entire intelligence of the system lives in the business logic layer. Anyone who bypasses this layer, for example through direct database access or replicated SQL logic, leaves the secure area of the system. The result is not harmless deviations, but quiet inconsistencies that often show up late and are difficult to understand. The only valid way to work with Vertec data is through the application server – and thus through the business logic.
There is no save button in Vertec. This is because data is not simply “saved” in the database, but is processed by the business logic. This not only ensures that the entered data is backed up in the database, but also all data depends on it. A value arrives in the business logic as soon as the changed field is left.
When different users are working on the same data objects, it is important that they each have the current state of the data. To ensure this, Notif technology is available, which allows automatic reconciliation of data across all sessions and apps.
Each Vertec session and app that is launched connects to the Cloud Server and sends all changes made to it. Notif then notiftif notifies each client when another client has changed data. The client then has the ability to reload the current version of the data. The network load of Notif is low because it only transmits information identifying the changed data, not the data itself. By default, Notif has a latency of 10 seconds for reporting changes. This means that changed data on one client arrives on the other clients in 10 seconds.
There is also no undo button in Vertec. This is because in Vertec, there are not simple changes that can be undone, like in a Word, but behind a lot of changes is business logic that runs, even customer-specific ones, in event scripts. Every feature would have to implement a “reversible” and every step in the business logic would run backward. This is not possible.
However, changes can also be tracked afterwards with the Audit Trail. Even without the “Undo” option, the previous state is not simply lost. The additional feature Audit Trail Object History brings the object history directly to your Vertec surface.
Also, the representation of the data on the user interface, i.e. the top layer of the model, always accesses the business logic and does not simply show “fields in the database”. As explained above, this structure allows for customer-specific adjustments to be implemented only once at the user interface – and apply immediately to all users and all platforms. No parallel maintenance of logic in different layers or clients.
Thus, the interface of full-featured Apps is always the same – once adapted, it automatically appears the same everywhere in the Cloud App, the Web App and the Desktop App. Unlike the specialized apps: the Phone App and the Outlook App have fixed interfaces that cannot be customized by the customer.
If a new entry is created, there are certain fields that must be filled in depending on the object in order for it to be valid. For example, a service needs an hour (time spent), a project needs a code, an address needs a name, so that they can be used and assigned meaningfully in Vertec. This is described in detail in the article Validity / status of entries. These are mandatory fields required by Vertec.
Constraints can also be used to create customer-specific validity conditions. Here, it is important to ensure that only persistent (i.e. not calculated) data fields and no associations (i.e. links to other objects) are checked, as this can lead to a significant performance loss. For checking such conditions, other means are suitable, for example checklists via Sql folder or Expression Folder.
In Vertec, there are values that “inherit” their value within a hierarchy (Cascading Attributes). Each value within the hierarchy inherits the value from the object above it. At each level, it is possible to overwrite the inherited value and thus fix it for that level. The child values then inherit this overwritten value as well.
Cascading attributes represent their value either in black (value is inherited) or in green (value is overwritten at this level). Example are the rate of services or the determination of a payment type.
If you want to delete a fixed value and thus inherit it again, you can simply delete the value in green font. The value then appears again in black and is thus inherited again.
Then there are values that aggregate upwards, i.e. are summed up at a higher level. An example of this is budget values from activityphaselinks to phases to project.
Such attributes are always derived, i.e. derived Calculated Data Fields (Derived Attributes) that calculate their value at run time. If a value is fixed at a level, the so-called x-value is described. Example of a service: ansatzext is derived, xAnsatzext is fixed.
Each object in Vertec is linked to other objects, e.g. an address as a customer of a project, an user with its services, etc. Links These, called Associations, are specified by the Vertec model and therefore automatically exist. Wrapper Link Types make such built-in links visible on the interface, and the linked objects appear on the entries in a subfolder (link container), e.g. the services on an user.
a variety of wrapper link types are already included with Vertec – all the ones you need to work effectively with Vertec. Customers can also create their own wrapper link types to display associations of the model. The entire Vertec model can be viewed in the Vertec Model Browser.
Custom links between objects can also be defined. For this purpose, there are the Custom Link Types, with which you can set which objects can be linked as with other objects. An example would be the linking of people (as Board of Directors) with companies (as VR mandates). These can then be linked with each other via Drag & Drop. The presentation on the interface is the same as with the wrapper link types – the linked objects appear in a subfolder (link container).
For Navigation in vertec there is a tree view on the left, with which you can navigate through the folder structure like in an explorer. If a folder is selected in the tree, the list of objects located in that folder appears on the right. These objects can be opened by double-clicking in the single view. Also in the single view there is a tree on the left, so that you can navigate to the subfolders of the object. Customers can create their own Folder and adjust the existing folder structure.
For general search for Vertec data there is the Vertec Full-Text Search. If you are searching for criteria in certain objects, e.g. “all invoices of a year,” Sql folder are suitable, where specific search and filter fields can be created.
With the query language OCL, you can navigate through the entire Vertec model and query data at run time. The Ocl expression editor is available for this purpose. The Vertec model can be found in the Vertec Model Browser.
It is also possible to connect an external LLM (Large Language Model) to Vertec and use Vertec as an Llm client, with which LLM functionalities from different vendors such as OPEN AI, Anthropic or Google Gemini can be used directly in Vertec. It processes plain text, i.e. unstructured data (i.e. without model information), which is well suited for automated summaries or formulations within Vertec.
For external queries of Vertec data, Vertec rest api and Vertec mcp server are available, which allows Vertec to connect to AI applications from external systems, allowing AI clients such as Claude, Copilot or ChatGPT to connect to Vertec to query structured data as well as perform tasks in Vertec, such as creating new objects.
Due to the multi-layered design of the Vertec architecture, it is possible to adapt Vertec individually to meet different customer requirements.
The data structure and the existing business logic always remain in place. On this basis, you can “play” with the data on the Vertec surface. The simplest customization is in individual List Settings and the creation of your own Folder to group and display data.
The existing data can be queried as desired, via OCL, in Expression or in Sql folders, or in individual Office reports (word, excel, pdf). The creating of own classes (Additional Classes) and fields (custom Custom Field Items) is also possible.
You can “intervene” in the business logic via Python Scripts. This allows you to control actions, both triggered by the user (Scripts as menu items or via Button) and automatically by actions in Vertec (Scripts on events). This allows you to expand the functionality of Vertec as you wish.
It is very important for any customization that attention is paid to a high- high-performance access to Vertec objects as well as to traceability. Please also note our 10-Point Plan for a Sustainable Vertec Installation.
With additional features, which Vertec provides and maintains for free, additional, often industry- or country-specific features can be imported into Vertec, such as travel expense reporting in Germany or mandate management in Switzerland. The additional features are also pure Vertec customizing, but instead of having to create them yourself, they can simply be entered at the touch of a button. The advantage of additional features provided by Vertec is that they bundle many years of know-how and industry knowledge and are standardized (best practice). Since customizing is simply imported with the additional features, it can also be adapted or expanded if necessary.
Here you will find an implementation to Vertec Customizing.
Thanks to the Vertec software design, Vertec is also consistently updateable. Your adjustments remain with an update, because they “only” affect the interface, build on the existing business logic and the existing data structure, but do not change them.
When adapting the business logic, we always pay attention to backward compatibility, and in case of changes to the data structure, your Vertec database will be automatically converted to the new structure during the update. If backward compatibility cannot be consistently maintained or certain elements are discontinued in Vertec, this will be transparently announced in the release notes with sufficient advance notice. The release notes can always be found in the article of the current Vertec version.
There are two types of releases: Major and Minor Releases. The difference is that Minor Releases only affect the business logic and the interface. Minor Releases can be loaded at any time and appear at regular intervals about every couple weeks. Major Releases include additional adjustments to the data structure (e.g. when implementation fundamentally new objects), and the Vertec database is (automatically) converted. Major releases are released more frequently, about every 1-2 years, and are announced as “new Vertec version”. A major release always includes all minor releases in between.
By means of extensions, Vertec can be connected to third-party systems. Both outbound, e.g. to your accounting department, and incoming, e.g. for querying and controlling Vertec from outside, e.g. via Vertec mcp server.
The Vertec architecture also ensures that the business logic works when working with the extensions. Again, no data is read directly from the database or written to it via the extension.
a variety of extensions, named Extensions in Vertec, are included with Vertec. Here you will find All vertec extensions at a glance.
You can also create your own extensions and individual Web Services.