[database of excel] Keuze administratie magazijn

[M-ThijZ]

Beste Tweakers.
Ik werk bij een elektronica bedrijf (assemblage). Het bedrijf is in de loop van de jaren steeds groter geworden en niemand weet eigenlijk meer wat er nu precies in het magazijn ligt. De waarde van alle onderdelen bij elkaar is best hoog en het is belangrijk dat er eens door deze vooraad heen gewerkt wordt. Nu zijn we al druk bezig met het opmaken van de balansen en moet er eens nagedacht worden over wat we nu precies met deze informatie gaan doen.
Zoals ik al zei gaat het om een bedrijf waar elektronica geassembleerd wordt, in het magazijn bevinden zich dan ook veel verschillende soorten componenten. Elk component heeft zijn eigen eigenschappen die opgeslagen moeten worden. Wat voorbeelden:

• weerstand: [waarde (ohm)] [waarde (afwijking %)] [aantal] [prijs]
• condensator: [waarde (voltage)] [waarde (capaciteid)] [aantal] [prijs]
• transistor: [waarde (max. belasting)] [waarde (pnp/npn)] [aantal] [prijs]
• relais: [waarde (schakelspanning)] [waarde (max. belasting] [aantal] [prijs]

Er zijn allerlei componenten aanwezig: IC-voeten, IC's, trafo's, boxheaders, zekeringen, dipswitches, headerstroken, potmeters. Van elke component zijn er tientallen (soms zelfs meer) verschillende uitvoeringen (kenmerkend aan de waardes).

Het is belangrijk dat er gesorteerd en gezocht kan worden naar wat er beschikbaar is.

Na een gesprek met mijn baas kwamen we op twee oplossingen:

1) Mijn baas had in gedachten om alle informatie in een excel sheet te zetten. Een kennis is erg handig met excel en kan voor het bedrijf een excel sheet maken waar een lijst van de te vinden componenten in zou staan, plus intregratie met paklijsten e.d. (hier sta ik zelf nogal sceptisch tegenover).

2) Ikzelf kwam met de oplossing om het geheel in een database te zetten, het probleem is dat ik zelf weinig ervaring heb met het opzetten van een professionele database binnen een bedrijfsomgeving, maar ik ben wel bereid er tijd in te steken om het een en ander onder de knie te krijgen (aan uitbesteding wordt nog even niet gedacht, het zou een mooie uitdaging voor me zijn en voor de ervaring zou ik het graag doen).


Volgens mij is het gewoon logisch om deze informatie in een database te zetten, daarom was het mij idee ook om het in een mysql database te zetten en een php frontend te gebruiken. Hier heb ik erg weinig ervaring in:
Zou iemand me kunnen adviseren bij de tabel / database structuur? Het probleem zit hem namelijk in de verschillende componenten die hun eigen eigenschappen hebben. Sommige componenten hebben 1 waarde, andere hebben er twee of drie.

Is het slim om het in mysql op te zetten en waar moet ik dan op letten?

[BtM909]

Ik zou zeker weten voor een database gaan, maar om welke hoeveelheid gaat het eigenlijk. Ook al gedacht aan bijvoorbeeld Access?

[RobIII]

Ook ik zou voor een database gaan. En als je die netjes normaliseert moet het opzetten van de tabellen niet al te moeilijk zijn. Mocht je er niet uitkomen (probeer het eerst zelf eens) dan zijn er genoeg mensen hier (waaronder ikzelf) die je een eindje op weg willen helpen of zelfs een simpel opzetje willen/kunnen maken voor je.

[Verwijderd]

Voordeel van Excel is dat je gegevens en front-end (paklijst genereren, etc.) in 1 systeem kunt bouwen, en als die kennis echt handig is, zou 'ie er ook nog wel iets bruikbaars van kunnen maken.

Maar met een database oplossing ben je een stuk flexibeler, vooral wanneer 't ook nog multi-user moet zijn (Excel kent dat woord niet).
MySQL en PHP kan prima, maar om zoiets snel op te zetten is waarschijnlijk Access een stuk handiger. Een PHP frontend klik je niet zo bij elkaar, Access is dan net even wat toegankelijker. Wanneer 't naar tevredenheid werkt kun je daarna altijd nog de database overzetten naar bv. MSSQL, en er een PHP/ASP.NET web frontend bij maken.

Wat betreft de database structuur: dat is het belangrijkste deel, en dan maakt 't niet uit of je het in Excel, MySQL, of een tekst editor doet. Je moet bepalen wat de eigenschappen van alle items zijn, en proberen die zo logisch mogelijk in te delen.
Een onderverdeling in hoofdcategorie -> subcategorie -> item ligt voor de hand, maar er zijn ook andere mogelijkheden.
Wat wel belangrijk is: elk item (of 't nou een weerstandje is of een volledige eindversterker) moet direct op te vragen zijn. De meeste zaken (Display bijvoorbeeld) gebruiken daarom unieke bestelcodes voor ieder item dat ze verkopen.

[M-ThijZ]

Daar heb je een goed punt Afterlife, een opzet in MS Access is iets makkelijker te realiseren en het heeft meteen al een 'soort-van' front-end om wat in te zoeken.

... maar om zoiets snel op te zetten is waarschijnlijk Access een stuk handiger ...

Het hoeft op zich niet snel, ik ben er liever drie maand mee bezig met een (semi) professioneel resultaat dan dat het snel in access wordt gezet. Tevens zou ik graag een open standaard als mysql gebruiken.
Kwa opzetten van een access en mysql database zit er volgens mij weinig verschil in tijd/moeite. Alleen kun je er in access meteen iets mee en moet er voor mysql eerst een php frontend geschreven worden waar erg veel tijd in gaat zitten.

... maar om welke hoeveelheid gaat het eigenlijk ...

Ik reken op minstens 25 hoofd-componenten (weerstanden, condensatoren, potmeters etc.) Waarbij ze elk component ontzettend veel verschillend waarden heeft. (weerstandjes bijv. van 1E to 300K en dan heb je ook nog verschillende afwijkingen) kortom heel erg veel componenten.

[TeasingU]

Ik adviseer je een bewuste keuze te maken wat betreft het systeem dat je gaat gebruiken. Het gaat er niet om dat je een professioneel pakket kiest, het gaat erom dat je dadelijk een systeem hebt waarmee jij 100% uit de voeten kunt. Dat een pakket dan open source of een open standaard is doet er dus niet toe.

Enkele vragen waar je rekening mee moet houden:
- Hoe groot wordt de database (qua rijen)
- Hoeveel werknemers zullen er tegelijkertijd met de applicatie werken
- Over welke software beschik je
- Over welke kennis beschik je (heb je al aangegeven)

In jouw situatie zou ik persoonlijk voor Access kiezen. Je kan er vrij snel een goedwerkende database van maken. Ook kun je er vrij exacte invoercontroles aan toevoegen wat er weer voor
zorgt dat je informatie consistent is. (kan ook met PHP)
Echter als je met meerdere werknemers tegelijkertijd met de applicatie werkt, dan wordt het
al een ander verhaal, dan kom je toch al gauw de beperkingen van Access tegen.
Een voordeel (vind ik zelf) van Access is wel dat je makkelijk je database kan backuppen. Het is gewoon een *.mdb dat je op een cd kunt branden.

Wanneer je kiest voor een webapplicatie met PHP en MySQL zul je toch wat meer kennis in huis moeten halen. Naast het programmeren moet je ook nog een fatsoenlijke interface bouwen. Om het geheel draaiende te houden is het ook van belang dat je jouw webserver(intern) in orde hebt. Heb je het eenmaal in orde dat heb je wel een leuk systeem gebouwd.

Laat je overigens niet beinvloeden door leden die beweren dat Access je data corrupt zou maken en dat soort dingen. Daar is echt niets van waar. In 9 van de 10 gevallen heeft de programmeur zitten prutsen maar dat soort dingen worden natuurlijk nooit bekend gemaakt.

Nu bedenk ik me net. Je kan ook met Access project en MySQL werken. Dan heb je een Access frontend en een MySQL backend.

Tja mogelijkheden genoeg natuurlijk...

[Verwijderd]

Kwa opzetten van een access en mysql database zit er volgens mij weinig verschil in tijd/moeite.

Klopt helemaal. Maar in Access is het wel een stuk simpeler om te knutselen met je datamodel, en naar ik begrijp heb je die nog niet helemaal op een rijtje. Heb je al een opzetje gemaakt van hoe de tabelstructuur en de links tussen de tabellen eruit moeten zien?

Je meldt wel...

Sommige componenten hebben 1 waarde, andere hebben er twee of drie.

...maar zit daar een lijn in? Oftewel, is dat te normaliseren?

Bovendien zei je weinig ervaring met MySQL en PHP te hebben (ik ook niet trouwens, ik zou direct naar Delphi/InterBase of C#/MSSQL grijpen), dus Access leek me een goede opstap.

[M-ThijZ]

Verwijderd schreef op maandag 03 januari 2005 @ 19:41:
Heb je al een opzetje gemaakt van hoe de tabelstructuur en de links tussen de tabellen eruit moeten zien?

Neen, gister ben ik daar wat mee bezig geweest en iemand in #mysql adviseerde twee tabellen:
basic-data, hierin staat de data die voor elk component van toepassing is (zoals aantallen) plus een unieke index.
properties-table, hierin staat dezelfde index gelinkt aan de waardes die van toepassing zijn

BASIC-DATA
[index] [type] [aantal] [prijs]

PROPERTIES
[index] [waarde]

Ik ben alleen bang dat ik problemen krijg bij componenten met meerdere waarden, ik zal eens wat invullen:

BASIC-DATA
[1] [weerstand] [350] [3,05]
[2] [condensator] [425] [3,60]
[3] [kristal] [20] [6,60]

PROPERTIES
[1] [100]
[2] [16]
[2] [18]
[3] [4]

Wat ik dus ingevoerd heb is:
350x weerstand 100(ohm) €3,05
425x condensator 16(Volt)/18(uF) €3,60
20x kristal 4(MHz) €6,60

Ik merk dus wel dat ik vooral op moet letten op _wat_ nu precies wat voorstelt, (de 1e waarde is het voltage, de 2e is de capaciteit). Het is belangrijk dat ik dit dus niet door elkaar ga halen.

Als iemand een betere structuur weet hou ik me zee aanbevolen.

[Verwijderd]

M-ThijZ schreef op maandag 03 januari 2005 @ 20:13:
[...]
BASIC-DATA
[index] [type] [aantal] [prijs]

PROPERTIES
[index] [waarde]

[...]
Als iemand een betere structuur weet hou ik me zee aanbevolen.

Wat dacht je van het volgende, dit lost je probleem van meerder waardes op.

PARTS (the inventory)
[index] [type] [ammount] [price] [supplier.index] [supplier_order_code]

PARTS_PROP_VALUE (parts propperty-value pairs)
[parts.index] [part_property.value] [value] [unit]

PART_TYPE (type of part)
[value]

PART_PROPERTY (all propperties of a given part_type)
[part_type.value] [value] [default_unit]

UNITS (units for the values and the factor (K=1000 and m=.0001) usefull for sorts)
[unit] [factor]

SUPPLIER (supplier (of parts))
[index] [n.a.w.] [etc. etc.]

DATA
====
350x weerstand 100(ohm) €3,05
425x condensator 16(Volt)/18(uF) €3,60
20x kristal 4(MHz) €6,60

DATA in tabels
================

PARTS
[1] [weerstand] [350] [3,05] [1] [5432.100]
[2] [condensator] [425] [3,60] [2] [c87.6543]
[3] [kristal] [20] [6,60] [3] [x4m]

PARTS_PROP_VALUE
[1] [Weerstand] [100] [Ohm]
[2] [Capaciteit] [18] [uF]
[2] [Spanning] [16] [V]
[3] [Frequentie] [4] [MHz]

PART_TYPE
[weerstand]
[condensator]
[kristal]

PART_PROPERTY
[weerstand] [Weerstand] [Ohm]
[condensator] [Capaciteit] [uF]
[condensator] [Spanning] [V]
[kristal] [Frequentie] [Mhz]

SUPPLIER
[1] [DisPlee] [etc. etc.]
[2] [BetaalMeijer] [etc. etc.]
[3] [(C)onraad] [etc. etc.]

UNITS
[Ohm] [1]
[uF] [.0000001]
[V] [1]
[Mhz] [1000000]

[ Voor 32% gewijzigd door Verwijderd op 03-01-2005 21:50 . Reden: data voorbeeld toegevoegd ]

[M-ThijZ]

TeasingU schreef op maandag 03 januari 2005 @ 19:41:
Wanneer je kiest voor een webapplicatie met PHP en MySQL zul je toch wat meer kennis in huis moeten halen. Naast het programmeren moet je ook nog een fatsoenlijke interface bouwen. Om het geheel draaiende te houden is het ook van belang dat je jouw webserver(intern) in orde hebt. Heb je het eenmaal in orde dat heb je wel een leuk systeem gebouwd.

Het in huis halen van kennis is geen probleem, ik zou er graag ervaring mee op doen, maar het is wel een flink karwei, maar de mogelijkheden zijn vrijwel onbeperkt en het is mogelijk een heel net systeem op te zetten.

Nu bedenk ik me net. Je kan ook met Access project en MySQL werken. Dan heb je een Access frontend en een MySQL backend.

Dus ik kan access als (tijdelijke) frontend gebruiken om de data in de mysql server te verwerken? Daarna kunnen werknemers meteen via access in de database werken en dat geeft mij de tijd om eventueel een mooie webapplicatie in elkaar te zetten, of begrijp ik nu iets verkeerd en zitten hier veel haken en ogen aan?

[Pogostokje]

M-ThijZ schreef op maandag 03 januari 2005 @ 21:06:
Dus ik kan access als (tijdelijke) frontend gebruiken om de data in de mysql server te verwerken? Daarna kunnen werknemers meteen via access in de database werken en dat geeft mij de tijd om eventueel een mooie webapplicatie in elkaar te zetten, of begrijp ik nu iets verkeerd en zitten hier veel haken en ogen aan?

Dat klopt helemaal. Maar het bouwen van een mooi frontend in Access kost je ook tijd natuurlijk. Die tijd is 'verloren' als je ook nog PHP wilt dev'en.

Maar waarom niet blijven bij Access?
Vergeet niet dat Access ontzettend uitgebreid is (veel uitgebreider dan de meeste mensen denken) en er een complete Visual Basic development omgeving in zit. Je frontend kun je dus volledig en uiterst professioneel opzetten met een versie van VB die naadloos met je database samenwerkt. Het onderhoud is simpel, backup is zo gemaakt en als je maximaal 255 gelijktijdige verbindingen verwacht kan Access dat gewoon verwerken. Zo heel ingewikkeld wordt je database nou ook weer niet en je moet het jezelf ook niet onmogelijk maken.

[ Voor 4% gewijzigd door Pogostokje op 03-01-2005 21:16 ]

[onkl]

Ik zou ook voor Access kiezen, zowel front als backend.
Excel klinkt "te klein", zoals deels hierboven al aangestipt:
-niet multiuser
-slecht opschaalbaar (een tabelletje/view toevoegen, het kan wel maar leuk is't niet)
-slecht converteerbaar als je ooit naar iets anders gaat.

Access is redelijk goed converteerbaar.
Je kan dus kiezen voor
Nu: Frontend: Excel (Liever niet) of Access, Backend Access
Later: F: Access, B: MySQL
Uiteindelijk: F: Iets intranetterigs, B: MySQL.

Als er nu nog niet zoveel kennis in huis is, zou ik MySQL/Access combi's nog even vermijden. Als Excel een optie is/was kan Access het makkelijk aan, als je 't later anders wil kan dat, dus je maakt het je alleen maar moeilijk lijkt me.
edit @ pogostokje:
Sterk punt, let er ook op dat je, als je access kiest als frontend er direct een bak extra licenciekosten ontstaan, kan je motiveren om direct webbased te gaan. (Maar daar weet ik niets vanaf, dus dan kan vast iemand anders je helpen )

[ Voor 17% gewijzigd door onkl op 03-01-2005 21:27 ]

[Pogostokje]

onkl schreef op maandag 03 januari 2005 @ 21:25:
Sterk punt, let er ook op dat je, als je access kiest als frontend er direct een bak extra licenciekosten ontstaan, kan je motiveren om direct webbased te gaan. (Maar daar weet ik niets vanaf, dus dan kan vast iemand anders je helpen )

Licentie kosten? Volgens mij is een Access licentie (bijvoorbeeld bij het office prof. pakket) op de PC's waar je het op wil gebruiken voldoende. Er komen geen extra front-end kosten bij ofzo. Dat zit er gewoon in. Deze kosten kunnen dus best meevallen, zeker omdat op veel PC's waar administratief werk verricht wordt al iets van office staat.

[jwpmzijl]

Database óf excel. => database !!!

Bedenk dat wil dit project kans van slagen hebben er ook iemand moet zijn die tijd heeft om alle voorraad mutaties in te vullen. Daar moeten procedures voor opgesteld worden die ook uit te voeren zijn. Dit aspect wordt vaak onderbelicht en is er de oorzaak van dat dergelijke projecten regelmatig mislukken.

Onderzoek dit voordat je manuren in een bodemloze put gooit.

Licentiekosten:
Als je Access gaat gebruiken dan moet voor elke werkplek waarop de applicatie gedraaid wordt een Access-licentie aanwezig zijn. Heb je Office pro legaal op iedere werkplek dan is dat dus geen probleem. Als je het werk uitbesteed dan beschikken de meeste Access programmeurs over een developer licentie waardoor zij de applicatie met een Access Run-time mogen verspreiden. In dat geval zijn er geen licentie kosten voor Access.

[ Voor 36% gewijzigd door jwpmzijl op 03-01-2005 22:28 ]

[M-ThijZ]

onkl schreef op maandag 03 januari 2005 @ 21:25:
Nu: Frontend: Excel (Liever niet) of Access, Backend Access
Later: F: Access, B: MySQL
Uiteindelijk: F: Iets intranetterigs, B: MySQL

Kijk dat klinkt goed in mijn oren!
Ik zal eens de tabelstructuur van whyshell in access proberen te zetten en eens wat test data erin zetten.
Misschien dat ik meteen naar de stap "Later" toe ga, Access met MySQL als backend opzetten. Dat lijkt me opzich niet zoveel moeilijker (ik zal zo even wat onderzoek doen) en het bespaard de convertie access --> mysql, waarbij misschien toch wat mis kan gaan (of niet zoals ik het wil/begrijp).
Uiteindelijk inderdaad een intranet, wie weet wat er in de toekomst gebeurt, misschien gaan er pc's over op linux, of zijn er geen access licenties. Een intranet is erg flexibel, multiplatform en werknemers kunnen ook over het internet gemakkelijk zonder extra applicaties, (vpn verbinding) toegang krijgen.

[Verwijderd]

Ik weet niet of je al aan de presentatie gedacht hebt, maar de gegevens moeten later natuurlijk vast ook mooi uitgedraaid worden in tabelletjes en met statistieken en de hele reutemeteut.

Als je dan Access gebruikt heb je al een duidelijk voordeel omdat je met een paar klikken die gegevens over kunt hevelen naar Word of Excel. Daarmee kunnen de meeste `eindgebruikers' ook wel uit de voeten, zeker als je ze een beetje uitlegt hoe alles werkt in het begin, en misschien een stap-voor-stap handleiding beschikbaar maakt. Daarna kan iedereen naar hartelust rapportjes gaan uitdraaien.

Als je vastzit aan een PHP/MySQL pagina dan zul je ten eerste alle rapporten moeten hardcoden (dat is heel vervelend werk, althans, vind ik toch), en de kans is groot dat je daarna regelmatig lastig gevallen gaat worden door collega's omdat jij de enige bent die iets aan de site kan aanpassen.

Mijn advies: pak Access en blijf erbij, tot je tegen echt grote schaalbaarheidsproblemen aanloopt (maar ik denk niet dat die er zullen komen).

[M-ThijZ]

Verwijderd schreef op maandag 03 januari 2005 @ 21:00:
[...]

Wat dacht je van het volgende, dit lost je probleem van meerder waardes op.

PARTS (the inventory)
[index] [type] [ammount] [price] [supplier.index] [supplier_order_code]

PARTS_PROP_VALUE (parts propperty-value pairs)
[parts.index] [part_property.value] [value] [unit]

PART_TYPE (type of part)
[value]

PART_PROPERTY (all propperties of a given part_type)
[part_type.value] [value] [default_unit]

UNITS (units for the values and the factor (K=1000 and m=.0001) usefull for sorts)
[unit] [factor]

SUPPLIER (supplier (of parts))
[index] [n.a.w.] [etc. etc.]

DATA
====
350x weerstand 100(ohm) €3,05
425x condensator 16(Volt)/18(uF) €3,60
20x kristal 4(MHz) €6,60

DATA in tabels
================

PARTS
[1] [weerstand] [350] [3,05] [1] [5432.100]
[2] [condensator] [425] [3,60] [2] [c87.6543]
[3] [kristal] [20] [6,60] [3] [x4m]

PARTS_PROP_VALUE
[1] [Weerstand] [100] [Ohm]
[2] [Capaciteit] [18] [uF]
[2] [Spanning] [16] [V]
[3] [Frequentie] [4] [MHz]

PART_TYPE
[weerstand]
[condensator]
[kristal]

PART_PROPERTY
[weerstand] [Weerstand] [Ohm]
[condensator] [Capaciteit] [uF]
[condensator] [Spanning] [V]
[kristal] [Frequentie] [Mhz]

SUPPLIER
[1] [DisPlee] [etc. etc.]
[2] [BetaalMeijer] [etc. etc.]
[3] [(C)onraad] [etc. etc.]

UNITS
[Ohm] [1]
[uF] [.0000001]
[V] [1]
[Mhz] [1000000]

Zou je me nog een paar dingen willen verduidelijken?
Wat zijn de onderlinge relaties tussen de verschillende tabellen? Ik ben nu een opzet aan het maken in access maar ik begrijp niet goed wat ik met UNITS en PART_TYPE aanmoet.
Zou je me kunnen vertellen wat ik zou moeten "verbinden"? En welke tabellen een primary (Id) key nodig hebben?

Ik ben het nu dus aan op opzetten in access, maar nog een vraagje (misschien een beetje te RTFM), maar hoe zet ik dit nu centraal op? Als ik nu een database heb wordt dat een *.mdb file, hoe zorg ik er nu voor dat het multiuser gebruikt kan worden?

[Tom-my]

wat ik hier nog niet zie is eigenlijk is het volgende;

- Hoeveel data komt er(grove schatting kwa records)
- Hoeveel users gaan het tegelijkertijd gebruiken
{Als je een grote database begint te krijgen of verwacht te krijgen is access niet eens interessant voor je, bij veel records wordt dat al erg traag.}
- Verder de beschikbaarheid en de betrouwbaarheid van je gegevens. { Een systeem van mssql /.mysql zorgt imo echt voor een flinke teug betrouwbaarheid tov access. }

Geen onbelangerijke items denk ik zo zelf.

[Verwijderd]

M-ThijZ schreef op dinsdag 04 januari 2005 @ 11:13:
[...]
Zou je me nog een paar dingen willen verduidelijken?
Wat zijn de onderlinge relaties tussen de verschillende tabellen? Ik ben nu een opzet aan het maken in access maar ik begrijp niet goed wat ik met UNITS en PART_TYPE aanmoet.
Zou je me kunnen vertellen wat ik zou moeten "verbinden"? En welke tabellen een primary (Id) key nodig hebben?

Ik ben het nu dus aan op opzetten in access, maar nog een vraagje (misschien een beetje te RTFM), maar hoe zet ik dit nu centraal op? Als ik nu een database heb wordt dat een *.mdb file, hoe zorg ik er nu voor dat het multiuser gebruikt kan worden?

Tuurlijk!
het eerste veld in alle tabellen is de Primary Key, met uitzondering van de tabellen waarbij dit een gerefereerde sleutel is, dan wordt de PK een samengestelde sleutel van de eerste 2 velden, dit geldt ook voor de tabellen met maar een veld.
de Foreign Keys hebben in de refererende tabellen de gerefereerde tabel als voorloop bijvoorbeeld [part_type.value].
De tabllen met meer een veld zijn voornamelijk bedoeld om consistentie af te dwingen, dit kan je doen in de DB door ze te koppellen, maar kan je ook in de invoer interface afdwingen.

Ik zou bij access persoonlijk voor een web interface kiezen omdat ik dat makkelijker vind, maar dat heeft meer met mijn gebrekkige kennis van de access als front end.

[ Voor 2% gewijzigd door Verwijderd op 04-01-2005 22:51 . Reden: woops wordo ]

[DaRealRenzel]

Ik wil niet veel zeggen, maar zijn de kosten die je gaat investeren (jouw tijd zelf ook meerekenen) niet veel te hoog om elk individueel weerstandje te registreren ? Veel grote organisaties gaan ook shroeven en zo niet per stuk invoeren, maar alleen per doos van 100. Ik ken zelfs een bedrijf dat gewoon voor bijv. 100 machines 5250 schroeven inkoopt (50 schroeven per machine, 5% verlies) en dus helemaal geen schroeven meer inventariseerd.... Sterker nog, de schroevenvoorraad wordt bijgehouden door de leverancier, en die factureerd gewoon 52,5 schroeven per geproduceerde machine.

Je moet niet proberen alles te automatiseren. Ik denk namelijk dat het niet rendabel zal zijn de verkoop van 2 weerstandjes á 10 eurocent ( 2 cent winst) in de computer te stoppen. Als je daar 1 minuut over doet en jouw uurkosten zijn 20 euro (= erg laag) dan gaat er 0,3 eurocent van de winst af. Op 2 eurocent is dat 15% van de winst die in administratiekosten gaat zitten. En da's heel veel.

[ Voor 9% gewijzigd door DaRealRenzel op 04-01-2005 23:02 ]

[M-ThijZ]

- data: van 25 hoofdgroepen uitgaande.. gemiddeld 50 soorten, dat zou dus neerkomen op 1250 records.
- users: weinig, hooguit drie/vier.
- betrouwbaarheid, beschikbaarheid. Wat wordt hiermee bedoelt?

Ik heb even wat gespeeld in access maar ik ben er niet meteen van ondersteboven. Het is vrij simpel om een database op te zetten maar de algemene feeling van het programma vindt ik toch niet zo fijn, ik krijg het gevoel dat ik met 1 verkeerde muisklik het hele systeem om zeep help, maar dat zal misschien wel komen doordat ik het nog niet goed ken.
Het is niet dat de database dus erg groot zal worden en door veel mensen tegelijkertijd gebruikt zal worden, maar het is wel belangrijk dat het systeem goed opgezet wordt aangezien het een flink aantal jaren mee moet. (niet zozeer de frontend maar de informatie zelf, al die data voor een tweede keer invoeren lijkt me geen pretje).