Function map — the outbound and inbound chains, function by function

1. Where everything is stored

Nothing in the two chains is stateless: each step leaves a trace, and knowing which table holds what is half of any diagnosis.

2. OUT — a customer invoice becomes an e-invoice

The chain

1. A USER VALIDATES AN INVOICE (or clicks Generate, or a mass action, or the API / cron)
2. TRIGGER BILL_VALIDATE

   • setInvoiceValidatedInThisRequest() — the marker the PDF hook reads
   • fetchLastknownInvoiceStatus(), then setEInvoiceStatus()
   • -> extlinks: NOT_GENERATED (in scope) or IGNORE (out of scope)

   core/triggers/interface_98_modEInvoicing_EInvoicingTriggers.class.php:172
3. the core then rebuilds the invoice PDF
4. HOOK afterPDFCreation()

   • the single entry point of the generation
   • afterODTCreation() forwards to it

   class/actions_einvoicing.class.php:69
5. the five gates, in order

   • 1. isEInvoiceGenerationInProgress() — we are the ones rebuilding: stop
   • 2. mustManageEInvoice() — out of scope (B2C, foreign third party...)
   • 3. isIgnoredStatus() and status != DRAFT
   • 4. EINVOICING_EINVOICE_IN_REAL_TIME, and not EINVOICING_DISABLE_SYNC_DOLI_TO_AP
   • 5. checkRequiredinformations() — -1 aborts or warns, per option
6. non blocking: checkRecipientRoutableForSend() only warns
7. ProtocolManager::getProtocol()

   • EINVOICING_PROTOCOL -> CIIProtocol or FacturXProtocol

   class/protocols/ProtocolManager.class.php:123
8. protocol->generateInvoice($invoice, $outputlangs, $pdfPath)

   class/protocols/CIIProtocol.class.php:544
9. generateXML()

   class/protocols/CIIProtocol.class.php:338
10. buildinvoicelines.inc.php

    • collects $invoiceData and $linesData
    • reads Facture and its lines, mysoc, buyer, contacts, Account,
    • Project, Expedition/Commande, VAT dictionary, einvoicing_routing

    lib/buildinvoicelines.inc.php:1
11. buildXML()

    • arrays -> CII DOM, gated by the profile

    class/protocols/CIIProtocol.class.php:2065
12. checkBusinessRules()

    • EN 16931 safety net, and: does the document claim
    • the amount the invoice claims (warn, or abort in strict mode)

    class/protocols/AbstractProtocol.class.php:203
13. the file that is actually transmitted

    CII

    • dol_copy() to
    • <output>/<REF>/<REF>_cii.xml

    class/protocols/CIIProtocol.class.php:544

    Factur-X

    • resolve the source PDF, merge,
    • restore the metadata ->
    • <REF>_facturx.pdf (PDF/A-3)

    class/protocols/FacturXProtocol.class.php:81
14. then, still inside generateInvoice()

    • hook afterEinvoiceCreation (other modules)
    • setEInvoiceStatus(STATUS_GENERATED) -> extlinks
    • checkFileSizeLimit() -> warnings
15. back in afterPDFCreation()
16. EINVOICING_AP_PRECHECK == 'auto' ? the PA validator, per provider

    SuperPDP

    • has_validator = 1
    • the file is validated at the platform
    • -> extlinks.ap_precheck_status / _result
    • a failure blocks the auto-send below

    class/providers/SuperPDPProvider.class.php:1038

    Esalink (Hubtimize)

    • has_validator = 0
    • nothing is validated at the platform
    • -> no ap_precheck_* is ever written
    • by hand from the card: -1, no validator

    class/providers/EsalinkPDPProvider.class.php:412
17. EINVOICING_AUTO_SEND_ON_GENERATION ? the four conditions

    • the option is on
    • isInvoiceValidatedInThisRequest() — this rebuild follows a validation
    • empty(status.transmitted) and not isTransmittedLockActive()
    • the precheck did not fail
18. provider->sendInvoice($invoice) — the deposit, per provider

    SuperPDP

    • api.superpdp.tech/afnor-flow/v1/
    • POST flows (multipart), then
    • GET flows/{id}?docType=Metadata
    • extlink AWAITING_VALIDATION, then the ack

    class/providers/SuperPDPProvider.class.php:1100

    Esalink (Hubtimize)

    • hubtimize.fr/api/orchestrator/v1/
    • POST flows (multipart), then
    • GET flows/{id}?docType=Metadata
    • extlink AWAITING_VALIDATION, then the ack

    class/providers/EsalinkPDPProvider.class.php:431

The manual paths join the same chain further down, through the two shared helpers, so their gates can never diverge from the automatic one:

Function by function

What the document says, and where it comes from

buildinvoicelines.inc.php is the whole Dolibarr → EN 16931 mapping. Anything it does not fill simply does not exist in the transmitted document — which is why an audit of a missing field always starts in this file, never in buildXML().

3. OUT — a lifecycle status leaves Dolibarr (CDAR)

The three ways a status is emitted

1. who fires, and on which invoice

   212 Encaissee — on OUR OWN invoice (we are the seller)

   • for each invoice paid by this payment, amount > 0
   • -> sendCashedInStatus()
   • AUTOMATIC, no option: the reform wants every
   • cash-in, partial ones included

   core/triggers/interface_98_modEInvoicing_EInvoicingTriggers.class.php:277

   205 Approuvee — on a SUPPLIER invoice (we are the buyer)

   • shouldSendApprovedOnValidation()
   • (EINVOICING_SEND_APPROVED_ON_VALIDATION, off by default)
   • or the card button, which validates the draft first
   • then sends only if the validation did not already

   core/triggers/interface_98_modEInvoicing_EInvoicingTriggers.class.php:302

   211 Paiement transmis — on a SUPPLIER invoice

   • EINVOICING_SEND_PAYMENT_SENT_STATUS
   • + getSommePaiement() > 0 + isEInvoice()
   • + not hasSentStatusMessage(211)

   core/triggers/interface_98_modEInvoicing_EInvoicingTriggers.class.php:361

   210 Refusee, and 205/206/207/208 by hand

   • doActions('confirm_sendStatusMessage')
   • -> sendStatusMessage($object, code, reasonCode)

   class/actions_einvoicing.class.php:564
2. provider->sendStatusMessage() — per provider, same path

   SuperPDP

   • is the code sendable for that object ?
   • CdarHandler::generateCdarFile()
   • POST flows, flowSyntax CDAR
   • storeStatusMessage(), then the verdict

   class/providers/SuperPDPProvider.class.php:2975

   Esalink (Hubtimize)

   • is the code sendable for that object ?
   • CdarHandler::generateCdarFile()
   • POST flows, flowSyntax CDAR
   • storeStatusMessage(), then the verdict

   class/providers/EsalinkPDPProvider.class.php:1798
3. CdarHandler::generateCdarFile()

   • who issues (SE or BY), who receives, the MDT-73 ladder below,
   • and the MDG-43 blocks: MEN for a 212, MPA for a 211

   class/utils/CdarHandler.class.php:271
4. POST flows (multipart, flowSyntax CDAR)
5. storeStatusMessage()

   • direction OUT, validation left pending

   class/einvoicing.class.php:3335
6. the PA verdict comes back: ajax poller, or the next synchronization
7. updateStatusMessageValidation()

   • updates the row, then dispatches

   class/einvoicing.class.php:3496
8. onOutboundStatusMessageValidated()

   • the only side effect: a 210 accepted by the PA
   • abandons the local supplier invoice

   class/utils/SupplierInvoiceHelper.class.php:639

Function by function

The MDT-73 ladder — who the CDAR is addressed to

1. Getting this wrong is what makes the platform answer "Electronic address (MDT-73) is invalid" or "no matching invoices found".
2. status 212, our own invoice

   • recipient = the BUYER, thirdpartyidprof(), scheme 0002
3. every other status (supplier invoice, we are the buyer): first rung that answers wins

   • 1. fetchDefaultRouting($vendor) — a routing recorded in Dolibarr — origin 'routing'
   • 2. BT-34 of the received invoice — the vendor said where it is — origin 'einvoice' (its own scheme is kept, not relabelled 0225)
   • 3. provider->checkRecipientDirectory(SIREN) — the national directory — origin 'directory'
   • 4. getBuyerCommunicationURI($thirdparty) — the SIREN, as a guess — origin 'thirdpartyid'
4. $cdarHandler->recipientURIID and ->recipientURIIDOrigin keep the answer, so the caller can name the address and the vendor in the error it shows.

4. IN — the synchronization

The chain

1. CRON "EInvoicing flows synchronization", hourly (declared in modEInvoicing::$cronjobs)
2. Document::cronSyncFlows()

   • provider = PDPProviderManager::getProvider(EINVOICING_PDP)
   • syncFromDate = getLastSyncDate()
   • maxflows = EINVOICING_FLOWS_SYNC_CALL_SIZE (100)

   class/document.class.php:1572
3. provider->syncFlows() — the one real difference between the two

   SuperPDP

   • api.superpdp.tech/afnor-flow/v1/
   • POST flows/search, no total in the answer
   • walks the updatedAfter cursor
   • MAX_SYNC_BATCHES batches at most
   • discards the flows already stored

   class/providers/SuperPDPProvider.class.php:1782

   Esalink (Hubtimize)

   • hubtimize.fr/api/orchestrator/v1/
   • POST flows/search, the answer has a total
   • one single call sized on that total
   • no cursor, no batch loop
   • discards the flows already stored

   class/providers/EsalinkPDPProvider.class.php:856
4. provider->syncFlow($flowId, $call_id) — same shape on both

   SuperPDP

   • api.superpdp.tech/afnor-flow/v1/
   • GET flows/{id}?docType=Metadata
   • fills a Document: flow_type, direction,
   • syntax, profile, ack_*, submittedAt
   • then the switch below

   class/providers/SuperPDPProvider.class.php:2209

   Esalink (Hubtimize)

   • hubtimize.fr/api/orchestrator/v1/
   • GET flows/{id}?docType=Metadata
   • fills a Document: flow_type, direction,
   • syntax, profile, ack_*, submittedAt
   • then the switch below

   class/providers/EsalinkPDPProvider.class.php:1223
5. switch ($document->flow_type)

   "CustomerInvoice"

   • an invoice WE sent, seen from the PA
   • Facture::fetch(0, trackingId)
   • -> the flow is only linked

   "SupplierInvoice"

   • a RECEIVED invoice -> the import below
   • direction must be 'In': an outgoing one
   • is not a received invoice, the flow is
   • marked processed and nothing is booked

   class/providers/AbstractPDPProvider.class.php:460

   "CustomerInvoiceLC"

   • a status ON ONE OF OUR INVOICES
   • -> the CDAR section below

   class/utils/CdarHandler.class.php:173

   "SupplierInvoiceLC"

   • direction 'In': a status the VENDOR issues
   • direction 'Out': OUR status coming back validated
   • -> fetchStatusMessages(flowId) then
   • updateStatusMessageValidation()

   class/providers/SuperPDPProvider.class.php:2812

   "" (empty)

   • a late validation answer for a sent invoice
   • -> extlinks STATUS_ERROR + agenda event
6. $document->create($user)

   • one row in einvoicing_document, always,
   • whatever happened above

Two return shapes matter and are easy to confuse:

• error (res < 0, no postponeflow): something was stored, or the flow is unusable. It is reported as a business action for the operator.
• postponed (res < 0 and postponeflow = 1): nothing was stored, the flow stays pending and the next run retries it. Used when no readable document could be fetched, or when the invoice references a document Dolibarr does not hold yet. That flag is the reason one bad flow no longer stalls every invoice queued behind it.

A received document becomes a supplier invoice

1. fetchImportableFlowDocument()

   • tries docType=Converted, then Original, then ReadableView
   • each through detectProtocolFromContent()
   • none readable -> postponeflow + "set the AP conversion format"

   class/providers/AbstractPDPProvider.class.php:460
2. createSupplierInvoiceFromSource()

   • per-call temp file in_<uid>.xml (two concurrent syncs
   • must not parse each other's invoice)
   • finally: commit or rollback the import transaction

   class/protocols/CIIProtocol.class.php:677
3. doCreateSupplierInvoiceFromSource()

   class/protocols/CIIProtocol.class.php:793
4. parseInvoiceHeader() / parseInvoiceLines()

   • pure XPath over $invoiceTemplate and $lineTemplate

   class/protocols/CIIProtocol.class.php:1739
5. _syncOrCreateThirdpartyFromEInvoiceSeller()

   • OWN TRANSACTION, committed before the import starts
   • 1. Societe::fetch() by idprof1..6 from the seller GlobalIDs
   • 2. else by VAT number (several matches = error)
   • 3. else, only with EINVOICING_THIRDPARTIES_MATCH_ON_NAME, findNearest()
   • 4. else Societe::create(), or refuse if auto-creation is off

   class/protocols/CommonProtocol.class.php:456
6. === FROM HERE ON, ONE TRANSACTION FOR THE WHOLE IMPORT ===
7. the two refusals that come before anything is written

   • already imported for this supplier ? findIdByRef(ref_supplier, socid) -> only (re)attach the files
   • every referenced document present ? no -> postponeflow, with a link to the screen that creates the missing invoice
8. fill the FactureFournisseur, then

   • createHeaderDiscounts() — document-level allowances -> DiscountAbsolute
   • FactureFournisseur::create($user) <- CORE
   • _saveImportedBuyerOrderReference() -> llx_einvoicing_extrafields
   • _linkSupplierInvoiceToPurchaseOrder() -> core add_object_linked('order_supplier')
9. createSupplierInvoiceLinesFromSource()

   • per line: findProductFromEinvoiceLine()
   • else _findOrCreateProductFromEinvoiceLine() -> Product::create()
   • else the vendor's default routing product
   • else a free line

   class/protocols/CIIProtocol.class.php:1236
10. createSupplierInvoiceLinesIntoDatabase()

    • INSERT a bare facture_fourn_det row, then core updateline()
    • deliberately NOT addline()

    class/protocols/CIIProtocol.class.php:726
11. then everything that hangs off the invoice

    • deposits: getOrCreateDepositDiscount() -> DiscountAbsolute::create()
    • Societe::update() to flag the third party as a supplier if needed
    • createHeaderChargeLines() — document-level charges (BG-21) as lines
    • ProductFournisseur::update_buyprice() — supplier prices of the imported products
    • insertOrUpdateExtLink($supplierInvoiceId, 'invoice_supplier', $flowId)
    • saveEInvoiceFileToSupplierInvoiceAttachment() x2 — document and readable view
12. alignInvoiceTotalsWithDocument()

    • every line exists now: confront the totals with BT-112 / BT-115
    • core update_price()

    class/protocols/CIIProtocol.class.php:3463

Function by function

XML → Dolibarr, the field map of the import

A status arrives on one of our invoices

1. flow_type "CustomerInvoiceLC"
2. CdarHandler::readFromString()

   • GET flows/{id}?docType=Original -> the CDAR XML
   • AcknowledgementDocument.ReferenceReferencedDocument.IssuerAssignedID
   • -> Facture::fetch(0, $ref), entity checked

   class/utils/CdarHandler.class.php:173
3. the three writes

   • insertOrUpdateExtLink(facture, flowId, ProcessConditionCode, ...) — the card and the list now show the PA status
   • storeStatusMessage(..., direction IN, reasonCode) — the status history of the invoice
   • addEvent('STATUS', ...) — the agenda of the invoice
4. The switch on the lifecycle code is, today, deliberately empty: no Dolibarr status is derived from an incoming code.

5. Cross-cutting

The locks, and what they key on

Who consumes what the two chains wrote

The options that decide, by chain

What actually differs between the two providers

6. Where to look when it goes wrong