Systembeskrivning Total Office Fakturasystem

Systembeskrivning Total Office Fakturasystem Version 1.0 2004-05-10 http://www.nada.kth.se/projects/prom04/fakturasystem/ Uppdragsgivare: Gruppmedlemmar: Örjan Melin David Johansson Pushparaj Silva Robert Celik Magnus Steen Christian Illanes Niklas Kullberg Johan Säfström Inga Nkomo 1

Innehållsförteckning 1 INLEDNING...3 2 SYSTEMBESKRIVNING...4 2.1 PALM...4 2.1.1 Process...4 2.1.2 Databaser...5 2.2 MAILHÄMTNING...6 2.2.1 Moduler...6 2.2.2 Funktion...6 2.2.3 Felhantering...7 2.2.4 Konfiguration...7 2.3 DATABASEN...7 2.3.1 Databasdesignen...8 2.3.2 Beskrivning av databasdesignen...9 2.3.3 Spegling...11 2.4 WEBBINTERFACE...11 2.4.1 Syfte...11 2.4.2 Uppbyggnad...11 2.4.3 Administrationsverktyg...14 2.4.4 Funktionalitet...14 2.4.5 Säkerhet...14 2.4.6 Vidareutvecklingsmöjligheter...15 2.5 UTSKRIFT...15 2.5.1 Skapande och användande av mall...15 2.5.2 Verifikat...15 2.5.3 Hämtning av data från databasen...16 2.5.4 Format för frågor till databasen...16 2.5.5 Översättning till SQL...16 2.5.6 OCR-kodrad...16 2

1 Inledning I detta dokument beskrivs de tekniska detaljer som bygger upp Fakturasystem. En systemskiss kommer nedan som ska ge en överskådlig bild av hur systemet fungerar. Figur 1 Översikt av systemet. 3

2 Systembeskrivning Nedan följer en systembeskrivning för samtliga delar som ingår i projektet. 2.1 Palm Det är i handdatorn som användarna skapar deras fakturor, varvid de skickas krypterade till en POP3-mailserver 2.1.1 Process Programmet består av sju huvuddelar. Dessa är: 1. Val av fakturadatum 2. Val av användare 3. Val av mottagare 4. Tilläggning av produkter 5. Val av betaldatum 6. Val av fakturanummer 7. Bekräftning av fakturan innan den skickas I figur 2 nedan beskrivs sambanden mellan dessa delar i ett processdiagram. Figur 2 Processdiagram: Översikt 4

En utveckling av delen Choose Produkter beskrivs i figur 3. Figur 3 Processdiagram: Choose Produkter 2.1.2 Databaser Programmet använder sig av ett flertal databaser för att upprätthålla sin funktionalitet. De flesta av dessa databaser är gemensamma med de två färdiga programmen Kvitton 1 och Fakturor 2 vilka enbart hanterar redovisning. I tabell 1 nedan följer en översikt av alla ingående databaser samt en kort beskrivning av dessa. 1 Färdigt program konstruerat av Total Office 2 Färdigt program konstruerat av Total Office 5

Namn Beskrivning Kvitton och Fakturor Fakturasystem Adress.pdb Innehåller företagets adressuppgifter mm. Ansvar.pdb Innehåller alla användare av systemet Mallar.pdb Används för att spara information om ej definierade produkter Verifikat.pdb Innehåller redovisningsunderlag Mail.pdb Inbyggda maildatabasen i Palm OS Produkter.pdb Definierade produkter TempProd.pdb Tabell 1 Databaser Temporär databas som används för att lagra produkter och deras belopp under skapandet av en faktura - 2.2 Mailhämtning 2.2.1 Moduler Mailhämtningen består av två huvudmoduler: Java-programmet Popper och Visual Basic-programmet ParseMail. ParseMail består i sin tur av två moduler, modparsemail och modsendemail. modparsemail innehåller den körbara main-metoden och funktioner för att dekryptera, tolka och spara information från e-mail i databasen. modsendemail innehåller funktioner för att skicka e-mail. 2.2.2 Funktion Vid körning av Mailhämtning.bat startas javaprogrammet popper som hämtar hem e-mailen från POP3-mailservern och lägger dessa som filer i en underkatalog vid namn mail. När popper har kört klart startas 6

ParseMail.exe. ParseMail läser in varje e-mail från katalogen mail. I tur och ordning dekrypteras, tolkas och lagras i mailen i databasen. Sedan flyttas de till en katalog för arkivering. När katalogen mail är tom, det vill säga alla e-brev har behandlats, så avslutas ParseMail. E-mailens färd genom mailhanteringen: Handdator Mailserver Popper ParseMail Databasen 2.2.3 Felhantering Om ett fel inträffar under körning av ParseMail så kommer det problematiska e-mailet att flyttas till en särskild katalog där det kan tas om hand senare. Vid slutet av körningen kommer även ett e-mail som sammanställer de fel som uppkommit att skickas iväg till en administratör eller liknande. Anledningen till detta är att ParseMail är menat att schemaläggas och då är det inte alltid som man kan ta om hand om problem som uppstår på en gång utan exekveringen måste kunna fortsätta. 2.2.4 Konfiguration Popper konfigureras genom textfilen settings.txt. ParseMail konfigureras genom textfilen ParseMail.ini. Mer information om detta finns i användarhandledningen. 2.3 Databasen Databasen är den del som är hjärtat i hela projektet. Den sammankopplar alla andra delar genom att innehålla all viktig information. Nedan beskrivs databasen mer utförligt. 7

2.3.1 Databasdesignen Figur 4 Databasdesignen 8

2.3.2 Beskrivning av databasdesignen Foretag: Företagen som är kunder hos Total Office Mobile Systems, d.v.s. de som skickar fakturor. ForetagsID, PRIMARY KEY INT NOT NULL AUTONUMMER ForetagsNamn VARCHAR(40) NOT NULL OrgNummer VARCHAR(20) NOT NULL GatuAdress VARCHAR(60) NOT NULL PostAdress VARCHAR(60) NOT NULL Telefon VARCHAR(20) NOT NULL Mobil VARCHAR(20) NOT NULL Fax VARCHAR(20) NOT NULL Mail VARCHAR(40) NOT NULL Loggo: Loggot för varje enskild företag. ForetagsID PRIMARY KEY INT NOT NULL Sokvag VARCHAR(200) NOT NULL Inloggning: Inloggningsuppgifter på webben för varje enskild företag. Username PRIMARY KEY VARCHAR(50) NOT NULL Password VARCHAR(50) NOT NULL ForetagsID INT NOT NULL Betalningsinfo: Betalningsinformation för ett specifikt företag. ForetagsID PRIMARY KEY INT NOT NULL Postgiro VARCHAR(20) Bankgiro VARCHAR(20) DrojsmalsRanta FLOAT Personer: Personer som är anställda av företaget samt personer som är kunder till företagen. PersonID PRIMARY KEY INT NOT NULL AUTONUMMER Fornamn VARCHAR(25) NOT NULL Efternamn VARCHAR(25) NOT NULL Pnr INT(12) HarAnstallda: Kopplar ihop vilka som är anställda hos ett specifikt företag. PersonID PRIMARY KEY INT NOT NULL ForetagsID PRIMARY KEY INT NOT NULL Adress: Adressen för personen som fakturan skickas till, samt företaget denne jobbar hos. AdressID PRIMARY KEY INT NOT NULL AUTONUMMER 9

ForetagsNamn VARCHAR(40) GatuAdress VARCHAR(60) NOT NULL PostAdress VARCHAR(60) NOT NULL Email VARCHAR(30) PersonID INT NOT NULL Custom: Övrig information hos personer som är kunder, t.ex. organisationsnummer, kundnummer m.m. CustomID PRIMARY KEY INT NOT NULL AUTONUMMER Beskrivning VARCHAR(200) NOT NULL Data VARCHAR(250) NOT NULL PersonID INT NOT NULL Nummer: Information som telefonnummer, mobilnummer, faxnummer m.m. NummerID PRIMARY KEY INT NOT NULL AUTONUMMER Nummer VARCHAR(30) NOT NULL Beskrivning VARCHAR(100) NOT NULL PersonID INT NOT NULL Produktinfo: Information om varje produkt. ProduktInfoID PRIMARY KEY INT NOT NULL AUTONUMMER Namn VARCHAR(60) NOT NULL Moms INT(2) NOT NULL Produkter: Mer specifik information (priset) om en produkt som har sålts. ProduktID PRIMARY KEY INT NOT NULL AUTONUMMER Pris Decimal(10,2) NOT NULL ProduktInfoID INT NOT NULL Faktura: Information om alla fakturor. (Denna information ska sparas 10 år i databasen). FakturaID PRIMARY KEY INT NOT NULL ForfalloDatum DATE NOT NULL FakturaDatum DATE NOT NULL FakturaNummer INT NOT NULL DrojsmalsRanta FLOAT Postgiro VARCHAR(20) Bankgiro VARCHAR(20) Utskriftstid DATETIME ForetagsID INT NOT NULL SandarePersonID INT AdressID INT NOT NULL 10

ProduktTillFaktura: Alla produkter som ska skrivas ut på en specifik faktura. VerifikatNummer INT NOT NULL ProduktID PRIMARY KEY INT NOT NULL FakturaID PRIMARY KEY INT NOT NULL NyaFakturor: Alla nytillkomna fakturor i systemet. Dessa har alltså inte skrivits ut ännu. FakturaID PRIMARY KEY INT NOT NULL 2.3.3 Spegling Total Office Mobile Systems har två databaser, ett lokalt och ett hos sajthotellet (ett webbhotell). På sajthotellets databas kommer logotypen hos varje företag att laddas upp, medan den lokala kommer få in all annan information. För att kunna ha backup, underlätta en eventuell flyttning av den lokala databasen och minska risken för att hela systemet blir oåtkomlig för kunderna behövdes någon form av spegling. Därför gjorde vi ett batch-script som speglar över logotypinformationen från sajthotellet till den lokala databasen. Dessutom speglas informationen i den lokala databasen till sajthotellet. De båda databaserna kommer nu alltså vara backup till varandra. 2.4 Webbinterface 2.4.1 Syfte Totaloffice hade redan vid projektets start en fungerande webbsida. Vår uppgift har varit att vidareutveckla denna sida med basen för ett webbinterface, skrivet i ASP. Syftet med webbinterfacet är att företagen skall kunna göra en hel del inställningar via webben, samt att kunna utnyttja vissa tjänster. Att göra inställningar via webben underlättar både för kunderna samt för Totaloffice. Exempel på inställningar kunderna kan göra är: Ladda upp logotyp (till företagets fakturor), ändra dröjsmålsränta och byta lösenord. I dagsläget finns inga andra tjänster klara, men det är tänkt att det i framtiden ska finnas möjlighet att skapa fakturor på webben, få en översikt av sin ekonomi, samt att kunna planera sin personaltillgång med tjänsten Personal Planner. Webbinterfacet ska vara lösenordsskyddat och säkerheten ska vara medtagen på alla sidor som rör kundens egen information. 2.4.2 Uppbyggnad Webbinterfacet består till största delen av en mängd webbsidor skrivna i ASP. Många av sidorna är knutna till databasen på Sajthotellet (Se avsnitt 11

2.3), och även sidorna i sig ligger lagrade där. Webbinterfacet ansluter bara till databasen på Sajthotellet, vilket gör att webbanvändningen rent fysiskt är skiljt från Totaloffice lokala servrar. Detta är fördelaktigt ur säkerhetssynpunkt. För att det hela ska bli så enkelt som möjligt har vi försökt strukturera upp all ASP-kod med hjälp av funktioner. Vissa av ASP-filerna innehåller enbart funktioner som andra filer anropar. Nedan följer en lista med alla funktionsfiler samt en kort beskrivning av var och en av dem. Totalofficelayout.asp Beskrivning: Den här filen innehåller flera funktioner för att skapa den layout som återfinns på Totaloffice sidor. Funktioner: gettotalofficeheadinfo() gettotalofficebodydefinition() leavetotalofficebodydeffinition() gettotalofficelayout() gettotalofficelayoutmenu() Database.asp Beskrivning: Den här filen innehåller funktioner för att skapa en anslutning, och arbeta mot databasen Funktioner: getconnection() getrecordset() Loginfunctions.asp Beskrivning: Den här filen innehåller alla funktioner som hanterar inloggning och utloggning, och kontroll av att användaren är inloggad. Funktioner: login() loggedin() logout() getloginform() MD5.asp Beskrivning: Den här filen innehåller en funktion för kryptering av lösenord. Koden är tagen från http://www.frez.co.uk och är fri att använda med vissa restriktioner. Dessa finns medtagna i filen. Funktioner: Md5() 12

Geometry.asp Beskrivning: Filen innehåller funktioner för att rita upp olika geometriska figurer mm. Funktioner: drawrectangle() drawroundrectangle() drawstring() drawimage() Invoice.asp Beskrivning: Denna fil innehåller allt som krävs för att rita upp fakturamallen och för att få nödvändig information ifrån databasen. Den innehåller till exempel funktioner för bilduppladdning. Funktioner: getinvoiceexampleinfo() getinvoiceloggofromdb() setinvoiceloggo() getinvoiceadressfromdb() getinvoicetelefonfromdb() getinvoicefaxfromdb() getinvoiceorganisationsnrfromdb() getinvoicemailfromdb() +en mängd andra funktioner Password.asp Beskrivning: Innehåller funktioner som hanterar ändring av lösenord. Funktioner: getcurrentpassword() setnewpassword() getchangepasswordform() Tokenizer.asp Funktioner: Tokenizer() getnexttoken() getnexttokenseparatedby() Här är en lista med övriga filer som inte innehåller några funktioner, men sköter själva hanteringen av webbsidorna: Index.asp Login.asp Loginpage.asp 13

Logout.asp Changepassword.asp Imageupload.asp Upload.asp 2.4.3 Administrationsverktyg Administrationsverktyget används för att skapa och redigera användare som ska kunna logga in på företagets sidor på Webben. Programmet AdminTool.exe kopplar upp sig mot databasen enligt parametrar som hämtas från AdminTool.ini. Från databasen hämtas automatiskt en lista på tillgängliga företag som användaren kan välja i en drop-down-ruta. Om man trycker på Hämta så hämtas alla användare som finns registrerade på det valda företaget. Lösenordet kan antingen genereras eller skrivas in manuellt. Innan lösenordet lagras i databasen hashas det med MD5-metoden. När den första användaren skapas på ett nytt företag så genereras automatiskt initiala Null-värden för företagets faktureringsuppgifter. Connection String för uppkoppling mot databasen finns i filen AdminTool.ini där den kan redigeras. 2.4.4 Funktionalitet Den funktionalitet som webbinterfacet erbjuder idag är: Inloggning med hjälp av sessioner (Cookies) säkra inre sidor automatisk utloggning vid inaktivitet blockering av att kunna se tidigare sidor efter utloggning kryptering av lösenord möjlighet att ladda upp företagets logotyp till fakturan kontroll av bildstorlek och filformat vid bilduppladdning Presentation av en fakturamall med företagets logotyp på Möjlighet att ändra lösenord för inloggning Utloggningsfunktion 2.4.5 Säkerhet Eftersom informationen som presenteras på webbinterfacets sidor kan vara känsliga för kunderna skyddas alla sidor av en särskild inloggningskontroll. Företagen kommer först till en inloggningssida. Här måste man ange användarnamn och lösenord för att kunna komma in och läsa innehållet innanför. Vid en korrekt inloggning skapas en session på servern och en på användarens dator, vilket betyder att användaren har fått rättighet att besöka webbinterfacets sidor. Sessionen är tidsbegränsad vilket innebär att om man inte gör någonting aktivt på webbinterfacets sidor inom 5 minuter så blir man utloggad. Eftersom servern förstör sin session när 14

detta händer, är det inte möjligt att komma tillbaka till sidor genom att backa i sin webbläsare. Det är inte heller möjligt att nå någon av webbinterfacets inre sidor genom att undvika inloggningssidan, eftersom alla inre sidor kräver en existerande session. Företagens användarnamn och lösenord sparas i databasen, men lösenorden krypteras innan de lagras, och på så sätt blir det omöjligt för andra att avläsa dessa från databasen. Algoritmen som används vid krypteringen är en hashningsalgoritm kallad MD5. Denna är irreversibel vilket betyder att den inte går att dekryptera. 2.4.6 Vidareutvecklingsmöjligheter Vi har hela tiden haft som mål att utveckla en bra bas för ett webbinterface. Vi förstod tidigt att detta skulle få en signifikant betydelse för systemet i framtiden. En funktion som säkert kommer att vara av intresse fär många, är att visa sammanställningar av företagets ekonomi. För att det ska vara så lätt som möjligt att bygga på och ändra på webbinterfacet, har vi lagt upp det mesta som funktioner (se ovan). Det finns funktioner för säkerheten, databaskoppling, layout osv. Detta gör framförallt att det är enkelt att lägga till nya sidor. Vi har även tänkt på att man kanske vill kunna få fakturainformation presenterad på en fakturamall som den vi använder för att visa företagens logotyp. Därför är även denna fakturamall uppbyggd av funktioner istället för att bara visa en inskannad bild. Systemet skulle således även kunna utökas med tjänsten att skicka fakturor via Internet, istället för att alltid använda sig av handdatorn, utan någon större svårighet. 2.5 Utskrift När detta program körs sker följande: först läses en lista på nyinkomna fakturors id-nummer in från databasen. Om antalet är noll så avslutas programmet. Annars genereras en mall av en faktura. De nyinkomna fakturorna skapas med hjälp av denna och skrivs sedan ut. Därefter markeras fakturorna som utskrivna i databasen. 2.5.1 Skapande och användande av mall Programmet har två interna bildobjekt. I en av dem skapas en mall av en faktura. Den ser ut som den färdiga fakturan, men är inte ifylld med de egentliga data (adresser osv.) För varje faktura som skrivs ut kopieras innehållet i mallbilden över till det andra bildobjektet och fylls i med relevant data. Därefter skrivs den ut. 2.5.2 Verifikat När fakturan skrivits ut ska en verifikatfaktura skrivas ut. Denna skapas med hjälp av den redan ifyllda fakturan. Det enda som fylls i är 15

verifikatnummer. Därefter skrivs verifikatfakturan ut. Det är alltså denna faktura som sedan skickas till avsändaren. 2.5.3 Hämtning av data från databasen I konfigurationsfilen står vilken data som ska hämtas från databasen. Kommunikationen med databasen sker via en ODBC-drivrutin som tar emot SQL-kommandon. Men i konfigurationsfilen står istället frågor till databasen i ett programspecifikt format. Detta översätts till SQL i programmet. Anledningen till att vi valt att skriva med ett programspecifikt format är att det annars skulle bli en hel del select/from/where -satser, vilket skulle göra filen mer eller mindre oläslig. 2.5.4 Format för frågor till databasen Alla databasfrågor i konfigurationsfilen omskrivs av <>. Formatet för databasfrågor i konfigurationsfilen är: tabell[nyckel]data. Den frågan skulle hämta attributet data från tabellen tabell, på den rad där attributet nyckel har det värdet som är aktivt värde. Aktivt värde hämtas från listan av nyinkomna fakturor, eller från databasen. Exempel: I frågan <a[b]c> söker man upp det värde på c, som finns i a på det ställe där b är id:t av den faktura som just nu behandlas. Om man istället vill hämta ett värde från databasen att indexera med, sker det med @. Exempel: I frågan <a[b]c@d[e]f> söker man upp c i a, där b är aktivt fakturaid. Därefter används värdet från c för att hitta f i tabellen d, där e=c. Det kan byggas ut i godtyckligt många nivåer, t.ex. är <a[b]c@d[e]f@g[h]i@j[k]l@m[n]o@p[q]r> en giltig fråga. Dessutom kan man använda formler i databasfrågorna. Formler måste omskrivas av {}. Man kan t.ex. skriva {<a[b]c@d[e]f>+<g[h]k>*3}. 2.5.5 Översättning till SQL Översättningen av databasfrågor utförs genom att frågan bryts upp och omtolkas till SQL på ett trivialt sätt. Se kod för närmare beskrivning. 2.5.6 OCR-kodrad En kodrad för OCR (Optical Character Recognition) skapas enligt Postgirots anvisningar. I det ingår fakturanummer med längdsiffra och kontrollsiffra, formaterat belopp och kontrollsiffra, samt formaterat postgironummer. OCR-kodraden måste placeras på ganska exakt rätt ställe (enligt Postgirot 16,9 mm från blankettens nedre kant). Om fakturans post i databasen inte innehåller postgironummer kommer OCRkodraden att bli oläslig för Postgirots OCR-maskiner, men om inget postgironummer finns kan man ändå inte betala via postgiro. 16

OCR-koden skrivs ut bokstav för bokstav, dvs. inte som en text, med ett specifikt teckenavstånd. Vid eventuellt byte av teckensnitt så kommer varje specifikt tecken alltid att hamna på rätt plats, storleken på tecknen kan dock behöva ändras. Det teckensnittet som medföljer är OCR-B (i enlighet med Postgirots anvisningar) och teckenstorlek har valts till 11 punkter. Det bör dock påpekas att olika OCR-B teckensnitt kan se olika ut, det som medföljer är det som vanligtvis finns på andra postgiroblanketter. 17