Naar aanleiding van een analyse van een geblokkeerde funktie "Index does not match the table" is er m.i.v. deze Releasenote een kontrole ingebouwd die detecteert of een vorige sessie is foutgelopen. Zo ja, dan zal de nieuwe Sessie automatisch beginnen met het reorganiseren van TBC.
Uit de analyse volgt dat het regelmatig voorkomt dat één werkstation op het netwerk onder één naam is ingelogged (bijv. horecaruimte-1 of magazijn-23) doch dat hier meerdere personen mee in Profit werken. Indien eerst gebruiker A een Sessie startte, zijn Profitsessie niet netjes beëindigd (wordt), dan weet Gebruiker A dat als zij verder wil, ze Profit opnieuw moet opstarten en direkt TBC moet reorganiseren. Maar... A verzuimt dit, en gaat naar huis.
De volgende dag komt Gebruiker B, en die start (op hetzelfde werkstation) Profit op. B weet niet dat de sessie van A is foutgelopen, en heeft dus geen idee dat hij eerst TBC moet reorganiseren. Resultaat is dat B op een willekeurige plek kan foutlopen (veelal al direkt bij de eerste Raadpleegfunktie op een Tag-bestand) zonder dat hij eigenlijk ook maar iets verkeerd gegaan heeft; de fout wordt nu veroorzaakt door de eerder foutgelopen sessie van Gebruiker A.
Bij het opstarten van een Profit sessie, zal direkt m.i.v. deze Releasenote worden gekontroleerd of een vorige Sessie netjes is afgesloten. Hierbij kijken we tot maximaal 31 dagen terug naar de historische sessies, en gaan we op zoek naar een Sessie die op dit werkstation heeft plaatsgevonden, maar waarbij in de Sessiegegevens géén eindtijd is geregistreerd; dat laatste is indikatief voor het niet juist hebben afgesloten van een Sessie.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| SYSE | Omschrijving (nog) niet bekend | 05-06-2014 | 05-06-2014 |
