Attribute |
Public completeDescription
|
Details:
Alias: |
|
Initial: |
|
Stereotype: |
|
Ordered: |
|
Range: |
|
Transient: |
False |
Derived: |
False |
IsID: |
False |
Notes:
|
The processes in question cover the transmission of initial information, acknowledgements the identification of problems and concluding replies. However, in many instances there is lapse of time between an initial transmission and its conclusion. During this time the initiator of the process is unaware of the status of his situation. For example in the case of the scheduling process matching information must be received in order to conclude the transaction and a time limit is imposed on its successful conclusion. The initiator may be able to expedite the transmission of the matching information if he was aware that it had not yet been received.<br/><br/>In other cases it may be that a participating party would like to have a global overview of his situation at a given point in time. Generally such status information may be offered as a service via a web access. However in some circumstances this would require that the market participant to poll the web site of each of his counter parties, making it difficult and time consuming for him to establish his overall position. In these circumstances it is felt useful to provide a harmonized requesting mechanism that will enable a market participant to make an electronic request for information by a means other than the web. The recipient may then acknowledge the request with the transmission of the requested information providing he has the capacity to do so. The nature of the information that is sent in reply to a request is dependent on the context in which the request is made. It is through bilateral agreement that such a service is provided. The agreement will also define the structure of the answering information flow.<br/>It is during this phase where a status request use case may be applied. This process will enable the initiator to receive the status of his transaction prior to its termination or the status of his overall situation. This will eventually enable him to react and expedite missing information prior to a transactions conclusion or carry out other actions to actualize his situation.<br/>
|
|
Public scope
|
Details:
Alias: |
|
Initial: |
|
Stereotype: |
|
Ordered: |
|
Range: |
|
Transient: |
False |
Derived: |
False |
IsID: |
False |
Notes:
|
Based on the European style market profile (IEC 62325-351), this part of IEC 62325-451 specifies a package for the Status Request business process and the associated document contextual model, assembly model and XML schema for use within European style markets. <br/>The objective of the problem statement process is to provide a means of informing a party that a document could not be issued by the expected time and thus will be delayed (the approval of this delay depends upon the rules that have been established between the parties) and an automated support in the case where an escalation procedure has to be put into place when an expected event does not occur or a critical situation has to be resolved. For the status request process, the objective is to facilitate to the market participant the establishment of his overall position with an harmonized requesting mechanism, enabling a market participant to make an electronic request for information to his counterparties.<br/>
|
|