[15.0][ADD] l10n_es_pos_sii: envío de pos.order al SII #3088
Conversation
|
Hi @pedrobaeza, |
|
He hecho una prueba y el certificado que había no era válido. Poniendo otro de prueba y configurando he conseguido realizar un envío correcto, pero para que se envíe he tenido que ir a la orden y enviarla manualmente. No se ha enviado al validar la orden del POS. Éste es el resultado tras el envío manual |
zamberjo
force-pushed
the
15.0-pos-sii-by-order
branch
2 times, most recently
from
24bd3aa
to
14e1d51
Compare
En poder revisamos/implementamos los abonos, el envío automático al cerrar sesión, y creo que podríamos darlo como funcional de momento. |
zamberjo
force-pushed
the
15.0-pos-sii-by-order
branch
from
5aad5c5
to
3d7ff0a
Compare
|
Nos ha surgido una duda durante el desarrollo de los test. |
zamberjo
force-pushed
the
15.0-pos-sii-by-order
branch
from
3d7ff0a
to
2548447
Compare
zamberjo
force-pushed
the
15.0-pos-sii-by-order
branch
3 times, most recently
from
5db02c3
to
90ba078
Compare
A falta de lo que ha comentado mi compañera @almumu ya se podría revisar. |
|
@almumu Odoo con l10n_es_pos muestra el cliente seleccionado en las facturas simplificadas, esta factura simplificada se conoce como nominativa y el cliente puede deducírsela siempre y cuando lleve el desglose de impuestos también, que también lo lleva con el l10n_es_pos, entonces, en mi opinión habría que enviar el cliente en estos casos, sólo poner el cliente por defecto en el caso de que no haya cliente ya en la factura simplificada, que es lo que se haría con el pos_default_partner. Parece que ya lo tenéis así contemplado en "_sii_get_partner" Muy buen aporte, gracias |
|
Sólo por puntualizar, creo que @omar7r se refiere a las facturas simiplificadas cualificadas:
Estas deben remitirse al SII como factura completa F1. Por lo tanto, en las facturas simplificadas F2 del TPV no sería necesario identificar al cliente en ningún caso. Saludos, |
|
Hola Como se indica en la AEAT, se puede crear una factura simplificada con datos del cliente y este podría deducirla: https://sede.agenciatributaria.gob.es/Sede/ayuda/manuales-videos-folletos/manuales-practicos/folleto-actividades-economicas/5-impuesto-sobre-valor-anadido/5_9-facturas/5_9_6-facturas-simplificadas.html#:~:text=Las%20facturas%20simplificadas%2C%20contendr%C3%A1n%20con%20car%C3%A1cter%20general%2C%20los,impositivo%20y%2C%20opcionalmente%20tambi%C3%A9n%20la%20expresi%C3%B3n%20%E2%80%9CIVA%20incluido%E2%80%9D. Cito: Tiene la misma validez que una factura normal entonces en el caso de tener cliente se podría emitir F1 desde el TPV. |
|
Hola, Efectivamente, pero vamos a pensar mejor, que otra vez (error del pasado) estamos pensando sólo en el SII. Hay que hacer que se reporte exactamente lo mismo en el Libro de IVA sin duplicar la lógica y la programación.
Nota: no daré por hecho nque todos entendemos que da igual el formato del papel en este asunto, una factura simplificada se puede imprimir en un A4 y una factura ordinaria en un papel de rollo. Explicación de por qué debemos modelar esto en el
|
| Obligación | Libro de IVA | SII |
|---|---|---|
| F. Simplificada sin cliente | F2 | F2 |
| F. Simplificada con cliente/NIF | F1 | F1 |
Reflexiones:
- (a) Cualquier cliente de Odoo con
l10n_es_posya debe de informar el asiento contable de la factura simplificada (pos.ticket) como Factura tipo F1, F2, o lo que proceda para el libros de IVA y por lo tanto dicha información no la debe de generar ell10n_es_pos_sii. - (b) Cualquier comercio debe poder imprimir una factura normal desde una impresora de rollo tipo Epson y no obligar a tener una impresora A4 (ver imagen de Factura ordinaria de IKEA debajo)
Referencias:
- Artículo 7. Contenido de las facturas simplificadas del Reglamento obligaciones de facturación (link BOE)
- 5.9.6 Facturas simplificadas (link AEAT)
Imagen 1:
Estoy disponible para un Google Meet siempre que lo queráis 😄
Mil gracias por todo y el esfuerzo ❤️ 🙏🏼
|
@acysos @HaraldPanten , aquí se está haciendo un esfuerzo de tiempos y económico importante creo que AEODOO debería organizar para ver si sumamos más contribuidores. Yo tengo un sólo PdV pequeño, no lo puedo asumir. Pero entiendo que @zamberjo lo necesitan con cierta urgencia y lo malo es que una vez hecho.. cambiar la implementación es complicado. |
|
Hola, Centrándome en el SII dentro del TPV que es el objetivo de la tarea: 1. Tipos de factura:
Partiendo de la premisa de que no podemos contemplar a todos los clientes que tengan NIF en su ficha como F1, ya que tendríamos multitud de errores como estos:
2. Dentro del LIVA:Este informe lee los apuntes contables. En el asiento resumen de simplificadas del POS no se completa nunca el cliente y por ello da error. Copio y pego imagen reportada en #3058 (comment):
3. Propuesta de solución:
Seguro que existen otras propuestas de solución, esta es la que me ha parecido más sencilla y menos problemática. De todas formas, estoy abierta a mantener un meet para verlo más en detalle si es necesario. Gracias a tod@s |
|
Hola, nosotros no tenemos demasiada prisa con esto pero si nos gustaría saber que rumbo tomar con este PR por no perder el trabajo hecho... Podemos hacer un meet si se considera necesario o si se organiza un grupo de trabajo desde AEODOO podemos colaborar si es que hay que replantear el desarrollo. |
| @api.model | ||
| def _get_sii_taxes_map(self, codes, date): | ||
| """Return the codes that correspond to that sii map line codes. | ||
|
|
||
| :param codes: List of code strings to get the mapping. | ||
| :param date: Date to map | ||
| :return: Recordset with the corresponding codes | ||
| """ | ||
| map_obj = self.env["aeat.sii.map"].sudo() | ||
| sii_map = map_obj.search( | ||
| [ | ||
| "|", | ||
| ("date_from", "<=", date), | ||
| ("date_from", "=", False), | ||
| "|", | ||
| ("date_to", ">=", date), | ||
| ("date_to", "=", False), | ||
| ], | ||
| limit=1, | ||
| ) | ||
| tax_templates = sii_map.map_lines.filtered(lambda x: x.code in codes).taxes | ||
| return self.company_id.get_taxes_from_templates(tax_templates) |
There was a problem hiding this comment.
Cambiaría la lógica de éste método. En mi opinión debería llamarse a un método en aeat.sii.map para que te devuelva las plantillas de impuestos, de este modo solo se buscaría una vez el registro del mapeo del SII aeat.sii.map en las llamadas a éste método.
# sii.mixin
def _get_aeat_sii_map
# aeat.sii.map
def _get_sii_taxes_map
# sii.mixin
def _get_sii_out_taxes(self):
aeat_sii_map = self._get_aeat_sii_map(self.date)
taxes_sfesb = aeat_sii_map._get_sii_taxes_map(["SFESB"])
...Además, tal y como está el método con el decorador @api.model, no tenemos acceso a self.company_id, el acceso debería hacerse con self.env["res.company"] para evitar confusiones.
| amount_to_balance=amount_to_balance, | ||
| bank_payment_method_diffs=bank_payment_method_diffs, | ||
| ) | ||
| self.order_ids.send_sii() |
There was a problem hiding this comment.
Entiendo que habría que coger únicamente los pedidos sin factura, ¿no?
There was a problem hiding this comment.
hay un método: _get_valid_document_states que obtiene los estados en los que debe enviarase al sii, y en el caso del pos, llama a SII_VALID_POS_ORDER_STATES, donde únicamente está el estado 'done'. Los facturados están en estado invoiced, por tanto no se enviarían
There was a problem hiding this comment.
Revisión funcional LGTM.
Tras varias pruebas, los pedidos de simplificadas se envían bien al SII mientras que los pedidos de facturas completas no se envían, la comunicación al SII en este caso se hace desde la factura (account.move).
Un pedido de simplificada no puede convertirse en factura completa cuando la sesión sí fue cerrada:
Mientras que un pedido de simplificada cuya sesión esté en proceso / abierta, sí se puede convertir en factura y no se remitirá por duplicado al SII.
Todas las facturas de simplificadas se informan como F2 u R5, independientemente de que hayamos establecido un cliente.
Como propuesta de mejora: añadir filtros y agrupaciones rápidos en el menú de pedidos del punto de venta:
Muchas gracias por el aporte y feedback!
|
Para intentar empujar esta tarea, si os va bien nos podemos reunir cualquier día de este mes de Julio y comentamos en conjunto todo lo que ha surgido con la parte de facturas simiplificadas cualificadas, Libro de IVA e incluso del Régimen Especial de Viajeros... ¿Os va bien la próxima semana? Gracias, @omar7r @rafaelbn @anmarmo1 @pedrobaeza @almumu @Gelo-fl @zamberjo |
|
Ok, por mi cuando querais. |
|
Hay ahora mismo conflicto de fusión. Decidme si organizáis algo entonces. |
|
|
||
| def _sii_get_partner(self): | ||
| partner = ( | ||
| self.partner_id.commercial_partner_id |
There was a problem hiding this comment.
sino se permiten las facturas nominativas por ahora, aquí siempre se debería de coger self.session_id.config_id.default_partner_id
| line.order_id.pricelist_id.currency_id or self.session_id.currency_id, | ||
| line.qty, | ||
| product=line.product_id, | ||
| partner=line.order_id.partner_id or False, |
|
Realizando pruebas se me ha ocurrido este supuesto:
Si el TPV no cierra sesión en el día, se nos puede dar el caso donde tengamos
Lo cual supone que dentro del SII tendré parte de las facturas registradas en el periodo 06/2023 y otras tantas en 07/2023, mientras que contablemente el asiento resumen constará a 07/2023. En definitiva, no cuadra la contabilidad y el 303 de Odoo con lo que hemos remitido al SII ni con el Pre-303. |
|
la fecha contable podría ser la fecha de inicio de la sesión, hasta que se cierre y ya no habría problema |
pedrobaeza
changed the title
|
Se podría hacer que los envíos al SII se hicieran al final de la sesión, no a tiempo real. Primero que se haga el asiento contable de cierre y que todos los pedidos se enviasen con esa fecha del asiento. De esa forma los envíos al SII coincidirían con la fecha contable del asiento |
|
Gracias a todos/as por la reunión de ayer y a @zamberjo por el código. Sobre lo que comenta Sonia, a efectos prácticos, esto solo es problema justo en la transición del periodo (mes). Es instruir a los usuarios que a final de mes, deben cerrar sesión sí o sí, para que contablemente sea correcto. Sobre la sugerencia de Gelo, tampoco sería del todo válido si se deja sin cerrar muchos días y se pasa el plazo de los primeros tickets. Voy a proceder a fusionar, y después hago una anotación de esto también en known issues. /ocabot merge patch |
|
On my way to merge this fine PR! |
|
Congratulations, your PR was merged at 2d34cb5. Thanks a lot for contributing to OCA. ❤️ |
Me parece bien que se haya mergeado este PR, pero no estoy 100% de acuerdo con la solución alternativa, ya que es un problema que puede darse en cualquier bar / restaurante todos los meses. Con la propuesta de Gelo operaríamos igual que si estuvieramos en la opción de enviar el asiento resumen al SII y no las facturas simplificadas individuales, en el primero la fecha de referencia para el SII sería la fecha contable del asiento y no la fecha del pedido. Esto no es una solución perfecta pero sí menos lesiva para el usuario que gestione la fiscalidad y tenga que ajustar, y además, es tal y como funciona el TPV de Odoo cuando no tenemos SII. Lo perfecto y más ambicioso es tocar el método estándar de facturación del TPV, para que registre tantos asientos como fechas de pedido contenga la sesión. En resumen, el error es especialmente lesivo para comercios que estén abiertos más allá de las 00:00 de la noche y para empresas que tengan 20 tiendas, puesto que revisar, localizar y corregir esas diferencias será muy manual. |
|
Hola, Sonia, Entiendo lo que dices, pero ten en cuenta que la generación de asientos contables en el cierre no tiene que ver directamente con este módulo. Por eso digo de ponerlo en el Known issues / Roadmap. Una posible solución al problema planteado, para los que no trabajan con nocturnidad, es asegurarse de cerrar la sesión el último día del mes (o módulo La propuesta de Gelo, que sí que es una alternativa a este módulo, también es algo que se puede implementar en un módulo separado Como por eso no es una solución mejor, vamos a tener esta primera aproximación que cerremos apartados, y lo dicho, se pueden realizar estas otras variantes. |
OCA#3088 Los pedidos se enviarán siempre como F2, sin especificar la contraparte. Aún así, en el _sii_get_partner que también se utiliza en otros métodos del sii, hacemos que el partner que obtiene sea el default partner del pos, para no generar incongruencias. Respecto a la fecha, de momento seguimos enviado la del pedido.
OCA#3088 Los pedidos se enviarán siempre como F2, sin especificar la contraparte. Aún así, en el _sii_get_partner que también se utiliza en otros métodos del sii, hacemos que el partner que obtiene sea el default partner del pos, para no generar incongruencias. Respecto a la fecha, de momento seguimos enviado la del pedido.
There was a problem hiding this comment.
Este PR introduce una regresión.
El antiguo método confirm_one_invoice ahora se llama confirm_one_document.
En una BD teníamos algunos trabajos en la cola cuando llegó la actualización. La cola se bloqueó porque el método confirm_one_invoice dejó de existir. Aviso por si os pasa lo mismo.
| @@ -1451,8 +863,5 @@ def _reverse_moves(self, default_values_list=None, cancel=False): | |||
| ) | |||
| return res | |||
|
|
|||
| def confirm_one_invoice(self): | |||
There was a problem hiding this comment.
Este era el nombre antiguo del método.
| new_cr.close() | ||
| raise ValidationError(fault) from fault | ||
|
|
||
| def confirm_one_document(self): |
|
Solucionamos regresión en #3165 Ping @zamberjo @pedrobaeza |
OCA#3088 Los pedidos se enviarán siempre como F2, sin especificar la contraparte. Aún así, en el _sii_get_partner que también se utiliza en otros métodos del sii, hacemos que el partner que obtiene sea el default partner del pos, para no generar incongruencias. Respecto a la fecha, de momento seguimos enviado la del pedido.
OCA#3088 Los pedidos se enviarán siempre como F2, sin especificar la contraparte. Aún así, en el _sii_get_partner que también se utiliza en otros métodos del sii, hacemos que el partner que obtiene sea el default partner del pos, para no generar incongruencias. Respecto a la fecha, de momento seguimos enviado la del pedido.
OCA#3088 Los pedidos se enviarán siempre como F2, sin especificar la contraparte. Aún así, en el _sii_get_partner que también se utiliza en otros métodos del sii, hacemos que el partner que obtiene sea el default partner del pos, para no generar incongruencias. Respecto a la fecha, de momento seguimos enviado la del pedido.
OCA#3088 Los pedidos se enviarán siempre como F2, sin especificar la contraparte. Aún así, en el _sii_get_partner que también se utiliza en otros métodos del sii, hacemos que el partner que obtiene sea el default partner del pos, para no generar incongruencias. Respecto a la fecha, de momento seguimos enviado la del pedido.
MVP de lo planteado en la issue #3058 (comment), todavía no hemos contemplado los abonos y el envío al SII es de forma manual (ver ROADMAP.rst)