Functional Design ecm Test scenarios for the EFET Test facility Broker Tests Product tests
|
|
|
- Lisa Dennis
- 8 years ago
- Views:
Transcription
1 Functional Design ecm Test scenarios for the EFET Test facility Broker Tests Product tests Arnhem, May 2006 Author M. Adriaensen / Y. Slee / L. van Vught By order of EFET author : M. Adriaensen / Y. Slee / L. van Vught B 46 pages 0 annexes approved : reviewed : W. Strabbing KEMA Nederland B.V. Utrechtseweg 310, 6812 AR Arnhem P.O. Box 9035, 6800 ET Arnhem The Netherlands T F contact@kema.com Registered Arnhem
2 Copyright KEMA Nederland B.V., Arnhem, the Netherlands. All rights reserved. This document contains proprietary information that shall not be transmitted to any third party without written consent by or on behalf of KEMA Nederland B.V. The same applies to file copying, wholly or partially. KEMA Nederland B.V. and/or its associated companies disclaim liability for any direct, indirect, consequential or incidental damages that may result from the use of the information or data, or from the inability to use the information or data.
3 Control registration Project: EFET Test Facility ecm Messages Version 3.2 Project number: Client: EFET Document name: Functional Design Test Scenarios Document number: Version Date Status Description Author Appr Draft Initial version WS MAdr Draft Several changes in document and test MAdr WS scenarios added Draft Several changes in document and test YS MAdr scenarios added Draft Complete revision of the scenarios LV MAdr Draft Review of the scenarios LV MAdr Draft Tscenarios converted to Sscenarios to avoid LV MAdr notsupported situations Draft Broker scenarios added LV MAdr Draft Ready for external review LV MAdr Draft Handled review from EFET members LV MAdr Draft State of TraderScenarios added LV MAdr Draft State of TraderScenarios added LV MAdr Draft State of BrokerScenarios added LV MAdr Paragraph 4 describing states and colors Draft Handled internal review LV MAdr Draft Renamed scenario codes LV MAdr Draft Separation into 3 documents (Trader / Broker / LV MAdr Broker Trader) Draft Handled comment of meeting LV MAdr Draft Handled comment of meeting LV MAdr Draft Splitting of product / enduser tests LV MAdr Draft Handled comment of meeting LV Madr
4 4 CONTENTS page 1 Introduction General checks General actions of the Test Facility General remarks about the scenarios Test Scenarios Overview Connectivity testing Scenarios for testing ecm Standard compliance Broker Confirmation Matching Process (Broker) Normal behavior Broker Confirmation Matching Process (Broker) Business Rules Offences Broker Confirmation Matching Process (Broker) ecm Field Type Offences Broker Confirmation Matching Process (Broker) Commodities and markets... 36
5 5 1 INTRODUCTION EFET defined the electronic Confirmation and Matching (ecm) system to enable electronic exchange of Trade Confirmations and Match suggestions regarding these trades. Starting with version 3.0 of this standard the messaging layer below this standard is based on ebxml MS V2.0. With this requirement all implementations of the ecm should be interoperable, even when coming from different sources. In order to check if the standard is detailed enough to reach this interoperability and to check if implementers and users have followed the standard as it was meant, EFET asked KEMA to provide a test facility that is able to simulate the applicable participant roles covering the complete functionality of the ecm standard. This test facility must comprise various test scenarios, selected by EFET, which must be performed by the System Under Test with positive result in order to be certified. The System Under Test can have different functionality, performing the role of a Trader (Seller or Buyer) or Broker. Important is that the Test facility can only test the interfacing with the System Under Test. The test facility will be available on the public Internet, 24 hours per day 7 days per week This document describes the test scenarios that are to be performed to certify ecm version 3.2 compliant products and a market participant using these products. When the test scenarios are approved by EFET, KEMA will propose selections from the list of scenarios that must be performed in a vendor test and in a market participant test. Chapter two describes in general the checks that will be performed by the test facility. In chapter three the behavior of the test facility in case a message is received is described. Chapter four describes the coding of the test scenarios. Chapter five describes in details the test scenarios on the transport, semantic and syntax level. Paragraph two of this chapter describes the scenarios for the ebxml layer. These tests always have to be performed prior to all other scenarios. Paragraph three of chapter five describes the scenarios for the business document flow of the EFET ecm.
6 6 2 GENERAL CHECKS This section describes the general checks that will be performed by the test facility on all incoming messages, unless otherwise specified in a test scenario. Correct XML structure Correct ecm documents conform EFET ecm XML Schema s Correct ecm message according to ecm V3.2 The use of correct EICcodes Correct use of ebxml parameters (CPAID, Service, Action, ConversationID, MessageID, PartyID) Correct use of ebxml message encodings (signature formats, compression) Each party has one party address where they should send their messages. The messages should be according to the test scenario currently active. This involves checking of: Expected message expected changes in data expected references to previous messages
7 7 3 GENERAL ACTIONS OF THE TEST FACILITY This section describes the general actions that will be performed by the Test Facility when it has received a message, unless otherwise specified in a test scenario. Incoming Message The source of the incoming message is unknown (the party address is unknown) There is no scenario active for the sender of the message Message is not a valid ecm message while a scenario is active Message is a valid ecm message but not as expected by the scenario Message is valid and as expected by the scenario Action Message is discarded No error message is displayed on website Message is discarded No error message is displayed on website Scenario is aborted Error message is displayed on website Rejection is sent with code Validation error Scenario is aborted Error message is displayed on website No reply is sent Scenario proceeds to the next step (if there is a next step) Positive ACK is sent If required by the scenario, the next message is sent.
8 8 4 GENERAL REMARKS ABOUT THE SCENARIOS Each scenario has a code (for example S101010). The scheme for this code is as follows: Position 1: An S to indicate that the System Under Test (SUT) has to send the first message, a T when the Test Facility takes the initiative. Position 2: At the moment this number will always be 1. If the ecm Test Facility needs to be extended in the future with a new set of scenarios, this number can be increased for the new scenarios. Position 3+4: The ecm message Type: o 01: CNF (Trade Confirmation) o 02: REJ (Rejection) o 03: MSU (Match Suggestion) o 04: MSA (Match Suggestion Acceptance) o 05: MSR (Match Suggestion Rejection) o 06: CAN (Cancellation) o 07: ACK (Acknowledgement) o 08: BFI (Broker Fee Information) o 09: BMN (Broker Match Notification) o 10: BCN (Broker Confirmation) Position 5+6: The scenario number Position 7: Version number. When a scenario needs to be changed (due to an error or new insights) after the parties have started testing, this number can be used to show the scenario is a new version. Standard this number will be 0. The scenarios contain references to make it easier for the helpdesk to find the necessary specifications. All references are to the ecm standard documents. The steps of the scenarios are numbered in the following way for a SScenario: Steps that require action from the SUT (the system of the party performing the test): Odd step numbers Steps that require action from the Test Facility: Even step numbers This can result in skipping a stepnumber, when one of the systems needs to perform two steps after each other (for example, when the SUT needs to send an Acknowledgement and a Confirmation).
9 9 The steps of the scenarios are numbered in the following way for a TScenario: Steps that require action from the Test Facility: Odd step numbers Steps that require action from the SUT (the system of the party performing the test): Even step numbers This can result in skipping a stepnumber, when one of the systems needs to perform two steps after each other (for example, when the Test Facility needs to send an Acknowledgement and a Confirmation). We defined most scenarios as Sscenarios because we want to avoid the following: Test Facility sends a CNF for a Commodity / Market / TransactionType the SUT does not support. Test Facility uses locations not supported by the SUT These situations would never result in a MATCHING status. In some scenarios the data that must be send must be containing specific data fields. All specific data entries must be specified and agreed upon before the scenario s can be implemented. This is avoided when the SUT sends in what they support. The Test Facility can make offences or not on the received data. For the Test Facility it is in most scenario s not relevant which Commodity / Market / TransactionType and locations are being used. In paragraph there are defined special scenarios so the SUT can prove that they support multiple Commodity / Market / TransactionType combinations. Each SUT will be assigned a EICcode for the communication. The Test Facility will have a EICcode for: Trader Role Broker Role The Test Facility has to perform two roles in some scenario s to test the actual situation as close as possible.
10 10 The overall purpose of the testing is that the Test Facility must check that the incoming messages at the test facility side are according what is expected. In the process of entering them at the beginning of the cycle and the delivery at the test facility no changes may occur. Also the other way around: In the process of sending by the test facility and handling the received files at the SUTside changes may not occur either. Therefore for every scenario the configured input and changes must be prescribed to be able to verify this (automatically by the Test Facility or manually by the SUToperator). For example: SUT sends a CNF which contains the information from Trade A. The contents of this trade A must then be specified in the appendix so that there is no discussion about the contents and values that are required o The only difference with the appendix may be the EICcodes of the SUT (Sender / Receiver / Buyer / Seller) o Other key fields must stay the same o Informational fields may be changed because they should not influence the matching process SUT must send an amendment, containing the information from Trade B. Test Facility will send an amendment with the information from Trade B. In combination with the wish of the EFET members the state changes are specified in the scenarios, so checks can be done manually at the SUTside to verify that the states are according what is expected. The specified states are the states after handling the step. When errors are detected at the Test Facility side the scenario will fail, and the history will show the results of the steps. The states and generated files can then be verified to see where the problem occurred within the SUT. The Testing of BFI is a local matter and can not be tested with the Test Facility.
11 11 Below is an example of the manner how to prescribe specific trades used in scenarios and the state changes required for a good result. Overview of statuses for CNF and BCN during the scenario System Under Test (Buyer) Test Facility (Seller) Test Facility (Broker) Step CNF 1 BFI 1 CNF 2 BCN 1 1 Sending to CP Trade 2 Pending 3 Valid 4 Start Trade 5 Pending Colors indicate the following knowledge: Color in Step Column Explanation CNF 1 / BCN 1 of SUT CNF 2 / BCN 2 of SUT CNF 3 / BCN 3 of SUT CNF 1 of Test Facility CNF 2 of Test Facility CNF 3 of Test Facility Related to matching process Color in Step Column Explanation CNF 1 / BCN 1 of SUT CNF 2 / BCN 1 of SUT CNF 3 / BCN 1 of SUT BFI 1 of SUT CNF 1 of Test Facility CNF 2 of Test Facility CNF 3 of Test Facility BCN 1 of Test Facility BCN 2 of Test Facility BCN 3 of Test Facility
12 12 Special attention is required for the states not mentioned in the state diagrams of the EFET ecm standard. These states are: State Explanation Not Applicable The state of a trade confirmation document being received is rejected by the ebxml layer Rejected The situation is not in the state diagrams but this situation can occur when: document not according schema ebxml validation is turned on errors detected by the ebxml layer when validating document against schema The state of a trade confirmation document being received from counterparty and sent rejection document The situation is not in the state diagrams but this situation can occur when: errors not detected by the ebxml layer errors not detected by the schema The states specified in this document are the states seen in the SUT and not the states seen in the testsystem. Making the scenario s understandable is possible in this document by indicating what the other side is doing. Therefore two states are added: The state Sending to CP can only be seen in the local system, therefore this state is indicated as Start to differentiate the local and remote states. This involves CNF and BCN documents. The state Potential Match can only be seen in the local system, therefore this state is indicated as Potential to differentiate the local and remote states.
13 Testdata product testing Testdata for product testing will be generated by the Test Facility: Activation using a webinterface Generation of testfiles (XMLfiles) o Broker Confirmation documents o Cancellation documents Zipping of all testfiles into a zipfile Downloading the zipfile from the website After receiving the zipfile the testing party (SUT) needs to activate the scenario s and needs to send the required testfiles when required. The filenaming of the test data will contain clear references to the scenario s and the step within the scenario s so the testing party knows when to use which file. Only Trade Confirmation documents and Cancellation documents are part of the testdata, as all other documents must be created by the EFETbox of the SUT. When not all scenario s can be completed with success, the generation of test data must be repeated to retry the scenario s that failed. The generated data for already completed scenario s will also be regenerated, because all tests must succeed in one run without errors, within the certification. Besides for certification the testfacility can also be used for: Development (producttest) Learning (enduser test) Integration (enduser test after certification before taking new partners into operation) For these purposes it is allowed to have failed scenario s and then also testdata will be regenerated for already completed scenario s, being able to repeat them again. When registering on the website a login will be generated for: Certification Testmode (development, learning and integration) It will only be possible to test on one of the two accounts at every point in time. This will be handled by agreeing a certain time period for each type of test. Outside the time periods it will not be possible to use the test facility. Example of different time periods and different accounts: From till From till From till Development Account 1 Certification Account 2 Integration Account 1
14 14 5 TEST SCENARIOS 5.1 Overview Subject of the test Type of tests Used in References EFET extensions to EbXML messaging Prod. + EbXML MS 2.0 EbXML MS V2.0 Part. Test EFET ecm standard V3.2F draft Real World Business Business Document Flow Prod. + EFET ecm standard Normal behavior Part. Test V3.2F draft Normal behavior combined with offences Business Rules Prod. + EFET ecm standard Normal behavior Part. Test V3.2F draft Offences ECM Fields Prod. + EFET ecm standard Normal behavior Part. Test V3.2F draft Type errors not covered by schema ecm XML document exchange Syntax Prod. + Part. Test EFET ecm standard V3.2F draft
15 Connectivity testing The purpose of connectivity testing is that it will check if the communication between two systems is valid and makes it possible to continue testing all scenarios. These scenarios should verify that ebxml Messaging layer works and complies with the ecm Standard ebxml Profile and the ebxml Messaging Service Standard 2.0. Issues that must be working are: Valid ebxml messages Communication to the right URI Encryption and Decryption of the messages Compression and Decompression of the messages Look at the standard for the required settings. When problems are available with one of the mentioned issues they must be solved before the testing with the Test Facility can be continued. For all test scenarios the ecm Standard ebxml Profile and the ebxml Messaging Service Standard 2.0 requirements will be tested on the background as it will be stopping the progress during the test scenarios. When both systems have the pingpong functionality available, this can verify that the other side is reachable and that the configured URI s are valid. Preconditions: The SUT ebxml implementation is setup with one private/public key pair for its own usage SUT provides an external URL for ebxml Service Access by means of HTTP Look in the standard for the required settings for the ebxml profile mandated by ebxml MS 2.0 / EFET 3.2. The required settings will be tested by the EFET test facility. Connectivity Test 1: Test the pingpong functionality (when supported by at least one side) System Under Test Test Facility Activate Pingpong Activate Pingpong Checks performed Validate that pingpong works from Testfacility to System Under Test Validate that pingpong works from System Under Test to Testfacility Communication is configured correctly for: o Ebxml o Routers o Firewalls o DNZ
16 16 Scenario: Purpose: Test type: T Send a Trade Confirmation (CNF) To check the ebxml interoperability between the parties Product test and enduser test Step System Under Test State SUT Test Facility State TS 1 Send a CNF Start 2 Send an ACK Pending Pending 3 Send a CAN to cancel the CNF DocumentID and DocumentVersion of previous sent CNF (Step 1) 4 Send an ACK Cancelled Cancelled 6 Send a CNF Sending to CP 7 Pending Send an ACK Pending 8 Send a CAN to cancel the CNF DocumentID and DocumentVersion of previous sent CNF (Step 6) 9 Cancelled Send an ACK Cancelled Checks performed Validate ebxml message against XSD of ebxml Check if an Acknowledgement (for CNF) was received Check if an Acknowledgement (for CAN) was received EFET box functionality can be used in the communication Communication works both ways Overview of statuses for CNF during the scenario System Under Test Test Facility Step CNF 2 CNF 1 1 Start Trade 4A 2 Pending 3 4 Cancelled 6 Start Trade 2A 7 Pending 8 9 Cancelled
17 17 Scenario: Purpose: Test type: T Send a Trade Confirmation (CNF) with an error in ebxml DocumentID missing (structure not according the XML Schema) To check the ebxml validation against the XML Schema Product test and enduser test Step System Under Test State SUT Test Facility State TS 1 Send a CNF Start 2 Send an ebxml error with DocumentID missing. Not Applicable Not Applicable Note that the error to return is not defined by the ecmstandard. Checks performed Check if a XML Rejection was received Check if the correct rejection reason is returned Overview of statuses for CNF during the scenario System Under Test Test Facility Step CNF 1 1 Start Trade 24A 2 Not Applicable
18 18 Scenario: Purpose: Test type: T Send a Trade Confirmation (CNF) with an enumeration error in ebxml AgreementType is invalid (enumeration not valid according the XML Schema) To check the ebxml validation against the XML Schema Product test and enduser test Step System Under Test State SUT Test Facility State TS 1 Send a CNF Start 2 Send an ebxml error with DocumentID missing. Not Applicable Not Applicable Note that the error to return is not defined by the ecmstandard. Checks performed Check if an ebxml Rejection was received Check if the correct rejection reason is returned Overview of statuses for CNF during the scenario System Under Test Test Facility Step CNF 1 1 Start Trade 24A 2 Not Applicable
19 Scenarios for testing ecm Standard compliance These scenarios should show that the SUT handles and processes the ecm documents in conformance to the EFET ecm V3.2 standard Broker Confirmation Matching Process (Broker) Normal behavior Scenario: Purpose: Role: Test type: S49 Full Broker Confirmation Matching process with Preliminary Match (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Preliminary Match BCN, CNF and BFI 5 Send an ACK if the BMN is correct Preliminary Preliminary 6 Send a BMN Match (Final) BCN, CNF and BFI 7 Send an ACK if the BMN is correct
20 20 Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 21A 2 Pending 4 Pending 5 Preliminary 6 7
21 21 Scenario: Purpose: Role: Test type: S50 Full Broker Confirmation Matching process without Preliminary Match (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 21A 2 Pending 4 5
22 22 Scenario: Purpose: Role: Test type: S52 Full Broker Confirmation Matching process with Amendment after Preliminary Match (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Preliminary Match 5 Send an ACK if the BMN is correct Preliminary 7 Send a BCN Amendment Document complies with the Business Rules for BCN. DocumentID: Same as in step 1 DocumentVersion: Augmented from step 1 8 Amended + BCN (Step 1), CNF and BFI Pending Send an ACK if the BCN is correct 10 Send a BMN Reversal BCN (Step 1), CNF and BFI Preliminary Amended + Pending 11 Send an ACK if the BMN is correct Pending Pending 12 Send a BMN Preliminary Match 13 Send an ACK if the BMN is correct Preliminary BCN (Step 7), CNF and BFI Preliminary
23 23 Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 14 Send a BMN Match (Final) BCN (Step 7), CNF and BFI 15 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 BCN 2 CNF 1 1 Sending to CP Trade 21A 2 Pending 4 Pending 5 Preliminary 7 Sending to CP Trade 21A 8 Amended Pending Pending Amended Pending 12 Pending 13 Preliminary 14 15
24 24 Scenario: Purpose: Role: Test type: S53 Full Broker Confirmation Matching process with Cancellation after Preliminary Match (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Preliminary Match BCN (Step 1), CNF and BFI 5 Send an ACK if the BMN is correct Preliminary Preliminary 7 Send a Cancellation Contents DocumentID and DocumentVersion of BCN (Step 1) 8 Cancelled Send an ACK if the BCN is correct Cancelled 10 Send a BMN Reversal BCN (Step 1), CNF and BFI 11 Send an ACK if the BMN is correct Cancelled Cancelled
25 25 Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 21A 2 Pending 4 Pending 5 Preliminary 7 8 Cancelled Pending Cancelled Pending
26 26 Scenario: Purpose: Role: Test type: S56 Full Broker Confirmation Matching process with CNF Amendment after Preliminary Match (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. TotalVolume = Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Preliminary Match BCN (Step 1), CNF and BFI 5 Send an ACK if the BMN is correct Preliminary Preliminary 6 Send a BMN Reversal because of changed CNF BCN (Step 1), CNF and BFI 7 Send an ACK if the BMN is correct Pending Pending 9 Send a BCN to Trader Document complies with the Business Rules for BCN. DocumentID: Same as in Step 1 DocumentVersion: Augmented from Step 1 TotalVolume = Amended + Pending Send an ACK if the BCN is correct Amended + Pending
27 27 Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 12 Send a BMN Preliminary Match with changed CNF BCN (Step 9), CNF (DocumentVersion: Augmented from step 6) and BFI 13 Send an ACK if the BMN is correct Preliminary Preliminary 14 Send a BMN Match (Final) with changed CNF BCN (Step 9), CNF (Same DocumentVersion as in step 12) and BFI 15 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 BCN 2 CNF 1 CNF 2 1 Sending to CP Trade 21B 2 Pending 4 Pending 5 Preliminary Pending 7 Pending 9 Sending to CP Trade 21C 10 Amended Pending Pending 12 Amended Pending 13 Preliminary 14 15
28 Broker Confirmation Matching Process (Broker) Business Rules Offences Scenario: Purpose: Role: Test type: S57 Referenced BCN is never used (SUT = Broker) To verify the detection of an ecm Business Rule offence and checking that it does not disturb the matching process Test Facility acts as a Trader Product test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Preliminary Match 5 Send a REJ with EFET:ReferencedDocNotExists Pending BCN (Not referencing the BCN of Step 1), CNF and 6 Send a BMN Preliminary Match 7 Send an ACK if the BMN is correct Preliminary BFI BCN (Step 1), CNF and BFI 8 Send a BMN Match (Final) 9 Send a REJ with EFET:ReferencedDocNotExists Preliminary BCN (Step 1), CNF and BFI Referenced DocumentVersion BCN changed Pending Preliminary Preliminary
29 29 Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 10 Send a BMN Match (Final) BCN (Step 1), CNF and BFI 11 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 21A 2 Pending 4 Pending 5 Pending 6 Pending 7 Preliminary 8 9 Preliminary 10 11
30 30 Scenario: Purpose: Role: Test type: S62 Referenced BCN does not exist (SUT = Broker) To verify the detection of an ecm Business Rule offence and checking that it does not disturb the matching process Test Facility acts as a Trader Product test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Preliminary Match 5 Send an ACK if the BMN is correct Preliminary BCN (Step 1), CNF and BFI 6 Send a BMN Match (Final) 7 Send a REJ with EFET:ReferencedDocNotExists Preliminary BCN (Step 1), CNF and BFI Referenced DocumentVersion BCN changed 8 Send a BMN Match (Final) BCN (Step 1), CNF (Step 4) and BFI (Step 4) Preliminary Preliminary 9 Send an ACK if the BMN is correct
31 31 Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 21A 2 Pending Pending 4 5 Preliminary 6 Pending 7 Preliminary 8 9
32 32 Scenario: Purpose: Role: Test type: S63 State of BCN is invalid (SUT = Broker) To verify the detection of an ecm Business Rule offence and checking that it does not disturb the matching process Test Facility acts as a Trader Product test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Preliminary Match 5 Send an ACK if the BMN is correct Preliminary BCN (Step 1), CNF and BFI 6 Send a BMN Preliminary Match 7 Send a REJ with EFET:RefDocInvalidState Preliminary (again) BCN (Step 1), CNF and BFI 8 Send a BMN Match (Final) BCN (Step 1), CNF (Step 4) and BFI (Step 4) Preliminary Preliminary 9 Send an ACK if the BMN is correct
33 33 Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 21A 2 Pending Pending 4 5 Preliminary 6 Pending 7 Preliminary 8 9
34 Broker Confirmation Matching Process (Broker) ecm Field Type Offences This paragraph describes test scenario s, which cause ecm Field offences which will not be detected by the schema. The outcome of each scenario is still a match. This makes it possible to check that the offence is detected and does not disturb the matching process. Scenario: Purpose: Role: Test type: S64 ReceiverRole invalid (SUT = Broker) To verify the detection of an ecm Business Rule offence and checking that it does not disturb the matching process Test Facility acts as a Trader Product test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Preliminary Match BCN (Step 1), CNF and BFI ReceiverRole = Trader 5 Send a REJ with EFET:InvalidData Pending Pending 6 Send a BMN Preliminary Match 7 Send an ACK if the BMN is correct Preliminary BCN (Step 1), CNF and BFI ReceiverRole = Broker 8 Send a BMN Match (Final) BCN (Step 1), CNF (Step 6) and BFI (Step 6) Preliminary 9 Send an ACK if the BMN is correct
35 35 Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 21A 2 Pending Pending 4 5 Pending 6 Pending 7 Preliminary 8 9
36 Broker Confirmation Matching Process (Broker) Commodities and markets This paragraph describes test scenario s, which validate the different allowed commodities and markets. The outcome of each scenario is still a match. This makes it possible to check that the offence is detected and does not disturb the matching process. Testing is normally the combination of the following three aspects: Commodity Market Scenario This then becomes a three dimensional matrix describing all the test possibilities. We only make a selection of this matrix to limit the amount of tests. We assume that most parties will support the Commodities Gas and Power for the Markets UK, BE, DE and NL. From these 16 combinations we have chosen 8 of them to have a good representation of the reallife situations later on. Also EUA Trades are part of the tests.
37 37 Scenario: Purpose: Role: Test type: S65 Gas Commodity UK FOR (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = Gas Market = UK TransactionType = FOR 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31A 2 Pending Pending 4 5
38 38 Scenario: Purpose: Role: Test type: S66 Gas Commodity UK OPT (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = Gas Market = UK TransactionType = OPT 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31B 2 Pending Pending 4 5
39 39 Scenario: Purpose: Role: Test type: S67 Gas Commodity BE FOR (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = Gas Market = UK TransactionType = FOR 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31C 2 Pending Pending 4 5
40 40 Scenario: Purpose: Role: Test type: S68 Gas Commodity BE OPT (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = Gas Market = UK TransactionType = OPT 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31D 2 Pending Pending 4 5
41 41 Scenario: Purpose: Role: Test type: S69 Power Commodity UK FOR (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = Power Market = UK TransactionType = FOR 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31E 2 Pending Pending 4 5
42 42 Scenario: Purpose: Role: Test type: S70 Power Commodity UK OPT (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = Power Market = UK TransactionType = OPT 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31F 2 Pending Pending 4 5
43 43 Scenario: Purpose: Role: Test type: S71 Power Commodity NL FOR (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = Power Market = UK TransactionType = FOR 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31G 2 Pending Pending 4 5
44 44 Scenario: Purpose: Role: Test type: S72 Power Commodity NL OPT (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = Power Market = UK TransactionType = OPT 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31H 2 Pending Pending 4 5
45 45 Scenario: Purpose: Role: Test type: S113 EUA_Phase1 (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = EUA_Phase1 Market = <n/a> TransactionType = FOR 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31I 2 Pending Pending 4 5
46 46 Scenario: Purpose: Role: Test type: S114 EUA_Phase2 (SUT = Broker) To test the full document flow of the Confirmation Matching Process and if the documents comply with the Business Rules. Test Facility acts as a Trader Product test and enduser test Step System Under Test (Broker) State SUT Test Facility (Trader) State TS 1 Send a BCN to Trader Document complies with the Business Rules for BCN. Commodity = EUA_Phase2 Market = <n/a> TransactionType = FOR 2 Pending Send an ACK if the BCN is correct Pending 4 Send a BMN Match (Final) BCN, CNF and BFI 5 Send an ACK if the BMN is correct Overview of statuses for CNF and BCN during the scenario System Under Test (Broker) Test Facility (Trader) Step BCN 1 CNF 1 1 Sending to CP Trade 31J 2 Pending Pending 4 5
Easy Manage Helpdesk Guide version 5.4
Easy Manage Helpdesk Guide version 5.4 Restricted Rights Legend COPYRIGHT Copyright 2011 by EZManage B.V. All rights reserved. No part of this publication or software may be reproduced, transmitted, stored
Helpdesk manual. Version: 1.1
Version: 1.1 Date: 06-May-2014 Introduction Once a new system has been delivered, or an update has taken place, issues could occur, questions raised and new functionality needed. You can register these
Corporate Access File Transfer Service Description Version 1.0 01/05/2015
Corporate Access File Transfer Service Description Version 1.0 01/05/2015 This document describes the characteristics and usage of the Corporate Access File Transfer service, which is for transferring
SWIFT Certified Application Payments
SWIFT Certified Application Payments Technical validation Guide 2014 Version 1.1 April 2014 Legal notices Copyright SWIFT 2014. All rights reserved. You may copy this publication within your organisation.
HTTP State Management
HTTP State Management Candidate Version 1.1 27 Feb 2007 Open Mobile Alliance OMA-TS-HTTPSM-V1_1-20070227-C OMA-TS-HTTPSM-V1_1-20070227-C Page 2 (17) Use of this document is subject to all of the terms
SEPA Credit Transfer Customer-to-Bank Implementation Guidelines for the Netherlands
SEPA Credit Transfer Customer-to-Bank Implementation Guidelines for the Netherlands Disclaimer These guidelines may be subject to changes. Utmost care has been taken to ensure the information in this publication
TABLE OF CONTENTS INTRODUCTION USE CASES FOR CONVERSION BETWEEN DIRECT AND XDR DATAMOTION XDR IMPLEMENTATION GLOSSARY OF TERMS
TABLE OF CONTENTS INTRODUCTION USE CASES FOR CONVERSION BETWEEN DIRECT AND XDR Conversion from Direct SMTP+S/MIME Messages to XDR Conversion from XDR to SMTP+S/MIME Data Transmission between two EHRS that
Transaction Report System (TRS) Interface Test specification
2010-13:24:002010- Transaction Report System (TRS) Interface Owner Date Comments 2007-05-30 Initial Draft 2007-06-12 Updated Pre requisite 2007-07-10 General updates 2007-07-20 Added test case TR_4.10
Secure Envelope specification
Secure Envelope specification for Corporate Access File Transfer 2/13/2015 Version 1.0.3 This document defines how a file (e.g. a payment file) which will be sent to the bank is digitally signed by the
User Manual. CitiDirect \ CitiDirect EB - Citi Trade Portal. InfoTrade Phone No. 0 801 258 369 infotrade@citi.com
CitiDirect \ CitiDirect EB - Citi Trade Portal User Manual InfoTrade Phone No. 0 801 258 369 infotrade@citi.com CitiDirect HelpDesk Phone No. 0 801 343 978, +48 (22) 690 15 21 Monday Friday 8.00 17.00
Service Schedule for Business Email Lite powered by Microsoft Office 365
Service Schedule for Business Email Lite powered by Microsoft Office 365 1. SERVICE DESCRIPTION Service Overview 1.1 The Service is a hosted messaging service that delivers the capabilities of Microsoft
ELKHART COUNTY BOARD OF REALTORS AND MULTIPLE LISTING SERVICE OF ELKHART COUNTY INC. VIRTUAL OFFICE WEBSITE (VOW) LICENSE AGREEMENT
ELKHART COUNTY BOARD OF REALTORS AND MULTIPLE LISTING SERVICE OF ELKHART COUNTY INC. VIRTUAL OFFICE WEBSITE (VOW) LICENSE AGREEMENT This License Agreement (the Agreement) is made and entered into between
997 Functional Acknowledgment
997 Functional Acknowledgment Version: 1.0 Draft Author: Margie Stewart Publication: 06/10/2013 Notes: Table of Contents 997 Functional Acknowledgment.......................................................................................
nehta Commissioning Requirements for Secure Message Delivery Secure Messaging 19 December 2012 National E-Health Transition Authority
nehta Secure Messaging Commissioning Requirements for Secure Message Delivery 19 December 2012 National E-Health Transition Authority National E-Health Transition Authority Ltd Level 25 56 Pitt Street
Transglobal Secure Collaboration Program Secure E-mail v.1 Gateway Design Principles
Transglobal Secure Collaboration Program Secure E-mail v.1 Gateway Design Principles Prepared by: CP Secure E-mail v.1 Project Team Version: 2.0.2 Date: 16 July 2012 Page i Copyright 2012 Transglobal Secure
OSCI Transport 1.2 Specification Status: FINAL OSCI Leitstelle
OSCI Transport 1.2 Specification Status: FINAL OSCI Leitstelle Bremen/Germany, June 2002 OSCI Transport 1.2 2 The following companies and institutions have been involved in the creation of this specification:
GTR OTC Lite User Guide
DTCC GTR OTC Lite User Guide April 2014 The European Securities and Markets Authority (the "ESMA") have not approved or otherwise sanctioned the information contained in this document. The EMIR business
Oracle Procurement. Punchout and Transparent Punchout Guide for Oracle iprocurement and Oracle Exchange Release 11i. Part No.
Oracle Procurement Punchout and Transparent Punchout Guide for Oracle iprocurement and Oracle Exchange Release 11i Part No. A92190-03 April 2003 Oracle Procurement Punchout and Transparent Punchout Guide
Foreign Account Tax Compliance Act (FATCA) Foreign Account Tax Compliance Act (FATCA) FATCA Reports
Foreign Account Tax Compliance Act (FATCA) August 2015 Foreign Account Tax Compliance Act (FATCA) FATCA Reports International Compliance Management Model (ICMM) Notifications User Guide FATCA Reports Foreign
StreamServe Persuasion SP4 Encryption and Authentication
StreamServe Persuasion SP4 Encryption and Authentication User Guide Rev A StreamServe Persuasion SP4 Encryption and Authentication User Guide Rev A 2001-2009 STREAMSERVE, INC. ALL RIGHTS RESERVED United
Secure Data Transfer
Secure Data Transfer INSTRUCTIONS 3 Options to SECURELY TRANSMIT DATA 1. FTP 2. WinZip 3. Password Protection Version 2.0 Page 1 Table of Contents Acronyms & Abbreviations...1 Option 1: File Transfer Protocol
Service Schedule for BT Business Lite Web Hosting and Business Email Lite powered by Microsoft Office 365
1. SERVICE DESCRIPTION 1.1 The Service enables the Customer to: set up a web site(s); create a sub-domain name associated with the web site; create email addresses. 1.2 The email element of the Service
State of Nevada Department of Health and Human Services (DHHS) Division of Health Care Financing and Policy (DHCFP)
Hewlett Packard Enterprise for HIPAA Compliant Electronic Transactions Nevada Medicaid Management Information System (NV MMIS) State of Nevada Department of Health and Human Services (DHHS) Division of
MRMLS LISTING INFORMATION LICENSE AGREEMENT
MRMLS LISTING INFORMATION LICENSE AGREEMENT (MRMLS data feed to Affiliated VOW Partner) This Listing Information License Agreement (the Agreement ) is made and entered into by and between MULTI REGIONAL
Centers for Disease Control and Prevention, Public Health Information Network Messaging System (PHINMS)
1 ebxml Case Study 2 3 4 5 Centers for Disease Control and Prevention, Public Health Information Network Messaging System (PHINMS) 4 October 2003 6 7 8 9 10 11 12 13 14 15 16 17 Document identifier: (Word)
StreamServe Persuasion SP5 Encryption and Authentication
StreamServe Persuasion SP5 Encryption and Authentication User Guide Rev A StreamServe Persuasion SP5 Encryption and Authentication User Guide Rev A 2001-2010 STREAMSERVE, INC. ALL RIGHTS RESERVED United
Realex Payments Integration Guide - Ecommerce Remote Integration. Version: v1.1
Realex Payments Integration Guide - Ecommerce Remote Integration Version: v1.1 Document Information Document Name: Realex Payments Integration Guide Ecommerce Remote Integration Document Version: 1.1 Release
Presence SIMPLE Architecture
Presence SIMPLE Architecture Approved Version 1.1 27 Jun 2008 Open Mobile Alliance OMA-AD-Presence_SIMPLE-V1_1-20080627-A OMA-AD-Presence_SIMPLE-V1_1-20080627-A Page 2 (21) Use of this document is subject
Realisation Agreement
PAGE 1 of 11 Disclaimer: the content of this draft is disclosed for information and discussion purposes only. In no way does this draft constitute rights for (potential) connected parties, or bind TenneT
API Integration Payment21 Recurring Billing
API Integration Payment21 Recurring Billing The purpose of this document is to describe the requirements, usage, implementation and purpose of the Payment21 Application Programming Interface (API). The
Dell Unified Communications Command Suite - Diagnostics 8.0. Data Recorder User Guide
Dell Unified Communications Command Suite - Diagnostics 8.0 2014 Dell Inc. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide
REAL ESTATE, FIRM CONTRACT. Access to IDX Data Feed AGREEMENT RECITALS DEFINITIONS
REAL ESTATE, FIRM CONTRACT Access to IDX Data Feed Note: This form is a legally binding contract between you and MLS. Simultaneously or prior to submitting this form/contract, you must become an IDX Broker.
PHIN MS Detailed Security Design
The Public Health Information Network Messaging System (PHINMS) sends and receives sensitive data over the internet to the public health information systems using Electronic Business Extensible Markup
ASF Commission Affacturage 02/08/2011 BUSINESS JUSTIFICATION
BUSINESS JUSTIFICATION FOR THE DEVELOPMENT OF NEW ISO 20022 FINANCIAL REPOSITORY ITEMS A. Name of the request: Messages set for factoring services B. Submitting organisation: Association française des
Ruby VASC Instructor Guide
Ruby VASC Instructor Guide Client Services, Training 300 S. Park Place Blvd. Suite 100 727.953.4000 Main Reception 727.953.4270 Training Administration 727.953.4001 - Fax i_trngregistration@smokestack.verifone.com
redcoal EmailSMS for MS Outlook and Lotus Notes
redcoal EmailSMS for MS Outlook and Lotus Notes Technical Support: support@redcoal.com Or visit http://www.redcoal.com/ All Documents prepared or furnished by redcoal Pty Ltd remains the property of redcoal
VIRTUAL OFFICE WEBSITE LICENSE AGREEMENT
Florida Keys Multiple Listing Service, Inc. VIRTUAL OFFICE WEBSITE LICENSE AGREEMENT Florida Keys MLS, Inc. 92410 Overseas Hwy, Ste. 11 Tavernier FL 33070 305-852-92940 305-852-0716 (fax) www.flexmls.com
MEFFGate Trading FIX INTERFACE SPECIFICATIONS
MEFFGate Trading FIX INTERFACE SPECIFICATIONS Version T1.2 30 July 2012 The information contained in this document is subject to modification without notice. Unless otherwise noted, the companies, names
Replacements TECHNICAL REFERENCE. DTCCSOLUTIONS Dec 2009. Copyright 2009 Depository Trust Clearing Corporation. All Rights Reserved.
TECHNICAL REFERENCE Replacements Page 1 Table of Contents Table of Contents 1 Overview... 3 1.1 Replacements Features... 3 2 Roles and Responsibilities... 4 2.1 Sender (Receiving Carrier)... 4 2.2 Recipient
Metalogix Replicator. Quick Start Guide. Publication Date: May 14, 2015
Metalogix Replicator Quick Start Guide Publication Date: May 14, 2015 Copyright Metalogix International GmbH, 2002-2015. All Rights Reserved. This software is protected by copyright law and international
Integrated SSL Scanning
Software Version 9.0 Copyright Copyright 1996-2008. Finjan Software Inc. and its affiliates and subsidiaries ( Finjan ). All rights reserved. All text and figures included in this publication are the exclusive
Business Requirements for Measure for Billing
Business Requirements for Measure for Billing Status: approved Version: 2.0 Revision: A Date: August, 2013 ebix Business Requirements for Measure for Billing 2 C O N T E N T A. About this document... 4
Aastra BluStar TM 8000i Desktop Media Phone / Aastra BluStar TM for Conference Room. 4.3.0 SIP Call Server Release Notes. Draft
Aastra BluStar TM 8000i Desktop Media Phone / Aastra BluStar TM for Conference Room 4.3.0 SIP Call Server Release Notes 1 41-001468-03 REVRC2 09.2013 Draft Content SIP Call Server Release Notes 4.3.0.......................................
OFFICIAL SECURITY CHARACTERISTIC MOBILE DEVICE MANAGEMENT
SECURITY CHARACTERISTIC MOBILE DEVICE MANAGEMENT Version 1.3 Crown Copyright 2015 All Rights Reserved 49358431 Page 1 of 12 About this document This document describes the features, testing and deployment
Copy Tool For Dynamics CRM 2013
Copy Tool For Dynamics CRM 2013 Page 1 of 15 Copy Tool 2013 Copyright Warranty disclaimer Limitation of liability License agreement Copyright 2013 Dynamics Professional Solutions. All rights reserved.
Danske Bank Group Certificate Policy
Document history Version Date Remarks 1.0 19-05-2011 finalized 1.01 15-11-2012 URL updated after web page restructuring. 2 Table of Contents 1. Introduction... 4 2. Policy administration... 4 2.1 Overview...
IBM Aspera Add-in for Microsoft Outlook 1.3.2
IBM Aspera Add-in for Microsoft Outlook 1.3.2 Windows: 7, 8 Revision: 1.3.2.100253 Generated: 02/12/2015 10:58 Contents 2 Contents Introduction... 3 System Requirements... 5 Setting Up... 6 Account Credentials...6
Common definitions and specifications for OMA REST interfaces
Common definitions and specifications for OMA REST interfaces Candidate Version 1.0 11 Jan 2011 Open Mobile Alliance OMA-TS-REST_Common-V1_0-20110111-C OMA-TS-REST_Common-V1_0-20110111-C Page 2 (20) Use
Structured Data Capture (SDC) Trial Implementation
Integrating the Healthcare Enterprise 5 IHE Quality, Research, and Public Health Technical Framework Supplement 10 Structured Data Capture (SDC) 15 Trial Implementation 20 Date: October 27, 2015 Author:
Oracle iprocurement and Oracle Exchange
Oracle iprocurement and Oracle Exchange Punchout Guide Release 11i September, 2002 Part No. A92190-02 Oracle iprocurement and Oracle Exchange Punchout Guide, Release 11i Part No. A92190-02 Copyright 2001,
CyberSource PayPal Services Implementation Guide
CyberSource PayPal Services Implementation Guide Simple Order API SCMP API September 2015 CyberSource Corporation HQ P.O. Box 8999 San Francisco, CA 94128-8999 Phone: 800-530-9095 CyberSource Contact Information
SERVICE LEVEL AGREEMENT. Open Source Support Desk B.V. Hargray, Inc.
SERVICE LEVEL AGREEMENT between Open Source Support Desk B.V. and Hargray, Inc. Copyright 2011 by Open Source Support Desk B.V. All rights reserved. This document is protected by copyright. No part of
Standard Registry Development and Publication Process
Document number: DSP4006 Date: 2007-12-12 Version: 1.1.0 Standard Registry Development and Publication Process Document type: Specification Document status: Informational Document language: E Copyright
StreamServe Encryption and Authentication
StreamServe Encryption and Authentication User Guide 4.1.2 SP2 Rev A StreamServe Encryption and Authentication User Guide 4.1.2 SP2 Rev A 2007 StreamServe, Inc. StreamServe is a trademark of StreamServe,
Federation Operator Practice (FOP): Metadata Registration Practice Statement
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 Preface to the Template Document Federation
Part 4. Share Capital
Part 4 Division 1 Section 134 A3599 Part 4 Share Capital Division 1 Nature of Shares 134. Nature and transferability of shares (1) A share or other interest of a member in a company is personal property.
Authorize.Net Mobile Application
Authorize.Net Mobile Application ios User Guide October 2015 Authorize.Net Developer Support http://developer.authorize.net Authorize.Net LLC 082007 Ver.2.0 Authorize.Net LLC ( Authorize.Net ) has made
End-User Reference Guide
Guide Websense Advanced Email Encryption v7.6 Websense Advanced Email Encryption Copyright 1996-2011 Websense, Inc. All rights reserved. This document contains proprietary and confidential information
End-User Reference Guide
Guide Websense Advanced Email Encryption v7.6 Contents Receiving secure email....................................... 1 How do I open a secure message?............................ 1 How do I register for
Authorize.Net Mobile Application
Authorize.Net Mobile Application Android User Guide October 2015 Authorize.Net Developer Support http://developer.authorize.net Authorize.Net LLC 082007 Ver.2.0 Authorize.Net LLC ( Authorize.Net ) has
AcroTime Workforce Management Time & Labor Human Resources Payroll Service Terms and Conditions
Terms of Agreement Acroprint Time Recorder Company (referred as Acroprint ) grants you access to use its web hosted time and attendance solution AcroTime (referred as Service ), subject to your agreement
End-User Reference Guide
Guide Websense Advanced Email Encryption v7.x Websense Advanced Email Encryption Copyright 1996-2014 Websense, Inc. All rights reserved. This document contains proprietary and confidential information
Getting Started with Apple Pay on the Authorize.Net Platform
Title Page Getting Started with Apple Pay on the Authorize.Net Platform September 2014 Authorize.Net Developer Support http://developer.authorize.net Authorize.Net LLC 082007 Ver.2.0 Authorize.Net LLC
Interface Certification for a RMA Interface
Title Page Interface Certification for a RMA Interface STAR/RMA Conformance Statement Table of Contents Title Page... 1 1 General Information... 3 1.1 Supplier... 3 1.2 Product Information... 3 1.3 Operational
TechSPEC Database Installation Guide. Version 1.0
TechSPEC Database Installation Guide Version 1.0 Special Notices TechSPEC Database Installation Guide ii Tech Data Corporation TechSPEC Database Installation Guide Special Notices Special Notices Information
ELECTRONIC DATA INTERCHANGE (EDI) TRADING PARTNER AGREEMENT THIS ELECTRONIC DATA INTERCHANGE TRADING PARTNER AGREEMENT
ELECTRONIC DATA INTERCHANGE (EDI) TRADING PARTNER AGREEMENT THIS ELECTRONIC DATA INTERCHANGE TRADING PARTNER AGREEMENT (the "Agreement") is made as of, 2, by and between UGI Utilities, Inc. Gas Division
EASEE-gas. Common Business Practice
CBP 2014-001/01 1 EASEE-gas European Association for the Streamlining of Energy Exchange - gas Common Business Practice Number: 2014-001/01 Subject: Harmonisation of the Nomination and Matching Process
DICOM Conformance Statement FORUM
DICOM Conformance Statement FORUM Version 3.1 Carl Zeiss Meditec AG Goeschwitzerstraße 51-52 07745 Jena Germany www.meditec.zeiss.com Document: DICOM Conformance Statement_FORUM_3.1.doc Page 1 of 25 1
WEF PUBLISHING SERVICE INSTITUTIONAL USER LICENSE
WEF PUBLISHING SERVICE INSTITUTIONAL USER LICENSE 1. BY SIGNING THIS LICENSE ( LICENSE ), the institution identified below ( Subscriber or you ) agrees to the terms and conditions set forth in this License.
Getronics Certification Certificate of Authentic Trustworthy
Getronics Version 3.0 Effective Date: 15 october, 2008 Getronics Nederland B.V. Fauststraat 1 P.O. Box 9105 7300 HN Apeldoorn The Netherlands Phone: +31 (0)20 570 4511 http://www.pki.getronicspinkroccade.nl
IPSecuritas 3.x. Configuration Instructions. Collax Business Server. for
IPSecuritas 3.x Configuration Instructions for Lobotomo Software 27. juillet 2010 Legal Disclaimer Contents Lobotomo Software (subsequently called "Author") reserves the right not to be responsible for
Cisco Application Networking for BEA WebLogic
Cisco Application Networking for BEA WebLogic Faster Downloads and Site Navigation, Less Bandwidth and Server Processing, and Greater Availability for Global Deployments What You Will Learn To address
Little League International
Little League International User Guide for Vendors November 2013 CONFIDENTIAL & PROPRIETARY The recipient of this material (hereinafter "the Material") acknowledges that it contains confidential and proprietary
Equens Certificate Policy
Equens Certificate Policy WebServices and Connectivity Final H.C. van der Wijck 11 March 2015 Classification: Open Version 3.0 Version history Version no. Version date Status Edited by Most important edit(s)
Cisco Application Networking for IBM WebSphere
Cisco Application Networking for IBM WebSphere Faster Downloads and Site Navigation, Less Bandwidth and Server Processing, and Greater Availability for Global Deployments What You Will Learn To address
Sentinel EMS v7.1 Web Services Guide
Sentinel EMS v7.1 Web Services Guide ii Sentinel EMS Web Services Guide Document Revision History Part Number 007-011157-001, Revision E. Software versions 7.1 and later. Revision Action/Change Date A
XML Document Management Architecture
XML Document Management Architecture Candidate Version 2.0 02 Dec 2010 Open Mobile Alliance OMA-AD-XDM-V2_0-20101202-C OMA-AD-XDM-V2_0-20101202-C Page 2 (30) Use of this document is subject to all of the
Battery Program Management Document
Battery Program Management Document Revision 5.8 May 2014 CTIA Certification Program 1400 16 th Street, NW, Suite 600 Washington, DC 20036 e-mail: certification@ctia.org Telephone: 1.202.785.0081 www.ctia.org/certification
CA Nimsoft Unified Management Portal
CA Nimsoft Unified Management Portal HTTPS Implementation Guide 7.6 Document Revision History Document Version Date Changes 1.0 June 2014 Initial version for UMP 7.6. CA Nimsoft Monitor Copyright Notice
Collaboration Protocol Agreement Guide. Public Health Information Network Messaging System (PHINMS)
Collaboration Protocol Agreement Guide Public Health Information Network Messaging System (PHINMS) Version: 1.0.0 Prepared by: U.S. Department of Health & Human Services Date: April 15, 2008 EXECUTIVE
PI Cloud Connect Overview
PI Cloud Connect Overview Version 1.0.8 Content Product Overview... 3 Sharing data with other corporations... 3 Sharing data within your company... 4 Architecture Overview... 5 PI Cloud Connect and PI
JiveX Enterprise PACS Solutions. JiveX HL7 Gateway Conformance Statement - HL7. Version: 4.7.1 As of 2015-05-20
JiveX Enterprise PACS Solutions JiveX HL7 Gateway Conformance Statement - HL7 Version: 4.7.1 As of 2015-05-20 VISUS Technology Transfer GmbH Universitätsstr. 136 D-44799 Bochum Germany Phone: +49 (0) 234
SOFTWARE LICENSE LIMITED WARRANTY
CYBEROAM INSTALLATION GUIDE VERSION: 6..0..0..0 IMPORTANT NOTICE Elitecore has supplied this Information believing it to be accurate and reliable at the time of printing, but is presented without warranty
Connection and Transmission Agreement
PAGE 1 of 13 Disclaimer: the content of this draft is disclosed for information and discussion purposes only. In no way does this draft constitute rights for (potential) connected parties, or bind TenneT
Conference Bridge User Guide P/N 0893416 Rev 1, September 2006 Printed in U.S.A. 5.99
Empowered by Innovation Technical Support Web Site: http://ws1.necii.com (registration is required) Conference Bridge User Guide P/N 0893416 Rev 1, September 2006 Printed in U.S.A. 5.99 This manual has
PayPal Express Checkout Services
Title Page PayPal Express Checkout s Using the Simple Order API January 2016 CyberSource Corporation HQ P.O. Box 8999 San Francisco, CA 94128-8999 Phone: 800-530-9095 CyberSource Contact Information For
Signature, Seal and Delivery of Electronic Documents
: October 2009* Signature, Seal and Delivery of Electronic Documents ------------------------------------------------------------------------------- 1.0 Introduction 1.1 This bulletin has been approved
END USER LICENSE AGREEMENT ( EULA )
END USER LICENSE AGREEMENT ( EULA ) PLEASE READ CAREFULLY THIS EULA IS A LEGAL AGREEMENT BETWEEN YOU, EITHER AS AN INDIVIDUAL, COMPANY OR OTHER LEGAL ENTITY (IN ANY CAPACITY REFERRED TO HEREIN AS END USER,
Message Containers and API Framework
Message Containers and API Framework Notices Copyright 2009-2010 Motion Picture Laboratories, Inc. This work is licensed under the Creative Commons Attribution-No Derivative Works 3.0 United States License.
Leads may be resubmitted within 4 months of the leads license renewal date.
1. LEAD GENERATION SERVICES (a) IBP agrees to collect and provide School with Leads as further specified herein and as described in the Lead Payment Schedule as may be executed by the parties from time
Stock Broker System Audit Framework. Audit Process
Stock Broker System Audit Framework Audit Process 1. System Audit of stock brokers should be conducted with the following periodicity a. Annual system audit is prescribed for stock brokers who satisfy
System to System Interface Guide
System to System Interface Guide Overview What does this guide cover? This guide describes the interface definition to firms intending to submit their TRS Product Sales Data (PSD) or Securities Trades
ONVIF TM. ONVIF Specification Version 2.4 Release Notes. ONVIF www.onvif.org info@onvif.org
ONVIF TM ONVIF Specification Version 2.4 Release Notes ONVIF www.onvif.org info@onvif.org 2008-2013 by ONVIF TM All rights reserved. Recipients of this document may copy, distribute, publish, or display
New York State Federal/State Employment Tax (FSET) Handbook for Software Developers
Publication 120 (08/13) New York State Federal/State Employment Tax (FSET) Handbook for Software Developers The information presented is current as of this publication's print date. Visit our Web site
Clinical Mapping (CMAP) Draft for Public Comment
Integrating the Healthcare Enterprise 5 IHE Patient Care Coordination Technical Framework Supplement 10 Clinical Mapping (CMAP) 15 Draft for Public Comment 20 Date: June 1, 2015 Author: PCC Technical Committee
EFETnet Software System Requirements
EFETnet Software System Requirements Version 6 Dated 2015-01-01 Ponton GmbH Page 1 of 7 Change Log Revision Date Mark Changes 1 2004-12-15 TZ MH Original Schedule to EFETnet Maintenance & Support Contract
JetAdvice Manager Data Collector v. 2.1. Date: 2014-06-30
JetAdvice Manager Data Collector v. 2.1 Date: 2014-06-30 NOTE The information contained in this document is subject to change without notice. EuroForm makes no warranty of any kind with regard to this
Building a protocol validator for Business to Business Communications. Abstract
Building a protocol validator for Business to Business Communications Rudi van Drunen, Competa IT B.V. (r.van.drunen@competa.com) Rix Groenboom, Parasoft Netherlands (rix.groenboom@parasoft.nl) Abstract
[MS-SSP]: Intellectual Property Rights Notice for Open Specifications Documentation
![[MS-SSP]: Intellectual Property Rights Notice for Open Specifications Documentation](/thumbs/32/15506703.jpg "[MS-SSP]: Intellectual Property Rights Notice for Open Specifications Documentation")
[MS-SSP]: Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open Specifications documentation for protocols, file formats, languages,
Structured Data Capture (SDC) Draft for Public Comment
Integrating the Healthcare Enterprise 5 IHE Quality, Research, and Public Health Technical Framework Supplement 10 Structured Data Capture (SDC) 15 Draft for Public Comment 20 Date: June 6, 2014 Author: