Hallo allemaal,

Ik heb inmiddels een eerste versie beschikbaar, dat je kunt installeren in versie 5. Nog niet uitgebreid getest, maar het werkt.
Dit rekenschema is gebaseerd op de zgn methode Bakker en wordt bv ook gebruikt in leerboeken voor HBO en WO.
Deze methode kenmerkt zich door een rubricering in 10 rubrieken.
Het beschikbare schema kent dus een lijst met grootboekrekeningen waarop geboekt kan worden en één rapportage rekening per rubriek.
In principe is dit schema bruikbaar voor elke nl bv. Maar let wel elk bedrijf of instelling heeft zo zijn eigen schema.

Ik wil het eerst nog wat verder beproeven en de module dan publiceren.
Als je geïnteresseerd bent, mail me even dan stuur ik de module.

Gert

Hoi Gert,
Wil je mij de module mailen? Ga ik er ook even mee testen.

Is er in jou schema onderscheid tussen balans en resultaat rekeningen?
Ben nog steeds op zoek naar balans en verlies/winst rapportages. Hoewel dit ook goed moet kunnen met de standaard rekening soorten van OpenERP.

Grtz,
Freerk

Hoi Freerk,

Ik zal hem mailen.
Het schema zoals nu beschikbaar, bevat nog geen rapportage structuur waar jij op doelt in de zin van balans en verlies en winst rekening.

Het is mij ook niet helder hoe dan de standaard moet zijn.
Je zou als vertrekpunt de structuur kunnen nemen, die je ook vindt in jaarrapporten van accountants over BV 's . Maar ik heb wel gezien, dat er nogal wat speelruimte in is.
Het staat nog op mijn lijstje om het verder uit te werken.

Dag Gert, anderen,

Ik ben de zaak aan het testen... Mijn eerste indruk: prima werk! Complimenten.

Een paar waarnemingen:

1. In de diverse popup-menu's prefaleert het interne type van rekeningen. Dat houdt in dat je een selectielijstje krijgt van rekeningsoorten en een leeg, handmatig in te vullen veld voor de gebruikerssoorten. Omdat alles intern op 'other' staat, is het 'alles of niets' - het selectiemenu doet er niet meer toe.
Volgens mij sluit het gebruik van user_types niet uit dat ook het internal_type gebruikt wordt. Als je dit zoveel mogelijk vertaalt naar de internal-types en alleen 'other' gebruikt als het niet anders kan, dan blijft de standaard-interface functioneel.

2. Bankrekeningen staan nu op user_type_asset. Er zijn diverse popup-selecties die het zoekbereik standaard limiteren tot 'cash'. De bankrekeningen vallen daar nu buiten. Dat is in het gebruik niet handig.

3. De benaming van de BTW-rekeningen komt terug op de factuur. Ik vind "1c 19%" niet erg sjiek staan op een factuur voorafgaande aan het BTW-bedrag. Het is wenselijk om BTW-rapportage en BTW-gebruik zo strikt mogelijk van elkaar te scheiden. Dat kan volgens mij al door de naamgeving aan te passen.

4. Ik begrijp waarom je onder de tafel zoveel BTW-rekeningen nodig hebt, maar als je nu via de interface gaat kijken, zie je veel dubbele rekeningnamen verschijnen zonder dat duidelijk is waarvoor dat dient. Is daar nog iets aan te doen?

5. Er zijn meer belastingen in Nederland. Wat te denken van accijns, verwijderingsbijdrage, milieuheffing, loonbelasting, enz., enz. Is het een idee om die ook in dit schema te verwerken?

Mer op, maar dat is meer een algemene opmerking, dat er in de Nederlandse vertaling vaak BTW wordt gebruikt als er in het Engels Tax staat. Volgens mij klopt dit alleen als er VAT staat. BTW is slechts één vorm van belasting. Het lijkt er nu op alsof alles in Nederland om de BTW draait....

6. Inhoudelijk zou ik verder het schema eens tegen het licht houden... er zijn een tweetal lege hoofdrubrieken terwijl andere overladen vol zijn. Klopt dit?

Zelf kan ik niet goed wijs uit de opsplitsing van al die verschillende inkoop-rekeningen op basis van BTW. Waarom zou een bedrijf zoiets willen? Het volstaat toch om de BTW-rekeningen correct tegen te boeken? Volgens mij gaat dat met dit schema prima zonder die uitsplitsing... of is dit het schema van de belastingdienst?

Als slot veronderstelt de naamgeving van de module dat andere typisch Nederlandse zaken er ook onderdeel van (zullen) zijn. Zijn er plannen in die richting?

Voor mijzelf ben ik ook bezig met een aantal aanpassingen die als typisch Nederlandse bestempeld kunnen worden, zoals bijv. Nederlandse persoonsnamen (initialen, voorvoegsels, meisjesnaam). Die zouden als module binnen een l10_nl naamgeving passen. Gezien het feit dat je in Nederland bijv. ook het IFRS-rekeningschema mag gebruiken, zou ik dit niet met deze module willen mengen.

Wat zijn jullie gedachten hierover? Is het een idee om een l10n_nl namespace te beginnen? Deze module zou dan bijv. l10n_nl_chart kunnen gaan heten, die van mij bijv. l10n_nl_partner, enz.. Zo kan elk ontwikkelen en gebruiken wat van pas komt.

Groet,

Beste Pieter,

gezien de BTW opmerking "1c 19%" bedoel je volgens mij niet het grootboekschema van Gert, maar het l10n_nl schema van mij, welke mede door input van Gert en Freerk nu is aanbeland bij versie 5.0.1.2
Voor diegene welke het nog niet weten, deze is te vrij beschikbaar via bazaar
https://code.launchpad.net/~openerp-com ... -community. iedereen kan hier ook mee ontwikkelen aan het schema.
het schema is ook als zip bestand beschikbaar via http://www.veritos.nl/downloads.html

Ik zal je gemaakte punten 1 voor 1 doorlopen.
1.) Het "Internal Type" veld is strikt toegewezen functionaliteit.
Receivable & Payable zijn voor de debiteuren en crediteuren rekeningen (1300 & 1600 in het schema)
View voor de structuuropbouw
Consolidation voor virtuele schema's
Closed voor niet meer in gebruik zijnde rekeningen.
Dan blijft nog over "Others" voor alle andere gevallen, en dat zijn de meeste rekeningen. Bij mijn weten staat de "Internal Type" op alle rekeningen goed en zijn er geen andere mogelijkheden over.

2.) Bankrekeningen staan sinds versie 5.0.1.0 op user_type_cash = Vlottende Activa"

3.) Dit was mij ook reeds opgevallen en dient een correctie, althans voor de standaard facturen welke gebruik maken van dit veld (Tax Code". Er zijn ook customized facturen in omloop welke gebruik maken van het veld "Tax Name". Die hebben dit probleem niet.
Ikzelf ben van plan om de code zoals 1c in "1c 19%" te verwijderen en een apart BTW rapport te maken, waarop de codes hard gecodeerd op het rapport staan. Het komt namelijk op meerdere plaatsten in OpenERP terug!

4.) Dit is helaas niet op te lossen. Met name bij buitenlandse transacties MOET je BTW heffen, maar mag je deze gelijk weer als voorheffing aftrekken. (Per saldo dus 0) Als we dit niet doen, gaat de BTW rapportage en dus de aangifte mis. De omschrijvingen zijn in versie 5.0.1.0 wel aangepast dus zou wat duidelijker moeten zijn.

5.) Ikzelf denk meer aan het creëren van branch modellen, waarbij het grootboekschema een onderdeel is. De autoverkoop/inkoop heeft weer andere behoefte als een boekhandel of productiebedrijf. Hetzelfde geld voor een eenmanszaak versus besloten vennootschap. Alles in een grootboek stoppen heeft geen zin. In het huidige schema zit eigenlijk al te veel voor algemeen gebruik. Maar verwijderen is nog altijd makkelijker als toevoegen

M.b.t. de vertaling, dat klopt. Sinds kort hebben we een Nederlande en een Vlaamse vertaling. (Dit was voorheen 1 vertaling) De Nederlandse community kan nu specifiek voor Nederland vertalen. Ook worden alle aangeboden vertalingen sinds vorige maand door een kleine groep gecontroleerd, zodat door het hele pakket dezelfde terminologie gebruikt kan gaan worden.

6.) Dat klopt. Rubriek 5 en 6 zijn leeg. Het gehanteerde schema volgt het Stelsel Bakker. Rubriek 5 en 6 worden in productiebedrijven gebruikt om tussenstappen tijdens productie financieel te boeken. Het gaat wat ver omdat in een algemeen schema te verwerken daar het ook bedrijfsspecifiek is. (zie hier de mogelijkheid van branche modellen)

Inkooprekeningen op basis van BTW, het geeft de mogelijkheden weer. Als iemand ze niet nodig heeft, gewoon verwijderen. Is makkelijker als toevoegen. Als je inkoop vanuit het buitenland hebt en zowel hoog als laag tarief, heb je ze echter wel nodig.

Naamgeving en andere typisch Nederlandse zaken -> Ja, ik heb plannen om diverse rapportages toe te voegen, import en export (clieop en bankafschriften) maar heb ook beperkte tijd. Anderen zijn ook hiermee bezig, zoals momenteel de bank import module.
Is de naamgeving helemaal juist? Momenteel nog niet, maar straks hopelijk wel. Voel je vrij om specifieke zaken toe te voegen.

IFRS kan denk ik goed met deze l10n_nl module werken. De IFRS module maakt extra velden aan voor een eigen IFRS rubricering op de grootboekrekeningen en maakt hierop haar rapportages.
Vervolgens is het boekhouden volgens IFRS regels (het volgens specifieke regels waarderen van balanswaardes)

l10n_nl namespace -> graag hoor ik hier ook de mening van anderen.
Lijkt mij goed om duidelijkheid te scheppen en verwarring naderhand te voorkomen.

LET OP! BIJ NIEUWE VERSIE INSTALLEREN VAN HET GROOTBOEKSCHEMA!

Als de nieuwe module is gecopieerd naar de addons directory, kan in een bestaand bedrijf (lees database) via administratie -> modules de module opgewaard worden.
Dit heeft echter GEEN effect op het bestaande rekeningschema!! (Deze zou dan overschreven worden, handmatige aanpassingen teniet doen en een bestaande administratie foutief kunnen weergeven)

Bij alle nieuw te creëren bedrijven word WEL het nieuwe schema gebruikt bij installatie.

Mijn vergissing. Inderdaad.



Dat klopt, maar zoals alles in OpenObject/ERP is alles wijzigbaar. Zie bijvoorbeeld de IFRS-module, die ook typen toevoegt. Alternatief is dat er in de tree-weergaven gesleuteld wordt aan het account type veld. Zoals het nu is, moet je de typen uit het hoofd kennen... wat raar is bij een geautomatiseerd systeem. Er zou bijvoorbeeld een selection field van gemaakt kunnen worden met search methods. Wellicht heb je zelf betere ideeen?



Dat is juist, maar doet niets af aan mijn waarneming.



Zoiets vermoede ik al. Goed nieuws!



Daar kan ik prima mee leven.



Als je het beperkt tot een rekeningschema en de rapportages die daarop gebaseerd zijn, wat dit volgens mij is, dan kan dit prima in één module. Branch-specifieke modulen worden in OpenERP zoveel mogelijk opgesplitsts in losse herbruikbare modulen en een profile_xxx module waarin de afhankelijkheden naar de onderliggende modulen bewaakt wordt, waaronder die met het rekeningschema. Er zijn diverse voorbeelden hiervan in zowel addons als addons-extra. Je zou dus profile_garage_nl kunnen maken o.i.d. met daarin een verwijzing naar l10n_nl.



Goed nieuws! Hoe word ik lid van die groep?



In principe mee eens, maar als je pretendeert een 'standaard' schema te maken, dan hoort het er wel in. Verder is productie allang niet meer gebonden aan fysieke goederen, ook dienstverleners kunnen deze rubrieken goed gebruiken.



Dit begrijp ik niet. Wat verplicht is dat je bij elke aankoop aangeeft waar deze is gedaan, bij verkoop aan wie het is gedaan en in welk land en in beide gevallen of de correcte heffing is toegepast. Dat kan door gebruik te maken van de BTW-rekeningen, wat met jouw BTW-schema en de machinerie van OpenERP vrijwel automatisch gebeurt. Het niet-verplichte categoriseren van grootboekrekeningen voor in- en verkopen op basis van toegepaste BTW-heffing is mooi voor de inspecteur van de belastingdienst, maar dient volgens mij niet de ondernemer - je krijgt of te maken met allerlei interne overboekingen om het inzicht te herstellen, of met een compleet analytisch schema er dwars doorheen. Beide geven extra werk. Ik kan hier werkelijk de meerwaarde niet van inzien.



Dat wil ik doen, maar ik zie er weinig in om dit in jouw module te doen. Er zijn - zoals je zelf al aangeeft - teveel kanten aan 'typisch Nederlands' om alles in één module te (kunnen) stoppen. Verder verlies je snel het overzicht als er allerlei mensen bijdragen en - zoals je zelf aangeeft - je weinig tijd hebt. Dat geeft alleen maar frustraties bij de mensen die willen bijdragen - en op je moeten wachten - en de gebruikers, die niet de gewenste kwaliteit krijgen.



Je zou daar wel eens gelijk in kunnen hebben. Ik heb de module bekeken. Het viel me op dat er inderdaad geen grootboekrekeningen in zitten. Ik heb echter te weinig kennis van dit systeem om te kunnen testen. Heb je het zelf uitgeprobeerd?

In ieder geval - voor zover je het niet doorhad - ik kan je bijdrage goed waarderen. Ook mijn tijd is kostbaar en beperkt. Toch steek ook ik hier tijd in. Ik hoop dat mijn opmerkingen bijdragen aan een betere kwaliteit.

Groet,

Dag Pieter,

ik had het door dat je de bijdrage goed kon waarderen! Ik ben ook blij met de feedback. Daar kan ik wat mee. Het laat in ieder geval dat zien dat anderen er mee werken, mee aan het experimenteren zijn.

In zijn algemeenheid blijft een grootboekschema in Nederland lastig. De overheid legt hier geen standaarden op zoals b.v. in België het geval is. Gevolg is dat er allerhande schema's zijn binnen de verschillende branches die Nederland rijk is. (auto brange met marge regels, gezondheidszorg, scholen, winkeliers met alleen binnelandse verkoop, webwinkels met wereldwijde verkoop, stichtingen en veringingen zonder BTW, enfin ga maar door) Sterker nog, het lijkt wel of bijna iedere boekhouder ook nog een eigen schema hanteert!
Eerst was er niets voor OpenERP dat werkte, met als resultaat dat vele (kleinere) potentiële gebruikers/ondernemers afhaakten. Ze kregen geen boeking in het systeem verwerkt. Begin maar eens een werkend schema in openERP te maken vanuit het niets. Dat lukt zonder boekhoudkennis niet.
Nu is er wel iets en wijzigen van een schema is een stuk makkelijker omdat je kunt afkijken op bestaande regels.
Het is een basis welke mogelijk aansluiting vind bij kleinere ondernemers.
Vandaar mijn opmerking over branchemodellen, waarbinnen specifieke zaken geregeld kunnen worden.
Grotere bedrijven welke overstappen vanuit een ander systeem op OpenERP hebben vaak al een uitgebreid schema. Deze word dan overgenomen te in OpenERP. Die gebruiken dit schema niet .

M.b.t. het "Internal Type". Hier zou ik persoonlijk niets aan gaan wijzigen. Het is essentiële basis functionaliteit. Als OpenERP hier straks wijzigingen maakt, klopt het verhaal niet meer en ligt het systeem onderuit.
Ik ben zelf altijd voorstander om zoveel mogelijk de basisfunctionaliteit te gebruiken en zo weinig mogelijk customisatie toe te passen. Dat scheelt een hele hoop in de uiteindelijke kosten van onderhoud van het pakket.
Nu volgt het schema het "Stelsel Bakker" waarbinnen de rubricering toch wel vaststaat welke kosten en opbrengsten rekeningen zijn en welke balansrekeningen.
Ik heb even geen oplossing voorhanden om (semi)automatisch de juiste grootboekrekening bij handmatige boekingen op te sporen, dan alleen middels de zoekopdracht.

De IFRS module wijzigt niets aan bestaande functionaliteit. Die voegt alleen iets toe, geheel losstaand. De module kan altijd weer verwijderd worden, zonder het systeem te breken.

Vertalingen gaan via launchpad. Iedereen kan vertalen. De controlegroep is sinds maart actief. Freerk heeft deze opgericht en bestaat nu uit 5 personen.
https://launchpad.net/~openerp-i18n-dutch/+members
Ikzelf hoop dat deze controle groep niet te groot word, anders kunnen we net zo goed geen controlegroep hebben! (ben er zelf overigens geen lid van)

Rubriek 5 en 6 -> als je een voorstel/voorbeeld hebt hoor ik het graag. Dan voegen we hem toe.

BTW grootboekrekeningen. Hier begreep ik jou dus blijkbaar niet. Ik doelde op de BTW regels, jij doelt volgens mij op de BTW grootboekrekeningen in de 1600 serie. Klopt dat hier alles is uitgesplitst. De boekhouding geeft op deze manier gewoon alle details weer. Is het nodig? Nee, het hoeft niet en is ook niet verplicht. Maar aangezien alles automatisch geboekt wordt, is het geen overkill. Eenmaal per jaar even de BTW rekeningen leegboeken kost met een jaarafsluiting nu ook niet zoveel tijd.

Mee werken aan de module -> het is niet mijn module . Ik heb een start gemaakt in de hoop dat andere hieraan gaan bijdragen. Samen gaat sneller en meerdere inzichten maken vaak een sterker product.
De structuur in launchpad is helemaal open, maar bijdragen via dit forum is natuurlijk ook goed. Bedankt voor je opmerkingen

Jan,

Even een afgeleide vraag, gezien je laatste paragraaf:

Hoe zet ik in OpenERP een openingsbalans op en hoe sluit ik een boekjaar goed af volgens Nederlandse accountancy begrippen?

Openingsbalans:
In 4.2 had ik na veel proberen uiteindelijk een goede openingsbalans, maar de gevolgde methode lijkt voor 5.0 niet meer te werken. Zodra ik het openingsboekjaar (de truuk van 4.2) probeer af te sluiten via een journaal met tegenrekeningen buiten het schema krijg ik eerst de melding 'Geen niet-afgeletterde boekingen in het oude jaar gevonden'. Als je vervolgens handmatig het afletteren ongedaan maakt en de tegenposten verwijdert lukt dat wel, maar worden de openingsposten verdubbeld. In plaats van 18000/18000 (de start) genereert dit 36000/36000.

Jaarafsluiting
Als ik een boekjaar afsluit met de wizard, gebeurt er van alles en nog wat, resulterend in allerlei wazige boekingen en vooral een foute balans.
Uit jouw laatste woorden begrijp ik dat je in feite het jaar met de hand afsluit door de diverse resultaatrekeningen leeg te boeken. Klopt dat? Waarom gebruik jij de wizard niet? Kan het huidige schema niet zo worden aangepast dat de wizard wel goed functioneert?

Ik ben benieuwd naar je antwoord.

Beginbalans:
Voorheen voerde ik een beginbalans in op 31 december, waarna bij een jaarafsluiting het nieuwe jaar goed begon.
In versie 5 is er een nieuw journaaltype "Situation" met de optie Centralized counterpart aangevinkt" bijgekomen, waardoor dit niet meer nodig zou moeten zijn. gewoon op startdatum boekhouding gebruiken (heb ik nog niet uitgetest)

Jaarafsluiting:
Praktijkprobleem is dat veel bedrijven pas rond april (of zlefs nog later) hun definitieve aangifte doen, jaarrekening deponeren en tot die tijd nog correctieboekingen maken op het voorgaande jaar a.d.h.v. accountantscontrole en hierdoor het resultaat van voorgaande jaar schommelt.
Met een systeemwizard jaarafsluiting worden ook alle periodes en het jaar volledig afgesloten! en zijn correctieboekingen niet meer mogelijk.
Dus as doen als alle cijfers zijn goedgekeurd! OpenERP 5 bied deze mogelijkheid ook.
Op 30 januari is er nog een bugfix ingebracht https://bugs.launchpad.net/openerp/+bug/317649
en er staat nog een blueprint open https://blueprints.launchpad.net/opener ... mprovement
Hiermee zouden de kostenrekeneningen en resultatenrekeningen een goed "resultaat cijfer" moet geven. (Heb ik nog niet uitgetest)

Waar ik op doelde zijn de balansrekeningen.
het systeem kan niet weten welke belansrekeningen elkaars tegenpolen zijn, aanschaf versus afschrijvingen. Als volledig is afgeschreven kunnen deze balansrekeningen tegen elkaar weggeboekt worden middels een memoriaalboeking. Hetzelfde geld voor de omzetbelasting grootboekrekeningen. Je neemt alleen het nog de te betalen cq het te ontvangen omzetbelasting mee naar het volgend jaar.
In geval van IFRS, dienen de "waarden" van bezittingen te worden herwaardeerd en verlies en/of winst hierop te worden weggeschreven of opgenomen. Dit kan het systeem natuurlijk niet zelf.
Dit gebeurt allemaal handmatig op transactiedatum 31 december.

Merci, helder verhaal. Als je de juiste tegenrekeningen wel zou koppelen, zou het dan wel kunnen? Ik ben geen accountant, dus graag wat geduld met mij....

Ik ben nog verder aan het testen met je BTW-schema... en ik ben tegen een kleine maar venijnige bug aangelopen: de code die je gebruikt voor terug te vorderen BTW 19% en variabel, zijn identiek. Daardoor overschrijft de variabele BTW die van 19% en verlies je de mogelijkheid om aan te geven dat je producten of diensten met hoog tarief in Nederland hebt gekocht.... Knap lastig dus, maar eenvoudig te corrigeren - voordat je de module laadt, daarna moet het met de hand.

Heb je overigens credit-facturen getest? Ik zie dat je de credit-codes op 1 hebt staan, net zoals in het l10n_chart_nl_standard (4.2), waar dit verkeerd uitpakt. Daar moeten ze -1 zijn. 5.0 heeft van alles veranderd, maar toch?

Groet,

BTW 19% en variabel, zijn identiek ->
Klopt, hier heb ik nog geen oplossing voor gevonden om variable BTW in te geven
Gezien de complicatie welke je aangeeft denk ik dat het het beste is om het variable BTW record te gaan verwijderen. Of heeft iemand hiervoor een oplossing?

Heb je overigens credit-facturen getest? ->
Ja, en dat werkte goed. Voor alle zekerheid vanochtend toch nog maar eens getest en het blijkt nog steeds goed te werken

Ho Jan,
Bezig met een openERP implementatie en kom nu aan de charts toe. Mijn vraag dan even; waarin verschilt (jouw ) versie met de openerp versies (l10n_chart_nl en l10n_chart_nl_standard (bron: modulelijst op doc.openerp.com)? Werken deze niet of zijn ze te basaal of wat...

En verder in et systeem dat ik opzet hoef ik alleen debiteuren te boeken en btw (uit verkopen, hoog / laag) omdat (vraag met niet waarom ) de uitendelijke boekhouding in een apart systeem gedaan wordt. Wat wel nodig is zijn BTW rapporten voor aangifte en uiteindelijk een export van verkopen naar het extra boekhoudsysteem. Voldoet het (veritos) schema hier beter aan dan de openerp schema's (vooropgesteld dat deze volgens jou überhaupt werken)....

Thorsten

Om maar met je laatste zin te beginnen, de schema's l10n_chart_nl en l10n_chart_nl_standard in de addons-extra directory werken niet, omdat ze geschreven zijn voor versie 4! Tijdens installatie gaat het al gelijk mis.
Dat is ook de reden geweest dat ik aan een nieuw schema voor versie 5 ben begonnen.
Vervolgens zijn die 2 V4 schema's ook niet bruikbaar als je met omzetbelasting anders dan "19% binnen Nederland" werkt. Alle andere omzetbelastingen zitten er niet in.
In de door mij ontwikkelde (en met hulp van Freerk en Gert verbeterde) versie, zitten ALLE mogelijke omzetbelastingen verwerkt, inclusief intra- en extra-communitair.

Het grootboekschema zelf (rubriek 0 t/m 9) is een uitgebreide basis, maar niet geschikt voor ieder bedrijf, daar iedere branch zo zijn eigen schema hanteert, zie mijn vorige postings. Waarschijnlijk zul je her den der wate rekeningen moeten verwijderen of wijzigen naar jullie specifieke behoefte.

Ik zal niet vragen naar de reden om met 2 systemen te (gaan) werken, maar je maakt mij wel nieuwsgierig. Wel jammer van jullie tijd die in dubbel financiële informatie verwerken gaat zitten.

Hoi Jan,
bedankt voor je uitleg. Beetje een algemeen probleem van modules die niet werken. Beter een paar modules die wel werken dan een hoop kopzorgen voor de mensen die serieus met het systeem aan de slag willen omwille van een mooie kreet: "meer dan 300 modules"....
Waarom een "dubbele" boekhouding... dat komt door de vraag van de klant die eigenlijk met zijn boekhouding tevreden is maar een tool wenst in ter ondersteuning van zijn groeiende activiteiten. Tevens ook een stuk vertrouwen (kleine mkb er) eerst maar een zien en dan...
Ik ben er van overtuigd dat als het systeem een jaar draait de wereld anders uit zie en ook dat hun accountants zich wel een paar keer achter de oren zullen krabben als ze zien hoe mooi en automatisch zo'n erp eigenlijk wwel kan werken. Maar das de toekomst (en wellicht doen alle beloofde modules binnen openerp het dan ook ).
Ben dus aan de slag gegaan met jouw versie en moet zeggen bravo! Alles ziet er op en er aan (voor een complete leek dan) maar de btw aangifte was al zo prachtig dat ik bij voorbaat overtuigd ben.
Alles prima dan? Nee...
Ik heb de module uit de trunk geïnstalleerd op een 5.0.3 versie (win 2003). de volgende problemen kwam ik bij installatie tegen:
bij installatie van de module account (tereglijk met het rekeningen schema) kon ik niet uit het nederlandse schema kiezen?! Vervolgens kwam wel de wizzard van et rekeningschema (met 6 cijvers, heb ik op 4 gezet). Het rekeningschema werd ook aangemaakt en was kennelijk meteen actief aangezien de al bestaane partners meteen aan de nederlandse rekeningen gekoppeld waren.
Omdat dit voor mij niet geheel duidelijk was in het begin heb ik per ongeluk nu wel zo'n 3 rekening schema's aangemaakt (in test db gelukkig...).
Doe ik iest verkeerd of zit er een glitch in de code? En vooral, mag ik er evengoed op vertrouwen dat het nu werkt!!

Groet
Thorsten