ORIfin kan facturen produceren aan de hand van een tabel waarin staat aangegeven welke bedragen om welke reden door welke relaties betaald moeten worden.

De basis daarvoor komt van twee kanten: allereerst een bestand (tabel) met de verschillende bijdragen waar het om gaat en daarnaast een bestand waarin staat wie welke bijdrage moet betalen. Beide bestanden kunnen geheel in ORIfin worden opgebouwd, maar ze kunnen ook worden geïmporteerd uit andere programma’s zoals @VO.

Bijdragen worden toegekend en uiteindelijk doorgeboekt naar de financiële administratie. Het is van groot belang goed bij te houden of dat doorboeken al plaats heeft gevonden of niet. Het belangrijkste gegeven in de bijdragenbestanden is daarom de “status toegekende bijdragen” in ORIfin.

Geeft die status aan dat het doorboeken al heeft plaatsgevonden, dan is elke wijziging op de toegekende bijdragen zinloos. Pogingen daartoe worden dan ook geweigerd. De mogelijkheid die dan wel wordt aangeboden is: haal alle toegekende bijdragen weg en ga opnieuw beginnen met het toekennen. De tabel bijdragen blijft daarbij volledig intact.

➔ Zijn er fouten gemaakt bij het toekennen en er is al doorgeboekt, dan moet er een oplossing worden bedacht buiten de bijdragen om. Of u moet een back-up terug zetten van de financiële administratie EN van de bijdragen van vlak VOOR het doorboeken. Dit geeft ook al aan dat het doorboeken secuur moet gebeuren en dat goed moet worden gekeken of dit doorboeken het gewenste resultaat op heeft geleverd, voordat er vol enthousiasme wordt doorgewerkt.

N.B. Om te voorkomen dat er verschillen kunnen ontstaan tussen doorgeboekte bedragen en de bedragen die op de facturen staan, is het pas mogelijk facturen te printen NADAT er is doorgeboekt.

Dit geeft nog eens extra aan hoe belangrijk het is om eerst de uitvoer goed te controleren voordat met de stand van de financiële administratie die is ontstaan NA het doorboeken. Draai daarom (evt. op het scherm) een lijst uit met openstaande facturen en ga na of de gegevens daarvan overeenkomen met hetgeen u verwachtte of (als de invoer uit @VO afkomstig is) dat de totalen overeenkomen met de totalen in @VO.

Denk er aan dat wat het maken van back-up’s betreft de bijdragenadministratie GEEN onderdeel uitmaakt van de financiële administratie. Het moet immers mogelijk zijn om een serie bijdragenbestanden terug te halen van een back-up zonder dat de rest van de financiële administratie daar last van heeft.

Bij elke bijdrage staat vermeld wat het bedrag is en welke relaties deze bijdrage moeten betalen. Dit laatste is alleen van belang als de bijdragen ook door ORIfin worden toegekend en niet als de gegevens uit een ander programma worden geïmporteerd. Ook staat aangegeven in welke totalen (of telvelden) de bijdrage moet worden geteld.

Voorbeelden: “Jaarlijkse bijdrage”, “Excursie Parijs”, “Gereedschap 1^e jaar”, etc.

Bij een totaal of telveld staat aangegeven op welke wijze dat totaal geboekt moet worden in de financiële administratie. Als het een eindtotaal betreft staat ook aangegeven in welke termijnen er betaald moet worden en voor welke datum.

Een rekenfunctie geeft aan welke berekening er moet plaatsvinden. De plaats van een rekenfunctie binnen de tabel van toegekende bijdragen aan een relatie bepaalt op welk moment de berekening uitgevoerd moet worden.

In eerste instantie moet worden opgegeven welke bijdragen er bestaan. De bijbehorende bedragen worden in totalen / telvelden geteld. Eventuele berekeningen kunnen dan worden gemaakt via de rekenfuncties.

Bij het produceren van de facturen worden eerst alle gegevens van een relatie bij elkaar gezocht, waarna eventuele rekenfuncties worden uitgevoerd. Een lange vaste serie variabelen wordt dan gebruikt om via “samenvoegen bestanden” met Word of WP de facturen te produceren. Deze serie variabelen wordt aan het eind van deze beschrijving weergegeven.

ORIfin levert de variabelen voor de leesstrook. Denk er echter wel aan dat de banken speciale eisen stellen aan het bedrukken van deze strook met betrekking tot het lettertype. In de regel zal dit OCR-II moeten zijn.

Binnen ORIAS mag het factuurnummer maximaal 16 posities lang zijn, opgebouwd uit alle mogelijke tekens. Een factuurnummer moet “zuiver” uniek zijn, waarmee we bedoelen dat elk verschil tussen twee factuurnummers voldoende is om het factuurnummer op te slaan.

In dit onderdeel echter maakt het factuurnummer deel uit van het betalingskenmerk dat ook op de leesstrook van de accepten terecht komt. De lengte van het factuurnummer wordt hier beperkt tot 15 posities, terwijl bovendien elk factuurnummer “onzuiver” uniek moet zijn. Dat wil zeggen dat het factuurnummer, als dat om wordt gezet naar een numeriek factuurnummer volgens een methode die we vanaf nu de BA-SMS-methode zullen noemen, niet gelijk mag zijn aan enig ander onzuiver factuurnummer van dezelfde relatie.

Een relatie heeft al een factuur met nummer “01234/pa” (factuur i.v.m. reis naar Parijs). Omgezet volgens de BA-SMS-methode wordt dat “01234172”. Een nieuw factuurnummer (dat “zuiver” gezien geldig is) zou kunnen zijn “01234/sc” (factuur i.v.m. schoolgeld). Dat factuurnummer wordt echter afgekeurd omdat bij omzetting volgens de BA-SMS-methode dit factuurnummer gelijk zou worden aan het eerdergenoemde factuurnummer “01234/pa”.

relaties op grond waarvan bedragen betaald moeten worden: in de meeste gevallen de leerlingen

In enkele gevallen kan de leerling zelf de betalingsplichtige zijn, bijvoorbeeld als de leerling meerderjarig is. De ORIfin-gebruiker (en @VO- of Magister-gebruiker) is zelf verantwoordelijk voor het op een juiste wijze bepalen wie de betalingsplichtige is. Dat gegeven wordt opgegeven bij dr relatiegegevens van de leerling en kan als zodanig eenvoudig worden aangepast.

Het is in ORIfin mogelijk om gegevens in te lezen vanuit een ander programma zoals @VO. In de rest van deze beschrijving noemen we telkens @VO met name, waarbij we dus elk programma bedoelen dat op diezelfde wijze gegevens kan aanleveren aan ORIfin.

Magister levert de gegevens op een andere manier aan ORIfin dan bijvoorbeeld @VO. Terwijl @VO orderregels aanbiedt die ORIfin de mogelijkheid geeft om facturen te produceren, biedt Magister alleen maar bedragen aan die geboekt moeten worden. @VO levert als het ware de invoer van de facturering, Magister levert de uitvoer van de facturering. Werkt u met Magister, dan heeft u het ORIfin-onderdeel “Facturen (bijdragen)” niet nodig.

Welke stappen u moet ondernemen om uiteindelijk facturen uit te kunnen draaien hangt sterk af van het feit of u kant en klare gegevens inleest vanuit @VO of niet.

Als u werkt met @VO: dit “opbouwen” gebeurt in @VO en kan in ORIfin dus achterwege blijven; na het inlezen van de gegevens uit @VO wordt de bijdragentabel automatisch opgebouwd

Als u werkt met @VO: dit “bepalen” gebeurt in @VO en kan in ORIfin dus achterwege blijven; na het inlezen van de gegevens uit @VO wordt de bijdragentabel automatisch opgebouwd

➔ Als u werkt met @VO is dit het moment waarop de @VO-gegevens worden ingelezen. Zie verderop in deze beschrijving uit welke werkzaamheden dat inlezen bestaat.

Draai een lijst uit met de toegekende bedragen en controleer of de details en de totalen overeenkomen met wat u verwacht. Als alles volledig naar wens is, ga dan pas door met de volgende twee stappen.

Dit is de enige stap die u ook moet doen als u met Magister koppelt. Het doorboeken vanuit Magister vindt echter plaats met een ander ORIfin-programma en valt buiten deze beschrijving.

➔ N.B. Voer stap 4 en 5 zo snel mogelijk na elkaar uit. Wacht even met inbrengen van andere boekingen tot blijkt dat de uitvoer volledig naar wens is, zodat u zeker weet dat er geen back-up teruggezet hoeft te worden.

Er zijn binnen ORIfin twee programma waarmee u kunt bepalen welke bijdrage betaald moet worden door welke relatie:

Met dit programma kunt u groepsgewijs bijdragen toekennen, waarbij het toekennen is gebaseerd op de voorwaarden die u per bijdrage heeft opgegeven in de bijdragentabel.

Met dit programma kunt u individueel per relatie bijdragen toekennen en correcties aanbrengen op de toegekende bijdragen.

Met dit programma kunt u voor groepen relaties bijdragen automatisch toekennen. Daarbij kunt u gebruik maken van de volgende mogelijkheden:

Voorbeeld: ken bijdrage “Leermiddelen 1^e leerjaar” toe; bij die bijdrage staat als selectiecriterium in te tabel bijdragen dat deze bijdrage doorberekend moet worden aan alle relaties met een “1" in de 1^e positie van rubriek “Huidige klas”.

Voorbeeld: selecteer alle relaties met een “1" in de 1^e positie van rubriek “Huidige klas”; bereken aan alle relaties van deze selectie een bijdrage door die in de tabel bijdragen staat omschreven als “Leermiddelen 1^e leerjaar”; er hoeft dan geen selectiecriterium opgenomen te zijn bij die bijdrage in de bijdragentabel.

➔ In dit programma kunt u ook aangeven of er voor deze run betalingsplichtigen bij gezocht moeten worden. Of het zinvol is om facturen te sturen naar minderjarigen, moet u zelf bepalen en is niet iets waar ORIfin over beslist.

Met dit programma kunt u wijzigingen aanbrengen op de toegekende bijdragen per relatie. De mogelijkheden die u hier heeft:

Deze lijst geeft exact weer welke bedragen er per betalingsplichtige worden berekend en op grond van welke leerling en welke bijdragen dat gebeurt. Het is verstandig om deze lijst uit te draaien (naar de printer of naar een bestand) vlak voordat u gaat doorboeken en de facturen gaat printen. (Zie ook “doorboeken”.) Mocht er achteraf iets fout blijken te zijn, dan kunt u dat op deze detaillijst nagaan.

Dit is de belangrijkste fase van een bijdragencyclus. Het doorboeken is onherroepelijk: na het doorboeken kunt u de bestanden niet meer veranderen. Tijdens het doorboeken wordt een lijst aangemaakt. Wij raden aan om in dit geval de uitvoer van de lijst naar het beeldscherm te sturen, zodat u direct kunt zien of alles in grote lijnen goed verloopt en zodat de printer geen spelbreker kan zijn tijdens het doorboeken. Een lijst op papier of naar een bestand kunt u beter vlak voor het doorboeken maken.

Deze fase wordt ook wel “printen facturen” genoemd. Die benaming is feitelijk niet juist omdat ORIfin de facturen niet zelf print, maar een bestand met parameters aanmaakt voor een tekstverwerker die met behulp van die parameters de facturen kan printen.

Een volledig overzicht van alle parameters kunt u achterin deze handleiding vinden. Ook vindt u daar een lijst van parameternamen die gebruikt kunnen worden om documenten te maken in Word of WordPerfect.

@VO bevat een eigen bijdragenadministratie, waarmee bepaald kan worden welke leerlingen welke bijdragen moeten betalen. Het resultaat van deze bewerking wordt via een bestand met orderregels weggeschreven naar ORIfin.

➔ Verderop in deze beschrijving vindt u een compleet overzicht van de informatie die vanuit @VO wordt ingelezen.

In @VO kan bij elke bijdrage worden aangegeven van welk grootboeknummer en van welke kostenplaats gebruik gemaakt moet worden. Een goede controle op die invoer is er uiteraard niet in @VO, aangezien de betreffende basistabellen in ORIfin staan.

Het voordeel is dan wel dat u binnen @VO niet verplicht bent om echte, bestaande grootboeknummers en kostenplaatsen te gebruiken: u mag een codering gebruiken die voor u het eenvoudigst is.

Tijdens het inlezen van het @VO-bestand in ORIfin worden deze codes (ook als het “echte” grootboeknummers en kostenplaatsen zijn) omgezet naar ORIfin-waarden. Bij het omzetten van kostenplaatsen kunt u in dat programma elke @VO-kostenplaats omzetten naar een combinatie ORIfin-kostenplaats en ORIfin-kostendrager.

Alle personen (dus ook leerlingen, ouders en verzorgers) krijgen binnen @VO een uniek persoonsnummer. Bij de leerlinggegevens kan binnen @VO een debiteurennummer worden opgegeven. Dat zal in de regel het debiteurennummer zijn van de ouders / verzorger. Dit is een belangrijk gegeven als u orderregels aanmaakt voor ORIfin omdat zowel de ouder als de leerling als relatie worden opgenomen in ORIfin.

De eerste stap bij het verwerken van een @VO-bestand in ORIfin is het bijwerken van de relatiegegevens. Nu zou het kunnen zijn dat er vanuit @VO relaties worden toegevoegd die voor ORIfin te weinig gegevens bevatten. Normaal gesproken zouden dergelijke relaties worden geweigerd. Aangezien dit tot oponthoud en wellicht andere problemen zou leiden, worden in dit soort situaties in plaats van de ontbrekende gegevens standaardwaarden aangenomen.

Het verwerken van een @VO-bestand begint altijd met een lege bijdragenadministratie, ook met een lege bijdragentabel.

Hierbij wordt gebruik gemaakt van de conversie-tabel “@VO-persoonsnummer”. Als blijkt dat nog niet alle betalingsplichtigen voorkomen, worden de volgende werkzaamheden uitgevoerd:

Dit toevoegen gebeurt met behulp van het ORIfin-programma “Muteren via tekstbestand relaties”.

Het opnieuw opbouwen van deze tabellen is een taak voor programma “Systeemfuncties relaties”.

Hierbij wordt gebruik gemaakt van de conversie-tabel “@VO-persoonsnummer”. Als blijkt dat nog niet alle leerlingen voorkomen, worden de volgende werkzaamheden uitgevoerd:

Dit toevoegen gebeurt met behulp van het ORIfin-programma “Muteren via tekstbestand relaties”.

Het opnieuw opbouwen van deze tabellen is een taak voor programma “Systeemfuncties relaties”.

Hierbij wordt van elk @VO-grootboeknummer gevraagd welk ORIfin-grootboeknummer daar tegenover staat en wordt van elke @VO-kostenplaats gevraagd welke combinatie ORIfin-kostenplaats / ORIfin-kostendrager daar tegenover staat.

Van elke @VO-bijdrage die door één of meer leerlingen betaald moet worden wordt een ORIfin-bijdrage aangemaakt. Bij die bijdragen komt ook een verwijzing naar een bijdragentotaal waarin staat aangegeven op welk grootboeknummer, kostenplaats, kostendrager er geboekt moet worden.

Nadat alle bijdragen en relaties binnen ORIfin bekend zijn gemaakt, kan de werkelijke conversie plaatsvinden.

Vanaf dat moment zit er verder geen verschil tussen een “echte” ORIfin-verwerking of een verwerking die gestart is in @VO: u kunt dus lijsten draaien, doorboeken en factureren. Ook kunt u nog allerlei wijzigingen aanbrengen.

Soms is het erg lastig om zaken die u onjuist heeft opgegeven in @VO te corrigeren in @VO en dan nogmaals te exporteren. Denk dan aan de mogelijkheid die er bestaat om basisgegevens na het inlezen van het @VO-bestand te corrigeren via “Onderhoud basistabel bijdragen” en om de toegekende bijdragen nog te wijzigen via “Onderhoud toegekende bijdragen”.

Op het volgende blad kunt u de volledige indeling vinden van het bestand uit @VO.

Extern volgnr	Intern volgnr	Naam variabele	Inhoud		Nadere toelichting
001	0	Relnr_1	Relatienummer		Betalingsplichtige “relatie”
002	1	Naam_1	Rubriek 200 (complete naam relatie)
003	2	Adres_1	Rubriek 205 of 202	Postadres. Als deze niet bestaat: bezoekadres
004	3	PC_1	Rubriek 206 of 203
005	4	Plaats_1	Rubriek 207 of 204
006	5	Land_1	Rubriek 789 of 235
007	6	Betreft	Constante aanwezig als de betalingsplichtige een ander is dan de relatie waarop de berekening betrekking heeft. Default: “Betreft:”
008	7	Relnr_2	Relatienummer		Relatie waarop berekening betrekking heeft “betreft relatie”
009	8	Naam_2	Rubriek 200 (complete naam relatie)
010	9	Adres_2	Rubriek 205 of 202	Postadres. Als deze niet bestaat: bezoekadres
011	10	PC_2	Rubriek 206 of 203
012	11	Plaats_2	Rubriek 207 of 204
013	12	Land_2	Rubriek 789 of 235
014	13	Factnr	Factuurnummer, maximaal 15 posities		Boekingsgegevens
015	14	FactDat	Factuurdatum)”, de officiële datum op grond waarvan de betalingstermijn gaat lopen
016	15	BoekPer	Boekingsperiode
017	16	Stuknr	Stuknummer
018	17	AanmaakDat	Aanmaakdatum)”, dit is de draaidatum waarop het bestand met variabelen is aangemaakt
019	18	Totbed	Totaal bedrag		Factuurbedrag
020	19	Totbed_E	Idem, alleen het deel in Euro’s
021	20	Totbed_C	Idem, alleen het deel in centen
022	21	Totbed_L	Idem, in leesstrook-formaat
023	22	Betkenm_1	Positie 1 t/m 4 van betalingskenmerk		Samen: betalings- kenmerk zoals op leesstrook
024	23	Betkenm_2	Positie 5 t/m 8 van betalingskenmerk
025	24	Betkenm_3	Positie 9 t/m 12 van betalingskenmerk
026	25	Betkenm_4	Positie 13 t/m 16 van betalingskenmerk
027	26	ReknrRel	IBAN betalingsplichtige		IBAN betalingsplichtige
028	27	ReknrBeg	IBAN begunstigde		IBAN + BIC begunstigde
029	28	BICBeg	BIC begunstigde		IBAN + BIC begunstigde
030	29	MachtID	Machtigings ID
031	30	RelnrBeg	Relatienummer begunstigde
032	31	RedenInc	Reden incasso
033	32				Voor toekomstig gebruik
034 t/m 042	33 - 41	... (zie rechts)	Betalingsplichtige: maximaal 9 vrije rubrieken waarvan de naam van de rubriek als “Naam variabele” wordt meegenomen		Vrije velden
043 t/m 051	42 - 50	... (zie rechts)	Relatie waarop berekening betrekking heeft: maximaal 9 vrije rubrieken, zie bovenstaand		Vrije velden
052	51	Vvdat_01	Vervaldatum)”	1^e termijn	Gegevens 1^e tot en met 10^e termijn
053	52	Tbed_01	Termijnbedrag
054	53	Tbed_E_01	Idem, alleen deel in Euro’s
055	54	Tbed_C_01	Idem, alleen deel in centen
056	55	Tbed_L_01	Idem, in leesstrook-formaat
057 t/m 101	56 - 100	idem	idem	2^e tot en met 10^e termijn
102	101	OmsByd_01	Omschrijving bijdrage	1^e bijdrage	Gegevens 1^e tot en met 40^e bijdrage
103	102	LKol_Byd_01	Bedrag voor kolom 2
104	103	RKol_Byd_01	Bedrag voor kolom 1
105 t/m 221	104 - 220	idem	idem	2^e tot en met 40^e bijdrage
222	221	TOms_01	Omschrijving teller	1^e teller	Gegevens 1^e tot en met 10^e teller
223	222	Tel_01	Bedrag teller
224	223	Tel_E_01	Idem, alleen deel in Euro’s
225	224	Tel_C_01	Idem, alleen deel in centen
226	225	Tel_L_01	Idem, in leesstrook-formaat
227 t/m 271	226 - 270	idem	idem	2^e tot en met 10^e teller
272	271	TOms_11	Omschrijving teller	11^e teller	Gegevens 11^e tot en met 100^e teller
273	272	Tel_11	Bedrag teller	11^e teller
274 t/m 451	273 - 450	idem	idem	12^e tot en met 100^e teller

)’= Volgnummer met als eerste nummer 001, t.b.v. bijvoorbeeld WordPerfect. Programmatechnisch heeft het eerste telveld als volgnummer 000.

Origineel teken	Omgezet naar
0, spatie	0
2,a,b,c	2
3,d,e,f	3
4,g,h,i	4
5,j,k,l	5
6,m,n,o	6
7,p,q,r,s	7
8,t,u,v	8
9,w,x,y,z	9
1 en overige tekens	1

Volgnr	Omschrijving @VO-gegeven			Wordt ORIfin-gegeven benaming + ORIfin-rubrieknr + D, L, B of T ( D = debiteur; L= leerling; B= bijdrage; T= totaal/teller )
1	@VO-nummer debiteur			Debiteurennummer @VO	782	D
1	@VO-nummer debiteur			Nummer betalingsplichtige	220	L
2	speciale ORIfin-informatie	@VO-nummer leerling		@VO-leerlingnummer	782	L
		oud ORIAS- of Schoolfact-nr		Oud llnr ORIAS/Sf	748	L
		roepnaam leerling		Roepnaam	779	L
		voorvoegsels achternaam leerling		Voorvoegsels achternaam	240	L
		achternaam leerling		Achternaam	241	L
3	factuurdatum			-
4	aanduiding grootboeknummer		Identificatie bijdrage bij inlezen in ORIfin	Via conversie: grootboeknummer ORIfin		T
5	aanduiding kostenplaats			Via conversie: kostenplaats en -drager ORIfin		T
6	omschrijving			Omschrijving bijdrage		B
7	bedrag (eventueel negatief voor korting-bedragen)			Termijnbedrag bijdrage		B
8	achternaam debiteur			Achternaam	241	D
9	voorletters debiteur			Voorletters	201	D
10	voorvoegsels debiteur			Voorvoegsels achternaam	240	D
11	titel debiteur			Aanhef / titel	780	D
12	geslacht debiteur			Geslacht	216	D
13	rekening of incasso			Rek./Incasso R/I	781	D/L
14	bank- of Postbanknummer			Banknummer	223	D
14	bank- of Postbanknummer			Postbanknummer	224	D
15	roepnaam + volledige achternaam leerling			-
16	rol debiteur			-
17	opleiding leerling			Opleiding leerling	790	L
18	klas leerling			Klas leerling	752	L
19	orderregel @VO			-
20	straat debiteur			Straat	245	D/L
21	huisnummer debiteur			Huisnummer	246	D/L
22	huisnummer aanduiding debiteur			-
23	toevoeging huisnummer debiteur			Huisnummer toevoeging	247	D/L
24	postcode debiteur			Postcode	206	D/L
25	woonplaats debiteur			Woonplaats	207	D/L
26	land debiteur			Land	789	D/L
27	telefoonnummer debiteur			Telefoon	208	D/L
28	e-mailadres debiteur			E-mail-adres	230	D
-	-			Relatiesoort = ‘$’	138	D
-	-			Relatiesoort = ‘\|’	138	L