Extending it

Acknowledgement handlers

A format needs to say which of its document types is the envelope receipt and which is the document receipt. That is one small class, and it is the only one consulted before the built-in mapping.

The module knows that CONTRL answers an EDIFACT interchange and APERAK answers an EDIFACT document. For a format of your own, or for a partner who insists on a variant of a format we ship, you say so yourself.

The layer map

One method, answering per layer.

[LunoLakeEDIDocumentFormatAttribute(enumLiteralStr(LunoLakeEDIDocumentFormat, SIMPLEDI))]
public final class LunoLakeEDIExampleAckTypes extends LunoLakeEDIAckTypeHandler
{
    public LunoLakeEDIDocumentType ackDocumentType(LunoLakeEDIAckLayer _ackLayer)
    {
        switch (_ackLayer)
        {
            case LunoLakeEDIAckLayer::Envelope:
                return LunoLakeEDIDocumentType::SIMPLEDI_ENVACK;

            case LunoLakeEDIAckLayer::Document:
                return LunoLakeEDIDocumentType::SIMPLEDI_DOCACK;
        }

        return LunoLakeEDIDocumentType::None;
    }
}

Registered against the format rather than against a document type.

Returning none for a layer switches that layer off for the format, exactly as an unsupported format behaves. A format with only an envelope receipt answers for one layer and returns none for the other.

This one overrides the built-ins

Every other seam is consulted only when the module has no answer of its own. This one is consulted first. That is deliberate: it lets you override what a receipt looks like in a format we already ship, for a partner whose implementation differs from the standard.

The acknowledgement types themselves

Each is a document type with its own handler, and they are the shortest handlers you will write. Three methods, and every other default left alone.

documentFormat, the format it belongs to.
businessProcess, returning the envelope or document acknowledgement process in both directions.
isAckAcceptanceCode, which decides whether a status code off the wire means accepted.

Everything else stays at its default because an acknowledgement builds no outbound contract, resolves no anchor, stages nothing, compares nothing, and never processes automatically.

Both directions, on purpose

The routing reads the business process and not the document type, so an acknowledgement type has to answer with an acknowledgement process whichever way it is going. A handler that answers one thing outbound and another inbound works for the half you tested and quietly breaks the other.

Acceptance codes

The one place to be careful. Answer true only for codes you know mean accepted, and let everything else fall through to false. An unknown code read as acceptance turns a rejected invoice into an invoice nobody chases, and that is a mistake you find out about at the end of the payment term.

Sending them

An acknowledgement is sent under an ordinary outbound agreement: the partner, the acknowledgement document type, and the format mapping that renders it. Receiving them needs nothing beyond the layer map, because the module knows what to do with a receipt once it can tell that it is one.