Kundennummer ändern
David Rummel
konnten dort immer die Kundennummern nachträglich ändern. Nun benutzen wir
LXFO2003 als Netzwerkversion und das Feld Kundennummer ist immer grau
hinterlegt, wenn man einen Kunden bearbeitet. Gibt es noch eine Möglichkeit
die Nummer nachträglich zu ändern. Hintergrund ist, dass sich unsere
Kd-Nummern aus verschiedenen Teilen zusammensetzen, wobei wir einige
Informationen erst nach Auftragsbeginn erhalten, und somit auch später erst
einpflegen können.
mfg
David Rummel
Silvia
> mfg
> David Rummel
Hallo David,
ich habe schon alles ausprobiert - ich bekomme die Nummern auch nicht
geändert. Das selbe Problem besteht auch bei den Lieferanten-Nummern. Das
ist mal wieder ein typischer Lexware-Bug
Gruß
Silvia
Udo Netzel [Team Sonderhomepage]
> ich habe schon alles ausprobiert - ich bekomme die Nummern auch nicht
> geändert. Das selbe Problem besteht auch bei den Lieferanten-Nummern.
Das
> ist mal wieder ein typischer Lexware-Bug
Das ist kein Bug, sondern Absicht! Die Kunden- bzw. Lieferanten-Nummer
ist ein Index-Feld und kann deshalb nicht verändert werden.
In Financial-Office Standard funktioniert es, da dort die Datenbanken
anders verknüpft sind.
--
Freundliche Grüße aus Berlin
Udo Netzel
Team http://Sonderhomepage.de --- User helfen Usern (UhU)
Gutleber Walter
nun mit ein bischen SQL kann man das schon ändern, da ja nur 3 Tabellen
betroffen sind.
Denn es sind ja nur die Auftrags und die Auftrags Positionsdatei. Und
natürlich die Kundenliste.
Aber der Aufwand ist es nicht wert. Warum immer so komplizierte Kundennummer
? Ist doch egal, welche Nummer die haben,
Hauptsache es gibt keine Doppelten.
Und die Erklärung es wäre ein index und man könnte den nicht ändern ?! Was
sind denn das für Programmierer ?
Klar kann man das ändern, Verzeichnisse kann man ja auch umbenennen
verschieben ...
Also das Programm hat schon ein paar Bugs. Aber es ist wohl ein Cobol
Nachkomme und die Btrieve Datenbank
der STD Version zeigt dies doch deutlich. Und auch die Datenbank von Sybase
ist wohl eine teure und nicht unbedingt gute wahl.
z.B. Interbase / Firebird, kostenlos und dann auch noch opensource also da
könnte man Kostensparen und dafür etwas mehr Fehler beseitigen.
Obejktorientierte und Durchdachte Strukturen, würden hier viele
Möglichkeiten eröffnen, ohne großen Aufwand.
Aber dennoch, finde ich das Programm besser als den Schrott für Viel geld,
der genau die gleichen Macken hat. (S)anduhren(A)nzeige(P)rogramm z.B.
und da ich ja nicht Kinderpost spiele, denke ich einfach Buchhalten
Lohnabrechnen und Rechnungen schreiben kann es und mehr braucht man doch
auch nicht wirklich !
mfg Walter
PS. Mußte das loswerden nichts für ungut.
"Udo Netzel [Team Sonderhomepage]" <Fo...@Sonderhomepage.de> schrieb im
Newsbeitrag news:9rDZUxi...@star.lexware.de...
David Rummel
"Gutleber Walter" <Walter....@setas.de> schrieb
> Ist doch egal, welche Nummer die haben,
> Hauptsache es gibt keine Doppelten.
Nein, leider nicht. Unsere Kundennummern setzen sich aus verschiedenen
Nummern zusammen, die später auf unseren selbsterstellten Dokumenten
erscheinen ohne weitere Informationen über den Besteller, Bezirk etc. Das
lässt sich dann nur noch aus der Kundennr. ableiten und wenn die nicht
vollständig ist, weil z.B. bei Auftragseingang noch nicht alle Daten
vorlagen (was bei uns aus diversen Gründen schon mal vorkommt), dann kriegen
wir früher oder später ein Problem bei der Zuordnung.
> Und die Erklärung es wäre ein index und man könnte
> den nicht ändern ?! Was sind denn das für
> Programmierer ?
> Klar kann man das ändern,
Sehe ich ähnlich. Ein ganz normales Indexfeld das der Endbenutzer gar nicht
erst zu Gesicht bekommt hätte gereicht, damit man in aller Ruhe alle
Informationen des Kunden abändern könnte, es existiert sogar schon so ein
Feld ("SheetNr"), jedenfalls scheint es keinen weiteren Zweck zu erfüllen,
aber ändern kann man die KD-Nummer ja trotzdem nicht.
Schade auch, dass hier ja wohl auch eines der "Gesetze" die bei der
Erstellung eines DB-Modells gelten sollten missachtet wurde. Man soll zwar
eine Datenbank möglichst restriktiv designen, aber trotzdem sichergehen,
dass alle Sonderfälle trotzdem abgedeckt werden, o.s.ä., falls ich mich
recht entsinne.
> Also das Programm hat schon ein paar Bugs.
Ja, aber mir scheint es, wenn man sich länger damit beschäftigt, findet man
auch immer mehr Möglichkeiten, um diese zu umgehen, mittlerweile läuft das
hier alles sehr gut, ich hab hier sogar schon etwas API-ähnliches mit dem
ich unsere Bastellösung hier erweitern kann :)
mfg
David Rummel
Udo Netzel [Team Sonderhomepage]
> Nein, leider nicht. Unsere Kundennummern setzen sich aus verschiedenen
> Nummern zusammen, die später auf unseren selbsterstellten Dokumenten
> erscheinen ohne weitere Informationen über den Besteller, Bezirk etc.
Das
> lässt sich dann nur noch aus der Kundennr. ableiten und wenn die nicht
> vollständig ist, weil z.B. bei Auftragseingang noch nicht alle Daten
> vorlagen (was bei uns aus diversen Gründen schon mal vorkommt), dann
kriegen
> wir früher oder später ein Problem bei der Zuordnung.
Warum benutzen Sie dafür kein Freifeld?
> Schade auch, dass hier ja wohl auch eines der "Gesetze" die bei der
> Erstellung eines DB-Modells gelten sollten missachtet wurde. Man soll
zwar
> eine Datenbank möglichst restriktiv designen, aber trotzdem
sichergehen,
> dass alle Sonderfälle trotzdem abgedeckt werden, o.s.ä., falls ich
mich
> recht entsinne.
Das widerspricht sich doch! Entweder restriktiv, oder *alle*
Sonderfälle. An eine derartige "Vergewaltigung" der Kundennummer hat
eben keiner gedacht und hier den Riegel vorgeschoben.
Man kann zwar theoretisch diese Index-Felder abändern, aber das ist hier
nicht vorgesehen.
David Rummel
Hallo Udo,
> Warum benutzen Sie dafür kein Freifeld?
Nun, ehrlich gesagt, wenn ich heute die Firma gegründet hätte, hätte ich es
wahrscheinlich auch so gemacht. Als ich aber hier dazukam war das natürlich
alles schon in vollem Gange und man hatte hatte halt diese Kundennr. so
gewählt, wahrscheinlich auch deshalb, weil die anderen Teile der KD-Nr. in
den Standard-Formularen, dann auch gleich automatisch an der richtigen
Stelle mitausgedruckt wurden etc. Außerdem konnte man am Anfang die Nummern
ja noch ändern, da damals noch die alte Einzelplatzversion von LXFO im
Einsatz war.
> Das widerspricht sich doch! Entweder restriktiv, oder
> *alle* Sonderfälle. An eine derartige "Vergewaltigung"
> der Kundennummer hat eben keiner gedacht und hier
> den Riegel vorgeschoben.
Ich finde nicht das sich das widerspricht. Sonst müsste restriktiv im
Endeffekt bedeuten, dass man gar nichts mehr darf. Aber wie Du auch schon
gesagt hast, sind diese Sonderfälle natürlich auch persönliche
"Ansichtssache" und wenn man wirklich *alle* Sonderfälle abdecken wollte,
bräuchte man für Datenbanken wahrscheinlich nur noch den Datentyp "longtext"
o.ä. :) Wie gesagt, ich hab hier mittlerweile was drumherum gebastelt, was
hier gut läuft, stören tuts mich aber halt trotzdem ein bisschen.
mfg
David Rummel
vi...@sadowsky.de
Hallo,
ich denke das Problem liegt hier in den sog. "sprechenden"
Kundennummern. Diese sind m.E. in der ralität weit häufiger
verbreitet, als man annimmt.
Aus diesem Grund, sollte auch KEINE Software auf einer vom Kunden
einzugebenden Nummer einen Index erzeugen, sondern intern ein
Indexfeld mitführen.
Das lernt man schon im Datenbank Grundkurs.
Eine Indexnummer wird dort z.B. als unsichtbare (für den Benutzer)
Autoinkrement Variable programmiert.
Robert
Burkhard Flügge
>
> ich denke das Problem liegt hier in den sog. "sprechenden"
> Kundennummern. Diese sind m.E. in der ralität weit häufiger
> verbreitet, als man annimmt.
> Aus diesem Grund, sollte auch KEINE Software auf einer vom Kunden
> einzugebenden Nummer einen Index erzeugen, sondern intern ein
> Indexfeld mitführen.
>
> Das lernt man schon im Datenbank Grundkurs.
>
> Eine Indexnummer wird dort z.B. als unsichtbare (für den Benutzer)
> Autoinkrement Variable programmiert.
Kurz zum Datenbank-Grundkurs
Entgegen Deiner Annahme SIND die Kundendaten mit einer internen ID versehen.
Da die Kundennummer immer eindeutig ist, bei den verdeckten Infos aber
Duplikate möglich sind, kämen in einer normalisierten Datenbank demnach
mindestens 2 getrennte Datenfelder in Frage. Die Infos hätten insofern in
der Kd.Nr. nichts zu suchen.
Die Kundennummer ist in der Faktura ja editierbar, aber halt nur so lange,
bis Aufträge über diese Nummer abgewickelt wurden.
Das macht Sinn, da die Auftragsbelege im Nachhinein nicht veränderbar sein
sollten und damit über diese Nummer auch in ein paar Jahren noch Aufträge
eindeutig identifizierbar sind.
Stell Dir vor, alle Daten, die Du in der Kundenmaske später veränderst,
wirkten sich auf die historischen Belege aus. Welch ein Chaos.
Das System mit den verdeckten Informationen ist ja nur für den *internen*
Gebrauch gedacht.
Daher würde ich, wenn die Infos unbedingt in der Kundennummer enthalten sein
sollen, die Erst-Aufträge vorerst über ein Sammelkonto abwickeln, bis alle
Kundendaten vorliegen, und später die Nummer generieren, oder, wie Udo schon
vorschlug, ein Freifeld verwenden, welches man in die entsprechenden Listen
und Formulare an passender Stelle integrieren kann.
Gruß Burkhard
Udo Netzel [Team Sonderhomepage]
> Stell Dir vor, alle Daten, die Du in der Kundenmaske später
veränderst,
> wirkten sich auf die historischen Belege aus. Welch ein Chaos.
Solange man die Belege online hat, könnte man das abfangen, indem man
nach der Änderung auch in den histrorischen Belegen die Kundennummer
ändert. Dauert eben je nach Rechner etwas.
Viel schlimmer ist aber die bereits gedruckte Rechnung. Ich stelle mir
gerade eine Querprüfung vom Finanzamt vor und der Prüfer sucht eine
Rechnung an Kunden "4711", die er aber nicht mehr findet, weil dieser
jetzt "0815" heißt.
...ja wissen Sie Herr Finanzamt, das ist so....und die Stirn des Prüfers
legte sich in Falten....;-))
Man könnte natürlich auch noch eine Änderungsdatenbank mitführen, die
alle Änderungen in allen Bereichen protokolliert, aber das dürfte wohl
für diesen Preis nicht realisierbar sein.
vi...@sadowsky.de
<Fo...@Sonderhomepage.de> wrote:
>Hallo Burkhard,
>
>> Stell Dir vor, alle Daten, die Du in der Kundenmaske später
>veränderst,
>> wirkten sich auf die historischen Belege aus. Welch ein Chaos.
>
>Solange man die Belege online hat, könnte man das abfangen, indem man
>nach der Änderung auch in den histrorischen Belegen die Kundennummer
>ändert. Dauert eben je nach Rechner etwas.
>
>Viel schlimmer ist aber die bereits gedruckte Rechnung. Ich stelle mir
>gerade eine Querprüfung vom Finanzamt vor und der Prüfer sucht eine
>Rechnung an Kunden "4711", die er aber nicht mehr findet, weil dieser
>jetzt "0815" heißt.
>
>...ja wissen Sie Herr Finanzamt, das ist so....und die Stirn des Prüfers
>legte sich in Falten....;-))
>
>Man könnte natürlich auch noch eine Änderungsdatenbank mitführen, die
>alle Änderungen in allen Bereichen protokolliert, aber das dürfte wohl
>für diesen Preis nicht realisierbar sein.
Hallo Udo,
ich denke zwar, das der Prüfer eher eine Rechnung an Herr / Frau /
Firma XYZ sucht, aber ansosnten muß ich dir teilweise Recht geben
(bzgl. Änderungsverfolgung).
Robert
Ralf Stahl
Hallo
Ich habs nicht mehr ausprobiert, aber ich glaube, wenn man die Kunden in
eine Datei exportiert und die KuNr. ändert und wieder mit "vorhandene
Datensätze überschreiben" importiert, werden die Nummern geändert (keine
Garantie, bitte vorher Daten sichern!).
Mfg Ralf Stahl
Udo Netzel [Team Sonderhomepage]
> Ich habs nicht mehr ausprobiert, aber ich glaube, wenn man die Kunden
in
> eine Datei exportiert und die KuNr. ändert und wieder mit "vorhandene
> Datensätze überschreiben" importiert, werden die Nummern geändert
(keine
> Garantie, bitte vorher Daten sichern!).
Nein, weil der Vergleich "vorhandene Datensätze" exakt mit der
Kundennummer verglichen wird.
Gutleber Walter
mich hat nun auch erwischt ! Ein Fehler bei der Eingabe und die Debitoren
Nummer stimmt nicht mit der Kundennummer.
Und die die andere Debitoren Nummer ist schon vergeben !
Also hab ich ein bischen programmiert und so:
vieleicht hilft es ja:
temporären Kunden einen mit der Nummer 99999 anlegen ohne Debitoren Konto
Wenn da ein projekt besteht geht es nicht. Also Erst das Projekt auf den
Tempkunden ändern und dann Kundennummer ändern
und dann Projekt wieder richtig zuordnen !
F3 ist die Aktive Firma also an die Benötigten Daten anpassen !
Alles ohne Garantie, aber wenn einer was ändern will hilft es ja vieleicht
ein wenig ! Alles auf eigene Gefahr !!
// Auszug
AnsiString tmp="99999";
AnsiString old="12003"; // Alte Kundennummer
AnsiString neu="12004";// Neue Kundennummer
Query1->SQL->Clear();
Query1->SQL->Add("UPDATE F3.FK_Auftrag");
Query1->SQL->Add("SET KundenNR='"+tmp+"'");
Query1->SQL->Add("WHERE KundenNR='"+old+"'");
Query1->ExecSQL();
Query1->SQL->Clear();
Query1->SQL->Add("UPDATE F3.FK_Kunde");
Query1->SQL->Add("SET KundenNR='"+neu+"'");
Query1->SQL->Add("WHERE KundenNR='"+old+"'");
Query1->ExecSQL();
Query1->SQL->Clear();
Query1->SQL->Add("UPDATE F3.FK_Auftrag");
Query1->SQL->Add("SET KundenNR='"+neu+"'");
Query1->SQL->Add("WHERE KundenNR='"+tmp+"'");
Query1->ExecSQL();
mfg Walter
"Udo Netzel [Team Sonderhomepage]" <Fo...@Sonderhomepage.de> schrieb im
Newsbeitrag news:AdEr6qF...@star.lexware.de...