Einheitliches Paginierungs-Pattern mit page, size und Multi-Field sort
für alle 14 List-Endpoints. Response-Format ändert sich von [...] zu
{ content: [...], page: { number, size, totalElements, totalPages } }.
Backend:
- Shared Kernel: Page<T>, PageRequest, SortField, SortDirection
- PaginationHelper (SQL ORDER BY mit Whitelist), PageResponse DTO
- Paginated Methoden in allen 14 Domain-Repos + JDBC-Implementierungen
- Safety-Limit (500) für findAllBelowMinimumLevel/ExpiryRelevantBatches
- Alle List-Use-Cases akzeptieren PageRequest, liefern Page<T>
- Alle Controller mit page/size/sort Query-Params + PageResponse
Frontend:
- PagedResponse<T> Type auf nested page-Format aktualisiert
- Alle 14 API-Client-Resourcen liefern PagedResponse mit PaginationParams
- Alle Hooks mit Pagination-State (currentPage, totalPages, pageSize)
- Alle List-Screens mit Seiten-Navigation (Pfeiltasten) und Footer
Loadtest:
- Podman-Support im justfile (DOCKER_HOST auto-detect)
- Verschärfte Performance-Schwellwerte basierend auf Ist-Werten
Spiegelt die bestehende traceForward-Architektur mit invertierter
SQL-JOIN-Richtung, um von einer Endprodukt-Charge alle verwendeten
Rohstoff-Chargen zu ermitteln (Herkunftsnachweis).
Implementiert startCounting() und updateCountItem() auf dem InventoryCount-
Aggregate, zwei neue Use Cases (StartInventoryCount, RecordCountItem) mit
zugehörigen Controller-Endpoints (PATCH /{id}/start, PATCH /{id}/items/{itemId}).
Inkl. Domain-, Application-, Integrations- und Gatling-Lasttests.
- MovementType-Ableitung via ReferenceType.toMovementType() in Domain Layer
- Doppelten Batch-Lookup in Stock.confirmReservation() eliminiert
- StockError.MovementCreationFailed statt RepositoryFailure für Domain-Fehler
- 204 No Content statt 200 OK (konsistent mit releaseReservation)
- Batches mit Menge 0 nicht mehr entfernen (FK stock_movements → stock_batches)
Allokierte Mengen werden physisch aus den Chargen abgezogen,
StockMovements erzeugt und die Reservation entfernt.
MovementType wird aus ReferenceType abgeleitet
(PRODUCTION_ORDER→PRODUCTION_CONSUMPTION, SALE_ORDER→SALE).
Reschedule (PLANNED/RELEASED) mit Datumsvalidierung und List-Endpoint
mit optionaler Filterung nach Datum/Status als Full Vertical Slice.
Lasttests um neue Szenarien erweitert.
- InventoryScenario.recordStockMovement(): HTTP-Request mit doIf
guards, verhindert 'No attribute mvStockId' Fehler
- ProductionScenario.productionWorkflow(): Seeded Batch-/Order-IDs
als Fallback wenn planBatch/createProductionOrder fehlschlägt,
stellt sicher dass startBatch/completeBatch/releaseProductionOrder
immer feuern und Gatling-Assertions Stats sammeln können
RELEASED ProductionOrder kann mit einer PLANNED Batch verknüpft und
in Produktion gestartet werden. Dabei wechselt der Order auf IN_PROGRESS
und die Batch auf IN_PRODUCTION. Neuer REST-Endpoint POST /{id}/start,
StartOrderProduction Use Case, BatchAlreadyAssigned Error, Liquibase-
Migration für batch_id FK auf production_orders.
Erweitert die StockMovement-Abfrage um batchReference- und from/to-Filter
mit Filter-Priorität stockId > articleId > batchReference > movementType > from/to.
Inkl. DB-Index auf batch_id, Unit-/Integrationstests und Lasttest-Szenarien.
