Diferencia entre revisiones de «Métodos servicio adjuntos web soap - Indice Manual Integración Directa»
Línea 1: | Línea 1: | ||
− | <includeonly>=</includeonly>== | + | <includeonly>=</includeonly>==Web soap attachment service methods==<includeonly>=</includeonly> |
− | + | 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: |
− | + | <br> | |
+ | <br> | ||
+ | [[Archivo:Diagrama de Envió de adjuntos.png|1000px|thumb|Diagrama de Envío de adjuntos]] | ||
<br> | <br> | ||
<br> | <br> | ||
− | + | '''@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. | |
− | |||
<br> | <br> | ||
− | |||
− | |||
− | |||
<br> | <br> | ||
<br> | <br> | ||
+ | ; REQUEST: Parameters to Send | ||
<br> | <br> | ||
− | |||
− | |||
{| class="mw-collapsible wikitable" | {| class="mw-collapsible wikitable" | ||
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Type |
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Identifier |
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Description |
|- valign="center" | |- valign="center" | ||
|- | |- | ||
|rowspan="2"|String | |rowspan="2"|String | ||
|tokenEmpresa | |tokenEmpresa | ||
− | |rowspan="2"| | + | |rowspan="2"|Provided by The Factory HKA Colombia |
|- | |- | ||
|tokenPassword | |tokenPassword | ||
Línea 31: | Línea 28: | ||
|Adjunto | |Adjunto | ||
|Adjunto | |Adjunto | ||
− | | | + | |Control data of the document that you want to attach |
|} | |} | ||
− | + | Where Class.Adjunto contains the information below: | |
{| class="mw-collapsible wikitable" | {| class="mw-collapsible wikitable" | ||
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Type |
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Identifier |
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Description |
|- valign="center" | |- valign="center" | ||
|- | |- | ||
|byte[] | |byte[] | ||
|Archivo | |Archivo | ||
− | | | + | |Byte array of the file to attach |
|- | |- | ||
|Array <string> | |Array <string> | ||
|email | |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 | |String | ||
|Enviar | |Enviar | ||
| | | | ||
− | : "0" | + | : "0" Attach file and associate it to the electronic document without sending the email to the Purchaser |
− | : "1" | + | : "1" Attach the file to the electronic document and immediately send an email to the Acquirer |
|- | |- | ||
|String | |String | ||
|Formato | |Formato | ||
− | | | + | |Attachment extension, allowed formats: |
: (png, bmp, jpg, pdf, doc, docx, xls, xlsx, ppt, pptx,rar) | : (png, bmp, jpg, pdf, doc, docx, xls, xlsx, ppt, pptx,rar) | ||
|- | |- | ||
|String | |String | ||
|Nombre | |Nombre | ||
− | | | + | |Name that the attached file will take |
|- | |- | ||
|String | |String | ||
|numeroDocumento | |numeroDocumento | ||
− | | | + | |Prefix and consecutive of the Electronic Document concatenated without separators. Example “PRUE980338212” |
|- | |- | ||
|String | |String | ||
− | | | + | |Type |
− | | 1: | + | | 1: Graphic representation generated by the ERP 2: Type of attached document or attachments |
|} | |} | ||
; RESPONSE: Parámetros a Recibir | ; RESPONSE: Parámetros a Recibir | ||
{| class="mw-collapsible wikitable" | {| class="mw-collapsible wikitable" | ||
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Type |
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Identifier |
− | ! style="background:#f2f2f2; text-align:center;"| | + | ! style="background:#f2f2f2; text-align:center;"|Description |
|- valign="center" | |- valign="center" | ||
|- | |- | ||
|int | |int | ||
|Código | |Código | ||
− | | | + | |Indicates the status of the operation returned by the service |
|- | |- | ||
|String | |String | ||
|Mensaje | |Mensaje | ||
− | | | + | |This error identification message |
|- | |- | ||
|Array <String> | |Array <String> | ||
|mensajesValidacion | |mensajesValidacion | ||
− | | | + | |Messages in case of refusal |
|- | |- | ||
|String | |String | ||
|resultado | |resultado | ||
− | | | + | |Result |
|} | |} | ||
{{clear}} | {{clear}} | ||
− | ===''' | + | ==='''SCENARIOS ISSUANCE OF DOCUMENTS WITH GRAPHIC REPRESENTATION'''=== |
− | ===<font color="Blue"> | + | ===<font color="Blue">Standard Graphical Representation (Using the Attachment parameter of the Send method as '0' or '1')</font>=== |
− | + | 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: | ||
{| class="wikitable" style="width: 100%;" | {| class="wikitable" style="width: 100%;" | ||
Línea 108: | Línea 107: | ||
|- valign="center" | |- valign="center" | ||
|-style="text-align:center;" | |-style="text-align:center;" | ||
− | |colspan="2"| | + | |colspan="2"|EXTENSIBLE FIELDS RESERVED BY TFHKA |
{| class="wikitable" style="width: 100%;" style="margin: auto;" | {| class="wikitable" style="width: 100%;" style="margin: auto;" | ||
− | ! style="color:white;background:#2F5496; text-align:center;"| | + | ! style="color:white;background:#2F5496; text-align:center;"|Code |
− | ! style="color:white;background:#2F5496; text-align:center;"| | + | ! style="color:white;background:#2F5496; text-align:center;"|PDF Label |
− | ! style="color:white;background:#2F5496; text-align:center;"| | + | ! style="color:white;background:#2F5496; text-align:center;"|Description |
− | ! style="color:white;background:#2F5496; text-align:center;"| | + | ! style="color:white;background:#2F5496; text-align:center;"|PDF Label |
− | ! style="color:white;background:#2F5496; text-align:center;"| | + | ! style="color:white;background:#2F5496; text-align:center;"|Observations |
|- valign="center" | |- valign="center" | ||
|100200 | |100200 | ||
− | | | + | |Footer |
− | | | + | |Footer |
|AN|100 | |AN|100 | ||
| | | | ||
|- | |- | ||
|5170000 | |5170000 | ||
− | |Total Base | + | |Total Base Excluded |
− | |Total Base | + | |Total Base Excluded |
− | | | + | |Free format |
− | | | + | |For totals the R.G |
|- | |- | ||
|5170001 | |5170001 | ||
− | |TOTAL | + | |TOTAL Discount Detail |
− | |TOTAL | + | |TOTAL Discount Detail |
− | | | + | |Free format |
− | | | + | |For totals the R.G |
|- | |- | ||
|5170002 | |5170002 | ||
− | |TOTAL | + | |TOTAL Withholdings |
− | |TOTAL | + | |TOTAL Withholdings |
− | | | + | |Free format |
− | | | + | |For totals the R.G |
|- | |- | ||
|5170003 | |5170003 | ||
− | |TOTAL | + | |TOTAL to Pay |
− | |TOTAL | + | |TOTAL to Pay |
− | | | + | |Free format |
− | | | + | |For totals the R.G |
|- | |- | ||
|5170004 | |5170004 | ||
− | |TOTAL | + | |TOTAL TO PAY in Letters |
− | |TOTAL | + | |TOTAL TO PAY in Letters |
− | | | + | |Free format |
− | | | + | |For totals the R.G |
|} | |} | ||
|} | |} | ||
Línea 156: | Línea 155: | ||
[[Archivo:EtiquetasRG.png|centro|EtiquetasRG]] | [[Archivo:EtiquetasRG.png|centro|EtiquetasRG]] | ||
− | ===<font color="Blue"> | + | ===<font color="Blue">Custom graphic representation by TFHKA</font>=== |
+ | |||
+ | 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. | |
− | |||
− | + | <font color="red">@IMPORTANT:</font> 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. | |
− | <font color=" | + | ===<font color="Blue">Graphic representation sent as an attachment from the administrative system or ERP (Use of the attachments parameter of the method Send in '11')</font>=== |
− | + | 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. | |
− | * The Factory HKA | + | * 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. |
− | * TFHKA | ||
− | ''' | + | '''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. |
Revisión del 14:24 2 mar 2022
Sumario
- 1 Web soap attachment service 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 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:
@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> | 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 |
|
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 | 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 |
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 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.