|
Notes |
|
|
|
|
|
|
|
Localizer reply (In Spanish):
"Estuve tratando de replicar esto en nuestro ambiente local de localización y tuve que forzarlo, le puse vacío por BD a la columna "em_fet_pagado", cuando viene vacío el valor del campo, no aparece la línea en la impresión.
Sin embargo creo que esto es normal porque en dicho campo se coloca el importe cobrado de la factura que tiene esa línea del cobro y no tendría porque estar en nulo o vacío. En todo caso se podría poner en 0, que es como cobrar 0 pesos de una factura, pero aún así el SAT rebotaría el timbrado.
Por lo tanto creo que el problema es que ese campo no tiene porque estar vacío, y ese escenario no hemos logrado reproducirlo. Cada que se timbra un cobro, va y se escribe el valor en cada línea del cobro para dicha columna.
Si pudieran facilitarnos los pasos para poder reproducir el error, entonces si podríamos revisar porque motivo no se está colocando ese valor, no se si sea un caso aislado esto en cierto escenario específico. Si es un solo cobro que está timbrado y que sucede esto, yo recomendaría que mejor hagan uno nuevo a ver si pasa lo mismo. Si son varios, entonces creo que podrían ayudar el Partner a identificar un patrón y los pasos para reproducirlo.
Cualquier duda quedo a la orden.
Saludos! |
|
|
|
|
As you can see, Tegik can not reproduce the error.
Would it be possible for us to check whether:
- this has happened only once or not?
- will it be possible to have access to the enviroment where this error occurred?
thanks and regards,
Patricia. |
|
|
|
|
Hola Aldo,
Por favor os pedimos reapertura de este ticket de soporte ya que el issue no se ha solucionado.
Añadimos datos de acceso al entorno solicitado para que puedan realizar las pruebas convenientes:
Entorno TEST
https://www.imcp-test-cloud-mitmut.com/openbravo/security/Login [^]
User: Openbravo
Password: ImcpMit2019%
Quedamos a la espera.
Saludos,
Patricia. |
|
|
|
|
Respuesta del localizador:
Gracias por el acceso al servidor, entré a revisar y no quise realizar un cobro nuevo de prueba y timbrarlo porque no se si esté configurado el Pac de Pegaso para timbrar en Test, ¿podrían confirmarlo con el partner por favor?
Por otro lado entré a revisar los cobros timbrado y al imprimir las plantillas se ven sus líneas correctamente. Para aquellos cobros no timbrados no se ven sus líneas, pero esta es una funcionalidad de la plantilla porque así está diseñada.
Entiendo que el ticket originalmente era porque para los cobros timbrados no se veían sus líneas, ¿han podido reproducir esto? La última vez que se intentamos nosotros no se logró.
Saludos! |
|
|
|
|
In Spanish:
Efectivamente, el modulo de timbrado es el de pegaso, adjunto captura para que no haya dudas.
Pueden realizar las pruebas que crean convenientes y necesarias en el entorno brindado, el mismo es una instancia de test.
El problema que da orgigen a este issue es que una de las líneas (de 8 líneas) no se visualizaba en el impreso. Adjunto la imagen del registro y el imprimible de entonces, quizás al ver estos datos puede encontrar algo en particular referido a los mismos.
La primera línea que se visualiza en la captura es la faltante en el pdf, la que poseía el valor null que impedía la impresión de esta. (El campo que referencia a la columna EM_Fet_Pagado).
El partner reporta que no han logrado reproducir esto nuevamente, solo sucedió aquella vez y no tienen un nuevo reporte sobre este evento.
Hay algún modo de realizar un timbrado y luego añadir una nueva línea? Se me ocurre que pudiese ser un modo de que uno de los valores quedase en null, que de algún modo no pase por el proceso de timbrado cuando este se ejecuta. O evadiera algún tipo de línea configurada de alguna manera en particular, referidos a métodos de pagos o tipos de documentos. No poseo un conocimiento total del proceso que realiza el timbrado (en esta localización en particular) pero me ocuparé de revisar el mismo con quien corresponda para ver si podemos brindar más información respecto a esto que ayude a la resolución.
In English:
Correct, the module of Timbrado is the one of pegasus, attached capture so that there is no doubt.
You can perform the tests that you believe are convenient and necessary in the environment provided, it is a test instance.
The problem that gives rise to this issue is that one of the lines (8 lines in total) was not displayed on the form. I attach the image of the registry and the printable of that time, perhaps when you see this data you can find something in particular referring to them.
The first line that is displayed in the capture is the missing one in the pdf, which had the null value that prevented the printing of this. (The field that references the EM_Fet_Paid column).
The partner reports that they have not managed to reproduce this again, it only happened that time and they do not have a new report on this event.
Is there any way to perform a "Tibrado" and then add a new line? This could be a way for one of the values to remain null, there could be some way in which the "Timbrado" process ignores this line when executing, like some type of line configured in some particular way, referring to payment methods or types of documents. I do not have a total knowledge of the process performs (in this particular location), but I will review the same with whoever corresponds to see if we can provide more information about it to help with the resolution. |
|
|
|
(0114714)
|
|
psanjuan
|
2019-09-23 09:35
(edited on: 2019-09-23 09:36) |
|
Respuesta del localizador:
"Entramos en el entorno a revisar ese Cobro y se ven varias cosas que están incorrectas operativamente.
(1) El cobro no se va a poder timbrar ni es necesario, porque tiene facturas de la versión 3.2 y los complementos de pagos se comenzaron a utilizar a partir de la 3.3 y solo acepta facturas así. Comenzando por eso ya puede traer varios errores. Por otro lado, las facturas son del 2017, ya muy viejas.
(2) El módulo que tienen de timbrado en ese servidor es bastante viejo, el 2.8.120 y ahorita el más nuevo es el 2.8.146 por lo que se han aplicado varios fixes y mejoras por lo que deberían de actualizar. Aún actualizando no podrán timbrar ese cobro porque trae facturas incompatibles como mencioné en el punto anterior.
Por otro lado te comento que estando timbrado ya un cobro, no es posible añadirle líneas nuevas, es un candado que nosotros colocamos.
Si el cliente te comenta que no lo a vuelto a reproducir, y aún así lo hiciera, este proceso que está haciendo no es el correcto, por las facturas tan viejas.
Realmente debería volverse a revisar si estuviera ocurriendo con facturas 3.3 en transacciones de cobro.
Ahorita que no está timbrado el cobro se ven las 8 líneas, como quiera no lo podrán timbrar así que se verán esas 8 líneas.
Lo que si es que al actualizar el módulo, te comento que puede que no las vean, porque la plantilla solo está diseñada para mostrar las líneas de cobro timbrados. La funcionalidad del módulo de Factura Electrónica de nosotros no está diseñada para cobros no timbrados, puesto que solo abarcamos la funcionalidad de timbrado electrónico, para lo otro ellos tendrían que hacer alguna plantilla personalizada aparte.
|
|
|
|
|
Respuesta de Openbravo:
Hola Aldo,
Me gustaría resumir todo tu feedback en puntos más concretos, para ver si podemos sacar cual es el verdadero problema que se está reportando en este issue, y si hay algún tipo de resolución o workaround, es decir:
(1) ¿A que te refieres cuando dices que las facturas son de la versión 3.2? ¿versión de qué?
(2) ¿Qué es lo que hay que timbrar las facturas o el cobro de las facturas, o las dos cosas?
(3) ¿es necesario legalmente timbrar esas factura o el cobro de esas facturas? si la respuesta es NO, ¿Por que no hace falta ? entonces ¿cual es el problema? si la respuesta es SI ¿que puede hacer el cliente para timbrarlas?
(4) Esta claro que tienen que actualizar el módulo de factura electrónica (timbrado) a la versión 2.8.146
(5) ¿Por que el cliente no está haciendo un proceso correcto? ¿Te refieres a que está intentando timbrar unas facturas de 2017 que no debería timbrarse?
(5) ¿Si actualizan el módulo ¿qué es exactamente lo que no van a ver y dónde? ¿Por qué?.
Esperamos vuestras noticias.
Saludos y gracias,
Patricia. |
|
|
|
|
Localizer answers:
1. Me refiero a la versión de XML de la Factura Electrónica que maneja el SAT (el servicio de hacienda en nuestro país) cuando recién salió la factura electrónica, manejaba un formato de XML que ellos lo bautizaron como el 3.2 y después el 01 de Enero del 2018 ya comenzó a usarse de manera obligatoria una versión nueva llamada 3.3. Había cambios en el formato XML y catálogos nuevos, entre otras cosas, cambios importantes. De esta manera ya nadie podría usar facturas 3.2, solo 3.3.
2. Las dos cosas se pueden timbrar, tanto facturas como cobros. Sin embargo lo del timbrado de cobros, que le llaman Complemento de Pago o REP, comenzó a hacerse obligatorio a partir del 01 de Septiembre del 2018 y solamente sería válido agregar a estos complementos de pago, facturas de la versión 3.3 del CFDI, las que fueron versión 3.2 no es necesario timbrar su complemento de pago (cobro). Esto es lo que está pasando en el ticket del cliente, todas las facturas son versión 3.2.
3. No es necesario timbrar el cobro de esas facturas porque son versión 3.2. Las facturas, si están timbradas, estarán con la versión 3.2 por la fecha que tienen y de hecho aparecen esa leyenda en uno de los campos de las factura, dice 3.2 si se meten a ellas.
4. De acuerdo que se actualice el módulo.
5. El cliente no está haciendo un proceso correcto porque como comentaba anteriormente, no es necesario y no se puede, emitir un complemento de pago y timbrarlo, si este contiene facturas 3.2, todas deben de ser 3.3.
6. Al actualizar el módulo van a tener mejoras de bugs y lo que dejarían de ver serían las líneas de los cobros en la impresión, siempre y cuando no estén timbrados. Esto porque así está el diseño de la impresión, nuestro módulo abarca la funcionalidad de cobros timbrados, no de los cobros que no estén timbrados, eso ya sería necesario un template aparte.
Con todo lo dicho anteriormente, espero que sea más claro todo y al final no es necesario timbrar un cobro con dichas facturas, el SAT no lo aceptará porque son facturas viejas con la versión 3.2 del CFDI. |
|
|
|
|
|
Issue resuelto en función de la contestación del localizador. |
|
Selección_387.png (273,613) 2019-07-02 23:44