Repository navigation
[Master]-CH] SEPA XML Files should append the Address 1 + '' + Address 2 fields under <PstlAdr><StrtNm> node if we use "Address 2" as Building Number for QR-Bills - #13273
Fixes4BC (neeleshsinghal) merged 6 commits into
Conversation
Good Sense Reviewer - Round 1Recommendation: Request ChangesWhat this PR doesThe PR combines The shared helper handles one or both address fields being empty and preserves the existing recipient events. However, the employee setter calls an undefined procedure, so the CH BaseApp cannot compile. The new tests generate empty address values, so they do not prove that building numbers are exported. Problem-solution fitFit: Partial Combining the two address fields addresses the missing building number at the shared export-buffer level. The compilation error prevents the fix from being used, and the new fixtures do not test a populated street and building number. SuggestionsS1 (🔴 High): Call the existing helper for employee addresses S2 (🟠 Moderate): Use nonempty addresses in the version 09 tests S3 (🟠 Moderate): Use nonempty addresses in the version 03 tests Risk assessment and necessityRisk: All four recipient types and payment exports that use the CH table are affected, including non-Swiss formats within CH. Public signatures, field definitions, and event timing are unchanged; there is no schema upgrade or amount-calculation change. The current employee call blocks compilation. Necessity: The change is needed to avoid dropping building numbers from exported creditor addresses when Address 2 holds them. Without a fix, users must correct exported XML or combine address data manually, which conflicts with keeping street and building number separate. A shared CH helper is a small, targeted solution.
|
…Bug-656806-SEPA-XML-Files-should-append-the-Address-1-Address-2-fields
Good Sense Reviewer - Round 2Recommendation: AcceptWhat this PR doesThe PR combines The helper now handles either address field being blank, preserves the existing recipient events, and keeps the field-length limit. The compile blocker and both ineffective tests from round 1 are fixed. Status of previous suggestions
New observations (commits since round 1)None - changes only addressed prior suggestions. Risk assessment and necessityRisk: The shared CH payment export table feeds customer, vendor, employee, and bank recipient data. The helper keeps the 70-character limit and existing recipient event timing, so the remaining regression surface is limited to address formatting. Necessity: The change is needed so Swiss payment exports keep the building number when it is stored in
|
Good Sense Reviewer - Round 3Recommendation: Accept with SuggestionsWhat this PR doesThe PR combines The credit-transfer filler sets the mode before selecting the recipient setter. In Swiss mode, the helper joins populated fields with one space and keeps the length limit; otherwise, it returns the first 70 characters of Problem-solution fitFit: Strong The reported Swiss credit-transfer case now retains the street and building number, while other export paths keep their original address-only result. Direct-debit formatting remains unchanged rather than gaining the same concatenation. Status of previous suggestions
New observations (commits since round 2)S4 (🟠 Moderate): Cover the new non-Swiss address guard Risk assessment and necessityRisk: The shared helper changes recipient address formatting for customer, vendor, employee, and bank credit transfers in CH. The current non-Swiss branch preserves the original primary address; direct-debit formatting also stays unchanged. The four added tests check real Swiss vendor export buffers for populated and blank Necessity: Retaining a building number stored in
|
Pull request was closed
Fixes AB#656806