Architecture, Allowed Value Sets and Record Type Definitions
Parts 1: Architecture, Part 2: Allowed Value Sets and Part 8: Record Type Definitions of DSR effectively provide a framework that applies to all the message profiles and the detailed building blocks that are used to create individual messages. When implementing a particular profile, reference has to be made to these parts of the standard for both the basic structure and the detailed elements that make up the message profile.
This part defines the common architecture that applies to all the different profile messages contained in DSR. The current Part 1 is version 1.3 the text of which is available here. The specification defines all aspects of the architecture of the message profiles, including:
The basic choreography that applies to all sales/usage profiles defined in other parts of the standard;
Descriptions of Multi-Record and Single-Record Block Variants that exist for some of the profiles and the distinctions between them. More information on this is available here;
How Blocks are created within a profile, a description of their constituent parts and how these interrelate within a DSR message;
File naming conventions; and
Common technical details that apply to all profiles, such as character coding, delimiters, how to manage empty records or cells and file or cell size.
This part sets out all the allowed value sets that can be used in the message profiles, the allowed values used and a definition of each. Some of these allowed value sets are used commonly throughout the different message profiles whilst others are specific to a particular message profile. The current Part 2 is version 1.4.1 the text of which is available here.
All of the profiles list the Blocks that are required to create a message that conforms to that profile. Within each Block are listed a series of Records that makeup that Block. Each of the Records contains a number of cells setting out what data should be included in that cell when creating a message which conforms to the profile. Some of these Records are common across all or many of the profiles, such as the Header Record or the Footer Record, many are specific to a given profile.
In order therefore to be able to create a message that conforms to a profile, implementers must identify which Records are required for that profile and then reference the detail of that Record in the Record Type Definitions part of the standard. The current Part 8 is version 1.4 the text of which is available here.