Fix duplicate EU bank transfer emails in batch payments

[peregrine-2024]

: Resolves duplicate EU bank transfer emails being sent multiple times for sale orders. This fix addresses ticket #67591 by implementing a persistent flag in the 'osi_l10n_us_payment_nacha_email' module to track email sending status and prevent duplicate execution of the 'action_send_detailed_payment_emails' method. The solution includes proper state management and concurrent execution protection through database flags with transaction handling to ensure each batch payment group processes emails only once. Technical details: Enhanced method validation, added persistent tracking flag, implemented transaction-safe execution logic. Reference: https://pm.opensourceintegrators.com/web#menu_id=218&cids=1&action=324&model=helpdesk.ticket&view_type=form&id=67591

[peregrine-2024]

🛠️ Automated Fix: Prevent Duplicate Bank Transfer Emails

This pull request addresses Ticket #67591 — a bug where the Bank Transfer Email was being sent multiple times for the same batch payment.

🔧 Changes Made

The core fix was implemented in the following file:

• osi_l10n_us_payment_nacha_email/models/account_batch_payment.py

Key Technical Improvements:

• Added Database-Level Locking:
  Introduced with_for_update() to lock the account.batch.payment record during email sending. This prevents concurrent executions from sending duplicate emails.

• Atomic Flag Setting:
  The remittance_email_sent field is now updated atomically before sending emails. This ensures only one process can proceed with sending the email for a given batch.

• Improved Error Handling:
  If a validation error occurs (e.g., no AP contact email found), the remittance_email_sent flag is reset so the email can be retried after correction.

• Logging Enhancements:
  Added _logger usage to track when duplicate sends are skipped, improving observability.

✅ How It Fixes the Issue

Previously, without locking mechanisms, concurrent triggers or repeated calls to the email-sending method could result in the same email being sent multiple times. With this change:

• Only one execution of the email-sending logic can proceed per batch.
• Concurrent calls will either wait for the lock or detect that the email has already been sent.
• The system is now resilient to race conditions and duplicate sends.

🧪 Testing & Review Notes

• Ensure that the fix works correctly under concurrent load scenarios.
• Verify that resetting the flag on validation errors allows proper retries.
• Confirm that logging output helps identify edge cases in production.

Please review and test thoroughly before merging.