Journal definition

All changes in a selected form or data object (e.g., changes to important customer data) can be recorded using a journal function. For this, a journal is first defined, and a relation between the journal and the data object, which is presented in the form, is created. In the form itself, an additional tab (Journal) for displaying the reported changes needs to be provided.

The changes to be logged can be field-related (log all modifications at or in a selected field) or record-related (log all changes to a DTO independently of field modifications). See below for details.

Note: You can define a "record related journal" in the journal definition. Remember that deleting a record also deletes the corresponding journal entries.

In the standard, PSA_ACT is delivered. As relations, products, documents, service objects, contacts, mail­ing lists, projects and resources are logged. A new interface, PSA_JRN_REC_IFC, is linked to the DTOs. For activities, the journal entries are stored in the table PSA_JRN_REC_DAT_ACT.

PSA_ACT is used the Entry portal. Here, a new view on activities has the journal table as a com­ponent. This way, the journal definition can be used to monitor changes to all DTOs. In the Entry Portal, the view to the most recently edited activities can be controlled.

Attention

Attention: The  additional “Journal” tab can only be provided with customizer permissions, as this requires knowledge of the data model, and associations between data objects must be created.

Fields, flags and functions

Title

Description

Name

Name of the data object (DTO)

Title

Title of the data object

Table

Name of the database table of the data object

Superclass

Title of the superclass of the data object

Rec. on Insert

y = Logging takes place when a new record is inserted (created) and fields are changed.

n = No logging when a new record is created. Changing fields is logged.

Rec. on Update

y = All fields marked with the Update flag (edit) in the list are monitored.

n = No logging takes place, even if fields in the list are marked.

Rec. on Delete

Deleted records are logged.

Rollback permitted

Refers to another function in the journal tab of the destination mask (rollback). We recommend leaving the setting in the list (Rollback) deactivated.

Upgrade Journal

y = This is a data object whose records are customized and will be written back when you upgrade the system. See below: Upgrade journal (flag).

Relations created

Indicates whether the journal is active.

Userexit

Userexit to be called when the journal entry is created and to which a comment can be passed if necessary. A class name or, with a preceding $ character, dynamic Java must be specified. The class must implement PsaJrnUsx.

Field name (list)

The actual data item name (e.g., GID of a contact)

Visible field name (list)

Entry visible in the user interface (e.g., name component of the contact)

Title

Field title at the data object

Type

Type of the field (date, integer, logic, string etc.)

Update

y = A journal entry is created when the field is modified.

Rollback

y = Rollback for this field is permitted (see information below).

Overwrite journal (flag)

Flag for a customizer causing only the most recent change to be recorded (programming support)

Function bar

Create relations

After a journal has been created, the relation between the data object and the journal tab in the destination mask is created, and an Interface is initialized.

Delete relations

The above mentioned relation is deleted, the interface is deactivated, no new changes are recorded, but the old entries are still available.

Check userexit (subdialog function)

Checks the specified userexit of the field marked in the list.

“Upgrade journal” flag

Note: This flag should not be set if changes to the contents of fields should only be logged and not adopted (e.g., from the test system into the productive system).
If the flag is set, this journal is launched again after a JustRelate CRM upgrade, and the value changes made to the standard by "PSA" are reverted.

The flag can be set if records such as menu entries (menu selection) and the like in the data object are customized (journal in adaptation lists). Then it makes sense that these journals are marked with the Upgrade journal flag. This ensures that changed entries are written back to the source record in the course of an upgrade.

Cancellation of a value update (rollback)

If a value change is rolled back, the changed value of an attribute from the data object for which the journal is defined is reset to the original value in the database.

Attention

Attention: The rollback option should only be used for special cases. Please remember that resetting changed attribute values can lead to inconsistencies in the database, because further attributes connected with these values are not included in the rollback. You should only permit the rollback if you are familiar with the data model and know how the attributes relate to each other.

Select a set from the journal list. Using the RMT menu or the function bar on the right hand side of the screen, the "Undo value update" function can be accessed.

If the journal entry in the operation field of the list has the value UPDATE, and the rollback flag is set (Rollback permitted field), and is the owner of the journal or base object set, then the attribute value is reset to the old value, no matter whether the new value matches the current value according to the journal entry. If several sets were selected for the same attribute and for the same base object set, and the function was accessed for those, the old value of the oldest journal entry should finally appear, for example, in the contact set. You can check this after refreshing the contact set. A corresponding journal entry with the RESET action is created in the journal list for the change made.