Candidate Standard

Skip to end of metadata
Go to start of metadata

This section of the DDEX Knowledge Base contains Version 1.0 of Part 1 (Architecture) of the Claim Detail Message Suite Standard

 

 

1 Introduction

This standard was developed by the member organisations of the Digital Data Exchange, LLC (DDEX) and provides a format for a response to a sales/usage report received by an owner/administrator of Musical Works (usually the "Licensor") which sets out the claim (“right share”) each owner/administrator is making in respect of the Musical Works identified in the sales/usage report and all the calculation details behind the individual and aggregate royalty claim being made by each owner/administrator in such detail that the original sender of the sales/usage report (usually the "Licensee") can be confident in accepting the associated invoice for payment. 

This standard defines the principles of the Claim Detail Message Suite Standard. It is accompanied by a series of standards that define Profile-specific messages based on this standard.

Any organisation wishing to implement this (or any other DDEX standard) is required to apply for an Implementation Licence. The terms of the licence and an application form can be found on https://ddex.net/implementation/implementation-licence-and-ddex-party-identifiers.


Essential Reading

Download/Print standard (PDF)

This standard is Part 1 of a multi-part standard. The other parts (incl. samples) are available here.

Samples for the CDM Standard can be found here.

CDM is a "Candidate Standard", which is a formal standard approved by DDEX for which DDEX has not had any information about live implementations. Once DDEX has received such input, it is expected that CDM will be promoted to "DDEX Standard".

2 Scope

 2.1 Introduction
This Standard provides a mechanism for Licensor (typically Music Rights Societies, Music Publishers) to send details of claims and/or details of invoices for such claims to relevant Licensees (typically Digital Service Providers). Such claim/invoice details are typically sent in response to sales/usage reports from the exploitation of Products based on electronic Releases containing Sound Recordings and/or Music Audio-Visual Recordings which embody Musical Works and/or other Resources. The claim details part of the standard may also be used as part of a process between a Licensor and a Licensee which does not require the initial receipt of sales/usage information.

Such sales/usage reports may be communicated using DDEX's Digital Sales Reporting Message Suite Standard or proprietary formats offering the same or similar functionality.

The format defined in this standard provides sufficient details about the individual and aggregate royalty claims being made by each Licensor so that the Licensee that sent the sales/usage report can be confident in accepting the associated invoice for payment. The communication of the invoice itself is not part of this standard.

The claim Detail Message defined herein enables the Licensor to provide for all identified releases claims and royalty amounts to be paid by the Licensee to the Licensor.

 The Claim Detail Message defined herein enables the Licensee to:

  • Check the mapping between a reported Sound Recording or Video, and the underlying Musical Work as made by the Licensor;
  • Determine whether the claims on Musical Works made by the Licensor are in any way in conflict with claims made by other Licensors for the same Musical Works (whether by right, by date, by territory or by usage);
  • Determine whether, in their view, the claimed and calculated amounts (per right share, per Musical Work and per message as appropriate) are aligned with the royalty rates agreed between each Licensor and each Licensee in the relevant licence agreement; and
  • Determine whether, in their view, the total claimed by each Licensor corresponds to the aggregate of the individual royalties claimed (by right share or by Musical Work, as appropriate).

This standard also provides a mechanisms for Licensees who have received such Claim Detail Messages to respond with a Claim Detail Discrepancy Notification should they determine that the Claim Detail Messages contain "discrepancies", i.e. issues that the recipient of the Claim Detail Messages has determined may impact the calculation of the royalties. Such discrepancies include, but are not limited to, arithmetic issues, questions about applied tariffs, disputes about Right Share control but also errors in the formatting of the Claim Detail Message – as soon as these errors have an impact on calculation of the royalties. While the resolution of such discrepancies is out of scope, Licensees are expected to use the Claim Detail Discrepancy Notification to signal such discrepancies to Licensors and subsequently work with those organisations to resolve them.

The Claim Detail Message Suite Standard therefore enables speedy settlement on all claims and invoices received from all Licensors related to a set of DSR (or equivalent) Messages relating to the same period and service and avoid, as much as possible, situations where a payment has to be delayed or reversed (e.g. by reducing future payments) because of contradictory or conflicting claims. 

In several places in this Standard, there are references to bilateral agreements which, in almost all cases, are between a Licensor and a Licensee. Such agreements determine elements of the way this Standard is to be used between two business partners which it is inappropriate to standardise. It should be noted in this context however that, whilst such bilateral agreements will determine such issues, it may not be the Licensor or the Licensee that are actually exchanging the messages. Rather one or both appoint a Message Sender or Message Recipient to do this on their behalf. However, because the bilaterla agreements are in place, most references to the roles undertaken in the exchanging of any of the messages in the Claim Detail Message Suite Standard are to Licensor and Licensee.

 2.2 Organisation of the Standard
This standard has seven clauses. Clause 1–4 provide an introduction, the scope as well as definitions for core terms and core abbreviations. Clause 5 then defines the overall choreography for the communication of Claim Detail Messages as well as Claim Detail Discrepancy Notifications before Clause 6 provides technical details of the format. Finally, Clause 7 lists the profile defined for this standard at time of publication.

3 Normative References

 3 Normative References
The following normative documents contain provisions, which through reference in this text constitute provisions of this standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest version applies.
  • DDEX Data Dictionary Standard. Latest Version
  • DDEX Party Identifier (DPID) Standard. Latest Version
  • DDEX, Digital Sales Reporting Message Suite Standard - Part 2: Allowed Value Sets
  • IETF. RfC2026. SSH File Transfer Protocol. October 2001
  • IFPI. Global Release Identifier (GRid) Standard. Latest Version
  • ISO 639-1:2002. Codes for the representation of names of languages — Part 1: Alpha-2 code. 2002
  • ISO 3166-1:1997. Codes for the representation of names of countries and their subdivisions – Part 1: Country codes. 1997
  • ISO 3901:2001. Information and documentation – International Standard Recording Code (ISRC). 2001
  • ISO 4217:2001. Codes for the representation of currencies and funds. Latest Version
  • ISO 8601: Data elements and interchange formats – Information interchange – Representation of dates and times. Latest Version
  • ISO 15707:2001. Information and documentation – International Standard Musical Work Code (ISWC). 2001
  • ISO/IEC 10646, Information technology — Universal multiple-octet coded character set (UCS). Latest Version

4 Terms and Abbreviations

 4.1 Terms and Definitions
For the purposes of this standard, the following terms, written in the remainder of this standard with capital letters, should be read as having the meanings specified here. These definitions sometimes contain other capitalised terms. Most of those terms are relevant for this standard and are defined in this Clause as well. The remainder of the capitalised terms are defined for the purpose of supporting other DDEX standards and have no special meaning for the purposes of this standard.

Block

A group of Records in a Message created in accordance with a flat-file standard that communicate information that belongs intrinsically together. All Records in a Block carry the same Block Identifier and all Records with the same Record Identifier belong to the same Block. The identifier of a Block shall be unique within a Sales Report Message created in accordance with this standard.

All Records of a Block are contiguously provided within a Message.

In the CDM Standard Blocks comprise the description of a claims and/or invoice details, plus any auxiliary information (if provided).

Cell

An individual data element in a Record. Cells are separated by Delimiters.

Contractually Mandatory

An entity in a DDEX Message that has the technical cardinality of 0-1 or 0-n but that is mandatory when a DDEX message is sent in a specific commercial context.

Contractually Mandatory fields may, however, be mandatory when a DDEX message is sent in a specific commercial context. In such circumstances, a message is deemed conformant only if and when it contains all the “contractually mandatory” fields as agreed by Message Sender and Message Recipient.

Delimiter

A character that delineates, in a flat file, either one Record from another Record or one Cell from another Cell.

Note: there are also Secondary Delimiters used in this standard.

Flat File Sales Report Messages (DSRF)

A Sales Report Message created in accordance with the Digital Sales Reporting Message Suite Standards (Architecture and Profiles). A Flat File Sales Report Message may be split into several individual files.

Head Release

A Release, originally communicated by the owner (or its agent) of a sound recording or audio-visual recording to a Licensee who then distributed that Release to consumers, whose Usage, Revenue or Sales are described in a Sales Report Message created in accordance with this standard.

Head Resource

A Resource whose Usage, Revenue or Sales are described in a Sales Report Message created in accordance with this standard. Head Resources are not communicated as part of a Head Release.

Licensee

A Party that is granted a Licence in respect of rights in one or more Creations, by a Licensor. The Licensee may be a human being or other legal person or corporate entity. The Licensee may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.

Licensor

A Party that grants a Licence in respect of rights in one or more Creations to one or more Licensees in accordance with the authorities it has been granted to do so by one or more Rights Controller(s), Rights Administrator(s) (where applicable), Licensing Agent(s) (where applicable) or Rights Holder(s). The Licensor may be a human being or other legal person or corporate entity. The Licensor may or may not also be the Rights Controller, the Rights Administrator, the Licensing Agent or the Rights Holder in the Creation(s) that are the subject of the Licence granting the rights. The Licensor may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.

Musical Work

A Work intended to be perceivable as a combination of sounds, with or without accompanying text.

Any words that are intended to be expressed with a MusicalWork (often termed Lyrics) form part of that MusicalWork; not all MusicalWorks have Lyrics.
A MusicalWork may be expressed and fixed to become part of a SoundRecording or a Video Recording, or may be used to create notated music (sheet music, scores, instrumental parts) or sound generation codes (such as MIDI files).
In some cases, the MusicalWork comes into existence simultaneously with its expression. This is common in extemporised forms such as jazz music.

Profile

A subset of a DDEX standard. Profiles define how to use the capabilities of a DDEX standard in a specific commercial context.

Release

A Release is an abstract entity representing a bundle of one or more Resources compiled by an Issuer. The Resources in Releases are normally primarily sound recordings or music audio-visual recordings, but this is not invariably the case. The Release is not itself the item of trade (or “Product”). Products have more extensive attributes than Releases; one Release may be disseminated in many different Products.

Resource

A digital fixation of an expression of an abstract Work (such as a sound recording, a video, an image, software or a passage of text). Resources are individual assets that make up a Release. Typical Resources are sound recordings, video clips and cover art images.

Revenue

The amount of money generated in accordance with the commercial relationship between Licensee and Licensor for the distribution of Releases to consumers.

Rights Controller

A Party that controls rights in one or more Creations in respect of some or all rights for specific territories, time periods, Rights Types, Usage Types and Commercial Model Types (which may be anything up to and including all rights for the world, in perpetuity, for all types of Usage and for all types of Commercial Models). Creations include Musical Works, Sound Recordings and other Resources as well as Releases.

A Rights Controller is in many cases also the Licensor.

A Rights Controller may be a human being or other legal person or corporate entity.

A Rights Controller may or may not also be the Rights Administrator, the Licensing Agent or the Rights Holder.

A Rights Controller may or may not be the Message Sender or Message Recipient of a message in a specific information exchange defined by a DDEX Standard.

Sale

Distribution of a product to end consumers. For the avoidance of doubt, the term “sales” includes all forms of distribution of products, whether revenue was generated, or not and, where revenue is generated, regardless of the business model used to do so.

Sales/Usage Report Message

See Flat File Sales Report Messages (DSRF).

Sales Context

The combination of one or more territories, one or more currencies, one or more use types, one or more commercial model types and/or one or more service descriptions for which a sales/usage report is being created.

The combination of one territory, one currency, one use types, one commercial model types and one service descriptions for which a sales/usage report is being created. It is permissible, subject to both parties agreeing, to communicate multiple Sales Contexts in one sales/usage report.

For the purposes of this standard Sales Contexts include, both the combination of one or more territories, one or more currencies, one or more use types, one or more commercial model types and/or one or more service descriptions for which a sales/usage report has been generated,  and the combination of one or more territories, one or more currencies, one or more use types, one or more commercial model types and/or one or more service descriptions for which sales or usages are anticipated, and for which a claim is to be made. 

Secondary Delimiter

Delimiter used to separate data elements within a single Cell.

Sub-Release

 A Release that is being created from one or more of the primary Resources of a Head Release, typically by the Message Sender.

For the purpose of this standard these Sub-Releases are being created by the Message Sender who is making Releases, and tracks from such Releases, available to consumers. These “unbundled tracks”, that is, all the tracks from a Release each made available separately, are the simplest form of Sub-Releases.

Usage

The identification of the Releases and Resources that actually get exploited by Licensees exercising a range of business and delivery models for the distribution of Releases to consumers, including the amount of use of each Release or Resource.

 4.2 Abbreviations
Editorial Comment

At time of publication this list shall be extended by

  • CDM – Claim Detail Message
  • CDMDisRecord – Claim Detail Record Discrepancy Notification
  • CDMDisOver – Claim Detail Over-Claim Discrepancy Notification
  • CDMCor – Correction or Update of a Claim Detail Message
  • CDMRet – Retraction of a Claim Detail Message
 

AMEPAutomated Message Exchange Protocol
ACAAppointed Certification Agency
AVSAllowed Value Set
BPBusiness Profile
CISAC

Confédération internationale des sociétés d'auteurs et compositeurs, the International Confederation of Societies of Authors and Composers (see cisac.org)

CACertification Agency
CTConformance Tester
DAWDigital Audio Workstation
DDEX

Digital Data Exchange

DSIGDigital Signature
DSPDigital Service Provider (incudes Mobile Service Providers)
DSRDigital Sales Reporting
ERNElectronic Release Notification
FTPFile Transfer Protocol (FTP specifically includes SFTP)
GRidGlobal Release Identifier
HTTPHypertext Transport Protocol  (HTTP specifically includes HTTPS)
HTTPSSecure Hypertext Transport Protocol
IECInternational Electrotechnical Commission (see iec.ch)
ISOInternational Organisation for Standardisation (see iso.org)
MIMEMultipurpose Internet Mail Extensions
MWLMusical Works Licensing
MWNMusical Works Notification
MRBV

Multi-Record-Block Variant

PCAPrivate Certification Agency
PDFPortable Document Format
RESTREpresentational State Transfer
RINRecording Information Notification
SFTPSecure FTP
SRBV

Single-Record-Block Variant

TISTerritory Information System (a CISAC Standard)
TLSTransport Layer Security
UGCUser-generated content
URLUniform Resource Locator
XMLeXtensible Markup Language
XSDXML Schema Definition
W3CWorld Wide Web Consortium (see w3c.org)
WSWeb Service

5 Choreography

 5.1 Post-Usage Choreography
This standard supports the post-usage choreography (sometimes referred to as "post-claim choreography") depicted below. As with all DDEX Standards, the use of the messages contained in the Claim Detail Message Suite Standard is voluntary and may be subject to bilateral commercial arrangements between Licensors and Licensees. Specifically, the timing of the sending of any of the messages of the Claim Detail Message Suite Standard, is left to bilateral agreements. 

In this choreography, all Right Share claim information is communicated between a Licensor and a Licensee in response to a DSR (or equivalent) Message sent by the Licensee to the Licensor.

 

 5.2 Relationship between Sales/Usage Report and Claim Detail Messages
Claim Detail Messages, when sent in the post-usage choreography, are send in response to a single DSR (or equivalent) Messages. As a consequence, a Claim Detail Message shall contain claim and, potentially also, invoice information with respect to this one DSR (or equivalent) Message only. It is permissible, however, to send multiple Claim Detail Messages in response to a single DSR (or equivalent) Message.

If a DSR (or equivalent) Message contains multiple Sales Contexts, each of the corresponding Claim Detail Messages must have the same or a subset of contexts.

Only if a Claim Detail Message is in response to a DSR (or equivalent) Message, will the Claim Detail Message contain claim and invoice information. In cases where a Claim Detail Message is not based on a DSR (or equivalent) Message, the Claim Detail Message will only contain claim information (see also Clause 5.5).

 5.3 Retractions and Replacements
Licensors that have sent  a Claim Detail Message in error may completely retract this Claim Detail Message by sending a second Claim Detail Message marked as a retraction in the MessageType cell of the Header Record. In the Header Record of the retraction, the RelatedCDM cell shall contain the MessageId of the Claim Detail Message that is to be retracted and with the MessageCreatedDateTime shall indicate the date and time that the retraction message was created. Other than the Header Record, the retraction message shall only contain a Footer Record. This applies to Claim Detail Messages sent in response to a DSR (or equivalent) Message as well as for Claim Detail Message not based on a DSR (or equivalent) Message (see also Clause 5.5).

The Licensor may then follow-up this retraction with a further Claim Detail Message that replaces the erroneous Claim Detail Message, as orignally sent. All three message shall have unique MessageIds.

If a Licensor wishes to retract a corrected Claim Detail Message, it must first retract all Claim Detail Messages previously sent that were corrected by the Claim Detail Message it wishes to retract before retracting that particular Claim Detail Message.

If a Licensor wishes to correct parts of a Claim Detail Message, the process described in Clause 5.4 must be used.

Unless specifically indicating otherwise, Retractions of Claim Detail Messages are considered to be Claim Detail Messages themselves.

Claim Detail Discrepancy Notifications cannot be retracted.

 5.4 Corrections
If a Licensor needs to correct a Claim Detail Message where some information sent in the original Claim Detail Message needs correcting while other information does not, the Licensor shall clearly mark the new Claim Detail Message as containing corrections. Such corrected Claim Detail Messages shall use the same references to the DSR (or equivalent) Message in cases where a Claim Detail Message is sent in response to such a DSR (or equivalent) Message, including the same SalesTransactionIds (or equivalent), as were used in the original Claim Detail Message. However, the new Claim Detail Message shall have its own unique MessageId.

To remove an individual claim from a Claim Detail Message, the Licensor shall set the relevant claim percentages to 0%.

To remove an individual invoice detail item from a Claim Detail Message, the Licensor shall set the relevant revenue figures to 0.

The format used to communicate such corrections follows the rules of the Profile of the corrected Claim Detail Message, albeit with different Record Types. Details are provided in the relevant Profiles.

Unless specifically indicating otherwise, Corrections of Claim Detail Messages are considered to be Claim Detail Messages themselves.

Claim Detail Discrepancy Notifications cannot be corrected.

 5.5 Pre-Usage Choreography
The standard also supports a pre-usage process (also known as a "pre-claim process") in which a Licensor and a Licensee share information that enables the establishment of Right Share claims for all Musical Works in which that Licensor has an interest, before the Licensee sends a DSR (or equivalent) Message that reports usages to the Licensor. Hence, both Licensee and Licensor should have, disputes notwithstanding, a common understanding of the Right Share claims of all Musical Works used in which that Licensor has an interest.

A pre-usage Claim Detail Message may be sent in direct reply to a DSR (or equivalent) Message without usage information or based on other, typically contractual, triggers. 

This process is a subset of the process depicted in Clause 5.1 and therefore this standard permits a Claim Detail Message to be sent by a Licensor to a Licensee without any financial calculations or invoice information.

6 Technical Details

 6.1 Baseline Format

The Messages defined in this standard are delimiter-separated values text files. Further details are provided the following sub-sections.

 6.2 Character Coding
The messages defined in this standard are coded using UTF-8 with a big endian byte ordering.
 6.3 Delimiters

6.3.1 Record Delimiter

Each Record is placed into one line terminated by a line feed (Unicode U+000A) or a carriage return and line feed pair (Unicode U+000D 000A).

6.3.2 Primary (Cell) Delimiter

Cells within a Record are separated by tab characters (Unicode U+0009).

6.3.3 Secondary  Delimiter

Should a Cell contain two or more data elements, these data elements shall be separated by a pipe character (Unicode U+007C). This is referred to as a Secondary Delimiter.

All data elements in a multi-value Cell shall be of the same primitive data type.

6.3.4 Namespace Delimiter

Should a Cell contain a data element whose providence needs to be provided, the data element shall be preceded by a string that provides a "namespace" and two colon characters (Unicode U+003A). The double colon is referred to as a Namespace Delimiter.

Examples include specifically, identifiers, where, e.g., a party ID can be communicated as  "ISNI::0000000081266409", indicating that the identifier (0000000081266409) is an International Standard Name Identifier (ISNI).

6.3.5  Spaces and Delimiters (I)

Delimiters shall not be surrounded by extra space characters. The same principle applies to the Secondary Delimiter.

Example: The writer pair Lennon/McCartney should be communicated as "Lennon|McCartney" and not as "Lennon | McCartney".

6.3.6 Spaces and Delimiters (II)

If a Message Sender has received data with extra white spaces, they are encouraged to trim any such extra white space characters when compiling a message specified in the Claim Detail Message Suite Standard. They may, however, also use the data with these extra white space characters in such cases. The same principle applies to the Secondary Delimiter.

Example: When the Message Sender received Lennon as “Lennon “ and McCartney as “McCartney “, then the writer pair may be communicated as “Lennon |McCartney “).

 6.4 Communicating Delimiters
To communicate a primary Delimiters in a Cell, such a Cell shall not be enclosed in double quote characters. Instead the Delimiters shall be immediately preceded by an escaping code.

To escape a primary Delimiter, the escaping code is the backslash character (Unicode U+005C). Therefore the string A[TAB]B would have to be communicated as A\[TAB]B (with [TAB]representing the tabulator).

To escape a secondary Delimiter, the escaping code is a double backslash character (Unicode U+005C). Therefore the string A|B would have to be communicated as A\\|B.

To communicate a backslash character, three backslash characters need to be communicated. Therefore the string A\B would have to be communicated as A\\\B.

This “escaping mechanism” must be used for all special characters in all Cells, whether those Cells allow multiple values or not. A non-escaped pipe character in a single-value cell is, consequently, an error.

For the avoidance of doubt, escaping a character that should not be escaped, or not escaping a character that should have been escaped, will lead to an invalid Claim Detail Message or Claim Detail Discrepancy Notification.

 6.5 Primitive Data Types
Within this standard the following primitive data types are used:
Data TypeDefinitionExample

String

A sequence of characters with a length of at least one character. This standard does not define a maximum length. Strings may not contain non-printable characters (Unicode U+0000 to U+001F).

Johannes Brahms

Boolean

A string containing either “true” or “false”

true

Integer

A sequence of digits to represent positive or negative integer numbers, or zero.

Details of the range of integers are provided in Clause 6.10.

135672

Decimal

A sequence of digits to represent positive or negative integer numbers, positive or negative decimal fractions or zero.

The character used to separate the integers from fractions is the dot (“.”, Unicode U+002E).

Thousands separators or any other digit grouping shall not be used.

Details of the precision of decimals are provided in Clause 6.10.

Note: this was referred to as "float" in previous versions.

123

123.567

-5.25

0

Date

A date in the ISO 6801 format to indicate a single year (YYYY), month (YYYY-MM) or day (YYYY-MM-DD).

2015-01-09

Duration

A duration in the ISO 6801 format (P[nY][nM][nD][T[nH][nM]nS]).

Elements including their designator may be omitted if their value is zero.

Note: the expressions “PT3M2S” (three minutes and two seconds) and “PT182S” (182 seconds) are both permitted and are equivalent.

PT3M2S

PartyIDA string in the form IdType::ID where IdType identifies the identification scheme. Examples are ISNI for an ISO 27729 International Standard Name Identifietr, IPI for a CISAC Interested Party Identifier or IPN for a SCAPR International Performer Number. The ID element then contains the identifier in the format defined by the Identificaiton scheme. Only one identifier can be communicated for each party in a PartyID field.ISNI::0000000081266409

DDEX Party ID

A string of 18 characters in accordance with the DDEX Party ID standard.

Note: the DDEX Party ID standard defines that DDEX Party IDs do not contain dashes in computer-to-computer communications. Therefore, DDEX Party IDs, when included in a Claim Detail or Claim Detail Discrepancy Message , shall not contain dashes.

PADPIDA2014122301Q

Multiple

A sequence of 0-n strings in accordance with a defined data type separated by Secondary Delimiters.

If only one data item is to be provided, no Secondary Delimiter shall be included.

If the cardinality of such an element is "M", at least one such data item must be provided.

Cells that may contain multiple values may be related. For example one Multiple-String Cell may be for names of composers/lyricists and it may be followed by a Multiple-String Cell for identifiers of these composers/lyricists. In those cases, both Cells must contain the same number of Secondary Delimiters and there may only be 0-1 data items between the Secondary Delimiters.

"12" or "12|54|123" or "12||123" (without the quotes)

 6.6 Empty Records

It is not permissible to include empty Records in a Claim Detail Message or a Claim Detail Discrepancy Notification.

 6.7 Empty Cells
It is possible to communicate empty Cells. In that case, two tab characters shall follow each other with no characters in-between.

The semantics of an empty cell is determined by the commercial relationship between a Licensor and a Licensee, unless specifically defined in this standard.

 6.8 Records to be Ignored
Records whose first character is the hash symbol (“#”, Unicode U+0023) shall be ignored by automated ingestors.
 6.9 Unknown Records

A company receiving a file with a Record containing information identified by an unknown Record Type Indicator may ignore such Records.

 6.10 Communicating Decimals and Integers
This standard does not prescribe a specific precision in which decimal numbers are to be given. Licensor and Licensee must agree a mutually agreeable precision for the type of transactions at hand. The same applies to Integers.

Implementers are reminded that some accounting applications may only be able to handle six, or even four, decimal places.

When a field of type “decimal” is to communicate an integer, the number may be represented with a trailing decimal point, a trailing “.0” or with no trailing characters. For example, the number five can be represented as “5”, “5.” for “5.0”.

When the number 0 (zero) is to be communicated in a Cell for decimal values, this shall be represented as 0 (and not 0.0 or 0.000000).

 6.11 Maximum Cell Size
While some Cells have an inherent length limitation (e.g. the Record Type Indicators are limited to four characters), other Cells have no length limitation.

Note: this has an implication for developers using databases with field length limitations. Such developers will be forced to shorten fields if the data received exceeds their databases’ capabilities.

 6.12 Allowed Values
Allowed values are listed, defined and provided in the DDEX Standard "Digital Sales Reporting Message Suite Standard, Part 2 – Allowed Value Sets" in accordance with the DDEX Data Dictionary and the latest version of the DDEX Data Dictionary Standard.

To override a DDEX-defined value, the DDEX-defined value “UserDefined” shall be used, followed by single space character and a string representing the term to be communicated. This string shall only comprise lower case letters, upper case letters or digits, e.g. UserDefined StreamInOnlineGame.

Such user-defined values will need to be agreed between Licensor and Licensee and users are encouraged to raise these issues with DDEX with a view to having these values added to the list of DDEX-defined allowed values.

 6.13 Linking Records
The detailed Claim Detail Message Records of type CDxx reference a Summary Record CSxx by means of a SummaryRecordId Cell. Additional information to augment the detailed data communicated in a Claim Detail Message Records of type CDxx may be provided though a CXxx record carrying the same BlockId as the CDxx it provides additional information for.

Some records, such as the InvoiceDetailRecordId in the detailed Claim Detail Message data Records need to be referenced from other messages such as an invoice message. In that case the combination of MessageSenderId, MessageId (as communicated in the CDMH Record), BlockId and reference are globally unique.

When choosing a reference, users are strongly recommended to limit themselves to letters and digits, i.e. A-Z, a-z and 0-9.

 6.14 Version
The Version of this standard, 1.0, shall be communicated in the Header Record in accordance with Part 2 of the Claim Detail Message Suite Standard. 
 6.15 Transfer of Claim Detail Messages and Claim Detail Discrepancy Notifications
This standard defines two messages: one to communicate claims and/or invoice details and one for the communication of discrepancies or disputes. These messages are defined in other Parts of this standard.

Message Sender and Message Recipient (who may be Licensee and Licensor, or who may have been authorised by Licensee and Licensor) may use the following approach to exchanging (and acknowledging) Claim Detail and Claim Detail Discrepancy Notifications Messages created in accordance with this standard:

  1. TheMessage Sender, shall upload the file containing the Claim Detail Message or Claim Detail Discrepancy Notification to a mutually-agreed folder on a mutually-agreed SFTP server;
  2. Once the message has been uploaded completely, the Message Sender, shall place a zero-byte semaphore into a sub-folder of the folder containing the uploaded message; 
    The sub-folder shall be called file_available/ and the semaphore file shall have the same file name as the Claim Detail Message or Claim Detail Discrepancy Notification, albeit with a underscore prefix and a file extension of .ctrl instead of .tsv;
  3. The Message Recipient shall download the uploaded message once it has seen the relevant semaphore file;
  4. Once the Message Recipient has successfully downloaded the message it shall delete the relevant semaphore file from the SFTP server;
  5. The Message Recipient may also delete the uploaded message from the SFTP server at this stage; and
  6. Should Message Sender and Message Recipient agree to communicate acknowledgements for Claim Detail Messages or Claim Detail Discrepancy Notifications, these should be placed, by the Message Recipient, into a sub-folder of the folder containing the uploaded Claim Detail Message or Claim Detail Discrepancy Notification called acknowledgements/. The name of the acknowledgement file shall be the name of the acknowledged message, albeit with three changes:
    • The name of the acknowledgement shall be preceded by ACK_ instead of the MessageType indicated below; and
    • The time stamp shall be replaced with a time stamp of the acknowledgement, expressed in the same syntax as the time stamp used in the file name of the uploaded message.

DDEX may define the syntax of the acknowledgement message in a separate Part of this standard at a later time.

All Claim Detail Messages and Claim Detail Discrepancy Notifications files shall be named in accordance with the Clause 6.16.

 6.16 File Name Convention
All Claim Detail Messages and Claim Detail Discrepancy Notifications files shall be named in accordance with the following syntax:

MessageType_MessageRecipient_MessageSender_ServiceDescription_MessageNotificationPeriod_TerritoryOfUseOrSale_MessageCreatedDateTime.ext

With:

MessageType

The name of the profile as defined in the appropriate Part of this standard (e.g. BasicCDMPostUsage for a Claim DetailMessage to communicate claims and/or invoice details in a post-usage context or OverClaimDiscrepancy for a Claim Detail Discrepancy Notification used to report overclaims). In case of retractions in accordance with Clause 5.3, the Message Type shall be set to CDMRetraction.

MessageRecipient

The Party Name or DDEX Party ID (DPID) of the Message Recipient (which may or may not be different from Licensor or Licensee). In the case of Claim Detail Messages, this is typically a Licensee; in the case of Claim Detail Discrepancy Notifications, this is typically a Rights Controller.

Note: DDEX Party IDs do not contain special characters.

MessageSender

The Party Name or DDEX Party ID (DPID) of the Message Sender (which may or may not be different from the Licensor or the Licensee). In the case Claim Detail Messages, this is typically a Licensor; Claim Detail Discrepancy Notifications, this is typically a Licensee.

This information shall be the same as that which is conveyed in the Header Record of the Claim Detail Message or Claim Detail Discrepancy Notification. Note: DDEX Party IDs do not contain special characters.

ServiceDescription

A description of the service name (e.g. a service tier) to be reported on as agreed by Licensor and Licensee. Multiple tiers can be communicated by separating them with dashes.

This information shall be the same as the information conveyed in the file Header and it is recommended to be the same as used in the filename the message is in response to.

Message-
Notification-
Period

The reporting Period covered by the Message in accordance with ISO 8601. The only allowed syntaxes are:

  • yyyy for a year
  • yyyy-mm for a month
  • yyyy-mm-dd for a day
  • yyyy-qq for a quarter
  • yyyy-ww for a week (starting on a Monday)
  • yyyy-mm-dd--yyyy-mm-dd with the two dates being the start and end date of the period (note the two dashes between the two dates).

TerritoryOf-
UseOrSale

The territory in which the sales/usage transactions took place in respect of which the Claim Detail Message or Claim Detail Discrepancy Notification is in respect of.

The TerritoryOfUseOrSale shall be provided as a single ISO Territory Code if one territory is to be communicated. Otherwise, the Licensor and Licensee(s) shall agree a value acceptable to both/all.

MessageCreatedDateTime

The date and time on which the Claim Detail Message or Claim Detail Discrepancy Notification was created. The only allowed format is the full basic ISO 8601 format without a time zone designator: yyyyymmddthhmmss. The time zone is assumed to be the one of the Message Sender's (which may or may not be different from Licensor or Licensee) location.

ext

The file extension, to be “.tsv.
When the file is compressed, for example with gzip, the extension should indicate this and may be .tsv.gz.

The following constraints apply:

  1. None of the file name elements may contain an underscore character.
  2. None of the file name elements may contain a space character.
  3. When a file name element is to be omitted, the two underscore characters to the left and right follow each other immediately.
  4. Other file naming conventions may be agreed on a bilateral basis (specifically for testing).
 6.17 Aiding Human Readability
Messages created in accordance with this standard are produced so that they can be ingested and processed automatically. However, when establishing a new data feed as well as for error handling during normal operation it may be helpful for humans to be able read a Claim Detail Message or Claim Detail Discrepancy Notification.

It is therefore recommended, for each Record Type used in a Message created in accordance with this standard, to include a Record that provide Cell “headings” for that Record once. The first Cell of such Records is populated with the relevant Record Type and shall be preceded by a hash symbol (“#”) in accordance with Clause 6.8.

Note: if such headings are over-used and/or repeated too often, they could unnecessarily inflate the file size.

7 Profiles

 7 Profiles
The architecture for all messages in this standard are defined herein. The Record Types used in all messages formatted in accordance with this standard can be found in Part 2 of the Claim Detail Message Suite Standard.

These Record Types are used in Profile-specific standards which are, in turn, built upon this standard. At the time of writing this Part, the following Profiles have been defined by DDEX as:

  1. Profile for Post-usage Reporting of New Claims and/or Invoice Details (Part 3);
  2. Profile for Correcting Post-usage Reports of New Claims and/or Invoice Details (Part 3);
  3. Profile for Pre-usage Reporting of New Claims (Part 3);
  4. Profile for Correcting Pre-usage Reports of New Claims (Part 3);
  5. Notification of Record Discrepancies (Part 4); and
  6. Notification of Over-Claim Discrepancies (Part 5).

DDEX expects to add further Profile standards over time. They will be published on the DDEX Knowledge Base where a complete list of Profiles of the Claim Detail Message Suite Standard can be found.

 

Evaluation Licence for DDEX Standards

 

 

Subject to your compliance with the terms and conditions of this Agreement, DDEX™ grants you a limited, nonexclusive, non-transferable, non-sublicenseable, royalty-free licence solely to reproduce, distribute within your organisation, and use the DDEX standard specifications (“DDEX Standards”) solely for the purpose of your internal evaluation. You may not make any commercial use of the DDEX Standards under this agreement. No other licences are granted under this agreement.

No representations or warranties (either express or implied) are made or offered by DDEX with regard to the DDEX Standards. In particular, but without limitation, no representations or warranties are made in relation to:

  1. The suitability or fitness of the standards for any particular purpose;
  2. The merchantability of the standards;
  3. The accuracy, completeness, relevance or validity of the standards; or
  4. The non-infringement of any third party intellectual property rights related to the DDEX Standards.

Accordingly, DDEX and/or its members shall not be liable for any direct, indirect, special, consequential or punitive loss or damages howsoever arising out of or in connection with the use of the standards. IN THE EVENT THAT ANY COURT OF COMPETENT JURISDICTION RENDERS JUDGEMENT AGAINST DDEX AND/OR ITS MEMBERS NOTWITHSTANDING THE ABOVE LIMITATION, THE AGGREGATE LIABILITY TO YOU IN CONNECTION WITH THIS AGREEMENT SHALL IN NO EVENT EXCEED THE AMOUNT OF ONE HUNDRED U.S. DOLLARS (US$ 100.00).

Users of the DDEX Standards are cautioned that it is subject to revision. Users are recommended to use the latest versions, which are available at http://www.ddex.net. The use of outdated versions of the standards is not recommended but may be required by agreement between implementers in particular cases.