Since the fix for #536 (merged in 2.22.0, commit a40c1e6), Mustang supports BT-18 via IExportableTransaction.getObjectIdentifierReferencedDocument() and generates:
ram:AdditionalReferencedDocument
ram:IssuerAssignedID...</ram:IssuerAssignedID>
ram:TypeCode130</ram:TypeCode>

</ram:AdditionalReferencedDocument>
However, for EN16931 / XRechnung mappings of BT-18, the CII structure also allows / expects the optional scheme identifier (BT-18-1) using:

ram:ReferenceTypeCodeAJW</ram:ReferenceTypeCode>
Problem

ZUGFeRD2PullProvider does not output ram:ReferenceTypeCode for the BT-18 AdditionalReferencedDocument block, even if the IReferencedDocument provides a non-empty value.

Invoice.setObjectIdentifierReferencedDocument(String id) creates a ReferencedDocument(id) and forces TypeCode=130, but offers no convenient overload to set ReferenceTypeCode (scheme) without manually constructing and mutating ReferencedDocument.

Expected XML
ram:AdditionalReferencedDocument
ram:IssuerAssignedIDID unique</ram:IssuerAssignedID>
ram:TypeCode130</ram:TypeCode>
ram:ReferenceTypeCodeAJW</ram:ReferenceTypeCode>
</ram:AdditionalReferencedDocument>
Reproduction (pseudo-code)
Invoice inv = new Invoice();
ReferencedDocument rd = new ReferencedDocument("ID unique");
rd.setReferenceTypeCode("AJW");
inv.setObjectIdentifierReferencedDocument(rd);

new ZUGFeRD2PullProvider().generateXML(inv);
Suggested fix

In ZUGFeRD2PullProvider, when writing the BT-18 AdditionalReferencedDocument, add:

ram:ReferenceTypeCode if getReferenceTypeCode() is not null/empty.

Add an overload in Invoice:

setObjectIdentifierReferencedDocument(String id, String referenceTypeCode) (and optionally Date) to avoid manual object creation.

This would align BT-18 with how Mustang already handles other referenced document blocks where ReferenceTypeCode is emitted.

Related:

#536 / PR #1018, merged commit a40c1e6.