Creating and managing analytic axes

Analytic axes and their sections are created and modified in the Administration > Axes module of Lucca. In Cleemy Expenses, a link in Configuration > Analytic axes also allows you to access this interface.

Consulting axes and their sections

chrome_RiT7uMHZvm.png

On the left of the screen, you can select an existing axis and create new ones. In this example, there are three axes: Project, Sub-project, and Cost center. The labels are arbitrary, and they function under the same principal!

On the right, you can consult the sections of a selected axis. Here, there are three in the “Project” axis.

The “New” button allows you to add a new analytic section to a selected axis.

The properties of an axis

Each axis has several properties which can be displayed thanks to the “Configuration” button.

chrome_GrfFZ5iQCe.png

The primary properties of an axis are the following:

  • The name of the axe is multilingual
  • The “Appear in the user’s file” check box allows you to define a default value to this axis for each employee in their personal file.
  • An axis may overlap with another (i.e. its parent). The “Define as a sub-axis” option allows this to be managed. Please reference the section about overlapping axes found below.
  • The last two options allows you to indicate if it is necessary to display the code and/or name to the user when he or she enters the analytic imputations of an expense.

The properties of an analytic section

When you create an analytic section, there is information that needs to be completed.

chrome_qbfCquraxL.png

  • The most important is the code: it is usually this value that will be used in accounting exports. The sections of an axis must all have a different code.
  • The project name allows you to display relevant information to employees when they enter their expenses.
  • Access can be public (all users can make attributions to a section) or restricted. In the latter, you can list the people, departments or legal entities that can make attributions to a section. These restrictions are cumulative. For example, restricting the “Marketing” department and the “Lucca” legal entity means that all employees from “Lucca” will have access to the section as well as all users from the “Marketing” department, independently from their legal entity.
  • A section can be deleted but only if nothing has been attributed to it. In this case, it can only be archived so that no new imputations can be made.

Overlapping analytics

Lucca manages overlapping imputations. In this example below, the “Sub-project” axis is a child of the project axis: the sections that it contains are linked to the sections of the Project axis in a way that allows users to first select the project and then one of the sub-projects in relation to the previously mentioned project.

chrome_KftHYQYgSZ.png

To indicate if an axis overlaps with another, you must complete the “Define as a sub-axis” field in its configuration interface.

By default, a section of the parent axis can have several children in the sub-axis, but a section of the sub-axis can only have one parent in the axis. The “items can have several parents” option changes this behavior.

The sections of the child axis can therefore be attached to those of the parent:

  • Either by completing the “Parent in the … axis” field when you open the properties of a child axis’ section
  • or by indicating the child of section of a parent axis from the properties of the latter.

Archiving an analytic section

You will not be able to delete an analytic section once a user has made an attribution to it. However, you can archive them using the link that will appear when you hover over it with your mouse.

 

chrome_sLUGeQcOkA.png

 

Archived sections can be displayed and reactivated thanks to the filter that can be found above the list of sections.

Importing analytic sections

Using the Administration > Import module and the “Analytic sections” section, you can import CSV files in order to create many sections with a line for each section to be created or modified.

The file contains different fields (indicate their names in the first line) of which some are mandatory (marked with a * below).

  • code*: this should only be for sections of the same axis
  • name*: a section’s label in the language of the user who is performing the import. If you want to specify the label language, you must make as many columns as there are translations and name them using the following format: multilingualName (xx-XX) when xx-XX is the language’s code. For example, fr-FR for French, en-GB for British English, en-US for American English, etc.
  • axis*: the axis ID. This is visible in the administration interface of the axes and can be found in the top right.
  • isPublic: accepts the true value (axis is visible by all users) or false (in which case, you must indicate department or user restrictions (cf. departments and users).
  • active: allows sections to be archived with the false value or to reactivate one with the true value.
  • Access restrictions are managed in four fields. You can indicate the people or departments authorized to make attributions to a section. Either in column by separating them with commas, or by creating as many columns as there are elements to allow.
    • departments: indicate the label of departments allowed to make attributions to the section.
    • departmentsWithSubs: functions like departments, with the exception that mentioned sub-departments will also be automatically included.
    • users: allows you to indicate users with access to the section by preferably entering their login. You can also use other unique user identifiers, such as email addresses. For more security, you can use users.mail, users.login, etc. as a field label in order to communicate to the module the identifier you are using.
    • Filiation links between sections:
      • childrenAxisSections allows you to list the child section(s) of a section. If your codes are integers, the import module risks confusing them with axis IDs. Therefore, you should use childrenAxisSections.code instead.
      • parentsAxisSections functions in the same way but in the child lines.

It is also possible to plan automatic imports. The file to be imported must be located in the SFTP/FTPS server which is consulted everyday. The file format you should use is the same as the one for a manual import.

Importing default analytic values for users

For axes with the “Appears in the user file” option, it is possible to perform an import of users in order to complete this field.

The name of the column to use in the import is “axisValues.code.” This must be completed with the code of the analytic section to be associated with the user. If there are several activated axes, a default value can be specified for each axis by including several fields labelled “axisValues(1).code,”  “axisValues(2).code,” etc. It is useful to indicate the ID of the axis in question in parentheses which will be visible in the interface of the analytic axis administration.


Finally, the list of every default section value for a user obeys the cancel and replace rule: if there is at least one “axisValues” column in the file, every user included in the file will have their complete list of values for every reset axis with the provided sections even if only the values of a single axis have been imported.

Page content

Was this article helpful?
1 out of 1 found this helpful