CCTS and JSON Discussion paper

G. Ken Holman

Crane Softwrights Ltd.

$Date: 2016/10/09 01:46:51 $(UTC)


Table of Contents

1. Overview
2. Current XML-based approaches to JSON
3. UN/CEFACT Core Component Technical Specification
3.1. CCTS component review
3.2. Portability with XML applications
4. Marshalling CCTS to JSON
4.1. BIE names
4.2. Document ABIE expression
4.3. ASBIE expression
4.4. BBIE expression
4.5. Extension expression
5. Unmarshalling JSON to CCTS
5.1. Overview of unmarshalling
5.2. JavaScript syntax
5.3. Python syntax
6. Example serializations of business documents
6.1. Examples overview
6.2. UBL-Invoice-2.1-Example-Trivial.json
6.3. Modified invoice example
6.4. UBL-TransportationStatus-2.1-Example.json

1. Overview

In a recent UBL TC teleconference it was observed that a JSON instance is more in line with an XML instance than it is with an XSD schema.

The UBL specification is a model of possible XML instances reflecting the business objects possible for a given document, and that model is expressed in XSD. The XML angle brackets express a single instance (hence the name!) of a set of CCTS-defined business objects needed to be exchanged between business partners.

So, to state the obvious, what is exchanged between business partners is that XML serialization of the given set of business objects of a given abstract business document. The XSD only exists as a guide for creation and a tool for validation. The XSD can be used by sender and receiver to know outside of a given application that the structure is as dictated by the committee, but the applications are simply working with the XML serialization in order to get the content.

This glosses over the XSD concept of the PSVI (post schema validation information set) that can be used by an application to interpret the lexical XML strings as known data types so that an application can process the data values instead of converting them. But I don't think we have an equivalent in JSON to have to address this.

So in the same way an application prepares XML from CCTS objects, in a JavaScript world it would prepare a JSON expression from CCTS objects. There is no role in the application for the XSD, and so would not need one for JSON. The XML programmer might have used the XSD to guide them in coding how the serialization would work, but they would go directly to XML angle brackets. I would think a JavaScript programmer would simply create the data structure, address it, and have it serialized as JSON.

Therefore, what was proposed in the TC meeting is that what we specify in UBL is the marshalling and unmarshalling of a set of CCTS objects to and from JSON syntax. No reference to XML, only to BBIEs, ASBIEs and Document ABIEs. That way we are framing the discussion in business objects that are up to the developer to express, only giving guidance on how to serialize those objects as a JSON stream for interchange.

A question we need to ask is whether this belongs as a separate UBL effort the way that Business Document Naming and Design Rules Version 1.0 was split off into a standalone specification. I propose we initiate a new project Business Document JSON Serialization Version 1.0 so that these concepts become formalized and simply applied by users of vocabularies described by CCTS.

Such a strategy also divorces the progress of these concepts from the progress of UBL 2.2. It won't hamper the release schedule of UBL 2.2.

For reference, this proposal uses the draft ISO/IEC 21778:2016, which is just an ISO cover over specification ECMA-404 (how would one know if they couldn't find it?):

This paper assumes the marshalling and unmarshalling happens directly to memory structures of the given language, so it is most likely that the developer will simply work with the information in the memory structures we guide them to use to express BBIEs, ASBIEs and Document ABIEs.

This proposal attempts to justify what might appear at first glance to be arcane syntax. But a rigourous approach should be appreciated by programmers.

2. Current XML-based approaches to JSON

One thing this CCTS focus allows is for us not to be constrained to XML syntax where it collides with JavaScript or JSON syntax. A good example is in namespaces where XML uses a colon, but the colon cannot be used when using dot notation for JSON structures. The same is true for the @ sign used by XPath for attributes.

It is not necessary to preserve the namespaces concept, but for completeness this proposal accommodates the expression of namespace URI strings if this is important for unambiguous identification. How these strings are used is outside the scope of this specification.

This proposal treats CCTS components and supplementary components simply by their name, not as namespace-qualified XML elements or as XML attributes.

Looking at an example XML to JSON converter, the one in the oXygen tool, some of their choices in the serialization of the content are questionable. For one, they actually use the English word "content" and I would think a serialization syntax would be language independent. So where they used "content", this proposal uses a single dollar sign.

Looking at the W3C example JSON-LD, http://www.json-ld.org, again it smells of XML with the use of @, which is unhelpful in JavaScript dot notation.

3. UN/CEFACT Core Component Technical Specification

3.1. CCTS component review

From a model perspective, the UN/CEFACT Core Components Technical Specification (CCTS) 2.01 http://www.unece.org/fileadmin/DAM/cefact/codesfortrade/CCTS/CCTS_V2-01_Final.pdfis used to define a class of business documents by specifying the available components to be used. An ABIE (aggregate) component specifies a collection of constituent components of ASBIE components (associations to other ABIEs) and BBIE components (basic indivisible portions of content). The Document ABIE is simply an ABIE that is not defined in the common library. A Document ABIE specifies the components at the apex of a business document. A Library ABIE specifies the components comprising an ASBIE. An assumption is that an ASBIE can be defined by a Library ABIE and not to a Document ABIE.

From an instance perspective, a given business document is comprised of its Document ABIE with its indivisible BBIEs and with its (divisible) ASBIEs that each have their own BBIEs and ASBIEs.

Each BBIE is defined by its data type. The available Core Component Types are summarized in Chapter 8 of the CCTS 2.01 specification. Each type has a mandatory content component and a number of optional supplementary components. The interpretation of the content is informed by the values of its given supplementary components. The data type content and supplementary component values are, ostensibly, either numbers or strings. Interpreting the strings to be abstract concepts such as date and time, or as true and false, is up to the program.

A name used in any given group is not prohibited from also being used in another group. For example, in the UBL vocabulary there is a Library ABIE named "Location" and a BBIE named "Location". This specification provides a mechanism, not based on namespace URI strings, to disambiguate names that might be sibling name/value pairs in an object.

A vocabulary based solely on CCTS has properties that are accommodated in this specification without needing also to accommodate the generalities of arbitrary XML markup. That distinction makes this serialization quite different from the serializations proposed in the community for XML documents.

For the purposes of this document, the http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.0/Business-Document-NDR-v1.0.html#S-DICTIONARY-INFORMATION section of the OASIS Business Document Naming and Design Rules Version 1.0 constrains how the CCTS components are defined.

For purposes of natural language independence, no words in any particular language are mandated by this specification. Of note, this specification exploits the use of the dollar sign for naming certain constructs, taking from CCTS terminology in a way that does not collide with a community's definition of a CCTS-based vocabulary.

3.2. Portability with XML applications

For portability between JSON applications and XML applications acting on the content, some assumptions about the CCTS model are presumed.

All BIE names shall be valid XML no-colon names, as used for the local name of an XML Namespace qualified name. Of note, the dollar sign allowed in a JSON name is not allowed in an XML name.

Certain BBIE data type content must be constrained by XML Schema Part 2: Datatypes (XSD) for portability with XML tools. Boolean values must only be expressed as "true" and "false", even though XSD also supports "1" and "0" for these values. Date and time values must be expressed using ISO 8601 as described by XSD. Binary object values must be expressed by XSD base64Binary in a string.

4. Marshalling CCTS to JSON

4.1. BIE names

There are four groups of names made from the names of the Document ABIEs, the names of BBIEs, the names of both Library ABIEs and the ASBIEs that point to them, and the names of extension scaffolding and metadata items. In fact there are many groups of Document ABIEs as each Document ABIE is in a group of one of only itself.

Note

These four groups of names are referenced in http://docs.oasis-open.org/ubl/Business-Document-NDR/v1.0/Business-Document-NDR-v1.0.html#S-NAMESPACES for XML serialization.

The namespace URI values applicable to all of the names found outside of foreign extensions in a given business document may be found as name/value pairs in the Document ABIE object for that document.

When two name/value pairs in a given JSON object have the same name but one of them is an ASBIE and the other is a BBIE, each name must be suffixed with, respectively, either "$S" or "$B" as appropriate and other names not in conflict shall not be suffixed. If all names of name/value pairs in a given JSON object are distinct, then all of the names shall have no suffix.

Note

A consequence of these rules is that when a CCTS-defined business vocabulary has no ABIE where a member ASBIE and a member BBIE have the same name, every possible JSON serialization will have no name suffixes.

Note

Users of a CCTS-defined business vocabulary will know where these rules may come into play before writing the application and so, for any given version of the vocabulary, an application writer will know when it may be necessary to check for a given name with either a suffixed name or a name without a suffix. If a future version of the vocabulary introduces a potential name collision, legacy applications may not be in a position to recognize the new use of a suffix. However, from a maintenance perspective, the application developer need only look for the use of those names where the collision has been introduced.

Editor's note only for consideration during review

We could elect to mandate the suffix on each and every item in order to be absolutely future-proof, but I truly believe it would be a rare (if ever) possibility for a vocabulary to be defined with two sibling ASBIE and BBIE items with the identical name. With UBL there is an ASBIE named "Location" and a BBIE named "Location", but they are never siblings. So even in UBL no name need ever be suffixed. Thus, I think we are justified in allowing the incredibly unlikely situation of a community revising an existing vocabulary to introduce a name collision.

4.2. Document ABIE expression

Each Document ABIE shall be represented as an object containing a single name/value pair.

The name of that pair shall be the local name of the Document ABIE.

The value of that pair shall be an object. The object may contain the following name/value pairs for documentary purposes, and for completeness should do so:

  • name "$D" with the value of the Document ABIE namespace URI;

  • name "$S" with the value of the ASBIE namespace URI (that is, the Library ABIE namespace URI);

  • name "$B" with the value of the BBIE namespace URI; and

  • name "$E" with the value of the extension namespace URI.

The Document ABIE object shall contain name/value pairs all of the ASBIE and BBIE members in actual use of those available as specified by the Document ABIE.

The Document ABIE object may contain a single name/value pair representing the apex of the scaffolding of foreign extension content. This name is defined by a specification of a given business vocabulary and may be different than that of other business vocabularies. However, all document types in a given business vocabulary should be using the same name for the apex of the scaffolding of foreign extension content.

Note

A Document ABIE has no associated metadata and so there is no need to accommodate anything akin to an attribute of an XML element.

An example of a serialized Document ABIE with some content elided by the ellipsis for brevity, leaving two BBIEs and an ASBIE that has two BBIEs:

{"Invoice":
 {
 "$D":"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2",
 "$S":"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2",
 "$B":"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2",
 "ID":[{"$":"123"}],
 "IssueDate":[{"$":"2011-09-22"}],
 "InvoicePeriod":[{
  "StartDate":[{"$":"2011-08-01"}],
  "EndDate":[{"$":"2011-08-31"}]
 }],
...
}}

4.3. ASBIE expression

Each sequence of one or more consecutive ASBIE components of the same name shall be serialized as a single name/value pair of its parent ASBIE or Document ABIE JSON object.

The one name for that pair shall be the name of the ASBIE. Only when there is another name/value pair for a non-ASBIE construct in the same object that has the same name as the ASBIE, the name of the ASBIE shall be suffixed with "$S".

The one value for that pair shall be a JSON array of one or more objects, each object representing, in array order, the sequence order of the consecutive ASBIEs.

Each ASBIE object in the array shall have as its name/value pairs all of the ASBIE and BBIE members in actual use of those available as specified by the ABIE that defines the ASBIE.

Note

An ASBIE has no associated metadata and so there is no need to accommodate anything akin to an attribute of an XML element.

Some examples of serialized ASBIEs … a party and two invoice lines:

  •  "AccountingSupplierParty":[{
      "Party":[{
       "PartyName":[{
        "Name":[{"$":"Custom Cotter Pins"}]
       }]
      }]
     }]
  •  "InvoiceLine":[{
      "ID":[{"$":"1"}],
      "LineExtensionAmount":[{"$":100.00,"currencyID":"CAD"}],
      "Item":[{
       "Description":[{"$":"Cotter pin, MIL-SPEC"}]
      }]
     },{
      "ID":[{"$":"2"}],
      "LineExtensionAmount":[{"$":200.00,"currencyID":"CAD"}],
      "Item":[{
       "Description":[{"$":"Axel"}]
      }]
     }]

4.4. BBIE expression

Each sequence of one or more consecutive BBIE components of the same name shall be serialized as a single name/value pair of its parent ASBIE or Document ABIE JSON object.

The one name for that pair shall be the name of the BBIE. Only when there is another name/value pair for a non-BBIE in the same object that has the same name as the BBIE, the name of the BBIE shall be suffixed with "$B".

The one value for that pair shall be a JSON array of one or more objects, each object representing, in array order, the sequence order of the consecutive BBIEs.

Each BBIE shall have a name/value pair whose name is "$ and whose value is the content component of the Core Component Type associated with the BBIE.

Each BBIE must have as many name/value pairs with the names and values of required supplementary components of the given instance of the Core Component Type.

Each BBIE may have as many name/value pairs with the names and values of optional supplementary components of the given instance of the Core Component Type.

Some examples of serialized BBIEs … an identifier, a date and two notes:

  •   "ID":[{"$":123}]

  •   "IssueDate":{"":"2011-09-22"}

  •   "Note":[{"languageID":"en","$":"Test"},
              {"languageID":"fr","$":"Tester"}]

4.5. Extension expression

When a business document contains foreign content not defined by the business vocabulary, this content is placed under a single apex containing all of the scaffolding of all foreign extension content. The name of this apex is defined by a specification of a given business vocabulary and may be different than that of other business vocabularies. However, all document types in a given business vocabulary should be using the same name for the apex of the scaffolding of foreign extension content.

This apex name is used as the name of the name/value pair of the Document ABIE object. Only when there is another name/value pair in the same object that has the same name as the extensions apex, the name of the extensions apex shall be suffixed with "$E".

The extensions apex name/value pair in the parent Document ABIE shall have as its value an array of extensions. Each member of the array shall be an object. Each object may have any number of name/value pairs of extension metadata, whose names are defined by the vocabulary. Each object shall have a name/value pair with the name "$" whose value is the foreign content.

For the purposes of this document, the expression of foreign content is out of scope. Where a business document provides for content not defined by the business document, the JSON serialization of that content shall be agreed upon between trading partners. Given that the apex of an extension has a role similar to a document element, one could consider serializing an extension in a manner similar to serializing a Document ABIE.

5. Unmarshalling JSON to CCTS

5.1. Overview of unmarshalling

A JSON stream loaded into an application's variable will create in that variable the objects and arrays representing CCTS constructs.

An application will, typically, know all of the names of all of the possible business objects represented by the Document ABIE, the ASBIEs and the BBIEs. It will also know the name of the extensions apex.

An array member of the extensions apex name/value pair of a Document ABIE object will be an array containing a name/value pair with the name "$". This is assumed to be foreign content with content agreed upon or unknown to trading partners.

Otherwise, should it ever be necessary for an application to infer the processing of a given value of a name/value pair in an object with an unrecognized name, an object that has a name/value pair with the name of "$ can be assumed to be a BBIE. An object that does not have a name/value pair with the name of "$" can be assumed to be an ASBIE.

The examples in this section are copied from the interactive interfaces of the "node.js" interpreter and the "python" interpreter.

5.2. JavaScript syntax

This JSON representation support for CCTS objects fully supports the dot notation defined in JavaScript.

The JSON stream creates an object with a single name/value pair. The name of that pair is the name of the Document ABIE. The value of that pair is the object defining the contents of the Document ABIE comprised of BBIEs and ASBIEs.

Each BBIE and ASBIE must be addressed as a list that is guaranteed to have at the least a single member addressed with "[0]".

Note

Future versions of the business vocabulary may raise the cardinality of the object and so this approach is future proof to revisions. This approach is also consistent and is used without thought of cardinality and so should be easier for the programmer (if a little verbose).

The content of a BBIE is addressed as the object name/value pair with the name "$". Supplementary components of a BBIE are addressed by their name.

Some examples of dot notation syntax:

> obj.Invoice.Note[0]
{ '$': 'Test', languageID: 'en' }
> obj.Invoice.Note[1]
{ '$': 'Tester', languageID: 'fr' }
> obj.Invoice.Note[1].$
'Tester'
> obj.Invoice.InvoiceLine[1].LineExtensionAmount[0].$
200
> obj.Invoice.InvoiceLine[1].LineExtensionAmount[0].currencyID
'CAD'

This approach also supports the object notation defined in JavaScript.

The same examples using list and object notation syntax:

> obj["Invoice"]["Note"][0]
{ '$': 'Test', languageID: 'en' }
> obj["Invoice"]["Note"][1]
{ '$': 'Tester', languageID: 'fr' }
> obj["Invoice"]["InvoiceLine"][1]["LineExtensionAmount"][0]["$"]
200
> obj["Invoice"]["InvoiceLine"][1]["LineExtensionAmount"][0]["currencyID"]
'CAD'

5.3. Python syntax

This approach fully supports the list and dictionary notation defined in Python.

The JSON stream creates a dictionary with a single name/value pair. The name of that pair is the name of the Document ABIE. The value of that pair is the object defining the contents of the Document ABIE comprised of BBIEs and ASBIEs.

Each BBIE and ASBIE must be addressed as a list that is guaranteed to have at the least a single member addressed with "[0]".

Note

Future versions of the business vocabulary may raise the cardinality of the object and so this approach is future proof to revisions. This approach is also consistent and is used without thought of cardinality and so should be easier for the programmer (if a little verbose).

The content of a BBIE is addressed as the dictionary name/value pair with the name "$". Supplementary components of a BBIE are addressed by their name.

Some examples using list and dictionary syntax:

>>> obj["Invoice"]["Note"][0]
{u'$': u'Test', u'languageID': u'en'}
>>> obj["Invoice"]["Note"][1]
{u'$': u'Tester', u'languageID': u'fr'}
>>> obj["Invoice"]["InvoiceLine"][1]["LineExtensionAmount"][0]["$"]
200.0
>>> obj["Invoice"]["InvoiceLine"][1]["LineExtensionAmount"][0]["currencyID"]
u'CAD'
>>> 

Note

Observe how the Python list and dictionary syntax is identical to the JavaScript list and object syntax.

6. Example serializations of business documents

6.1. Examples overview

These examples are extracted from sample XML instances found in the UBL 2.1 distribution at http://docs.oasis-open.org/ubl/os-UBL-2.1/xml/.

For legibility the examples are indented. Indentation is insignificant white space and optionally can be eliminated from the file.

6.2. UBL-Invoice-2.1-Example-Trivial.json

{"Invoice":
 {
 "$D":"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2",
 "$S":"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2",
 "$B":"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2",
 "ID":[{"$":"123"}],
 "IssueDate":[{"$":"2011-09-22"}],
 "InvoicePeriod":[{
  "StartDate":[{"$":"2011-08-01"}],
  "EndDate":[{"$":"2011-08-31"}]
 }],
 "AccountingSupplierParty":[{
  "Party":[{
   "PartyName":[{
    "Name":[{"$":"Custom Cotter Pins"}]
   }]
  }]
 }],
 "AccountingCustomerParty":[{
  "Party":[{
   "PartyName":[{
    "Name":[{"$":"North American Veeblefetzer"}]
   }]
  }]
 }],
 "LegalMonetaryTotal":[{
  "PayableAmount":[{"$":100.00,"currencyID":"CAD"}]
 }],
 "InvoiceLine":[{
  "ID":[{"$":"1"}],
  "LineExtensionAmount":[{"$":100.00,"currencyID":"CAD"}],
  "Item":[{
   "Description":[{"$":"Cotter pin, MIL-SPEC"}]
  }]
 }]
}}

6.3. Modified invoice example

This example has multiple BBIEs for "Note and multiple ABIEs for "InvoiceLine":

{"Invoice":
 {
 "$D":"urn:oasis:names:specification:ubl:schema:xsd:Invoice-2",
 "$S":"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2",
 "$B":"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2",
 "ID":[{"$":"123"}],
 "IssueDate":[{"$":"2011-09-22"}],
 "Note":[{"$":"Test","languageID":"en"},
 {"$":"Tester","languageID":"fr"}],
 "InvoicePeriod":[{
  "StartDate":[{"$":"2011-08-01"}],
  "EndDate":[{"$":"2011-08-31"}]
 }],
 "AccountingSupplierParty":[{
  "Party":[{
   "PartyName":[{
    "Name":[{"$":"Custom Cotter Pins"}]
   }]
  }]
 }],
 "AccountingCustomerParty":[{
  "Party":[{
   "PartyName":[{
    "Name":[{"$":"North American Veeblefetzer"}]
   }]
  }]
 }],
 "LegalMonetaryTotal":[{
  "PayableAmount":[{"$":100.00,"currencyID":"CAD"}]
 }],
 "InvoiceLine":[{
  "ID":[{"$":"1"}],
  "LineExtensionAmount":[{"$":100.00,"currencyID":"CAD"}],
  "Item":[{
   "Description":[{"$":"Cotter pin, MIL-SPEC"}]
  }]
 },{
  "ID":[{"$":"2"}],
  "LineExtensionAmount":[{"$":200.00,"currencyID":"CAD"}],
  "Item":[{
   "Description":[{"$":"Axel"}]
  }]
 }]
}}

6.4. UBL-TransportationStatus-2.1-Example.json

{"Order":
 {
 "$D":"urn:oasis:names:specification:ubl:schema:xsd:Order-2",
 "$S":"urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2",
 "$B":"urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2",
 "UBLVersionID":[{"$":"2.1"}],
 "CustomizationID":[{"$":"urn:www.cenbii.eu:transaction:biicoretrdm001:ver1.0"}],
 "ProfileID":[{"$":"urn:www.cenbii.eu:profile:BII01:ver1.0","schemeAgencyID":"BII","schemeID":"Profile"}],
 "ID":[{"$":"34"}],
 "IssueDate":[{"$":"2010-01-20"}],
 "IssueTime":[{"$":"12:30:00"}],
 "Note":[{"$":"Information text for the whole order"}],
 "DocumentCurrencyCode":[{"$":"SEK"}],
 "AccountingCostCode":[{"$":"Project123"}],
 "ValidityPeriod":[{
  "EndDate":[{"$":"2010-01-31"}]
 }],
 "QuotationDocumentReference":[{
  "ID":[{"$":"QuoteID123"}]
 }],
 "OrderDocumentReference":[{
  "ID":[{"$":"RjectedOrderID123"}]
 }],
 "OriginatorDocumentReference":[{
  "ID":[{"$":"MAFO"}]
 }],
 "AdditionalDocumentReference":[{
  "ID":[{"$":"Doc1"}],
  "DocumentType":[{"$":"Timesheet"}],
  "Attachment":[{
   "ExternalReference":[{
    "URI":[{"$":"http://www.suppliersite.eu/sheet001.html"}]
   }]
  }]
 },{
  "ID":[{"$":"Doc2"}],
  "DocumentType":[{"$":"Drawing"}],
  "Attachment":[{
   "EmbeddedDocumentBinaryObject":[{"$":"UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi","mimeCode":"application/pdf"}]
  }]
 }],
 "Contract":[{
  "ID":[{"$":"34322"}],
  "ContractType":[{"$":"FrameworkAgreementID123"}]
 }],
 "BuyerCustomerParty":[{
  "Party":[{
   "EndpointID":[{"$":"7300072311115","schemeAgencyID":"9","schemeID":"GLN"}],
   "PartyIdentification":[{
    "ID":[{"$":"7300070011115","schemeAgencyID":"9","schemeID":"GLN"}]
   },{
    "ID":[{"$":"PartyID123"}]
   }],
   "PartyName":[{
    "Name":[{"$":"Johnssons byggvaror"}]
   }],
   "PostalAddress":[{
    "ID":[{"$":"1234567890123","schemeAgencyID":"9","schemeID":"GLN"}],
    "Postbox":[{"$":"PoBox123"}],
    "StreetName":[{"$":"Rådhusgatan"}],
    "AdditionalStreetName":[{"$":"2nd floor"}],
    "BuildingNumber":[{"$":"5"}],
    "Department":[{"$":"Purchasing department"}],
    "CityName":[{"$":"Stockholm"}],
    "PostalZone":[{"$":"11000"}],
    "CountrySubentity":[{"$":"RegionX"}],
    "Country":[{
     "IdentificationCode":[{"$":"SE"}]
    }]
   }],
   "PartyTaxScheme":[{
    "RegistrationName":[{"$":"Herra Johnssons byggvaror AS"}],
    "CompanyID":[{"$":"SE1234567801"}],
    "RegistrationAddress":[{
     "CityName":[{"$":"Stockholm"}],
     "Country":[{
      "IdentificationCode":[{"$":"SE"}]
     }]
    }],
    "TaxScheme":[{
     "ID":[{"$":"VAT","schemeID":"UN/ECE 5153","schemeAgencyID":"6"}]
    }]
   }],
   "PartyLegalEntity":[{
    "RegistrationName":[{"$":"Johnssons Byggvaror AB"}],
    "CompanyID":[{"$":"5532331183","schemeID":"SE:ORGNR"}],
    "RegistrationAddress":[{
     "CityName":[{"$":"Stockholm"}],
     "CountrySubentity":[{"$":"RegionX"}],
     "Country":[{
      "IdentificationCode":[{"$":"SE"}]
     }]
    }]
   }],
   "Contact":[{
    "Telephone":[{"$":"123456"}],
    "Telefax":[{"$":"123456"}],
    "ElectronicMail":[{"$":"pelle@johnsson.se"}]
   }],
   "Person":[{
    "FirstName":[{"$":"Pelle"}],
    "FamilyName":[{"$":"Svensson"}],
    "MiddleName":[{"$":"X"}],
    "JobTitle":[{"$":"Boss"}]
   }]
  }],
  "DeliveryContact":[{
   "Name":[{"$":"Eva Johnsson"}],
   "Telephone":[{"$":"1234356"}],
   "Telefax":[{"$":"123455"}],
   "ElectronicMail":[{"$":"eva@johnsson.se"}]
  }]
 }],
 "SellerSupplierParty":[{
  "Party":[{
   "EndpointID":[{"$":"7302347231111","schemeAgencyID":"9","schemeID":"GLN"}],
   "PartyIdentification":[{
    "ID":[{"$":"SellerPartyID123"}]
   }],
   "PartyName":[{
    "Name":[{"$":"Moderna Produkter AB"}]
   }],
   "PostalAddress":[{
    "ID":[{"$":"0987654321123","schemeAgencyID":"9","schemeID":"GLN"}],
    "Postbox":[{"$":"321"}],
    "StreetName":[{"$":"Kungsgatan"}],
    "AdditionalStreetName":[{"$":"suite12"}],
    "BuildingNumber":[{"$":"22"}],
    "Department":[{"$":"Sales department"}],
    "CityName":[{"$":"Stockholm"}],
    "PostalZone":[{"$":"11000"}],
    "CountrySubentity":[{"$":"RegionX"}],
    "Country":[{
     "IdentificationCode":[{"$":"SE"}]
    }]
   }],
   "PartyLegalEntity":[{
    "RegistrationName":[{"$":"Moderna Produkter AB"}],
    "CompanyID":[{"$":"5532332283","schemeID":"SE:ORGNR"}],
    "RegistrationAddress":[{
     "CityName":[{"$":"Stockholm"}],
     "CountrySubentity":[{"$":"RegionX"}],
     "Country":[{
      "IdentificationCode":[{"$":"SE"}]
     }]
    }]
   }],
   "Contact":[{
    "Telephone":[{"$":"34557"}],
    "Telefax":[{"$":"3456767"}],
    "ElectronicMail":[{"$":"lars@moderna.se"}]
   }],
   "Person":[{
    "FirstName":[{"$":"Lars"}],
    "FamilyName":[{"$":"Petersen"}],
    "MiddleName":[{"$":"M"}],
    "JobTitle":[{"$":"Sales manager"}]
   }]
  }]
 }],
 "OriginatorCustomerParty":[{
  "Party":[{
   "PartyIdentification":[{
    "ID":[{"$":"0987678321123","schemeAgencyID":"9","schemeID":"GLN"}]
   }],
   "PartyName":[{
    "Name":[{"$":"Moderna Produkter AB"}]
   }],
   "Contact":[{
    "Telephone":[{"$":"346788"}],
    "Telefax":[{"$":"8567443"}],
    "ElectronicMail":[{"$":"sven@moderna.se"}]
   }],
   "Person":[{
    "FirstName":[{"$":"Sven"}],
    "FamilyName":[{"$":"Pereson"}],
    "MiddleName":[{"$":"N"}],
    "JobTitle":[{"$":"Stuffuser"}]
   }]
  }]
 }],
 "Delivery":[{
  "DeliveryLocation":[{
   "Address":[{
    "ID":[{"$":"1234567890123","schemeAgencyID":"9","schemeID":"GLN"}],
    "Postbox":[{"$":"123"}],
    "StreetName":[{"$":"Rådhusgatan"}],
    "AdditionalStreetName":[{"$":"2nd floor"}],
    "BuildingNumber":[{"$":"5"}],
    "Department":[{"$":"Purchasing department"}],
    "CityName":[{"$":"Stockholm"}],
    "PostalZone":[{"$":"11000"}],
    "CountrySubentity":[{"$":"RegionX"}],
    "Country":[{
     "IdentificationCode":[{"$":"SE"}]
    }]
   }]
  }],
  "RequestedDeliveryPeriod":[{
   "StartDate":[{"$":"2010-02-10"}],
   "EndDate":[{"$":"2010-02-25"}]
  }],
  "DeliveryParty":[{
   "PartyIdentification":[{
    "ID":[{"$":"67654328394567","schemeAgencyID":"9","schemeID":"GLN"}]
   }],
   "PartyName":[{
    "Name":[{"$":"Swedish trucking"}]
   }],
   "Contact":[{
    "Name":[{"$":"Per"}],
    "Telephone":[{"$":"987098709"}],
    "Telefax":[{"$":"34673435"}],
    "ElectronicMail":[{"$":"bill@svetruck.se"}]
   }]
  }]
 }],
 "DeliveryTerms":[{
  "ID":[{"$":"FOT","schemeAgencyID":"6","schemeID":"IMCOTERM"}],
  "SpecialTerms":[{"$":"CAD"}],
  "DeliveryLocation":[{
   "ID":[{"$":"STO"}]
  }]
 }],
 "AllowanceCharge":[{
  "ChargeIndicator":[{"$":true}],
  "AllowanceChargeReason":[{"$":"Transport documents"}],
  "Amount":[{"$":100,"currencyID":"SEK"}]
 },{
  "ChargeIndicator":[{"$":false}],
  "AllowanceChargeReason":[{"$":"Total order value discount"}],
  "Amount":[{"$":100,"currencyID":"SEK"}]
 }],
 "TaxTotal":[{
  "TaxAmount":[{"$":100,"currencyID":"SEK"}]
 }],
 "AnticipatedMonetaryTotal":[{
  "LineExtensionAmount":[{"$":6225,"currencyID":"SEK"}],
  "AllowanceTotalAmount":[{"$":100,"currencyID":"SEK"}],
  "ChargeTotalAmount":[{"$":100,"currencyID":"SEK"}],
  "PayableAmount":[{"$":6225,"currencyID":"SEK"}]
 }],
 "OrderLine":[{
  "Note":[{"$":"Freetext note on line 1"}],
  "LineItem":[{
   "ID":[{"$":"1"}],
   "Quantity":[{"$":"120","unitCode":"LTR"}],
   "LineExtensionAmount":[{"$":6000,"currencyID":"SEK"}],
   "TotalTaxAmount":[{"$":10,"currencyID":"SEK"}],
   "PartialDeliveryIndicator":[{"$":false}],
   "AccountingCostCode":[{"$":"ProjectID123"}],
   "Delivery":[{
    "RequestedDeliveryPeriod":[{
     "StartDate":[{"$":"2010-02-10"}],
     "EndDate":[{"$":"2010-02-25"}]
    }]
   }],
   "OriginatorParty":[{
    "PartyIdentification":[{
     "ID":[{"$":"EmployeeXXX","schemeAgencyID":"ZZZ","schemeID":"ZZZ"}]
    }],
    "PartyName":[{
     "Name":[{"$":"Josef K."}]
    }]
   }],
   "Price":[{
    "PriceAmount":[{"$":50,"currencyID":"SEK"}],
    "BaseQuantity":[{"$":"1","unitCode":"LTR"}]
   }],
   "Item":[{
    "Description":[{"$":"Red paint"}],
    "Name":[{"$":"Falu Rödfärg"}],
    "SellersItemIdentification":[{
     "ID":[{"$":"SItemNo001"}]
    }],
    "StandardItemIdentification":[{
     "ID":[{"$":"1234567890123","schemeAgencyID":"6","schemeID":"GTIN"}]
    }],
    "AdditionalItemProperty":[{
     "Name":[{"$":"Paint type"}],
     "Value":[{"$":"Acrylic"}]
    },{
     "Name":[{"$":"Solvant"}],
     "Value":[{"$":"Water"}]
    }]
   }]
  }]
 },{
  "Note":[{"$":"Freetext note on line 2"}],
  "LineItem":[{
   "ID":[{"$":"2"}],
   "Quantity":[{"$":"15","unitCode":"C62"}],
   "LineExtensionAmount":[{"$":225,"currencyID":"SEK"}],
   "TotalTaxAmount":[{"$":10,"currencyID":"SEK"}],
   "PartialDeliveryIndicator":[{"$":false}],
   "AccountingCostCode":[{"$":"ProjectID123"}],
   "Delivery":[{
    "RequestedDeliveryPeriod":[{
     "StartDate":[{"$":"2010-02-10"}],
     "EndDate":[{"$":"2010-02-25"}]
    }]
   }],
   "OriginatorParty":[{
    "PartyIdentification":[{
     "ID":[{"$":"EmployeeXXX","schemeAgencyID":"ZZZ","schemeID":"ZZZ"}]
    }],
    "PartyName":[{
     "Name":[{"$":"Josef K."}]
    }]
   }],
   "Price":[{
    "PriceAmount":[{"$":15,"currencyID":"SEK"}],
    "BaseQuantity":[{"$":"1","unitCode":"C62"}]
   }],
   "Item":[{
    "Description":[{"$":"Very good pencils for red paint."}],
    "Name":[{"$":"Pensel 20 mm"}],
    "SellersItemIdentification":[{
     "ID":[{"$":"SItemNo011"}]
    }],
    "StandardItemIdentification":[{
     "ID":[{"$":"123452340123","schemeAgencyID":"6","schemeID":"GTIN"}]
    }],
    "AdditionalItemProperty":[{
     "Name":[{"$":"Hair color"}],
     "Value":[{"$":"Black"}]
    },{
     "Name":[{"$":"Width"}],
     "Value":[{"$":"20mm"}]
    }]
   }]
  }]
 }]
}}