13.0 mig l10n es account invoice sequence#1208
13.0 mig l10n es account invoice sequence#1208emagdalenaC2i wants to merge 49 commits intoOCA:13.0from
Conversation
…cia de factura y la del asiento. Sustituye al antiguo nan_account_invoice_sequence.
…tá asignada a un diario como secuencia de factura.
…ntenido del campo internal_number. [IMP] l10n_es_account_invoice_sequence: PEP8 y convenciones v7.
…ura ocultado cuando el diario no es del tipo adecuado.
[MIG] Eliminados módulos no migrados a v7
* Tests * Asigna la misma secuencia para la factura y el asiento * Nueva API * al cancelar y validar una factura se le asigna otro numero * with_context, quitar browse e 'internal_number' solo si se necesita * Cuando Valida -> Cancela -> Valida no se asigna correctamente el num. asiento contable * Permitir eliminar facturas en borrador o canceladas * Descripción del módulo ampliada y extraída a RST
…tandard Odoo for invoice numbering Restore default behaviour on unlink too
* Full tests * All flows covered * Journal fix on install
…tion and not after Bump version
…ectly for first use Odoo has included the possibility of changing first invoice number when there's no other invoices in the system. With this patch, the number is get and set correctly.
|
@meigallodixital Si quieres ir hacia esta versión y no se avanza lo que te interesa, tienes 2 opciones:
Si no, se avanzará esto según los intereses de aquellos que lo contribuyan, lo que normalmente no tiene una planificación estricta. |
|
Personalmente, y ya lo he manifestado en ocasiones anteriores, este módulo es innecesario y aleja el entorno del estándar de Odoo. Odoo te garantiza la secuencia de facturas sin huecos. Tampoco creo necesaria la renumeración de asientos, como mucho, para los más puristas, podría añadirse un número de secuencia para el libro diario. |
|
@pedrobaeza Este cambio creo que es demasiado crítico para que alguien fuera de los que llevais l10n_spain o tenga muy claros los procesos internos de facturación/contabilidad de Odoo lo migre como bien comentais al principio del hilo. Es más creo que es más un tema de decidir una estructura que no afecte al resto como la que propone @anajuaristi que técnico/programación/migración. Si se decide una forma y no es muy compleja podría intentar migrarlo a ver si soy capaz. Respecto a lo de liberar siempre lo hago, de hecho le empezaría a atacar a la parte de operating_unit desde ya, al menos la parte funcional, si esto y el account de operating_unit estuviesen listos. |
Ahora el problema de 13.0 es más que número de factura y asiento es el mismo campo y en españa no es así, no se corresponden per se. no se si con lo que propones se arreglaría, no se si es solución parecida a la que comenta @anajuaristi |
|
No me gusta entrar en estos debates porque al final cada asesor dice una cosa, pero al menos yo suelo sustentarme en el BOE, no solo en buenas prácticas o costumbres. Vamos por pasos, la ley obliga a que las facturas sean correlativas, esto en principio manteniendo una secuncia separada por cada diario de facturación con Odoo estandar no sería un problema aunque no se usa doble secuencia, ya que cada diario tendría su secuencia única sin huecos: Pero que sucede con el registro mercantil del libro diario. El BOE dice "Todo empresario deberá llevar una contabilidad ordenada, adecuada a la actividad de su empresa que permita un seguimiento cronológico de todas sus operaciones, así como la elaboración periódica de balances e inventarios. Llevará necesariamente, sin perjuicio de lo establecido en las Leyes o disposiciones especiales, un libro de Inventarios y Cuentas anuales y otro Diario" Este BOE no dice especificamente que tengán que tener númeración única correlativa todo los apuntes. Por lo tanto, podría no ir en contra de la ley, usar una sola secuencia y no realizar este desarrollo. Pero cual es la realidad, sobre todo en las empresas obligadas a auditoria externa, que lo primero que piden es el libro diario numerado en orden cronológico, no multiples numeraciones. Esto nos obliga a tener una secuencia por asiento y otra por factura, ya que la facutra no puede cambiarse. Odoo puede ir por un camino, pero no tiene porque ser la realidad o correcto, de hecho no es la primera vez que sucede un caso similar. Un último tema, aunque ya ajeno a Odoo, todos softwares, incluidos los grandes ERPs que no son Odoo, tienen renumeración de asientos, pero si no tenemos doble secuencia no podemos hacerlo, ya que sobre escribiriamos las secuencias de las facturas que no es legal. |
|
Buenos días: Lo primero que pienso es que al tener un cambio tan importante en v13 con las desaparición de las facturas y esto afectar tanto a localización española creo que deben opinar/intervenir más personas como ya se hizo en v11 cuando se decidió suprimir el cierre de año contable y cambiar en base a eso los informes del PGCE. Pensad que este cambio se hace ahora en v13 (aunque muchos no la estéis implantando) pero ya será para "siempre" (v14, etc..) @omar7r @JordiBForgeFlow @angelmoya @carlosdauden @rlizana @misern2 @emagdalenaC2i @albertgafic @santiarg ... Gracias @acysos por estos datos. "La ley obliga a que las facturas sean correlitvas".
Bromas a parte. Tenemos:
A ver si podemos aportar todos ideas y comentarios para sacar conclusiones. A priori mi opinión es:
Gracias |
|
Mi opinión ya la conocéis, no soy partidario de usar el módulo, nunca lo he instalado en ningún cliente. |
|
Buenas |
|
@jalzaga el problema es el cambio de modelo. Hasta la V12 existía account.invoice (con su número de factura) y account.move (con su número de asiento). Por tanto, aún sin la instalación del módulo podíamos decir que teníamos de base al menos 2 campos diferentes, a pesar de que Odoo standar llevaba el número de factura al número de asiento. Nuestro módulo account_invoice_sequence, permitía tener una numeración secuencial diferente para account.move (correlativa independientemente del diario del que proviene el asiento y por tanto distinta del número de factura) El problema es que ahora account.invoice NO EXISTE MAS. Es decir, el modelo como tal ha desaparecido, por tanto, ya de base no tienes 2 campos, tienes uno único. Es decir, la secuencia de account.move y listo. No hay más. Esta secuencia se calcula según el diario en el que se registre el asiento y por tanto, ya no existirá más una secuencia correlativa independiente del diario, a no ser que añadamos una nueva. |
|
Por lo que comenta @rafaelbn y @jalzaga , parece claro que no es obligatorio SÍ o SÍ. O, al menos, no hay una normativa que obligue a ello específicamente. De este modo, no veo la necesidad de que sea un "STOPPER" de cara a avanzar en la localización española. Tengamos en cuenta, también, que la decisión que se tome ahora se deberá seguir en versiones posteriores, V14 y futuras... Por lo menos a mi entender. Aún así, como dice @anajuaristi ; el hecho de mantenerlo no supondría un gran problema. Dependerá en todo caso de cada implantador/cliente ya que podemos encontrarnos con todos los gustos/necesidades como hasta ahora. De este modo, también cubriríamos los casos de uso comentados por @acysos en comparación con otros softwares, Odoo seguiría siendo polivalente y se potenciaría la herramienta. En todo caso, valdría la pena evaluar los pros y contras (complejidad de adaptación/tiempo a invertir/beneficios) y si debe ser un punto crítico en el cual invertir los esfuerzos de la Comunidad. Para mí no lo es, sino que lo entiendo como una mejora, más bien. De optar por mantenerlo (o no), se debería analizar de dónde venimos (versiones anteriores) para tener en cuenta las migraciones en los casos que se estuviera utilizando (o no) debido al cambio de modelo, etc. Gracias. |
|
Eso es +1 @HaraldPanten |
|
Comento porque me habéis nombrado, pero la verdad que tengo ninguna opinión firme ni a favor ni en contra. Discontinuar el módulo y usar el estándar lo veo bien. Si no me he perdido, se comenta que no se tenga la secuencia única almacenada, y ese número único se saque en el informe de diario general. Pero también es verdad que si el número que te de el diario no queda almacenado en el asiento funcionalmente cumple, pero a nivel usuario no creo que estén muy conformes. Si por otro lado estamos pensando en crear una secuencia que quede almacenada en el asiento (independiente del diario) y que se renumere, entonces estamos rehaciendo la doble secuencia, y la renumeración de la secuencia estándar ya está en OCA. |
|
Si @angelmoya... pero el módulo de renumeración tendría que ir sobre el
nuevo campo si es que se crea la nueva secuencia. Tal cual está ahora no
valdría. Pero la modificación es bastante simple, creo.
El lun., 24 feb. 2020 a las 12:13, Angel Moya - PESOL (<
notifications@github.com>) escribió:
… Comento porque me habéis nombrado, pero la verdad que tengo ninguna
opinión firme ni a favor ni en contra.
Discontinuar el módulo y usar el estándar lo veo bien.
Si no me he perdido, se comenta que no se tenga la secuencia única
almacenada, y ese número único se saque en el informe de diario general.
Pero también es verdad que si el número que te de el diario no queda
almacenado en el asiento funcionalmente cumple, pero a nivel usuario no
creo que estén muy conformes.
Si por otro lado estamos pensando en crear una secuencia que quede
almacenada en el asiento (independiente del diario) y que se renumere,
entonces estamos rehaciendo la doble secuencia, y la renumeración de la
secuencia estándar ya está en OCA.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1208?email_source=notifications&email_token=AABNRX2BMKBNQR42QL7ARFTREOTUVA5CNFSM4JCMK5FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMXNJXI#issuecomment-590271709>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABNRX6P3E76T3FURJJHYD3REOTUVANCNFSM4JCMK5FA>
.
--
CEO Avanzosc, S.L <http://www.avanzosc.es/> : Office phone / Tfono
oficina: (+34)
943 02 69 02
Ana Juaristi Olalde <http://www.anajuaristi.com/>: Personal phone: 677 93
42 59. User/usuario skype: Avanzosc
www.avanzosc.es
www,odoomrp.com <http://odoomrp.com/>
www.pymeserp.com
www.agroalerp.com
[image: Logo Avanzosc]
*El contenido de esta comunicación y de toda su documentación anexa es
confidencial y se dirige exclusivamente a su destinatario. El uso no
autorizado de esta información está prohibido por la legislación vigente.
Si usted no es el destinatario le rogamos nos lo indique, no comunique su
contenido a terceros y proceda a su destrucción. Disculpe las molestias que
le haya ocasionado la recepción indebida de este e-mail. Sus datos figuran
en un fichero cuyo titular es Avanzosc, S.L., a quien usted puede dirigirse
para ejercer sus derechos de acceso, rectificación, cancelación y oposición
en Av) Julio Urkijo, 34 20720, Azkoitia (Gipuzkoa), Tef. 943 02 69 02
- **administracion@avanzosc.
<soporte@avanzosc.es>es*
*Komunikazio honen edukia eta dokumentazio erantsia konfidentziala da eta
hartzaileak bakarrik jaso beharko luke. Indarrean dagoen legeriak debekatu
egiten du bertan eskainitako informazioa baimenik gabe erabiltzea.
Komunikazioa zuri iritsi bazaizu, baina zu ez bazara hartzailea, mesedez,
guri jakinarazi, eta jasotako informazioa ez inori jakinarazi eta suntsitu.
Barkatu okerreko email hau jasotzeak eragindako eragozpenak. Zure datuak
Avanzosc, S.L. enpresaren fitxategietan sartuta daude. Zure datuak atzitzea
eska dezakezu, bai eta, datuak zuzentzea, ezereztea eta tratamenduari aurka
egitea ere. Horretarako, enpresara jo dezakezu, helbide honetan: **Julio
Urkijo etorbidea 34,** 20720, Azkoitia (Gipuzkoa), telefonoa: 943 02 69 02
- *
*administracion@avanzosc. <soporte@avanzosc.es>es* *This message and all
documents attached to it are confidential and intended only for the person
or entity to which it is addressed. Any use of this information by
unauthorised persons is prohibited under current legislation. If you
received this message by error, please advise us, destroy it and refrain
from communicating its contents to third parties. We apologise for any
inconvenience receiving this email improperly may cause to you. Your
personal data are included in a file owned by Avanzosc, S.L. If you want to
exercise your rights of access, correction, erasure and objection you can
contact the Controller at **julio Urkijo 34** 20720, Azkoitia (Gipuzkoa),
T: 943 02 69 02 – administracion@avanzosc. <soporte@avanzosc.es>es*
|
|
Por eso digo @anajuaristi
Creo que lo mas correcto es lo último, no crear ninguna secuencia y tirar de la impresión para tener esa secuencia única... pero es lo menos claro desde el punto de vista del usuario. |
|
Buenas, Es cierto que desde el punto de vista del usuario lo va a tener menos claro, pero ya hemos echo muchas veces pedagogía para reconducir al usuario a la forma en que trabaja el sistema 😄 . Lo mismo pasó con las cuentas contables de cliente/proveedor y recientemente con el cierre del ejercicio. |
|
Lo que está claro es que ahora el número de asiento contable corresponde a la secuencia del diario y eso debe de seguir igual. Lo que estamos debatiendo es como llevar la gestión de la numeración de los asientos contables para realizar el libro diario. Solo hay dos opciones:
Yo me decanto por la opción "Sin campo":
|
|
Muy bien explicado @rlizana , a mí me has convencido |
|
Me parece bien la propuesta de @rlizana , no obstante, yo dejaría la numeración secuencial en el libro diario como opción, pudiendo dejar la secuencia original de Odoo. El problema fundamental de usar una numeración distinta en el diario es que, en caso de requerir la búsqueda de los asientos del libro diario en Odoo por una auditoría, no se referencian directamente. |
|
@jalzaga aparezca o no la numeración secuencial siempre debe de aparecer el número del diario, para que se puedan referenciar al asiento. |
|
Si aparecen las dos numeraciones por mi "sin campo" Ok, creo que lo simplificamos |
|
@rlizana Sí, pero en el libro diario oficial solo hay un número de asiento, no puedes poner dos. El que quiera el número secuencial para el asiento podría seleccionarlo como opción, si no se eligiese esta opción aparecería solo el número de secuencia de cada diario, eso sí, siempre ordenado por fecha. |
|
¿@jalzaga conoces algún enlace oficial o BOE donde se especifique el formato exacto? |
|
No estoy muy metido en la localización y quizás no estoy entendiendo el problema. Con poner la secuencia "l10n_es_account_invoice_sequence.sequence_spanish_journal" en todos los journal de facturas no sería suficiente? Con Odoo normal, en caso de cancelar una factura, ésta ya no aparecería en el libro de diario. Con lo cual habría un salto en la secuencia de factura. Pero ésto también pasa si tienes el módulo instalado, porque la secuencia avanza irremediablemente (y tiene sentido porque después de cancelarla se puede reconfirmar). Ésto también pasa en la versión 12. La idea entonces es renumerar a la hora de generar el informe? Sólo el general ledger? No parece que eso sea más sencillo que migrar el módulo, porque están los OCA financial reports y los mis builder. Cómo se ha hecho hasta ahora? Gracias anticipadas por las respuestas. |
|
Hola @AaronHForgeFlow , Sobre este aspecto, en el Codesprint en remoto de mayo se llegó a una conclusión con @ValentinVinagre y @pedrobaeza para gestionarlo de otra forma. Tengo pendiente abrir una issue explicando la metodología que se va a sugerir, ya que finalmente lo que se vio más viable era cambiar algún aspecto del account_financial_report para contemplar los casos de uso de los que hablamos en este PR, etc. Yo no te sabría decir si la propuesta cubre lo que buscamos. Aún así, puede que tu aportación sea una alternativa válida. A la espera de opiniones 😉 |
|
Siempre he visto horrible la opción de renumerar asientos. El principal problema es que pierdes la referencia al asiento. Imagina que estas discutiendo sobre un determinado asiento con un compañero o con Hacienda, y.. zas! Al dia siguiente ese número de asiento ya no es el mismo, y ya no puedes encontrar el original. Esto es un fallo garrafal que no veo que se comente. En mi opinión, si la ley requiere ordenar el libro diario por fecha, así se está haciendo. Si requiere un número correlativo, se puede extender el 'account_financial_report' en un modulo l10n_es.., para generar, al vuelo, un número correlativo, ahora que los de @ForgeFlow lo hemos dejado bien limpio en v13. En el informe siempre aparecería el número de asiento, por si quieres seguir la referencia a través de otros informes. Y si esto no es del gusto del señor inspector, porque no es cómodo... pues se le dice que la otra opción generaba pérdida de información y es la mejor que se nos ha ocurrido. @acysos SAP no permite renumerar asientos contables. En la migración de l10n_es debemos incorporar un script que mueva los números de factura antigo al número de asiento. @ValentinVinagre @HaraldPanten @pedrobaeza entiendo que compartís la conclusión. Para ir avanzando, @AaronHForgeFlow va a implementar esta migración. |
|
Sí, ésa fue la conclusión: la de generar el número en el libro diario al vuelo, y script de migración en OpenUpgrade. Por cierto, voy a cerrar este PR ya. |
|
Prometo no tardar en crear issue de debate sobre el tema para llegar a una conclusión y ponernos manos a la obra! 🙏 |
|
script de migración propuesto: OCA/OpenUpgrade#2391 |
20 participants
No description provided.