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

Web soap attachment service 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 Send method with the attachments parameter set to “1” or “11”. The flow of the method is presented below:

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 send receives a "0" then the document continues to wait for more attachments and if it receives "1" it sends with the attachments that have been uploaded so far.

REQUEST

Parameters to Send

Type	Identifier	Description
String	tokenEmpresa	Provided by The Factory HKA Colombia
	tokenPassword
Adjunto	Adjunto	Control data of the document that you want to attach

Where Class.Adjunto contains the information below:

Type	Identifier	Description
byte[]	Archivo	Byte array of the file to attach
Array <string>	email	Mail to which you want to send the XML (AttachedDocument) with all the attachments loaded so far (sending is activated when send is "1")
String	Enviar	"0" Attach file and associate it to the electronic document without sending the email to the Purchaser "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	Type	1: Graphic representation generated by the ERP 2: Type of attached document or attachments

RESPONSE

Parámetros a Recibir

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	Messages in case of refusal
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 time and associated 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 contributor 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 from 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 the attached files, the following aspects must be taken into account:

• The files to be synchronized must be Base64 encoded.
• It is recommended to indicate the emails reported in the Class.Recipient.email[] array as recipient emails.
• The names of the attached files to be synchronized must be different.
• Only the synchronization of one (1) file is allowed with the type parameter u003d '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 Attachments 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 Technical Annex of the DIAN regarding the maximum weight of 2MB of the .ZIP file delivered in the email notification.