Jobs

Jobs execute recurring or manual background work such as imports, exports, alerts, OCR, synchronization, and report delivery.

Each job should have a clear description, expected runtime, owner, and troubleshooting path.

Job Types

Type	Purpose	Examples
Manual job	Started by an administrator or authorized user.	Import bank data, import daily rates, send report now.
Scheduled job	Runs periodically without user interaction.	E-mail import, overdue reminders, nightly synchronization.
Processing job	Continues document processing after upload or import.	OCR, PDF conversion, invoice analysis, workflow start.
Integration job	Exchanges data with external systems.	ERP import/export, MQTT agent action, payment status update.
Reporting job	Creates or sends reports.	Due-date report, reminder report, audit or exception reports.

Job Metadata

Every operational job should be documented with:

• job identifier,
• display name,
• short description,
• owner or responsible team,
• required role or ACL,
• required parameters,
• expected runtime,
• retry behavior,
• relevant logs,
• expected result.

This makes the admin page understandable and reduces the need to read code during support cases.

Manual Execution

When a job is started manually, the user context matters. Some jobs run with the current user's permissions, while others elevate to a server or service user internally.

Before starting a manual job, verify:

• the user has permission to run the job,
• required parameters are filled correctly,
• the job is safe to run more than once,
• external systems are available,
• the expected output location or target system is known.

Parameter Dialogs

Some jobs ask for parameters before execution, such as date ranges, currencies, clients, or export options.

Parameters should only be mandatory when the job cannot choose a safe default. Optional filters should remain optional, especially for administrative import jobs such as daily rates.

Idempotency

An idempotent job can be run repeatedly without creating duplicate or inconsistent data. This is ideal for imports and synchronization.

When a job is not idempotent, document the risk clearly. Examples include jobs that send e-mails, create payment files, export invoices, or trigger external bookings.

Status and Result

After running a job, administrators should be able to answer:

• Did the job start?
• Did it finish?
• Which records were processed?
• Which records failed?
• Was data changed?
• Was an external system called?
• Is a retry possible?

If the job only says "error", improve logging or add a more specific error response.

Access Control

Job access should follow least privilege:

• general users should not see administrative jobs,
• operational admins should see module-specific jobs,
• technical admins may see system jobs,
• destructive or external-booking jobs should require explicit confirmation.

For Invoice installations, import/export jobs often require roles such as accounting, trustee, module admin, or administrator roles depending on customer policy.