La factura electronica se genera con TZ = UTC, bajo ciertas condiciones.

syscon3 commented 3 years ago

Impacted versions:

12.0

Steps to reproduce:

Comenzar con una instalacion limpia de Odoo 12
Instalar todos los modulos necesarios para FE segun instructivo
Crear una factura nueva desde las 6pm hasta 0am y validarla
Se confirma que tanto el SO como el postgres como el usuario que emite la factura, entan configurados con TZ - "America / Costa Rica"

Current behavior:

Se genera la fecha de la factura y la clave en el xml con TZ = UTC,
Hacienda la rechaza por fecha incorrecta.

Expected behavior:

Que la factura se genere con TZ="America/Costa Rica"

Video/Screenshot link (optional):

Link or URL

syscon3 commented 3 years ago

Un dato interesante es que cuando se instala el odoo y se crea la base de datos, el sistema no le asigna el valor TZ a la empresa por defecto, y cuando se crea una nueva tampoco. Probe asignarle el valor "America/Costa Rica" al campo TZ directamente en la tabla res_partner(registro relacionado de res_company) de la base de datos. Despues de estos cambios, el xml se genera correctamente y es aceptado por hacienda.

keadanis commented 3 years ago

Correr el siguiente comando para establecer la zona horaria de CR y no tendrá problemas.

sudo timedatectl set-timezone America/Costa_Rica

syscon3 commented 3 years ago

Estimado, eso ya lo cambie en mi VPS y no me funciono, por alguna razón la única manera que funcione es ajustando a mano el valor del campo TZ directamente en la tabla res_partner.

IMHO, hay que cambiar la parte del código donde genera la fecha/hora para armar el consecutivo y forzarlo siempre a America/Costa_Rica como se hacia en la versión 11. Ya que si o si, se valida con la hora de costa rica y no deberia depender de ninguna configuración adicional del SO ni de la base ni de nada.

Si están de acuerdo, propongo un PR para eso y lo evalúan.

keadanis commented 3 years ago

He probado y no he modificado el código y todo funciona como se debe, claro que tanto usuarios y server deben estar configurados con la zona horaria correspondiente a CR. Pero si a usted le funcionó en hora buena, pero no veo que alguien mas tenga ese problema o al menos lo haya reportado.

TheCloneMaster commented 3 years ago

Extraño, pues como indica Kendall, tenemos bastantes instalaciones corriendo sin problemas en versión 12 y superiores, sin necesidad de aplicar ningún cambio.

De todas formas vamos a darle un vistazo al código. Saludos, -Mario

On Tue, Jun 22, 2021 at 2:14 PM Kendall Adanis @.***> wrote:

He probado y no he modificado el código y todo funciona como se debe, claro que tanto usuarios y server deben estar configurados con la zona horaria correspondiente a CR. Pero si a usted le funcionó en hora buena, pero no veo que alguien mas tenga ese problema o al menos lo haya reportado.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/odoocr/l10n_cr/issues/243#issuecomment-866301618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2XBFDWIBHWXICN2Z74P6LTUDVJHANCNFSM457NBIBA .

syscon3 commented 3 years ago

En mi caso, trabajo con VPS en Uruguay y tengo varias instancias de Odoo para UY y CR simultáneamente en un solo server, de ahí puede que venga el problema para poder configurar correctamente. Pero creo que seria conveniente, para hacer que la fecha sea Explicita para CR y que no dependa de zonas horarias o configuraciones de servidores o base de datos.

El código actual es

                now_utc = datetime.datetime.now(pytz.timezone('UTC'))
                now_cr = now_utc.astimezone(pytz.timezone('America/Costa_Rica'))
                dia = inv.number_electronic[3:5]  # '%02d' % now_cr.day,
                mes = inv.number_electronic[5:7]  # '%02d' % now_cr.month,
                anno = inv.number_electronic[7:9]  # str(now_cr.year)[2:4],
                # date_cr = now_cr.strftime("%Y-%m-%dT%H:%M:%S-06:00")
                # date_cr = api_facturae.get_time_hacienda()
                date_cr = now_cr.strftime("20" + anno + "-" + mes + "-" + dia + "T%H:%M:%S-06:00")

Si observan, esta comentada la linea date_cr = now_cr.strftime("%Y-%m-%dT%H:%M:%S-06:00") que para mi es la que Explicitamente asigna date_cr con la fecha_hora actual de CR, que es la que tiene que tener la clave.

La linea date_cr = now_cr.strftime("20" + anno + "-" + mes + "-" + dia + "T%H:%M:%S-06:00") la veo muy "hardcodeada" y esta tomando valores desde inv.number_electronic que se genera en api_facturae.get_clave_hcienda()

    '''Creamos la fecha para la clave'''
    dia = str(doc.date_invoice.day).zfill(2)  # [8:10]#'%02d' % now_cr.day,
    mes = str(doc.date_invoice.month).zfill(2)  # [5:7]#'%02d' % now_cr.month,
    anno = str(doc.date_invoice.year)[2:]  # str(now_cr.year)[2:4],
    cur_date = dia + mes + anno

que genera la parte de la fecha de la clave segun la fecha de la factura, que depende de la configuracion del sistema. Antes lo tenian con now_cr y lo comentaron...

Como reza la religión de los pythonistas.. mas vale Explicito que Implícito

Propongo que el bloque de código actual, se sustituya con:

                date_cr = api_facturae.get_time_hacienda()

También hay que modificar donde se genera la fecha de la clave en get_clave_hacienda y evaluar la incidencia de estos cambios en el resto del modulo.

Si ven que es posible lo pruebo con diferentes configuraciones y propongo el PR para que le hagan el merge, o si lo consideran incorrecto lo dejamos así.

Saludos y gracias por la atención.

keadanis commented 3 years ago

Mas bien yo lo veo como un caso de personalización que un problema de la localización, pero espero se evalúe lo que propones y saber que tantos cambios mas conllevaría.

TheCloneMaster commented 3 years ago

Se cambió de esta forma para que la fecha sea la misma que lleva el consecutivo de la factura, y de esta forma tanto el consecutivo como la fecha concuerden. Si está dando problema, significa que ya el numérico de la factura va con fecha incorrecta, y esa es la parte que se debería corregir más bien.

Saludos, -Mario

On Thu, Jun 24, 2021 at 8:05 AM Eduardo Silva @.***> wrote:

En mi caso, trabajo con VPS en Uruguay y tengo varias instancias de Odoo para UY y CR simultáneamente en un solo server, de ahí puede que venga el problema para poder configurar correctamente. Pero creo que seria conveniente, para hacer que la fecha sea Explicita para CR y que no dependa de zonas horarias o configuraciones de servidores o base de datos.

El código actual es
            now_utc = datetime.datetime.now(pytz.timezone('UTC'))

            now_cr = now_utc.astimezone(pytz.timezone('America/Costa_Rica'))

            dia = inv.number_electronic[3:5]  # '%02d' % now_cr.day,

            mes = inv.number_electronic[5:7]  # '%02d' % now_cr.month,

            anno = inv.number_electronic[7:9]  # str(now_cr.year)[2:4],

            # date_cr = now_cr.strftime("%Y-%m-%dT%H:%M:%S-06:00")

            # date_cr = api_facturae.get_time_hacienda()

            date_cr = now_cr.strftime("20" + anno + "-" + mes + "-" + dia + "T%H:%M:%S-06:00")
Si observan, esta comentada la linea date_cr = now_cr.strftime("%Y-%m-%dT%H:%M:%S-06:00") que para mi es la que Explicitamente asigna date_cr con la fecha_hora actual de CR, que es la que tiene que tener la clave.

La linea date_cr = now_cr.strftime("20" + anno + "-" + mes + "-" + dia + "T%H:%M:%S-06:00") la veo muy "hardcodeada" y esta tomando valores desde inv.number_electronic que se genera en api_facturae.get_clave_hcienda()
'''Creamos la fecha para la clave'''

dia = str(doc.date_invoice.day).zfill(2)  # [8:10]#'%02d' % now_cr.day,

mes = str(doc.date_invoice.month).zfill(2)  # [5:7]#'%02d' % now_cr.month,

anno = str(doc.date_invoice.year)[2:]  # str(now_cr.year)[2:4],

cur_date = dia + mes + anno
que genera la parte de la fecha de la clave segun la fecha de la factura, que depende de la configuracion del sistema. Antes lo tenian con now_cr y lo comentaron...

Como reza la religión de los pythonistas.. mas vale Explicito que Implícito

Propongo que el bloque de código actual, se sustituya con:
            date_cr = api_facturae.get_time_hacienda()
También hay que modificar donde se genera la fecha de la clave en get_clave_hacienda y evaluar la incidencia de estos cambios en el resto del modulo.

Si ven que es posible lo pruebo con diferentes configuraciones y propongo el PR para que le hagan el merge, o si lo consideran incorrecto lo dejamos así.

Saludos y gracias por la atención.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/odoocr/l10n_cr/issues/243#issuecomment-867664386, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2XBFEY6BBKXVWBW74MR2DTUM3SFANCNFSM457NBIBA .

syscon3 commented 3 years ago

Estoy de acuerdo contigo Mario, ya el numérico se genera de esa manera, voy a verlo por ese lado. En cuanto lo que dices Keadanis, entiendo que lo veas como una personalización, pero en este caso como el modulo es totalmente localizado para CR, seria lógico explicitar la zona horaria en la creación de los numéricos.

Saludos Jorge.

EstebanMonge commented 2 years ago

Ponga la zona horaria en el usuario que genera las facturas, con eso ya funciona, eso se hace en el perfil de cada usuario.

odoocr / l10n_cr