This section of the DDEX Knowledge Base contains version 2.0 of the "Release and Business Profiles for Sales Reports"

Introduction

The Digital Data Exchange, LLC (DDEX) has, in the past defined a series of message suite standards to make the communication of information along the digital music delivery chain more efficient. As part of these message is the communication of sales and usage reports from retailers of Releases to relevant rights holders, such as record companies — for rights in sound recordings and/or video resources — and music rights societies or music publishers — for rights in the underlying musical work.

Such sales and usage reports can, however, vary between different uses. For instance, reports would differ by the type of organisation they are sent to: a report to a sound recording rights holder would carry different information from a report sent to the controller of musical work rights. Similarly, “marketing reports” often differ from “financial reports”.
In order to aid companies that only wish to communicate a small subset of the types of products that the “full” DDEX standards allow, DDEX has developed a series of “profiles”. These profiles come in two flavours. Firstly “Release Profiles” that define subsets of Releases to be communicated along the music delivery chain and, secondly, “Business Profiles” that define subsets of the commercial information governing the distribution of Releases.

This standard defines a set of Release and Business Profiles that define how to use the Digital Sales Reporting Message Suite Standard to express the most common types of sales and usage reports to owners or rights controllers with respect to musical works as well as sound recordings and other resources.

The full set of Release and Business Profiles is available from http://ddex.net. 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 at http://ddex.net/implementing-ddex-standards.

Downloads & Older Versions

Download/Print standard (PDF)

XML Sample Files (ZIP)

The DDEX Data Dictionary ...

... for the Recording Data and Rights Choreography Standard (RDR-C, Version 1.0): Message Structure and AVSs

... for the US Letters of Direction Choreography Standard (LoD, Version 1.0): Message Structure and AVSs

... for the Electronic Release Notification Message Suite Standard (ERN, Version 4.2): Message Structure and AVSs

... for the Musical Work Right Share Notification Choreography Standard (MWN. Version 1.2): Message Structure and AVSs

... for the US Musical Work Licensing Choreography Standard (MWL, Version 1.0): Message Structure and AVSs

... for the Standard for the Communication of Media Enrichment and Description Information (MEAD): Message Structure and AVSs

... f or the Standard for communicating links between Resources and Musical Works (Version 1.1)

... for the Recording Data and Rights Standard (Version 1.4)

... for Release Deliveries using SFTP or Web Service (Version 1.7)

... for the Recording Information Notification (Version 1.1)

... for Work and Share Notifications

... for Works Licensing

Why are there multiple data dictionaries?

2 Scope

2.1 Overview

This standard defines the most widely used Release and Business Profiles for Sales Reports. They are provided in two forms: (i) a summary of the differences between any Release Profile and the relevant “full” standard (in Clause 2) and (ii) sample XML messages.

Complete, valid, sample XML files supporting these Release and Business Profiles are available for download from http://ddex.net.

2.2 Nomenclature

The following mathematical nomenclature is used in this standard.

“0-1” means that at most one (i.e. either none or one) element has to be included in the relevant Profile;
“0-∞” means that any number (i.e. either none, one or more) of elements may be included in the relevant Profile; and
“1-∞” means that at least one element have to be included in the relevant Profile.

The term “mandatory” encompasses the two cardinality expressions “1” and “1-∞”. The term “optional” encompasses the two cardinality expressions “0-1” and “0-∞”.

2.3 Organisation of the Document

This standard has three clauses and two annexes. While Clauses 1 and 2 provides general introductory information, Clause 3 provides the Release and Business profiles defined herein. Annex A then provide normative sample XML (the actual XML code is provided in separate documents) whereas Annex B then defines a mechanism on how to communicate allowed values defined by DDEX later than the message format used in the communication between two business partners.

Note: DDEX may also make available ISO/Schematron rules to support automatic validation of the rules documented herein. These ISO/Schematron will become part of the formal conformance regime that DDEX is in the process of setting up.

2.4 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.

Digital Data Exchange (DDEX): Sales Reporting Message Suite Standard, Version 4.2
Digital Data Exchange (DDEX): Release Profile for Common Release Types, Version 1.1.

Note: the provisions within this standard are specific to the above-mentioned standards. However, users for older versions of the baseline standards are encouraged to still follow the rules defined herein wherever technically and practically possible as the provisions within this profile standard are accepted best practice for the communication of Release and Sales/usage information.

2.5 Release Notes

Version 2.0 of this standard supports sending sales reports to record companies in addition to those to be sent to music rights societies. It also makes use of the Version 4.x of the Digital Sales Reporting Message Suite standard and its tighter linking of the Release descriptions and the sales figures.

Finally, the Release profiles defined herein follow the Release profiles defined for Release Deliveries (see the Clause 2.4).

3 Definition of Profiles

3.1 Introduction

This standard defines Profiles for two types of reports: Financial Reports in which the message sender provides financial information with respect to the use of Releases to enable sender and recipient of the message to settle financial transactions (e.g. royalty payments). Marketing Reports, on the other hand, are reports that are used by the recipients primarily for market analysis purposes. Marketing reports are typically only sent to owners of sound recording rights (i.e. record companies). It should be noted, for the avoidance of doubt, that Marketing Reports may also include financial information but such information is not used without a Financial Report to settle financial transactions between message sender and message recipients. Reports that are meant as a means to communicate information for settling financial transactions, whether they are used for marketing research purposes as well, are Financial Reports, not Marketing Reports.

The Profiles defined in this standard come in two sets: One set defines the structure of Releases that are being reported as being sold in a sales report and one set defining the terms and conditions, including price, of the use such Release have been put to. The former Profiles are Release Profiles as defined in Sub-clause 3.2 and the latter are Business Profiles defined in Sub-clause 3.3.

The Release Profiles only apply to the SalesReportToSocietyMessage as the SalesReportToRecordCompanyMessage cannot be profiled with respect to Release information; thus the ReleaseProfileVersionId shall not be used in the SalesReportToRecordCompanyMessage.

3.2 Release Profiles

This standard defines ten Release Profiles. They are categorised by the structure of elements and sub-elements as defined in the table below.

Table 1 — Release Profiles defined in this Standard

Release Profile Name and description	Resources contained in Release
Release Profile Name and description	Primary Resources/Collections	Secondary Resources
1. Audio Single A single SoundRecording plus supporting cover image.	1-∞ SoundRecording of type MusicalWorkSoundRecording 1 Image of type FrontCoverImage, 0-∞ items of bonus material

2. Video Single A single music video recording plus support screen capture image.	1-∞ Video of type ShortFormMusicalWorkVideo 1 Image of type VideoScreenCapture 0-∞ items of bonus material

3. Mixed Media Bundle A product with a mixture of several audio and video recordings and potentially images and text, plus supporting screen capture per video track and a single cover image.	0-∞ SoundRecordings of type MusicalWorkSoundRecording 0-∞ Videos of type ShortFormMusicalWorkVideo 0-∞ Images of type Photograph, FrontCoverImage, BackCoverImage, BookletFrontImage BookletBackImage, Poster or Wallpaper 0-∞ Texts At least 2 Resources of different types 1 Image of type FrontCoverImage 0-∞ Images of type VideoScreenCapture 0-∞ items of bonus material (e.g. such as Images and Booklets)


4. Audio Album A product with several audio recordings, some of which are not songs, plus supporting cover image, including singles containing more than one Resource. Examples include comedy shows.	1-∞ SoundRecordings of type MusicalWorkSoundRecording or NonMusicalWorkSoundRecording 1 Image of type FrontCoverImage 0-∞ items of bonus material

5. Video Album A product with several video recordings, plus screen capture per track and supporting cover image.	1-∞ Video of type ShortFormMusicalWorkVideo 1 Image of type FrontCoverImage 0-∞ Images of type VideoScreenCapture 0-∞ items of bonus material

6. Ringtone A single audio mobile ringtone clip.	1 SoundRecording of type RingtoneClip 0-1 Image of type FrontCoverImage
6. Ringtone A single audio mobile ringtone clip.
7. Long-form Music Video A multi-chapter long form video recording, plus a supporting cover image and potentially a screen capture per chapter.	1 Video with a type of either LongFormMusicalWorkVideo, ConcertVideo or Documentary 1 Image of type FrontCoverImage 0-∞ Images of type VideoScreenCapture 0-∞ items of bonus material

8. Digital Boxed Set A multi-volume/component digital product made up of a number of other existing digital products, plus supporting cover image(s).	0-∞ SoundRecordings of type MusicalWorkSoundRecording 0-∞ Videos of type ShortFormMusicalWorkVideo	1-∞ Images of type FrontCoverImage 0-∞ Images of type VideoScreenCapture 0-∞ items of bonus material



9. Classical Audio Album A product with several audio recordings, grouped into classical works, plus supporting cover image.	1-∞ SoundRecordings of type MusicalWorkSoundRecording, albeit with additional elements as defined below 1 Image of type FrontCoverImage 0-∞ items of bonus material
10. Single Resource Release A single Resource not for distribution to consumers. Typically provided to a partner for finger printing /rights management type services.	1 Resource of any type	None

Details or communicating such Releases are defined in the DDEX Standard Release Profile for Common Release Types, Version 1.1 with the addition of following constraints (note, the above table has been taken from that standard):

All available Titles, DisplayArtistNames are mandatory to be provided for Releases and Resources;
If the sender of the sales report has it’s own ProprietaryId for a Release, Resource or MusicalWork, such ProprietaryIds shall be provided;(*)
If the sender of the sales report has any ProprietaryId, allocated by a third party for a MusicalWork, such ProprietaryIds shall be provided;
Territorial variations of Releases and Resources should be avoided where possible and the only TerritoryCode should be WorldWide; the use of ExcludedTerritoryCode should be avoided; and
Collections and CueSheets should not be provided and may be ignored by the message recipient.

(*) In most circumstances it is recommended to not send any proprietary IDs but to focus on identifiers such as GRid, ISRC and ISWC. However, for sales reports, where recipients often do not have any information about sold Releases before ingesting such reports, any identifiers can help matching the received data to data available in the recipients’ system(s). For example a music publisher might receive, from a record company catalogue information which contains the labels’ internal work identifier (typically called “song ID” or “song code”). If a label would forward this information to all it’s distribution partners and if these then forward this work identifier to the music publisher when sales are reported, the amount of work the publisher needs to do to identify the composer is greatly reduced.

3.3 Business Profiles

This standard defines 17 Business Profiles. They are categorised by a series of key allowed-values that need to be communicated in the relevant fields in a conformant sales report message.

In some cases it may be necessary to specify a specific DistributionChannelType and/or UserInterfaceType (e.g. for an internet-only Ad-Supported Download Service or an Ad-Supported Conditional Download Service limited for use on mobile phones). If none of these values are provided in a sales report any DistributionChannelType and/or UserInterfaceType may have been used by the message sender’s consumers. The same applies for DrmEnforcementType with no DrmEnforcementType meaning that the consumer accessed DRM-protected and/or non-protected content.

Table 2 — Business Profiles defined in this Standard

Profile Name	CommercialModel-Type	UseType	Other aspects
1. Generic Download Service Consumers can download content via the internet and keep the DRM-protected Releases with no limitation (this profile was called “profile 1” in the Business Profile: Sales Reporting to Music Rights Societies).	PayAsYouGoModel	PermanentDownload
2. Ringtones and Mobile Service Consumers can access content as Ringtones on their mobile phones. This also includes other "Mobile Products" (2).	PayAsYouGoModel	UseAsRingtone or UseAsRingbackTone
3. Subscription Download Service Consumers can download content via the internet and keep the Releases (5).	SubscriptionModel	PermanentDownload
4. Interactive Subscription Streaming Service Consumers subscribe to a service where they can interactively stream content from a large repository of content (6).	SubscriptionModel	OnDemandStream
5. Interactive Ad-Supported Subscription Streaming Service Consumers can download content via the internet and keep the Releases as long as a subscription is kept. Payment is partly via subscription fees and party through advertisements (13).	AdSupportedModel followed by[1] SubscriptionModel	OnDemandStream
6. Tethered[2] Subscription Download Service Consumers can download content via the internet and keep the Releases as long as a subscription is kept (7).	SubscriptionModel	Conditional-Download
7. Interactive Ad-Supported Streaming Service Consumers subscribe to a service where they can interactively stream content from a large repository of content. Payment is received via advertisement.	AdSupportedModel	OnDemandStream
8. Ad-Supported Non-interactive Streaming[3] Consumers subscribe to a service where they cannot interact with the stream content beyond start/pause/stop/skip from a large repository of content. Payment is received via advertisement. Also: Consumers can listens to pre-programmed (often algorithmically generated) stream of music with no interactivity. Payment is received via advertisement. (9)	AdSupportedModel	NonInteractive-Stream
9. Ad-Supported Time-limited-Interactive Streaming Service Consumers can stream music with only temporal interactivity. Payment is received via advertisement (10).	AdSupportedModel	TimeInfluenced-Stream
10. Ad-Supported Download Service Consumers can download content via the internet and keep the DRM-protected Releases with no limitation. Payments are funded through advertisements (11).	AdSupportedModel	PermanentDownload
11. Ad-Supported Teathered Download Service Consumers can download content via the internet and keep the Releases as long as a subscription is kept. Payments are funded through advertisements (12).	AdSupportedModel	ConditionalDownload
12. Non-Protected Download Service Consumers can download content via the internet and keep the non-protected Releases with no limitation.	PayAsYouGoModel	PermanentDownload	DrmEnforce-mentType of NotDrmEnforced
13. DRM-Protected Download Service Consumers can download content via the internet and keep the DRM-protected Releases with no limitation.	PayAsYouGoModel	PermanentDownload	DrmEnforce-mentType of DrmEnforced
14. Kiosk Service Consumers can access a physical Kiosk and download content from there. They can then keep the Releases.	PayAsYouGoModel	PermanentDownload	UserInterface-Type of Kiosk
15. Non-Interactive Subscription Streaming Service[4] Consumers subscribe to a service where they cannot interact with the stream content beyond start/pause/stop/skip from a large repository of content. Also: Consumers can listens to pre-programmed (often algorithmically generated) stream of music with no interactivity. Payment is received via subscription fee.	SubscriptionModel	NonInteractive-Stream
16. Non-Interactive Ad-Supported Streaming Service Consumers subscribe to a service where they cannot interact with the stream content beyond start/pause/stop/skip from a large repository of content. Payments are funded through advertisements	AdSupportedModel	NonInteractive-Stream
17. Purchase As Physical Product	Normally not used	PurchaseAsPhysicalProduct

The following constraints on the sales report message shall be adhered to:

The MessageSchemaVersionId attribute to the root element shall be included and set in accordance with the relevant Sales Reporting Message Suite Standard.
The BusinessProfileVersionId and ReleaseProfileVersionId attributes to the root element shall be set in accordance with Sub-clause 2.4 of this standard.
A MessageHeader shall be provided as follows:
1. A MessageThreadId and MessageID shall be provided.
2. A MessageSender and MessageRecipient shall be provided through a DPID and a FullName.
3. A SentOnBehalfOf shall be provided only if message is created by a company not liable for reporting. In that case the same structure as below shall be used as for MessageSender and MessageRecipient.
4. A MessageCreatedDate shall be provided.
5. No AuditTrail shall be provided.
A MessageNotificationPeriod shall be provided.
No RemittanceAdvice, MessageContentRevenueType or RightsCoverage shall be provided.
A SalesReportToRecordCompanies shall contain ContainedReleaseSummary information for all Releases for which usages/sales are reports in the sales report message as follows:
1. At least one ReleaseId, without the IsReplaced flag being set shall be communicated.
2. A ReleaseType shall be communicated.
3. A ReleaseReference shall be included.
4. The TitleText of a ReferenceTitle shall be communicated.
5. No RightsAgreementId or RelatedRelease shall be provided.
6. At least one ReleaseSummaryDetailsByTerritory shall be communicated, typically with the TerritoryCode set to WorldWide with the following subelements:
  1. At least one DisplayArtistName and LabelName shall be provided.
  2. No RightsAgreementId shall be provided.
A SalesReportToSocietyMessage
1. Shall not contain any ContainedReleaseSummary but shall contain Release and Resource information in defined in Sub-clause 2.2 of this standard for all Releases for which usages/sales are reports in the sales report message.
2. May contain a MusicalWork composite. If that is provided, at least one "creative" MusicalWorkContributor should, if possible, be provided. "Creative" parties are parties with one of the following MusicalWorkContributorRoleCodes: Adapter, Arranger,AssociatedPerformer, Author, Composer, ComposerLyricist, Contributor, Librettist, Lyricist, NonLyricAuthor. SubArranger, Translator.
One SalesReport composite shall be provided as follows:
1. A DSP composite needs to be provided with the FullName of the DSP’s PartyName and a Party ID.
2. A Licensor shall be provided in a SalesReportToSocietyMessage with the FullName of the Licensor’s PartyName and a Party ID.
3. At least one SalesByCommercialModel shall be provided as follows:
  1. One or more CommercialModelTypes need to be provided in accordance with Table 2.
  2. One CurrencyOfAccounting is to be provided.
  3. At least one SalesByTerritory shall be provided as follows:
    1. Exactly one TerritoryCode shall be provided. This may not be “WorldWide”.
    2. No TaxRate and no Deal shall be provided.
    3. At least one ReleaseTransaction shall be provided as follows:
      1. A TransactionReleaseReference shall be provided for each Release.
      2. At least one SalesTransaction shall be provided as follows:
        UseType(s), UserInterfaceType(s) and DistributionChannelType(s) shall be provided in accordance with Table 2 (note, that UserInterfaceType and DistributionChannelType may be optional).
        A Deal/DetailedDeal shall be provided only in a SalesReportToRecordCompanies with any combination of the following optional fields: PriceInformation (with either PrieceRangeType, WholesalePricePerUnit or ECPM), PromotionalCode, CampaignName, DeductionRate, EffectiveUnitRoyaltyRateNet (wich is mandatory), IsReplacementPurchase and TechninalInstantiation plus a mandatory PriceConsumerPaidExcSalesTax. Any other element shall not be provided. (Note: this is the only place where a Deal composite is permissible)
        SalesData shall be provided as follows:
        SalesDataGrouping, including sub-elements, may be provided, typically for Marketing Reports in accordance with the commercial relationship between message sender and recipient.
        NumberOfConsumerSalesGross and NumberOfFreeUnitsToConsumers shall be provided.
        NumberOfUnitAdjustments and NumberOfUnitAdjustmentsToFreeUnits may be provided if adjustments are to be made.
        No isUpgrade flag shall be set.
        The DataToBeForwarded flag shall be provided appropriately.
      3. Comments and DurationsUsed are not to be included in the message.
    4. RecordCompanyMarketShareData shall only be provided in a SalesReportToRecordCompaniesMessage, if required by the commercial relationship between sender and recipient. This composite shall include UnitsSoldTotal and may include UseType(s), UserInterfaceType(s) and DistributionChannelType(s) in accordance with Table 2.
    5. NumberOfSubscribers and DspNetRevenues shall be provided even if no subscribers are reported with relevant UseType(s), UserInterfaceType(s) and DistributionChannelType(s) in accordance with Table 2.
    6. DspGrossRevenue shall be provided for subscription services with UseType(s), UserInterfaceType(s) and DistributionChannelType(s) in accordance with Table 2.
    7. DspDeductionsAmounts or PercentageNetRevenueShare may be communicated if required by the commercial relationship between sender and recipient.
    8. No,MinimumAmountPerCustomer, WholesaleAmountTotal, WholesaleAmountTotalInCurrencyOfAccounting and CurrencyExchangeRate need to be reported.
    9. TotalAmountPayableInCurrencyOfAccounting shall be reported.
TotalSalesByReleaseType needs to be reported in the SalesReportToRecordCompanyMessage only.
RoyaltyAmount and NumberOfSalesTransactionRecords need to be provided.
Systems are required to be able to operate on financial elements that are of a basic XML data type xs:decimal with six decimal digits unless specifically agreed differently by the involved parties.

All other data elements provided may be ignored by the message recipient.

[1] The sales report shall have one SalesReportByCommercialModel composites, with two CommercialModel-Type elements as defined in the table.

[2] This is also called conditional subscription download.

[3] Also known as Ad-Supported Web Radio.

[4] Also known as Subscriber Web Radio

3.4 Signalling a Specific Profile

3.4.1 Financial Reports

To indicate the use of a specific Profile in in providing a Financial Report, the ReleaseProfileVersionId and BusinessProfileVersionId attribute on the root tag of the message shall be set as follows:

FinancialReportProfile/20

With “xxx” being the name of the Profile as defined in bold face in column 1 of the tables listed in this Clause without any space, dash or parentheses characters. For example, a sales report to a music rights society in accordance with the Generic Download Service Business Profile and the Audio Single Release Profile defined herein shall have the BusinessProfileVersionId attribute set to

FinancialSalesReportProfile/20/GenericDownloadService

and the ReleaseProfileVersionId set to

FinancialSalesReportProfile/20/AudioSingle

3.4.2 Marketing Reports

To indicate the use of a specific Profile in providing a Marketing Report, the BusinessProfileVersionId attribute on the root tag of the message shall be set as follows:

MarketingSalesReportProfile/20

With “xxx” being the name of the Profile as defined in bold face in column 1 of the tables listed in this Clause without any space, dash or parentheses characters.

Annexes

Annex A (normative) XML Samples

A.1 Introduction

Normative XML Samples are provided in separate files as detailed in the sub-clauses below. Conformance to this standard requires looking at the relevant Business Profile files and the relevant Release Profile files.

A.2 Business Profiles

Business Profiles are represented by two XML sample files representing all Business Profiles. The files are named BusinessProfile_SalesReportToRecordCompanyMessage.xml and BusinessProfile_SalesReportToSocietyMessage.xml respectively.

These files only contain one dummy Release description to ensure the message is valid.

A.3 Release Profiles

Release Profiles for the SalesReportToSocietyMessage are represented through a set of XML files named after the name of the Release Profile as used in the main part of this standard The name of the XML files always starts with ReleaseProfile_.

The XML code for the SalesReportToRecordCompanyMessage is provided in BusinessProfile_SalesReportToRecordCompanyMessage.xml.

These messages do not contain any sales figures.

Annex B (informative) Communication of Allowed Values defined in a Later Standard

In order to communicate an allowed values defined by DDEX later than the message format used in the communication between two business partners the following approach shall be taken:

The element shall contain the value “UserDefined”;
The UserDefinedValue attribute shall be set to the value from the later standard; and
The Namespace attribute shall be set to the same value as defined as normative content for the MessageVersionId attribute for that standard.

For example, to communicate a UseType of KioskDownload, a term defined for Version 3.3 of the Release Notification Standard in a Version 3.2 message the following XML code shall be used:

<UseType UserDefinedValue="KioskDownload" Namespace="ern/33">
   UserDefinedValue
</UseType>

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:

The suitability or fitness of the standards for any particular purpose;
The merchantability of the standards;
The accuracy, completeness, relevance or validity of the standards; or
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.

Release and Business Profiles for Sales Reports