Data Exchange Mechanisms
The data to be exchanged, and the mechanism to be used to exchange it, will depend on the scenario between you and your customer. In this post we will outline the approach that can be used in two main scenarios when one of the parties isn’t using Cradle:
- One to One – single need to single response
- One to Many – single need may link to one or more responses
Each of these scenarios can be further varied by being a ‘one off’ or an iterative repeated exchange.
Scenario 1 -One to One
This scenario is where the customer has a list of needs and each need will only have one response, you then have the option of capturing the data only once or capturing the needs and responses multiple times.
Once-only Data Exchange (one to one)
The simplest approach where your customer/supplier has a list of needs, you can then respond to each need with values for the new attributes. One file is exchanged between you and the customer which they incorporate with their needs.
Within Cradle you have a single item type for these needs, the item type would be made up of the following attributes:
Need # | Need ID (n#) |
Need | Text frame to store the need statement |
Compliance | Category to record the compliance of the response |
Response | Text frame to store a statement of how it is compliant |
Responses would then be added to each need, with values for the new attributes, such as the degree of compliance and a statement of how it is compliant.
There are a number of ways the response could be sent to the customer / supplier, as a report, a document or using an interchange such as CSV (Comma Separated Values).
Once all your responses are updated the next step is to create an export file to send to your customer.
Use CSV which includes only plain UTF-8 and avoid codepage issues. Only one file needs to be sent which includes:
- Need #
- Compliance
- Response
To make this process easier you can set up export formats with the settings you want so that each time you want to run the process you don’t need to remember what the correct setting is. You can choose to load the export format which will instantly load the settings you have saved.
The customer then merges your response into their needs by importing the file with overwrite set to merge. The customer could also use import formats so each time you supply an update they have the correct import settings.
Repeated Data Exchange (one to one)
Your customer/customer has a list of needs where there are multiple copies for each need, you would then respond with datestamps so that when the customer imports the file the correct needs are updated. One file is exchanged between you and the customer which they incorporate with their needs.
Within Cradle you have a single item type for these needs, the item type would be made up of the following attributes:
Need # | Need ID (n#) |
Need | Text frame to store the need statement |
Compliance | Category to record the compliance of the response |
Response | Text frame to store a statement of how it is compliant |
Need-Datestamp | Category to record need date (ndate) |
Response-Datestamp | Category to record response date (rdate) |
Responses should then be added to each need, with values for the new attributes, such as the degree of compliance and a statement of how it is compliant. Responses have a datestamp and will overwrite their predecessor when loaded.
Once all your responses are updated the next step is to create an export file to send to your customer. There are a number of ways the response could be sent to the customer / supplier, as a report, a document or using an interchange such as CSV (Comma Separated Values).
Use CSV which includes only plain UTF-8 and avoid codepage issues. Only one file needs to be sent which includes:
- Need #
- Need-Datestamp
- Compliance
- Response
- Response-Datestamp
To make this process easier you can set up export formats. (See above regarding export formats)
The customer then merges your response into their needs by importing the file with overwrite set to merge. Responses have a datestamp and will overwrite their predecessor when loaded. The customer could also use import formats so each time you supply an update they have the correct import settings.
Scenario 2 -One to Many
This scenario is where the customer has a list of needs and each need may have many responses and/or a single response may be valid for multiple needs. The advantage of this scenario is that duplication of data is kept to a minimum, you also have the option of capturing the data only once or capturing the needs and responses multiple times.
Once-only Data Exchange (one to many)
Where your customer has a list of needs, you then respond with the new item (response) which you can link to a need. The major advantage of this is that a response can apply to more than one need removing the possibility of duplicate data/information.
Within Cradle you have two item types one for needs and one for the responses.
The need item type would be made up of the following attributes:
Need # | Need ID (n#) |
Need | Text frame to store the need statement |
Compliance | Category to record the compliance of the response |
The response item type would be made up of the following attributes:
Response # | Response ID (r#) |
Response | Text frame to store the response statement |
Compliance | Category to record the compliance of the response |
Response items would be created for each need with values for the new attributes, such as the degree of compliance and a statement of how it is compliant and linked to the corresponding need.
Once all responses are updated the next step is to create files to send to your customer. You can send one file which includes the Response #, Compliance, Response and a list of related need #’s. This single file would be loaded from a Word table with the above columns. Or load two CSV plain UTF-8 files, one with responses and the other with links.
Sends 1 file: | Response #, Compliance, Response, list of related need #s |
Or 2 files: | Response #, Compliance, Response |
Need #, Response # |
To make this process easier you can set up export formats. (See above regarding export formats)
The customer then incorporates your responses with their needs by importing the file with overwrite set to merge. The customer could also use import formats so each time you supply an update they have the correct import settings.
Repeated Data Exchange (one to many)
Where there are multiple copies for each need, you then respond with new items (responses) with a datestamp which you can link to a need. The major advantage of this is that a response can apply to more than one need removing the possibility of duplicate data/information as well as dealing with multiple copies of a need.
Within Cradle you have two item types, one for needs and one for the responses.
The need item type would be made up of the following attributes:
Need # | Need ID (n#) |
Need | Text frame to store the need statement |
Compliance | Category to record the compliance of the response |
Need-Datestamp | Category to record need date (ndate) |
The response item type would be made up of the following attributes:
Response # | Response ID (r#) |
Response | Text frame to store the response statement |
Compliance | Category to record the compliance of the response |
Response-Datestamp | Category to record response date (rdate) |
Response items would be created for each need with values for the new attributes, such as the degree of compliance and a statement of how it is compliant and linked to the corresponding need.
Responses are created for each need, each with an ID (r#). Responses
have a datestamp and overwrite their predecessor when loaded. All links to needs are replaced in each load.
Once all responses are updated the next step is to create files to send to your customer. You can send one file which includes the Response #, Compliance, Response and a list of related need #’s. This single file would be loaded from a Word table with the above columns. Or load two CSV plain UTF-8 files, one with responses and the other with links.
Sends 1 file: | Response #, Need-Datestamp, Response-Datestamp, Compliance, Response, list of related need #s |
Or 2 files: | Response #, Need-Datestamp, Response-Datestamp, Compliance, Response |
Need #, Response # |
To make this process easier you can set up export formats with the settings you need so that each time you want to run the process you don’t need to remember what the correct settings are.
Customer loads responses and links each response to the associated needs. If the customer has multiple copies of each need, the need datestamps identify which needs to update. There are a number of options you can use to capture the data: