Account statement, mailing, demand letter, refund — behaviour

Statement (statementpdf)

1. Right: core modify + statement; pdftemplate and dlbtdocstore must exist; content scope on the filter.
2. Content: debit/credit, overpayments, rate sources.
3. Filed according to the client's “statement” → “document” → “invoice” storage rule (fileDocument), linked to the client company (addDocLink).
4. If a letter is needed, a printable demand letter is produced too; if e-mail can be sent, the response returns the mail form data.

Errors: error_statement_partner, error_statement_client, error_statement_empty, error_statement_doc, error_pdf_engine, error_pdf_no_storage.

E-mail (sendmail) and demand letter (dunning)

• The envelope button appears with canAction(sendmail) and opens the shared mail/send form (event_key=dunning_letter, object_type=settlement_statement). mail/send requests the attachment through the internal call generatemaildoc(), which runs the statement generation with the plan's filters and the approved letter text. generatemaildoc() checks no right itself; statementPdfRun uses the statement right.
• The demand letter (buildDunningLetter) has a 15-day payment deadline, signatories and a list of annexes, from the letter template or the text edited on the form; the letter branch of statementPdfRun requires canAction(dunning), otherwise no letter is produced. Without a template: error_letter_no_template.

Overpayment refund (refundfile)

From the overpayments of one client and one partner (getPartnerCredits) it builds an HCT (GIRO) XML from the client's active own bank account (dlbtgiro->hctXml), files it in the document centre and creates a draft payment document with transaction::addTransaction(); the response returns a preview link. Right: core modify + refund. Errors: error_refund_none, error_refund_client, error_refund_partner, error_refund_own_account, error_refund_account, error_pdf_no_storage.

Data model

Table names carry the installation's own prefix in the database: doc, doc_link, transaction, transaction_item; models and services: masterdata/bankaccount, dlbtgiro, dlbtdocstore, pdftemplate.

Permission keys

statement, sendmail, dunning, refund — all exist only in the legacy permission table and are not classified in the feature master.