Enhance banking transaction data structure and validation
Playwright Tests / test (push) Has been cancelled

- Increased the length of the NameOfPayer field from NVARCHAR(60) to NVARCHAR(140) in the banking transactions function, table, temporary table, and user-defined type to accommodate longer names.
- Expanded the SepaRemittanceInformation field from VARCHAR(150) to VARCHAR(200) in the banking transactions function for more detailed remittance information.
- Modified the stored procedure fds__setBankingtransaction_done to return additional transaction data (ValueDate and Amount) along with the success flag for improved notification messaging.
- Added validation in MFRClientConfig constructor to ensure the provided URL is not null or empty, enhancing error handling for configuration settings.
This commit is contained in:
Stefan
2026-07-04 16:37:23 +02:00
parent aaf062fd77
commit c98be7b23f
24 changed files with 287 additions and 74 deletions
+48
View File
@@ -36,6 +36,7 @@ public class BankingService : IBankingService
using var act = FuchsTelemetry.StartActivity("banking.parse");
var sw = Stopwatch.StartNew();
var tbl = schemaDatatable?.Clone() ?? BuildDefaultSchema();
ApplyKnownColumnWidths(tbl);
var diag = new ParseDiagnostics();
// Buffer once so we can sniff the format and (re)parse from the bytes.
@@ -280,6 +281,53 @@ public class BankingService : IBankingService
}
}
/// <summary>
/// The schema DataTable fetched from <c>[dbo].[fds__tt__bankingtransactions]</c> via
/// <c>SELECT TOP(0) * FROM @tmp</c> comes back with <see cref="DataColumn.MaxLength"/> = -1
/// for every string column — ADO.NET does not carry character-length facets through a
/// table-variable-typed SELECT. Without a real MaxLength, <see cref="SetCell"/>'s truncation
/// guard never engages, so an over-long real-world CAMT field (routine for rich SEPA
/// remittance/reference data) sails through parsing and the temp-table bulk copy — which
/// builds its columns from this same DataTable and creates them as NVARCHAR(MAX) — only to
/// throw "String or binary data would be truncated" once the merge stored procedure inserts
/// into the real, correctly-width-constrained target table. These widths mirror
/// [dbo].[fds__tt__bankingtransactions] / [dbo].[fds__bankingtransactions] (kept identical by
/// design) so truncation happens safely here instead of failing the whole import downstream.
/// </summary>
private static readonly Dictionary<string, int> KnownColumnMaxLengths = new()
{
["AccountIdentification"] = 50,
["FundsCode"] = 1,
["AccountNumberOfPayer"] = 30,
["BankCodeOfPayer"] = 11,
["CompensationAmount"] = 50,
["CreditorReference"] = 30,
["CreditorsReferenceParty"] = 50,
["CustomerReference"] = 50,
["EndToEndReference"] = 50,
["JournalNumber"] = 10,
["MandateReference"] = 50,
["NameOfPayer"] = 140, // ISO 20022 Max140Text — some banks put the full postal address in <Nm>, not just a name
["OriginalAmount"] = 150,
["OriginatorsIdentificationCode"] = 150,
["PayersReferenceParty"] = 150,
["PostingText"] = 30,
["SepaRemittanceInformation"] = 200,
["UnstructuredData"] = 390,
["UnstructuredRemittanceInformation"] = 390,
["DebitCreditMark"] = 2,
["TransactionTypeIdCode"] = 3,
};
private static void ApplyKnownColumnWidths(DataTable tbl)
{
foreach (var (columnName, maxLength) in KnownColumnMaxLengths)
{
if (tbl.Columns.Contains(columnName) && tbl.Columns[columnName]!.DataType == typeof(string))
tbl.Columns[columnName]!.MaxLength = maxLength;
}
}
private static DataTable BuildDefaultSchema()
{
var t = new DataTable();