Motor de reservas de stock sobre documentos de venta y almacén

Problema

Una reserva de stock es una promesa sobre mercancía que muchas veces todavía no ha llegado. Se reserva contra un pedido pendiente y, mientras tanto, el usuario puede modificar ese pedido, cancelarlo o cerrarlo a mano. La parte difícil no es reservar: es liberar en el momento correcto, porque una reserva que no se libera bloquea existencias que están disponibles y una que se libera antes de tiempo deja un pedido sin servir.

Encima, varias tareas de servidor tocan las mismas filas a la vez.

Solución

El motor cubre el ciclo entero y no solo el alta. Cuando entra la mercancía del pedido, asigna automáticamente los lotes a las reservas que estaban esperando. Cuando se cancela el documento, borra las reservas asociadas. Cuando alguien cierra a mano un pedido o un traslado, el efecto tiene que ser el mismo que si se hubiera servido: lo reservado queda libre.

Los artículos no inventariables siguen su propio camino, porque no hay existencias que reservar y aun así el documento las pide.

El punto delicado es la concurrencia. Dos tareas de servidor que recorren las mismas reservas en orden distinto terminan cada una esperando el bloqueo que tiene la otra, y ese interbloqueo lo resuelve el gestor de base de datos abortando a una de las dos. La que cae pierde el trabajo de su transacción, así que no basta con capturar el error: hay que fijar el orden de los accesos, acotar las transacciones a lo que de verdad tiene que ser atómico y dejar el proceso en un estado desde el que se pueda reintentar sin duplicar reservas.

Arquitectura

Usuario: pedido de venta | traslado
                 |
                 v
        Motor de reservas  <-->  Reservas (tabla)
         ^             |
         |             v
         |     Liberacion:  cancelacion
         |                | cierre manual
         |                | servicio
         |
  Tareas de servidor (concurrentes)
         |
         v
  Entrada de mercancia --> asignacion de lotes
         |
         v
    SQL Server / SAP HANA

Por qué está montado así

Liberar es el caso principal, no la excepción. Cada vía por la que un documento deja de necesitar stock (se cancela, se cierra a mano, se sirve) dispara su propia liberación.

Cuando entra la mercancía, los lotes se asignan solos a las reservas que esperaban. El usuario no tiene que volver a entrar en el pedido.

Los artículos no inventariables van por su camino. No tienen existencias y aun así aparecen en los documentos, así que reservarlos no significa nada.

Con la concurrencia no basta capturar el error. Fijé el orden en que se recorren las filas y acorté las transacciones a lo que de verdad tiene que ser atómico, porque reintentar a ciegas lo que acaba de morir por interbloqueo suele duplicar reservas.

Resultado

Es el módulo al que más he vuelto: cerca de 400 commits repartidos entre el núcleo común y las implantaciones que lo usan.