https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43674 --- Comment #10 from Phan Quang Minh <minhpq@tinhvan.com> --- Thank you for pointing that out — you are right, and I should have checked which schema revision the core work targets rather than assuming. For the record, illtransactions.org currently publishes five: v1_1, v1_2, v1_3, 2021-2 (June 2022) and 2021-3 (December 2025). We built against v1_2, which is two revisions behind the one you used. That is on us and we are moving to 2021-3. I have now diffed the two. None of the three reports changes: Envelope (this bug). 2021-3 declares ISO18626Message identically, same namespace, same required version attribute, wrapping the same xs:choice of six message types. Your patch is correct against 2021-3 as well as v1_2. Element order (bug 43694). 2021-3 uses xs:sequence throughout — 68 of them — so order is still significant. The reproduction in that bug stands unchanged. Agency identifiers (bug 43695). type_agencyId still carries agencyIdType and agencyIdValue. Worth noting that 2021-3 is stricter here than v1_2 was: in type_supplyingAgencyMessageHeader both supplyingAgencyId and requestingAgencyId are mandatory, so the hardcoded values are not an optional field being filled in with a placeholder — they are required content that currently carries no information. Where the revisions do differ, and it affects us rather than you: - v1_2 has a single shared header element. 2021-3 splits it into type_requestHeader, type_requestingAgencyMessageHeader and type_supplyingAgencyMessageHeader, with different content models. Notably the supplying header has no requestingAgencyAuthentication, which matches what I said earlier about there being nothing in a supplyingAgencyMessage to authenticate the sender with — it is explicit in 2021-3. - multipleItemRequestId is mandatory in v1_2 but optional in 2021-3. We had been filling it with a copy of requestingAgencyRequestId to satisfy v1_2, which was always a bit of a fiction; under 2021-3 we can simply omit it. - confirmationHeader drops multipleItemRequestId; messageInfo loses offeredCosts, retryAfter and retryBefore to the new retryInfo; serviceInfo renames preferredFormat to itemFormat and gains preferredEdition and loanCondition; supplyingAgencyMessage gains retryInfo and shippingInfo; consortialId is new. So the remaining timestamp issue I mentioned in comment #6 is unaffected by any of this: xs:dateTime means the same thing in every revision. Noted that you have made 43694 depend on this one. That ordering makes sense to me — the envelope patch touches the same serialisation path an ordering fix would have to change. -- You are receiving this mail because: You are watching all bug changes.