Gå til innhold

MySQL for bokføring og regnskap?

Rumbeldunk

Anbefalte innlegg

Rumbeldunk

Rumbeldunk

Skrevet
Skrevet (endret)

Går det å bruke slike tabeller for regnskapsføring? Hvordan bør tabellene være til bokføring? :hmm:

 

Regnskapsføring (bankgiro, administrasjon, diverse_inn_ut):

 

CREATE TABLE `bankgiro` (

`id` int(10) NOT NULL auto_increment,

`dato` date NOT NULL default '0000-00-00',

`tekst` varchar(255) NOT NULL default '',

`bilag` varchar(255) NOT NULL default '',

`debet` varchar(255) NOT NULL default '',

`kredit` varchar(255) NOT NULL default '',

PRIMARY KEY (`id`),

UNIQUE KEY `id` (`id`)

) TYPE=MyISAM AUTO_INCREMENT=1;

 

CREATE TABLE `administrasjon` (

`id` int(10) NOT NULL auto_increment,

`dato` date NOT NULL default '0000-00-00',

`tekst` varchar(255) NOT NULL default '',

`bilag` varchar(255) NOT NULL default '',

`debet` varchar(255) NOT NULL default '',

`kredit` varchar(255) NOT NULL default '',

PRIMARY KEY (`id`),

UNIQUE KEY `id` (`id`)

) TYPE=MyISAM AUTO_INCREMENT=1;

 

CREATE TABLE `diverse_inn_ut` (

`id` int(10) NOT NULL auto_increment,

`dato` date NOT NULL default '0000-00-00',

`tekst` varchar(255) NOT NULL default '',

`bilag` varchar(255) NOT NULL default '',

`debet` varchar(255) NOT NULL default '',

`kredit` varchar(255) NOT NULL default '',

PRIMARY KEY (`id`),

UNIQUE KEY `id` (`id`)

) TYPE=MyISAM AUTO_INCREMENT=1;

Endret av Rumbeldunk
Lenke til kommentar

Videoannonse

Videoannonse
Annonse
roac

roac

Skrevet
Skrevet

Personlig vil jeg si at det er en rekke "feil" her:

 

1. Det bør være en tabell for alle posteringer, med kode for hva slags postering det er snakk om.

 

2. Beløp bør lagres som en "monetary" datatype, evt et desimaltall.

 

3. Beløp kan med fordel lagres i én kolonne, og så avgjør fortegn om det er snakk om kredit eller debet. En "linje" skal vel uansett ikke ha både kredit og debet?

 

4. Unique Key er vel ikke nødvendig på kolonnen som er primary key, siden en primary key av natur skal opprette denne selv. Du risikerer å sitte med dobbelt sett av indekser/keys som må holdes oppdatert.

 

5. MyISAM er ikke en egnet databasemotor til denne type datamodeller, jeg ville valgt InnoDB eller en nyere (er det Falcon den heter?) som har bedre transaksjonshåndtering.

 

6. Bilag er vel snakk om bilagsnummer, og bør derfor være en numerisk datatype.

 

Forskjeller mellom regnskap og bokføring aner jeg ikke.

Lenke til kommentar
Frank2004

Frank2004

Skrevet
Skrevet (endret)

Jeg ville startet med følgende tabeller:

Konto

Postering

Bilag

Kontakt (Kunder og leverandører)

 

 

5. MyISAM er ikke en egnet databasemotor til denne type datamodeller, jeg ville valgt InnoDB eller en nyere (er det Falcon den heter?) som har bedre transaksjonshåndtering.

Jepp. Bra eksempel her på at mysql er vanskeligere å bruke (riktig) enn andre database-systemer, hvor man slipper tenke på (eller vite om) slikt.

Endret av Frank2004
Lenke til kommentar
Rumbeldunk

Rumbeldunk

Skrevet
  • Forfatter
Skrevet

Det er ikke noen som har god kjennskap til regnskapsføring her inne da, og som kan forklare? Tror det er mange i forumet som har lyst på en slik database.

 

Vil det være nok om postering er slik?

 

CREATE TABLE `postering` (

`id` int(10) NOT NULL auto_increment,

`bilag` int(10) NOT NULL default '',

`belop_kroner` bigint(19) NOT NULL default '',

`belop_ore` int(2) NOT NULL default '',

`konto_kode` int(4) NOT NULL default '',

`debet_kredit` varchar(1) NOT NULL default '',

`dato` date NOT NULL default '0000-00-00',

PRIMARY KEY (`id`),

UNIQUE KEY `id` (`id`)

) TYPE=MyISAM AUTO_INCREMENT=1;

Lenke til kommentar
roac

roac

Skrevet
Skrevet
Det er ikke noen som har god kjennskap til regnskapsføring her inne da, og som kan forklare? Tror det er mange i forumet som har lyst på en slik database.

 

Vil det være nok om postering er slik?

 

CREATE TABLE `postering` (

`id` int(10) NOT NULL auto_increment,

`bilag` int(10) NOT NULL default '',

`belop_kroner` bigint(19) NOT NULL default '',

`belop_ore` int(2) NOT NULL default '',

`konto_kode` int(4) NOT NULL default '',

`debet_kredit` varchar(1) NOT NULL default '',

`dato` date NOT NULL default '0000-00-00',

PRIMARY KEY (`id`),

UNIQUE KEY `id` (`id`)

) TYPE=MyISAM AUTO_INCREMENT=1;

Hvorfor skiller du kroner og øre? Det gjør bare at du ikke kan regne med det etterpå. hvorfor trekker du debeg_kredit som en kolonne, og ikke som fortegnet til en desimal datatype som sier hvor mange kroner,øre som har gått, og med et fortegn som sier om pengene har gått ut eller inn.

 

Og fortsatt er ikke MyISAM en egnet databasemotor.

 

Til slutt, det er mulig MySQL støtter det, men å sette en int default til en tom tekststreng er strengt tatt en selvmotsigelse. Default bør være NULL (ingen verdi), evt hvis du ikke klarer å håndtere dette en fornuftig numerisk verdi.

 

Bortsett fra dette vil jeg si at det har blitt bedre.

Lenke til kommentar
RulleRimfrost

RulleRimfrost

Skrevet
Skrevet

Aldri skill kroner og øre nei.

 

Ikke er jeg heller noen kløpper på regnskap, men dette er strengt tatt ikke regnskap, kun en transaksjonslogg.

Husk at når du f eks fører en kreditpost på en konto vil det alltid føres en motsvarende debetpost på en annen konto (f eks betaler du en faktura synker kontantbeholdning, mens eiendeler øker osv. Ellers blir ikke balansen ved avluttet periode 0, og regnskapet er helt bortkastet). Søk opp NRS, så blir det nok fint.

Lenke til kommentar
Rumbeldunk

Rumbeldunk

Skrevet
  • Forfatter
Skrevet (endret)

Det er ikke transaksjonslogg jeg skal ha, men tabeller som er egent for regnskap- og bokføring.

 

Å føre en motsvarende debetpost på en annen konto kan vi ordne med PHP :) det er hvordan tabellene skal være utformet jeg lurer på.

Endret av Rumbeldunk
Lenke til kommentar
Frank2004

Frank2004

Skrevet
Skrevet (endret)
Forstår ikke helt hva du mener med å bruke fortegn til en desimal. Det må være en god tabell for dette, slik at det blir mulig å regne sammen alt til slutt for driftsregnskap og balanse. Se et eksempel her: http://www.iogt.no/getfile.php/94699.637/regneeks.xls

Med desimal menes datatypen decimal/numeric. Jeg antar denne er støttet av, og beskrevet i dokumentasjonen til, mysql.

 

En kreditering er penger ut fra konto, altså negativt fortegn, mens debitering blir et positivt beløp.

Endret av Frank2004
Lenke til kommentar
Frank2004

Frank2004

Skrevet
Skrevet
Ikke er jeg heller noen kløpper på regnskap, men dette er strengt tatt ikke regnskap, kun en transaksjonslogg.

Ettersom emnet alt er tatt opp; Har jeg rett i at regnskapsfolk kaller hver postering(slinje) for en transaksjon?

 

Som en vanlig dødelig ville jeg heller sagt at hele bilaget var en transaksjon, men så kan jeg ikke regnskap heller..

Lenke til kommentar
Rumbeldunk

Rumbeldunk

Skrevet
  • Forfatter
Skrevet (endret)

Ingen som kan regnskap her? hva om det blir bokettersyn fra Skateetaten da :thumbup:

 

En postering skal/bør være slik da?:

 

Her er bilag med auto_increment, som løpende nummerering. Bigint kan bruke negative tall om det blir satt inn som -1000,00, kontokode for skille mellom egenkapital, salgs-og driftsinntekt og lignende. Så tekst til å beskrive bilaget og dato. Har likvel med d_k for debet og kredit som D eller K. Fakturaer skal kunne scannes og kastes, derfor er det lagt til filvedlegg_pdf_bilag.

 

CREATE TABLE `postering` (

`bilag` int(10) NOT NULL auto_increment,

`belop_kroner` bigint(19) NOT NULL default '',

`d_k` varchar(1) NOT NULL default '',

`kontokode` int(4) NOT NULL default '',

`tekst` varchar(255) NOT NULL default '',

`filvedlegg_pdf_bilag` varchar(255) NOT NULL default '',

`dato` date NOT NULL default '0000-00-00',

PRIMARY KEY (`id`),

UNIQUE KEY `id` (`id`)

) TYPE=MyISAM AUTO_INCREMENT=1;

Endret av Rumbeldunk
Lenke til kommentar
RulleRimfrost

RulleRimfrost

Skrevet
Skrevet

Sist jeg brukte en hovedbok var på vgs i -92, og da var de laget av papir :) Men vi har noen regnskap og faktura-databaser på jobben.

Husker ikke dette sikkert, men tror disse basene benyttet minst desimal(26,6) for beløp og egne kolonner for debet og kredit. Mener også også standard norske kontokoder er minst 5 siffer ?

 

Tror økonomifolkene ser 1 transaksjon som 2 posteringer (D/K) og et bilag kan inneholde mange transaksjoner (basebeløp, mva, renter osv)

Da kan du si at en postering kan godt se sånn ut, men det er bare en halv transaksjon, og en halv transaksjon kan ikke gi et helt bilag :?Lurer på om ikke regnskapsfolkene holder til i Excel-forum...

Lenke til kommentar
blackbrrd

blackbrrd

Skrevet
Skrevet (endret)

Vel, det er jo ihvertfall ikke lov å bruke f.eks excel til å generere fakturaer da.. :p

 

Har selv bare laget et faktura-system og der knytter jeg bare fakturaene mot et journalnr og generer journal filen som regnskapet trenger ved forespørsel. Ingen grunn til å lagre de dataene nok en gang, alt du trenger skal jo allerede ligge på fakturaen. Som du ikke skal kunne endre etter at den er opprettet.

 

En linje i journalen inneholder diverse stuff, men det viktigste er:

Debitkonto, Kreditkonto og beløp.

Debitkonto og Kreditkonto burde være foreign keys til en konto-tabell.

Beløp burde være numeric e.l. med to desimaler. Dvs et fast-presisjonsfelt. Det er ikke så gøy å jobbe med flyt-tall når regnskapsfolka får spunk hvis noe er ett øre feil :p

 

... og hvis det er noen som lurer, jeg har ikke rørt koden jeg lagde på en god stund nå, så derav de vage detaljene. ;)

Endret av blackbrrd
Lenke til kommentar
  • 2 uker senere...
Rumbeldunk

Rumbeldunk

Skrevet
  • Forfatter
Skrevet (endret)

Har grublet litt, og laget en "old-school" modell i notisblokk :new_woot: . Her finnes 3 eksempel-kontoplaner, som er navnet på tabellene. Eksemplene nedenfor viser hvordan dataene vil se ut.

 

Kontoplanene er:

3910: Representasjon

3911: Bankgiro/Postgiro

3912: Innkjøp

 

I tillegg en tabell med autonummer (id), hvor ID'et nummererer andre bøker (kontoplanene).

 

----------------------------------------------------------------
Tabell #Indeks
id | tekst					| dato	   | konto_d | konto_k | 
----------------------------------------------------------------
1  | Uttak til representasjon | 2008-06-25 | 3910	| 3911	|
----------------------------------------------------------------
2  | Uttak til representasjon | 2008-06-26 | 3910	| 3911	|
----------------------------------------------------------------
3  | Innkjøp av kontorutstyr  | 2008-06-26 | 3912	| 3911	|
----------------------------------------------------------------
4  | Uttak til representasjon | 2008-06-26 | 3910	| 3911	|
----------------------------------------------------------------

 

Når det blir ført et bilag i regnskapet, blir det satt inn i tabellen over.

 

Dersom vi skal se på bilaget 3, og dette åpner med en spørring:

 

SELECT * FROM 3912 AS a INNER JOIN 3911 AS b on a.id=b.id WHERE a.id ='3'

 

Så fungerer det OK, men er det noe kritikkverdig når det gjelder arkitekturen for en slik layout?

 

Tabell #3910 (Representasjon)
-----------------------------------------------------------------------------------------------
id | debet | kredit | tekst					| vedlegg_bilag | kundenr | dato	   | konto
-----------------------------------------------------------------------------------------------
1  | 79,50 |		| Uttak til representasjon | fil1.pdf	  | 1002	| 2008-06-25 | 3911
-----------------------------------------------------------------------------------------------
2  | 1000  |		| Uttak til representasjon | fil2.pdf	  | 1002	| 2008-06-26 | 3911
-----------------------------------------------------------------------------------------------
3  | 500   |		| Uttak til representasjon | fil4.pdf	  | 1002	| 2008-06-26 | 3911
-----------------------------------------------------------------------------------------------
##########################################################################
Tabell #3911 (Bankgiro)
-----------------------------------------------------------------------------------------------
id | debet | kredit | tekst					| vedlegg_bilag | kundenr | dato	   | konto
-----------------------------------------------------------------------------------------------
1  |	   | 79,50  | Uttak til representasjon | fil1.pdf	  | 1002	| 2008-06-25 | 3910
-----------------------------------------------------------------------------------------------
2  |	   | 1000   | Uttak til representasjon | fil2.pdf	  | 1002	| 2008-06-26 | 3910
-----------------------------------------------------------------------------------------------
3  |	   | 3654   | Innkjøp av kontorutstyr  | fil3.pdf	  | 1002	| 2008-06-26 | 3912
-----------------------------------------------------------------------------------------------
4  |	   | 500	| Uttak til representasjon | fil4.pdf	  | 1002	| 2008-06-26 | 3910
-----------------------------------------------------------------------------------------------
##########################################################################
Tabell #3912 (Innkjøp)
-----------------------------------------------------------------------------------------------
id | debet | kredit | tekst					| vedlegg_bilag | kundenr | dato	   | konto
-----------------------------------------------------------------------------------------------
3  | 3654  |		| Innkjøp av kontorutstyr  | fil3.pdf	  | 1002	| 2008-06-25 | 3911
-----------------------------------------------------------------------------------------------

 

For driftsregnskapet burde det gå med noe lignende:

 

SELECT SUM(debet) FROM 3910

SELECT SUM(kredit) FROM 3910

 

SELECT SUM(debet) FROM 3912

SELECT SUM(kredit) FROM 3912

 

driftsregnskap #3910
------------------------------
| debet   | kredit | resultat
------------------------------
| 1579,50 |		| -1579,50
------------------------------

 

driftsregnskap #3912
------------------------------
| debet | kredit | resultat
------------------------------
| 3654  |		| -3654
------------------------------

 

Overskudd/Underskudd: -5238,50

Endret av Rumbeldunk
Lenke til kommentar
Rumbeldunk

Rumbeldunk

Skrevet
  • Forfatter
Skrevet
Har grublet litt, og laget en "old-school" modell i notisblokk :new_woot: . Her finnes 3 eksempel-kontoplaner, som er navnet på tabellene. Eksemplene nedenfor viser hvordan dataene vil se ut.

 

Kontoplanene er:

3910: Representasjon

3911: Bankgiro/Postgiro

3912: Innkjøp

 

I tillegg en tabell med autonummer (id), hvor ID'et nummererer andre bøker (kontoplanene).

 

----------------------------------------------------------------
Tabell #Indeks
id | tekst					| dato	   | konto_d | konto_k | 
----------------------------------------------------------------
1  | Uttak til representasjon | 2008-06-25 | 3910	| 3911	|
----------------------------------------------------------------
2  | Uttak til representasjon | 2008-06-26 | 3910	| 3911	|
----------------------------------------------------------------
3  | Innkjøp av kontorutstyr  | 2008-06-26 | 3912	| 3911	|
----------------------------------------------------------------
4  | Uttak til representasjon | 2008-06-26 | 3910	| 3911	|
----------------------------------------------------------------

 

Når det blir ført et bilag i regnskapet, blir det satt inn i tabellen over.

 

Dersom vi skal se på bilaget 3, og dette åpner med en spørring:

 

SELECT * FROM 3912 AS a INNER JOIN 3911 AS b on a.id=b.id WHERE a.id ='3'

 

Så fungerer det OK, men er det noe kritikkverdig når det gjelder arkitekturen for en slik layout?

 

Tabell #3910 (Representasjon)
-----------------------------------------------------------------------------------------------
id | debet | kredit | tekst					| vedlegg_bilag | kundenr | dato	   | konto
-----------------------------------------------------------------------------------------------
1  | 79,50 |		| Uttak til representasjon | fil1.pdf	  | 1002	| 2008-06-25 | 3911
-----------------------------------------------------------------------------------------------
2  | 1000  |		| Uttak til representasjon | fil2.pdf	  | 1002	| 2008-06-26 | 3911
-----------------------------------------------------------------------------------------------
3  | 500   |		| Uttak til representasjon | fil4.pdf	  | 1002	| 2008-06-26 | 3911
-----------------------------------------------------------------------------------------------
##########################################################################
Tabell #3911 (Bankgiro)
-----------------------------------------------------------------------------------------------
id | debet | kredit | tekst					| vedlegg_bilag | kundenr | dato	   | konto
-----------------------------------------------------------------------------------------------
1  |	   | 79,50  | Uttak til representasjon | fil1.pdf	  | 1002	| 2008-06-25 | 3910
-----------------------------------------------------------------------------------------------
2  |	   | 1000   | Uttak til representasjon | fil2.pdf	  | 1002	| 2008-06-26 | 3910
-----------------------------------------------------------------------------------------------
3  |	   | 3654   | Innkjøp av kontorutstyr  | fil3.pdf	  | 1002	| 2008-06-26 | 3912
-----------------------------------------------------------------------------------------------
4  |	   | 500	| Uttak til representasjon | fil4.pdf	  | 1002	| 2008-06-26 | 3910
-----------------------------------------------------------------------------------------------
##########################################################################
Tabell #3912 (Innkjøp)
-----------------------------------------------------------------------------------------------
id | debet | kredit | tekst					| vedlegg_bilag | kundenr | dato	   | konto
-----------------------------------------------------------------------------------------------
3  | 3654  |		| Innkjøp av kontorutstyr  | fil3.pdf	  | 1002	| 2008-06-25 | 3911
-----------------------------------------------------------------------------------------------

 

For driftsregnskapet burde det gå med noe lignende:

 

SELECT SUM(debet) FROM 3910

SELECT SUM(kredit) FROM 3910

 

SELECT SUM(debet) FROM 3912

SELECT SUM(kredit) FROM 3912

 

driftsregnskap #3910
------------------------------
| debet   | kredit | resultat
------------------------------
| 1579,50 |		| -1579,50
------------------------------

 

driftsregnskap #3912
------------------------------
| debet | kredit | resultat
------------------------------
| 3654  |		| -3654
------------------------------

 

Overskudd/Underskudd: -5238,50

 

Ordentlige kontoplaner: konto.txt

Lenke til kommentar
Frank2004

Frank2004

Skrevet
Skrevet
Dersom vi skal se på bilaget 3, og dette åpner med en spørring:

 

SELECT * FROM 3912 AS a INNER JOIN 3911 AS b on a.id=b.id WHERE a.id ='3'

 

Så fungerer det OK, men er det noe kritikkverdig når det gjelder arkitekturen for en slik layout?

 

Kan du vise meg en spørring som henter ut alle posteringer på kto. 3000 - 3999?

 

Og føre dette bilaget:

6900: debet 1000

2710: debet 250

1900: kredit 1250

Lenke til kommentar
Frank2004

Frank2004

Skrevet
Skrevet
en tabell som heter kontoplan som referer til kontoplantype som inneholder kontonr og beskrivelse.

Har faktisk sett kontoplantype-tabellen du beskriver, og gremmes skikkelig over det navnet. :) En kontoplan er vel en samling kontoer for et bestemt bruksområde (evt. firma), så jeg ville gått ut fra at kontoplantype inneholder data som 'Kontoplan for privatregnskap', 'Kontoplan for gartnere', 'Bob-rogers kontoplan', osv.

 

Jeg er ikke sikker på at OP trenger en kontotype-tabell heller. Ser både fordeler og ulemper med dette hvis systemet skal håndtere flere kontoplaner; men har ikke nok erfaring med slike systemer til å vite hva som veier tyngst.

Lenke til kommentar
Rumbeldunk

Rumbeldunk

Skrevet
  • Forfatter
Skrevet

Har fått info og tips fra Skatteetaten, som skriver at:

 

For å lage en bokføringsspesifikasjon må du kombinere ulike opplysninger fra ulike kontoer for å vise hvordan bilaget er postert. Da må du søke gjennom alle kontotabellene, for å finne linjene til det bilaget du skal sette sammen informasjon om, og det må gjøres for hvert bilag som er ført i perioden.

 

Et tips er å lage en tabell som inneholder bilagslinjer, der hver linje har opplysninger om kredit- eller debetpostering, der hvert bilag har to eller flere slike bilagslinjer.

 

Da kan du gruppere/sortere alle bilagslinjene etter spesifikasjon. Det må være mulig å registrere all informasjon som er for de ulike spesifikasjonene.

 

Et bilag skal føres med like stort beløp til kredit som til debet, fordelt på to eller flere bilagslinjer.

Eksempel: Utgående faktura for avgiftspliktig salg på kr 2500 inkl mva

 

Debet: Kunde kr 2500

Kredit: Avg.pl. salg kr 2000**

Kredit: Utgående mva 25% kr 500

 

** (må kodes slik at grunnlaget kommer på riktig sted i omsetningsoppgave og MVA-spesifikasjon)

 

 

Eksempelet mitt er nesten riktig, men trenger en kolonne til MVA-spesifikasjon.

Egne tabeller for kontoplaner fjernes. Alt kan registreres stort sett i én tabell, mer flere kolonner.

 

Skal poste en ny versjon SQL-tabellen en dag, men post gjerne forslag. Jo flere, jo bedre :)

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
Gå til emneliste
×
×
  • Opprett ny...