Repository navigation
A minor version that writes the twelve points of the first conformance reading of an orchestrator implementation into the standard (Ratified Decisions 56 to 67, one per point). The protocol now has 43 message types in 12 categories, 61 schemas and 45 validated examples. protocolVersion is "0.5", and every schema identifier is re-issued as urn:ipproto:schema:0.5:.
0.5.0 is additive. Nothing is renamed, removed or made required for an existing message, and no rule of 0.4 is relaxed. A 0.4 message is valid under 0.5. See For implementers below.
Added
Envelope: recordedBy, optional. The actor that entered a message on the originating actor's behalf, with the originator's consent, and the person there who entered it. The originator stays the originator and the message binds it; userContext stays reserved for a user of the originating actor. Decision 56.
2 messages, category Payments. Invoice Disputed: the payor disputes an invoice, with a closed list of seven reason categories, optionally naming the disputed lines by position and the disputed amount. Invoice Cancelled: the payee cancels an invoice, with a closed list of four reason categories, optionally naming the replacement invoice and a cancellation document. Accepting an invoice still has no message; an invoice is never changed, a correction is a cancellation and a new Invoice Issued. Decision 57.
Document type creditNote.
Record resolution (Conventions): how a receiver resolves an actor, role declaration, document or authority claim URI that a message names, from the actor that issued the record; a recommended, non-normative HTTPS shape and the address type urn:ipproto:address:recordResolution. Decision 59.
Tax treatment notStated, provisional under Open Question 7: the sender does not know the treatment; the invoice document says what applies. Decision 61.
Conformance page with the orchestrator profile: how a claim is made and checked (met, partly met, not met, not applicable), the three profiles side by side, ten general requirements G1 to G10, core requirements OR-R, OR-W, OR-I, OR-L, OR-D, OR-V, OR-J, and conditional modules for procurement, payments, subscriptions and assets. Decisions 63 and 67.
Payment note. Where an ERP or accounting system pays outside the exchange, Payment Authorized and Payment Executed do not apply; the invoice messages still do. Decision 64.
Identifier schemes urn:ipproto:scheme:vat and urn:ipproto:scheme:companyRegister on Actor Reference, and the optional identifier field registrationAuthority, which the schema requires with companyRegister. Decision 65.
6 examples (45 in all) and seven glossary terms.
Changed
Work Instruction, decided without a change: an instruction states only agreed clocks and named deliverables; an implementation that lacks them fixes its data, not the message. Decision 60.
Milestone Failed / Milestone Abandoned: only the primary actor reports a failure; a work requester that ends a milestone because its provider did not perform abandons it, as decisionAuthority. Decision 62.
Actor Reference: immutable once published, not once registered; a later change of legal name or jurisdiction takes a new actor URI. Decision 66.
A message is a record, not only a transmission (Conventions): every action between two organizations that has a message is recorded as that message, also where all parties work on one platform; the organization that acted is the originator. Decision 67.
Generated TypeScript types regenerated from the 0.5 schemas.
Fixed
Service Deliverable: assertions is conditional, as the schema always had it; the page had called it required. Decision 58.
For implementers
Schema identifiers are re-issued. Every schema $id is now urn:ipproto:schema:0.5:. The 0.4 identifiers keep naming the 0.4.x set. New messages carry "protocolVersion": "0.5".
A 0.4 message is still valid. All 39 examples of 0.4.1 validate unchanged against the 0.5 schemas. The 0.5 schemas differ from the 0.4 schemas in the envelope, Actor Reference and Invoice Issued, and by the two new message schemas.
A 0.4 receiver keeps working if it degrades on unknown message types and values, as VERSIONING.md requires. It ignores recordedBy and reads such a message as the originator's, which is right.
Strict validators. A receiver that validates strictly against the 0.4 schemas accepts recordedBy and registrationAuthority, because unknown fields pass, and rejects Invoice Disputed, Invoice Cancelled and the tax treatment notStated.
One caution. recordedBy on the envelope and registrationAuthority on an identifier are now defined names, and an identifier of scheme urn:ipproto:scheme:companyRegister must carry registrationAuthority.
The package ships 61 schemas and 45 validated examples; npm run validate in schemas/ checks them.
Full changelog: https://github.com/GregXIV/ip-operations-protocol/blob/v0.5.0/CHANGELOG.md Changes since 0.4.1: v0.4.1...v0.5.0