k (→Open vragen) |
k |
||
(2 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
Regel 2: | Regel 2: | ||
|Naam=Open Administratie | |Naam=Open Administratie | ||
|Eigenaar=Stitch | |Eigenaar=Stitch | ||
− | |Status= | + | |Status=Canceled |
|Skills=Administratie, Web Post-Get, Wiki automatisering | |Skills=Administratie, Web Post-Get, Wiki automatisering | ||
|Samenvatting=Administratie van Hack42 beschikbaar maken aan de wereld | |Samenvatting=Administratie van Hack42 beschikbaar maken aan de wereld | ||
}} | }} | ||
+ | |||
Een manier om de administratie van de stichting open te stellen aan de rest van de wereld, behoudens anonimiteit (rekeningnummer of transactie) in gewenste situaties. Hieronder wordt de interface IHackerSpaceAdministratie v0.5 beschreven: | Een manier om de administratie van de stichting open te stellen aan de rest van de wereld, behoudens anonimiteit (rekeningnummer of transactie) in gewenste situaties. Hieronder wordt de interface IHackerSpaceAdministratie v0.5 beschreven: | ||
Regel 18: | Regel 19: | ||
Of het banksaldo te zien zal zijn is de vraag. In ieder geval kan wel worden bijgehouden of donaties worden gedaan en waar de stichting zijn geld aan uitgeeft. | Of het banksaldo te zien zal zijn is de vraag. In ieder geval kan wel worden bijgehouden of donaties worden gedaan en waar de stichting zijn geld aan uitgeeft. | ||
− | Leden kunnen zelf facturen inboeken en uitschrijven. Dit onder bepaalde restricties om wildgroei en spookboekingen te voorkomen. Deze moeten nog opgesteld worden, wat onderdeel wordt van dit project... Dat soort regels wil/kan/mag/ga ik niet alleen opzetten namelijk. Persoonlijk hoop ik dat de taak als penningmeester hierdoor ook een stuk eenvoudiger wordt, zodat de uitdaging in een andere hoek gezocht kan worden. | + | Leden kunnen zelf facturen inboeken en uitschrijven. Dit onder bepaalde restricties om wildgroei en spookboekingen te voorkomen. Deze moeten nog opgesteld worden, wat onderdeel wordt van dit project... Dat soort regels wil/kan/mag/ga ik niet alleen opzetten namelijk. Persoonlijk hoop ik dat de taak als penningmeester hierdoor ook een stuk eenvoudiger wordt, zodat de uitdaging in een andere (financiele) hoek gezocht kan worden. |
== Plan == | == Plan == | ||
Regel 94: | Regel 95: | ||
==== Open vragen ==== | ==== Open vragen ==== | ||
− | * Heeft | + | * Heeft inkomen van de stichting invloed op de persoonlijke situatie van de bestuurders? |
* | * | ||
* | * |
Huidige versie van 7 feb 2012 om 18:05
Project: Open Administratie | |
---|---|
Naam | Open Administratie |
Door | Stitch |
Status | Canceled |
Madskillz | Administratie, Web Post-Get, Wiki automatisering |
Doel / Omschrijving | |
Administratie van Hack42 beschikbaar maken aan de wereld | |
Alle Projecten - Project Toevoegen |
Een manier om de administratie van de stichting open te stellen aan de rest van de wereld, behoudens anonimiteit (rekeningnummer of transactie) in gewenste situaties. Hieronder wordt de interface IHackerSpaceAdministratie v0.5 beschreven:
Afkomst
Voor een eigen project (generators) wilde ik niet alleen de software ook het hele bedrijf open gooien. Het idee van Open Company groeide, daarbij hoort een administratie die door iedereen bekeken kan worden.
Mogelijk voordeel
De winst zit in drie delen: transparantie, nakomen verplichtingen, feedback. Deze komen samen op de volgende manier:
Transparantie is een verplichting naar de leden toe. Deze kunnen hierover advies geven, daarnaast is het meteen duidelijk waar donaties naar toe gaan en wat er binnen komt. Naar buiten toe hoeft de administratie niet gesloten te zijn, maar gezien het maatschappelijk belang is het mogelijk wel nuttig om dit te doen. In ieder geval voor een groot gedeelte. Andere hackerspaces en organisatie kunnen mogelijk ideeën opdoen van onze administratie, gezien ze in hetzelfde schuitje zitten.
Of het banksaldo te zien zal zijn is de vraag. In ieder geval kan wel worden bijgehouden of donaties worden gedaan en waar de stichting zijn geld aan uitgeeft.
Leden kunnen zelf facturen inboeken en uitschrijven. Dit onder bepaalde restricties om wildgroei en spookboekingen te voorkomen. Deze moeten nog opgesteld worden, wat onderdeel wordt van dit project... Dat soort regels wil/kan/mag/ga ik niet alleen opzetten namelijk. Persoonlijk hoop ik dat de taak als penningmeester hierdoor ook een stuk eenvoudiger wordt, zodat de uitdaging in een andere (financiele) hoek gezocht kan worden.
Plan
Er zijn een aantal stappen nodig om dit project voor elkaar te krijgen:
- Mutaties weergeven op de wiki
- Bepalen welke administratiesoftware wordt gebruikt
- Administratiesoftware aansluiten op mutaties
- Leden toegang geven tot administratie software
- Procedures vaststellen voor het uitschrijven en inboeken van facturen
- Procedures vaststellen voor een financiële audit
- Open vraag: hoe interne geldstromen worden beheerd
- Hacks: privacy dingesen enzo
1: Inzicht mutatiehistorie
Mutatiehistorie van banken moet automatisch ingelezen kunnen worden. Bij de ing is het een kwestie van post commando's sturen naar een webserver en een download accepteren. Voor de ABN-AMRO zou eerst de randomreader (hashfunctie) gekraakt of gerainbowed moeten worden. Dit laatste is waarschijnlijk ook niet al te lastig, als het al niet gedaan is.
Deze mutaties kunnen gedeeltelijk naar de wiki verhuisd worden, dit kan met een wiki bot. Een andere oplossing is om de database van de administratiesoftware te syncen met de wiki. Wat makkelijker is wint.
(Overigens: de abn vraagt 7 cent per mutatie. Dus liever een andere bank.)
2: Bepalen administratiesoftware
Vanuit de hackerspaces heb ik begrepen dat er een homebrew solution komt (revspace). Er zijn daarnaast al een aantal opensource oplossingen, welke nog nadere inspectie nodig hebben.
Ik heb zelf ervaringen met Snelstart. Vooral het inlezen van mutaties en automatisch boeken werkt daarin prettig. Factureren gaat goed en rapporteren is ook redelijk okee. Gezien het op een SQL Server draait betekent het ook makkelijk uitlezen van gegevens (hoewel nog niet geprobeerd).
Het boekhoudpakket moet minimaal de volgende dingen kunnen (de rest doet een accountant):
- Inboeken facturen en bonnen
- Uitschrijven facturen
- Bijhouden mutaties rekeningen (inlezen, desnoods via omweg)
- Kruisposten boekingen (grootboekrekeningen)
- Bijhouden leden (klanten?)
- Automatisch uitschrijven facturen
- Eigen logo op factuur
- Meerdere BTW tarieven
- Rapporteren: openstaande facturen (in/uit)
- Gegevens benaderbaar via automatiseringsprocessen
- MOAR???
3: Administratiesoftware aansluiten op mutaties
Wanneer de software is bepaald worden de mutaties van de rekeningen automatisch ingelezen. Afhankelijk van de gekozen software zal hier een omweg voor gebouwd moeten worden. De standaard formaten zijn in Nederland MT9400 en CSV. Beide CRAP dus. XML was duidelijker geweest omdat je dan niet aan de volgorde van elementen vast zit.
4: Leden toegang geven tot administratie
Afhankelijk van het pakket zal er een machine en installatie moeten komen waarbij het mogelijk is om snel(!) via een remote desktop(!) dingen te kunnen doen. Het moet net lijken alsof je zelf op de machine werkt, anders is het irritant. Hier zijn waarschijnlijk genoeg kant en klare oplossingen voor, en er is genoeg kennis om dit te regelen in de hackerspace wereld.
Een ander ondereel is de voorwaarden opstellen waartoe leden dingen kunnen doen in de administratie. Een incorrecte administratie kost tijd en geld, en in moeilijke tijden willen we niet dat er mee geklooid wordt. Onder deze stap valt dus ook het backuppen en mogelijk loggen van activiteit in dat systeem.
5: Procedures vaststellen voor het inboeken en uitschrijven van facturen
Hoe het makkelijkst, met screenshots erbij, een aantal standaardhandelingen uitgevoerd kunnen worden. Op dit moment zijn het de volgende zaken:
- Aanmaken klanten en deelnemers
- Inboeken kassabon
- Inboeken factuur
- Uitschrijven factuur
- Checken openstaande facturen
Daarin worden ook alle tips en tricks vermeld hoe je een dergelijke actie zo gunstig mogelijk kan voltooien. Facturen bijvoorbeeld pas na 29 dagen betalen.
6: Procedures financiële audit
Binnen zes maanden na elk boekjaar (na 31 december) moeten de boeken worden gecontroleerd. Dit is iets wat we zelf niet kunnen doen, gezien we niet de kennis/skills/truuks in huis hebben om de administratie optimaal te gebruiken. Er zijn ook 1.000.000 regelingen, waar we mogelijk wel of niet gebruik van willen maken. Het is verstandig om een aantal maanden voor afsluiting van het boekjaar advies in te winnen: daaruit blijkt of we nog van regelingen kunnen profiteren voor het einde van dat jaar.
De volgende audits lijken me nuttig:
- Advies voor sluiting (2 maanden voor eind boekjaar)
- Sluiting Boekjaar (binnen 6 maanden na eind boekjaar)
7: Interne geldstromen
Of en hoe een interne kas wordt beheerd is nog onduidelijk. Heb zelf geen ervaring met het beheren van cash geld (spullen kopen, cash ontvangen); waarschijnlijk zijn dit bulk acties waar weinig onderhoud voor nodig is. Verkoop van snoep enzo zal vast per kwartaal onderhouden kunnen worden, de inkoop gaat met de facturen mee.
Er kan ook gedacht worden aan een monies systeem over alle hackerspaces heen, maar dat is mogelijk niet nuttig maar omdat het kan. Dit maakt dingen mogelijk nodeloos ingewikkeld.
8: Hax
Anonieme transacties
Sommige transacties hebben de voorkeur niet op de wiki te verschijnen, maar alleen voor het bestuur en de leden. Dit wordt geregeld door het codewoord "ANON" in de transactieomschrijving te zetten.
Open vragen
- Heeft inkomen van de stichting invloed op de persoonlijke situatie van de bestuurders?
Voetnoten
Owja: tussen de regels door laat ik wat nadelen zien van abn-amro. Ik heb veel ervaring met die bank, en vind 250 euro per jaar voor een kleine ondernemersrekening afzetterij. Zeker gezien 100% van de diensten die ik heb gebruikt geautomatiseerd of geoutsourced zijn.