PLANTA customizer
General Information
General Customizing Information
Information
- The PLANTA customizer allows PPMS to be structured to represent processes specific to a business, with adaptations ranging from the terminology used through the definitions of user roles up to the creation of interfaces.
- It is distinguished between marking and activating data fields:
- The Module Customizer enables PPMS menus and modules to be created and modified specifically for particular roles and users.
- Module customizing is not about simple modifications, like the module customizing, but about substantial changes to the PPMS System.
Structure of the Module Customizer
Data structure
- PLANTA project records are edited in data fields of the modules.
- A module consists of data areas.
- A data area
- corresponds to a data table.
- consists of data fields.
- A data field corresponds to a data item.
- A Data item belongs to a data table.
- The data items of a data table form the record.
Module details
- A module
- must have at least one data area assigned to it,
- can have any number of data areas assigned to it.
- A data area
- can be used multiple times, i.e. assigned to many modules.
- must have at least one data item assigned to it as a data field.
- can have any number of data items assigned to it as data fields.
Reflection database in module
Important Terms of the System Customizer
Term |
Explanation |
Data Dictionary |
Contains all information on the data model. - Together with the data tables and their relations, data items form the PLANTA Data Dictionary.
|
Data tables |
Name for a collection of similarly structured data that is usually technically stored together. %ICON[stop}% New data tables must not be created by the customer’s system customizer, but only by PLANTA, i.e. the existing tables must be used. |
Relations |
They contain the relationships between data tables. There can be a maximum of 31 relations for a data table. These cannot be modified by the customizer. - Example:
- Project and task are in a 1:n relationship, i.e. a project can have n tasks, and a task can only belong to one project.
|
Data item (DI) |
PLANTA name for the smallest logical data object.- Examples for the Project data table:
- DI 001001 Project ID
- DI 001061 Customer
- Besides real data items in which data is saved physically, there are also virtual data items in which no data is saved physically. Their values are calculated online from other data items or are components for complex data items.
- Complex data items are virtual data items that are composed of several sub-DIs.
|
PLANTA Database Schemas
System Databases |
Name |
Description |
System |
Q1B |
Here, the system data is saved |
Customizer |
Q2B |
Here, the customizing data is saved |
Persons |
Q3B |
Here, the person data is saved |
User databases |
Name |
Description |
Persons |
Q3B |
Here, the person data is saved |
Project and portfolio management |
Q5B |
Here, the project and portfolio management data is saved |
Request management |
Q6B |
Here, the request management data is saved. This database schema is only required by customers with older releases who use request management. PLANTA no longer offers a request management component. |
User database |
Name |
Description |
User database |
K[License number] |
Contains individual data tables. |
To be Considered
Attention
- You can change the entire PLANTA system using the PLANTA customizer.
- If used improperly, it can also lead to a loss of data or destruction of the PLANTA system.
- If used properly, the flexibility of the Customizer enables the configuration of the PLANTA system to be completely adjusted to individual requirements.
- It is important to always performed a data backup before customizing.
- System customizing can make basic changes to the functionality of the PLANTA system and can even destroy them. Careful project planning and data backup are essential before starting to carry out the work.
- The entire PLANTA functionality is stored in the data tables of the Q1B – Q3B databases. If a change that is destructive to a function is carried out at a crucial point, a possible consequence may be, in extreme cases, that the PLANTA system can no longer be opened. If no data backup is available in such a case, all customizing information will be lost and a completely new installation required. The contents of the Q1B, Q2B, and Q3B databases can only be changed using PLANTA itself.
- In doubtful cases, it is preferable to consult PLANTA before undertaking any measure.
- The Q1B, Q2B, and Q3B databases are application-independent. They are required by the system customizer in order to process the Q4B – Q7B databases.
- In the Q1B, Q2B, and Q3B databases, customizing is not permitted.
- This means that it is not permitted to customize the Customizer.
- It is recommended that only trained personnel is given the right to carry out customizing.
- If you make individual changes to your PLANTA system, you have to keep an eye on the update safety of your system. For this purpose, see the Individual Customizing and Update Safety topic.
Treatment of NULL in the Database
Date and Numeric Fields
Information
- In order to improve the performance,
- all numeric fields in the database should receive a NOT NULL constraint and a standard value 0. Otherwise, when filtering, the
NVL(, 0)
function will be used in the case of Oracle, or ISNULL(, 0)
for SQL Server.
- all numeric fields in the database should receive a NOT NULL constraint and a standard value 1970-01-01. Otherwise, when filtering, the
NVL(<field>, TO_DATE('01.01.1970', 'DD.MM.YYYY')
function will be used in the case of Oracle, or ISNULL(<field>, CONVERT(DATETIME, '01.01.1970', 104)
for SQL Server.
- Here, it is important that the setting in the database and in the customizing are equal. This means that the SQL data item (a bit field) in DT412 Data Item must reflect the actual status in the database.
- For this purpose, the first bit must be set if a NOT NULL constraint exists. This corresponds to the values "1" or "3".
- Otherwise it must not be set. This corresponds to the values 0 to 2.
- According to the settings in the customizing, not to those in the database, comparison operations sometimes fail on these fields, records that contain NULL here are excluded from the result, or negative impact on the performance as a result of the functions mentioned above can be expected without deriving any benefits.