This type is a generic key-value pair The name of this property. Must be unique within all properties. This contains a set of metadata elements to be returned in the callback to ER>B. A single metadata item This contains an invoice document. As ER>B supports multiple formats, and we can't tell whether it will always be XML, the content must be base64Binary encoded. It also helps decoupling from a specific XML schema version of an invoice. If it is an XML document, the XML declaration <?xml version='...' encoding='...'?> is always contained in the binary encoded data! The ER>B internal type of the invoice document. E.g. 'ebInterface 4.0' or 'AustroFIX 5'. The original encoding of the document before it was Base64 encoded. E.g. UTF-8. The MIME type of the invoice document. Usually this is 'application/xml' for all XML data types This type represents an attachment delivered together with the invoice. All attachments are Base64 encoded as they are usually binary files. The (file)name of this attachment. It should not contain any path element! The original encoding of the document before it was Base64 encoded. This is only relevant for text attachments. The MIME type of this attachment This type contains a printable invoice - usually a PDF - that is generated automatically by ER>B. The transmission is always Base64 encoded. The MIME type of the printable invoice. For PDF this is e.g. 'application/pdf'. This type contains settings relevant for exactly this invoice transmission. Optional request extension point. Only handled upon bilateral agreement. If this flag is set to 'true', the delivery is considered a test-delivery and should not be processed productively! For production invoices, this flag is set to 'false'. If ID of the language in which the returned messages should be printed. Currently supported are: 'de' - German 'en' - English The request type filled in ER>B. The type of the recipient ID as bilaterally agreed. For GLN numbers this may e.g. be 'GLN'. For the ER>B 'Auftragsreferenz' the value is 'ERB'. The ID of the recipient as bilaterally agreed. This may e.g. be a GLN number or the ER>B 'Auftragsreferenz'. The syntax of this field differs from case to case. The ER>B internal ID that is the key for asynchronous response matching. Contains the metadata for the passed invoice. This information is mainly present because it must be send back in the asynchronous callback so that ER>B can build the status message for the original supplier. Contains the AustroFIX invoice XML document. Contains the original invoice document as delivered to ER>B. It is optional, if the original document was AustroFIX (e.g. by filling out the web form). All attachments delivered together with the original invoice. Only certain file types are allowed: PDF, PNG, XLS, XLSX and XML. The maximum size of all attachments together is currently limited to 50 MB (before Base64 encoding). The total amount of attachments is currently limited to 200. The printable version of the invoice, without any attachments (if present) as they are passed separately. Settings that apply only to this single invoice transmission! Optional extension point. Only handled upon bilateral agreement. The success type - empty by default as nothing is required. Optional success response extension point. Only handled upon bilateral agreement. The internal error code for machine-processing. A list should be provided. This text is forwarded to the invoice deliverer. The field containing the error. This text is forwarded to the invoice deliverer. The main error message for the specified field. This should contain a human readable text. This text is forwarded to the invoice deliverer. The text should be in the language defined by the request attribute Settings/@language. The response error type. It contains a list of error details. All error details. Optional error response extension point. Only handled upon bilateral agreement. The global response choice. Either success or error. If the 'Success' element is present the invoice is considered to be accepted. Further invoice checking by humans may occur. In that case the error handling must be bilateral between the original supplier and the final invoice recipient. If the 'Error' element is present the invoice is considered to be rejected. In case of success this elements is present In case of error this element is present The generic exception type in case something goes wrong on the receiver side. In an exception is thrown the invoice will be rejected. The invoice deliverer will get a generic error message without the exception details. The human understandable exception message.