automatiseren gegevens kopiëren

[RenéP]

In de loop van vanmiddag zal ik reageren

[RenéP]

Een Journaal of Postenboek  (hier genoemd tblBoekingen) wordt normaliter elke maand afgesloten. De ingevoerde gegevens worden dan naar het Grootboek overgebracht, d.w.z. per rekening wordt het saldo van de posten overgebracht, niet elke post afzonderlijk. Dus als in november 5 keer een post is ingevoerd t.b.v. rekening  NS Retour, dan wordt het saldo van NS Retour naar het Grootboek overgebracht.

 

Het Grootboekbestand wordt gebruikt om vergelijkende financiële overzichten te kunnen maken (Balans, Verlies- en Winstrekening, staat van herkomst en besteding van middelen, etc.) Zoals je misschien bij Rapporten gezien heb regeneer ik sommige overzichten via een omweg. 

 

Waarom zitten Grootboek en grootboektwee niet in één tabel? Het zijn twee tabellen die nog geen functie hebben. tblGrootboekTwee is de te gebruiken tabel. De andere tabel kan worden verwijderd en wordt de naam tblGrootboekTwee gewijzigd in tblGrootboek.

 

De velden die vanuit tblBoekingen nodig zijn:

RekeningNr; Datum (jaar); Periode (correspondeert met het maandnummer); Bedrag (maandsaldo).

 

Vanuit tblRekeningen is nodig:

het veld Rekeningnaam.  (Via een relatie tussen tblBoekingen  en tblRekeningen ?)

 

 

Uit eerder bericht:

 

De velden 3 en 4 (de vlaggen) zijn bedoeld om te gebruiken ter voorkoming van fouten bij het opslaan van de gegevens uit de tabel Boekingen. Op het einde van het jaar (in elk geval ná 31 december en vóór de nieuwe boekingen van het nieuwe jaar) moeten de

H velden overgebracht worden naar de V velden en de H velden vervolgens op 0  worden gezet. 

 

Ik denk dat deze vlaggen gebruikt kunnen worden bij het ontwerp van  eventuele gebeurtenisprocedures (Visual Basic). Zo niet, dan kunnen deze velden verwijderd worden.

 

Ik hoop dat ik duidelijk ben geweest. En ja hoor, je krijgt van mij alle geduld die je denkt nodig te hebben.

 

Groeten,

René

[plx]

Voor bij als niet boekhouder ziet dit er toch nogal chaotisch uit. Het dubbel opnemen van records in tblBoeken gaat totaal aan me voorbij.
Die vlaggen daar begrijp ik helemaal niets van.

Jij wilt tblBoekingen leeg maken en de gegevens ervan wegschrijven in tblGrootboek?

[RenéP]

Ik zal in de loop van vandaag een overzicht maken van mijn bedoelingen en die ik in een programma wil onderbrengen. Vergeet alles wat naar boekhouden ruikt.

Alvast: er worden GEEN dubbele records in tblBoekingen opgenomen.

 

Tot later.

[RenéP]

Ik zoek dus naar VBA programmering voor het kopiëren van gegevens uit  tblBoekingen naar  tblGrootboek. Ik kom er zelf niet helemaal uit. (NB: tblGrootboek staat in de database genoemd als tblGrootboekTwee.)

 

1.Een periode (=maand) afsluiten in tblBoekingen. Voorbeeld: RekeningNr 12  met Rekeningnaam Benzine staat in tblBoekingen  

ingevoerd op 10 oktober voor € 45,00 op 14 oktober voor €63,00 en op 30 oktober voor €59,00. Het saldo van deze rekening moet dan overgebracht worden, dus RekeningNr 12 Benzine €167,00 naar tblGrootboek in het veld met kolom H10 (= Huidige periode 10, of te wel oktober 2015.) En zo geldt het  voor alle  rekeningen in tblBoekingen voor (in dit geval) oktober.

 

2. Variabelen e.d.  om een goed verloop van de procedure te krijgen. Bijv. de periode vast te stellen, op 1 januari in tblGrootboek de gegevens in de kolommen H1 t/m H12 overbrengen naar de kolommen V1 t/m V12 en vervolgens H1 t/m H12  op 0  zetten om voor het nieuwe jaar te gebruiken, ondervanging van fouten, e.d.m.

 

Ik stel voor om eerst het onder 1 genoemde te bekijken. 

 

Ik hoop iets duidelijker te zijn geweest.

[plx]

Toch een paar opmerkingen. GEBRUIK GEEN decimaal getal voor je rekening nummer!!!!
Maak elkens je een nieuw rekening maakt in tblBoekingen een nieuw record met de verschillende maanden in tabel tblGrootboek!

 

ik heb een frmA gemaakt met een knop en de code voor het verwerken van november.
Nogmaals de manier waarom je tblBoekingen maakt is voor mij als niet boekhouder chaotisch want alles wordt dubbel geboekt.
 

FinadAccess 2015.zip

17 november 2015 aangepast door plx

[RenéP]

Dag PLX,

 

Dank voor je reactie. Ik heb momenteel te weinig tijd om naar behoren naar de inhoud te kijken en eventueel te becommentariëren. Ik ben vanaf morgen enkele dagen afwezig en kom zaterdag terug. Dit laat ik je weten om elke misvatting op welk communicatieniveau dan ook te voorkomen. 

 

Je berichten doen soms denken aan een strenge leermeester. Daar is niets mis mee. Integendeel!

 

Over het chaotische: ik heb een geheel andere kijk op chaos als alleen het opslaan van twee keer dezelfde gegevens! Los hiervan: na overbrenging van de gegevens van tblBoekingen naar tblGrootboek is het de bedoeling dat dezelfde gegevens in tblBoekingen worden gewist. INDIEN MEN DIT WENST.

 

Over Punt 2 uit mijn bericht van maandag kreeg ik geen reactie. Nu wil ik je het volgende voorleggen: Mijn database Finad komt voort uit dBaseIII+, zoals ik eerder meldde. Niet alles is foutloos over te brengen naar de VBA van Access 2007, heb ik ervaren. Vandaar dan ook mijn hulpvraag. Ik probeer het programma van dBaseIII+ over te hevelen naar Acces 2007. Ik vind zelf dat me dat redelijk lukt. Maar redelijk lukken is iets anders als foutloos lukken. Mag ik je het programma van dBaseIII+ t.a.v. het sluiten van een periode, zij het enigszins aangepast, voorleggen? M.n. om te kijken naar de procedures, de gebruikte functies, declaraties variabelen etc. (die toch veel met VBA overeenkomen)? Laat me iets weten.

 

Maak telkens je een nieuw rekening maakt in tblBoekingen een nieuw record met de verschillende maanden in tabel tblGrootboek! Kijk, ter compensatie! Hier snap IK nou niets van. (Bij de gehele procedure waar we het hier over hebben, wordt ook gekeken naar een rekening die nog niet bekend is en die vervolgens wordt toegevoegd.)

 

 GEBRUIK GEEN decimaal getal voor je rekening nummer!!!! Daar is (was) een reden voor. Rekeningen die aan elkaar verwant zijn, werden onder een vast (voor-)nummer gesteld, en de decimalen waren voor de onderscheiden rekeningen. Denk hierbij aan bijvoorbeeld Verzekeringen. Er zijn meerdere verzekeringen, dus: 30.1 WA, 30.2 Brand etc. Je hebt me er wel van overtuigd dat dit net zo goed kan met 301, 302 etc. Ga ik veranderen. (Wat is eigenlijk tegen een decimaal gesteld rekeningnummer?)

 

Vriendelijke groet

René

[plx]

(Wat is eigenlijk tegen een decimaal gesteld rekeningnummer?)

 

 

computers rekenen niet zo nauwkeurig als het om decimale getallen gaat. In sommige gevallen is voor een computer 1*0.999999999999 =1 (of 1.00000000000) voor een berekening van een 100 m loop is dat ok...voor een raketlancering is dat twijfelachtig maar voor een rekening is het een drama want dat is gewoon een andere rekening.

 

Wil je een rekening per se numeriek, deel het op stukken gehele getallen. Voorgetal-getal-controlegetal   054-0246326-64 en maak van deze velden een samengestelde sleutel.

Persoonlijk neem ik dan liever één tekst veld waarvan je de onderdelen bij controle nog kunt converteren naar getallen.

 

En streng? Mss wel maar als je me kan overtuigen van een ander idee, ben ik bereid om te luisteren op voorwaarde dat je ook met mijn zienswijze rekening houdt.

[RenéP]

Procedure PeriodeSluiten.docx
 
Goede middag PLX, ik ben er weer.
 
(...) dat je ook met mijn zienswijze rekening houdt. In een voorgaand bericht schreef ik: "Je hebt me er wel van overtuigd dat dit net zo goed kan met 301, 302 etc. Ga ik veranderen." 
 
De procedure die je hebt geschreven (dank!) opent niet door een foutmelding ("set DB=Current Db : Compileerfout; Fout bij laden van DLL"), die niets met de procedure zelf te maken heeft. Op 24 dec. 2014 meldde ik deze fout al en je hebt me daarbij geadviseerd. Ik kreeg de melding niet meer en dacht dus: opgelost. Ook omdat ik alleen als het nodig is, aan de database "sleutel" en dus die melding niet te zien kreeg. Bij het begin van het huidige onderwerp opeens weer wel. Ook wanneer ik een record vanuit een formulier wilde verwijderen. Ik had dit allemaal na afsluiting aan je willen voorleggen, maar zie nu dat die foutmelding bij frmA ook voorkomt.
Toendertijd gaf Microsoft ook als mogelijkheid om via het register een en ander op te lossen. Die oplossing kon Microsoft ook bewerkstelligen. Alles uiteraard zonder verantwoordelijk te zijn voor als het eventueel misliep. Die mogelijkheid biedt  M ook nu nog, zag ik op haar site. Ik ben zeer onzeker voor wat betreft het sleutelen aan het register, temeer er nu tot mijn wel zeer grote tevredenheid Windows10 op mijn pc draait. Je hebt frmA en de betreffende database. Advies?
 
Ik heb nog een tweede advies nodig. Ik stuur je een bijlage met daarin een overzicht en commentaar van het dBaseIII+ programma over het Grootboek (PeriodeSluiten). Zou je er eens naar willen kijken en de procedureregels  in AccessVBA willen herschrijven of van commentaar te voorzien? (Zo heb ik nog niet kunnen ontdekken hoe een standaardmodule moet worden aangeroepen, net zo min als vanuit een procedure naar een benodigde tweede of sub-procedure).
 
Met vriendelijke groet,
René

[plx]

Als we nu eens van scratch (opnieuw) zouden beginnen.

Als je tabellen in dBase ok zijn, kunnen we ze wellicht wel importeren?

Of we vinden een oude pc waarbij je in dbase kan exportern naar een csv bestand?

 

Maak eens een word doc (of waarom niet meteen een Access database) met de tabellen en velden die je in dbase had?