Repository navigation
Inbound Peppol: second supplier's invoice with the same number is dropped and acknowledged #8
Description
Dedup in _poll_provider only looks at cbc:ID. If supplier A and supplier B both send invoice 2026001, B's isn't stored but still gets acknowledged, so it's gone from the mailbox. Adding the sender endpoint, company and document type to the dedup key would fix it.
Activity
sync: l10n_cssk@8949f588
Rad0van commentedon Oct 24, 2026
Confirmed and fixed in 792f382 (
edi_base,edi_base_peppol).The duplicate check is now a seam,
edi.message._inbound_duplicate_domain, returning the domain to search. The default (provider, biztalkmessage_id, direction) is unchanged for EDIFACT.edi_base_peppolwidens it with what you suggested: the document kind (Invoice/CreditNote/ …), the sender's endpoint and the receiver's endpoint. These are the same values_compute_envelope_fieldsstores, so the search compares like with like. A re-delivery of the same document is still recognised and acknowledged once.If the sender's endpoint can't be read at all, the document is stored rather than deduplicated. A duplicate kept is a nuisance; a document acknowledged without being stored is gone.
Tests (
edi_base_peppol/tests/test_peppol_inbound_dedup.py) cover: two suppliers' 2026001 both kept and both acknowledged, the same supplier's 2026001 twice stored once, an invoice and a credit note with one number, one supplier invoicing two of our companies through one mailbox, and a document with no sender endpoint. Without the fix the three "different document" cases fail.One thing worth knowing if you read the model:
edi.messagestill declaresUNIQUE(message_id, direction)through_sql_constraints, which 19.0 no longer reads, so no such index exists (checked on a fresh install). It's now commented as unsafe to port tomodels.Constraintas it stands, since that would bring this bug back as a failed insert.sync: l10n_cssk@8949f588