Das deutsche QBasic- und FreeBASIC-Forum

[mlb]

ganz kurz mein problem:

ist laden.. bzw. anzeigen.. bei der demo gibt man die nummer ein und diese wird dann auch angezeigt.. wie funktioniert das?
in eienr DB ganz klar aber er hats uach nicht in eienr DB gemacht..

und beim löschen .. das ich genau diesen artikel wieder lösche bzw. ändere.. das heißt ich muss in die entsprechende zeile usw.

mit einer DB wäre alles superleicht aber wie es scheint hat er keien gemacht, also darf ich leider auch keien machen.. da es 1:1 aussehen soll...

was kann ich hier tun?

Hallo!

Kurze Vorgeschichte:
Ich habe eine Wette verlohren und muss nun ein Artikelverwaltungsprogramm in QBasic schreiben, da ich mich aber leider nicht wirklich in QBasic auskenne habe ich mir zuerst von hier ein Musikverwaltugnsprogramm geloaded.. aber dieses Coding finde ich etwas zu aufwändig, bzw. würde es ja in vba einfacher gehen..

es geht einfach um folgendes:
Ein Artikelverwaltungsprogramm schreiben,
wo mann Erfassen, anzeigen,löschen,ändern etc.
die exe, so wie es aussehen sollte habe ich bereits zur verfügung nur der weg dort hin ist etwas kompliziert,

ich hoffe, ihr könnt mir hierbei weiterhelfen



Mfg

MLB

________________________Bisher,
so wie es aussehen sollte, schicke ich gerne per E-Mail zu..

[Michael Frey]

Du hast jetzt nicht Ernsthaft das Gefühl, jemannd schreibt dir das Programm?

Mal ein Tipp:

[dreael]

Schlussendlich zählt für so eine Anwendung immer die Spezifikation, was es können muss. Also bevor man sich auf Details stürzt, ob der hervorgehobene Buchstabe auf der Bildschirmmaske weiss oder pink erscheinen soll, sollte man so ein Projekt erst einmal ganz grundlegend betrachten.

Ich gebe hier nur ein Beispiel für so ein Konzept:
Man sei ein Freiberufler und verkaufe meinetwegen Musikinstrumente und Zubehör im Versandhandel, wobei man hier verschiedene Hersteller (z.B. Akkordeons von Hohner, Blockflöten von Moeck usw.) vertritt und ausserdem in einem Gewerbezentrum ein Büro mit Lagerraum gemietet hat, damit man insbesondere Kleinartikel sofort liefern kann.

Unsere EDV-Anwendung muss vielleicht folgende Dinge verwalten können:
- Kundenstamm
- Lieferantenstamm
- Artikelstamm
- Rechnungswesen Kreditoren und Debitoren

Aufbau Kundenstamm: Genaue Anschrift mit Typ (Privat oder gewerblich), Firmenname und zuständige Person, Adresse/PLZ Ort/Land, Telefon, Fax, E-Mail und evtl. Homepage, dazu noch ein Feld Kundenklasse (Unterscheidung, ob wichtiger Hauptkunde oder nur Einmalig-Besteller), Bonität (Schufa-Auskunft sowie Erfahrung aus der Vergangenheit, ob er seine Rechnung immer pünktlich zahlt oder erst nach 5 Mahnungen und Betreibungsandrohungen) und somit die Konditionen (z.B. 30 Tage Zahlungsfrist und 5000 Euro Kreditlimite oder Vorauszahlung), USt-Nummer (leer bei privaten Kunden). Als Schlüsselfeld eine Kundennummer, die das System fortlaufend vergeben soll.

Aufbau Lieferantenstamm: Ebenfalls genaue Anschrift mit Firmenname, zuständiger Verkaufsperson, Adresse und Land/PLZ/Ort, Telefon, Fax, E-Mail und Homepage, zusätzlich noch die Bankverbindung (Bankname, Kontonummer und Bankleitzahl), Fremdkundennummer (unter welcher Nr. erscheint man dort als Kunde), USt-Nr. Auch hier fortlaufende Nummer als Schlüsselfeld.

Aufbau Artikelstamm: Bezeichnung des Artikel (z.B. "Gitarrenzupfplättchen") und Beschreibung (z.B. "aus Kunststoff rot"), Ankaufs- und Verkaufspreis, Lagerbestand, Mindestbestellmenge, Lieferant (1:n-Verknüpfung, d.h. verweist auf Datensatz zuvor!) und Bestellnummer.

Aufbau Auftrag: Kunde (1:n-Referenzierung!), Bezeichnung, Referenz (Kunde kann eine frei wählbare Bezeichnung angeben, die auf sämtlichen Begleit- und Rechnungspapieren erscheinen soll. Dies ist im Beschaffungswesen bei Grosskonzernen sehr gebräuchlich), Status (Enumerationsdatentyp, der folgende Zustände bei auf Rechnung belieferte Kunden kennt: Offerte, Bestellung entgegengenommen, Ausgeliefert, fakturiert und Betrag noch offen, Zahlung erhalten), Datumfelder für Offerte, Auftragsentgegennahme, Fakturadatum, Mahnstufe.

Dazu braucht es gleich noch einmal eine Tabelle (=in QB relative Datei) für Auftragsposition: Pointer-Index auf Auftrag, Anzahl und Artikel (auch Pointer-Index).

Von Zeit zu Zeit müssen wir unser Lager aufstocken, also müssen wir schriftlich per Fax oder EDI bestellen können. Aufbau Lieferantenbestellung: fortlaufende Nr., Pointer auf Lieferant, Datum unserer Nachschubbestellung. Status (Enumerationsdatentyp: Bestellung am Zusammenstellen, Bestellung zustestellt, Ware erhalten, Ware am Eingang kontrolliert, Rechnung erhalten, Rechnung bezahlt und erledigt), Rechnungsnummer Lieferant / Mitteiltext für die Giro-Überweisung.

Und auch hier brauchen wir natürlich Bestellposition: Zeiger auf Bestellung, Anzahl und Zeiger auf Artikel.

Hinweise Zeiger in QB: In relativen Dateien verwendet man normalerweise GET# und PUT#. Dabei stellt die Datensatznummer gewissermassen die "Speicheradresse" dar => Zeigerfelder sind daher einfach eine Ganzzahl, in welcher die Datensatznummer hinterlegt wird.

Bis hierhin (man sieht aufgrund der Länge des Postings, dass so etwas durchaus etwas Komplexeres gibt!) haben wir erst das Datenmodell definiert. Jetzt müssen wir noch die Funktionen definieren. Wir benötigen:

- Kunde erfassen / mutieren / löschen*
- Lieferant erfassen / mutieren / löschen*
- Artikel erfassen / mutieren / löschen*
* = nur erlaubt, wenn keine offenen Aufträge bzw. Bestellungen existieren!

Auftrag erfassen: Kunde auswählen, dann Bezeichnung (z.B. "Beschaffung Gitarre") nehmen, heutige Datum als Default bei Offerte einsetzen, Funktion Bestellposition hinzufügen, die man beliebig oft aufrufen kann (Beispiel: 1x Art. "Contry-Gitarre Modell XY", 2x Reserve-Saite e, 2x Reserve-Saite a, 2x Reserve-Saite d', 5x Zupfplättchen rot, 1x Kapotaster, 1x Notenständer, 1x Fussstütze, 1x Buch "Die Gitarrenschule von XY" => gibt also dann schlussendlich eine Anzahl Positionen-Records). Sobald Auftrag erfasst, muss man diese auf dem Laserdrucker ausgeben können (bzw. die Offerte als PDF distillen, falls die Anfrage per E-Mail reinkam. Aber dies dürfte den Rahmen eines QB-Projekts sprengen).

Sobald auf dem Fax die schriftliche Bestellung reintrudelt: Funktion, um Auftrag anhand der Nummer abrufen können und Status anpassen. Nun kommen die Nuancen für so ein Projekt: Lagerbestände (Feld "Anzahl im Lager" von Artikel) sollte man entsprechend nachtragen, so dass man als Sachbearbeiter sieht, wo überall es zuwenig im Lager hat).

Wechseln wir daher zur Lieferantenseite: Auch dort ganz analog eine Maske, um eine Bestellung zusammenstellen zu können, z.B. beim Saitenhersteller je 200 Stück von allen 6 Saiten liefern lassen. Das Tüpfchen aufs i wäre eine Funktion "Automatische Bestellungen generieren", die anhand der Lagerbestände automatisch ermittelt, wo überall Nachschub notwendig ist.

Die Bestellfunktion muss dabei in der Lage sein, auf dem Laserdrucker eine fixfertige schriftliche Bestellung zu generieren, die man nur noch unterschreiben und auf den Fax legen muss bzw. als XML-Datei über EDI einlesen kann.

Sobald alles Material da ist, wollen wir es natürlich ausliefern können und dazu eine Rechnung (mit korrekt ausgewiesener Mehrwertsteuer!) auf dem Laserdrucker ausgeben können, die man dem Kunden per Post zur Bezahlung zukommen lässt (oder neuerdings bei Privatpersonen auch häufig per E-Mail schickt).

Schliesslich müssen wir die Zahlungen überwachen, also braucht unsere QB-Applikation noch ein Funktion "Mahnlauf". Diese sucht sämtliche Aufträge mit Status "fakturiert", die noch offen sind und sich bereits über dem Fälligkeitsdatum befinden. Als Output muss dann auf dem Laserdrucker eines der üblichen Schreiben abhängig von der Mahnstufe erscheinen, also "Kontoauszug", "1. Mahnung", "2. Mahnung", "Letzte Mahnung" und nach Mahnlaufdurchführung überall das Mahnstufenfeld um 1 erhöhen.

Ebenfalls eine Funktion in unserer Applikation: Giro-Eingang verbuchen. Nur bei mir in der Schweiz noch zusätzlich möglich: Von der Bank maschinell verarbeitbare Zahlungseingänge (bekommt man als ASCII-File) einlesen, weil es bei uns die sog. orangen ESR-Einzahlungsscheine gibt. In Deutschland ist mir bisher noch kein vergleichbares System bekannt.

Umgekehrt auf der Kreditorenseite: Wenn ich dort meine Rechnungen beglichen habe, möchte ich diese ebenfalls als erledigt verbuchen können. Luxuserweiterung dort: DTA-Zahlungsdatei generieren, in dem man einfach dem System sagen kann, es soll z.B. die innerhalb der nächsten 14 Tagen fälligen offenen Rechnungen raussuchen und zusammengenerieren und diese nach erfolgreicher Übermittlung an die Bank (früher eine Diskette per Post - heute ein <INPUT type="file">-Upload innerhalb der jeweiligen Online-Bankingoberfläche) ebenfalls automatisch verbuchen.

Schlussendlich interessieren wir uns noch für Auswertefunktionen, z.B. Datenfeld "Bonität" automatisch aufgrund des Mahnstatus updaten, Total von jedem Artikel verkaufte Anzahl Einheiten ermitteln => Umsatz usw.

@mlb: Ich hoffe, Du bist nicht gleich erschlagen, aber so ein Projekt kann schnell einmal recht komplex werden!
_________________
Teste die PC-Sicherheit mit www.sec-check.net