|
|
Når vi har problemer med TPS prosessen dreier det seg enten om at TPS prosessen går ut i feil eller at det ser ut som den henger av en eller annen grunn. I første omgang tar jeg for med det jeg kaller for TPS feil. Senere vil jeg komme tilbake til fenomenet TPS heng; som har andre mekanismer/fenomener inne i bildet. Jeg vil også komme med en revidert utgave av det som er skrevet her om "TPS feil". Dette er første utgave av mitt forsøk på å videreformidle mine erfaringer. Jeg vil komme tilbake med stoff om andre problemstillinger, som heng i TPS prosessen. Sidene vil også gjennomgå redesign m.h.t. layout slik at det på en ryddig og oversiktlig måte kan presenteres tips, råd og løsninger for en rekke andre problemstillinger som kan oppstå. TPS feil kan grovt deles inn i 3 kategorier: 1) Hovedbok problemer - indikert av data i tabellen AGLSHD etter TPS-kjøring. 2) Reskontroproblemer - indikert av data i tabellen ACRSHD etter TPS-kjøring. 3) Problem relatert til faste registre - indikert av melding i loggen til AGRTPS. Mellom 2 kjøringer av AGRTPS skal det ikke finnes data i tabellene AGLSHD og ACRSHD. Som en hovedregel kan vi si at følgende er sant: Dersom SELECT COUNT(*) FROM AGLSHD gir annet resultat enn "0" har vi er hovedbok problem. Dersom SELECT COUNT(*) FROM ACRSHD gir annet resultat enn "0" har vi er reskontro problem. Hovedbok problem Dette vil i utgangspunktet være bilag som ikke går i null, og "synderen" avsløres med følgende SQL:SELECT CLIENT,VOUCHER_NO,SUM(AMOUNT) FROM AGLTRANSACT GROUP BY CLIENT,VOUCHER_NO HAVING SUM(AMOUNT) != 0 Typiske grunner til at vi får stans i TPS prosessen når bilag ikke går i null er: - Det er ikke satt opp konto for agio, smådifferanser, bankomkostninger m.m. - Det er ikke gitt tillatelse til differanser, slik som valutadifferanser (agio). - Differansen er større enn den differansen det er gitt tillatelse til. Dette er ting som ligger i firmaoppsettet i AGRESSO. Reskontro problem Dette skyldes som oftest dobbeltinnlesinger, som fører til forsøk på å legge inn duplikat i reskontro (ASUTRANS)og som blir stanset av en UNIQUE INDEX på CLIENT,VOUCHER_NO,SEQUENCE_NO i tabellen ASUTRANS. Synderen avsløres med følegende SQL: SELECT a.CLIENT,a.VOUCHER_NO,a.SEQUENCE_NO FROM ACRSHD a, ASUTRANS x WHERE a.CLIENT=x.CLIENT AND a.VOUCHER_NO=x.VOUCHER_NO AND a.SEQUENCE_NO=x.SEQUENCE_NO Dette krever gjerne gjerne kraftig lut, d.v.s at man må slette rader fra ACRSHD, etter NØYE analyse. Dette krever en viss erfaring og trenger dere bistand er den ikke lengre unna enn her. Problemer relatert til FASTE REGISTRE
Dette problemet gjelder etter min erfaring primært periode-registeret
(ACRPERIOD). |
|
2007-2008 © www.stenland.com |
|