Import skipped forever when split is on but download_batch_transactions is off

[barredterra]

Problem

When Split Batch Transactions is enabled and Download Batch Transactions is disabled, unresolved batch transactions still abort the entire EBICS import.

In that case camt.054 is never downloaded, so the retry path can never succeed.

Current behavior

In sync_ebics_transactions:

1. camt.054 is only fetched if download_batch_transactions is set.
2. Import still proceeds with batch_xml=None.
3. If split_batch_transactions is on and a batch has no sub-transactions (len(transaction) == 0), UnresolvedBatchTransactionError is raised.
4. The request is marked Skipped, the bank is asked to resend (confirm_download(success=False)), and a warning suggests trying again later.

That assumes camt.054 may appear on a later sync. With download disabled, it never will.

Why this is easy to hit

• Split Batch Transactions defaults to enabled.
• Download Batch Transactions defaults to disabled.
• The two checkboxes are independent; nothing requires download when split is on.

Expected behavior

Either:

• Do not treat missing camt.054 as a transient skip when download is disabled (import the batch as a single transaction / proceed without waiting), or
• Tie the settings together so split cannot leave the sync stuck without download.

Relevant code

• banking/ebics/utils.py — sync_ebics_transactions, process_camt_document, UnresolvedBatchTransactionError
• EBICS User fields split_batch_transactions / download_batch_transactions

[john-frandsen]

Good catch — and the diagnosis is exactly right. The two defaults (split on, download off) are independent and both ship that way out of the box, so a fresh install is in a guaranteed-stuck state the first time it hits a batch entry. A few things worth layering in on the fix:

1. The retry-forever loop is a real correctness bug, not just an annoyance. confirm_download(success=False) tells the bank "I didn't process this camt.054, send it again." But download_batch_transactions=False means the EBICS client never requests camt.054 again. So the skip path is asserting "this is transient, it'll arrive later" into a configuration where it provably never will. That's the load-bearing inconsistency — a skip is only valid if download can later produce the document.

2. The code is right to not fabricate sub-transactions when TxDtls are absent. camt.054 (bank-to-customer debit notification) is the document that carries the breakdown of a batch (Ntry with BCH/BCHG code) that camt.053/camt.052 only summarize as a net Amt. Without it, the sub-transactions genuinely don't exist in the data you received — inventing them would be worse than failing. So the fix belongs at the settings/guard layer, not the parser.

3. Fail-safe options, in order of how much I trust them. (a) Tie the toggles: split=True must imply download=True, validated at EBICS-user save time (reject or auto-enable) — this kills the footgun at the source and is the one I'd ship first. (b) Degrade instead of skip: when split is on but download is off and a batch has no TxDtls, import the batch as a single net transaction (the summarized Amt) rather than raising UnresolvedBatchTransactionError. (c) Keep the skip, but only when download is on.

4. If you take option (b), the single-row placeholder needs a flag so a later camt.054 doesn't double-count. Today there's no breakdown because download is off; tomorrow someone flips download on and the breakdown arrives — the loader has to recognize "this Ntry already has a net-row placeholder" and replace it rather than append the breakdown alongside. A batch_resolved / is_net_placeholder flag on the row (or matching on (account, entry_ref, booking_date)) closes that window. Otherwise you trade one bug for its mirror image.

5. On the amount/date side: keep both booking and value date on the net row. Batch entries frequently settle on a value_date different from their booking_date, and the net Ntry carries both. Whichever you surface to the user, persist both — reconciliation against the bank's running balance is the thing that has to net out, and that reconciles on booking date while cash availability reconciles on value date.

6. The Ntry/NtryDtls/TxDtls absence is the exact split point. A batch Ntry with zero NtryDtls, or NtryDtls with no TxDtls, is precisely the case the download toggle controls — and it's the same absence that an MT940 :60F:-only statement exhibits. Worth handling the "no breakdown available" branch as a first-class path (net row + a batch_unresolved=True marker the user can filter on) rather than an exception, because it's a legitimate terminal state for plenty of accounts that simply don't subscribe to the breakdown feed.

7. Quick guard you can ship today while the bigger fix lands: at the top of sync_ebics_transactions, if split_batch_transactions and not download_batch_transactions, either log a hard warning on every sync or short-circuit to the net-import path. That stops new installs from silently accumulating stuck skips the moment they enable split.