Introduction[1] The Confirmation element is the intended root element of the schema. The confirmation mirrors the elements in a filing, except that a confirmation also includes Confirmation:Number, Confirmation:Date, Confirmation:Time, Confirmation:FilingStatus and Confirmation:Error. Rules for Mirroring Filing XML in Confirmation XML[2] Elements in the confirmation mirror elements in a filing based on the assumption that filing information may change as the Filing XML travels downstream from a filing application to the court. In case the information changes, or even if it does not, the confirmation serves as a receipt and notice of the information ultimately accepted by the court. There is a corresponding element in a confirmation for every element in a filing so that changed information can be communicated to the filing application. For example, the filing application may include an incorrect or incomplete value for a case category. The clerk of court or the EFM itself may add or change the case category value. If such a change is made, the application creating the confirmation must include the changed value in the Confirmation XML element that corresponds to the Filing XML element that included the original value. The Confirmation XML can then be returned to the filing application as a receipt and record of the information accepted by the court. [3] If values sent in Filing XML are changed, then a receiving application must return the changed values in Confirmation XML. On the other hand, if values sent in Filing XML are not changed, then a receiving application is not required to mirror all elements and return them in Confirmation XML; however, the receiving application may do so. [4] The following elements, which are required in Filing XML, are optional in Confirmation XML: Confirmation:Case, Confirmation:CourtDetails, Confirmation:Filers, and Confirmation:LeadDocument. Notwithstanding the rule in the paragraph above, these elements should be included in a confirmation, if the information exists. The elements are optional to accommodate situations where the information does not exist, such as when an error occurs. [5] There are a number of data elements that may be optionally included in Filing XML, such as Case:Category. Although it is a matter of policy, courts are encouraged not to reject filings if optional information is absent or incorrect. If the court adds or corrects this information, clerk review or EFM applications must send the added or corrected information back to the filing application in asynchronous Confirmation XML. Dates and Times in Filing XML and Confirmation XML[6] The following table summarizes dates and times in Filing XML and Header XML as those dates and times relate to Confirmation XML. Elements | Filing | Confirmation Synchronous (Received) | Confirmation Synchronous (Error) | Confirmation Asynchronous (Accepted) | Confirmation Asynchronous (Rejected) |
---|
Header:Date/Time | Moment of generation | Moment of generation | Moment of generation | Moment of generation | Moment of generation | Filing:Date/Time | Filer's assertion of when filed | N/A | N/A | N/A | N/A | Confirmation:Date/Time | N/A | Moment of generation | Moment of generation | Moment of generation | Moment of generation | Confirmation:FilingDate and Confirmation:FilingTime | N/A | Mirror Filer's assertion of when filed | If available, mirror Filer's assertion of when filed. Otherwise, moment of generation | Court's determination of when filed | Court's determination of when filed |
[7] Moment of generation is the moment the XML is created and then sent, assuming the creation-time and sending-time are close in time (i.e., within seconds or minutes). If the XML is created at a time that is significantly different than when it is sent, then the XML should be edited prior to sending to reflect a date and time as close as possible to the sending date and time. [8] All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset. Confirmation:FilingStatus and Document:FilingStatus[9] Document:FilingStatus is the status of a document when the Confirmation:FilingStatus value is equal to Partial. Partial means that some documents in the filing may have been accepted, rejected, or are still pending review. The Document:FilingStatus element should only be used in Confirmation XML. It must be ignored in Filing XML. If Confirmation:FilingStatus is not equal to Partial, then Document:FilingStatus must be ignored by a receiving application. As with any Confirmation XML, Document:Key values must be present for all documents per this specification so that filing applications can match a filed document with the document's disposition. Court Initiated Documents[10] It is possible for the receiving application to send more documents in a confirmation than the number of documents it receives. The additional documents are called court initiated documents. Court initiated documents must include a Document:Key value generated by the original receiving application (i.e., the court's application, not the filing application). Although this is a simple rule, it means that there are three types of Document:Key processing in a Confirmation XML, as follows: Keys | Court Application ("CA") | Filing Application ("FA") |
---|
Same Keys | Send FA keys in Document:Key | Check for and match FA keys in Document:Key. If each key matches, then processing is done. | Different Keys | Send CA keys in Document:Key and FA keys in LegacyKey | Check for FA keys in Document:Key. If any key is not recognized, then check for FA keys in LegacyKey. If all keys match either a Document:Key or a LegacyKey, then processing is done. | Court Initiated New Key | Send CA key in Document:Key. Do not include LegacyKey. | Check for FA keys in Document:Key. If any key is not recognized and FA keys does not exist in LegacyKey, then this is a court initiated document. |
[11] See the Document schema for additional documentation. Court Initiated Transactions[12] Court initiated documents are distinguished from court initiated transactions. A court initiated transaction is a transaction that the court originates in a case without having first receiving a filing. Confirmation XML must not be used for court initiated transactions. Instead, Notice XML must be used for court initiated transactions. Confirmation Acknowledgement[13] A confirmation acknowledgement is a confirmation to an asynchronous confirmation. An application is not required to send a confirmation acknowledgment, but may do so. If an application sends a confirmation acknowledgment, the application must send Confirmation XML as defined in this specification with as few elements as possible. If the transaction is successful, then the Confirmation:FilingStatus value must be equal to Received. If the transaction is unsuccessful, then the Confirmation:FilingStatus must be equal to Error. If an error occurs, the sending application (i.e., the court or an intermediary server) is not responsible sending another Confirmation XML, but may do so. Child Element(s) | minOccurs | maxOccurs | Number | 1 | unbounded |
[14] Confirmation:Numbers is a container element for one or more Confirmation:Number elements. Confirmation XML may have more than one Confirmation:Number element depending on whether an intermediary application is involved in the transaction. See the Confirmation:Number element for more details.
Introduction[15] Confirmation:Number is a sequential number generated by a receiving application that evidences receipt of a filing. The Confirmation:Number should be generated sequentially by the receiving application and must be unique within the receiving application (taking into consideration the required attributes on the element). Delivery of a Confirmation:Number value to a sending application from a receiving application signifies that the sending application no longer has responsibility to file or re-file the filing. [16] The Confirmation:Number is different than the Confirmation:FilingKey. The Confirmation:FilingKey is a mirror of the Filing:Key to which the confirmation is responding. Confirmation:Number Meaning and Responsibility to Re-File[17] Confirmation:Number has three required attributes (a) NumberSource (b) NumberType, and (c) OrganizationKey. The NumberSource attribute must have one of two values: Intermediary or Court. The value Intermediary means that an intermediary application has generated the confirmation number, rather than the court. The value Court means that a court has generated the confirmation number. The NumberType attribute must have one of two values: Synchronous or Asynchronous. The value Synchronous means that the communication is a synchronous confirmation. The value Asynchronous means that the communication is an asynchronous confirmation. In a synchronous transaction, regardless of whether a court or an intermediary has generated the confirmation number, the receipt of a confirmation number means that the sending application no longer has a responsibility to file or re-file the filing. If the confirmation number has been generated by an intermediary, it may be informative to the sending application (i.e., to the filer) to know whether the filing has actually reached the court. Ultimately the filer seeks confirmation that the filing reached the court. As a result, a filer will be most interested in receiving a court confirmation number and distinguishing a court and an intermediary confirmation number. Intermediary Application: Synchronous/Asynchronous Confirmations[18] Assuming a filing transaction where there is a filing application, an intermediary application, and a court application, it is possible that an intermediary application will not synchronously forward a filing to a court. Instead, the intermediary application might hold the filing for a duration of time (e.g., a second, a minute, or an hour) prior to forwarding the filing to the court. In this situation, the intermediary application is only able to return a confirmation number to the filing application that has been generated by the intermediary. It cannot send a court-generated confirmation number, because no such number exists. In this situation, the intermediary application can send only one Confirmation:Number element. For example, the Confirmation:Number value might be 00000001234 with an NumberSource attribute value equal to Intermediary. [19] Assuming the same scenario as above, a court application could send a subsequent asynchronous confirmation through the intermediary application or directly to the filing application. If a subsequent asynchronous confirmation is sent directly from the court application to the filing application, then the Confirmation:Number value might be 00000007899 with an NumberSource attribute value equal to Court. If a subsequent asynchronous confirmation is sent through the intermediary application, then the intermediary application might only pass through the court's Confirmation XML (a discouraged practice incompatible with the Header XML specification) or it could pass through the court's confirmation number and add its own intermediary confirmation number. In the latter situation, the filing application would receive two Confirmation:Number elements and two values, such as 00000001234 and 00000007899, one with an NumberSource attribute value equal to Intermediary and another NumberSource attribute value equal to Court. Intermediary Application: Synchronous/Synchronous Confirmations[20] Assuming the same three applications, the intermediary application could send the filing synchronously to the court. This would require opening a second HTTP connection between the intermediary application and the court application while the original HTTP connection between the filing application and the intermediary application is still open. This is technically possible and works well with small Filing XML, but may result in unwanted overhead and increased transaction times from the perspective of the filer for large Filing XML. In this situation, the filing application should receive two Confirmation:Number elements and two values, such as 00000001234 and 00000007899, one with an NumberSource attribute value equal to Intermediary and another NumberSource attribute value equal to Court. Court Application: Synchronous Confirmation[21] If there are only two applications involved in a filing transaction, a filing application and a court application, then only one Confirmation:Number element is required. In this situation, the Confirmation:Number element must have an NumberSource attribute value equal to Court. OrganizationKey Attribute[22] The OrganizationKey attribute is a required attribute that holds a unique identifier for the organization responsible for generating the confirmation number. The combination of the NumberSource attribute and the OrganizationKey attribute allows the filing application to identify the organization responsible for generating the confirmation number and whether the organization is a court or an intermediary. [23] Confirmation:Date is the date on which the confirmation is generated by the sending application. See the introduction to this schema's documentation or more information. [24] All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset. [25] Confirmation:Time is the time at which the confirmation is generated by the sending application. See the introduction to this schema's documentation or more information. [26] All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset. Introduction[27] Confirmation:FilingStatus is the status of the filing. Confirmation:FilingStatus can have the following values: (a) Received, (b) Accepted, (c) Pending, (d) Rejected, (e) Held, (f) Partial, (g) Update, and (h) Error. A Confirmation:Number must be sent with all values, except for Error status. Received[28] The value Received means that, at least, the receiving application has checked that the Filing XML is well-formed and valid against the schema. Receiving applications may also programmatically check whether certain values in the Filing XML are logically correct. For example, a receiving application may check to ensure that plaintiff and defendant names are acceptable values or that all fees have been paid. If the Filing XML is acceptable to the receiving application, then the receiving application must return the value Received (or other acceptable value as defined in this section) along with a Confirmation:Number. Sending the value Received with a Confirmation:Number means that the filing application no longer has a responsibility to file or re-file. The value Received will most often be used when sending a synchronous confirmation. Accepted[29] The value Accepted means that the filing has been accepted by the court as filed or lodged. (It is recognized that terms such as "filed" and "lodged" and their meanings may differ among jurisdictions. Jurisdictions should define the meaning of Accepted in applicable court rules.) [30] The Confirmation:FilingDate and Confirmation:FilingTime are the date and time when the court accepts the filing. The Confirmation:FilingDate and Confirmation:FilingTime may be the same values as the Filing:Date and the Filing:Time in the original Filing XML, provided that the court accepts the filing application's assertion of the filing date and time. If the court does not accept the filing date and time, then it must provide its own values. The Confirmation:FilingDate and Confirmation:FilingTime values may or may not be the same as the Confirmation:Date and Confirmation:Time. A Confirmation:Number must be sent with the Accepted status. The value Accepted will most often be used when sending an asynchronous confirmation. Pending[31] The value Pending means that the filing is still pending as of the Confirmation:Date and Confirmation:Time. A Confirmation:Number must be sent with the Pending status. Note that all confirmation numbers should be sequential, regardless of the Confirmation:FilingStatus (e.g., even for Pending filings). A Pending confirmation may be useful as a means of providing good customer service when a filing has been waiting in a queue for a long time. The value Pending will most often be used when sending an asynchronous confirmation. [32] If the value is Pending, then the Document:File element may be empty. See the Document schema for additional details. Held[33] The value Held means that the filing is not only pending, but it has been reviewed and is awaiting some other action, as of the Confirmation:Date and Confirmation:Time. A Confirmation:Number must be sent with the Held status. Note that all confirmation numbers should be sequential and unique (taking into consideration the attributes on the element), regardless of the Confirmation:FilingStatus (e.g., even for Held filings). A Held confirmation may be useful as a means of providing good customer service when a filing has been waiting in a queue for a long time. The value Held will most often be used when sending an asynchronous confirmation. [34] If the value is Held, then the Document:File element may be empty. See the Document schema for additional details. Rejected[35] The value Rejected means that the filing has been rejected by the court at a time subsequent to the initial receipt. It is, therefore, possible that a filer could receive a Confirmation:Number and a Received status, but that the document might later be rejected. Court rules should address this possibility. A Confirmation:Number must be sent with the Rejected status. A confirmation with a Confirmation:FilingStatus value equal to Rejected should also include a Confirmation:Message with a value describing the reason for the rejection. The value Rejected will most often be used when sending an asynchronous confirmation. Partial[36] The value Partial means that some documents in the filing have been rejected by the court and some documents have been accepted. If the court partially rejects a filing, the status of each document can be found in the Document:FilingStatus element. Unless the Document:FilingStatus element has the value Partial, the Document:FilingStatus should not be populated and should be ignored. Update[37] The value Update means that the confirmation is an updated version of a previously submitted asynchronous confirmation. The update status may not change an accepted document to rejected or a rejected document to accepted. The update status does not replace service or notice of new documents. The update status should have limited use only for sending changed data, such as party information, in situations where there has been a clerical error or other change in data that would not affect the substantive rights of parties. [38] If the value is Update, then the Document:File element may be empty. See the Document schema for additional details. Error[39] The value Error means that there has been a technical error and the filing has not been Received. If the Filing XML is not well-formed and valid, then the receiving application must return an Error. If the value Error is used, then a Confirmation:Number must not be sent. [40] If the errors in the Filing XML or the network connection are so severe that the receiving application cannot respond with a confirmation (e.g., the receiving application has no knowledge of the filing), then the filing application should generate Confirmation XML itself with a Confirmation:FilingStatus value equal to Error. A filing application should generate a confirmation, for example, if it cannot reach the server to create an HTTP connection, if the HTTP connection times out, or if the HTTP response does not return a well-formed and valid confirmation. It may also happen that the filer's network connection is not working, in which case the filing application should generate a confirmation. A confirmation with a Confirmation:FilingStatus value equal to Error should also include a Confirmation:Error element with a values describing the error. [41] Confirmation:FilingDate is the date of the filing as confirmed by the court. If the court accepts the filer's assertion of the date of filing, then the Confirmation:FilingDate may be the same as the Filing:Date, at the discretion of the court. Otherwise, Confirmation:FilingDate is a date designated by the court. The Confirmation:FilingDate is not the same as the transmission date, although these date values may be the same or very close in time. Confirmation:FilingDate is not a date from the document. Confirmation:FilingDate is not the date of service of process. See the introduction to this schema's documentation or more information. [42] All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset. [43] Confirmation:FilingTime is the time of the filing as confirmed by the court. If the court accepts the filer's assertion of the time of filing, then the Confirmation:FilingTime may be the same as the Filing:Time, at the discretion of the court. Otherwise, Confirmation:FilingTime is a time designated by the court. The Confirmation:FilingTime is not the same as the transmission time, although these time values may be the same or very close in time. See the introduction to this schema's documentation or more information. [44] All times must use a time zone offset. For example, the following time is correct: 10:53:26-07:00. The following time is incorrect: 10:53:26. Dates must not use a time zone offset. Child Element(s) | minOccurs | maxOccurs | LegacyCase | 1 | unbounded |
[45] Confirmation:LegacyCases is a container element for the Confirmation:LegacyCase element. Child Element(s) | minOccurs | maxOccurs | Filer | 1 | unbounded |
[46] Confirmation:Filers is a container element for one or more Confirmation:Filer elements.
[47] Confirmation:Filer contains information about who filed the case as accepted by the court. This information should mirror the information accepted by the court. See Person and Organization schemas. Child Element(s) | minOccurs | maxOccurs | Person | 1 | unbounded |
[48] Confirmation:People is a container element for one or more Confirmation:Person elements. Confirmation:People should include information about people sent in the Filing XML as accepted by the court. Confirmation:People should also include people added to the case by the court in the context of the filing transaction. Confirmation:People should not include people that are in the case management system, but are otherwise unrelated to the filing. See Person schema.
[49] Confirmation:Organizations is a container element for one or more Confirmation:Organization elements. Confirmation:Organizations should include information about organizations sent in the Filing XML as accepted by the court. Confirmation:Organizations should also include organizations added to the case by the court in the context of the filing transaction. Confirmation:Organizations should not include organizations that are in the case management system, but are otherwise unrelated to the filing. See Organization schema. Child Element(s) | minOccurs | maxOccurs | Thing | 1 | unbounded |
[50] Confirmation:Things is a container element for one or more Confirmation:Thing elements. Confirmation:Things should include information about things sent in the Filing XML as accepted by the court. Confirmation:Things should also include things added to the case by the court in the context of the filing transaction. Confirmation:Things should not include things that are in the case management system, but are otherwise unrelated to the filing. See Thing Schema. Child Element(s) | minOccurs | maxOccurs | Charge | 1 | unbounded |
[51] Confirmation:Charges is a container element for one or more Confirmation:Charge elements. Confirmation:Charges should include information about charges sent in the Filing XML as accepted by the court. Confirmation:Charges should also include charges added to the case by the court in the context of the filing transaction. Confirmation:Charges should not include charges that are in the case management system, but are otherwise unrelated to the filing. See Charge schema.
[52] Confirmation:LeadDocuments is a container element for Confirmation:LeadDocument. Confirmation:LeadDocuments should include lead documents added to the case by the court. Regardless of whether the filing application sends a base64-encoded document or a link, there is no requirement to send back a base64 encoded document, although applications may do so. Applications are instead encouraged to send back a link to the filed document. This results in smaller confirmations and faster transaction times. See Document schema. [53] It is possible that a filer or a filing application identifies what should be an attachment as a lead document. In this situation, the clerk review application should allow the clerk to reclassify the lead document as an attachment. Likewise, the clerk review application should allow the clerk to reclassify an attachment as a lead document. The Confirmation XML must include a lead document, in any situation. All documents, whether a lead document or an attachment, must be identified using a unique Document:Key value. If documents switch nodes or are included in Confirmation XML nodes that are in a different order than Filing XML nodes, then the unique Document:Key value must must follow the document. See the Document schema and the Document:Key element for more information. Child Element(s) | minOccurs | maxOccurs | Attachment | 1 | unbounded |
[54] Confirmation:Attachments is a container element for one or more Confirmation:Attachment elements. The Confirmation:Attachments element should include attachments added to the case by the court. Regardless of whether the filing application sent a base64-encoded document or a link, there is no requirement to send back the base64 encoded document, although applications may do so. Applications are instead encouraged to send back a link to the filed document. This results in smaller confirmations and faster transaction times. See the Confirmation:LeadDocument element for documentation on switching a lead document and confirmation or changing the order of of attachments. See the Document schema and the Document:Key element for more information. Child Element(s) | minOccurs | maxOccurs | Fee | 1 | unbounded |
Attribute(s) | type | use | fixed/default | FeeTotal | xsd:string | required | None |
[55] Confirmation:Fees is a container element for one or more Confirmation:Fee elements. Confirmation:Fees must include each individual fee charged to the filer by the court. The total amount of the fees, whether there is only one fee or multiple fees, must be included in the required attribute FeeTotal. See Fee schema. Child Element(s) | minOccurs | maxOccurs | Service | 1 | unbounded |
[56] Confirmation:Services is a container element for one or more Confirmation:Service elements. A Confirmation:Service element represents one service of process event. To express more than one service of process event, applications must use more than one Confirmation:Service elements. See Confirmation:Service element. Child Element(s) | minOccurs | maxOccurs | Calendar | 1 | unbounded |
[57] Confirmation:Calendars is a container element for one or more Confirmation:Calendar elements. A Confirmation:Calendar element represents multiple calendar events on a single day for a given court department. To express multiple calendar events on a single day for a single court department, applications must use only one Confirmation:Calendar element. To express multiple days, applications must use multiple Confirmation:Calendar elements. To express events taking place in different departments, applications must also use multiple Confirmation:Calendar elements. See Confirmation:Calendar element. Child Element(s) | minOccurs | maxOccurs | Extension | 1 | unbounded |
[58] Confirmation:Extensions is a container element for one or more Confirmation:Extension elements. In a filing, a Filing:Extension is a generic name/value pair that allows filing applications to send information not included in the filing specification. The Filing:Extension element may include a SendBack attribute value equal to Yes. Receiving applications that encounter a SendBack value equal to Yes must send back the exact name/value pair in Confirmation:Extension element. See Extension schema. [59] Confirmation:Confidential is a single element of type boolean. When set to true, Confirmation:Confidential means that the court has honored the filer's request to keep the incoming filing confidential. When set to false, Confirmation:Confidential means that the court has not honored the filer's request. [60] Confirmation:Sealed is a single element of type boolean. When set to true, Confirmation:Sealed means that the court has honored the filer's request to seal the document. When set to false, Confirmation:Sealed means that the court has not honored the filer's request. Child Element(s) | minOccurs | maxOccurs | Message | 1 | unbounded |
[61] The Confirmation:Messages element is a container element for one or more Confirmation:Message elements. [62] Confirmation:RunMode is a single element with two possible values: Test or Live. Filing:RunMode is used when sending test filings to a live server so that downstream applications or the court clerk will know to ignore or behave differently toward the test filing. The element may also be useful in situations where test filings into a live server need to be purged programmatically, rather than deleted manually. Confirmation:RunMode must mirror the value sent in the original filing. [63] Applications are urged to implement Confirmation:RunMode in both test and live systems. When migrating from a test environment to a live environment, this element allows applications to send and receive filings and confirmations in a live system, while retaining the ability to identify a filing or a confirmation as a test. The ability to send and receive test filings and confirmations in a live system is helpful in the final stages of going live with an electronic filing system. Child Element(s) | minOccurs | maxOccurs | Error | 1 | unbounded |
[64] The Confirmation:Errors element is a container element for one or more Confirmation:Error elements. [65] Confirmation:Message is descriptive text about the confirmation or some other message from the court to the filer. Confirmation:Message must be used when Confirmation:FilingStatus value is equal to Rejected. Confirmation:Message may be used for other messages intended to be conveyed to the filer, except for error messages. [66] The corresponding Filing:Message element is defined as a message intended to be conveyed to the court from the filer on any topic. Unlike other confirmation elements, Confirmation:Message should not mirror the text sent by the filing application. Instead, the Confirmation:Message should include a message intended to be conveyed from the court to the filer, if any. [67] Applications must use the Error:Message element when sending an error message. [68] Confirmation:FilingKey is the value of the Filing:Key in the original filing. Receiving applications must send the original Filing:Key with the confirmation so the filing application can match the original filing with the confirmation. [69] Confirmation:Case contains information about the case filed as confirmed by the court. If the court adds, deletes, or changes information in the Filing:Case element, then receiving application must send back the added or changed information and must not send back the deleted information. See Case Schema. [70] Confirmation:LegacyCase contains information about a case with a case number that is associated with, and a predecessor of, Confirmation:Case. See Case Schema. [71] Confirmation:CourtDetails contains information about the court into which documents have been filed as confirmed by the court. Filing applications should copy this information from the court's Policy XML. As a result, this information should not change in Confirmation XML. See CourtDetails Schema. [72] Confirmation:Person contains information about a person that is a party to a case or is otherwise associated with a case. If the court adds, deletes, or changes information in the Filing:Person element, then receiving application must send back the added or changed information and must not send back the deleted information. See Confirmation:People documentation. See Person schema. [73] Confirmation:Organization contains information about a organization that is a party to a case or is otherwise associated with a case. If the court adds, deletes, or changes information in the Filing:Organization element, then receiving application must send back the added or changed information and must not send back the deleted information. See Confirmation:Organizations documentation. See Organization schema. [74] Confirmation:Thing contains information about a thing associated with a case. If the court adds, deletes, or changes information in the Filing:Thing element, then receiving application must send back the added or changed information and must not send back the deleted information. See Confirmation:Things documentation. See Thing Schema. [75] Confirmation:Charge contains information about a charge. If the court adds, deletes, or changes information in the Filing:Charge element, then receiving application must send back the added or changed information and must not send back the deleted information. See the Confirmation:Charges documentation. See Charge Schema. [76] Confirmation:Fee contains information about a court filing fee. See Confirmation:Fees documentation, the Fee schema, and the Policy XML specification. [77] Confirmation:Service contains information about documents that have been processed served. See the Service schema. [78] Confirmation:Coversheet contains a filing coversheet document, if any, as accepted by the court. Regardless of whether the filing application sent a base64-encoded document or a link, there is no requirement to send back the base64 encoded document, although applications may do so. Applications are instead encouraged to send back a link to the filed document. This results in smaller confirmations and faster transaction times. See the Document schema. [79] Confirmation:LeadDocument is the primary and most important document in a filing as accepted by the court. See the Confirmation:LeadDocuments documentation and the Document schema. [80] Confirmation:Attachment contains information about a related documents as accepted by the court. See the Confirmation:LeadDocument and Confirmation:Attachments elements. [81] A Confirmation:Payment provides confirmation information about a payment made by a filer. In a Confirmation:Payment only the Payment:Total should be included as confirmation of the total amount charged to the filer's credit card. In a confirmation, this amount should match the amount in the Confirmation:Fees element FeeTotal attribute. See the Payment schema. [82] A Confirmation:Calendar provides confirmation information about calendared events. See the Calendar schema. [83] A Confirmation:Extension is a generic name/value pair that allows applications to send information not included in the confirmation specification. See Confirmation:Extensions element. [84] A Confirmation:Error contains human- and machine-readable information about an error in the Filing XML. If the Confirmation:Number element is not returned, then a Confirmation:Error must be returned. If Confirmation:FilingStatus is equal to Error, then the Confirmation:Error must be returned. |