Openbravo Issue Tracking System - Localization Pack: Spain |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0039852 | Localization Pack: Spain | SII Retail | public | 2018-12-26 14:43 | 2019-07-12 14:57 |
|
Reporter | psanjuan | |
Assigned To | nonofrancisco | |
Priority | urgent | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | |
Platform | | OS | 30 | OS Version | Openbravo Appliance 14.04 |
Product Version | | |
Target Version | | Fixed in Version | | |
Merge Request Status | |
Regression date | |
Regression introduced by commit | |
Regression level | |
Review Assigned To | |
Support ticket | |
OBNetwork customer | |
Regression introduced in release | |
|
Summary | 0039852: "Operation date" field empty in POS invoices |
Description | "Operation date" field empty in POS invoices |
Steps To Reproduce | In an enviroment with Openbravo for Retail install SII module.
In Openbravo backoffice configure the Organization (Legal Entity) to be subject to SII as described below:
- Navigate to SII configuration and set as Yes the field In SII system. To properly do that it is required to enter a valid electronic certificate path or hack the system no to validate that.
Besides this configure the corresponding channel touchtpoint type of VBS-1 terminal as Generate invoice for orders = Yes.
(Regardless same behaviour should apply in case cash up process is the one that creates the invoice, or OB Web POS function "Invoice this Receipt" is the one that creates the corresponding invoice).
Go to Openbravo Web POS and create a new sale for Arturo Montoro by selecting any product. Make sure that Invoice check is selected. Complete and pay the sale.
In Openbravo backoffice, go to sales invoice window and search by the invoice just created.
Verify it is created there with "Invoice" value in the field "Invoice type Key", but with no information in the field "Operation date". |
Proposed Solution | Sales Invoice operation date should be the "Order" (sales receipt) Date.
Return Invoice operation date should be the "Order" (original sales receipt) Date, not the date of the return from customer sale.
If more than one order (sales receipt) are include in a return invoice, return invoice "operation date" in the header should be last one (fecha más reciente).
In Spanish
2.13. ¿Qué fecha de operación debe hacerse constar en una factura rectificativa?
La fecha de realización de la operación correspondiente a la factura original que se
está rectificando.
2.14. ¿Qué fecha de operación debe constar en una factura rectificativa si se
rectifican varias facturas mediante un único documento de rectificación?
Se consignará el último día en el que se haya efectuado
|
Additional Information | |
Tags | No tags attached. |
Relationships | has duplicate | defect | 0040884 | | closed | psanjuan | The field "Fecha de Operación" is not being filled in the backoffice |
|
Attached Files | Issue_39852.jpg (74,133) 2019-06-20 12:50 https://issues.openbravo.com/file_download.php?file_id=13028&type=bug
|
|
Issue History |
Date Modified | Username | Field | Change |
2018-12-26 14:43 | psanjuan | New Issue | |
2018-12-26 14:43 | psanjuan | Assigned To | => Opentix-Test |
2018-12-26 14:46 | ngarcia | Issue Monitored: ngarcia | |
2019-03-15 11:27 | psanjuan | Note Added: 0110451 | |
2019-03-15 11:27 | psanjuan | Status | new => acknowledged |
2019-03-15 11:29 | psanjuan | Note Added: 0110452 | |
2019-03-15 11:30 | psanjuan | Note Edited: 0110452 | bug_revision_view_page.php?bugnote_id=0110452#r18476 |
2019-03-15 11:33 | psanjuan | Note Added: 0110453 | |
2019-06-07 11:56 | psanjuan | Resolution time | => 1561672800 |
2019-06-07 11:56 | psanjuan | Assigned To | Opentix-Test => Triage Finance |
2019-06-07 12:01 | psanjuan | Summary | "Fecha Operación" field empty for POS invoices. => "Fecha Operación" field empty for POS invoices. (to be translated to English) |
2019-06-19 14:06 | psanjuan | Summary | "Fecha Operación" field empty for POS invoices. (to be translated to English) => "Fecha Operación" field empty for POS invoices |
2019-06-19 14:06 | psanjuan | Description Updated | bug_revision_view_page.php?rev_id=18959#r18959 |
2019-06-19 14:06 | psanjuan | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=18961#r18961 |
2019-06-19 14:07 | psanjuan | Note Added: 0112891 | |
2019-06-20 12:41 | psanjuan | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=18966#r18966 |
2019-06-20 12:45 | psanjuan | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=18967#r18967 |
2019-06-20 12:49 | psanjuan | Summary | "Fecha Operación" field empty for POS invoices => "Operation date" field empty in POS invoices |
2019-06-20 12:49 | psanjuan | Description Updated | bug_revision_view_page.php?rev_id=18968#r18968 |
2019-06-20 12:49 | psanjuan | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=18969#r18969 |
2019-06-20 12:49 | psanjuan | Proposed Solution updated | |
2019-06-20 12:50 | psanjuan | File Added: Issue_39852.jpg | |
2019-06-20 13:08 | Sandrahuguet | Assigned To | Triage Finance => nonofrancisco |
2019-06-20 13:09 | psanjuan | Category | SII => SII Retail |
2019-06-20 13:09 | psanjuan | Note Added: 0112912 | |
2019-06-26 16:14 | nonofrancisco | Status | acknowledged => scheduled |
2019-06-27 17:28 | nonofrancisco | Note Added: 0113071 | |
2019-07-01 09:47 | Sandrahuguet | Resolution time | 1561672800 => 1562796000 |
2019-07-05 10:14 | psanjuan | Note Added: 0113192 | |
2019-07-05 10:20 | psanjuan | Note Edited: 0113192 | bug_revision_view_page.php?bugnote_id=0113192#r19039 |
2019-07-05 10:21 | psanjuan | Note Added: 0113193 | |
2019-07-05 10:22 | psanjuan | Note Edited: 0113193 | bug_revision_view_page.php?bugnote_id=0113193#r19041 |
2019-07-05 10:26 | psanjuan | Note Edited: 0113193 | bug_revision_view_page.php?bugnote_id=0113193#r19042 |
2019-07-05 10:28 | psanjuan | Note Added: 0113194 | |
2019-07-05 10:31 | psanjuan | Note Edited: 0113071 | bug_revision_view_page.php?bugnote_id=0113071#r19044 |
2019-07-05 10:31 | psanjuan | Note Edited: 0113193 | bug_revision_view_page.php?bugnote_id=0113193#r19045 |
2019-07-05 10:33 | psanjuan | Note Edited: 0113194 | bug_revision_view_page.php?bugnote_id=0113194#r19047 |
2019-07-05 11:19 | psanjuan | Note Edited: 0113192 | bug_revision_view_page.php?bugnote_id=0113192#r19048 |
2019-07-05 11:32 | psanjuan | Proposed Solution updated | |
2019-07-09 10:56 | psanjuan | Proposed Solution updated | |
2019-07-09 11:06 | psanjuan | Proposed Solution updated | |
2019-07-11 09:30 | psanjuan | Note Edited: 0113071 | bug_revision_view_page.php?bugnote_id=0113071#r19079 |
2019-07-11 09:34 | psanjuan | Note Edited: 0113192 | bug_revision_view_page.php?bugnote_id=0113192#r19080 |
2019-07-11 09:35 | psanjuan | Note Edited: 0113071 | bug_revision_view_page.php?bugnote_id=0113071#r19081 |
2019-07-11 09:38 | psanjuan | Note Edited: 0113192 | bug_revision_view_page.php?bugnote_id=0113192#r19082 |
2019-07-11 09:59 | psanjuan | Note Edited: 0113193 | bug_revision_view_page.php?bugnote_id=0113193#r19085 |
2019-07-11 10:11 | psanjuan | Note Edited: 0113194 | bug_revision_view_page.php?bugnote_id=0113194#r19086 |
2019-07-11 12:15 | psanjuan | Note Edited: 0113194 | bug_revision_view_page.php?bugnote_id=0113194#r19097 |
2019-07-11 12:16 | psanjuan | Note Edited: 0113193 | bug_revision_view_page.php?bugnote_id=0113193#r19098 |
2019-07-11 12:17 | psanjuan | Note Edited: 0113194 | bug_revision_view_page.php?bugnote_id=0113194#r19099 |
2019-07-11 12:19 | psanjuan | Note Added: 0113270 | |
2019-07-11 12:20 | psanjuan | Note Edited: 0113193 | bug_revision_view_page.php?bugnote_id=0113193#r19100 |
2019-07-12 13:54 | psanjuan | Note Edited: 0113192 | bug_revision_view_page.php?bugnote_id=0113192#r19120 |
2019-07-12 14:01 | psanjuan | Note Edited: 0113194 | bug_revision_view_page.php?bugnote_id=0113194#r19121 |
2019-07-12 14:03 | psanjuan | Note Edited: 0113194 | bug_revision_view_page.php?bugnote_id=0113194#r19122 |
2019-07-12 14:06 | psanjuan | Note Edited: 0113194 | bug_revision_view_page.php?bugnote_id=0113194#r19123 |
2019-07-12 14:07 | psanjuan | Note Edited: 0113194 | bug_revision_view_page.php?bugnote_id=0113194#r19124 |
2019-07-12 14:31 | hgbot | Checkin | |
2019-07-12 14:31 | hgbot | Note Added: 0113334 | |
2019-07-12 14:31 | hgbot | Status | scheduled => resolved |
2019-07-12 14:31 | hgbot | Resolution | open => fixed |
2019-07-12 14:31 | hgbot | Fixed in SCM revision | => http://code.openbravo.com/erp/pmods/org.openbravo.module.sii.retail/rev/19aa2a13498c37ddb106adcbce084b3e3990dd83 [^] |
2019-07-12 14:57 | psanjuan | Note Edited: 0113270 | bug_revision_view_page.php?bugnote_id=0113270#r19129 |
2019-07-12 14:57 | psanjuan | Note Added: 0113338 | |
2019-07-12 14:57 | psanjuan | Status | resolved => closed |
2019-07-16 11:20 | psanjuan | Relationship added | has duplicate 0040884 |
Notes |
|
|
con fecha 27/12/2018 se analiza esto:
He estado haciendo pruebas en una máquina local de un cliente que tenemos con POS.
Depurando el trigger AEATSII_INVOICE_TRG he podido comprobar que nunca entra ni en la parte de INSERT ni en la de UPDATE.
Antes de la comprobación de si se trata de un INSERT o un UPDATE está la siguiente comprobación que es donde se detiene el flujo:
IF AD_isTriggerEnabled()='N' THEN
IF TG_OP = 'DELETE' THEN
RETURN OLD;
ELSE
RETURN NEW;
END IF;
END IF;
Entiendo que ese condicional lo que comprueba es si el trigger no está habilitado, lo que me da que pensar que el POS, antes de crear una factura, deshabilita los triggers y los vuelve a habilitar una vez creada.
He hecho pruebas quitando ese condicional y de ese modo sí entra tanto en el INSERT como en el UPDATE, por lo que como solución a la incidencia reportada por Qualitic voy a quitar dicho condicional.
Por otro lado, me he dado cuenta que la lógica para asignar los campos de SII automáticamente sólo funciona en caso de tener configurado el POS para generar una factura por cada pedido, pero no funciona en el caso de tener una factura al hacer el cierre de caja que agrupe todos los pedidos. Por este motivo he incorporado una lógica nueva para tener en cuenta este tipo de facturas. |
|
|
(0110452)
|
psanjuan
|
2019-03-15 11:29
(edited on: 2019-03-15 11:30) |
|
Se envia obx al cliente que reproduce este problema por no facturar directamente las facturas del POS, si no agrupadas.
|
|
|
|
|
|
|
In Spanish:
Durante la venta desde el POS (ya sea facturando un pedido concreto o al cierre de caja) la factura creada en el BackOffice solo tiene relleno automáticamente el campo tipo de factura relacionado con el SII y el campo "Fecha operación" queda vacio.
Extrañamente, cuando se crea una factura tanto de venta como de compra desde el BackOffice, el campo "Fecha operación" si se rellena correctamente.
Para comprobar si el problema era de la transición automática de pedido a factura, colocamos un valor por defecto a "Fecha operación" para los pedidos, pero una vez mas se rellenaba bien desde el BackOffice, quedando en blanco desde el POS.
Parece como si el valor por defecto no estuviera siendo tenido en cuenta cuando la generación de las entidades ocurre desde el POS.
Hemos hecho todo tipo de pruebas y revisado múltiples veces la configuración, pero aparentemente, no hay nada incorrecto.
Para nuestro cliente, que genera cientos de facturas desde el POS cada día, es importante que este proceso sea automatizado y funcione adecuadamente.
Adjunto una captura de pantalla de los módulos SII instalados en el sistema, así como capturas de pantalla de las facturas que se crean en el BackOffice desde el POS.
Si necesitan mas detalles, por favor, no duden en solicitárnoslos.
Dada la cercanía de la entrada en vigor del SII en Canarias, agradeceremos cualquier ayuda que puedan prestarnos. |
|
|
|
|
|
(0113071)
|
nonofrancisco
|
2019-06-27 17:28
(edited on: 2019-07-11 09:35) |
|
Test Case 1 - Direct and Complete Invoice
In an enviroment with Openbravo for Retail install SII module.
As Openbravo/The White Valley Group Admin
Navigate to SII configuration window
Create a new record
Organization: The White Valley Spain S.A
In SII system: checked
To properly do that it is required to enter a valid electronic certificate path or hack the system no to validate that.
Go to Channel Touchpoint Type window
Edit VBS POS Terminal Type
Set Generate invoice for orders = Yes.
Go to Openbravo Web POS and create a new sale for Arturo Montoro by selecting any product.
Make sure that Invoice check is selected. Complete and pay the sale.
In Openbravo backoffice, go to sales invoice window and search by the invoice just created.
Verify it is created there with "Invoice" value in the field "Invoice type Key", and a date in the field "Operation date", that is "Current Date".
|
|
|
(0113192)
|
psanjuan
|
2019-07-05 10:14
(edited on: 2019-07-12 13:54) |
|
Test Case 2 - Direct and complete corrective invoice (s)
In Openbravo Web POS select the sale just book by using the option "Verified Returns". Return all the products and press apply.
Complete and pay the return sale.
Go to Openbravo backoffice, search by the return sales invoice just created and verify it does have an operation date = current date (sales order date).
Verify that the Invoice Type Key = Corrective Invoice.
Repeat the same scenario to return more that one sale with a diferent order date (different than current one), as described below:
Select Verified Return option. Apply the filter.
Select two or more sales with a diferent order date, for instance order 231 dated on July 5th, and order 239 dated on July 9th (current date is July 11th).
Select them, and return all products. Complete and pay.
Go to backoffice and search by the return sales invoice just created.
Verify that the operation date shown in that return sales invoice is July 9th, 2019
In POS select two receipts, one having a date of 11/07 (current date is 12/07)
, and other 16/05 by using Verfied Return options.
Complete and pay the return.
Go to Openbravo backoffice and search by the return sale just created.
Verify its operation date = 11/07
|
|
|
(0113193)
|
psanjuan
|
2019-07-05 10:21
(edited on: 2019-07-11 12:20) |
|
Test Case 3 - Direct and Simplified invoices (cash up)
In openbravo backoffice, search by the channeltouch point used and navigate to the channel touchpoint type. Configure it as described below:
Configure it as "Generate Invoice for Orders" = No
Group orders in one invoice = No
Go to Openbravo web POS and create a sale for an anonymous customer. Complete and Pay the sale.
Create another sale for Arturo Montoro and use the option "Invoice this receipt". Complete and pay the sale.
Run cash up process.
Go to Openbravo backoffice, search by the sales invoices just created and verify that the one of identified customer (Arturo Montoro) has
Operation date = current date (sales order date).
Invoice type key = Invoice
verify that the one of anonymous customer has
Operation date = current date (sales order date).
Invoice type key = Simplified Invoice.
|
|
|
(0113194)
|
psanjuan
|
2019-07-05 10:28
(edited on: 2019-07-12 14:07) |
|
Test Case 4 - Return Direct and Simplified invoices (cash up).
4.1 In Openbravo web POS create a return sale for the anonymous customer, by using the option "Verified Returns". Select for instance an order dated on July 11th (current date is July 12th)
Complete and pay the return sales.
Run the cash up
Go to openbravo backoffice and search by the return sales invoice just created. Verify it is created as Simplified Invoice and its operation date is July 11th.
4.2 In Openbravo web POS create a return sale for the anonymous customer, by using the option "Verified Returns". Select for instance an order dated on July 5th (current date is July 12th). Use the option invoice this receipt.
Complete and pay the return sales.
Go to openbravo backoffice and search by the return sales invoice just created. Verify it is created as Simplified Invoice and its operation date is July 5th.
4.3 Select now two receipts in the same return, one dated on 20/03 and the other one dated on 13/05. Complete and Pay. Run cahs up process.
Verify that the operation date of the return invoice just created is the last one, that is 13/05
4.4 Repeat same test as above but this time using Invoice this receipt. Verify that the operation date is the last one choosen before.
|
|
|
(0113270)
|
psanjuan
|
2019-07-11 12:19
(edited on: 2019-07-12 14:57) |
|
Test Case 5 - Aggregated sales and returns.
In Openbravo backoffice, search by the channeltouch point used and navigate to the channel touchpoint type. Configure it as described below:
Group orders in one inovice = Yes
Separate Invoice for returns = No (as it seems this is not working, return sales invocies are not created).
5.1 In POS create two sales for the anonymous customer and two more for Arturo Montoro.
Run cash up.
Go to Openbravo backoffice, search by the two invoices just created and verify that both have as operation date, current date, that is July 12th.
5.2 In POS create a return sale for any customer by selecting two receipts dated on a different date, ie. 05/07 and 20/06 (use Verified return feature). Complete and pay the return sales.
Run cash up.
Go to Openbravo backoffice, search by the return sales just created and verify that the operation date of the invoice is the last one that is 20/06
|
|
|
(0113334)
|
hgbot
|
2019-07-12 14:31
|
|
Repository: erp/pmods/org.openbravo.module.sii.retail
Changeset: 19aa2a13498c37ddb106adcbce084b3e3990dd83
Author: Sandra Huguet <sandra.huguet <at> openbravo.com>
Date: Fri Jul 12 14:30:38 2019 +0200
URL: http://code.openbravo.com/erp/pmods/org.openbravo.module.sii.retail/rev/19aa2a13498c37ddb106adcbce084b3e3990dd83 [^]
Fixes issue 39852: Sets OperationDate in SII hooks
OperationDate field on Invoice entity is set in a trigger during invoice
creation.
---
M src/org/openbravo/module/sii/retail/hook/SIIFinishInvoiceHook.java
M src/org/openbravo/module/sii/retail/hook/SIIOrderLoaderHook.java
---
|
|
|
|
Verified and working.
Issue closed. |
|