Métodos servicio adjuntos web soap - Indice Manual Integración Directa

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:

Diagrama de Envío de adjuntos

@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>	email	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	"0" Attaches file and associates it with the electronic document without sending the email to the Acquirer "1" Attach the file to the electronic document and immediately send an email to the Acquirer
String	Formato	Attachment extension, allowed formats: (png, bmp, jpg, pdf, doc, docx, xls, xlsx, ppt, pptx, rar)
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

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 Code PDF label Description PDF label Observations 100200 Footer Footer 100 5170000 Total Base Excluded Total Base Excluded Free Format For totals the R.G 5170001 TOTAL Discount Detail TOTAL Discount Detail Free Format For totals the R.G 5170002 TOTAL Withholdings TOTAL Withholdings Free Format For totals the R.G 5170003 Total to pay TOTAL to Pay Free Format For totals the R.G 5170004 TOTAL TO PAY in Letters TOTAL TO PAY in Letters Free Format For totals the R.G

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.