Automatic User Maintenance in Acubiz
This guide describes the technical requirements and data structures applicable for automatic import and maintenance of user data in Acubiz.
The guide covers the following topics:
General requirements for the import file
Handling of company structures (Single vs. multiple company structure)
Specification of data fields (Column overview)
Examples of file setup based on configuration
General Requirements for the Import File
To ensure a flawless integration, data must be provided in accordance with the following guidelines:
Format: The file must be provided as a semicolon-delimited (
;) text file.No headers: The file must not contain headers/column names. The first line must contain the first user data.
One consolidated file: All user data across all companies must be provided in one single file.
Company Structures and EMSID
Acubiz supports different corporate structures. The definition of your structure determines which data is required:
One Company (Single Accounting)
If the company consists of only one entity, the solution is set up with one database. Acubiz automatically assigns all imported users to this company. Therefore, it is not necessary to specify a company ID (EMSID) in the import file.
Multiple Companies (Group Structure)
If the solution includes multiple companies (e.g., divided by countries or legal entities), Acubiz consists of one common user database and multiple company databases (EMS’s). In this scenario, it is mandatory to include an EMSID (company key) for each employee, so the system can identify the employee’s primary company.
Note: The company key is agreed upon during implementation and will typically match the company’s internal company codes.
Field Definitions and Column Structure
To avoid errors in data mapping, fields must be provided in the exact order shown in the table below. Depending on your configuration, the file stops at the column that covers your needs.
| Column | Field Name | Description | Status |
| 1 | Import ID | Unique and permanent key for the user. Used to create/update the user and must never be changed during the employee’s lifetime. | Mandatory |
| 2 | Initials | The user’s initials or other unique identification. | Mandatory |
| 3 | First Name | The employee’s first name. | Mandatory |
| 4 | Last Name | The employee’s last name (often indicated with initials in parentheses). | Mandatory |
| 5 | Email Address | The employee’s email, which also functions as the login username. | Mandatory |
| 6 | Employee Number | The employee’s internal ID in, for example, HR or payroll system. | Configuration-dependent |
| 7 | Approver (ID) | Specifies the Import ID (column 1) of the employee’s primary approver. | Configuration-dependent |
| 8 | EMSID | The company key that defines the employee’s primary company (e.g., DK, SE, NO). | Required for multiple companies |
| 9 | Financial Dimension 1 | For example, cost center or department. Applied to all transactions in the flow. Acubiz supports up to 9 dimensions. | Optional |
| 10 | Creditor Number | The employee’s creditor number in the ERP system (used for payments). | Optional |
| 11 | Power of Attorney Limit | The user’s approval limit amount. Specified as an integer in the company’s system currency. | Optional |
Examples of File Setup
Below are four concrete examples of how the file content should be structured depending on the company’s setup in Acubiz.
Example 1: Basic User Data (Single Company Only)
Used if you only have one company and do not map approvers or dimensions automatically.
Plaintext
1001;aaa;Anders;Andersen (aaa);aaa@mail.comExample 2: User Data with Employee Number and Approver
Here the file is extended to column 7. Notice how Anders (1001) has Bo (1002) as approver in column 7, and vice versa.
Plaintext
1001;aaa;Anders;Andersen (aaa);aaa@mail.com;1001;1002
1002;bbb;Bo;Jensen (bbb);bbb@mail.com;1002;1001Example 3: Multiple Companies (With EMSID)
Here the company relation is added in column 8 (e.g., DK, SE, NO) for correct placement in the group structure.
Plaintext
1001;aaa;Anders;Andersen (aaa);aaa@mail.com;1001;1002;DK
1002;bbb;Bo;Jensen (bbb);bbb@mail.com;1002;1001;DK
1003;ccc;Anne;Frandsen (ccc);ccc@mail.com;1003;1002;SE
1004;ddd;Hanne;Jensen (ddd);ddd@mail.com;1004;1002;NO
1005;eee;Jens;Hansen (eee);eee@mail.com;1005;1002;NOExample 4: Full Automatic Update (Including Dimensions, Creditor, and Power of Attorney)
This example shows the extended integration where financial dimensions, creditor number, and approval limits (power of attorney) are updated automatically.
Plaintext
1001;aaa;Anders;Andersen (aaa);aaa@mail.com;1001;1002;DK;10;123;0
1002;bbb;Bo;Jensen (bbb);bbb@mail.com;1002;1001;DK;10;124;20000
1003;ccc;Anne;Frandsen (ccc);ccc@mail.com;1003;1002;SE;15;125;0
1004;ddd;Hanne;Jensen (ddd);ddd@mail.com;1004;1002;NO;20;126;0
1005;eee;Jens;Hansen (eee);eee@mail.com;1005;1002;NO;20;127;0ℹ️ Additional needs? The final data delivery and any need for more dimensions or special fields will be clarified in close dialogue with your consultant during the implementation phase. See the complete list of available import fields via our documentation portal.
ℹ️See a complete list of import fields related to user import
Comments
0 comments
Please sign in to leave a comment.