Reference
Troubleshooting
VLDTION refuses loudly rather than continuing quietly. Every message below names the cause, because a silent partial import is worse than a blocked one.
Imports
| What you see | What it means |
|---|---|
| Mapping is incomplete | A required field has no column. The mapping step lists which ones; map them and the import unblocks. |
| Rows require attention | Those rows could not be normalised, an unparseable date, a non-numeric amount, a missing identifier. They are not imported, and the count is stored against the dataset so the difference is never silent. The panel lists the reason and the row numbers. |
| No rows could be normalised from this file | Every row failed. Usually the wrong sheet, or a header row that is not the first row. Check the column mapping preview before importing. |
| The file could not be read | The file is not a readable CSV or XLSX, or it is a workbook feature this build does not open. VLDTION never evaluates spreadsheet formulas; it reads the last computed value stored in the file. |
| Field extraction unavailable | The file declares a specification version this build has no layout profile for. It is still validated structurally; fields are not read at positions that may have moved. See BKMVDATA. |
Findings and runs
| What you see | What it means |
|---|---|
| INSUFFICIENT DATA on a rule | The rule governs those records but the export does not carry a field it needs, the document falls outside the period its source covers, or, for a cross-period rule, the workspace holds no earlier period for this client. This is a result, not an error, and it is never counted as a pass. |
| VLDTION asks for a second file | A Hashavshevet MOVEIN export is fixed-width with no header: MOVEIN.PRM carries the field positions. Attach it and the import continues. Nothing is read against an assumed layout. |
| Rules listed as unable to run, before the import | The export was recognised and read, but does not carry a field those rules need. They will report insufficient data. Everything else still runs. |
| UNSUPPORTED on a rule | The rule cannot run against this source format in this build. |
| A second run appeared after a configuration change | Correct. Changing configuration produces a new run rather than rewriting the old one, and the rule versions that produced historical findings are kept with them. |
| Notes and statuses carried into the new run | Findings are content-addressed: the same records failing the same rule produce the same identifier, so what you recorded follows the finding across runs. |
Storage
| What you see | What it means |
|---|---|
| The workspace will not open | In the browser build the database lives in the browser's own storage, which private-window and storage-cleared sessions discard. The desktop build keeps a SQLite file instead. |
| A backup was written by a newer version | It restores, and anything this build does not understand is ignored rather than guessed at. The warning names the schema versions involved. |
| That file is not a VLDTION workspace backup | Restore only accepts a vldtion.workspace.v1 document. Nothing was changed. |
Before anything destructive
Erasing a workspace cannot be undone. Write a backup from Settings first. It is a single JSON file holding every dataset, run, finding state and note.