Commits (35)
-
Cuauhtémoc Díaz Minor authored
ahora se pueden imprimir los account.voucher aunque no esten timbrados close #1
a9b4b2ee -
Cuauhtémoc Díaz Minor authored
ahora manda a llamar a datosQR() que esta definido en el parser
16fb09aa -
Cuauhtémoc Díaz Minor authored879e0593
-
Cuauhtémoc Díaz Minor authored
se cambia noupdate a 0 y se elimina field tml_source
86a6e1e1 -
agb80 authored
En la definición del reporte agrega la referencia al parser que se necesita para generar el reporte `account.voucher`
8b3c92c9 -
agb80 authored03a34d11
-
agb80 authoredac8e6f4d
-
agb80 authorede361f836
-
agb80 authored440043ff
-
Sotero Toribio Campistrano authored
Se complementa la nota de credito con el metodo de pago PUE, y la forma de pago con codigo (15)Condonación, ya que nos lo muestra el SAT en el anexo 20. que estos campos se lleban por default en la nota de credito. Closed #21
cd99f344 -
agb80 authored8796496c
-
agb80 authored5a292d2e
-
agb80 authoredaecc9f22
-
agb80 authoredd3594fed
-
agb80 authoredc27d34ef
-
agb80 authored
Cuando estamos emitiendo recibos de pago por operaciones realizadas con clientes en el extranjero debemos de colocar dentro del encabezado del XML su número de identificación fiscal y de manera automático colocar el RFC genérico para clientes en el extranjero que proporciona el SAT. Este comportamiento ya se tenía adaptado de manera correcta en las facturas electrónicas pero faltaba incluirlo en los recibos de pago. Básicamente este commit es un copy/paste del template de la factura electrónica al recibo de pagos.
e15c127c -
Cuauhtémoc Díaz Minor authoredee6a748c
-
Cuauhtémoc Díaz Minor authoredd17a9fc0
-
agb80 authored
Cuando las transacciones son multi moneda utilizabamos el campo `amount_currency` para calcular el monto del importe pagado a una factura. Sin embargo cuando se presenta una pérdida cambiaria el campo `amount_currency` queda en cero aunque la transacción sea multi moneda lo que ocasionaba que se sumanran los montos en diferentes monedas y se enviaran datos equivocados en el voucher. El cambio que proponemos hace que utilicemos el campo `currency_id` para saber si estamos trabajando con una transacción multi moneda y sumar los montos correspondientes del campo `amout_currency` con esto los importes en el XML se envían de forma correcta.
200051df -
agb80 authored
En el reporte PDF del Recibo Electrónico de Pagos se estaba usando un campo inexistente para desplegar el tipo de cambio en el que se efectuó la operación.
76f84092 -
Cuauhtémoc Díaz Minor authored908d5794
-
Cuauhtémoc Díaz Minor authoredfe4724e3
-
José Atonaltzin Maldonado Ortiz authored
Cuando se tiene una factura de cliente y esta se paga con un monto mayor al de la factura finkok lanzaba un error ya que el saldo insoluto era menor a cero, con esta correccion se abarcan los escenarios en donde el pago de una factura puede ser menor o mayor al monto establecido en la misma evitando asi el error de finkok
32beb78b -
agb80 authored6ba3885f
-
José Atonaltzin Maldonado Ortiz authored
se corrige la hora del pago en el vaucher en el campo FechaPago ya que originalmente tenia la siguiente estructura: 2018-10-05T00:00:00, sin embargo en la guia de llenado del sat indica que se debe colocar de la siguiente manera 2018-10-05T12:00:00
851cae38 -
agb80 authored4d49bdd9
-
agb80 authored73a98d7e
-
agb80 authoredfcf1bfeb
-
agb80 authoredc37c6f30
-
agb80 authored
De acuerdo a la guía de llenado de complemento de pagos vigente al día 31 de agosto de 2018 los recibos electrónico de pagos se pueden cancelar siempre y cuando vayan a ser substituidos posteriormente por un recibo electrónico. El nuevo recibo debe estar relacionado con el recibo que se está cancelando. Para automatizar este proceso al interior del sistema estamos realizando los siguientes cambios importantes: * Agregamos un nuevo estado a los vouchers de pago que se llama `signed` que servirá para identificar claramente los vouchers firmados. * Cuando estamos en el estado `signed` agregamos dos botones de acción que permiten que el usario pueda realizar la cancelación del voucher o la substitución. * Si el usuario opta por cancelar el voucher entonces el sistema realiza de manera automática la cancelación del CFDI correspondiente, cancela también el voucher de pago al interior del sistema y posteriormente genera un nuevo CFDI por el valor de 1 peso relacionado con el CFDI original y lo timbra. * Si el usuario opta por substituir el voucher entonces el sistema cancela el voucher y el CFDI relacionado y luego vuelve a abrir el voucher de pago para que pueda ser modificado dejando de manera interna la relación con el CFDI original para que se incluya en el nuevo CFDI que se está generando. * Eliminamos el filtro `Sin Firmar` porque ya no tiene razón de ser, ahora todos los vouchers no firmados estarán por defecto en el estado `posted`
f0d769f0 -
agb80 authorede0fe9656
-
agb80 authored
Para facilitar el funcionamiento del sistema cuando se realiza una instalación nueva agregamos una plantilla de correo electrónico por defecto para el envío del recibo de pagos de forma automática.
376acc16 -
agb80 authored8da9613c
-
Cuauhtémoc Díaz Minor authored5c0bb668
-
agb80 authored6d491fa7
Showing
No preview for this file type