- Created by DDEX Secretariat, last modified on 2016-11-18
This section of the DDEX Knowledge Base contains version 2.0 of the "Release and Business Profiles for Sales Reports"
Introduction
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
... 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)
2 Scope
Complete, valid, sample XML files supporting these Release and Business Profiles are available for download from http://ddex.net.
- “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-∞”.
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.
- 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.
Finally, the Release profiles defined herein follow the Release profiles defined for Release Deliveries (see the Clause 2.4).
3 Definition of Profiles
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
.
Table 1 — Release Profiles defined in this Standard
Release Profile | Resources contained in Release |
| |
Primary Resources/Collections | Secondary Resources |
| |
1. Audio Single |
| ||
2. Video Single A single music video recording plus support screen capture image. |
| ||
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. |
| ||
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. |
| ||
5. Video Album A product with several video recordings, plus screen capture per track and supporting cover image. |
| ||
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. |
| ||
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). |
| 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. |
|
| |
10. Single Resource Release A single Resource not for distribution to consumers. Typically provided to a partner for finger printing /rights management type services. |
| 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 forReleases
andResources
; - If the sender of the sales report has it’s own
ProprietaryId
for aRelease
, Resource orMusicalWork
, suchProprietaryIds
shall be provided;(*) - If the sender of the sales report has any
ProprietaryId
, allocated by a third party for aMusicalWork
, suchProprietaryIds
shall be provided; - Territorial variations of Releases and Resources should be avoided where possible and the only
TerritoryCode
should beWorldWide
; the use ofExcludedTerritoryCode
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.
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 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:
- A MessageThreadId and MessageID shall be provided.
- A MessageSender and MessageRecipient shall be provided through a DPID and a FullName.
- 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.
- A MessageCreatedDate shall be provided.
- 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:
- At least one ReleaseId, without the IsReplaced flag being set shall be communicated.
- A ReleaseType shall be communicated.
- A ReleaseReference shall be included.
- The TitleText of a ReferenceTitle shall be communicated.
- No RightsAgreementId or RelatedRelease shall be provided.
- At least one ReleaseSummaryDetailsByTerritory shall be communicated, typically with the TerritoryCode set to WorldWide with the following subelements:
- At least one DisplayArtistName and LabelName shall be provided.
- No RightsAgreementId shall be provided.
- A SalesReportToSocietyMessage
- 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.
- 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:
- A DSP composite needs to be provided with the FullName of the DSP’s PartyName and a Party ID.
- A Licensor shall be provided in a SalesReportToSocietyMessage with the FullName of the Licensor’s PartyName and a Party ID.
- At least one SalesByCommercialModel shall be provided as follows:
- One or more CommercialModelTypes need to be provided in accordance with Table 2.
- One CurrencyOfAccounting is to be provided.
- At least one SalesByTerritory shall be provided as follows:
- Exactly one TerritoryCode shall be provided. This may not be “WorldWide”.
- No TaxRate and no Deal shall be provided.
- At least one ReleaseTransaction shall be provided as follows:
- A TransactionReleaseReference shall be provided for each Release.
- 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.
- Comments and DurationsUsed are not to be included in the message.
- 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.
- 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.
- DspGrossRevenue shall be provided for subscription services with UseType(s), UserInterfaceType(s) and DistributionChannelType(s) in accordance with Table 2.
- DspDeductionsAmounts or PercentageNetRevenueShare may be communicated if required by the commercial relationship between sender and recipient.
- No,MinimumAmountPerCustomer, WholesaleAmountTotal, WholesaleAmountTotalInCurrencyOfAccounting and CurrencyExchangeRate need to be reported.
- 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.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
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.
- 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.