solucionado bug balance de situacion - #91
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 22b94b059c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| <null>NO</null> | ||
| </column> | ||
| <column> | ||
| <name>restriccion</name> |
There was a problem hiding this comment.
Populate restrictions for existing balance accounts
When this column is added on upgrade, existing balance_accounts rows keep restriccion as NULL, and BalanceAccount::matchesRestriction() treats that as unrestricted, so already-installed companies still count the pymes double-balance accounts (551/5525/5523/5524) on both sides. The only populated values are in the seed CSV, while Init::update()/copyBalancePymes() do not backfill the new field, so the fix only works for fresh seed imports; add a migration/backfill for the affected existing rows.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
@Pabloferrandezroca faltaría añadir una migración haciendo lo que dice el comentario de Codex, para que aquellas instalaciones con el plugin ya activo se rellene esa nueva columna "restriccion" donde debe hacerlo, así el usuario no tiene que rellenarla manualmente.
El PR #91 rellenaba la restricción de las cuentas de doble saldo (551, 5523, 5524, 5525) en instalaciones existentes, pero el método fallaba justo en ese escenario: se ejecutaba antes de que la columna restriccion existiera, porque nunca se instanciaba BalanceAccount fuera de la migración de tablas legacy. Se sustituye por una clase de Migration (patrón estándar del core, con registro en migrations.json) que instancia los modelos antes de tocar la columna, y se renombra restriccion a restriction para ser coherente con el resto de columnas de balance_codes. También se aplica la misma comprobación de restricción en ProfitAndLoss e IncomeAndExpenditure, que reutilizan cuentas del mismo modelo y quedaban sin cubrir. Se añaden tests de regresión del descuadre, de no regresión en cuentas de amortización, y de la propia migración. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
solucionado el bug que al realizar un balance de situación con cuantas de doble saldo se descuadra