Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

l10n_es_payment_order_confirming_aef: Bankinter no toma una fecha de emisión correcta #3425

Closed
giarve opened this issue Feb 5, 2024 · 3 comments
Labels

Comments

@giarve
Copy link
Contributor

giarve commented Feb 5, 2024

Module

l10n_es_payment_order_confirming_aef

Describe the bug

Bankinter usa la fecha de proceso del fichero AEF que actualmente es incorrecta (tomamos el primer pago y su fecha). Los demás bancos usan la fecha de subida del fichero a sus plataformas. Por ende, es probable que la mejor solución sea poner el campo de fecha de generación del fichero como "fecha proceso".

Si se pone una fecha de vencimiento del primer pago (criterio para hacer esto? Ninguno), nunca se habilita la remesa en el sistema para que los proveedores lo decidan usar o no.

# 67 - 74 Fecha proceso
fecha_proceso = fields.first(self.record.payment_line_ids).date
text += self._aef_convert_text(str(fecha_proceso).replace("-", ""), 8)

To Reproduce

Affected versions: 14.0,15.0,16.0

Steps to reproduce the behavior:

  1. Crear remesa de pago
  2. Generar fichero
  3. Subir fichero a Bankinter

Expected behavior
La fecha de generación del fichero se establece aquí:

# 67 - 74 Fecha proceso
fecha_proceso = fields.first(self.record.payment_line_ids).date
text += self._aef_convert_text(str(fecha_proceso).replace("-", ""), 8)

@giarve giarve added the bug label Feb 5, 2024
@pedrobaeza
Copy link
Member

No termino de entender el problema, pero lo que puedo decir es que la fecha de pago depende de lo que se elija en la orden de pago. Puede ser una fecha fija o puede ser la fecha de hoy. Obviamente, si se escoge fecha de vencimiento, y la primera línea tiene una fecha en el futuro posterior al de otras líneas, esa fecha no será representativa.

De todas, ¿para qué utilizan los bancos ese dato de fecha proceso? Cada línea luego lleva información de su propia fecha:

text += str(line.date).replace("-", "").replace("/", "")

con lo que es un dato bastante testimonial.

@giarve
Copy link
Contributor Author

giarve commented Feb 5, 2024

No termino de entender el problema, pero lo que puedo decir es que la fecha de pago depende de lo que se elija en la orden de pago. Puede ser una fecha fija o puede ser la fecha de hoy. Obviamente, si se escoge fecha de vencimiento, y la primera línea tiene una fecha en el futuro posterior al de otras líneas, esa fecha no será representativa.

De todas, ¿para qué utilizan los bancos ese dato de fecha proceso? Cada línea luego lleva información de su propia fecha:

text += str(line.date).replace("-", "").replace("/", "")

con lo que es un dato bastante testimonial.

Los demás bancos, para nada. Bankinter para procesar el fichero, si no, ni crea los confirming hasta esa fecha, y es como si nunca se hubiera subido el fichero.

Según me han explicado los usuarios, es para dar planificar una disponibilidad del confirming desde fecha previa a la subida real del fichero (los otros bancos no tendrían esta posibilidad).

Solución:
Se pone la fecha de generación del fichero. No afecta a ningún otro banco y soluciona el caso de Bankinter. La verdad es que dudo que lo use alguien como planificador, sinó habrá que crear un campo explícito para especificar esa fecha, pero ya digo que solo pasa con Bankinter y ni necesitamos eso en nuestro caso de uso (sirve con poner la fecha de generación del fichero).

@pedrobaeza
Copy link
Member

Vale, como no tiene ninguna función especial, se puede utilizar la fecha que comentas. ¿Puedes hacer un PR con el cambio?

raistdev added a commit to raistdev/l10n-spain that referenced this issue Feb 12, 2024
… as today

Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
raistdev added a commit to raistdev/l10n-spain that referenced this issue Feb 12, 2024
… as today

Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
raistdev added a commit to raistdev/l10n-spain that referenced this issue Feb 12, 2024
… as today

Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
raistdev added a commit to raistdev/l10n-spain that referenced this issue Feb 12, 2024
Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
raistdev added a commit to raistdev/l10n-spain that referenced this issue Feb 12, 2024
Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
raistdev added a commit to raistdev/l10n-spain that referenced this issue Feb 12, 2024
Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
enriquemartin pushed a commit to Digital5-Odoo/l10n-spain that referenced this issue Feb 21, 2024
Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
david-s73 pushed a commit to Studio73/l10n-spain that referenced this issue Jun 18, 2024
Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
david-s73 pushed a commit to Studio73/l10n-spain that referenced this issue Jul 2, 2024
Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
david-s73 pushed a commit to Studio73/l10n-spain that referenced this issue Jul 22, 2024
Bankinter is actually using the processing date indicated in the file for their
planning and using the first line payment date causes that the files generated
don't work with that bank.

As harmless for the rest of the banks, let's use the date where the file is generated
for this data.

Closes OCA#3425
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants