Stefan
c741535aec
Playwright Tests / test (push) Canceled after 0s
- Added a new SQL script to address the "String or binary data would be truncated" error in mfr sync by widening the Note fields in service objects and companies to NVARCHAR(MAX). - Updated the table types and associated stored procedures to accommodate the changes, ensuring compatibility with existing data. - Queued a re-sync for previously rejected rows due to truncation issues. - Created application logins for fuchs_fds and fuchs_web with placeholder passwords for initial setup. - Introduced functions for invoice backdating and invoice date retrieval to streamline invoice processing. - Developed a password generation function with customizable parameters for length and character types. - Added a random number generation function to support password creation.
3.7 KiB
3.7 KiB
status, date, applyTo, supersededBy
| status | date | applyTo | supersededBy | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Accepted | 2026-09-30 |
|
0035 — The invoice date is DateFinalized everywhere
Context
ADR 0032 made DateFinalized the invoice date for the PDF, the e-invoice (BT-2) and the number
sequence, and introduced backdating (which only moves DateFinalized). Everything else — invoice
lists, revenue reports and charts, the DATEV export, document lookups, the request details — still
dated and grouped invoices by DateCreated, the moment the draft was created. A backdated invoice
therefore showed September on the document and October in every list, report and in DATEV, and any
invoice drafted in one month and finalised in the next had the same split.
Decision
- One invoice date, everywhere: the German calendar day of
DateFinalized, falling back toDateCreatedonly for drafts. Both columns are stored in UTC. - One implementation per side:
[dbo].[fds__fn_invoiceDate](DateFinalized, DateCreated)in SQL andInvoiceDates.IssueDatein C#. No proc converts or picks the date itself. - Applies to: the DATEV export (period filter,
Belegdatum,Belegfeld 2), the invoice lists (fds__getInvoices_list,list2,list_vario: period filter,Belegdatum,DateOfCreation, ordering, overdue fallback), the revenue reports (fds__r_*: year/month filters and grouping,fds__r_getBalanceThisMonth), document lookups (fds__getFDSDocument,fds__getReportDocument),fds__getRequest_details(new columnInvoiceDate, shown in the request's invoice list), and the invoice date shown in reminders (fds__prepReminder,fds__createReminder,fds__getReminder). - Reminders use the same rule for their own date: the reminder PDF's date is the reminder's
DateFinalized(German day), draft:DateCreated. - No transition safeguard. The switch applies to all periods, past and future; already exported DATEV periods are not reconciled (confirmed by the business owner, 2026-09-30).
DateCreatedkeeps its meaning — the creation timestamp of the row — and is still returned where callers read it as such. Draft previews stamp it withDateTime.UtcNowto match the stored column.
Consequences
- Reports and exports for a past period can differ from what they showed before this change: an invoice drafted in month M and finalised in M+1 now counts in M+1.
- Filters on the invoice date are not SARGable (they were not before either:
CAST(DateCreated as date)). Acceptable at the current table size; an indexed computed column is the follow-up if it matters. - Any new list, report or export that shows or groups invoices by date must use
fds__fn_invoiceDate— neverDateCreatedor a rawDateFinalized.
Alternatives considered
- Keep
DateCreatedin lists/reports,DateFinalizedonly on documents — rejected: the same invoice would carry two dates, and backdating would never reach the books. - Transition safeguard for already exported DATEV periods — rejected by the business owner.