Openbravo Issue Tracking System - Openbravo Localizations |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0029632 | Openbravo Localizations | Localization Mexico | public | 2015-04-20 09:36 | 2015-07-21 10:45 |
|
| Reporter | psanjuan | |
| Assigned To | tegik_forge | |
| Priority | immediate | Severity | critical | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | | OS | 20 | OS Version | Ubuntu 8.04.1 |
| Product Version | | |
| Target Version | | Fixed in Version | | |
| Merge Request Status | |
| Regression date | |
| Regression introduced by commit | |
| Regression level | |
| Support ticket | |
| OBNetwork customer | No |
| Regression introduced in release | |
|
| Summary | 0029632: Error found in "Adaptación WebPOS para factura electrónica" module |
| Description | Error found in "Adaptación WebPOS para factura electrónica" module.
In Spanish:
El error está en la llamada a la clase
com.tegik.facelectr.ad_actionButton.facturaElectronica
desde la clase HookTimbradoCashUp.
El problema es debido a que en la clase facturaElectronica, se realiza la orden
OBDal.getInstance().commitAndClose();
Esto puede ser correcto en un proceso independiente pero no es correcto que en un hook se realice esta acción ya además de poder crear problemas de session de DAL, esta llamada rompe la transaccionalidad.
Puede ocurrir que se de un error una vez realizado el commitandclose y que el proceso cashup no termine pero las accciones realizadas en base de datos antes del commit se persisitiran. En el caso de que se produzca un error todas las acciones deberían de deshacerse y esto se podria hacer si no se hiciese el commit.
|
| Steps To Reproduce | n/a |
| Proposed Solution | In Spanish:
Solicitamos revisen el desarrollo para evitar utilizar dicho metodo.
Una opción sería que el servlet facturaElectronica no realizase todas las acciones en la propia clase, sino que llamase a otra clase en la que propiamente se hiciese la facturación electronica.
Esta otra clase no realizaria el close y commit y se podria llamar desde el hook, y el servlet sería el que tras usar la nueva clase de facturación hiciese el commit.
El servlet no sería invocado desde el hook sino unicamente la nueva clase.
|
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | design defect | 0029611 | | acknowledged | Triage Platform Base | Openbravo ERP | The way we disable triggers with TriggerHandler may lead to leaving the triggers disabled indefinitly |
|
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2015-04-20 09:36 | psanjuan | New Issue | |
| 2015-04-20 09:36 | psanjuan | Assigned To | => tegik_forge |
| 2015-04-20 09:36 | psanjuan | OBNetwork customer | => No |
| 2015-04-20 21:03 | tegik_forge | Note Added: 0076639 | |
| 2015-04-22 09:32 | psanjuan | Note Added: 0076672 | |
| 2015-04-22 09:34 | psanjuan | Status | new => scheduled |
| 2015-04-22 09:34 | psanjuan | Resolution | open => fixed |
| 2015-04-22 09:34 | psanjuan | Fixed in SCM revision | => see note |
| 2015-04-22 09:34 | psanjuan | Status | scheduled => resolved |
| 2015-04-22 09:35 | psanjuan | Status | resolved => closed |
| 2015-05-15 13:50 | egoitz | Note Added: 0077492 | |
| 2015-05-15 13:50 | egoitz | Status | closed => new |
| 2015-05-15 13:50 | egoitz | Resolution | fixed => open |
| 2015-05-15 14:05 | ngarcia | Issue Monitored: ngarcia | |
| 2015-05-15 14:17 | ngarcia | Relationship added | related to 0029611 |
| 2015-05-15 15:10 | tegik_forge | Note Added: 0077496 | |
| 2015-05-18 09:09 | psanjuan | Note Edited: 0077496 | bug_revision_view_page.php?bugnote_id=0077496#r8560 |
| 2015-06-02 16:46 | egoitz | Note Added: 0077992 | |
| 2015-06-02 19:23 | ngarcia | Priority | urgent => immediate |
| 2015-06-02 19:23 | ngarcia | Severity | major => critical |
| 2015-07-21 10:45 | egoitz | Note Added: 0078989 | |
| 2015-07-21 10:45 | egoitz | Status | new => closed |
| 2015-07-21 10:45 | egoitz | Resolution | open => fixed |
|
Notes |
|
|
|
Hola
En la versión 2.6.3 ya ha sido removida esa instrucción.
Saludos |
|
|
|
|
Feedback de Tegik sobre la resolución de este issue:
La clase HookTimbradoCashUp pertenece a Adaptación WebPOS Factura Electrónica, esta clase esta timbrado la factura llamando la clase com.tegik.facelectr.ad_actionButton.facturaElectronica que pertenece a Electronic Invoice Mexico.
El error está en la llamada de la clase java com.tegik.facelectr.ad_actionButton.facturaElectronica.
Esta clase pertenece a la factura electrónica y lo que se nos está indicando en el ticket es que el bug se encuentra en la instrucción OBDal.getInstance().commitAndClose();
Lo que se ha hecho fue remover esa instrucción de factura electrónica para que HookTimbradoCashUp no tenga el mismo bug. |
|
|
|
(0077492)
|
|
egoitz
|
|
2015-05-15 13:50
|
|
|
reopened becuase the bug still exists |
|
|
|
(0077496)
|
|
tegik_forge
|
2015-05-15 15:10
(edited on: 2015-05-18 09:09) |
|
Hola
removí muchas instrucciones commitAndClose(), pero hubo en especial una linea donde se la movia, dejaba de funcionar correctamente la factura electrónica.
Te explico:
Una vez cuando se llama el servicio web del proveedor de sellado de factura, se llenan varios campos la tabla de factura. Las instrucciones son las siguientes:
factura.setFetSellosat(getValuefromXML(archivoTimbradoNuevo, "selloSAT"));
factura.setFetCertificadoSat(getValuefromXML(archivoTimbradoNuevo,"noCertificadoSAT"));
factura.setFetFoliofiscal(getValuefromXML(archivoTimbradoNuevo, "UUID"));
Despues de llenar estas instrucciones, se hace un save, flush y el commitAndClose.
Después generamos el PDF y tomamos los campos FoliosFiscal, CertificadoSat y Sellosat ya que es información que necesita el cliente en el PDF. Cuando se genera el PDF, nos encargamos de enviar el PDF creado a un correo electrónico.
Hace poco quite todas las instrucciones de commitAndClose como se me indico en este ticket, pero recibí dos llamadas de clientes que estaban recibiendo sus PDF en blanco en los campos FoliosFiscal, CertificadoSat y Sellosat. Estuve debugeando y colocando las instrucciones save, flush y refresh y ninguna de estas instrucciones solucionaba el error que me había reportado los dos clientes. Volví a colocar las instrucciones de commitAndClose y me permitió enviar correctamente el PDF.
Actualmente solamente hay una instruccion de commitAndClose en la clase facturaElectronica.java, pero esta instrucciones es la solución para crear y enviar correctamente el PDF.
¿Cual soluciones nos pueden proponer para quitar esta instrucción de la clase?
|
|
|
|
(0077992)
|
|
egoitz
|
|
2015-06-02 16:46
|
|
Buenas,
Un flush debería de bastar para evitar hacer el commit ya que al usar la misma conexion cualquier cambios ya estaría disponible dentro de esa conexion.
si es necesario un commit es posible que en las siguientes acciones tras el commit se esté usando una conexion distinta a la de DAL.
Debugee todo el proceso y compruebe si más adelante se abre alguna nueva conexion de base de datos.
En caso contrario debería de ser suficiente el flush. |
|
|
|
(0078989)
|
|
egoitz
|
|
2015-07-21 10:45
|
|
|