Neue Tabellenstruktur fuer mein Projekt

19/01/2010 - 21:39 von Volker Neurath | Report spam
Hallo zusammen,

ich bin nun nicht derjenige, der sich durch Rueckschlaege stoppen laesst
- zumindest nicht so leicht.
Allerdings habe ich mir jetzt vorgenommen, mein Projekt auf eine
solidere Basis zu stellen als bisher und deswegen damit begonnen,
das Tabellendesign zu ueberarbeiten.

Allerdings tue ich mich an einigen Stellen etwas schwer.
Daher hier nochmal kurz zur Erlaeuterung:

Ziel ist, eine DB zu erstellen, in der Informationen ueber Angebote
gespeichert sind (bisher aber nicht die einzelnen Angebotspositionen -
dies soll aber bei Bedarf moeglich sein - oder zumindest moeglichst
"einfach" hinzuzufuegen sein).

Ein Angebot enthaelt bei uns, neben den Artikelpositionen, folgende
Informationen:

Angebotsnummer
Verantwortlicher VB VB=Vertriebsbeauftragter
Erfasser
Gueltig ab
Gueltig bis
Abgabe am: (Termin zur vorlage beim Distributor)
Distributor
Haendler
Endkunde
AP Distributor
AP Haendler
AP Endkunde

Ausserdem sollen einige organisatorische Daten mitgespeichert werden:
problem - gab es Probleme bei der Angebotserfassung (ja/nein)
manuell - wurde das Angebot Artikel fuer Artikel manuell
erfasst (ja/nein) [1]
Master - Kennzeichen des "Master"-angebotes eines Projektes[2]
Vorgaenger - Vorgaenger des aktuell erfassten Angebotes
Kommentare - beliebige kommentare zu einem Angebot.
Status - Bearbeitungs-/Freigabestatus[3]

Zudem waere es nett, wenn jede Veraenderung des Status eines Angebotes,
egal ob dies durch manuelle Bearbeitung oder import von externen Daten
geschieht, mitgeloggt werden koennte.[3]

Wichtig ist noch:
wenn ein Angebot abgelaufen ist ? entweder wegen Überschreitung des
Gültigkeitsdatums oder wegen Mengenüberschreitung (d.h. Kunde bestellt mehr,
als die ursprünglich angebotene Menge) ? dann wird bei uns ein neues Angebot
erstellt, in dem je nach dem das Gültigkeitsdatum veràndert oder die Mengen
der Artikel angepasst wurden.
Ebenso kommt es vor, dass Nachfolgeangebote erstellt werden müssen, weil im
ersten Schritt die Preisgestaltung noch nicht optimal war.
Dieser komplex ist schwierig zu beschreiben, ich mach morgen mal ein paar
Beispiele - ich will dieses Post nicht noch lànger machen ;)

Ich habe mir zu diesem Komplex selbstverstandlich schon Gedanken gemacht
und eine neue Tabellenstruktur erstellt; ihr koennt sie unter
http://home.telebel.de/voneura/foto...en-neu.JPG
einsehen.

Unterschiedliche Tabellen für Distributoren (Direct customer)
Hàndler(Indirect customer) und Endkunde (Final customer) habe ich damals
erstellt, weil ich nicht 100% sicher war, dass es zwischen dem SAP-
Nummernkreis für Distributoren und Hàndler keine Überschneidungen gab - an
die Vergabe eines Autowert-Primàrschlüssels hatte ich damals nicht gedacht,
außerdem wàre auf diese Weise die Vermeidung von Mehrfacheingabe eines
Kunden zumindest extrem erschwert, wenn nicht gar unmöglich.

Volker

[1] die Artikel eines Angebotes koennen auf zweierlei Weise erfasst werden:
1. manuelle Einzeleingabe
2. Hochladen einer Exceltabelle mit festgelegter Struktur, in der
die Artikel gespeichert sind.

[2] Zu ein und demselben Projekt kann es mehrere Angebote mit unter-
schiedlichen Distributor-Haendler-Kombinationen.
Als "Master" bezeichnen wir bisher die erste zu einem Projekt
erfasste Quotation, aeh, Angebot.
Bei allen weiteren soll diese Nummer (oder was auch immer)
mitgefuehrt werden, um eine ProjektHistorie darstellen zu koennen,
ebenso die Nummer des vorangegangenen Angebotes (siehe oben)

[3] Ein einmal erfasstes Angebot kan in unserem System folgende
Stati annehmen:
On hold - in Bearbeitung durch den Erfasser
Awaiting Approval - warten auf Freigabe durch Verantwortliche
Rejected - Abgelehnt
Sent to customer - An kunden verschickt
Won
Lost
Partially win

Wichtig sind fuer meine DB aber nur die ersten 4.
Im übrigen bin ich der Meinung, dass TCPA/TCG verhindert werden muss

Wenn es vom Himmel Zitronen regnet, dann lerne, wie man Limonade macht
 

Lesen sie die antworten

#1 Frank Müller
21/01/2010 - 01:12 | Warnen spam
Hallo Volker,

Volker Neurath wrote:

ich bin nun nicht derjenige, der sich durch Rueckschlaege stoppen
laesst - zumindest nicht so leicht.



Sehr gut

Allerdings habe ich mir jetzt vorgenommen, mein Projekt auf eine
solidere Basis zu stellen als bisher und deswegen damit begonnen,
das Tabellendesign zu ueberarbeiten.



Noch besser :-)
Aber erlaube mir, unabhàngig davon die Frage, ob es nicht
zusàtzlich auch angebracht ist, das ganze Konzept von der
Logik her zu überarbeiten.

Folgende Punkte scheinen mir nicht nicht ganz klar, wahrscheinlich
auch nur weil ich ja deine konkrete Situation nicht kenne. Aber
andere Leser hier ja auch nicht.

Ziel ist, eine DB zu erstellen, in der Informationen ueber Angebote
gespeichert sind (bisher aber nicht die einzelnen Angebotspositionen -
dies soll aber bei Bedarf moeglich sein - oder zumindest moeglichst
"einfach" hinzuzufuegen sein).



Definiere Angebotspositionen...

Ein Angebot enthaelt bei uns, neben den Artikelpositionen, folgende
Informationen:



im Vergleich zu Artikelpositionen.
Bei "normalen" Angeboten an einen Kunden ist das eigentlich identisch.
Was du jetzt weiter schreibst sind die Kopfdaten mehr oder weniger.

Angebotsnummer
Verantwortlicher VB VB=Vertriebsbeauftragter
Erfasser
Gueltig ab
Gueltig bis
Abgabe am: (Termin zur vorlage beim Distributor)
Distributor
Haendler
Endkunde
AP Distributor
AP Haendler
AP Endkunde



Da fehlt meiner Meinung nach das konkrete Angebotsdatum.
Weil darauf wird ja bei Bestellungen in der Praxis konkret
Bezug genommen. Ihr Angebot [Angebotsnummer] vom [Amgebotsdatum]

Ausserdem sollen einige organisatorische Daten mitgespeichert werden:



Das sind aber Zusatzinfos die nicht in der Angebotstabelle selbst enthalten
sein sollten.


Zudem waere es nett, wenn jede Veraenderung des Status eines
Angebotes, egal ob dies durch manuelle Bearbeitung oder import von
externen Daten geschieht, mitgeloggt werden koennte.[3]


Wichtig ist noch:
wenn ein Angebot abgelaufen ist ? entweder wegen Überschreitung des
Gültigkeitsdatums



Das würde eine Abfrage auf die Angebotsnummer und dein Gültig bis
Feld ergeben.


oder wegen Mengenüberschreitung (d.h. Kunde
bestellt mehr, als die ursprünglich angebotene Menge) ? dann wird bei
uns ein neues Angebot erstellt, in dem je nach dem das
Gültigkeitsdatum veràndert oder die Mengen der Artikel angepasst
wurden.



Also ist es ein völlig neues Angebot mit neuer Angebotsnummer.

Ebenso kommt es vor, dass Nachfolgeangebote erstellt werden müssen,
weil im ersten Schritt die Preisgestaltung noch nicht optimal war.



Auch dann ist ist es jeweils ein völlig neues Angebot mit neuer Nummer.

Die Historie kannst du aber über die Kundentabelle führen weil ja
zu jedem Kunden die Angebote erfasst sind. Man kann sich für
zusammenhàngende Angebote auch einen eigenen Nummernkreis
ausdenken wie z.B. Angebotsnummer 4711, 4711-1, 4711-2 usw.

Dieser komplex ist schwierig zu beschreiben, ich mach morgen mal ein
paar Beispiele - ich will dieses Post nicht noch lànger machen ;)

Ich habe mir zu diesem Komplex selbstverstandlich schon Gedanken
gemacht und eine neue Tabellenstruktur erstellt; ihr koennt sie unter
http://home.telebel.de/voneura/foto...en-neu.JPG
einsehen.



OK da ist SAP im Spiel wie es aussieht. Das ist eine ganz eigene
Welt von der Logik her.

Unterschiedliche Tabellen für Distributoren (Direct customer)
Hàndler(Indirect customer) und Endkunde (Final customer) habe ich
damals erstellt, weil ich nicht 100% sicher war, dass es zwischen dem
SAP- Nummernkreis für Distributoren und Hàndler keine
Überschneidungen gab - an die Vergabe eines Autowert-Primàrschlüssels
hatte ich damals nicht gedacht, außerdem wàre auf diese Weise die
Vermeidung von Mehrfacheingabe eines Kunden zumindest extrem
erschwert, wenn nicht gar unmöglich.



Na ja, ein Autowert ist nie tauglich für eindeutige Identifizierung eines
Datensatzes. Geschweige denn eines Kunden bei der Neuanlage.

Aber wie es aussieht, arbeitest du ja mit SAP. Da gibt es doch
viele Sachen schon von Hause aus die du hier versuchst nachzubilden.

Deine neue Tabellenstruktru in allen Ehren, aber so wie ich das
mitbekommen habe machst du das nur "nebenbei" mit der Programmierung.

Ist Access eigentlich das richtige Werkzeug dafür? Ich denke eher nicht,
wenn es sich nicht grade um einen persönlichen Wunsch eines Vorgesetzten
handelt der irgendwelche Infos möchte. Der mag dem natürlich überaus
wichtig sein, aber dennoch, ist das die richtige Lösung?

Gruß,
Frank

Ähnliche fragen