25. december 2003 - 23:04Der er
17 kommentarer og 2 løsninger
db med opgørelse over kunder og lager
Jeg forsøger mig med en dB hvor der gerne skulle kunne opereres med tabeller således at jeg hele tiden har styr på hver enkelt kundes enkelte ordre og samlede varekøb og samtidig have styr på lageret både med tilførsel og "afgang"(når kundens ordre bliver registreret). Jeg skal vel bruge en kundetabel med kundeid,.. en varetabel med vareid, varenavn, pris pr. enhed....osv Jeg ønsker forslag til udarbejdelse af dB, men altså det er meget VIGTIGT både at have styr på kundens varekøb og også lagerregnskabet
Der bliver investeret massivt i AI. Teknologien er mere tilgængelig end nogensinde, og ambitionerne er høje. Alligevel oplever mange virksomheder, at resultaterne udebliver.
Jeg har en lille testdb hvoraf du muligvis kan få lidt inspiration. Den omhandler udelukkende lagerregnskab og har således ikke kundedelen med, men det er ikke noget problem at tilføje dette. Blot læg din e-mail.
Meget afhænger at størrelsesordenen af kunder og varer, men sandsynligvis kan du i formularen, som kombinerer de to, nøjes men 2 kombibokse. En til kunder og en til varer + nogle felter til varer.
Modtaget en meget god testdB. Men det store spørgsmål er egentlig hvordan jeg får de to dele kunder + vare til at hænge sammen. Jeg har max. 50 kunder og max 70 varer. Det primære for mig er at der hele tiden er styr på kunden og at der så også bagvedliggende er styr på lageret.
Nu er vi vist kommet dertil, at vi må vide, hvad du vil bruge det til. Skal der f.eks. udskrives faktura og/eller følgeseddel?
Men til at begynde med kan du lave en formular baseret på varalageret og med 2 kombibokse, som vi kan kalde [KUNDELISTE] og [VARELISTE], så vi ved, hvad vi snakker om.
Lageret skulle der gerne være styr på med testdb'en.
Som fynbohans skriver, skal du oprette en tabel til dine kunder. I tabellen "Køb" laver du herefter en combo, der plukker en kunde fra kundetabellen.
Hvis der skal oprettes en historik med alle køb fra kunderne, skal du desuden tænke på, at prisændringer vil slå igennem på alle køb. Det er derfor nødvendigt at lave en speciel tabel, hvori du gemmer alle gennemførte køb.
Jeg tror jeg er ved at være derhenne hvor jeg gerne vil hen,- men hvordan skal jeg egentlig (som du nævner mugs) forholde mig ved prisændringer, når jeg skal oprette en speciel tabel?
Jeg forestiller mig, at du kan afgive et tilbud på en handel. Dette tilbud kan udmøntes i en handel, som du er nødt til at sende over i en speciel tabel, der ikke har relationer til andre tabeller. Derved vil alle data om handler blive lagret uden de berøres af prisændringer.
Tabellen kan være en kopi af min tabel "Køb" i testdb'en. Når du afgiver et tilbud oprettes dette i tabellen "Køb", og når handlen effektueres kan du sende data over til den nye tabel med en tilføjelsesforespørgsel eller en SQL-sætning.
Som mugs skriver bør du også have en salgstabel. Da du sikkert gerne vil gemme gamle priser bør du også have et ekstra felt i tabellen med varer, som viser hvilken pris er den aktuelle - et Ja/Nej-felt.
Jeg forsøger at arbejde videre med jeres store hjælp. Jeg håber at det vil lykkes for mig selvom jeg prøver mig noget frem (er virkelig noget af en amatør, men ved stædighed og brug af meget tid lykkes det som regel at få noget brugbart frem). Jeg mener at det vil være fair at fordele points som gjort.
Points er fordelt og tak for det. Du vender bare tilbage hvis du får problemer.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
