Bank import rules — system description
Data model, saving and deletion rules, pre-fill logic and permission keys of the rule table used by the bank statement recognition engine.
Overview
The parameter table of the recognition engine. A rule consists of conditions (own account, partner account, direction, transaction code, memo fragment — each with its own use switch) and the data of the resulting item (supplier or customer company, item category, custom item name, sort order, status). The bank import run uses the rules. Rules are global and not tied to a company.
Data model
Table names carry the installation's own prefix in the database.
| Table | Purpose | Relation |
|---|---|---|
transaction_rule | the rules: conditions with use flags, resulting item, sort order, status | read and written by the bank import model (getRules, saveRule, setRuleStatus) |
transaction_import_row | imported statement rows | a row can reference the rule that matched it; the list counts matched rows from here |
Process
- List: filter by account number (owner or partner), code, status and assigned company; per row name, condition summary, sort order, status and number of referring rows.
- Pre-fill from a bank import row (
import_row_id): normalised accounts, direction, code heuristics (bank fee, cash in/out), supplier or customer by direction; for a bank fee the bank's company from the GIRO code of the account number. - Save: only ticked conditions are stored; account conditions are normalised to the canonical 24-digit identifier.
- Per-row on/off switch on the status field.
- Delete: physical, only if no import row references the rule; otherwise an error with the count.
- Back button: if the user came from the raw import list, it returns to the filtered bank import list.
Rules and validation
- Name is required ("Warning: Rule name is required!").
- At least one condition is required, otherwise the rule would match every row.
- The item category is the canonical key of the coding rules; the custom item name only overrides the displayed name.
Permissions
- Layer 1: the list page opens with base access to the rule or the bank import path; saving and deleting require modify permission on the bank import path.
- Layer 2: key checks go through one shared function: the own key (
list,edit,delete,debug) OR the bank importrulepermission is enough. The new-rule button checks only the ownaddkey. - Layer 3: no content scope — rules are global master data.
The add, edit and delete keys are not in the function catalogue, so a non-super-admin user can in practice edit through the bank import rule permission.
Known limitations
- Rules cannot be restricted to a client: a rule affects the import of every client.