[Gelöst]Stammdaten/Posten Debitoren zusammenfassen?

[Gelöst]Seit langer Zeit ärgert uns das Problem von unentdeckten Dubletten unter welchen Rechnungen erfasst wurden. Das Umbenennen auf einen bestehenden Debitor ist ja nicht möglich, weshalb mir die Idee kam: warum nicht beim richtigen Debitor den Stammrecord löschen und den falschen auf den richtigen umzubenennen. Ziel: die Bewegungen/Posten sind dann unter einer einzigen Nummer. (Ahnlich wie dies schon in Foren bei Lagerbuchungsgruppen beschrieben wurde.)
Hat jemand in diesem Bereich schon Erfahrung oder gibt es gar ein Report hierzu?

Zuletzt geändert von nikwinkler am 26. August 2008 14:32, insgesamt 2-mal geändert.

Ich habe zwar zu dem Thema keine direkte Erfahrung,
aber wenn du den einen Debitoren löschen willst, dann musst du vorher sicherstellen, das zu diesem keine Buchungen erfolgt sind.
Schliesslich wird die Deb.Nr. beim Buchen gespeichert.

Gruß Mikka

vielleicht muss ich noch präzisieren: wir haben eben den gleichen Kunden unter 2 Nummern erfasst und bei beiden Nummern sind Buchungen vorhanden. Unser Ziel ist es die Buchungen unter eine Nummer zusammenzufassen.

Das geht meines Wissens nicht ohne Weiteres...

Einfach umbenennen geht nicht, da ja zwei zusammengeführt werden müssen.

Theoretisch müsste Debitor B gelöscht werden und die Posten, die Lieferungen, die Rechnungen, die speziellen Preis/Artikel-Beziehungen, Mahnungen,etc. auf Debitor A umgeschlüsselt werden.

Dazu sollte man zum einen eine entsprechende Auflistung machen, was alles umgeschlüsselt werden muss und zum anderen geht das wahrscheinlich nicht ohne einen entsprechenden Programmcode und einer Navision-Lizenz, die Posten verändern darf.
Denn erst müssten alle Posten (inkl. dem Rest) umgeschlüsselt sein, dann könnte die Dublette gelöscht werden.

Hallo zusammen,

ich stehe aktuell auch vor der Aufgabe/Herausforderung für einen Kunden, dessen Debitoren zu "mergen".

Dabei habe ich einen interessanten Eintrag mit Code unter www mibuso com gefunden:
http://www.mibuso.com/forum/viewtopic.p ... e+customer

Hat jemand damit schon Erfahrungen gemacht ?

Wolfgang

Hallo,
da melde ich mich doch mal zu Wort - obwohl ich nun mittlerweile ja eher "Aussenseiter" bin...
Also mit dem "Mergen" auf diese Art und Weise wære ich seeeehr vorsichtig.
Technisch ist das ja nicht das Problem - den ersten Debitoren zu løschen, ohne den Delete-Trigger zu durchlaufen (dann findet keine Pruefung statt und es bleibt alles von dem erhalten) und dann den zweiten in den ersten umzubennen.
Aaaaaber: sowas wuerde ich unbedingt mit dem Steuerberater/Pruefer abklæren!! Gerade das ændert ja im Nachhinein Belege und Posten... Und støsst nicht immer auf Wohlwollen der Pruefer.
Allerdings haben wir das hier bei meinem letzten Arbeitgeber genau so gemacht - vor gut 2,5 Jahren wurden 2 Datenbanken (durch eine Fusion) zusammengefuehrt. Einen Monat spæter hab ich in dem Betrieb angefangen und musste erstmal "aufræumen". Da im Zusammenhang mit der Fusion sowieso einiges umgestellt und geændert wurde - war es auch fuer den Pruefer nicht problematisch, auf diese Weise mit den Debitoren Ordnung zu schaffen.
Wenn's ordentlich dokumentiert wird und der Pruefer keine Einwænde hat - geht das schon.
Eine andere, wenn auch afwændigere, Møglichkeit ist, von Debitor B auf Debitor A per Stichtag die offenen Posten umzubuchen. Mittels eines (neuen) boolschen Feldes ein "Archiv"-Kennzeichen zu setzen (oder man nutzt das "Gesperrt-Kennzeichen"), mit dem man solche Debitoren in Forms und Reports ja auch rausfiltern kann. Ist zwar umstændlicher, stimmt aber ggf. den Pruefer versøhnlicher.

Na dann - viel Glueck!

noch ein kleiner Nachtrag:
Wenn ihr das mit dem Løschen und Umbenennen macht, unbedingt gucken, was noch so im OnDelete-Trigger in der Tabelle 18 steht und gegebenfalls manuell oder im "Merge-Report" handlen.
Ich denke da so an Bankkonten, Lieferadressen, Marketing-Verknuepfung......

das mit den Customers mergen ist ein guter ansatz,

ich würde das benötigen für artikel und artikelposten,wertposten.....

wir haben nämlich bei manchen Artikeln zu beginn die falsche lagerabgangsmethode eingestellt und können diese Artikel nicht umschlüsseln, da ja Posten vorhanden sind....

könnte man das für artikel ebenso machen? also artikelposten umschaufeln, dann artikel die Lagerabgangsmethode ändern und wieder umschaufeln?

Auaaa!!!
Das geht ja nun mit Artikeln ueberhaupt nicht.
Bei Artikelposten existiert ja noch ein bissl mehr - wo du auf diese Weise nicht die gewuenschte Ordnung hinbekommst. Ich sage da nur: Artikelausgleichsposten, Reservierungsposten usw. - gerade in Verbindung mit der Lagerabgangsmethode.
Was soll denn das System machen, wenn du Artikelposten umschaufelst, die Lagerabgangsmethode ænderst und dann die Posten wieder zurueckschaufelst? Die Ausgleichsposten ændern sich dadurch ja nicht automatisch. Auch nicht die Wertposten, die die Abgænge entsprechend bewerten.
In einer gaaaanz alten Navisionversion - als es noch keine Wertposten gab - und auch keine Ausgleichsposten, haben wir mit nem Report die Ausgleiche neu gesetzt und die entsprechenden Lagerwerte ermittelt und gesetzt - aber das war ein Heidenaufwand. Und ist bei der heutigen Datenstruktur eigentlich nicht mehr auf diese Art zu bewæltigen.

Da wird euch wohl nix anderes uebrig bleiben, als mit der richtig eingestellten Lagerabgangsmethode die Bewegunen nachzubuchen....

Hallo Jeanette,

danke für den Hinweis bez. Steuerberater.
Im Falle meines Kunden trifft das zum Glück nicht zu, sonst würde ich strikt davon abraten. Navision ist hier rein für die Warenwirtschaft im Einsatz, ohne richtige Fibu. Auch Zahlungsverkehr und Mahnwesen ist in den drei großen Buchstaben

Die Zuordnung in S#P erfolgt über eine Mitarbeiter/Fremdkunden-Nr. die in Navision ein eigenes Feld hat.
Da liegt aber auch schon mein neues Problem.
Ich habe den Programmcode (http://www.mibuso.com/forum/viewtopic.p ... e+customer) in einem Report angewendet, und folgende Meldung erscheint:
"Das folgende Feld muss Bestandteil des Primärschlüssels sein:

Feld: "Mitarbeiter-Nr"
Tabelle: Debitor"

Ich habe schon die Trigger OnModify, OnRename und OnValidate/Mitarbeiter-Nr. überprüft und ggfls. den Code auskommentiert.

Im CRONUS klappt der Report einwandfrei.

Wer hat noch eine Idee ?
Den Primärschlüssel werde ich jedenfalls dafür nicht erweitern !!!

Wolfgang

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Wie sieht denn der Programmcode genau aus?

(Im Cronus læufts vielleicht, weil da das Feld nicht verwendet wird...)

Wer hat noch eine Idee ?
Den Primärschlüssel werde ich jedenfalls dafür nicht erweitern !!!

Schon mal den Debugger angeworfen (Break on Trigger eq false)?

Markus

Diese Art von Fehler kommt z.B. immer dann, wenn ein auf Recordebene gerechnet wird (CALCSUMS) und im aktuell gewählten Schlüssel das zu summierende Feld nicht als SumIndexField vorkommt.

Hier ist die Konstellation ja etwas anders; diese Meldung in Kombination mit "Primärschlüssel" kannte ich noch nicht.
Egal, ich vermute, den Fehler bekommst du nur deswegen in CRONUS nicht, weil du in deiner Datenbank Filterkriterien gändert hast - es wird eben genau dieses Nicht-Standardfehlt bemeckert.

Hast du im mibuso-Objekt vielleicht einen Filter auf dieses Feld gesetzt (ich habe absolut keine Ahnung, wie dieses Objekt aussieht).

Markus hat schon recht: Höre auf deinen Debugger

Hm, Code ist jetzt auskommentiert, sowohl CRONUS als auch Indivdual.
Weiterhin funzt es nur im CRONUS.
Der Debugger meldet den Fehler direkt beim RENAME-Statement.

Habe daraufhin direkt in Tabelle 18 RENAMEd. Gleicher Fehler

In der Tabelle war ein Key mit diesem Feld angelegt, den habe ich mal deaktiviert, aber kein Erfolg. Ebenfalls ist der komplette Code, der dieses Feld betrifft aus den Tabelle 18 Triggern auskommentiert.

Bin im Moment etwas ratlos.


Wolfgang

was steht denn im report nun noch drin??

In der Tabelle war ein Key mit diesem Feld angelegt, den habe ich mal deaktiviert, aber kein Erfolg. Ebenfalls ist der komplette Code, der dieses Feld betrifft aus den Tabelle 18 Triggern auskommentiert.

Den Report interessiert nicht, was in der /Tabelle/ steht; kommentiere lieber den Aufruf (im Report) mit den Schlüsselfeldern aus.

Markus

Ich bin bereits einen Schritt weiter, als ich geschrieben habe, dass ich ohne Report direkt in der Tabelle 18 den Debitor geändert habe. Denn da kommt bereits die Meldung. Deshalb interessiert mich der Report aktuell nicht.
Ich dachte an Tabellen Relationen in anderen Tabellen auf das Feld Mitarbeiter-Nr. kann mir das aber nicht erklären
Hat von Euch einer dieses Problem beim Rename des Primary Keys gehabt ?

Werde über Dev Kit mal schauen, wo das Feld überall ist.

Wolfgang

in irgendeiner Tabelle gibt es wohl einen Lookup auf das Feld Mitarbeiter-Nr. der Tabelle 18.
Wenn du jetzt auf der Tabelle 18 einen Rename machst, prüft Navision in allen anderen Tabellen, ob dort ein Lookup auf Tabelle 18 gemacht wurde, um dort die Daten ebenfalls zu ändern. Dabei stößt Navision auf eine Tabelle, in der das lookup auf diese Mitarbeiter Nr steht und wirft den Fehler.
Hier hilft wirklich nur das DevToolKit, was aber mit den aktuellen Objektdaten gefüttert sein muss. Du kannst aber auch einfach alle Tabellen im Objektdesigner alle Tabellen markieren und dann F11 drücken.
Alle Tabellen mit Problemen haben dann eine Satzmarkierung im Objektdesigner. eine von denen hat dann den falschen Lookup. Ein Lookup MUSS immer auf ein Primärschlüsselfeld zeigen.

Du kannst aber auch einfach alle Tabellen im Objektdesigner alle Tabellen markieren und dann F11 drücken.

Das wird ihm wohl nicht viel helfen.
Ein Lookup bringt leider erst einen Laufzeitfehler.
Beim Kompilieren meckert Navision da nicht.

Vielleicht wurde ja auch in der Tabelle 18 selbst das Feld Mitarbeiter-Nr. mit einem Lookup auf sich selbst angelegt?
Oder ich tippe auf Tabelle 23 (Kreditor), dass es dort viell. auch dieses Feld gibt mit nem Lookup auf die Mitarbeiter-Nr. im Debitor?

Aber -voyager- dir wird wohl nix anderes uebrig bleiben, als mal alle im Zusammenhang mit der Uebertragung an "den grossen Bruder" angefassten Tabellen nachzugucken.
Es werden doch sooo viele Tabellen nicht sein, in denen dieses Feld eingefuegt wurde??

Viel Glueck!

Du kannst aber auch einfach alle Tabellen im Objektdesigner alle Tabellen markieren und dann F11 drücken.

Das wird ihm wohl nicht viel helfen.
Ein Lookup bringt leider erst einen Laufzeitfehler.
Beim Kompilieren meckert Navision da nicht.

Stimmt, da hast du leider Recht, dann hilft wirklich nur noch das DevToolkit....

So, konnte mich mal wieder diesem Problem widmen.

Es lag an einer TableRelation auf dieses Feld "Mitarbeiter-Nr." in einer Tabelle, welches den Abbruch verursacht hat.
Nachdem ich diese TableRelation entfernt habe, konnte der Rename wunderbar durchlaufen.

Mein Problem ist somit gelöst.
Ob es "nikwinkler" (Verfasser des Eintrags) als Hilfe und als Lösungsansatz reicht, weiß ich nicht

Wolfgang

Vielen Dank für die rege Diskussion zu diesem Thema - ich kam nun erst dazu die Posten zusammenzufassen. Wobei wir die Adresskarten und Debitorkarte von Hand bereinigen und erst am Schluss mit der oben beschriebenen Routine (Debitorrecord löschen ohne Delete Trigger) anwenden um die Bewegungen/Posten zusammenzubringen.

Zuletzt geändert von nikwinkler am 26. August 2008 14:30, insgesamt 1-mal geändert.