[17.0][IMP] l10n_es_aeat_sii_invoice_summary: Refactor to avoid overwrite when it is not necessary

[carlosdauden]

El origen de la refactorización es que se estaban enviando como F4 facturas rectificativas porque se estaba sobrescribiendo el tipo de factura de forma indiscriminada.
Ejemplo del problema:

• Cualquier factura rectificativa donde sii_invoice_summary_start != sii_invoice_summary_end

ping @sergio-teruel

@Tecnativa TT60749

[pedrobaeza]

Esto debería llamar a _is_aeat_summary_invoice, ¿no? De todas formas, este método puede que se use en otros lados donde no interese igualarlas. Habría que pasar un contexto donde se quiere obtener esto y solo entonces igualarlo.

[carlosdauden]

No, no se debe llamar a _is_aeat_summary_invoice porque, tal como está explicado en el comentario, el objetivo es que la estructura sea la misma de la factura simplificada independientemente del resto de condiciones que evalúa ese método.

No, no es necesario pasar un contexto ya que no vamos a añadir código innecesario para un caso que no se va a dar.
Si alguna vez se da se deberá evaluar si se quiere mantener este enfoque o hay que cambiarlo, y en caso de querer mantenerlo una solución podría ser añadir ese contexto.
Si se te ocurre un caso real y concreto también podemos hacer ahora ese análisis, pero no porque puede que se use, ya que las posibilidades teóricas y las ocurrencias son infinitas, pero nuestro trabajo es aplicar el sentido común en contacto con la realidad.

[pedrobaeza]

Lo del contexto sí que lo considero necesario, ya que si tienes un método _is_aeat_simplified_invoice, lo que esperas como programador es que ese método devuelva cuándo la factura es simplificada, no cuando es simplificada y cuando es una factura resumen, con lo que aunque ahora mismo no parece que afecte a ninguna otra cosa (que eso no lo sabes, porque otros han podido utilizar ese método en sus customizaciones), puede que en el futuro a nosotros mismos nos vaya eso en contra.

Otra posible vía es la de tener en el módulo padre un método nuevo _is_sii_simplified_structure o algo así, que sea el que se evalúa para enviar esa estructura básica, y entonces sea el que se sobreescribe aquí.

[carlosdauden]

¿En qué caso real una factura resumen no tiene el mismo trato que una factura simplificada?

Podemos no hacer absolutamente nada y que sea el usuario el que se asegure de que ambas cosas están marcadas para las facturas resumen, pero lo que se ha intentado es simplificar el código y cubrir el mayor número de casos sin que afecte a nadie que esté usando el módulo sin marcar las facturas resumen como simplificadas.

Antes de hacer el PR me he tomado mi tiempo analizando donde se utiliza cada método e intentando comprender cual es el comportamiento esperado.
En todas las llamadas al método _is_aeat_simplified_invoice (SII, POS, VeriFactu, etc.) el comportamiento deseado es que las facturas resumen tengan la misma estructura que las simplificadas, por lo que añadir un contexto, un nuevo método o lo que sea va en contra del objetivo de simplificación, ya que habría que modificar todos esos módulos cuando lo que se busca es precisamente lo contrario.

Si te parece, en lugar de teorizar sin mirar nada, puedes hacer un pequeño análisis para estudiar el caso concreto y evitas hacer perder más tiempo a las personas que ya lo han realizado.
Una vez hecho ese análisis puedes tomarte la libertad de cerrar el PR y abrir uno nuevo si lo consideras oportuno.

La realidad actual es que las facturas no se envían al SII correctamente y el código que hay es un despropósito (al que por cierto no se le pusieron problemas para fusionar).

Este PR tiene 2 commits en los que se resuelve el problema principal con dos enfoques distintos, siendo el último el óptimo, pero el primero es más conservador por si no se llegaba a entender la segunda opción.

[sergio-teruel]

Gracias por la corrección @carlosdauden
Parece que ahora que se envían las rectificativas como tal el test no pasa porque el test no estaba bien planteado.

¿Puedes corregir el test y aprobamos.?

[carlosdauden]

@sergio-teruel tests en verde, los tests se estaban asegurando de que la factura rectificativa estuviese mal comunicada 😮
#3071 (comment)

[carlosdauden]

ping @RodrigoBM @SoniaViciana

[PabloMartFL]

Probado en el runboat y funciona correctamente, a partir de este desarrollo las facturas resumen rectificativas se envían como R5

He estado revisando la AEAT sobre todo el FAQ -> https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/FaqGral/FAQs_10_02_2025.pdf Y la AEAT permite la generación de este tipo de asientos resumen mientras cumplan ciertas condiciones, por lo que doy aprobación al PR

[pedrobaeza]

Aunque obviamente para este caso funciona, revisad mi comentario en #4796 (comment)

Es mejor no dejar efectos laterales que luego nos hagan tener horas y horas de depuración para ver que es que se marcó como simplificada una factura que en realidad es una de resumen.

@carlosdauden a tu pregunta de "en qué caso no se comporta una de resumen como una simplificada", yo te lo planteo de la otra forma: ¿dónde dice Hacienda que se deban comportar siempre igual? Si fuera eso, la AEAT no haría la distinción, o lo llamaría factura simplificada de resumen.

Esto puede ser pasarse de precavidos, pero es mejor ahora prevenir, que luego lamentar.

Fíjate por ejemplo que esto estaría cambiando el comportamiento en el caso de VERI*FACTU, que ya llama a ese mismo método:

l10n-spain/l10n_es_verifactu_oca/models/account_move.py

Line 103 in eb2ed79

is_simplified = self._is_aeat_simplified_invoice()

[carlosdauden]

Yo no he dicho que para la AEAT sea lo mismo, estoy hablando del trato que se da en el código que utiliza ese método.

En este comentario ya estoy explicando que módulos usan ese método:
#4796 (comment)

Si te fijas bien en lo que hace el método que indicas, verás que si se desarrollase el módulo l10n_es_verifactu_invoice_summary (solo como ejemplo ya que estamos con teorías), seguramente interesaría que se modificase el comportamiento:

l10n-spain/l10n_es_verifactu_oca/models/account_move.py

Lines 103 to 110 in eb2ed79

	is_simplified = self._is_aeat_simplified_invoice()
	invoice_type = "F2" if is_simplified else "F1"
	if self.move_type == "out_refund":
	if self.verifactu_refund_specific_type:
	invoice_type = self.verifactu_refund_specific_type
	else:
	invoice_type = "R5" if is_simplified else "R1"
	return invoice_type

Estoy de acuerdo en el nombre _is_aeat_simplified_invoice puede hacer pensar a un programador junior que va a devolver lo mismo que el campo aeat_simplified_invoice (aunque se intuya que no se suele tener un método que lo único que haga es devolver el valor de un campo si no es con la intención de poder intervenir sin modificar el campo).

Para que se entienda mejor e intentar desbloquear la situación voy he subido un nuevo commit siguiendo esa otra via a la que se hace referencia aquí:
#4796 (comment)

Tal como se ve en el commit la idea será renombrar el método en futuras migraciones para no modificar en una versión estable por si alguien ha utilizado ese método en sus personalizaciones.

[pedrobaeza]

Gracias por los cambios. Un comentario sobre los pos.order, y luego, aunque sea simplificada, puede contener los datos del cliente (porque así se requiera - el típico ticket que pides con los datos de la empresa para pasar gastos -). El nombre del método _is_aeat_unidentified_document sugiere lo contrario, ¿o es que realmente está anonimizando todas esas facturas?

[pedrobaeza]

Aquí hay que seguir teniendo en cuenta los límites de las simplificadas (<400 €).

[carlosdauden]

Eso queda fuera del ámbito de este PR.

Pregunta a quien hiciese al PR que añadió "el código original" y a quien aprobase y fusionase esos cambios: