If one of the notifications is not sending, most likely the issue is not an error or malfunction, but the fact that two notifications were created for this ESF — and one of them is redundant.
This is exactly the situation the client encountered: after checking the ESF documents and related notifications, it turned out that for one invoice the system (or the user) generated two notifications. One of them had already been sent correctly earlier — it did its job and there are no issues with it. The second one turned out to be a duplicate that doesn't need to be sent at all.
What to do in this situation:
1. Check how many notifications are linked to the specific ESF — if there are two, that's already a reason to figure out which one is the current one.
2. Look at the status of each notification: if one has already been sent and accepted, it means the obligation for this ESF has already been fulfilled.
3. The second, redundant notification does not need to be sent — it carries no additional information and is technically superfluous.
Thus, a "non-passing" notification in this case is not a malfunction, but a normal situation: the system is simply trying to send a document that is no longer needed, because its role was already fulfilled by the first notification.
Frequently Asked Questions
Do I need to delete the redundant notification? In the reference analysis itself, it was specifically stated that the second notification does not need to be sent — since it is redundant and duplicates a task that has already been completed.
How do I know which notification is the "correct" one? Look at which one was sent and accepted earlier — that is exactly the working, current document.
Why do two notifications arise for one ESF? This happens with repeated actions on a document — for example, if the notification was generated more than once. It's important to check before resending whether the required notification has already been created earlier.