GICA mémorise maintenant le dernier document (ACHAT ou VENTE) sur lequel travaille un utilisateur.
Si par exemple, l'utilisateur "JL" entre dans le document d'achat "COF/999", les éléments suivants sont enregistrés dans une nouvelle table "locked" de GICA:

    - JL
     - edoca   (le nom du fichier qui contient l'entête du document)
    - COF/999
    - Date
    - Heure
    - Process  (utile pour nous pouvoir tuer une session après le plantage d'un PC)

Ces infos seront affichées si un autre utilisateur veut entrer dans la COF/999 alors que l'utilisateur JL travaille toujours sur le document.

Techniquement, la clef de cette table est constituée par les 2 premiers champs, sinon, tous les documents se retrouveraient dans la table.
Si par la suite, le même utilisateur entre dans un autre document d'achat, cet enregistrement sera modifié avec les nouvelles données mais il n'y aura jamais qu'un seul record "JL + edoca".

Il existe donc malheureusement des cas exceptionnels où l'information affichée ne sera pas correcte.
Par exemple, si un utilisateur "indiscipliné" utilise le même programme sur 2 sessions différentes et entre dans 2 documents différents, il crée 2 "lock" informatiques mais seulement le dernier sera visible dans la table "locked" (vu la composition de la clef de cette table).
Voici donc ce qui peut se passer dans ce cas (qu'il est possible d'interdire dans la configuration d'un dossier GICA):

1) X entre dans COF/999   (date d1, heure h1, process p1)
2) X entre dans COF/2000 (date d2, heure h2, process p2) sans être sorti du COF/999.
3) Y veut entrer dans COF/999 et reçoit "doc utilisé", ce qui est vrai, mais comme infos: "Util: X  Date: d2 Heure: h2 Process: p2".
 
Conclusion:
Cette adaptation donnera plus de confort mais si on veut utiliser les infos affichées autre que le code de l'utilisateur qui travaille sur le document, il faudra être prudent.