external.schemas.hr-xml-2007.CPO.ApplicationAcknowledgement.xsd Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of phive-rules-setu Show documentation
Show all versions of phive-rules-setu Show documentation
SETU Standards validation rules for phive
"Copyright The HR-XML Consortium. All Rights Reserved. http://www.hr-xml.org"
Name: AcknowledgeTypes.xsd
Status: Recommendation
Date this version: 2007-04-15
Purpose: Defines the Acknowledge schema
Author(s): Paul Kiel, Dan Diman, Kim Bartkus
Documentation: ApplicationAcknowledgement.doc
Terms of license can be found in license.txt.
2005-10-26: Changed MessageIdType from an enumerated list to a simple string. Made UniquePayloadTrackingId repeatable. Review by the Technical Steering Committee recommended this. Backwardly compatible.
2005-11-08: Changed EntityNoException from fixed=true to a single enumeration. It is believed that this would be better supported by code generators. No content model changes.
This is an ID (or code) used by the organization generating the acknowledgement to identify the specific exception.
How severe the exception is. Fatal means system processed nothing. Warning means system processed something, but perhaps incompletely. Information means system processed everything, but a problem *may* occur that needs notification.
Fatal means system processed nothing.
Warning means system processed something, but perhaps incompletely.
Information means system processed everything, but a problem *may* occur that needs notification.
The exception content message.
The leve at which processing stops (within the entity). If fatal severity, this will match the EntitySchemaXPath. If a warning severity, then this will be the point at which processing stops within entity.
The offending element(s) or attributes (inside the scope of ExceptionScopeSchemaXPath, which in turn is in the scope of the EntityDisposition.
Indicates who is responsibile for correcting the exception.
Additional information (in a name-value pair format).
XML fragment beginning with the element pointed to by the EntityInstanceXPath above.
Business level exceptions regarding the specified entity. This would not include enveloping or xml related exceptions.
Should the detail be optional? Or should this be a choice between the element as it is now and a "no-op" element that indicates total success of the transaction.
Dispostion for a single entity. Repetable for batched entities. For example, representing a Subscriber in Enrollment.
The identifier for the component disposition, for example SubscriberId
The Entity disposition name,. Example is "Subscriber".
This will define the "root" level at which the exception applies by reference to the schema. This is an XPath not for the XML payload instance, but the XML document that is the schema itself.
XPath to the entity in the payload. This is the full XPath and not simply pointing to the axis in general. For example in Enrollment, this value would be an XPath to the Subscriber element (including the occurrence of the Subscriber in the instance - such as Enrollment/Organization/Subscriber[position()=2]).
Entities successfully accepted in the payload transaction.
This is the main resuable that can be incorporated into SOAP fault scenario.!!!!
An identifer passed back for referencing the transation. For example, an order number or confirmation code.
The message identifier of the enrollment transaction for which application acknowledgement is being returned. Matches the transport layer id.
The sender in a trading partnership agreeing to use the enrollment acknowledgement will provide this value in the attribute of the same name on the "Enrollment" element; the value will be repeated in this elemnt to produce an acknowledgement of a specific enrollment payload. Matches the Enrollment Id.
The date and time at which the message containing the payload here acknowledged was received.
The date and time at which a particular processing action was performed on the payload. The description attribute will contain text meaningful to both parties in the exchange. For example, an acknolwegment sender could provide date/times such as "Medical Coverages Processed" or "Claims Ready". Value applies to non-exception cases.
The date and time at which this acknowledgement was created. It is recommended to use the time at which the acknowledgement payload was completed.
A URI indicating where the schema used to create the enrolment payload being acknowledged can be found.
An XPath to the entity level in the xml instance. It does not indicate which occurrence of the entity, only the axis. For example, it may be Enrollment/Organization/Subscriber - not indicating which Subscriber occurrence. The instance is located by ReceivedPayloadSchemaURI.
The number of items referreed to in the EntitySchemaXPath element.
A non-standard or shorter name for the entities identified by the EntityXPath (e.g. "Families with Medical Coverage" or "Life Insurance Coverages with Total Volume Over 2 million dollars".