Entity is representing an object type, and is created through configuration. The main configuration of an entity consists of following elements:
The system has additionally the concept of a multientity. Multientities are entities that don't have a single source of data, only they are grouping several entities into one, summing the data from several single entities.
For example the entities phone call, task, request, appointment, meeting are by default grouped in a multientity called Activity, this allows us to see all activities in one list, but at the same time maintain the entity specific functionality and detail views.
Entities among others can be configured in the configuration logical module.
Logical modules are simply entities grouped together. The grouping way can be freely configured, and is most often based on the logical relationship between entities. Any entity can be in as much logical modules as configured.
We can say that logical modules is the top most part of the system, logical modules contain several entities, whereas the entities can have several functional modules assigned.
The logical modules described in this section are the standard ones, preconfigured out of the box in the platform. Obviously they can reconfigured, new logical modules can be added, existing ones can be changed or removed.
In this section we briefly explain the logical modules and entities that comes with the standard configuration. For more details feel free to contact us, as there is much more.
Logical modules are visible in the UI in the following way:
The My Work logical module is responsible to provide to the user the functionality which is mostly related with his day to day work. In a perfect configuration the user should be able to do about 80% of the needed by him functionalities from within this module, without the need for additional clicks by opening other logical modules, which should be used only in some cases.
In the default configuration the user can access following items from this logical module:
The contacts logical module aggegates all contact information stored in the system. Contacts can be divided on internal and external.
This logical module contains following entities:
The mails logical module is a mail client build into the system. It's based only on three main entities:
As we can see, in the logical modules there is a box structure indicating access to different account, the purpose of the structure is as follows:
Each account box has pretty standard and self explaining subboxes - New, Draft, Other, and under Other we have Done, Sent, Outbox, Junk, All correspondence
Because all email message of the user are within the platform, it encourages the user to register contacts and attachments in the system. Leading to a powerfull knowledge base within the a7 EBusiness Platform
Similarly the email itself can be converted in a task or request, and we can associate the message with an existing project, document and task, or we can create a new one in context of the message.
The activities logical module groups all entities and functionalities that are related to current activities of the user.
A sample of a custom functionality of a box is the Activity Overview box, which is related to the activities multientity, but doesn't display it in a standard list, only using a custom dedicated view implemented in the functional module implemented specific for the activities logical module.
Similarly cases, are still using the standard workspace view, allowing to view a preview view of the selected case. But the view of the list is custom, which allows a user friendly tree-like way to display the hierarchy of cases, which can be used to clasify among others the activity records.
It's also a perfect example usage of the multientity concept, a task or a request or a phone call etc. have different fields which are specific for those entities, but they share fields common for entities, like the owner, the case, the responsible person. So all those entities are grouped with the multientity activities. Any time we need a common functionality for all activities, be it the Activity Overview or associating an activity with a project, we can use the activity multientity, but when we want functionalities for certain entities, like a task or a request, we can use the functionalities of those single entities.
In the activities logical module the usage of the status module by the entities is very usefull and allows to track the activities easily. More about this in the status module section
This logical module covers basic CRM functionality, so leads, opportunities, mailing lists, products, invoices etc. Thanks to the existing mail integration, it's possible to create and send mailings directly from the system. And because of the existing MS Office integration, we can easily configure our custom invoice templates and generate them with prefilled data from the system.
The sales logical module is thought for the sales team and has entities that encourage to use following workflow on the sales process:
Lead -> Opportunity -> Offer -> Contracts -> Client
However the standard configuration for this module is pretty basic, as CRM systems tend to be highly customised, as organization needs vary a lot when it comes to relationships with customers. We don't want to impose any right way to do CRM.
By using the standard file templates and office integration modules, together with the documents logical module, we can easily create sales documents. More about this in the file template module section.
The document logical module contains entities that present in the standard configuration the functionality of a standard document management system.
That is, we can store in a centralized file server files and describe them with metadata on the entity records. We can then set statuses for all document, perform versioning on them, and create relations between documents and entities from other logical modules like for example activities or contacts.
The most standard functionality is contained in the document entity, however, with the standard configuration there are more specific entities, like Contracts, Offers, Letters or Outgoing Invoices, those contain more specific metadata for this type of documents.
All the document related entities are grouped with the All documents multientity were we can find besides standard documents also contracts, letters and so on.
All documents can be grouped in Folders, based on which we can granularly set up our security settings, so which user what type of access should have to the documents repository.
All files are stored in a centralized file repository, when the user wan't to open or download a file, it gets downloaded to his local machine, and a link between the local file and the file on the repository is created, that allows the system to take care about synchronizing the contents of those files. More about this in the file module section.
Based on the file template module we can generate documents with prefilled data from the system on prepared file templates. More about this in the file template module section
In case of document related entities the version module comes very handy, allowing for even sophisticated versioning of documents, altough the logic can be simplified through configuration. More about this in the version module section
The ticket sales logical module was originally created as a dedicated system for a railway company. To allow generate reports, monitor and maintain their ticket distribution network.
The tickets were sold on two channels, POS devices used by sales agents, and ticket machines.
The first main functionality of this logical module is monitoring the devices of the sales network, the POS devices were working offline and sending sales records on time intervals to the central database in configured time intervals when a GSM network was available. The ticketmachines worked online and were connected with the system through a SOAP based web service.
The second main functionality was carrying out settlements with sales agents which were using the POS device.
The third main functionality was sales analysis of the network. In that regard the aggregation functionality of the system became very useful in analysis of the sales records allowing to look at the data from different angles. More about aggregation in the data aggregation section
Based on the sales records send to the database from the devices, the user can generate reports for the sales agents with invoices.
This logical module is self explaining, it contains all entities which contains dates, and displayes them using a calendar UI control.
Each entity can be configured to be displayed on the calendar, and the field can be configured which should be used to determine where on the calendar the record should be displayed.
By default activities and reminders are displayed in the calendar.
The support logical module is thought for the support team and has entities that encourage to use following workflow on supporting customers:
Phone Call -> Complaint -> Request -> Task
Similarly to the sales logical module, this module is small in the standard configuration, as organizations differ in handling the support. So it's highly recommended to customize this module to the organizations needs.
The configuration logical module is divided in two main parts, security and configuration.
The security part should be handled by trained staff and/or administrators in scope of security of the settings. More about security in the security section.
The main configuration part allows for customization of the system, from simple things like changing a fields label or status transitions, through adding a new field to an object, to more sophisticated system changes like creating new relations and functions.