[VB & MySQL] Voorraad beheer performance en mogelijkheden

[Fles]

Beste mede tweakers,

Ik ben nu bezig met een model opzetten voor een voorraad beheersysteem. Om het geheel te realiseren gebruik ik VB en MySQL via ODBC. Nu loop ik echter tegen een probleem aan, namelijk het volgende:

Bij het invoeren van een product kan deze na een tijdje verschillende statussen krijgen, zoals: 'besteld', 'nabestelling', 'vervallen'. Als je nu bijvoorbeeld 10 keer één product invoert, kan het best zijn dat 5 daarvan een andere status krijgen dan de rest.

Als ik nu in de database één record toevoeg met als aantal 10, dan kan ik dit niet goed verwerken. Het leek het me het makkelijkst werken om gewoon 10 records toe te voegen, die elk dus een aparte status kunnen krijgen en deze koppelen aan het artikelnummer/omschrijving. Met behulp van groeperen in SQL kun je het toch over laten komen als één

Nu vraag ik me af hoe het met de performance zit als je het op deze manier aan gaat pakken. Je moet dan de producten in een loop zetten die iedere keer een query vanuit VB naar MySQL stuurt. Nou geloof ik dat VB en MySQL al niet de meest ideale combinatie is, vandaar mijn bezorgdheid

Ik denk dat er per jaar ongeveer 10000 aantallen moeten worden verwerkt, maar het systeem moet wel wat jaartjes mee denk ik.

Weet iemand wat over performance of dit problemen op levert, of heeft misschien een alternatief voor dit systeem?

[whoami]

Eerst gewoon ff dit: waarom zouden VB en MySQL geen goede combinatie zijn ? Als je het goed gebruikt, zie ik er geen graten in (afgezien dat MySQL dan eigenlijk eerder een brak dbms is).

Ik snap ook niet waarom je 10 keer product één zou invoegen ?
Jij, als klant plaatst een bestelling, die bestelling bevat product 1, waarvan je 10 stuks besteld.
Dan zou je gewoon één bestelregel moeten maken waarmee je aangeeft dat je 10 stuks van product 1 hebt besteld, en niet gaan foefelen zoals jij wilt doen, want dan kom je geheid in de problemen.
(Tenzij het natuurlijk de specifieke business-logica vereist dat de klant per eenheid kan zien wat de status is, maar dat lijkt me sterk).

Ik begrijp ook niet wat je met dit bedoeld:

u vraag ik me af hoe het met de performance zit als je het op deze manier aan gaat pakken. Je moet dan de producten in een loop zetten die iedere keer een query vanuit VB naar MySQL stuurt.

welke query ga je hier naar de DB sturen, en waarom ?

[dingstje]

Items die nog niet effectief ontvangen zijn maken geen deel uit van de technische voorraad. Ik zou ze dan ook nog niet opnemen in die tabel. Ik zou echter wel een koppeling maken in je applicatie naar de tabel waarin je de orders bij de leveranciers bijhoudt en hun status. Pas als ze effectief geleverd zijn kun je ze dan zetten in je tabel met voorraad. Het zou bijvoorbeeld kunnen zijn dat je per product een serienummer wil ingeven, en dat kan je (in de meeste gevallen) pas wanneer je de producten effectief ontvangen hebt. Van die bestellingen bij leveranciers zul je waarschijnlijk toch moeten bijhouden wanneer ze waarschijnlijk geleverd zullen worden etc. dus een aparte tabel zul je vast wel nodig hebben.

[Fles]

whoami schreef op dinsdag 29 november 2005 @ 19:33:
Eerst gewoon ff dit: waarom zouden VB en MySQL geen goede combinatie zijn ? Als je het goed gebruikt, zie ik er geen graten in (afgezien dat MySQL dan eigenlijk eerder een brak dbms is).

Ik snap ook niet waarom je 10 keer product één zou invoegen ?
Jij, als klant plaatst een bestelling, die bestelling bevat product 1, waarvan je 10 stuks besteld.
Dan zou je gewoon één bestelregel moeten maken waarmee je aangeeft dat je 10 stuks van product 1 hebt besteld, en niet gaan foefelen zoals jij wilt doen, want dan kom je geheid in de problemen.
(Tenzij het natuurlijk de specifieke business-logica vereist dat de klant per eenheid kan zien wat de status is, maar dat lijkt me sterk).

Ik begrijp ook niet wat je met dit bedoeld:

[...]
welke query ga je hier naar de DB sturen, en waarom ?

Misschien is het niet helemaal duidelijk naar voren gekomen waar het om gaat.

Als ik 1 bestelregel invoer met het aantal 10, dan kan ik niet per stuk de status aangeven. Het kan zijn als ik op deze manier werk dat er van die 10 maar 5 binnen komen en 3 in nabestelling komen en 2 vervallen. Dit is een beetje moeilijk aangeven met 1 bestelregel. Het zou misschien kunnen door voor iedere status een kolom te maken, maar ik wil het eigenlijk wel zo flexiebel houden dat ik later een status kan toevoegen en dat gaat een beetje lastig op deze manier.

Als ik wel ga werken op de manier die ik aangaf moet ik dus 10 keer een query uitvoeren om 10 keer hetzelfde product in te voegen die ieder voor het aantal 1 staat.

Ik moet dus inderdaad WEL per eenheid kunnen zien wat de status is

dingstje schreef op dinsdag 29 november 2005 @ 19:39:
...
Ik zou echter wel een koppeling maken in je applicatie naar de tabel waarin je de orders bij de leveranciers bijhoudt en hun status.
...

Dit is inderdaad precies m'n bedoeling, vandaar die verschillende statussen die een product kan hebben. Het moet behalve een voorraad beheersysteem ook een bestel systeem worden.

Dat VB en MySQL niet zo'n optimale combinatie is heb ik hier een keer opgevangen. Ik nam het ook niet direct voor waar aan, maar dan weet ik nu dat het nie zo veel uit maakt

[ Voor 21% gewijzigd door Fles op 29-11-2005 22:00 ]

[sig69]

Graveheart schreef op dinsdag 29 november 2005 @ 21:53:
[...]
Als ik 1 bestelregel invoer met het aantal 10, dan kan ik niet per stuk de status aangeven. Het kan zijn als ik op deze manier werk dat er van die 10 maar 5 binnen komen en 3 in nabestelling komen en 2 vervallen. Dit is een beetje moeilijk aangeven met 1 bestelregel.

Kan je in deze situatie de bestelregel niet verwerken? 5 krijgen de status afgehandeld, 3 in nabestelling en 2 vervallen? Dit zijn dus ten hoogste 3 records in je tabel, misschien maar 2 omdat je die laatste eventueel kan verwijderen mocht je dat willen.

Het moet behalve een voorraad beheersysteem ook een bestel systeem worden.

Een voorraadbeheersysteem is in mijn ogen iets wezenlijks anders dan een bestelsysteem. Je zou dit soort systemen uiteraard wel kunnen koppelen.

[ Voor 16% gewijzigd door sig69 op 29-11-2005 22:42 ]

[Verwijderd]

Waarom niet per bestel regel opslaan hoeveel er is besteld. Dus bijv 10x Product A. In dezelfde regel geef je aan (indien de statussen vast zijn) Hoeveel er binnen zijn in nabestelling zijn en vervallen. Hierbij heb je direct de check dat aantal binnen + nabestelling + vervallen gelijk dient te zijn aan de bestel hoeveelheid.

[Gomez12]

Verwijderd schreef op dinsdag 29 november 2005 @ 23:26:
Waarom niet per bestel regel opslaan hoeveel er is besteld. Dus bijv 10x Product A. In dezelfde regel geef je aan (indien de statussen vast zijn) Hoeveel er binnen zijn in nabestelling zijn en vervallen. Hierbij heb je direct de check dat aantal binnen + nabestelling + vervallen gelijk dient te zijn aan de bestel hoeveelheid.

Het nadeel hiervan is dat je niet meerdere leveringen op 1 regel kunt hebben, dan gewoon 3 kolommen maken : besteld, geleverd, afgevoerd.
In 1e instantie heb je dan 1 regel met besteld 10 en geleverd 0 afgevoerd 0.
Dan komen er 5 binnen, regel 2 wordt dan besteld 10 geleverd 5 afgevoerd 0
Dan laat je er 2 vervallen, regel 3 wordt dan besteld 10 geleverd 0 afgevoerd 2

Op dit moment kan je op bonnr gewoon kijken hoeveel er nog openstaat door :

SQL:

select (distinct(besteld)-sum(geleverd)-sum(afgevoerd)) as nog_te_leveren
from orders
where ordernr=1

komen de laatste 3 binnen dan klopt het nog steeds.
Of je maakt er 3 tabellen van : besteld, geleverd, afgevoerd. Maar dit vind ik overdreven.alhoewel netjes genormaliseerd krijg je een onoverzichtelijke warboel. Dit is er even vanuit gaande dat er maar 1 statusverandering per x is. Desnoods zet je er nog een tekstveldje achter zodat mensen kunnen invullen waarom de statusverandering was.
Vergeet trouwens niet dat dit heel leuk is om per regel te zien, maar ik persoonlijk ben meer geinteresseerd in het aantal keer dat er over 1 order gedaan word ( want aparte verzendkosten per deellevering ) dan in het aantal keer dat er over 1 regel gedaan.Dus afhankelijk of je ook iets met verzend/ontvangst bonnen doet zou ik er ook nog iets in gaan zetten als welke deellevering het is

[Verwijderd]

dingstje schreef op dinsdag 29 november 2005 @ 19:39:
Items die nog niet effectief ontvangen zijn maken geen deel uit van de technische voorraad. Ik zou ze dan ook nog niet opnemen in die tabel.

Dat is geheel afhankelijk van hoe je "voorraad" definieert. Veel webshops hebben bijvoorbeeld nooit "voorraad" (gebruiken de distributeurs als goedkoop magazijn) Toch kun je de voorraad opvragen.
Dit is een voorbeeld van een samenwerkende supply chain.

Maar ook als je wel fysieke voorraad hebt is het soms handig om bestellingen in de voorraad weer te geven. Een inkoper kan zien hoeveel producten er zijn verkocht, wat er op voorraad ligt en wat er al onderweg is. En dus wat hij moet gaan bestellen Ook voor klanten kan dit belangrijk zijn, bestelde producten hebben een datum waarop ze (waarschijnlijk) binnenkomen. Bij nog niet bestelde producten treed een veel grotere variantie in de tijd op die het kost om het product daadwerkelijk op voorraad te krijgen.

Dan heb ik het nog niet over zaken met meerdere magazijnen, Bulk producten die in kleinere eenheden worden doorverkocht of verschillende statussen van de voorraad (vrije voorraad, gereserveerde producten, RMA producten, demo producten) Nee, voorraadbeheer kun je zo ingewikkeld maken als je zelf wilt

Maar meestal is het genoeg om te weten
Aantal van product X in magazijn afgeleverd = A (pakbon)
Aantal van product X verkocht aan klant = B (Alweer de Pakbon)

Voorraad = A-B

Maar definieer eerst de verschillende statussen die een product kan krijgen en de overgangen tussen die statussen.

Wat wij gedaan hebben was enige triggers op de tabellen zetten die de productregels voor de verschillende acties bevatten (inkoop, verkoop, reservering, levering e.d.). Deze triggers hielden dan in een aparte tabel per status bij hoeveel producten daarvan beschikbaar waren.
Dus als er 5 producten X in bestelling stonden en bij de goederen ontvangst kwamen 2 producten X binnen werd het aantal in bestelling met twee verminderd en de fysieke voorraad met 2 verhoogd. Bleek 1 van de twee producten kapot, werd de fysieke voorraad weer met 1 verminderd en de RMA voorraad 1 hogen. Enz enz.

Voordeel was dat we ten alle tijde konden zien wat de exacte hoeveelheid producten met de verschillende statussen was terwijl er maar één extra tabel voor nodig was die ook nog vrij simpel van opzet was PRODUCTID, STATUSID, AANTAL was (uit mijn hoofd) voldoende.

Nadeel is trouwens dat je bij elke verschillende statuswissel een set triggers nodig hebt om de juiste gegevens te updaten.

Maar goed dit was natuurlijk niet met MySQL..

[StevenK]

Ik heb sterk het idee dat TS begonnen is VB te kloppen zonder eerst een datamodel te bouwen ?

En wat die DB betreft: MSDE is wel gratis, MySQL niet voor commerciële toepassingen *en* de integratie met Visual Studio is toch wel wat beter, om het over de mogelijkheden nog maar niet te hebben.

[farlane]

StevenK schreef op woensdag 30 november 2005 @ 07:46:
En wat die DB betreft: MSDE is wel gratis, MySQL niet voor commerciële toepassingen *en* de integratie met Visual Studio is toch wel wat beter, om het over de mogelijkheden nog maar niet te hebben.

Als de TS in VB.Net werkt wel, VB6 is geen onderdeel van de VS IDE dus dan heb je daar niets aan.

[Fles]

Allereerst heb ik het inderdaad over VB6. Maar eigenlijk staat nog helemaal niets vast en ben ik ook nog nergens aan begonnen

Nu heb ik dus de volgende opties:
1. Producten per eenheid invoeren, voor 10 keer hetzelfde product 10 records toevoegen.
2. Per status een kolom in de producten tabel die elk voor een status staan en aantal ingevuld kan worden.
3. Met triggers werken.

Nou werkt 3 denk ik perfect met de koppeling van bestel naar voorraad. Zodra er producten binnen komen zorgt een trigger dat de voorraad verhoogd wordt en andersom. Producten worden verkocht en de voorraad gaat omlaag. Dit kun je echter combineren met optie 1 en 2.

Bij optie 2 lijkt mij alleen dat je in de praktijk tegen het probleem aan loopt dat als je twee keer een aantal van een bepaald product besteld, deze ook twee keer wordt vermeld bij binnenkomst en je dus in de gaten moet houden bij welke het "aantal binnen" wordt opgeteld, hoewel je dit natuurlijk wel kunt automatiseren... Met optie 1 kun je bijvoorbeeld twee keer een aantal van 1 product toevoegen en dan zal hij deze automatisch bij elkaar optellen en uiteindelijk weergevel als 1 positie.

In de praktijk zit het nog wel wat ingewikkelder kwa mogelijkheden die het programma moet bevatten, maar dit forum is niet om werk uit handen te laten nemen. Vandaar alleen de vraag over performance en eventuele andere mogelijkheden mogelijkheden, hoewel tips nooit weg zijn

Is er iemand die één van beide mogelijkheden direct absurt vind, of onmogelijk acht? Kwa performance slecht of afwerking van status wisseling. Mijn voorkeur gaat eigenlijk nogsteeds uit naar optie 1, omdat je die volgens mij het meest flexibel kunt gebruiken met bijvoorbeeld verschillende statussen. Maar als ik straks ook zoekopdrachten met LIKE moet gaan kunnen toepassen weet ik niet hoe snel dit programma zal blijven als er behoorlijk wat producten zijn toegevoegd.

[ Voor 14% gewijzigd door Fles op 30-11-2005 23:42 ]

[sig69]

Ik vind optie 1 "ranzig", en snap onderstaande verhaal waarom optie 2 lastig zou zijn niet:

Bij optie 2 lijkt mij alleen dat je in de praktijk tegen het probleem aan loopt dat als je twee keer een aantal van een bepaald product besteld, deze ook twee keer wordt vermeld bij binnenkomst en je dus in de gaten moet houden bij welke het "aantal binnen" wordt opgeteld, hoewel je dit natuurlijk wel kunt automatiseren... Met optie 1 kun je bijvoorbeeld twee keer een aantal van 1 product toevoegen en dan zal hij deze automatisch bij elkaar optellen en uiteindelijk weergevel als 1 positie.

[BertS]

Optie 1 zou ik uit m'n hoofd zetten. Die gaat heel veel ballast veroorzaken in je database, wat nooit zinvol is.

Wat ik zou doen:
* Standaard 1 record wegschrijven, met daarin een StatusID
* Bij wijziging van de status bij bijv. 5 van de 10 eenheden uit die record: record opslitsen in 2x5 eenheden. Worden dan ook twee regels in de bestelling, zodat je daar de status mee kunt nemen.

[Gomez12]

Graveheart schreef op woensdag 30 november 2005 @ 23:33:
...
Nou werkt 3 denk ik perfect met de koppeling van bestel naar voorraad. Zodra er producten binnen komen zorgt een trigger dat de voorraad verhoogd wordt en andersom. Producten worden verkocht en de voorraad gaat omlaag. Dit kun je echter combineren met optie 1 en 2.

Indien alleen optie 3 dan gelijk wegwerpen, als er ergens iemand 1 fout maakt dan kan je nooit meer de goede voorraad opbouwen / terughalen uit je database.

Bij optie 2 lijkt mij alleen dat je in de praktijk tegen het probleem aan loopt dat als je twee keer een aantal van een bepaald product besteld, deze ook twee keer wordt vermeld bij binnenkomst en je dus in de gaten moet houden bij welke het "aantal binnen" wordt opgeteld, hoewel je dit natuurlijk wel kunt automatiseren...

Wat is hierbij nou precies het probleem??? 2x 1 aantal besteld is 2 inkooporders dus is het alleen met je leveranciers afspreken dat ze eventjes jouw inkoopordernr op de pakbon zetten. Indien je 2 verkooporders op 1 inkooporder wilt hebben krijg je op je inkooporder maar 1 regel met opgetelde som van de aantallen van je 2 verkooporders (inkooporder!=verkooporder). Het omzetten van inkooporders naar verkooporders moet je toch in je applicatie gaan regelen en moet (in verband met vrachtkosten / orderkosten / etc ) nooit 1 op 1 zijn ( anders krijg je bij 100x een verkooporder van 2 euro en een leverancier met 5 euro orderkosten bij orders onder de 10 euro leuk 500 euro orderkosten op een inkooporder van 200 euro )

Met optie 1 kun je bijvoorbeeld twee keer een aantal van 1 product toevoegen en dan zal hij deze automatisch bij elkaar optellen en uiteindelijk weergevel als 1 positie.

En je weet nooit wanneer iets binnenkomt, levertijd etc kan jouw app niets over zeggen... Bij een serieus bedrijf zou ik dit waardeloos vinden.

In de praktijk zit het nog wel wat ingewikkelder kwa mogelijkheden die het programma moet bevatten, maar dit forum is niet om werk uit handen te laten nemen. Vandaar alleen de vraag over performance en eventuele andere mogelijkheden mogelijkheden, hoewel tips nooit weg zijn

Is er iemand die één van beide mogelijkheden direct absurt vind, of onmogelijk acht? Kwa performance slecht of afwerking van status wisseling. Mijn voorkeur gaat eigenlijk nogsteeds uit naar optie 1, omdat je die volgens mij het meest flexibel kunt gebruiken met bijvoorbeeld verschillende statussen. Maar als ik straks ook zoekopdrachten met LIKE moet gaan kunnen toepassen weet ik niet hoe snel dit programma zal blijven als er behoorlijk wat producten zijn toegevoegd.

Ik vraag me af waarom je je druk zit te maken over performance terwijl jouw performance issues gelijk je bussiness logic aantasten. Maak eerst maar eens de applicatie werkend en maak je dan maar zorgen over de performance.

BTW, een snellere processor is goedkoop als je aan het eind van het jaar niet de goede gegevens kunt opleveren.

Bouw eerst eens een datamodel zoals jij het wilt hebben ( zonder optimalisaties ) ga daarna normaliseren en daarna nog eens een keertje optimaliseren dan behoud je altijd de gegevens die je in 1e instantie wou hebben. Terwijl je nu bezig bent met je zorgen te maken over optimalisaties en het komt op mij over alsof je voor de optimalisaties bereid bent om basisgegevens op te geven.

[Fles]

Ja, zulke reacties wilde ik hebben M'n eigen verzinsel is dus waardeloos/vies.

Gomez12 schreef op donderdag 01 december 2005 @ 01:36:
Terwijl je nu bezig bent met je zorgen te maken over optimalisaties en het komt op mij over alsof je voor de optimalisaties bereid bent om basisgegevens op te geven.

Nou, ik heb nog helemaal niets op papier staan. Ik heb alleen in m'n hoofd een beetje vooruit gedacht hoe het er eventueel uit zou kunnen zien en hoe het kan werken. In princiepe offer ik geen basisgegevens op, maar als iets niet kan, dan kan het niet en zal het anders moeten. Het enige wat ik dan misschien inlever is flexibiliteit.

Wat me net nog tebinnen schiet, en hoe ik bij dat absurde idee kwam om voor elke eenheid 1 record te gebruiken. Als je een bestelling doet van 10 en er komen eerst 5 binnen en later nog een keer 5, dan hebben deze twee groepen een verschillend ordernummer. Het is niet zo moeilijk om verschillende statussen bij te houden van hoeveelheden producten, maar dit is op die manier wat eenvoudiger.

edit:
typo

[ Voor 26% gewijzigd door Fles op 01-12-2005 11:12 ]

[Verwijderd]

Gomez12 schreef op donderdag 01 december 2005 @ 01:36:
[...]

Indien alleen optie 3 dan gelijk wegwerpen, als er ergens iemand 1 fout maakt dan kan je nooit meer de goede voorraad opbouwen / terughalen uit je database.

Om twee redenen onzin.

Je hebt gewoon een voorraad tabel. Bij voorraadtellingen en diefstal kun je die tabel rechtsstreeks bewerken. Iets wat bijvoorbeeld bij optie 2 niet kan.
Bij foutieve invoer kun je de invoer corrigeren en wordt automatisch de voorraad aangepast.

Het enige waar de triggers voor zorgen is dat je niet per scherm handmatig de update hoeft uit te voeren en zo consequente voorraad afhandeling kan afdwingen. De triggers zijn dus voornamelijk een scheiding tussen de frontend en businesslogic. Het concept 1 optellen bij je voorraad als er een binnenkomt en 1 ervan aftrekken als je iets verkoopt kan je dus in theorie ook handmatig doen door bij elk scherm wat de voorraad kan wijzigen de voorraad tabel aan te passen. Maar dat is niet efficient en niet te onderhouden.

In mijn mening zijn 10 losse regels per product niet echt handig en database vervuiling. Als ik 50000 fluitjes op voorraad en ik verkoop er 10 maakt het niet uit welke 10 fluitjes dat zijn. Belangrijk is dat ik er daarna nog maar 49990 op voorraad heb. Niet welke.
Is dat laatste wel van belang en moet je op serienummer niveau werken krijgt elk product dus zijn eigen artikelnummer (= serienummer) Dat leidt ertoe dat je dus gewoon zowel bij inkoop als verkoop het serienummer opgeeft (met aantal per definitie 1) ipv het artikelnummer en je voorraadtabel dus de status van elk uniek artikel bijhoudt. Mengvormen zijn natuurlijk ook mogelijk, maar dat is meer een issue voor de front end.

Tot slot valt het mij op dat sommigen op rijniveau willen bijhouden wat de status is. Dus dat van bestelling X er 5 stuks geleverd zijn en 5 nog niet. Dat is in principe niet nodig mits je met pakbonnen werkt. Pakbonnen, zowel van de leveranciers als van jezelf, geven de goederenstromen aan. Die bepalen je voorraad. Of een klant alles geleverd heeft gekregen wat die besteld heeft zie je aan het verschil tussen de pakbon(nen) en de orderbevestiging (en meestal faktuur).
In mijn ogen loopt het systeem van op rijniveau alles bijhouden namelijk in de soep als je met credit fakturen gaat werken. (Klant besteld tien producten, krigt er 5 geleverd. Ziet dat ze niet aan zijn eisen voldoen en cancelled de overige vijf. Jij stuurt hem een creditnota voor de 5 gecancelde artikelen) Op rijniveau blijven er dan artikelen open staan. Maar zowel jij als de klant hebben aan de verplichtingen voldaan. Natuurlijk valt dit wel aan te passen door bij beide artikelregels de aantallen te corrigeren maar dat is niet echt netjes. Daarnaast heb je eigenlijk de pakbonnen sowieso nodig voor de administratie van wanneer welke deellevering gedaan is.
Op rijniveau werken voegt dus in mijn ogen niets toe behalve extra data die ook nog eens vervuild gaat worden. Ik zou het dus niet zo aanpakken.

[ Voor 63% gewijzigd door Verwijderd op 01-12-2005 14:48 ]

[Fles]

Verwijderd schreef op donderdag 01 december 2005 @ 13:15:
In mijn mening zijn 10 losse regels per product niet echt handig en database vervuiling. Als ik 50000 fluitjes op voorraad en ik verkoop er 10 maakt het niet uit welke 10 fluitjes dat zijn. Belangrijk is dat ik er daarna nog maar 49990 op voorraad heb. Niet welke.
Is dat laatste wel van belang en moet je op serienummer niveau werken krijgt elk product dus zijn eigen artikelnummer (= serienummer) Dat leidt ertoe dat je dus gewoon zowel bij inkoop als verkoop het serienummer opgeeft (met aantal per definitie 1) ipv het artikelnummer en je voorraadtabel dus de status van elk uniek artikel bijhoudt. Mengvormen zijn natuurlijk ook mogelijk, maar dat is meer een issue voor de front end.

Ik wil inderdaad alle mogelijke producten invoeren zodat je een lijst hebt met wat je kunt leveren, al dan niet uit voorraad. Hier link je vervolgens vanuit een andere tabel hoeveelheden aan die besteld moeten worden.

Maar waar ik dan nog wel mee zit, en het kan zijn dat ik er overheen lees in jou oplossing, dat als er eerst 5 producten binnen komen van de 10 en later nog een keer 5, dan hebben deze een ander pakbonnummer. Of ga je er dan vanuit dat je die 10 opsplitst in twee keer 5?

[StevenK]

Verwijderd schreef op donderdag 01 december 2005 @ 13:15:
In mijn mening zijn 10 losse regels per product niet echt handig en database vervuiling. Als ik 50000 fluitjes op voorraad en ik verkoop er 10 maakt het niet uit welke 10 fluitjes dat zijn. Belangrijk is dat ik er daarna nog maar 49990 op voorraad heb. Niet welke.

Een bedrijf zal om fiscale redenen toch op één of andere manier zijn voorraad moeten waarderen. En er zijn waarderingsstelsel waarin het antwoord op de vraag welke fluitjes jij verkocht wel degelijk van belang is.

[Verwijderd]

Graveheart schreef op donderdag 01 december 2005 @ 14:51:
[...]

Ik wil inderdaad alle mogelijke producten invoeren zodat je een lijst hebt met wat je kunt leveren, al dan niet uit voorraad. Hier link je vervolgens vanuit een andere tabel hoeveelheden aan die besteld moeten worden.

Ho ho ik had het niet over alle mogelijke soorten producten maar álle producten.

Simpel voorbeeld
Je bent een winkel en verkoopt Xboxen en PS2s. Je kan dan zeggen ik heb 10 Xboxen en 5 PS2s op voorraad. Meestal meer dan genoeg info. Maar je kan ook zeggen Ik heb 1 Xbox met serienummer 12345, 1 xbox met serienummer 12346, 1 xbox met serienummer 12347 enz (en 1 PS2 met serienummer abcd, ....) op voorraad.

Als iemand dan een xbox bij je afneemt en terugkomt kun je zien of de xbox die hij terug brengt ook daadwerkelijk de xbox is die hij gekocht heeft. De meeste bedrijven doen dit niet omdat dit nogal arbeidsintensief is. Maar in sommige bedrijfstakken wil je gewoon van elk potje weten waar het vandaan komt en waar het heen gaat. Denk bv aan apotheken. Als er bij een medicijnen fabrikant iets fout gaat, is het erg handig dat je kan volgen dat klant A pillen uit een besmette batch heeft en klant B niet. Maar dit is dus een uitzondering Bij de AH bv scanner ze gewoon op productcode.

Maar waar ik dan nog wel mee zit, en het kan zijn dat ik er overheen lees in jou oplossing, dat als er eerst 5 producten binnen komen van de 10 en later nog een keer 5, dan hebben deze een ander pakbonnummer. Of ga je er dan vanuit dat je die 10 opsplitst in twee keer 5?

Je hebt dan gewoon twee verschillende pakbonnen en één inkooporder. Dat zijn dus verschillende dingen. Die kun je aan elkaar koppelen maar dat hoeft theoretisch zelfs niet (maar is natuurlijk wel aan te raden). Je inkooporder heeft namelijk vrij weinig met je goederenstroom (voorraad) te maken en je kunt ze dus gescheiden registreren. Het is wel makkelijk voor het overzicht zodat je weet dat een bepaalde order compleet is geleverd. Maar in eerste instantie gaat het erom dat je weet wélke producten geleverd zijn. Niet zozeer bij welke inkooporder ze horen.

Wat goed werkt is dat aangezien leveranciers jou inkoopbonnummer vermelden, dat nummer bij het invoeren van de pakbon op te geven en op die manier de gegevens van de inkoopbon uit te lezen. De magazijnmedewerker hoeft dan als alles klopt enkel nog het aantal in te geven. Als je daarnaast dat inkoopnummer ook nog eens bij de pakbon opslaat kun je vanuit de inkooporder zien welke pakbonnen erbij horen. Je moet er wel rekening mee houden dat je pakbon artikelen van meer dan 1 inkoopbon kan bevatten (dus een koppeltabel!) en dat er wel eens artikelen geleverd kunnen worden die je niet besteld hebt (bv 10 Xbox 360 core ipv 10 xbox 360 premium) Maar dat laatste is weer een reden voor een scheiding tussen inkoop en pakbon. De enige manier om het zonder deze scheiding te doen is een extra inkoopregel aan te maken met een besteld aantal van 0 en een geleverd aantal van X. En dat is weer niet netjes.

Het goed weergeven van deze gegevens is echter niet triviaal. Zeker niet als je meerdere pakbonnen kan hebben die gezamelijk weer bij meerdere inkooporders horen. Maar met registratie op regelniveau werkt het al helemaal niet.

vb

Twee inkopen
inkoop 1
5x xbox 360
10x PS2

Inkoop 2
10x Xbox 360
3x PS2

4 pakbonnen
Pakbon 1
Uw ref (inkoop 1)
2 xbox 360
3 PS2

Pakbon 2
Uw ref (inkoop1, inkoop2)
3 xbox 360
4 PS2

pakbon 3
Uw ref (inkoop1, inkoop 2)
7 xbox 360
4 PS2

Pakbon 4
Uw ref (inkoop2)
3 xbox 360
2 PS2

Dit loopt uiteindelijk glad. Maar om netjes bij te houden welke producten wanneer zijn binnengekomen en bij welke inkooporder ze horen is lastig. Met op rijniveau in je inkooporder werken weet je enkel dat ze zijn binnengekomen. Niet wanneer dat was of op welke pakbon ze stonden. Bij gescheiden systemen weet je ook dát ze zijn binnengekomen, maar daarnaast weet je wanneer ze zijn binnengekomen en dat ze in gedeeltes zijn binnengekomen en (met wat moeite) dat de pakbonnen voor de inkooporders inkoop 1 en inkoop 2 gezamelijk een compleet systeem vormen. Er is dus ondanks dat je leverancier het je erg moeilijk maakt meer informatie beschikbaar.

Gelukkig krijg je van slechts weinig leveranciers dit soort pakbonnen. De meeste doen niet aan gecombineerde deelzendingen. En dat houdt het allemaal een stuk overzichtelijker.

[Verwijderd]

StevenK schreef op donderdag 01 december 2005 @ 15:57:
[...]

Een bedrijf zal om fiscale redenen toch op één of andere manier zijn voorraad moeten waarderen. En er zijn waarderingsstelsel waarin het antwoord op de vraag welke fluitjes jij verkocht wel degelijk van belang is.

In praktijk gaat men er bij gelijksoortige producten (fluitjes) in een Fifo systeem vaak gewoon vanuit dat als er iets verkocht wordt dat dan wel het oudste zou zijn geweest. Ook kun je natuurlijk door je magazijn indeling en werkwijze een Fifo of Lifo systeem afdwingen. Bij voorraad waarderingen om fiscale zaken spelen er daarnaast nog een hele hoop andere zaken mee als hoe oud een product is. Fiscale voorraadwaardering wijkt daardoor ook vaak sterk af van de commerciele waardering van dezelfde voorraad. (ik ken bedrijven die voor veel geld voorraad in de boeken hebben staan maar als ze failiet gaan is de voorraad veel minder waard. Het omgekeerde komt trouwens ook voor)

Maar natuurlijk, bij producten die snel verouderen (melk bijvoorbeeld) is het wel van belang dat het oudste het eerst verkocht wordt. Ik gaf ook al aan dat er ook situaties zijn waar meer informatie gewenst kan zijn. Maar laten we het niet nodeloos nog ingewikkelder maken. Ik heb het gevoel dat de TS het al moeilijk genoeg heeft.

[StevenK]

Verwijderd schreef op donderdag 01 december 2005 @ 16:39:
Maar natuurlijk, bij producten die snel verouderen (melk bijvoorbeeld) is het wel van belang dat het oudste het eerst verkocht wordt. Ik gaf ook al aan dat er ook situaties zijn waar meer informatie gewenst kan zijn. Maar laten we het niet nodeloos nog ingewikkelder maken. Ik heb het gevoel dat de TS het al moeilijk genoeg heeft.

Aan de andere kant zou het voor TS heel bruut zijn wanneer zijn systeem zometeen niet bruikbaar blijkt omdat het niet mogelijk is een voorraadwaardering toe te passen.

[Verwijderd]

StevenK schreef op donderdag 01 december 2005 @ 16:45:
[...]

Aan de andere kant zou het voor TS heel bruut zijn wanneer zijn systeem zometeen niet bruikbaar blijkt omdat het niet mogelijk is een voorraadwaardering toe te passen.

Tuurlijk is dit model niet heilig Het is echter in mijn ogen wel een stuk robuster dan de andere twee oplossingen. Maar vergeet niet dat voorraad waarderen toch grotendeels een handmatig process is (je moet je voorraad tellen) en alle informatie over de in en uitgaande goederenstromen in dit systeem gewoon behouden blijft (in tegenstelling tot bij optie 2) Hiermee zou je in mijn ogen elke waarderingsgrondslag voor de voorraad moeten kunnen toepassen. Maar misschien zie jij knelpunten voor bepaalde waarderingssystemen en weet je een beter systeem.

Ik houd mij aanbevolen.