{gelöst}Termindatei für Stammdatenänderungen

Hallo,

wir würden gern Stammdatenänderungen in eine Termindatei legen. (ähnlich Preistermine) Es soll z.b. wenn bekannt wird, das sich ein Lieferant oder ein Artikel ändert, die Info gleich eingetragen werden und dann zum Termin X in die aktiven Stammdateien übernommen werden.

Hat das schon jemand realisiert bzw weiß jemand eine Lösung dazu?


Danke
NAVUser

Zuletzt geändert von NAVUser am 23. März 2010 12:03, insgesamt 1-mal geändert.

Im Standard wäre mir hier nichts bekannt.
Was mir spontan einfällt ist eine neue Tabelle in der du hinterlegt ab wann was geändert wird:
- Aktivierungsdatum
- Tabelle
- Feld
- PKey
- neuer Wert

und das dann z.B. mit der Projektwarteschlagen durchlaufen.

Ich könnte mir vorstellen, dies sogar ohne neue Tabellen abzubilden, Beispiel Artikel:
Dort neues Felder: Änderungsdatum, Zielnr..
Ich lege mittels "Artikel kopieren" einen neuen Artikel (dieser hat dann natürlich irgendeine andere Nummer) an, ändere bestimmte Felder. Nun setze ich zwei neue Felder: Änderungsdatum (ab welchem Tag die Feldinhalte dieses neuen Artikels übernommmen werden sollen) und Zielartikelnummer (selbstredend). Nun muss noch ein Automatismus geschaffen werden (z.B. mit dem Navision Application Server, aber auch durch Ausprogrammierung der Codeunit 1), der die Artikeltabelle nach Datensätzen mit Änderungsdatum <>leer & <= heute abfragt, die Daten in den Zielartikel kopiert und - vielleicht - die "Kopiervorlage" löscht.

Dieser Ansatz ist nur dann sinnvoll, wenn diese "Termindatei" die unterschiedlichsten Änderungen (= Felder) auf einmal beinhalten soll. Wenn es sich nur um einzelne Felder handelt, die "synchronisiert" werden sollen, wäre es vielleicht besser, mit Danjos Ansatz zu arbeiten.

Ich würde es mit einer Art zukünftiger Änderungsprotokollposten versuchen, weil man so mit wenig Feldern schön flexibel bliebe. Wie man das Durchführen der Änderungen anstubsen könnte, steht ja schon oben.

Ich würde es mit einer Art zukünftiger Änderungsprotokollposten versuchen, weil man so mit wenig Feldern schön flexibel bliebe. Wie man das Durchführen der Änderungen anstubsen könnte, steht ja schon oben.

Das wäre ja dann Danjos Vorschlag

Das wäre ja dann Danjos Vorschlag

Isses aufgefallen? Mist

Naja, halt nicht richtig gelesen, wie immer

Das mit der Tabelle ist schön und gut, aber man darf nicht alle Stammdaten einfach ändern, wenn Sie an anderer Stelle noch gebraucht werden.
einfaches Beispiel:
Im Artikeltext steht "Gartenspaten grün", der Lieferant hat jetzt die Farbe geändert auf meinetwegen 'grau'. Wenn ich mir so eine Änderung auf Termin lege, und ich noch grüne Spaten im Lager habe, kommt das u.U. nicht so gut. Ein weiteres Beispiel könnten geänderte Einheiten sein. Weil im Karton jetzt nicht mehr 10 sondern nur noch 8 Teile enthalten sind, darfst du den Umrechnungsfaktor der Einheit nicht einfach ändern, wenn du noch Belege oder Bestände mit der alten Einheit bearbeiten musst.

Deshalb würde ich mir sehr genau überlegen, welche Felder ich auf Terminänderung lege. u.U. entziehe ich dem System damit Daten, die evtl. noch gebraucht werden.
Außerdem musst du beachten, ob die Feldänderung noch andere Änderungen bewirkt. Will sagen: Änderst du den Namen eines Debitors, solltest du dringend mit Validate arbeiten, wenn du auch Kontakte benutzt, da die bei Handbetrieb aktualisiert würden. Gleiches gilt für INSERT/Modify(True/False);

Mit anderen Worten überlege dir sehr genau, was du mit der Terminänderung erreichen willst, sonst erreichst du nur unbrauchbare Stammdaten oder gar ein unbrauchbares System.

Gruß, Fiddi

Du hast natürlich recht mit deinem Einwand. Es geht dabei natürlich um Änderungen die SAVE sind. z.b. wir kaufen ab Donnerstag einen Artikel bei einem bestimmten Lieferanten. Das ganze ist in der Vorwoche schon klar oder wir ordnen Artikel intern anders zu z.b. in Verkaufsunterlagen.
Eine Reihe der Änderungen ist natürlich Bestandsabhängig. z.b. ob ich einen Kartoninhalt ändere wenn noch alte Ware da ist usw.
Im Kundenbereich können das Konditionen sein, die ab einem bestimmten Zeitpunkt gültig sind. (z.b. neue DebPreisgruppe)

mfg
NAVUser

Das mit der Tabelle ist schön und gut, aber man darf nicht alle Stammdaten einfach ändern, wenn Sie an anderer Stelle noch gebraucht werden.
einfaches Beispiel:
Im Artikeltext steht "Gartenspaten grün", der Lieferant hat jetzt die Farbe geändert auf meinetwegen 'grau'. Wenn ich mir so eine Änderung auf Termin lege, und ich noch grüne Spaten im Lager habe, kommt das u.U. nicht so gut. Ein weiteres Beispiel könnten geänderte Einheiten sein. Weil im Karton jetzt nicht mehr 10 sondern nur noch 8 Teile enthalten sind, darfst du den Umrechnungsfaktor der Einheit nicht einfach ändern, wenn du noch Belege oder Bestände mit der alten Einheit bearbeiten musst.

Deshalb würde ich mir sehr genau überlegen, welche Felder ich auf Terminänderung lege. u.U. entziehe ich dem System damit Daten, die evtl. noch gebraucht werden.
Außerdem musst du beachten, ob die Feldänderung noch andere Änderungen bewirkt. Will sagen: Änderst du den Namen eines Debitors, solltest du dringend mit Validate arbeiten, wenn du auch Kontakte benutzt, da die bei Handbetrieb aktualisiert würden. Gleiches gilt für INSERT/Modify(True/False);

Mit anderen Worten überlege dir sehr genau, was du mit der Terminänderung erreichen willst, sonst erreichst du nur unbrauchbare Stammdaten oder gar ein unbrauchbares System.

Gruß, Fiddi

Die Debitorenpreisgruppe hat auch einen Haken.
Erstellst du heute schon einen Auftrag, der erst nächste Woche gelten soll, würde er sich beim Gültigkeitsdatum schon die richtigen Preise/Rabatte ziehen. Wenn du die Stammdaten änderst klappt das nicht, wie im Standard mit der "Sales Price".

Bestimmte Stammdaten dürfen auch nicht mehr geändert werden, wenn Buchungen erfolgt sind (Basiseinheit, Artikelkategorie,Lagerabgangsmethode,...). Änderst du ohne Vaildate den Basiseinheitencode bei einem Artikel mit Bestand, kannst den Artikel danach vergessen, es stimmen keine Bestände oder Einstandpreise mehr.

Du siehst vielleicht wie kompliziert das mit dem Änderungsdienst wird. Versuche die Daten lieber zur Laufzeit zur ermitteln. Das funktioniert auch, wenn der Job nachts mal nicht gelaufen ist, und reagiert sofort auf geänderte Stammdaten und nicht erst einen Tag später.

Gruß, Fiddi