8069-Overstocking #3051
No reviewers
Labels
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: verdnatura/salix#3051
Loading…
Reference in New Issue
No description provided.
Delete Branch "8069-Overstocking"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
@ -0,0 +14,4 @@
DECLARE cWarehouses CURSOR FOR
SELECT DISTINCT warehouseFk, shipment
FROM orderRow r
sols una taula no cal alias
@ -0,0 +43,4 @@
JOIN cache.available a ON a.calc_id = vCalcFk AND a.item_id = r.itemFk
SET r.amount = 0
WHERE ADDTIME(o.rowUpdated, oc.reserveTime) < NOW()
AND a.available <= 0
cal pensar, si hi ha 20 disponibles, pero el client demana 100?
a.available <= 0 soluciona el tema. Quan la cistella de la compra està fora de hora, eixa quantitat no s'ha tingut en compte en el càlcul del disponible
@ -101,6 +101,8 @@ BEGIN
CALL order_checkEditable(vSelf);
CALL orderRow_updateOverstocking(vSelf);
es confirmen moltisim pedidos al dia, pero la cache no es calcula tantes vegades, este enfoque colocaria molta carrega, faria les mateixes comprobacions practicamente cada minut varies vegades.
Quan parlarem diguerem de asociar-ho al calcul del disponible
Si ho fique en available_refresh, estic cridant desde el esquema hedera al esquema order
I si per eixemple, algú a mà coloca una quantitat gran en una linea de pedido, al recalcular el dispo, borraría moltes cistelles. Després, si modifica la quantitat, les cistelles no tornen al lloc. Per això semblava millor que en el moment de confirmar, faça la cridà.
WIP: 8069-Overstockingto 8069-Overstocking