Exports
Exports transfer documents, booking data, payment files, or status information to external systems.
Administrators should validate export logs, generated files, ERP responses, and retry behavior.
Export Categories
| Export | Purpose | Typical risk |
|---|---|---|
| ERP invoice export | Transfers booking header and accounting rows to ERP. | Duplicate booking or rejected payload. |
| Payment file export | Creates payment files for banks or payment processing. | Incorrect payment data or duplicate payment file. |
| Status export | Sends payment, booking, or lifecycle status to an external system. | Stale or inconsistent status. |
| Document export | Sends files and metadata to another archive or portal. | Missing files or wrong metadata. |
| Report export | Generates CSV, Excel, PDF, or DOCX output. | Wrong filters or incomplete data. |
ERP Exports
ERP exports usually require:
- valid client/accounting mapping,
- creditor or debtor address,
- bank connection if payment data is exported,
- currency,
- tax code,
- account and cost center,
- booking date and delivery date,
- accounting rows,
- document or attachment if required by the ERP.
Typical causes of ERP export errors:
| Error area | What to check |
|---|---|
| Address | Missing ERP address number, inactive address, wrong creditor/debtor type. |
| Bank | Missing IBAN, missing internal bank, wrong payment type. |
| Currency | Currency not imported, missing daily rate, ERP expects own exchange-rate handling. |
| Tax | Tax code missing, wrong ERP field, invalid combination with account. |
| Accounting | Missing account, cost center, amount, accounting area, or balancing issue. |
| Permission | Export user or service user lacks write/export permission. |
Payment Files
Payment files should be treated carefully because they can trigger real financial processing.
Before creating or sending payment files:
- verify selected invoices,
- verify bank account and IBAN,
- verify currency and amount,
- verify due date and payment terms,
- verify internal bank,
- check whether the file was already generated,
- confirm the target format and transmission process.
Retry Behavior
Export retry behavior must be explicit.
Safe retry depends on whether the external system has already accepted the export. If an ERP accepted a booking but centraQuest did not receive the response, a blind retry may create a duplicate booking.
For support cases, always capture:
- export job ID,
- object ID,
- external response,
- generated payload or file,
- external booking/reference number if available,
- current lifecycle state,
- whether the external system already contains the record.
Export Validation Checklist
After an export, verify:
- the source object changed to the expected status,
- the export response is stored or logged,
- generated files are available,
- external references are written back,
- payment or booking status is visible,
- failed records remain actionable,
- retries are documented.