Tourist tax return — system description
Data model of IFA return headers and accommodation lines, save validation, conditions and side effects of XML and PDF generation, the two delete modes and the content scope.
Overview
Monthly tourist tax return per client: one row is one return (client + municipal setting + year + month + type) with guest night and exemption data per accommodation. The calculation and the portal XML are produced by the system's IFA service, the PDF by the PDF template engine; both go to the document centre (object nav_ifa, category tax_return).
Data model
Table names carry the installation's own prefix in the database.
| Table | Purpose | Main fields |
|---|---|---|
ifa_return | return header | client, setting, year, month, type, filler and submitter data, signature, xml_doc_id, pdf_doc_id, date_generated, status (9 = trash) |
ifa_return_line | accommodation line | property, address snapshot, lines 1–8 and sub-lines |
ifa_setting | municipal setting | tax rate, empty portal form |
company | client and submitter company | tax number, seat, statistical number |
Operated properties come from the masterdata/property model (operator column added by migration).
Process
- List: filter by company group and client, property, period (quick range); per row client, municipality, period, type, rate, guest nights, taxable nights, tax, discount, payable, generation date, XML/PDF document, "outdated file" flag (changed after generation), list of missing data; totals.
- XML download: built at once from the saved data and returned as a download, independent of the document centre (the button is shown only when no XML is filed).
- Helper endpoints: the client's seat, statistical number (master, otherwise the latest return) and operated properties; the submitter company's e-mail, phone and members.
- Save: without a chosen setting it looks one up from the accommodation's town and the year; accommodation lines come from the client's operated active properties with the address as a snapshot; calculation by the IFA service; submitter e-mail and phone filled from the contacts when empty. Writes only to the database; the answer lists missing data; the record is read back after saving.
- Generation: with incomplete data (tax number, seat, 17-digit statistical number, filler name, e-mail, phone, signature, submitter, authorisation type, property) nothing is generated and the gap is named; builds the XML from the setting's empty form and the PDF with the
nav_ifa_returntemplate (Hungarian captions if a Hungarian language file exists); deletes the old XML/PDF with the document centre cleanup operation and files the new ones by the client's storage rule (nav, otherwisedocument); success only if both documents were created. File removal deletes one generated file from the document centre and from the header. - Send by e-mail: redirect to the mail sending module, attachments from the document centre
nav_ifalink. - Delete: with
deletethe generated XML/PDF are cleaned up and the return is physically deleted; with onlystatusdeletestatus 9 (trash).
Validation
- Client and setting are required; the setting's year must equal the return's year; year 2000–2100, month 1–12; signature date in a valid format.
- The property must be an operated property of the client and appear only once; postcode/town and street or lot number are required; it must be in the setting's town; at least one property.
- No duplicates: client + setting + year + month + type.
- Lines 2 + 3 + 4 cannot exceed line 1; line 7 cannot exceed line 6.
Permissions
- Layer 2:
list(list, XML, helper endpoints),add/editon saving (addfor a new record; without permission the form is read-only),generate,sendmail,delete,statusdelete,debug. - Layer 3: the list, the XML (another company's return cannot be downloaded), the company identifier of the helper endpoints, saving (the existing row AND the posted client, plus the submitter company), generation and deletion stay within the content scope; trash rows follow the trash visibility rule.