Closed victoralmau closed 1 month ago
antoniocanovas
commented
6 months ago Buenos días, según observo en el módulo queda pendiente la parte de fabricante aunque hay una propuesta comentada sobre los dominios a aplicar.
En este PR ¿Es objetivo terminar la parte de fabricantes, o aprobar lo que hay en este momento?
Sobre lo pendiente ¿Nos ponemos a revisar estos dominios de "get_manufacturer_moves_domain" o hay alguien trabajando en ello / algo distinto?
Gracias.
victoralmau
commented
6 months ago Buenos días, según observo en el módulo queda pendiente la parte de fabricante aunque hay una propuesta comentada sobre los dominios a aplicar.
En este PR ¿Es objetivo terminar la parte de fabricantes, o aprobar lo que hay en este momento?
Sobre lo pendiente ¿Nos ponemos a revisar estos dominios de "get_manufacturer_moves_domain" o hay alguien trabajando en ello / algo distinto?
Gracias.
La parte de fabricante no estará contemplada en este módulo, será necesario hacer una extensión del mismo con dependencia de mrp y añadir ahí toda la lógica correspondiente; hay algún comentario en el ROADMAP al respecto que quizás pueda ayudar aunque la base de este módulo servirá.
victoralmau
commented
6 months ago He probado a hacer una compra a un país no comunitario y no considera impuesto sobre esta importación, sólo lo hace sobre intracomunitarios. La norma dice: "Está sujeta al impuesto la fabricación, importación, adquisición intracomunitaria o tenencia irregular de productos". Entiendo que habría que ampliar un dominio para extracomunitarios en "get_acquirer_moves_domain". Un saludo,
¿Estás seguro de que una compra a un pais no comunitario se debe considerar? Creo que no (indícanos el link a la documentación si lo tienes a mano), actualmente se tienen en cuenta las compras a intracomunitarios y las ventas a no españoles (podrás verlo en el método get_acquirer_moves_domain()).
victoralmau
commented
6 months ago Sugiero un cambio en el tratamiento de la información con Canarias. Si el producto es adquirido en Canarias con destino a la Península, debe tributar y ahora no se tiene en cuenta.
¿Tienes el link a la documentación que lo indique? De todas formas, para ello, haría falta indicar el país de origen (origin_country_id) de cada producto, algo que se conseguiría con product_harmonized_system (ese módulo también añade el código HS a los productos que quizás resulte confuso para quien no lo necesite).
¿Debería añadirse esa dependencia en este módulo o en un módulo hijo dependiente de este?
pedrobaeza
commented
6 months ago No, el caso que comentan de Canarias queda fuera del alcance del desarrollo. Añádelo al ROADMAP, y aquellos interesados pueden luego hacer un PR mejorándolo, aunque en ningún caso se debe depender de product_harmonized_system. Cuando se quiera añadir, se debate la mejor solución técnica.
pedrobaeza
commented
6 months ago @victoralmau el CI está en rojo, y otra cosa que no veo que aporte mucho es depender de report_csv, porque generar directamente el archivo con las utilidades Python puede ser prácticamente igual de cantidad de código.
victoralmau
commented
6 months ago Eliminada la dependencia report_csv y CI en verde.
victoralmau
commented
2 months ago He cambiado los campos específicos de la plantilla (product.template) para que sean almacenables y se pueda filtrar por esos datos.
Creo que si está todo ok se podría fusionar y añadir cualquier corrección que pudiera aparecer a futuro en otros PRs
pedrobaeza
commented
2 months ago ¿Cómo está hecho en core para esos campos similares? ¿También almacenables? ¿O implementan un método search? Para evitar una instalación pesada, habría que interceptar el método auto_init (opción favorita de Odoo, y más visible al estar contenida en el mismo archivo del modelo) o poner un pre_init_hook.
victoralmau
commented
2 months ago ¿Cómo está hecho en core para esos campos similares? ¿También almacenables? ¿O implementan un método search?
¿A que campos te refieres? (estoy buscando campos compute con depends de product_variant_ids pero no veo ninguno "similar").
Para evitar una instalación pesada, habría que interceptar el método auto_init (opción favorita de Odoo, y más visible al estar contenida en el mismo archivo del modelo) o poner un pre_init_hook.
Ok, si finalmente se quedan almacenables utilizaré el método auto_init.
PD: Otra opción es no añadir estos campos como store en la plantilla y evitar cualquier posible problemática al respecto (al menos por ahora) si realmente no es necesario.
pedrobaeza
commented
2 months ago Veo que ya has encontrado lo que comentaba de cómo lo hace el core, aunque creo que el core no hace los métodos search. No vienen mal de todas formas, pero en lugar de repetir código solo cambiando el nombre del campo, puedes hacer un método genérico con un argumento extra field, y desde cada search, llamar a ese método con el campo correspondiente.
victoralmau
commented
2 months ago Añadido un método genérico respecto al search, creo que es importante que se pueda buscar por esos campos de la plantilla porque si alguien no utiliza variantes deberá poder filtrar por ellos.
pedrobaeza
commented
1 month ago La declaración, para la parte cubierta, lleva ya bastante tiempo funcionando con éxito, así que vamos a fusionarlo. Si alguien quiere encargarse de la parte de fabricante, y puesto que esa parte requeriría un módulo extra para no depender de mrp, puede ser una contribución posterior.
/ocabot merge nobump
OCA-git-bot
commented
1 month ago On my way to merge this fine PR! Prepared branch 15.0-ocabot-merge-pr-3505-by-pedrobaeza-bump-nobump, awaiting test results.
OCA-git-bot
commented
1 month ago Congratulations, your PR was merged at 3ad576fcc1e3f62cb548c3a64a9fef0106611b4d. Thanks a lot for contributing to OCA. ❤️
Superseed https://github.com/OCA/l10n-spain/pull/2992
Nuevo módulo
Cambios hechos:
report_csvPor favor @pedrobaeza, puedes revisarlo?
@Tecnativa TT48472