Built-in Tests

The app ships its own tests covering setup and record type processing – useful after configuration and after an update.

Why these tests exist

Whether a DATANORM import works correctly depends on many details: unit mapping, posting groups, number series, price sources. The built-in tests exercise that chain on their own, without needing real supplier files.

Good occasions to run them:

• after configuration, as a sign-off
• after an app update
• when an import produces unexpected results and you want to narrow down the cause

You start the tests from DATANORM Setup.

Feature tests

The Run Feature Tests action checks the core functions in sequence:

Area	What is checked
Licence	Is the licence valid?
Setup	Are the required values in place?
SFTP	Is the SFTP configuration coherent?
Import	Is a test file read correctly?
Synchronisation	Does it produce items?
Export	Can a DATANORM file be generated?

Record type test cases

The Run Record Type Test Cases action verifies record type processing against the DATANORM specification. Each case imports a small sample file embedded in the code and compares the result with the expected value.

Test case	Verifies
REG-V4-ARTICLE	The A and B record of a V4 article are merged into one record.
REG-V4-PRICE	All article blocks of a V4 price line are read.
REG-V4-DISCOUNT	Discount groups from the R record are taken correctly.
REG-V5-ARTICLE	A V5 article is read in full from the A record.
REG-DUPLICATE	The same article number appearing repeatedly in a file creates no duplicate entry.
REG-PURCH-PRICE	An imported price produces a purchase price line.
REG-VENDOR	Vendor assignment applies to the session and its staging data.
REG-SET-V5	A V5 set becomes an assembly BOM.
REG-SET-V4	A V4 set becomes an assembly BOM.
REG-SET-OPTIONAL	Optional lines are included or left out according to the setting.
REG-SET-NESTED	A nested set is resolved across multiple levels.

Reading the results

Show Test Results opens the list of test runs. Each row names the test case, the outcome and, on failure, the detail message with the expected and the actual value.

Outcome	Meaning
Passed	The case behaves as expected.
Failed	The result deviates. The detail message names the deviation.
Skipped	The case could not run, for example because a prerequisite is missing.

Notes on running them

The tests create test data and process it. Run them in a sandbox environment, not in a production tenant.

A failing test usually points at the setup, not at a defect. If a posting group is missing, for instance, the synchronisation check fails. Fix the cause and start the run again.

If a test still fails after you have corrected the setup, send the detail message to support, see Support Contacts.