Documenting code, one commit at a time.
En el proyecto Reimpact/platform, hemos implementado recientemente una mejora crucial en la forma en que se generan los informes de almacenes. Anteriormente, el sistema presentaba una limitación significativa: los informes se filtraban exclusivamente por un único warehouse_id. Esta restricción provocaba que los almacenes no declarantes, que estaban asociados a través de un
Continuando con el desarrollo de la plataforma Reimpact, hemos implementado una serie de mejoras significativas centradas en la gestión de datos y la funcionalidad de los paneles administrativos. Estas actualizaciones buscan optimizar los flujos de trabajo, mejorar la coherencia de la información y proporcionar una visión más clara del estado operativo.
Una de las adiciones clave es una nueva
En el proyecto Reimpact, hemos implementado una mejora significativa en la gestión interna de almacenes, enfocándonos en la claridad y eficiencia de la asociación de datos. Este ajuste, aunque técnico, tiene un impacto directo en la coherencia de los informes y la experiencia de usuario en los formularios.
This post discusses recent enhancements to the report generation process within the Reimpact/platform project, focusing on storing and displaying the generated report data.
The primary goal of these changes is to persist generated report data and provide flexible views for different report types. This involves adding a report_data column to the packaging_generated_reports
In the Reimpact/platform project, we encountered a tricky issue with queue deserialization in our multi-tenant environment. This post details the problem, our investigation, and the solution we implemented.
Our application uses a queue to generate reports. A GenerateReportJob is dispatched, serializing the GeneratedReport model.
In the Reimpact platform, we recently addressed an issue related to how database table names were being handled during migration seeding. Specifically, the system wasn't accurately extracting table names from migration files, leading to discrepancies and potential errors.
Previously, the migrationTableAlreadyCreated method relied on parsing table names directly
When building multi-tenant applications with Laravel, ensuring each tenant's database schema is correctly migrated can be a challenge. In the Reimpact platform, we encountered issues with tenant schemas either re-running all migrations on each deploy or skipping them entirely. This led to potential data inconsistencies and application instability.
Without a dedicated migration
