In this section you can manage general partition-wide settings.

• Base URL – Sets the base URL prefix under which this instance is reachable from the Internet. An example of the base URL is https://qa.pricefx.eu.

• Company Name – Replaces the default word "Company" in Company Parameters and Company Processes with your own string (e.g., your company's name). The maximum length is 50 characters.

• Default Timezone – Sets the default time zone as an offset to GMT/UTC. All target dates, valid-after dates and expiry dates will be in this timezone. For example, this setting will determine the moment when a workflow logic starts to be valid (and automatically used) or when a Quote expires. Bear this time offset in mind when setting validity dates throughout the application. 
  If you wish to reflect on the daylight saving changes, use a timezone which has such information (full timezone info is shown here for this reason).

• Max Grid Group By – Defines the maximum number of rows the Group By function in grids is performed for. If the number of rows exceeds the limit, grouping is disabled. The default limit is 10,000.

• Email Redirection – Specifies an email address where all emails from the system are redirected. This can be useful for testing scenarios where sending emails to real users is not desired.

Password Settings

• Password Complexity Requirements – Sets the complexity for passwords. Details are below.

• Enable password history – If checked, the user cannot set the same password if the last one was reset.

• Password history size – Sets the number of previous passwords that cannot be reused.

• Passwords expire after (days) – If set, all passwords expire in the given number of days. This expiry setting is applied whenever a password is changed.

  • If the password expiry has to be employed (e.g., because of company policy), you need to instruct all users to change their password first.

  • If you prefer a password to never expire (e.g., for a technical account used for integration), you just do not update it and then the expiry setting is not applied. 

  • Password expiry setting can also be made for individual users; to learn how these two settings work together see the User Admin section.

  • An email notification is sent to users 5 days before password expiration asking them to change the password. In Advanced configuration options, you can change the number of days before the expiry date when the email is sent (daysBeforeSendingPasswordExpirationEmailNotification) or disable the email notifications completely (disablePasswordExpirationEmailNotifications).

• Check compromised passwords – If checked, every new password is checked against the online database of broken passwords – Have I Been Pwned. This check is done anonymously and the password is never sent to the external provider (only a part of the hashed version).

Two-Factor Authentication and Login

• Mandatory two-factor authentication – If checked, two-factor authentication is required for all users logging in to the application (directly, not via SSO). After enabling, it can take up to 10 minutes to take effect.

• Disable automatic relogin of Web UI – Using this option you can control what happens after the user session expires due to inactivity. If the option is checked, users are required to log in again to continue working with the application. If the option is not checked, users are automatically logged in, provided the same browser window is still open. The advantage of the automatic relogin is improved user experience, however, make sure that such application behavior is in line with your processes.

• Disable Pricefx support login – Disables O365 support login, so that you can explicitly approve/grant access by non-partition users like root/support. This includes the support user accounts created in PlatformManager. 

• Disable Platform login – Prevents any user accounts from PlatformManager from logging into the partition. Also, user accounts for this partition can no longer be created from PlatformManager (e.g. General Admin users, Support users or so called Technical User Accounts). If such accounts were already created before this option was used, they will still remain in the list of users. You can delete them if needed.

Logging & History

• Activate comment history – If enabled, history of comments in Price Lists, Manual Price Lists and Live Price Grids is captured and displayed in the product details portlet Comment History.

• Allow Groovy logging to system log – If enabled, Groovy scripts in calculation logics are allowed to write messages to the system log file when the calculation is executed (api.logXX statements).

• Disable logging to Redis – If checked, the Log page will display the traditional log file as in previous releases (before Bijou 7.0). This is sufficient if your partition is not running in the new cloud native environment. If unchecked (default) and the cluster runs on Redis, structured logs from standard output will be sent to Redis and displayed to the user after selecting the options Administration > Logs > Logs / Logs (Perf).

Events

• Event URL – HTTP endpoint to which events from the current partition are published.

• Event email – Email address to which events from the current partition are published. When empty, emails with events are not generated. 

• Disable sending events through HTTP (PUSH) – Check if you use the Pull method.

Others

• Determine workflow logic validity date on the item effective date – If there are more workflow logics set as Active for a certain document type, you can decide here how a valid workflow logic is selected. Basically, the workflow logic determination follows the same principles also found everywhere else regarding validity dates. If this option is checked, the date that drives the logic selection (= the "target date") will be the effective date of the Quote, Agreement/Promotion or Rebate Agreement. Hence a date that could also be in the future. If it is unchecked, the target date of "now" (i.e., the point in time when the document was submitted) is used.

• OBJREFs options – OBJREFs stands for object references, a table in Pricefx which holds information which Agreements/Promotions or Rebate Agreements contain which products and for which customers. This information can be generated on the header level either during save or later or on the line item level where it can be switched off completely. The following two options can have a significant impact on the performance.

  • Update OBJREFs on header level at AP/RBA submit – If enabled, the OBJREF table is not updated during saving an Agreement/Promotion or Rebate Agreement, but only when the document is submitted, copied or a new revision is created. The update is synchronous and handles the header level only.
    If not enabled, the OBJREFs update happens during saving the document.

  • Disable creation of OBJREFs on line item level after AP/RBA save/submit – If enabled, the OBJREFs for line items of an Agreement/Promotion or Rebate Agreement are not created at all.
    If not selected, the OBJREF table for line items of an Agreement/Promotion or Rebate Agreement is updated during saving, submitting or copying the document. The update happens asynchronously, so it may take some time before the Agreements/Promotions or Rebate Agreements are visible in Customer Details and other places. During the execution of the background update job, it is impossible to delete or approve the document. You can check whether the job has already finished in the Job/Task Tracking section.

• api.retainGlobal defaults to TRUE – If enabled, sets the default value of api.retainGlobal to true. In that case, using only api.global is sufficient to instruct the formula engine to keep the hash map in between logic runs.

• Load content of PX/CX/SX automatically – If disabled, data in the Product, Customer and Seller Extensions tables are loaded only after you click the Refresh button.

• Decouple product/customer extensions from product/customer records – Enables you to make product, customer and seller extensions configuration independent from product, customer and seller records. If unchecked (default), the SKU/CustomerID/SellerID meta data record for PX/CX/SX is always taken from the Product/Customer/Seller record and the editability of a PX/CX/SX record is also cross checked against the user group editability settings of the corresponding Product/Customer/Seller record. In the same way, renaming the ProductID/CustomerID/SellerID column in the Products/Customers/Sellers table is coupled/decoupled with PX/CX/SX table.

• Apply user filtering in Product / Customer / Seller Extensions – If enabled, Product, Customer and Seller filters defined in User Admin will also affect Product, Customer and Seller Extensions. This option is not available if Product/Customer Extensions are decoupled from Product/Customer Records. Note that this extra filtering will have an impact on performance.

• Show progress in Configurator when being recalculated

• Infer mass edit rounding – If enabled, the number of decimal places is preselected in the Precision column of the mass edit dialog. The value depends on the data type of the edited column: MONEY, PERCENT 2 decimal places, NUMERIC 3 decimal places, NUMERIC_LONG 10 decimal places. The preselected value can always be changed by the user in the dialog.

• Allow editing the target date after the price list was calculated – If checked, it is possible to edit the target date even after the price list was calculated.

• Enable table data export only for defined user groups – Allows you to define which user groups are allowed to download data from tables within the application (i.e., see the Download to XLS/PDF/DOC icon). To specify the groups, enter their names (case insensitive) separated by a comma. 
  If this option is not checked, everyone can export data.
  If this option is checked but no user group is defined, the export functionality is disabled for all the users.

• Table pagination – Sets the partition-wide default number of items displayed per table page (50, 300 or 500). If no value is selected, the default will be 300. Users can override this setting by creating a view preference for individual tables or selecting their own default value in User Settings.

• Auto-align values in Calculation Results – If enabled, results are aligned depending on data type (money, number percentage to the right, text to the left). If disabled (default), all results are aligned to the left.

Do not forget to click the Save Changes button. After saving, settings on this page do not apply immediately. Because of caching, it can take up to 5 minutes to apply them.

Criteria for Password Complexity

By default, a password must be at least 6 characters long and must contain at least one number and one upper case character.

In addition to that the following criteria can be set:

• Similarities with user's first name – The user's first name is parsed for non-alphabetic characters (e.g., spaces). If any of such characters are found, the name is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are less than three characters in length are ignored, and substrings of the tokens are not checked. For example, the name "Erin M." is split into two tokens:  "Erin" and "M". Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included "erin" as a substring anywhere in the password.

• Lowercase letters only – The password must not only comprise lowercase letters.

• User name included in password – The username is checked to determine whether it is part of the password. If the username is less than three characters long, this check is skipped.

• At least one capital – The password must contain at least one capital letter.

• Similarities with user's email – The user's email is parsed for non-alphabetic characters (e.g., @ or spaces). If any of such characters are found, the name is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are less than three characters in length are ignored, and substrings of the tokens are not checked. For example, the email "erin@example.eu" is split into three tokens:  "erin", "example" and "eu". Because the third token is only two characters long, it is ignored. Therefore, this user could not have a password that included either "erin" or "example" as a substring anywhere in the password.

• At least one lowercase letter – The password must contain at least one lowercase letter.

• Repeating characters – The password must not contain repeating characters (e.g., aa or 11).

• At least one number – The password must contain at least one digit.

• Special characters – The password must contain at least one of the following symbols:  ~!@#$%^&*_-+=`|(){}[]:';"<>,.?/

• Digits only – The password must not only comprise digits.

• Capitals only – The password must not only comprise capital letters.

• Minimal password length – Sets the minimum length of the password. The allowed value is between 6 and 16 characters.