Ingresos egresos - asientos - lockeo

Cuando se hace un asiento de ventas, compras o ingresos y egresos en forma Defintiva o Reciclado, en realidad no se recorren las facturas sino los movimientos que esas facturas generaron.
O sea que basicamente se traba todo el esquema de ingresos y egresos que esta presente no solo en la venta sino en los pagos o bancos en general.

Como la cantidad de movimientos es muy grande, se tarda en recorrerlos un tiempo considerable, si el tipo de asiento es reciclado o definitivo el proceso marca al movimiento como contabilizado, o sea es necesario trabarlo para poder grabarle la S de contabilizado.

Si esta trabado ese movimiento, y posiblemente los anteriores y posteriores tambien, quedan imposibilitados de ser tomados por otro proceso o terminal que lo necesite, o que necesite intercarlar alguno nuevo, debido a que en los archivos los datos no estan secuenciales, sino desparramados como el sql interpreta mejor.
Sql no envia nada y el sistema se queda esperando.

Habitualmente espera unos 35 segundos y luego hace lo que puede, si esta en una orden de pago es posible que grabe una parte si y la otra no.

Eso genera las famosas inconsistencias que hay una manera de buscarlas porque uno sabe como se van grabando las cosas.

Por ejemplo si un recibo se traba, la secuencia es : grabar el recibo, actualizar la cuenta corriente, generar el movimiento de ingresos y egresos, dar de alta los cheques que el cliente me dio.

En un sistema ideal con un solo usuario y una sola operacion a la vez, uno puede tomar el criterio que se llama UTL, o sea, dejar en stand by toda la cadena hasta que se completa el ultimo eslabon, en el ejemplo anterior seria no dar por terminado nada hasta que el cheque de terceros esta archivado.

Con 43 usuarios, como estan trabajando habitualmente ustedes, eso seria imposible, ya que seria practicamente como si cada uno tuviera que esperar que termine el otro, volviendo el sistema multiusuario en monousuario.

Entonces uno lo que hace es ir grabando por partes, divide la UTL en : grabar el recibo, grabar la cuenta corriente, grabar el movimiento y grabar el cheque de terceros, (UTLs mas chiquitas) posibilitando que otro usuario este en la misma cadena pero en otro eslabon.

Cuando alguno traba a otro se produce una especie de arbol, uno traba un movimiento de ingresos y egresos, el que esta haciendo el recibo queda trabado por no poder generar el movimiento, el que esta haciendo el recibo trabo a los clientes, por lo que el que esta facturando no puede acceder a los legajos, y que ademas como esta facturando un producto, los productos pueden quedar trabados y el que esta haciendo una orden de compra se traba por no poder leer los productos y deja trabado a proveedores, por lo que el que hace una orden de pago deja trabado a ingresos y egresos completando el ciclo.

Ante esta cirscunstancia sql determina grabar lo que puede y por eso quedan recibos sin asiento, facturas faltantes en la cuenta corriente, ordenes de pago huecas y demas.

Otra es que se quede esperando para siempre, no grabaria nada, todo se quedaria trabado hasta que reinicien el servidor.

Por todo esto es que pido que traten de no realizar ese tipo de procesos en el horario normal, igualmente no recuerdo otro de uso cotidiano por ustedes que genere el mismo caos, hay otros que uso yo de noche que de utilizarlos de dia provocarian el mismo lio.