Commerce Data Interchange Format
Standard behind the semantic blockchain.
Enterprises have recognised the need for standardisation of documents that are shared across organisation, to enable process automation. Hence, today standards like EDI is a common practise to share across large enterprises. However EDI solution come with infrastructure overhead and the document shared are flat files.
As ⦃param⦄ provides an EDI like capabilities in the form of permissioned public blockchain network for enterprises of all sizes to collaborate and share documents in a well structured format called JSON-LinkedData, referred as Commerce Data Interchange Format (CDIF).
JSON-LinkedData is originally created as a standard for Semantic web. This is now, can be very well extended for establishing machine-readable data on the commerce blockchain. We can enhance the data links by adding supporting documents such as Catalogues, Booking Tickets, Payments, Shipments, etc...
A valid Invoice described using schema.org's (modified) JSON-LD structure:
{
"@context": "http://schema.org/",
"@type": "Invoice",
"provider": { #Optionally details are included for the first time invoices between B2B
"@type": "Organization",
"@id": "0x131783612317312678316238172376",
"address": {
"@type": "PostalAddress",
"@id": "0x131783612317312678316238172376",
"addressLocality": "Seattle",
"addressRegion": "WA",
"postalCode": "98052",
"streetAddress": "20341 Whitworth Institute 405 N. Whitworth"
},
"employee": {
"@type": "Person",
"@id": "0x131783612317312678316238172376",
"name": "Jane Doe - Point of Contact"
},
"email": "mailto:[email protected]",
"name": "Divum Labs Pvt. Ltd.",
"telephone": "(425) 123-4567",
"faxNumber":"(425) 123-4569"
},
"customer": { #Optionally details are included for the first time invoices between B2B
"@type": "Organization",
"@id": "0x131783612317312678316238172376",
"address": {
"@type": "PostalAddress",
"@id": "0x131783612317312678316238172376",
"addressLocality": "Seattle",
"addressRegion": "WA",
"postalCode": "98052",
"streetAddress": "20341 Whitworth Institute 405 N. Whitworth"
},
"employee": {
"@type": "Person",
"@id": "0x131783612317312678316238172376",
"name": "Jane Doe - Point of Contact"
},
"email": "mailto:[email protected]",
"name": "Customer of this Receipt Inc.",
"telephone": "(425) 123-7654",
"faxNumber": "(425) 123-7659"
},
"referencesOrder": {
"@type": "Order",
"orderDate": "2014-12-01",
"orderNumber": "123ABC", # receipt / document id. As it is autogenerated, this field will be missing in txn argument
"paymentMethod": "#ByInvoice",
"orderedItem": [
{
"@type": "OrderItem",
"@id": "<receiptId>_<index>", // managed by events handler
"orderQuantity": 1,
"orderedItem": {
"@type": "Product",
"@id": "0x131783612317312678316238172376",
"name": "Sony 101.4 cm TV",
"mpn": 101, //Optional
"productID": "sony123",
"gtin8": "", //Unique id for product....
"offers": {
"@type": "Offer",
"priceCurrency": "USD",
"price": 44999,
"priceValidUntil": "2020-11-05", //Optinal
"itemCondition": "NewCondition", //Optinal
"availability": "InStock",//Optinal
}
}
},
# Second Item
{
"@type": "OrderItem",
"@id": "<receiptId>_<index>", // managed by events handler
"orderQuantity": 2,
"orderedItem": {
"@type": "Product",
"@id": "0x131783612317312678316238172376",
"name": "Samsung 101.4 cm TV",
"mpn": 101, //Optional
"productID": "sam123",
"gtin8": "", //Unique id for product....
"offers": {
"@type": "Offer",
"priceCurrency": "USD",
"price": 44999,
"priceValidUntil": "2020-11-05", //Optinal
"itemCondition": "NewCondition" //Optinal
}
}
}
]
},
"minimumPaymentDue": {
"@type": "PriceSpecification",
"price": 44999000,
"priceCurrency": "USD"
},
"totalPaymentDue": {
"@type": "PriceSpecification",
"price": 44999000,
"priceCurrency": "USD"
}
}
⦃param⦄ aim to provide standard convertors for direct ERP integration. Where convertors will plugin to systems like SAP, Zoho Books, connect via standard API interfaces to translate the native ERP formats into CDIF compatible to ⦃param⦄ CLI and API.
One could extend the knowledge of the commerce transaction by adding more standard documents. For example:
- Online Travel Agent could add Schema.org complaint Invoice -> Ticket -> Seat Booking by Airline operator.
Each knowledge extension transaction will go through schema validation at the node-level before the transaction is sent on the network.