Varken bokföringsnämnden, revisorerna eller någon annan vet hur det ska se ut.

Av CARL GUSTAF RUMENIUS

Bokföringslagen anger med all önskad tydlighet att bokföring skall ske kronologiskt och systematiskt beträffande alla affärshändelser för vissa typer av bolag och föreningar. I bokföringsskyldigheten innefattas även att rörelsens ekonomiska resultat och ställning skall redovisas och att affärshändelserna skall dokumenteras med verifikationer och att dessa skall arkiveras tillsammans med bokföringsböcker och annat räkenskapsmaterial. Användes automatisk databehandling i bokföringssystemet skall beskrivningen kompletteras med systemdokumentation och behandlingshistorik.

Av ovanstående kan uttydas att beskrivningar skall ske beträffande affärshändelser samt i den mån ADB användes även av system och behandlingar.

Man kan med olika framgång verbalt beskriva eller definiera något som är enhetligt och klart avgränsat tex en affärshändelse, speciellt om denna dessutom redan är dokumenterad med en faktura eller dylikt. Svårare blir det att beskriva något immateriellt tex en behandling. Allra svårast blir det att beskriva ett system om man inte först gjort klart för sig vilka delar systemet består av och vad som utgör systemets gränser samt vilket språk som kan vara lämpligt att beskriva systemet i.

När ADB är inblandat kan man naturligtvis säga att ett bokföringssystem består av en del ADB och en del bokföring, men eftersom bokföring och ADB många gånger hänger ihop blir uppdelningen av ett bokföringssystem i klart avgränsbara delar vanskligt.

Inom ADB har många försök gjorts att nå fram till en enhetlig systemdokumentation för definierade ADB-system i vissa systemutvecklingsmodeller, men antalet metoder har varierat och vidareutvecklats allteftersom nya tekniker inom ADB har introducerats.

Jag skulle själv inte försöka mig på att beskriva ett ADB-bokföringssystem utan mycket klart givna förutsättningar och med ett språk som specialanpassats för denna uppgift.

Eftersom syftet med denna artikel är att redogöra för min tolkning av system-dokumentation och behandlingshistorik, skall jag emellertid tillföra några synpunkter.

Den givna förutsättningen som jag utgår ifrån är att bokföringen är ett resultat från indata som matats in i ett totalintegrerat ADB-system. Språket som jag använder är svenska språkets syntax plus ett dataspråk som heter dBASE. Det totalintegrerade systemet kallar jag MIS (management information system). MIS är ett applikationssystem som lagrar data i sk relationsdatabaser och som använder dessa databaser vid beräkningar och utskrifter.

Eftersom data matas in i ena änden av systemet och kommer ut i andra änden i den form som bokföringslagen anger bör systemdokumentationen enligt bokföringsnämndens anvisningar avse en beskrivning av ADB-systemets uppbyggnad och

behandlingshistoriken omfatta en beskrivning av de dokument som innehåller uppgifter om genomförda bearbetningar.

ADB-systemets uppbyggnad

För att förena krav på utförlig systemdokumentation med användarvänlighet i systemet byggs lämpligen systemdokumentationen in i de menylayouter som styr behandling av inrapportering, bearbetning och utrapportering i systemet. Systemdokumentationen blir på så sätt en innehållsförteckning av de funktioner, som ingår i systemet och behandlingshistoriken en redovisning av de utdatarapporter som systemet genererar med uppgifter om de tidsscheman som gäller för resp rapport.

För att systemdokumentationen skall bli överskådlig och detaljerad är menyerna indelade i ett mönster som motsvarar de delsystem som genererar data till bokföringssystemet. Således finns en meny för ordersystemet, en meny för fakturering och reskontra samt en meny för vardera inköp och löner.

Varje meny liknar varandra. De första kommandona omfattar registrering av grunddata, de följande kommandona omfattar rapportutskrifter och därefter ändrings- och servicekommandon.

Bokföringssystemet är en del av MIS och någon ytterligare indelning av MIS i bokförings- och ADB-system behövs ej göras. För den datafrälste kan nämnas att dBASE-databasernas utseende säger en del om hur systemet fungerar rent tekniskt.

I och med att indata och utdata lagras i databaser och aldrig försvinner från systemet kan transaktioner skrivas ut vid vilka tidpunkter som helst. Kontroller och avstämningar är också möjliga att göra oberoende av tiden.

Stundom kan läsas att komplexa system är sårbara och oöverskådliga. Detta kan vara riktigt om data dubbellagras i olika register. Säkerheten sjunker drastiskt då data dubbellagras. Finessen med systemintegration är emellertid att systemet ej behöver betraktas som skiljda delsystem med alla de problem som hör därtill.

En fördel med integrerade system av typen MIS är att databaserna är oskiljaktigt förenade med den programvara som arbetar mot dem. Ur säkerhetssynpunkt är detta oskattbart. Systemet kan ej arbeta om en databas ej kan öppnas eller om någon databas saknas eller har förändrats.

Systemintegrationen gör systemet oberoende av organisatoriska förändringar. Bokföringens organisation kan ordnas utan att systemet behöver förändras. Interna kontroller kan lätt läggas in som endast ger viss personal tillträde till vissa databaser.

Systemintegrationen gör det också möjligt för revisorn att ställa krav på avstämningar, kontroller od. Systemet är lätt att kontrollera eftersom databaserna medger extraktioner av data för speciella kontroller. Relationsdatabasidéen innebär att data förvaras endast på ett ställe, vilket gör det lätt att kontrollera att data alltid är komplett och korrekt.

Egentligen skulle behandlingshistoriken ej rubriksättas eftersom denna dokumentation är en del av systemdokumentationen. Men eftersom bokföringsnämndens anvisningar tar upp denna del för sig kan jag inte avstå från att göra på samma sätt. I behandlingshistoriken skall lämnas redogörelse för databearbetningar, systemförändringar, systempåverkningar och avstämningar.

Enligt mitt synsätt kunde behandlingshistoriken vara ett sammanfattande namn för samtliga utdataprodukter ur systemet, där resp produkt är identifierad med beställare, dokument-/rapportnamn, datum, antals- och beloppsuppgifter samt referens till annat motsvarande dokument eller rapport. Bokföringens grundbok är ingenting annat än huvudbokens poster sorterade i datumordning.

I ett relationsdatabassystem typ MIS sker sällan enskilda databearbetningar. Databearbetning är ett ord som förknippas med sk satsvis bearbetning i äldre sk batchsystem i motsats till realtidsbearbetning eller direkt bearbetning, som är förknippat med relationsdatabassystem. Vid inrapportering av data i relationsdatabassystem genereras transaktioner som lagras i databaser. I samband med detta uppdateras olika fält i posterna, som kan vara summor, konton od. När sedan rapporter genereras sker summeringar, ackumuleringar och andra operationer. Således dokumenteras i viss mån de olika bearbetningsprocesserna av menyernas och rapporternas utformning.

Systemförändringar sker oftast kontinuerligt i ett system typ MIS. Komplexa system har en benägenhet att förbättras och effektiviseras för att tillfredsställa nya användarkrav. Dessa förändringar avspeglas omedelbart i menyernas och rapporternas utseende och i de hjälpfunktioner, som ger utförligare information om systemets funktion och hantering.

Systempåverkningar förekommer ej annat än vid olyckstillfällen eller otillbörliga intrång.

Avstämningar görs oftast vid rapportutskrifter eller vid utnyttjande av sk frågespråk. En revisor kan med hjälp av dBASE-kommandon göra utsökningar av transaktioner i olika register och behandla dessa poster för sig oberoende av huvudsystemet.

Fjärde generationens utvecklingshjälpmedel medger att systemkonstruktörer kan framställa ADB-system, som i komplexitet och "intelligens" ersätter mänskliga funktioner, sk expertsystem. Gränserna sätts ej längre av kapacitet och snabbhet i de datorer, som lagrar och behandlar data utan ligger på det mänskliga planet. Metoder att skapa informationsstruktur i enskilda transaktioner och systematisera grundregister samt att ordna informationen i enhetliga system är den vetenskap som utgör förutsättningen för att utveckla allt effektivare och intelligentare datorer.

Kunskap om system och applikationer byggs in i dagens datorer och redovisas sannolikt endast då myndigheten kan ställa konkreta frågor eller redovisa klara regler för hur dokumentationen av ett system skall se ut. Ett av de starkaste skälen till denna förmodan är att konkurrensen inom dataområdet numera ligger på programvaru- och applikationssidan. Med detta vill jag säga att det finns metoder för strukturering och systemkonstruktion, som ligger långt fram i utvecklingen, men som av konkurrensskäl ej gärna redovisas.