Embedded Files
Retenciones
Todo registro comenzará con 3 campos, de longitud fija, sin posibilidad de variarla.
PNRO-ORDEN : 10 caracteres
PFEC-VTO: 8 caracteres
TIPO-SUBTIPO: 6 caracteres
El campo PNRO-ORDEN es un campo alfanumérico que servirá, junto a otros, para agrupar las retenciones que se verán en el mismo pdf.
Puede ser el número de orden de pago o cualquier otro numeró que permita agrupar las distintas retenciones.
El campo PFEC-VTO podrá quedar en blanco y eso se definirá según el aspecto final que tendrá la retención.
El campo TIPO-SUBTIPO será un código que le asignaremos a cada una de las retenciones que la empresa genere.
Hablando del aspecto de la retención, existen dos formatos. El primero que puede tener hasta 7 columnas y el segundo hasta 15 columnas en hoja apaisada.
En los dos formatos es posible poner el logo de la empresa y la firma del responsable.
La firma podrá ser la misma para todos los certificados o podrá ser distinta para cada retención.
Los títulos de las columnas son configurables en el primer ejemplo se dispone de una línea en el segundo de dos.
Las distintas partes del documento son el título, el encabezado, el detalle y el pie.
El título queda definido por el código enviado en el campo TIPO-SUBTIPO y que se les indicará durante la configuración.
El encabezado tiene dos zonas. La primera en donde se muestran los datos de la empresa y de la retención (nro, fecha de emisión, etc.) y la segunda donde se muestran los datos del contribuyente sujeto de retención.
El detalle es la zona donde se pondrán los datos correspondientes a la retención por ejemplo Nro de factura sobre la que se realizó la retención, alícuota, base de retención, total de retenido, ect.
Esto será definido por el usuario con la sola restricción de la cantidad de columnas y el espacio físico.
El pie es la zona donde se podrá poner el importe en letras. Algunas líneas de observaciones totalmente configurables y la firma con su aclaración y cargo.
* La variable Pnro-Orden (los 10 primeros caracteres cada registro) es el número de Orden de Pago. Debe ser el mismo que están enviando en la interfase para la generación del detalle del pago. Es lo que permite asociar la retención al pago y deberá ser exactamente igual, es decir que no es lo mismo “0000001234” que “ 1234”
* Todos los registros de la misma orden de pago deberán encontrarse uno detrás de otro dentro del txt de retenciones. De esta manera se generará un archivo Pdf por cada Orden de pago que tendrá tantas hojas como registros con ese número de orden de pago tenga el txt de retenciones.
*Cuando tengan más de 10 detalles por retención deben agregar un nuevo registro a continuación del primero. Por ejemplo, si tengo una retención de ganancias con 27 detalles tendré que tener 3 líneas o registros en el txt, las dos primeras con 10 detalles cada una y la tercera con sólo 7 detalles. La que tiene 7 detalles deberá ser la última línea (de las 3) y todos los datos del pie del documento son tomados de esta última línea. Las 3 líneas tienen que estar una detrás de la otra, no puede haber entre ellas otro tipo de retención.
Para que se realice la paginación los campos PNRO-ORDEN, TIPO-SUBTIPO y NRO-COMPR deberán ser iguales en todos los registros de paginación.
*Los tamaños de los campos son fijos, lo que no se complete con datos deben ser blancos.
*CONTROL DE PROCESAMIENTO: A fin de poder llevar un control de los TXTs procesados se requiere que, a partir del primer TXT generado con datos, los siguientes contengan en el primer registro el número de la última orden de pago procesada en el TXT anterior.
Por ejemplo:
Supongamos que este es el primer txt
100382903331/10/13 IVACB …
100382903431/10/13ICAAN …
100382903520/07/13RENCAN …
100382903520/07/13IVACB …
el segundo txt debe tener como primer registro el nro. de op del último registro del primer txt
1003829035
100382903606/12/13IVACB …
100382903706/12/13IVACB …
100382903831/05/13RENCAN …
100382903831/05/13IVACB …
100382903931/05/13ICAAN …
el tercer txt debe tener como primer registro el nro. de op del último registro del segundo txt
1003829039
100382904131/05/13ICAAN …
100382904331/05/13ICAAN …
100382904331/05/13RENCAN …
Es muy importante tener este control que nos permitirá detectar fallas en el txt el mismo día que se procesa y no esperar un reclamo de algún proveedor que implica el análisis de varios txt tratando de buscar el problema.
Page updated
Report abuse