The documentation from version 39.5.17 of PLANTA project can be found in the new PLANTA Online Help

CurrentEN Web>CustomizingDocumentation>CustomizingModules>GlobalSettingsMOD009ABF

Global Settings MOD009ABF
- Classes
- Special Parameters
  - General
  - Application

Global Settings MOD009ABF

Access path

Customizer Module Customizer Modules Global Settings
Customizer Master Data Global Settings

Information

In the Global Settings module, customizing objects are stored/managed
- which can, e.g., be used in different Python macros and/or value ranges (like modules, OLEs, etc.) to ensure that they can easily be interchanged system-wide.
- the settings of which (in the case of parameters) are to apply system-wide.
When you open the module, all global settings are displayed categorized by classes (object category).

Module Variants

For each class, there is a module variant of the same name. When you open the module variant, only global settings of this class are displayed.

Attention

Global settings cannot be deleted. Records that have been created unintentionally or that are not required anymore can be reused for a new global setting.

Classes

For the categorization of global settings, the so called classes are used in this module.

Classes: Module ID, Dialog message ID, OLE object, Parameter, Startup module ID

Information

The following procedure exemplifies how to store a module ID in the global settings. The procedure for other classes is the same.

Store ID in global settings

Select Insert Global Settings from the context menu.
Select the requested class in the Class listbox, here "module ID".
Enter the module ID in the Alpha (120) field.
Define a Python ID in the Python ID field.
If required, fill other fields.
Save.

Read ID from global setting

from ppms import ppms_cu
mod_id=ppms_cu.Helper.get_global_setting("python_id").alpha120.get_value()

Details

The ppms_cu Python module is imported in order to be able to use the get_global_setting() method of the Helper class.

Notes

Python IDs must be usable as Python literals. They must not contain blanks, umlauts, special characters, etc.
Python IDs must be defined uniquely in the global settings.
Individual Python IDs must start with an L and the license number.
- Example: L100_pr_datasheet
- If the customizer does not set this manually, the system will set it automatically.

Classes: Module variant ID, Restrict filter results

Information

The following procedure exemplifies how to store a module and module variant ID in the global settings.

Store IDs in global settings

Select Insert Global Settings from the context menu.
Select the requested class, here Module variant ID in the Class listbox.
Enter the module ID in the Alpha (120) field.
Enter the module variant ID in the Parameter Alpha (120) field.
Define a Python ID in the Python ID field.
If required, fill other fields.
Save.

Read ID from global setting

from ppms import ppms_cu
#Read the module ID
mod_id=ppms_cu.Helper.get_global_setting("python_id").alpha120.get_value()
#Read the module variant ID
mv_id=ppms_cu.Helper.get_global_setting("python_id").parameter.get_value()

Details

The ppms_cu Python module is imported in order to be able to use the get_global_setting() method of the Helper class.

Notes

Python IDs must be usable as Python literals. They must not contain blanks, umlauts, special characters, etc.
Python IDs must be defined uniquely in the global settings.
Individual Python IDs must start with an L and the license number.
- Example: L100_pr_datasheet
- If the customizer does not set this manually, the system will set it automatically.

Class: Template

Store template code in global settings

Select Insert Global Settings from the context menu.
Select the requested class in the Class listbox, here "Template”.
Store the template in the Template code parameter.
If required, fill other fields.
Save.

Read ID from global setting

from ppms import ppms_cu
template=ppms_cu.Helper.get_global_setting("python_id").template_code.get_value()

Details

The ppms_cu Python module is imported in order to be able to use the get_global_setting() method of the Helper class.

Notes

Python IDs must be usable as Python literals. They must not contain blanks, umlauts, special characters, etc.
Python IDs must be defined uniquely in the global settings.
Individual Python IDs must start with an L and the license number.
- Example: L100_pr_datasheet
- If the customizer does not set this manually, the system will set it automatically.

Special Parameters

Note

For information on creating and changing global settings, see here. The parameters listed below are to be observed especially when launching PLANTA project.

General

Parameter	Version	Meaning
`wiki_url`		URL which is used when the PLANTA Wiki is opened via the menu items ? Data field description (F1), ? Module description (F2) and ? Open manual (CTRL+M) http://wiki.planta.de/twiki/bin/view/CurrentEN/
`smtp_server_adress`		If you want to use the PLANTA e-mail function (to directly send e-mails), you must store the IP of the smtp server (externally accessible address) here. In order to guarantee reception and forwarding by the mail server, you may have to check or set particular settings of the mail server and client: Accepting and forwarding sender/recipient addresses. For automatic password dispatch, the sender address must be adjusted in the template code of the `smtp_server_adress` parameter ( to do so, extend the parameter line). The template code field is filled with "no-reply@planta.de” by default. For the dispatch of project information, the e-mail address of the currently logged on user will be used for the sender. SPAM settings of mail server/mail client (e.g. in MS-Outlook, Lotus Notes). Possible whitelists for sender and recipient addresses, mail host names/mail host IP address. If the PLANTA e-mail function is used, you have the option to include a link for opening PLANTA project in the e-mail by individual customizing. If you wish to implement this option in your system, please refer to your PLANTA consultant.
`py_editor`		Here, the path for the editor is stored, which can be opened, e.g., in the Modules module by clicking on the Edit Python macro button. If no Python editor is stored for this parameter in the Alpha (120) field, the following message is displayed when the Edit python macro (Alt + E) button is clicked on in the Modules module: Please enter and save an editor If a wrong editor is stored, the Error executing python script: The system cannot find the specified file message is displayed.
`pdf_export_path`		Here, the path for PDF Export is stored

Application

If value "0" is offered for selection as a parameter value and no value is defined for a particular parameter, it behaves as if it was set to "0".

From DB 39.5.16

Parameter	Meaning	Default
`change_project_functional_global`	Controls whether the functional ID is to be changed globally (e.g. also in already existing status reports). Values 0: The functional ID is not changed globally 1: The functional ID is changed globally	1
`listbox_ressource_466`	The parameter defines which resource types are displayed in the resource listbox (MOD009595). Values 0: Only the project team is displayed 1: All resource types (project team + internal employees, external employees, departments, skills) are displayed 2: The project team and all resources which are no resources and departments are displayed 3: The project team and departments are displayed The parameter does not influence the display in the revenue and cost resource listboxes (MOD009BJC) This setting is used in the value range of DI051871 TDI: Restrict FC from DT467 Resource:	1
`default_pm_model_idea` `default_pm_model_intention` `default_pm_model_project` `default_request_model`	These parameters control which process model will be copied automatically by default when ideas/proposals/proposals/requests are created. The ID of the required process model must be entered in the Alpha (120) field.
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the functional ID of the task is displayed in the Task field instead of the WBS code. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed, which can be changed manually upon requirement Since the field is an output field by default, it must be changed to input field to be manually editable. This must be done after every database update.	1
`p_project_budget_approved_edit`	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) columns in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects upon requirement (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.	0
`p_project_budget_edit`	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. *4 = Approved* values only*: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved* values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.	1
`usage_plan_working_hours`	Controls whether the hours to be worked function or the presence time function can be used in Time Recording. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all required customizings are activated/displayed in the respective modules. 4: manual recording of presence time (time of arrival/leaving and breaks). All customizing required for this purpose are activated/displayed in the respective modules.	0
`p_project_budget_portfolio_relevant`	The Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. which project budget is compared to the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value exists, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.	0
`project_parameter_heredity`	With this global parameter you can define which parameters are inherited when subprojects are created from the parent project (entries under "project_attributes") as well as whether the stakeholders from the main project are to be inherited (entry under "project_child_records") In the Standard, the following parameters are currently inherited: Project code, Cost center, Priority, Status, Customer, Customer manager, Planning type, Booking type, and Stakeholder. All project parameters, i.e. all real fields from DT461, except key and object protection fields, can be included in the list (entries under "project_attributes").
`load_userdefined_submodules`	Controls the way in which the submodules of a main module are to be loaded. Values 0: in line with the customizing settings in DT404 1: in line with the individual user settings in DT170	1
`show_roadmap_dates`	If this parameter is activated, the dates of the last released road map are displayed in the Project Core Data module. If the project is assigned to several portfolios, the earliest roadmap dates are displayed. Values 0: Roadmap dates are not displayed in the Project Core Data module 1: Roadmap dates are displayed in the Project Core Data module	1
`maximum_work_hours_per_day`	This parameter can be used to define the default value which will be stored in the Max. actual hours/day field when new employee resources are created (Resource type = 1*) can be defined.	10
`load_creation_variant`	Controls the way of time recording in the Time Recording module Values 1: Simple time recording. Working hours per day are recorded below the scale. 2: Simple time recording with comment. Working hours per day are recorded below the scale and a comment can be written for each entry. 3: Extended time recording (direct load recording). Working time is recorded directly in the load records. Several load records per day are possible. In this variant the setting of the `usage_actual_load_reporting` global parameter is to be considered	2
`posting_cancelation`	Parameter for controlling automatic reverse postings. Values 0 = deactivate automatic reverse postings 1 = Automatic reverse postings for exported loads (SAP status = set) 2 = Automatic reverse postings for approved loads (Approval = set) 4 = Automatic reverse postings for loads before the key date (if load date Key date performance ) 8 = automatic reverse postings for imported loads (Imported on or Imported by set or if there is a record in the pulse table in which the PLANTA_ID = UUID from DT472) The parameter is a bitflag, i.e. if automatic reverse posting is to apply to multiple cases simultaneously, the respective sum values must be used (e.g. "15" for automatic reverse postings for all above mentioned cases). Show overview of possible combinations Hide overview of possible combinations When you use the 4, 5, 6, 7, 12, 13, 14, 15 setting, the effect of the Key date performance parameter is virtually undermined. Data can be created manually before or on the key date and already existing postings can be corrected or deleted (e.g. incorrect ones). Reverse postings are then automatically created for them, so that the changes can also be traced before the key date. NEW For this reason, 11 is used as a default value in the PLANTA Standard to retain the "fixed" effect of the key date. NEW Warning: If the value of this parameter is changed, the PLANTA service must be restarted!	11
`link_allow_self_signed_certificates`	This parameter serves to configure whether self-signed certificates are accepted by PLANTA link. Has an effect on PLANTA link, Weblink, and Hybrid. Values 0 = not accepted 1 = accepted	0
`planta_link_hostname`	With this parameter you can configure the host name to be used by PLANTA link in web interfaces. The required host name must be entered in the Alpha (120) field. If the field is not filled, the default host name of the computer is used.
`calendar_shift_years_future`	With this parameter you can define by how many years the calendar is to be moved into the future if it is updated on a fix date. For further information, see the Calendar module. Here, a positive integer should be placed.	4
`calendar_shift_years_past`	With this parameter you can define by how many years the calendar is to be moved into the past if it is updated on a fix date. For further information, see the Calendar module. Here, a negative integer should be placed.	-1
`quick_launch_amount`	Here you can enter the number of planning objects to be displayed in the user menu under "Recently viewed".	10
`dataarea_module_listbox_variant`	ID of the listbox module variant of the Data Areas module. Is automatically opened after the creation of a new listbox module.	0110BC
`listbox_generation_template`	Module ID of the template module which is used for the creation of a new listbox module. Here you can store an alternate template if required. The template module must not possess more than one data area.	009D65
`listbox_generation_work_area`	ID of the work area to which a newly created listbox module is assigned. If no ID is stored, the new module is not assigned to any work area.	01100100
`ole_aob_incoming_black`	Black OLE for incoming external links	DBOLE(001693)
`ole_aob_incoming_blue`	Blue OLE for incoming external links	DBOLE(001695)
`ole_aob_outgoing_black`	Black OLE for outgoing external links	DBOLE(001692)
`ole_aob_outgoing_blue`	Black OLE for outgoing external links	DBOLE(001694)

From DB 39.5.15

Parameter	Meaning	Default
`change_project_functional_global`	Controls whether the functional ID is to be changed globally (e.g. also in already existing status reports). Values 0: The functional ID is not changed globally 1: The functional ID is changed globally	1
`listbox_ressource_466`	The parameter defines which resource types are displayed in the resource listbox (MOD009595). Values 0: Only the project team is displayed 1: All resource types (project team + internal employees, external employees, departments, skills) are displayed 2: The project team and all resources which are no resources and departments are displayed 3: The project team and departments are displayed The parameter does not influence the display in the revenue and cost resource listboxes (MOD009BJC) This setting is used in the value range of DI051871 TDI: Restrict FC from DT467 Resource:	1
`default_pm_model_idea` `default_pm_model_intention` `default_pm_model_project` `default_request_model`	These parameters control which process model will be copied automatically by default when ideas/proposals/proposals/requests are created. The ID of the required process model must be entered in the Alpha (120) field.
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the functional ID of the task is displayed in the Task field instead of the WBS code. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed, which can be changed manually upon requirement Since the field is an output field by default, it must be changed to input field to be manually editable. This must be done after every database update.	1
`p_project_budget_approved_edit`	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) columns in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects upon requirement (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.	0
`p_project_budget_edit`	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. *4 = Approved* values only*: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved* values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.	1
`usage_plan_working_hours`	Controls whether the hours to be worked function or the presence time function can be used in Time Recording. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all required customizings are activated/displayed in the respective modules. 4: manual recording of presence time (time of arrival/leaving and breaks). All customizing required for this purpose are activated/displayed in the respective modules.	0
`p_project_budget_portfolio_relevant`	The Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. which project budget is compared to the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value exists, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.	0
`usage_actual_load_reporting`	The parameter is no longer supported from DB 39.5.14
`project_parameter_heredity`	With this global parameter you can define which parameters are inherited when subprojects are created from the parent project (entries under "project_attributes") as well as whether the stakeholders from the main project are to be inherited (entry under "project_child_records") In the Standard, the following parameters are currently inherited: Project code, Cost center, Priority, Status, Customer, Customer manager, Planning type, Booking type, and Stakeholder. All project parameters, i.e. all real fields from DT461, except key and object protection fields, can be included in the list (entries under "project_attributes").
`load_userdefined_submodules`	Controls the way in which the submodules of a main module are to be loaded. Values 0: in line with the customizing settings in DT404 1: in line with the individual user settings in DT170	1
`show_roadmap_dates`	If this parameter is activated, the dates of the last released road map are displayed in the Project Core Data module. If the project is assigned to several portfolios, the earliest roadmap dates are displayed. Values 0: Roadmap dates are not displayed in the Project Core Data module 1: Roadmap dates are displayed in the Project Core Data module	1
`maximum_work_hours_per_day`	This parameter can be used to define the default value which will be stored in the Max. actual hours/day field when new employee resources are created (Resource type = 1*) can be defined.	10
`load_creation_variant`	Controls the way of time recording in the Time Recording module Values 1: Simple time recording. Working hours per day are recorded below the scale. 2: Simple time recording with comment. Working hours per day are recorded below the scale and a comment can be written for each entry. 3: Extended time recording (direct load recording). Working time is recorded directly in the load records. Several load records per day are possible. In this variant the setting of the `usage_actual_load_reporting` global parameter is to be considered	2
`posting_cancelation`	Parameter for controlling automatic reverse postings. Values 0 = deactivate automatic reverse postings 1 = Automatic reverse postings for exported loads (SAP status = set) 2 = Automatic reverse postings for approved loads (Approval = set) 4 = Automatic reverse postings for loads before the key date (if load date Key date performance ) 8 = automatic reverse postings for imported loads (Imported on or Imported by set or if there is a record in the pulse table in which the PLANTA_ID = UUID from DT472) The parameter is a bitflag, i.e. if automatic reverse posting is to apply to multiple cases simultaneously, the respective sum values must be used (e.g. "15" for automatic reverse postings for all above mentioned cases). Show overview of possible combinations Hide overview of possible combinations When you use the 4, 5, 6, 7, 12, 13, 14, 15 setting, the effect of the Key date performance parameter is virtually undermined. Data can be created manually before or on the key date and already existing postings can be corrected or deleted (e.g. incorrect ones). Reverse postings are then automatically created for them, so that the changes can also be traced before the key date. NEW For this reason, 11 is used as a default value in the PLANTA Standard to retain the "fixed" effect of the key date.	NEW 11
`link_allow_self_signed_certificates`	This parameter serves to configure whether self-signed certificates are accepted by PLANTA link. Has an effect on PLANTA link, Weblink, and Hybrid. Values 0 = not accepted 1 = accepted	0
`planta_link_hostname`	With this parameter you can configure the host name to be used by PLANTA link in web interfaces. The required host name must be entered in the Alpha (120) field. If the field is not filled, the default host name of the computer is used.
`calendar_shift_years_future`	With this parameter you can define by how many years the calendar is to be moved into the future if it is updated on a fix date. For further information, see the Calendar module. Here, a positive integer should be placed.	4
`calendar_shift_years_past`	With this parameter you can define by how many years the calendar is to be moved into the past if it is updated on a fix date. For further information, see the Calendar module. Here, a negative integer should be placed.	-1
`quick_launch_amount`	Here you can enter the number of planning objects to be displayed in the user menu under "Recently viewed".	10
`dataarea_module_listbox_variant` NEW	ID of the listbox module variant of the Data Areas module. Is automatically opened after the creation of a new listbox module.	0110BC
`listbox_generation_template` NEW	Module ID of the template module which is used for the creation of a new listbox module. Here you can store an alternate template if required. The template module must not possess more than one data area.	009D65
`listbox_generation_work_area` NEW	ID of the work area to which a newly created listbox module is assigned. If no ID is stored, the new module is not assigned to any work area.	01100100
`ole_aob_incoming_black` NEW	Black OLE for incoming external links	DBOLE(001693)
`ole_aob_incoming_blue` NEW	Blue OLE for incoming external links	DBOLE(001695)
`ole_aob_outgoing_black` NEW	Black OLE for outgoing external links	DBOLE(001692)
`ole_aob_outgoing_blue` NEW	Black OLE for outgoing external links	DBOLE(001694)

From DB 39.5.14

Parameter	Meaning	Default
`change_project_functional_global`	Controls whether the functional ID is to be changed globally (e.g. also in already existing status reports). Values 0: The functional ID is not changed globally 1: The functional ID is changed globally	1
`listbox_ressource_466`	The parameter defines which resource types are displayed in the resource listbox (MOD009595). Values 0: Only the project team is displayed 1: All resource types (project team + internal employees, external employees, departments, skills) are displayed 2: The project team and all resources which are no resources and departments are displayed 3: The project team and departments are displayed The parameter does not influence the display in the revenue and cost resource listboxes (MOD009BJC) This setting is used in the value range of DI051871 TDI: Restrict FC from DT467 Resource:	1
`default_pm_model_idea` `default_pm_model_intention` `default_pm_model_project` `default_request_model`	These parameters control which process model will be copied automatically by default when ideas/proposals/proposals/requests are created. The ID of the required process model must be entered in the Alpha (120) field.
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the functional ID of the task is displayed in the Task field instead of the WBS code. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed, which can be changed manually upon requirement Since the field is an output field by default, it must be changed to input field to be manually editable. This must be done after every database update.	1
`p_project_budget_approved_edit`	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) columns in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects upon requirement (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.	0
`p_project_budget_edit`	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. *4 = Approved* values only*: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved* values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.	1
`usage_plan_working_hours`	Controls whether the hours to be worked function or NEW the presence time function can be used in Time Recording. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all required customizings are activated/displayed in the respective modules. 4: manual recording of presence time (time of arrival/leaving and breaks). All customizing required for this are activated/displayed in the respective modules. NEW	0
`p_project_budget_portfolio_relevant`	The Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. which project budget is compared to the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value is available, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.	0
`usage_actual_load_reporting`	The parameter is no longer supported from DB 39.5.14
`project_parameter_heredity`	With this global parameter you can define which parameters are inherited when subprojects are created from the parent project (entries under "project_attributes") as well as whether the stakeholders from the main project are to be inherited (entry under "project_child_records") In the Standard, the following parameters are currently inherited: Project code, Cost center, Priority, Status, Customer, Customer manager, Planning type, Booking type, and Stakeholder. All project parameters, i.e. all real fields from DT461, except key and object protection fields, can be included in the list (entries under "project_attributes").
`load_userdefined_submodules`	Controls the way in which the submodules of a main module are to be loaded. Values 0: in line with the customizing settings in DT404 1: in line with the individual user settings in DT170	1
`show_roadmap_dates`	If this parameter is activated, the dates of the last released road map are displayed in the Project Core Data module. If the project is assigned to several portfolios, the earliest roadmap dates are displayed. Values 0: Roadmap dates are not displayed in the Project Core Data module 1: Roadmap dates are displayed in the Project Core Data module	1
`maximum_work_hours_per_day`	This parameter can be used to define the default value which will be stored in the Max. actual hours/day field when new employee resources are created (Resource type = 1*) can be defined.	10
`load_creation_variant`	Controls the way of time recording in the Time Recording module Values 1: Simple time recording. Working hours per day are recorded below the scale. 2: Simple time recording with comment. Working hours per day are recorded below the scale and a comment can be written for each entry. 3: Extended time recording (direct load recording). Working time is recorded directly in the load records. Several load records per day are possible. In this variant the setting of the `usage_actual_load_reporting` global parameter is to be considered	2
`posting_cancelation`	Parameter for controlling automatic reverse postings. Values 0 = deactivate automatic reverse postings 1 = Automatic reverse postings for approved loads (SAP status = set) 2 = Automatic reverse postings for approved loads (Approval = set) 4 = Automatic reverse postings for loads before the key date (if load date Key date performance ) 8 = automatic reverse postings for imported loads (Imported on or Imported by set or if there is a record in the pulse table in which the PLANTA_ID = UUID from DT472) The parameter is a bitflag, i.e. if automatic reverse posting is to be applied to multiple cases simultaneously, the respective sum values must be used (e.g. "15" for automatic reverse postings for all above mentioned cases). Show overview of possible combinations Hide overview of possible combinations When you use the 4, 5, 6, 7, 12, 13, 14, 15 setting, the effect of the Key date performance parameter is virtually undermined. Data can be created manually before or on the key date and already existing postings can be corrected or deleted (e.g. incorrect ones). Reverse postings are then automatically created for them, so that the changes can also be traced before the key date.	15
`link_allow_self_signed_certificates`	This parameter serves to configure whether self-signed certificates are accepted by PLANTA link. Has an effect on PLANTA link, Weblink, and Hybrid. Values 0 = not accepted 1 = accepted	0
`planta_link_hostname` NEW	With this parameter you can configure the host name to be used by PLANTA link in web interfaces. The required host name must be entered in the Alpha (120) field. If the field is not filled, the default host name of the computer is used.
`calendar_shift_years_future` NEW	With this parameter you can define by how many years the calendar is to be moved into the future if it is updated on a fix date. For further information, see the Calendar module. Here, a positive integer should be placed.	4
`calendar_shift_years_future` NEW	With this parameter you can define by how many years the calendar is to be moved into the past if it is updated on a fix date. For further information, see the Calendar module. Here, a negative integer should be placed.	-1
`quick_launch_amount` NEW	Here you can enter the number of planning objects to be displayed in the user menu under "Recently viewed".	10

From DB 39.5.13

Parameter	Meaning	Default
`change_project_functional_global`	Controls whether the functional ID is to be changed globally (e.g. also in already existing status reports). Values 0: The functional ID is not changed globally 1: The functional ID is changed globally	1
`listbox_ressource_466`	The parameter defines which resource types are displayed in the resource listbox (MOD009595). Values 0: Only the project team is displayed 1: All resource types (project team + internal employees, external employees, departments, skills) are displayed 2: The project team and all resources which are no resources and departments are displayed 3: The project team and departments are displayed The parameter does not influence the display in the revenue and cost resource listboxes (MOD009BJC) This setting is used in the value range of DI051871 TDI: Restrict FC from DT467 Resource:	1
`default_pm_model_idea` `default_pm_model_intention` `default_pm_model_project` `default_request_model`	These parameters control which process model will be copied automatically by default when ideas/proposals/proposals/requests are created. The ID of the required process model must be entered in the Alpha (120) field.
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the functional ID of the task is displayed in the Task field instead of the WBS code. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed, which can be changed manually upon requirement Since the field is an output field by default, it must be changed to input field to be manually editable. This must be done after every database update.	1
`p_project_budget_approved_edit`	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) columns in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects upon requirement (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.	0
`p_project_budget_edit`	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. *4 = Approved* values only*: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved* values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.	1
`usage_plan_working_hours`	Controls whether the hours to be worked function can be used. Read more on the hours to be worked function. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all customizings required for this are switched on/displayed in the respective modules.
`p_project_budget_portfolio_relevant`	The Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. which project budget is compared to the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value is available, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.	0
`usage_actual_load_reporting`	Controls the creation of working time/working hours in the NEW Time Recording module and in NEW time recording variant 3 ( `load_creation_variant` = 3) of the 009ABV Time Recording module Values 0: time recording is done in accordance with the times entered in the from/to fields. The Actual load is set to "output" and is automatically calculated from the times entered. If this option is selected, the `load_creation_variant` global parameter must be set to "3". `usage_actual_load_reporting` = 0 can only be used in this combination. 1: time recording is done by in accordance with the hours entered in the Actual load field. The from/to fields are hidden.	1
`project_parameter_heredity`	With this global parameter you can define which parameters are inherited when subprojects are created from the parent project (entries under "project_attributes") as well as whether the stakeholders from the main project are to be inherited (entry under "project_child_records") In the Standard, the following parameters are currently inherited: Project code, Cost center, Priority, Status, Customer, Customer manager, Planning type, Booking type, and Stakeholder. All project parameters, i.e. all real fields from DT461, except key and object protection fields, can be included in the list (entries under "project_attributes").
`load_userdefined_submodules`	Controls the way in which the submodules of a main module are to be loaded. Values 0: in line with the customizing settings in DT404 1: in line with the individual user settings in DT170	1
`show_roadmap_dates`	If this parameter is activated, the dates of the last released road map are displayed in the Project Core Data module. If the project is assigned to several portfolios, the earliest roadmap dates are displayed. Values 0: Roadmap dates are not displayed in the Project Core Data module 1: Roadmap dates are displayed in the Project Core Data module	1
`maximum_work_hours_per_day`	This parameter can be used to define the default value which will be stored in the Max. actual hours/day field when new employee resources are created (Resource type = 1*) can be defined.	10
`load_creation_variant` NEW	Controls the way of time recording in the Time Recording module Values 1: Simple time recording. Working hours per day are recorded below the scale. 2: Simple time recording with comment. Working hours per day are recorded below the scale and a comment can be written for each entry. 3: Extended time recording (direct load recording). Working time is recorded directly in the load records. Several load records per day are possible. In this variant, the setting of the `usage_actual_load_reporting` global parameter is to be considered	2
`posting_cancelation` NEW	Parameter for controlling automatic reverse postings. Values 0 = deactivate automatic reverse postings 1 = Automatic reverse postings for approved loads (SAP status = set) 2 = Automatic reverse postings for approved loads (Approval = set) 4 = Automatic reverse postings for loads before the key date (if load date Key date performance ) 8 = automatic reverse postings for imported loads (Imported on or Imported by set or if there is a record in the pulse table in which the PLANTA_ID = UUID from DT472) The parameter is a bitflag, i.e. if automatic reverse posting is to be applied to multiple cases simultaneously, the respective sum values must be used (e.g. "15" for automatic reverse postings for all above mentioned cases). Show overview of possible combinations Hide overview of possible combinations When you use the 4, 5, 6, 7, 12, 13, 14, 15 setting, the effect of the Key date performance parameter is virtually undermined. Data can be created manually before or on the key date and already existing postings can be corrected or deleted (e.g. incorrect ones). Reverse postings are then automatically created for them, so that the changes can also be traced before the key date.	15
`link_allow_self_signed_certificates` NEW	This parameter serves to configure whether self-signed certificates are accepted by PLANTA link. Has an effect on PLANTA link, Weblink, and Hybrid. Values 0 = not accepted 1 = accepted	0

From DB 39.5.11

Parameter	Meaning
`change_project_functional_global`	Controls whether the functional ID is to be changed globally (e.g. also in already existing status reports). Values 0: The functional ID is not changed globally 1: The functional ID is changed globally
`listbox_ressource_466`	The parameter defines which resource types are displayed in the resource listbox (MOD009595). Values 0: Only the project team is displayed 1: All resource types (project team + internal employees, external employees, departments, skills) are displayed 2: The project team and all resources which are no resources and departments are displayed 3: The project team and departments are displayed The parameter does not influence the display in the revenue and cost resource listboxes (MOD009BJC) This setting is used in the value range of DI051871 TDI: Restrict FC from DT467 Resource:
`default_pm_model_intention`	Default process model when creating proposals
`default_pm_model_project`	Default process model when creating projects
`default_request_model`	Default process model when creating requests
`default_pm_model_idea`	Default process model when creating ideas
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the WBS code is displayed in the Task field instead of the functional ID of the task. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed, which can be changed manually if necessary Since the field is an output field by default, it must be changed to input field to be manually editable. This must be done after every database update.
`p_project_budget_approved_edit`	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. * For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects if necessary (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.
`p_project_budget_edit`	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. 4 = Approved values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.
`usage_plan_working_hours`	Controls whether the hours to be worked function can be used. Read more on the hours to be worked function. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all customizings required for this are switched on/displayed in the respective modules.
`p_project_budget_portfolio_relevant`	The Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. which project budget is compared to the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value is available, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.
`usage_actual_load_reporting`	Controls the creation of working hours in the Reporting Hours Worked module Values 0: the reporting is done by entering the time in the from/to fields. The Actual load is set to "output" and is automatically calculated from the entered times. 1: the reporting is done by entering the hours in the Actual load field. The from/to fields are hidden.
`project_parameter_heredity`	With this global parameter you can define which parameters are inherited when subprojects are created from the parent project (entries under "project_attributes") as well as whether the stakeholders from the main project are to be inherited (entry under "project_child_records") In the Standard, the following parameters are currently inherited: Project code, Cost center, Priority, Status, Customer, Customer manager, Planning type, Booking type, and Stakeholder. All project parameters, i.e. all real fields from DT461, except key and object protection fields, can be included in the list (entries under "project_attributes").
`load_userdefined_submodules`	Controls the way in which the submodules of a main module are to be loaded. Values 0: in line with the customizing settings in DT404 1: in line with the individual user settings in DT170
`show_roadmap_dates`	If this parameter is activated, the dates of the last released road map are displayed in the Project Core Data module. If the project is assigned to several portfolios, the earliest roadmap dates are displayed. Values 0: Roadmap dates are not displayed in the Project Core Data module 1: Roadmap dates are displayed in the Project Core Data module
`maximum_work_hours_per_day` NEW	With this parameter the default value which is stored in the Max. actual hours/day field when new employee resources are created (Resource type = 1) can be defined. Values In PLANTA project* Standard, the default value "10" is stored.

From DB 39.5.10

Parameter	Meaning
`change_project_functional_global`	Controls whether functional ID is to be changed globally (also e.g. in already existing status reports). If you have selected value "1", the change is applied globally.
`listbox_ressource_466`	The parameter defines which resource types are displayed in the resource listbox (MOD009595). Values 0: Only the project team is displayed 1: All resource types (project team + internal employees, external employees, departments, skills) are displayed 2: The project team and all resources which are no resources and departments are displayed 3: The project team and departments are displayed The parameter does not influence the display in the revenue and cost resource listboxes (MOD009BJC) This setting is used in the value range of DI051871 TDI: Restrict FC from DT467 Resource:
`default_pm_model_intention`	Default process model when creating proposals
`default_pm_model_project`	Default process model when creating projects
`default_request_model`	Default process model when creating requests
`default_pm_model_idea`	Default process model when creating ideas
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the WBS code is displayed in the Task field instead of the functional ID of the task. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed, which can be changed manually if necessary Since the field is an output field by default, it must be changed to input field to be manually editable. This must be done after every database update.
`p_project_budget_approved_edit`	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. * For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects if necessary (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.
`p_project_budget_edit`	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. 4 = Approved values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.
`usage_plan_working_hours`	Controls whether the hours to be worked function can be used. Read more on the hours to be worked function. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all customizings required for this are switched on/displayed in the respective modules.
`p_project_budget_portfolio_relevant`	The Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. which project budget is compared to the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value is available, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.
`usage_actual_load_reporting`	Controls the creation of working hours in the Reporting Hours Worked module Values 0: the reporting is done by entering the time in the from/to fields. The Actual load is set to "output" and is automatically calculated from the entered times. 1: the reporting is done by entering the hours in the Actual load field. The from/to fields are hidden.
`project_parameter_heredity`	With this global parameter you can define which parameters are inherited when subprojects are created from the parent project (entries under "project_attributes") as well as whether the stakeholders from the main project are to be inherited (entry under "project_child_records") In the Standard, the following parameters are currently inherited: Project code, Cost center, Priority, Status, Customer, Customer manager, Planning type, Booking type, and Stakeholder. All project parameters, i.e. all real fields from DT461, except key and object protection fields, can be included in the list (entries under "project_attributes").
`load_userdefined_submodules` NEW	Controls the way the submodules of a main module are to be loaded. Values 0: in line with the customizing settings in DT404 1: in line with the individual user settings in DT170
`show_roadmap_dates` NEW	If this parameter is activated, the dates of the last released road map is displayed in the Project Core Data module. If the project is assigned to several portfolios, the earliest roadmap dates are displayed. Values 0: Roadmap dates are not displayed in the Project Core Data module 1: Roadmap dates are displayed in the Project Core Data module

From DB 39.5.9

Parameter	Meaning
`change_project_functional_global`	Controls whether functional ID is to be changed globally (also e.g. in already existing status reports). If you have selected value "1", the change is applied globally.
`listbox_ressource_466`	The parameter defines which resource types are displayed in the resource listbox (MOD009595). Values 0: Only the project team is displayed 1: All resource types (project team + internal employees, external employees, departments, skills) are displayed 2: The project team and all resources which are no resources and departments are displayed 3: The project team and departments are displayed The parameter does not influence the display in the revenue and cost resource listboxes (MOD009BJC) This setting is used in the value range of DI051871 TDI: Restrict FC from DT467 Resource:
`default_pm_model_intention`	Default process model when creating proposals
`default_pm_model_project`	Default process model when creating projects
`default_request_model`	Default process model when creating requests
`default_pm_model_idea`	Default process model when creating ideas
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the WBS code is displayed in the Task field instead of the functional ID of the task. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed, which can be changed manually if necessary Since the field is an output field by default, it must be changed to input field to be manually editable. This must be done after every database update.
`p_project_budget_approved_edit`	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. * For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects if necessary (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.
`p_project_budget_edit`	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. 4 = Approved values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.
`usage_plan_working_hours`	Controls whether the hours to be worked function can be used. Read more on the hours to be worked function. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all customizings required for this are switched on/displayed in the respective modules.
`p_project_budget_portfolio_relevant`	The Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. which project budget is compared to the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value is available, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.
`usage_actual_load_reporting`	Controls the creation of working hours in the Reporting Hours Worked module Values 0: the reporting is done by entering the time in the from/to fields. The Actual load is set to "output" and is automatically calculated from the entered times. 1: the reporting is done by entering the hours in the Actual load field. The from/to fields are hidden.
`project_parameter_heredity`	With this global parameter you can define which parameters are inherited from the main project when creating subprojects (entries under "project_attributes") as well as whether the stakeholders from the main project are to be inherited (entry under "project_child_records") In the Standard, the following parameters are currently inherited: Project code, Cost center, Priority, Status, Customer, Customer manager, Planning type, Booking type, and Stakeholder. All project parameters, i.e. all real fields from DT461, except key and object protection fields, can be included in the list (entries under "project_attributes").

From DB 39.5.3

Parameter	Meaning
`change_project_functional_global`	Controls whether functional ID is to be changed globally (also e.g. in already existing status reports). If you have selected value "1", the change is applied globally.
`listbox_ressource_466`	The parameter defines which resource types are displayed in the resource listbox (MOD009595). Values 0: Only the project team is displayed 1: All resource types (project team + internal employees, external employees, departments, skills) are displayed 2: The project team and all resources which are no resources and departments are displayed 3: The project team and departments are displayed The parameter does not influence the display in the revenue and cost resource listboxes (MOD009BJC) This setting is used in the value range of DI051871 TDI: Restrict FC from DT467 Resource:
`default_pm_model_intention`	Default process model when creating proposals
`default_pm_model_project`	Default process model when creating projects
`default_request_model`	Default process model when creating requests
`default_pm_model_idea`	Default process model when creating ideas
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the WBS code is displayed in the Task field instead of the functional ID of the task. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed, which can be changed manually if necessary Since the field is an output field by default, it must be changed to input field to be manually editable. This must be done after every database update.
`p_project_budget_approved_edit`	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. * For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects if necessary (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.
`p_project_budget_edit`	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. 4 = Approved values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.
`usage_plan_working_hours`	Controls whether the hours to be worked function can be used. Read more on the hours to be worked function. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all customizings required for this are switched on/displayed in the respective modules.
`p_project_budget_portfolio_relevant`	The Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. which project budget is compared to the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value is available, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.
`usage_actual_load_reporting` NEW	Controls the creation of working hours in the Reporting Hours Worked module Values 0: the reporting is done by entering the time in the from/to fields. The Actual load is set to "output" and is automatically calculated from the entered times. 1: the reporting is done by entering the hours in the Actual load field. The from/to fields are hidden.

From DB 39.5.0

Parameter	Meaning
`change_project_functional_global`	Controls whether functional ID is to be changed globally (also e.g. in already existing status reports). If you have selected value "1", the change is applied globally.
`listbox_resource_466`	Values 0: Only the project team is displayed 1: The module finds all kinds of resources (also stakeholders) 2: The module only finds the project team and all resources that are not employees and departments 3: The module only finds project team and departments This setting is used in the following value ranges: - DI051871 TDI: Restrict filter criteria from DT467 Resource
`default_pm_model_intention`	Default process model when creating proposals
`default_pm_model_project`	Default process model when creating projects
`default_request_model`	Default process model when creating requests
`default_pm_model_idea`	Default process model when creating ideas
`default_roles`	Template in which roles are stored which are created for each user by default upon transfer from the Fast Creation of Employee Data module.
`show_psp_instead_of_id`	This parameter controls whether the WBS code is displayed in the Task field instead of the functional ID of the task. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed.
`p_project_budget_approved_edit` NEW	Controls the input and the maintenance of the approved budget values system-wide in the Approved and Approved (without SP) columns in the Budget module in the project environment and in the Edit Period: module in the portfolio environment. The values are generally only edit in the yearly tranches and summarized to the respective output fields on the respective project. For detailed information, see the Budget module. Values 0 = Bottom up: Project: The approved budget values are entered and maintained in the yearly tranches on any project level (regardless of whether it is a main or subproject). Portfolio: In the portfolio environment, the sums of all project levels of the yearly tranche (main and subprojects of a project) are displayed automatically. They can be approved but not edited directly. Editing is only possible in the Budget module in the project environment. 1 = Top down: Project: the Approved budget values are input and maintained in the yearly tranches of the main project as the sum of the main and subprojects of the corresponding yearly tranche. Budgets can be entered manually in the yearly tranches of the subprojects upon requirement (organizational rule). This does not influence the main project values. Portfolio: In the portfolio environment, only the annual values of the main project level are relevant. Here, Approved values which have not been approved yet can be edited and approved directly. The Top down model cannot be used at the moment.
`p_project_budget_edit` NEW	Controls the input and maintenance of the project budget values in the Budget and Budget (without SP) columns in the Budget module. The Functions for transferring the project budget values are not influenced by this parameter. For detailed information, see the Budget module. Values 0 = Open: Manual input and maintenance is also possible on project and annual value level. The annual values are summarized on project level automatically. As soon as a value has been entered for a cost type group on annual value level, the value is overwritten on project level by the sum of the year values. 1 = Annual values only: Manual input and maintenance is only possible on annual value level. The project budget data fields on project level are output data fields. The year values are automatically summarized on project level. 2 = Project values only: Manual input and maintenance is only possible on project level. The project budget data fields on annual value level are output data fields. 3 = Baseline values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the Baseline current values in the project budget data fields. This requires that a baseline has been created for the project. The update of the values is done when the Budget module is opened. 4 = Approved values only: Manual input and maintenance is neither possible on project level nor on annual value level. Automatic adoption of the approved Approved values in the project budget data fields, provided that annual values of the project have been approved. The value update is done when the Budget module is opened.
`usage_plan_working_hours` NEW	Controls whether the hours to be worked function can be used. Read more on the hours to be worked function. Values 0: Hours to be worked function is deactivated and any customizing connected to it is switched off or hidden. 1: Trigger (not implemented) 2: Import (not implemented) 3: Hours to be worked function is activated and all customizings required for this are switched on/displayed in the respective modules.
`p_project_budget_portfolio_relevant` NEW	Relevant budget parameter in the portfolio environment controls system wide which project budget is relevant in the portfolio environment, i.e. is compared with the portfolio budget. Values 0 = Approved/Requested: Approved values from the current planning are compared to the portfolio budget as relevant budget. If no Approved value is available, the Requested value becomes the relevant budget. 1 = Project budget: Project budget values from the current planning are compared to the portfolio budget as relevant budget. 2 = Baseline: Baseline values (project costs/total effort from the baseline) are compared to the portfolio budget as relevant budget. 3 = Active status report: Costs SR / effort SR values (project costs/total effort from the active status report) are compared to the portfolio budget as relevant budget. 4 = Costs/effort total from the current planning: Cost/effort values (costs/effort total from the current planning) are compared to the portfolio budget as relevant budget.

Up to DB 39.5.0

Parameter	Meaning
`change_project_functional_global`	Controls whether the functional ID is to be changed globally (also e.g. in already existing status reports). If you have selected value "1", the change is applied globally.
`listbox_resource_466`	Values 1: The module finds all kinds of resources (also stakeholders) 2: The module only finds project team and all resources that are not employees and departments 3: The module only finds project team and departments This setting is used in the following value ranges: - DI051871 TDI: Restrict filter criteria from DT467 Resource
`default_pm_model_intention`	Default process model when creating proposals
`default_pm_model_project`	Default process model when creating projects
`default_request_model`	Default process model when creating requests
`default_pm_model_idea`	Default process model when creating ideas
`show_psp_instead_of_id`	This parameter controls whether the WBS code is displayed in the Task field instead of the functional ID of the task. Values 0: In the Task field, the functional task ID is displayed. 1: In the Task field, the WBS code is displayed. 2: In the Task field, the functional task ID is displayed.

Attachments

Topic attachments
I	Attachment	History	Size	Date	Comment
png	Wertetabelle.png	r1	6.5 K	2019-09-06 - 12:14
txt	WertetabelleStorno.txt	r1	0.5 K	2019-09-06 - 12:19

39.5 Venus Current EN

PLANTA project

PLANTA pulse

PLANTA project

Suche in Topic-Namen
Suche in Topic-Inhalten