[PHP] Factuur-id koppelen aan factuur regels

[Verwijderd]

Ik ben me aan het orienteren wat de beste manier is om facturen in een MySQL DB op te slaan.

Ik wil een aparte tabel voor de factuur-basis gebruiken en de factuurregels aan de factuur basis koppelen doormiddel van het factuur ID te gebruiken, factuurnummer kan ook... deze is alleen langer dus wellicht trager dan het factuurid.

Nu kan ik gebruik maken van een MySQL functie welke de laatste ID op een tabel onthoudt, dit is alleen niet te doen als meerdere mensen op hetzelfde moment een factuur voor dezelfde persoon aanmaken.

Een timestamp zou een oplossing kunnen bieden, hoewel dit ook tricky kan zijn... ook als je automatisch facturen zou willen genereren.

Een combinatie van klantnummer en timestamp zou wellicht kunnen, alleen je wil de invoicenummer dus ook opvolgend laten zijn, dit kan dan ook niet meer.

Ik zou dus een "random getal (timestamp+klantinfo)" kunnen gebruiken als referentie tussen de invoice en invoiceregels, alleen het factuurnummer zou autoincrement moeten zijn, of kan dit ook anders ? Dus het uitlezen van het laatste factuurnummer en dan deze gebruiken als nummer... kan ook tricky zijn als meerdere mensen welke een factuur aanmaken dezelfde waarde uitgelezen hebben als "laatste".

Wat zou een degelijke en veilige manier kunnen zijn ?

[Verwijderd]

bedoel jij niet gewoon mysql_insert_id() of iets dergelijks?

http://nl2.php.net/manual/en/function.mysql-insert-id.php

[MuisM4t]

Even voor mijn begrip: wat bedoel je met een factuur-basis en factuurregels?

[Johnny]

Het is geen probleem om mysql_insert_id() aan te roepen direct nadat je de query hebt uitgevoerd. Een andere manier is om gebruik te maken van transacties waarbij je pas nadat je alle queries succesvol hebt uitgevoerd een commit() doet om hem definitief te maken.

[Verwijderd]

Verwijderd schreef op maandag 30 maart 2009 @ 17:45:
bedoel jij niet gewoon mysql_insert_id() of iets dergelijks?

http://nl2.php.net/manual/en/function.mysql-insert-id.php

Ja klopt, dit bedoel ik.

Deze functie zou geen probleem op moeten leveren ?

Ik heb wel gelezen dat dit pas bij 100.000 inserts per seconde een probleem "zou" kunnen worden.... opzich veilig genoeg dus ?

Over commit() zou ik eens na kunnen zoeken... wellicht een goede optie.

[HuHu]

Verwijderd schreef op maandag 30 maart 2009 @ 17:56:
[...]


Ja klopt, dit bedoel ik.

Deze functie zou geen probleem op moeten leveren ?

Ik heb wel gelezen dat dit pas bij 100.000 inserts per seconde een probleem "zou" kunnen worden.... opzich veilig genoeg dus ?

Over commit() zou ik eens na kunnen zoeken... wellicht een goede optie.

Ten eerste is 100.000 inserts per seconde natuurlijk een kansloos argument, dat ga je nooit halen. Ten tweede staat in de documentatie gewoon vermeld dat mysql_insert_id() het ID terug geeft van de query die als laatste over die connectie is uitgevoerd. Als je op één connectie één INSERT doet en daarna mysql_insert_id() aanroept, dan krijg je altijd het ID van die INSERT terug, ook al hebben er in theorie nog 99.999 andere INSERTs tussen kunnen zitten.

Zo slim waren ze wel toen ze het maakten, want je zou echt niet de eerste zijn met dit probleem.

[Verwijderd]

Verwijderd schreef op maandag 30 maart 2009 @ 17:56:

Over commit() zou ik eens na kunnen zoeken... wellicht een goede optie.

Als je überhaupt had overwogen dit te maken zonder transacties...

[T-MOB]

De kanttekening bij mysql_insert_id() is dat je moet oppassen met persistente connecties. Je krijgt de laatste auto-increment van de connectie, niet per se die van je huidige script.
In een transactie kun je werken met de mysql-functie LAST_INSERT_ID().

[GlowMouse]

T-MOB schreef op maandag 30 maart 2009 @ 19:59:
De kanttekening bij mysql_insert_id() is dat je moet oppassen met persistente connecties. Je krijgt de laatste auto-increment van de connectie, niet per se die van je huidige script.

Als je een insert doet en dan een jaar wacht voordat je de laatste id opvraagt, dan krijg je nog steeds de juiste. Connecties worden niet tijdens de uitvoer van je script zomaar aan een andere thread uitgeleend.

[Boss]

Op zich kan je ook prima op het factuurnummer koppelen. Database technisch misschien niet de meest nette optie, maar het argument van snelheid zou ik me geen zorgen om maken. Tenzij je bezig bent met een next-gen-enterprise-accounting applicatie

[Verwijderd]

GlowMouse schreef op maandag 30 maart 2009 @ 20:05:
[...]

Als je een insert doet en dan een jaar wacht voordat je de laatste id opvraagt, dan krijg je nog steeds de juiste. Connecties worden niet tijdens de uitvoer van je script zomaar aan een andere thread uitgeleend.

Dus prima geschikt voor batch gerelateerde zaken en tevens handmatig dus.

Boss schreef op maandag 30 maart 2009 @ 20:09:
Op zich kan je ook prima op het factuurnummer koppelen. Database technisch misschien niet de meest nette optie, maar het argument van snelheid zou ik me geen zorgen om maken. Tenzij je bezig bent met een next-gen-enterprise-accounting applicatie

Tja... zou leuk zijn

[Verwijderd]

Is het mogelijk om twee identieke factuurnummers te hebben?
Wat heeft het ID dan nog voor nut?

[Verwijderd]

Verwijderd schreef op dinsdag 31 maart 2009 @ 10:47:
Is het mogelijk om twee identieke factuurnummers te hebben?
Wat heeft het ID dan nog voor nut?

Omdat het ID gebruikt kan worden op je factuurnummer op te bouwen en dit wel handig is met autoincrement.

[HuHu]

Verwijderd schreef op dinsdag 31 maart 2009 @ 10:47:
Is het mogelijk om twee identieke factuurnummers te hebben?
Wat heeft het ID dan nog voor nut?

Dat ligt aan je definitie van factuur en factuurnummer. Wettelijk gezien moet elke factuur een uniek en oplopend factuurnummer hebben. Echter heb je verschillende typen facturen (reeds voldaan, nog te betalen, enz...).

Als een factuur van status veranderd (van nog te betalen naar reeds voldaan), dan is het netjes om een nieuwe factuur te sturen met daarop zichtbaar de gewijzigde status. Je kunt besluiten die nieuwe factuur een nieuw factuurnummer te geven, maar dat kan onduidelijk zijn. Daarom kun je ook hetzelfde factuurnummer op de nieuwe factuur zetten.

In je database bewaar je zowel de 'nog te betalen' als de 'reeds voldaan' factuur. Beiden hebben een uniek ID, maar wel hetzelfde factuurnummer.

Dus afhankelijk van hoe je een probleem (statuswijziging van een factuur) aanpakt kun je wel/geen identieke factuurnummers hebben.

[Verwijderd]

Ik was me overigens aan het beraden of ik de details van een invoice, invoiceregels dus... direct als detail in een record zal zetten of deze doormiddel van een did en een join in een query uit de producten tabel zal halen en ze op die manier laten showen....

Ik ben zelf van mening dat directe invoice records makkelijker zijn omdat je dan de producten niet hoeft te laten bestaan in je billing database.

Iemand een andere mening ?

[Gomez12]

HuHu schreef op dinsdag 31 maart 2009 @ 11:12:
[...]
In je database bewaar je zowel de 'nog te betalen' als de 'reeds voldaan' factuur. Beiden hebben een uniek ID, maar wel hetzelfde factuurnummer.

Dus afhankelijk van hoe je een probleem (statuswijziging van een factuur) aanpakt kun je wel/geen identieke factuurnummers hebben.

Ik zal wel verkeerd denken, maar dan heb je toch 1 factuur met meerdere statussen ( waarbij die statussen nog een statusveld binnen die factuur kan zijn ), als een factuur compleet betaald is dan krijg je kopfactuur een status betaald. De rest is status niet volledig betaald.
Of het dan over enkele regels niet-betaald of over de complete factuur niet betaald gaat dat valt wel op te maken uit een query op je factuur-regels gekoppeld aan je boekhouding.

2 facturen bijhouden lijkt me echt complete onzin als het enkel om een status gaat.

Imho heb je in een factuur kop staan : status en aantal x geprint.
Zolang status niet volledig betaald is dan kan je hem herprinten.
Als het aantal x geprint hoger is dan 1 dan krijg je de tekst herinnering erbij.
Voor de rest lijkt het me alleen maar de vraag wat wil je loggen.

Zelfs een status veld ( volledig betaald / niet volledig betaald ) gaat (in theorie / schoolboekjes ) al in tegen de 2e normaliserings regel ( maar is over het algemeen wel performance technisch handig als het systeem meerdere jaren draait ) het nut van een factuur meerdere keren opslaan zie ik dan ook helemaal niet.

Verwijderd schreef op donderdag 02 april 2009 @ 23:00:
Ik was me overigens aan het beraden of ik de details van een invoice, invoiceregels dus... direct als detail in een record zal zetten of deze doormiddel van een did en een join in een query uit de producten tabel zal halen en ze op die manier laten showen....

Ik ben zelf van mening dat directe invoice records makkelijker zijn omdat je dan de producten niet hoeft te laten bestaan in je billing database.

Iemand een andere mening ?

Ik ben zelf structureel van mening dat elk detail van een factuur apart opgeslagen moet worden ( je moet het 7 jaar lang kunnen herproduceren ) dus in de invoice tabel.
Maar ik ken ook systemen die teruggrijpen naar de originele tabellen waar met 100% versioning gewerkt wordt.

Mits jij 100% versioning hebt geintroduceerd ( dus ook bijv iets lulligs als btw-percentage / kortingspercentage per klant per artikel etc. ) is het je eigen keus.

Heel simpel gezegd moet je over 7 jaar ongeacht welke assortimentswijzigingen / klantadreswijzigingen / kortingspercentageswijzigingen / kortingsgroepswijzigingen / btw-wijzigingen etc. etc. er ook geweest zijn de originele factuur kunnen herproduceren. Dan kan je 7 jaar versioning constant meedragen of je kan gewoon kiezen voor dubbele opslag.

[Verwijderd]

Die 7 jaar (wat volgens mij 5 jaar is.. maar goed..) loopt wel los... data zal er niet uit gehaald worden.

Het gaat om de manier van opslaan... bij een referentietabel kun je een product nooit wijzigen en zul je een nieuw product aan moeten maken met een andere prijs als je dit wil.

Ik ga voor 100% invoice regels heb ik al bedacht... veel flexibeler.