Web soap service attachment methods - Direct Integration Manual Index - Electronic Invoice
Sumario
- 1 Web soap service attachment methods
- 1.1 “CargarAdjuntos” Method
- 1.2 SCENARIOS ISSUANCE OF DOCUMENTS WITH GRAPHIC REPRESENTATION
- 1.3 Standard Graphical Representation (Using the Attachment parameter of the Send method as '0' or '1')
- 1.4 Custom graphic representation by TFHKA
- 1.5 Graphic representation sent as an attachment from the administrative system or ERP (Use of the attachments parameter of the method Send in '11')
Web soap service attachment methods
The SOAP Web Attachment Service exposes a single method that will be used n times per generated electronic document, where n is the number of attached files that the electronic invoice that is being processed has (bear in mind that since it is an email where the invoice with its graphic representation and the attachments, then there is a limit of attachments based on the weight (in KB) of the same).
“CargarAdjuntos” Method
It allows attaching or sending files (attachments) by email during the issuance of the electronic document. This method is executed after consuming the Enviar method with the attachments parameter set to “1” or “11”. Here is the flow of the method:
@IMPORTANT: The CargarAdjuntos method receives among its parameters a field to indicate the sending of the mail, that is, if the field or property enviar receives a “0 ” then the document continues to wait for more attachments and if it receives “1” it is sent with the attachments that have been loaded up to that moment.
- REQUEST
- Parameters to Send
| Type | Identifier | Description |
|---|---|---|
| String | tokenEmpresa | Supplied by The Factory HKA Colombia |
| tokenPassword | ||
| Adjunto | Adjunto | Control data of the document to be attached |
Where Class.Adjunto contains the following information:
| Type | Identifier | Description |
|---|---|---|
| byte[] | Archivo | Array of bytes of the file to be attached |
| Array <string> | Mail to which you want to send the XML (AttachedDocument) with all the attachments loaded so far (sending is activated when sending is "1") | |
| String | Enviar |
|
| String | Formato | Attachment extension, allowed formats:
|
| String | Nombre | Name that the attached file will take |
| String | numeroDocumento | Prefix and consecutive of the Electronic Document concatenated without separators. Example “PRUE980338212” |
| String | Tipo | 1: Graphic representation generated by the ERP 2: Type of attached document or attachments |
- RESPONSE
- Parameters to Receive
| Type | Identifier | Description |
|---|---|---|
| int | Código | Indicates the status of the operation returned by the service |
| String | Mensaje | This error identification message |
| Array <String> | mensajesValidacion | Validation messages in case of rejection |
| String | resultado | Result |
SCENARIOS ISSUANCE OF DOCUMENTS WITH GRAPHIC REPRESENTATION
Standard Graphical Representation (Using the Attachment parameter of the Send method as '0' or '1')
Under this scenario, the issuer of electronic documents has the standard graphic representation generated by TFHKA, which will be delivered to the acquirer in the notification email of the electronic document. During the issuance of the document, extra fields reserved by TFHKA may be included in the standard graphic representation, which will include predetermined labels in it in order to provide the reader of the representation with clarity about the amounts and information reported. The extra fields reserved by TFHKA in the standard graphic representation are detailed below:
EXTENSIBLE FIELDS RESERVED BY TFHKA
| ||||||||||||||||||||||||||||||||||||
Custom graphic representation by TFHKA
In the event that the issuer contracts a graphic representation service with TFHKA, it must be taken into account that it is a development project which entails associated times and costs. In addition to the time associated with the development of the personalized template by TFHKA, the adaptation of the development in the accounting system must be taken into account, which must be carried out by the software house or its developer, in order to report the extra fields. in which the information to be displayed will be reflected.
The extra fields mentioned above are provided by the TFHKA graphics team, once a version approved by the taxpayer is available for use.
@IMPORTANT:As can be seen, this scenario involves the development of both parties (ERP and TFHKA), therefore, before contracting this service, the scope and customization costs must be determined.
Graphic representation sent as an attachment from the administrative system or ERP (Use of the attachments parameter of the method Send in '11')
In the case in which the issuer contracts a graphic representation service with the software house, developer or person in charge of making the corresponding adjustments in the accounting software or ERP for the issuance of electronic documents, the following aspects must be taken into account:
- The Factory HKA is responsible for the generation of the UBL and its transmission to the DIAN.
- Once the correct validation and generation of the UBL is verified, the software house can proceed to generate a graphic representation that must comply with:
- The elements of law required by the DIAN: inclusion of the QR code and the CUFE or CUDE chain in the documents, as appropriate.
- The elements of law required by any supervisory entity to the issuer of the documents.
- The visual and brand representation elements required by the client: logos, banking information, legends referring to the tax responsibilities of the issuer, etc.
- The Software House, in this scenario, assumes responsibility together with the taxpayer for any incident of fraud due to evasion, misinterpretation, error or omission of relevant and mandatory information by the regulations.
- TFHKA does not protect this representation in its systems and makes it clear that its participation as a technology provider is limited to the generation of the UBL and its validation before the DIAN.
During the synchronization of attachments, the following aspects must be taken into account:
- Files to be synced must be Base64 encoded.
- It is recommended to indicate as recipient emails the emails reported in the Class.Destinatario.email[] array
- The names of the attachments to be synced must be different.
- Only the synchronization of one (1) file is allowed with the type parameter = '1', corresponding to the graphic representation of the electronic document.
- For the common attachments to be synchronized, which do not correspond to the graphic representation of the document, the type parameter of the Loading Attachments method must be set to '2', corresponding to Annexes or common attachments.
- All attachments to be synchronized must not exceed the weight of 1.8 MB, this in order to comply with the provisions of the DIAN Technical Annex regarding the maximum weight of 2MB of the .ZIP file delivered in the email notification electronic.
