Innehåll. Rebus Extra Funktioner. Sida 1 E-POST KONFIGURATION 2 SMS 4 KORT ONLINE VIA PAYZONE 7 WEB-IMPORT AV KUNDER 9 BOKFÖRINGSEXPORT VIA FIL 15

Transkript

1 Innehåll Funktion E-POST KONFIGURATION 2 SMS 4 KORT ONLINE VIA PAYZONE 7 WEB-IMPORT AV KUNDER 9 BOKFÖRINGSEXPORT VIA FIL 15 OCR-NUMMER (BANKGIRO/PLUSGIRO-AVIER) 17 BETALNING VIA OCR-FIL 22 SKRIVARHANTERING 23 FTP (FILE TRANSFER PROTOCOL) 28 1

2 E-post konfiguration Alla listor och rapporter som kan tas ut från Rebus kan skickas via e-post i olika format, t.ex. PDF-format. Dessutom kan man göra e-post utskick till kunder genom massutskick till vissa kundkategorier. För att kunna skicka e-post från Rebus måste några inställningar göras. Börja i Grund / Generella data. E-post server: Ange namn eller IP-adress till e-post servern. E-post port: Ange port i nätverket för e-post. Standard är port 25. Domän: Anv.namn: Lösen: Om e-post servern kräver verifikation och även windows-auktorisation ska man ange domämnamnet till nätverket här. Om e-post servern kräver verifikation, ange användarnamnet här. Om e-post servern kräver verifikation, ange lösenordet här. För att testa om kontakt finns med e-post servern, klicka på knappen Kontakt. Då visas något som liknar följande ruta. Skillnaden kan vara att det kan stå att kontakt inte gick bra. Motsvarande inställningar finns i följande rutiner p.g.a. att man kan använda andra e-post servrar beroende på vilken användare man är och vilken filial man tillhör: 1. Användare 2. Filialer 2

3 Man kan dessutom ställa in flera andra inställningar som har med e-post att göra: Loggning Markera om skickad e-post ska loggas så att man kan skriva ut en logg-fil på all skickad e-post under en viss period. Logg-filen registrerar också eventuella fel-meddelanden om e-post av någon anledning inte gick att skicka. Läskvitto Om avsändaren vill ha ett läskvitto på en skickad e-post kan man markera det i Generella data. Om man på användarnivå och filialnivå har en egen e-post adress kan man även där sätta en egen inställning för läskvitto. Observera att massutskick av e-post aldrig kan kräva läskvitto, det skulle bli för ohanterligt. Blindkopia Det här valet ska markeras om man vill skicka en blindkopia av all skickad e-post till en särskild e-post adress. Bra att använda om man vill spara all skickad e-post i Outlook hos någon användare. Observera att massutskick av e-post aldrig skickar blindkopior. Kopia till avsändaren Om man väljer att skicka blindkopia till en viss e-post adress kan man också markera det här valet så skickas det en kopia av e-posten även till avsändaren. Vad kan e-postas? Alla listor och rapporter kan e-postas i ett flertal olika format, bl.a. som PDF, till kunder, leverantörer, agenter, reseledare och chaufförer. Filer kan även bifogas. Man kan göra massutskick av e-post till t.ex. en viss kundkategori med bifogade filer. ResPro kan skicka aviseringar till leverantörer när det gäller bokning, ändring och avbokning. 3

4 SMS För att kunna skicka SMS måste en del grunddata registreras i Grund-modulen. I dagsläget har vi byggt support mot företaget Communication Dynamics och deras SMS-tjänst. Kunden sluter avtal med ComDyn så får de en aktiveringskod/konto som ska matas in i Rebus. Se följande grundbild: Rebus kan i dagsläget skicka SMS i några olika rutiner: Via Grund-modulen under menypunkten Skicka / Skicka SMS. Där man kan skapa och skicka ett SMS i taget till en eller flera kunder. Man kan söka efter kund, leverantör, användare, agent, reseledare eller chaufför. Därefter skriver man in SMS-texten (standardtexten visas förvald), spara den och välj eventuellt fler att skicka till. Klicka sedan på Sänd så skickas alla SMS iväg. 4

5 Via Resebyrå-modulen Res-Back under menypunkten: Hem/Avrese-meddelanden. I den här funktionen kan man söka kunder som kommer hem, eller ska resa, en viss datumperiod och man kan välja avreseort och/eller destination samt eventuell leverantör. Vissa byråer använder den här rutinen för att skicka ett välkommen hem -meddelande. I rutinen kan man skriva lista, skriva etiketter, e-posta eller skicka SMS. Alla skickade SMS sparas (åtminstone de 100 första tecken) i en logg-fil som kan skrivas ut via Grund-modulens menypunkt Utskrifter / SMS Loggfil. 5

6 Man kan också skicka SMS direkt från orderbilden i Resebyrå-modulen. I kundregistret kan man för varje kund avgöra om det ska vara tillåtet att skicka SMS eller inte. Det är en del av de begränsningar i företagets marknadsbearbetning som kunderna själva kan avgöra. Det andra är om de vill ha e- post eller tryckta utskick (etiketter). 6

7 Kort online via Payzone (Spectracard) (f.d. Alphyra) Modulen Kort online kan användas i alla Rebus-moduler för att ta betalt på order och fakturor med alla typer av kort, t.ex. VISA och bankkort. Alla filer som behövs för installation finns på Rebus installations-cd under katalogen Spectracard. För att kunna använda betalning med kort online måste först och främst ett avtal upprättas mellan kunden och Payzone så att man får ett konto hos dem för sina betalningar. Rebus kortbetalnings-modul måste köpas av oss på Åbergs DataSystem AB. SERVER på resebyråns interna nätverk: Endast en dator i nätverket ska vara Spectracom-server. Installera den genom att köra programmet "ScoSrv.exe". Programmet på den datorn måste alltid vara startat för att kontakten mot Payzone ska finnas. Om den inte är startad så tror programmet att klienterna som försöker dra ett kort är offline och frågar om "Black list" etc. och vi slänger då upp fönstret för kontrollringning och man måste mata in en kontrollkod som man borde få om man kontrollringer banken för att se om transaktionen bör gå igenom. Kommunikationen mellan Spectracom-servern och Payzone kan ske på flera olika sätt där en fast uppkoppling mot Internet är det enklaste och snabbaste. Vid installationen försöker Spectracom-servern automatiskt koppla upp sig mot Payzone och på vårt eget kontor där vi gjorde installationen i samband med vår utveckling hade vi inte det minsta problem, vi fick kontakt direkt. Det finns andra sätt också t.ex. ADSL och modemuppkoppling men där har vi inte testat själva. Använder man ett fast Internet så får man också snabbast svarstider för varje korttransaktion, endast några sekunder. Programmet "Scosrv.exe" är själva online-servern och den måste alltid vara startad på den dator som agerar server i kundens nätverk. Alla andra datorer på kontoret (klienter) som ska kunna ta online-betalningar kommer att anropa den datorn som i sin tur anropar Payzone och tar emot svaret om det gått bra eller dåligt med korttransaktionen. Svaret skickas direkt vidare till den klient som tog emot kortet och svaret presenteras på skärmen som "Godkänd" eller inte. KLIENTER på resebyråns interna nätverk: Programvaror som måste ligga under \Windows\System32: Scocli32.dll Scalos32.dll OBS: I en "Terminal Server"-miljö fungerar det inte att lägga filerna i den globala System32-katalogen. De måste placeras i den inloggade användarens egna Windows eller System32-katalog. Man kan även placera den direkt i Rebus-katalogen, men risk för krockar blir då större om flera betalar samtidigt eftersom programmet bl.a. skapar loggfiler. Svensk översättningsfil som ska ligga under \Windows (eller \WinNT): err_txt.se Programmet "Scocliin.exe" måste en gång för alla köras på varje klient för att spika IP-numret och Payzones installationsnummer mot den dator som är Spectracom-server i det interna nätverket. GRUND-data: Mata in ett unikt terminalnr på varje användare. Det används även som kassörnummer. Mata in data om Payzone/Spectracard i rutinen Inställningar / Kort Online. Payzones installationsnummer och IP-nummer till servern måste anges. Lägg till ett betalningssätt för kort online i kontoplanen. Sätt en bock för kvitto, transferfaktura, kreditkort och kort online. Betalningar med kort online kan göras i följande rutiner: Faktura Presentkort Arr-Front Arr-Back Res-Front Res-Back Delbetalning/slutbetalning/retur på faktura Delbetalning/slutbetalning/retur på presentkort Delbetalning/slutbetalning/retur på order Delbetalning/slutbetalning/retur på order Delbetalning/slutbetalning/retur på order Delbetalning/slutbetalning/retur på order 7

8 Kvitton kan skrivas ut i samtliga fall förutsatt att man på betalsättet i kontoplanen har markerat att "kvitto" ska kunna skrivas ut. Man kan även skriva ut ett dokument som heter "signature-on-file" om man har bockat för det i samband med dragningen av kortet. Begränsningar: Vid tester med Access som databas har vi upplevt att det inte är riktigt stabilt så därför godtar vi endast onlinetransaktioner då Microsoft SQL Server eller MSDE används. Det innebär rent praktiskt inga problem eftersom vi i allmänhet ändå inte tillåter Access som databas på grund av dess ytterst begränsade pålitlighet. Om kortet Diners TAC används på en betalning så godtar vi inte någon online-transaktion eftersom Diners vill ha alla sådana transaktioner via en fil till sig själva. Om kortnumret börjar på , vilket är prefixet för Diners TAC, så godkänner vi alltså inte någon online-transaktion. 8

9 Webimport av kunder Vissa resebyråer/arrangörer har en egen hemsida där de har ett formulär där kunder kan registrera sig som intresserade av antingen resor eller vill ha en katalog. Om tillverkaren av hemsidan lagrar dessa kunder i en SQL Server databas kan Rebus koppla upp sig mot den och läsa in dem till Rebus kundregister. Rebus kan sätta en kundkategori på dem som sedan kan användas till att skriva ut kundetiketter. Import av intressenterna till Rebus kundregister görs genom att man i kundregistret klickar på knappen som ser ut så här: Klickar man på knappen startas denna inmatningsbild: Importtyp Här finns det i dagsläget tre typer av web-import. Det är gjort till olika kunder och det skiljer lite mellan dem. Typ 1: Häst & Sportresor Typ 2: Tjörnarps Buss Typ 3: Lotus Travel / Svensk-kinesiska resebyrån. Servernamn Rebus behöver veta namnet eller IP-adressen till web-servern där hemsidan och SQL-databasen finns. UserID Här anger man användarnamnet som ska användas för att logga in på web-serverns SQL-server. Password Här anger man det lösenord som krävs för att logga in på web-serverns SQL-server. 9

10 MySQL Om web-serverns databas körs på en Linux MySQL så måste det markeras här eftersom uppkopplingen då ska ske via ODBC istället för via OLEDB Provider. För att det ska fungera så måste MyODBC (3.51) installeras. Den kan hämtas från och installeras på datorn eller också kan vi leverera den eftersom vi har hämtat den därifrån ("MyODBC exe", 732 KB). Provider Här ska man ange namnet på den OLEDB Provider som programmet ska använda för att koppla mot webservern. För en normal Microsoft SQL-server så heter providern "sqloledb". Om man har annan databas på servern t.ex. Oracle så ska annan provider anges. Om man vill koppla mot en Linux MySQL så kan provider utelämnas eftersom man då måste bocka för föregående fält "MySQL" och kopplingen sker via MyODBC. Timeout Ange i sekunder hur lång tid programmet ska försöka få kontakt med servern. Databas Här anger man namnet på den SQL-databas som programmet ska öppna på web-servern. Tabellnamn Här anger man namnet på den SQL-tabell som innehåller de kunder som registrerat sig via web-sidan och som man vill importera till Rebus kundregister. Auto-ID Varje kund som ska skrivas in i Rebus kundregister måste ha en kund-id. Här kan man bestämma om programmet ska ta en automatisk ID eller om man vill använda kundens telefonnummer som kund-id. Hur den automatiska kund-id skapas har bestämts inne i Rebus grundinställningar. Basen är ett löpnummer som man kan formatera på olika sätt (nollutfylld eller inte) samt om man vill ha någon bokstav i första positionen eller inte. Exempel: A00123, Z123 eller enbart 123. Kategori Varje ny kund som skrivs in i Rebus kundregister kan kategoriseras direkt med en kundkategori. Här väljer man vilken som ska användas. Web-import med typ 2 (Tjörnarps buss) och 3 (Lotus Travel / Svensk-kinesiska) saknar detta kategorival eftersom kategorin redan har angivits då kunden/intressenten registrerade sig, den är alltså redan angiven i web-databasen och tas därifrån för varje importerad kund. Kategorifältet får inte vara längre än 8 tecken. "Hämta" När alla fält är inmatade korrekt klickar man på hämta-knappen och då försöker programmet koppla upp sig mot web-servern, logga in sig på SQL-servern samt öppna den angivna databasen och den angivna tabellen. Skulle det inte gå bra så kommer programmet att ge ett meddelande på vad som inte gick bra. Då handlar det nästan alltid om behörighetsproblem i webserver och/eller brandvägg som tekniker på deras sida måste åtgärda för att släppa igenom Rebus. Vid inhämtningen så visas alla kunder som importeras i rutan till höger. 10

11 I de typer (1-3) som vi har i drift idag så innehåller tabellerna följande fält: Web-import typ 1 (Häst & Sportresor) Num Foretag Fornamn Efternamn Adress Postnummer Postaddress Land Telehem Telearb Fax Msgkund Agent Kategori (Uniknr) (Text, max 50 tecken) (Text) (Text) (Text, max 50 tecken) (Text) (Text) (Text, max 50 tecken) (Text, max 25 tecken) (Text, max 25 tecken) (Text, max 20 tecken) (Text, max 50 tecken) (Text, 64 KiloByte) 0=Normal kund, 1=Agent Agents ev. kategori Fältet "Num" är ett unikt löpnummer som vi endast använder som referens när vi ska radera posten från webservern efter att vi skrivit in den i Rebus kundregister. Om fältet "Foretag" är tomt så betyder det att kunden är en privatperson och då används fälten "Fornamn" och "Efternamn" som kundens första namn. Kundens andra namn (attention) blir då tom. Om fältet "Foretag" inte är tomt så betyder det att kunden är ett företag och då läggs företagsnamnet som kundens första namn och fälten "Fornamn" och "Efternamn" som kundens andra namn (attention). Förnamn och efternamn slås ihop med efternamn först som i exemplet "Andersson, Sture". Företagsnamn och attention får i Rebus max innehålla 50 tecken. För att kontrollera om kunden redan finns i Rebus kundregister görs en sökning med företagsnamn, förnamn, efternamn och adress. Finns det en kund med exakt samma uppgifter så markeras den som en uppdatering genom att ändringsdatum på kundposten i Rebus sätts till dagens datum och kundkategorin för kunden skrivs. Postnummer och postadress slås ihop till ett fält i Rebus och får tillsammans ha max 50 tecken. Finns inte kunden sedan tidigare så skrivs en kundpost i Rebus med det kund-id som valts och alla uppgifter i kundposten som lästs från web-servern. Registreringsdatum och ändringsdatum sätts till dagens datum och kundkategorin skrivs. Fältet "MsgKund" skrivs i kundens informationsruta som kan innehålla mycket text. Om kundens land är "NORGE" eller "NORWAY" så sätts kundens valuta till NOK. Om land är "FINLAND" eller "SUOMI" så sätts kundens valuta till EUR. Om land är "DANMARK", "DENMARK" eller "DK" så sätts kundens valuta till DKK. Detta innebär att kunden vill ha bekräftelser och fakturor i sin egen valuta. Om "Agent"=0 så är det en normal kund och då används den kundkategori som valts i samband med webimporten. Om "Agent"=1 så är det t.ex. en finländsk agent som har registrerat och då har de själva angivit kategori på websidan, i det läget ska kundkategori tas från fältet "Kategori" i den framlästa posten. När kunden har skrivits i Rebus kundregister så raderas den från web-servern via referensfältet "Num" och så läses nästa post in och förfarandet upprepas. 11

12 Web-import typ 2 (Tjörnarps buss) Num (Uniknr) Fornamn (Text) Efternamn (Text) Adress (Text, max 50 tecken) Postnummer (Text) Postadress (Text) Telehem (Text, max 25 tecken) (Text, max 50 tecken) Msgkund (Text, 64 KiloByte) Fodelsear (Text 4) Kategori (Text 8) Fältet "Num" är ett unikt löpnummer som vi endast använder som referens när vi ska radera posten från webservern efter att vi skrivit in den i Rebus kundregister. Kunden är alltid en privatperson och förnamn och efternamn slås ihop med efternamn först som i exemplet "Andersson, Sture". Kundens andra namn (attention) blir tom. För att kontrollera om kunden redan finns i Rebus kundregister görs en sökning med namn och adress. Finns det en kund med exakt samma uppgifter så markeras den som en uppdatering genom att ändringsdatum på kundposten i Rebus sätts till dagens datum och den valda kundkategorin för kunden skrivs. Postnummer och postadress slås ihop till ett fält i Rebus och får tillsammans ha max 50 tecken. Finns inte kunden sedan tidigare så skrivs en kundpost i Rebus med det kund-id som valts och alla uppgifter i kundposten som lästs från web-servern. Registreringsdatum och ändringsdatum sätts till dagens datum och kundkategorin skrivs. Fältet "MsgKund" skrivs i kundens informationsruta som kan innehålla mycket text. Fältet "Fodelsear" skrivs också in i kundens informationsruta. När kunden har skrivits i Rebus kundregister så raderas den från web-servern via referensfältet "Num" och så läses nästa post in och förfarandet upprepas. 12

13 Web-import typ 3 (Lotus travel / Svensk-kinesiska resebyrån) ID (Uniknr) Fornamn (Text) Efternamn (Text) Adress (Text, max 50 tecken) Postnummer (Text) Postadress (Text) Land (Text) Telehem (Text, max 25 tecken) Telearbete (Text) (Text, max 50 tecken) Msgkund (Text, 64 KiloByte) Katalog (Text 8) (Kundkategori-ID) Fältet "ID" är ett unikt löpnummer som vi endast använder som referens när vi ska radera posten från webservern efter att vi skrivit in den i Rebus kundregister. Kunden är alltid en privatperson och förnamn och efternamn slås ihop med efternamn först som i exemplet "Andersson, Sture". Kundens andra namn (attention) blir tom. För att kontrollera om kunden redan finns i Rebus kundregister görs en sökning med namn och adress. Finns det en kund med exakt samma uppgifter så markeras den som en uppdatering genom att kundpostens ändringsdatum i Rebus sätts till dagens datum och kundkategorin för kunden skrivs. Ändrarsignatur blir den inloggade användaren. Postnummer och postadress slås ihop till ett fält i Rebus och får tillsammans ha max 50 tecken. Finns inte kunden sedan tidigare så skrivs en kundpost i Rebus med det kund-id som valts och alla uppgifter i kundposten som lästs från web-servern. Registreringsdatum och ändringsdatum sätts till dagens datum. Registrerings/ändrar-signatur blir den inloggade användaren. Kundkategorin kommer från web-databasen och fältet Katalog. Kunden väljer alltså en kategori på hemsidan och det lagras i fältet Katalog. Fältet "MsgKund" skrivs i kundens informationsruta som kan innehålla mycket text. När kunden har skrivits i Rebus kundregister så raderas den från web-servern via referensfältet "ID" och så läses nästa post in och förfarandet upprepas. 13

14 Generellt för alla import-typer När alla kunder är inlästa så visas en ruta upp där det står hur många nya kunder som skrivits in samt hur många kunder som blivit uppdaterade. Alla nya kunder har fått dagens datum som registreringsdatum och kan listas ut via t.ex. kundetikett-rutinen. De visas dessutom med namn i formulärets högra ruta. Alla uppgifter angående server, lösenord m.m. som är inmatade i formuläret sparas och kommer att vara förskrivna nästa gång man går in på rutinen. Sammanfattning I stora drag så tror vi att den här proceduren kommer att fungera mot de flesta kunder, men vi kan bli tvungna att bygga fler varianter av import med tanke på att inte alla web-servrars tabeller innehåller just de här fälten och med just de namnen. Men vi förordar naturligtvis att använda någon av våra tre importtyper om det är möjligt. Utskrift av kundetiketter När man skriver ut kundetiketter kan man göra urval på en del saker, t.ex. från/till registreringsdatum eller ändringsdatum. Det är perfekt i fallet när kunder har hämtats in via web-importen. Hos Lotus Travel gjorde de ofta ett litet fel som gjorde att kunderna fick 8-9 kataloger. Det berodde på att de flera gånger i veckan körde ut etiketter på samma datumperiod och kategori, de räknade inte med att redan utskrivna kunder då skulle skrivas ut en gång till. Därför gjorde vi en möjlighet för dem att byta kategori efter att etiketterna körts ut. De bytte då till en kategori som de inte körde ut etiketter från. Kategoribytet görs endast när man skrivit ut etiketter på skrivaren, inte vid förhandsgranskning. (Det gjorde de faktiskt också fel på, de förhandsgranskade och skrev sedan ut etiketterna från förhandsgranskningen, vilket gjorde att inget kategoribyte gjordes och så fick de dubbletter igen nästa gång de skrev ut) 14

15 Bokföringsexport via fil Alla bokföringsunderlag som skapas av Rebus kan förutom att skrivas ut på papper även skrivas till fil i ett flertal format som kan importeras av olika bokföringsprogram. Dessa filformat klarar Rebus av att exportera: Pyramid SIE-4 Raindance Agresso WinTime Inställningen av vilket format Rebus ska använda görs i Grund-modulens Generella data. Pyramid Det här är en ren textfil som endast används vid export till ekonomisystemet Pyramid. Namnet på bokföringsfilen ska vara t.ex.: C:\Rebus\Bokf.py SIE-4 Det här är ett standardiserat filformat som de flesta bokföringsprogram kan använda. SIE betyder Standard Import Export och 4 betyder att vi supportar nivå 4 i dess specifikationer, vilket enbart är export av bokföringsdata. De andra nivåerna möjliggör export av bokslutssaldon, periodsaldon och objektsaldon från ett bokföringsprogram till ett annat eftersystem. Sådant behöver inte Rebus, vi vill bara exportera bokföringsdata. Det finns ytterligare en SIE-inställning och det är SIE-typ: 0 = Ett verifikat per underlag 1 = Ett verifikat per transaktion Normalt har man inställning 0 (ett verifikat per underlag) vilket innebär att man får en post i filen för kundfakturor, en för kundinbetalningar, en för inkommande leverantörsfakturor och en för betalda leverantörsfakturor. Då får man in en saldering per konto för den aktuella perioden. Om man sätter inställning 1 (ett verifikat per transaktion) kommer Rebus att numrera varje transaktion (enligt bilden ovan) och i stort sett skicka över en hel reskontra till bokföringsprogrammet. Varje faktura, inbetalning etc. kommer att redovisas separat i filen. Det möjliggör att man i bokföringsprogrammet kan följa upp varje enskild transaktion istället för att få t.ex. en hel månads kontering i en klump som med den första inställningen. Vilken inställning som ska användas bör nog företagets revisor/ekonomiavdelning bestämma. Den första inställningen är den som alla använder idag, men tiden jobbar nog för det andra alternativet på grund av den mer detaljerade uppdelningen. 15

16 När man exporterar data till SIE-filen så byggs den på (append) hela tiden tills den har lästs in i ett bokföringsprogram. När den har lästs in markerar bokföringsprogrammet det i filen (via #FLAGGA). Rebus kontrollerar den markeringen så att den nästa gång skapar om filen och börjar fylla den på nytt. Namnet på bokföringsfilen ska vara t.ex.: C:\Rebus\Bokf.si Val 6 är ett specifikt SIE-format för Norge, då måste man också ha skrivit in organisationsnumret för det norska företaget i fältet Org.nr SIE. Detta eftersom svenska och norska organisationsnr inte ser likadana ut. Val 7 är också ett specifikt SIE-format för Interbus. Om man också vill föra över vilket bokföringsår som gäller kan start/slut-datum matas in här. Raindance Namnet på bokföringsfilen ska vara t.ex.: C:\Rebus (d.v.s. endast sökvägen, inget filnamn) Programmet lägger själv på datum och tid så att filen får namnet: C:\Rebus\ _ _ txt Skriver man en kopia av ett bokföringsunderlag så blir filnamnet: C:\Rebus\ _ _100930_K.txt De datum som används är från/till-datum som angivits i bokföringsunderlags-rutinen samt aktuell tid. En kopia får dessutom ett _K som tillägg. Exporten verkar bara fungera på val 1 (Kundfakturor), kör man inbetalningar eller leverantörsfakturor så spårar det ur. Jag har faktiskt inte koll på det här. Lite instabilt tycker jag att det verkar. Programmet borde inte spåra ur, om det bara är kundfaktura som gäller så borde programmet säga det istället för att spåra ur. Funktionen som skriver bokföringsunderlaget på filen verkar också göra en inbetalning på fakturorna så det här är helt klart en specialanpassning till Connex, som är den enda kund som använder det här idag. Agresso Namnet på bokföringsfilen ska vara t.ex.: C:\Rebus\BF Var noga med att sätta ett bokföringsprefix också. Det används i filen för att identifiera företaget. Rebus lägger på datum när filen skapas så att namnet blir: C:\Rebus\BF txt Agresso skapar en fil även då man skriver ut en kopia på bokföringsunderlaget. I dagsläget är det endast Fjällexpressen som använder det här. WinTime Det här är ett norskt format som Peter byggde in till Den Norska Turistföreningen. Men de använder det inte längre, de har gått över till det norska SIE-formatet. 16

17 OCR-nummer (Bankgiro/PlusGiro-avier) När betalningsavier skrivs ut från Fakt, Arr eller Res så kan Rebus skapa OCR-nummer som ska användas för identifikation vid inbetalningen. Dessa OCR-nummer skrivs ut på PlusGiro C-avier eller Bankgiro-avier och betalningen kommer att återredovisas via OCR-filer som ska läsas in i Rebus. Det är skillnad på OCR-numren beroende på vilken modul avierna kommer från och vilket land de används i. OCR-numren beräknas olika om det är svenskt, norskt eller finskt samt om det är PlusGiro eller Bankgiro. Här beskrivs de svenska avierna. Från fria fakturor i Faktura-modulen: OCR-numret börjar alltid med 9 för att visa att det är en fristående faktura. Nästa sex tecken innehåller fakturanumret Nästa sex tecken är vilket visar att det inte finns någon order kopplad mot fakturan. De två sista tecknen 54 är en längdsiffra och en checksiffra. Från Arrangörs-modulen: Det här är ett gammalt format som inte används längre. OCR-numret började med 2 för att visa att det kom från en Arr-order. Nästa sex tecken innehöll fakturanumret Nästa sex tecken var orderns bokningsnr De två sista tecknen 58 var en längdsiffra och en checksiffra. 17

18 Det här är det format från Arrangörs-modulen som gäller nu: OCR-numret börjar alltid med 8 för att visa att det kommer från en Arr-order. Nästa sju tecken innehåller fakturanumret Nästa sju tecken är orderns bokningsnr De två sista tecknen 76 är en längdsiffra och en checksiffra. Motsvarande avi för bankgiro ser ut så här: OCR-numret ser nästan likadant ut. Skillnaden mellan Plusgiro och Bankgiro är alltid, oavsett Rebus-modul, att längdsiffran saknas i slutet. Den sista siffran är alltid en checksiffra, i detta fall 7. Fakturanumret är fortfarande och orderns bokningsnr är fortfarande

19 Från Resebyrå-modulen. PlusGiro-avi på bekräftelse: Avier som skrivs ut direkt från en Res-order skiljer sig en del mot Fakt och Arr på grund av att när vi byggde det här så hade vi redan kunder som använde OCR-inläsningen, därför ville vi inte ändra på den strukturen. OCRnumret består av beställningsnumret 1162 och de två sista tecknen 69 är en längdsiffra och en checksiffra. Från Resebyrå-modulen. Bankgiro-avi på bekräftelse: OCR-numret ser nästan likadant ut. Skillnaden mellan Plusgiro och Bankgiro är alltid, oavsett Rebus-modul, att längdsiffran saknas i slutet. Den sista siffran är alltid en checksiffra. I detta fall är checksiffran 7. Beställningsnumret är fortfarande

20 Från Resebyrå-modulen. En faktura ställs ut med PlusGiro C-avi: När en Res-order faktureras och avier skrivs börjar OCR-numret alltid med 1 för att visa att fakturan är skapad från en Res-order. Nästa sex tecken innehåller fakturanumret Nästa sex tecken är orderns beställningsnr De två sista tecknen 54 är en längdsiffra och en checksiffra. Från Resebyrå-modulen. En faktura ställs ut med Bankgiro -avi: OCR-numret ser nästan likadant ut. Skillnaden mellan Plusgiro och Bankgiro är alltid, oavsett Rebus-modul, att längdsiffran saknas i slutet. Den sista siffran är alltid en checksiffra, i detta fall 4. Fakturanumret är fortfarande och beställningsnr är fortfarande

21 Fakturera ett presentkort, PlusGiro C-avi: När man fakturerar ett presentkort och ställer ut en PlusGiro C-avi ser det ut så här. Att göra på detta sätt är förmodligen inte så vanligt, men det är fullt möjligt. OCR-numret börjar då alltid med 4 för att visa att fakturan är skapad från ett presentkort. Nästa sex tecken innehåller fakturanumret Nästa sex tecken innehåller presentkortsnumret De två sista tecknen 50 är en längdsiffra och en checksiffra. Fakturera ett presentkort, Bankgiro-avi: Som vanligt ser OCR-numret nästan likadant ut. Skillnaden mellan Plusgiro och Bankgiro är alltid att längdsiffran saknas i slutet. Den sista siffran är alltid en checksiffra, i detta fall 2. Fakturanumret är fortfarande och presentkortsnumret är fortfarande

22 Betalning via OCR-fil Programmet för att läsa in OCR-filer finns i Faktura-modulen. Detta för att det är allmängiltigt i hela Rebus och startkatalogen är Rebus Import-katalog (ImportPath). Betalningar kan göras på Fakturor, Arr-order och Res-order. Programmet kan läsa in OCR-filer från: 1. PlusGirot 2. Bankgirot 3. Bankgirots format BGMAX Programmet kan också läsa in OCR-filer från tre olika länder: 1. Sverige, PG/BG/BGMAX 2. Norge, Postgiro 3. Finland, Bankgiro (Bankföreningen i Finland) Man bör använda knappen Skriv ut först för att se vilka betalningar som finns i filen. Knappen Uppdatera utför inbetalningarna på de fakturor/order som står i filen. Därefter skriver man ut en lista så att man ser status på fakturorna/orderna när betalningen är gjord. Om inbetalningsfilen är en BGMAX-fil så innehåller den även manuella betalningar, men den här rutinen kan endast läsa in de poster som är markerade som betalda via OCR. På listan ser man då vilka som är manuellt inbetalda och de får man också betala in manuellt. Rebus kan inte göra det automatiskt p.g.a. att den som betalat in har skrivit betalningstexten helt fritt, det finns alltså inget OCR-nummer att läsa för att matcha betalningen med rätt faktura eller order. 22

23 Skrivarhantering Listformat Blankettval I dessa två rutiner lägger man upp skrivarval för listor och blanketter samt vilka varianter av listor/blanketter som ska användas. Rebus har många varianter att välja bland. Listor är t.ex. kundlista, artikellista, bokföringsunderlag etc. Blanketter är fakturor, resebevis, orderbekräftelse, PlusGiro/Bankgiro-avier, voucher etc. Upplägget i listrutinen är enkelt på så sätt att man för t.ex. valet Kundlista lägger upp ett eller flera alternativ. Många listor kan ha olika alternativ (utseendevarianter) beroende på vilken information som ska visas. Det här beror oftast på vad våra kunder vill ha listan till. 23

24 I blankettval kan man lägga upp flera alternativ där man inom varje alternativ kan ha flera banval. T.ex. kan alternativ 1 ha 2 banval där man först skriver ut en faktura och sedan en PlusGiro-avi. Sedan vill man även ha alternativ 2 där man skriver ut en faktura och en Bankgiro-avi. När man ska skriva ut en faktura väljer man då ett av dessa två alternativ beroende på vilka utskrifter man vill göra. Alla banval inom det valda alternativet skrivs då ut i ett svep. Väljer man däremot att förhandsgranska går det inte i ett svep, då kan man välja vilket av banvalen man vill granska på skärmen. Om man lägger upp alternativ och banval för t.ex. Resebyrå-modulen kan man ha ännu fler banval att skriva ut i ett svep, t.ex. en bekräftelse, en PlusGiro-avi (B eller C), en voucher, en namnlista och en resplan. Man kan alltså kombinera sina alternativ med banval efter behov och önskemål. De upplagda alternativen och banvalen kan man koppla mot skrivare på olika sätt. T.ex. ska fakturan skrivas ut på en viss skrivare från ett visst pappersfack, PlusGiro-avin från en annan skrivare och ett annat fack o.s.v. Dessa inställningar kan enkelt göras i upplägget. Vill man inte hårdstyra till en viss skrivare kan man markera att listan/blanketten ska använda Windows standardskrivare. Då spelar det ingen roll vilken dator man sitter på då t.ex. en kundlista skrivs, den kommer ut på den skrivare som är inställd som standardskrivare på den aktuella datorn. Ett problem man kan få med standardskrivare är den hårda styrningen till pappersfacken som då kanske inte alltid fungerar. Det finns också sätt att sätta specifika skrivarstyrningar per användare. Det gör man genom att använda knappen Användare. Här kan man på en viss lista/blankett (eller alla) välja en annan skrivarstyrning för en viss användare. Det går även att bestämma att just den här användaren ska använda Windows standardskrivare fast alla andra användare är styrda till det generella upplägget, eller har andra skrivarstyrningar specifikt för dem. 24

25 Varianter Det finns också sätt att skapa nya varianter av listor/blanketter beroende på önskade förändringar. Det kan man göra genom att använda knappen Varianter. Normalt gör vi på Åbergs varianter till kunderna enligt deras önskemål och namnger dem på ett visst sätt, då följer de med som standard i nya versioner av Rebus. I exemplet ovan kan man se att en bekräftelsevariant till Biljettbutiken heter RB01BB. Standardvarianten heter RB01. Den här rutinen kan användas om man saknar en variant och snabbt vill lägga till den till systemet. Man kan t.ex. editera RB01, spara den som ett nytt namn RB01TEST. För att kunna välja RB01TEST i blankettvalet och använda den för utskrifter måste den nya blanketten registreras som en variant. OBS: Alla nya varianter som läggs till i Rebus utanför Peters och Görans kontroll måste skickas till oss så att vi får lägga in dem fast i systemet. Annars kommer varianten att saknas när nästa version har installerats. Visa fack Med hjälp av knappen Visa fack kan man se koderna för varje fack för alla skrivare som är installerad på sin PC. Det är bra att ha när man inte får pappret att dra ur rätt fack. Varje skrivare har ofta sina egna speciella koder. 25

26 Användaradministration I rutinen för användaradministration kan man också ändra den användarspecificerade skrivarhanteringen för upplagda listor och blanketter. 26

27 Användare På användarnivå kan följande inställningar göras: Minne Markerar man det här kommer Rebus hela tiden komma ihåg vilken variant av lista som sist användes för användaren och nästa gång man använder samma utskriftsrutin så är det förvalt. Om man inte har markerat är alltid det översta utskriftsalternativet förvalt. Session Markera om Rebus ska behålla sessionsnumret på skrivarnamnet. Det här är bara applicerbart då man använder Citrix eller Terminal Server eftersom skrivarna ofta får ett nytt sessionsnummer adderat till skrivarnamnet varje gång man loggar in. Det här med sessioner är en inställning som teknikerna som installerat och konfigurerat systemet har gjort och kanske inte gäller alla system. Om sessionsnummer används och det är inställt att sessionsnumret ska behållas så tror Rebus alltså att det är en ny skrivare varje gång och man får upp rutan för val av skrivare vid utskrifterna, trots att det egentligen är samma skrivare. Exempel: Skrivaren LaserJet 4500 heter just detta i Rebus. Arbetar systemet med sessioner på skrivarnamnen kan skrivaren heta något av följande LaserJet 4500 IN SESSION 10 eller LaserJet 4500 /SESSION 10. Rebus måste maska bort sessionsnamnen för att veta att det är samma skrivare. Nästa gång man loggar in kanske man får session 11 och rent namnmässigt är det då ytterligare en ny skrivare. 27

28 FTP (File Transfer Protocol) I Grund-modulens Hjälp-meny finns det en rutin som ger möjlighet att skicka iväg filer till vår FTP-server. Den rutinen ska användas då kunderna har för stora filer som inte kan e-postas. Vi tänkte då särskilt på dumpade SQL-databaser. Ibland behöver vi ju få hit kundens databaser för att kunna testa och leta efter ett fel. Det bästa vore då om kunden gjorde en backup av databasen, zippade filerna och därefter använde den här rutinen för att skicka dem till oss. Att vi vill att de zippar filerna först är att de då komprimeras ganska mycket och går därefter fortare att sända över. De tar mycket mindre plats också. FTP-rutinen kan även användas av de som kör Rebus Resebyrå/Producent-modul med Internetbokning. Då kan man skicka över alla bilder på sina produkter till webservern. Markera först rutan Sänd web-bilder och ange den webkod som vi tillhandahåller. 28