Fehler bei Zahlungsverkehreingang-Zuordnung verbuchen

  • Es ist eindeutig, das hier jemand Gott spielt. Dagegen protestiere ich. Ich fordere hiermit auf, das der Eigentümer des Forums sofort reagiert.

    Ich habe kein Problem damit, wenn Buhl der Meinung ist, daß ich nicht mehr als unabhängiger Modertor agieren sollte, ich meinen Platz hier Räume. Das Forum ist nicht mein Leben.
    Zu dem Rest verkneife ich mir eine Kommentar.

  • Man kommt hier mit seinen Schwierigkeiten in Erwartung einer Unterstützung und dann?!

    Damit meinst Du Beiträge wie diesen?
    Und wie soll ein Forumsteilnehmer in diesem Fall helfen?


    Ich dachte die Moderatoren helfen einem, aber hier wird man ja so richtig schikaniert.

    Das ist Unsinn. Außerdem bin ich nur ein Moderator - die anderen Moderatoren werden sicherlich den einen oder anderen Punkt anders sehen.
    Oder fällt das "Duzen" bei Dir unter Schikane? Da kann ich Dich beruhigen. Das ist in diesem und anderen Nutzerforen die normale Umgangsform.

  • Genau, auch Moderatoren können PNs schreiben. Vielleicht kann man die ganzen Trollpostings mal abtrennen, verschieben und ebenso meine Verwarnung und Diffamierung meiner Person zurück nehmen.


    Lösung folgt im nächsten Beitrag.

  • Zufälliger Weise habe ich vor der "Zuordnung verbuchen" eine Sicherung gemacht. Sonst mache ich die immer erst vor dem Monatswechsel, nach "Zuordnung verbuchen".


    Dann bin ich in die Einstellungen -> DB-Manager gewechselt. Suche nach "Zahlungsverkehreingang".


    Bei "Archiv Zahlungsverkehreingang" kann man leider nichts prüfen oder importieren. Dafür gibt es leider nicht wie in anderen Programmpunkten eine Import-Export-Möglichkeit, mit der ich dann auch meine alten Sicherungen nach den Reparaturen mal wieder zusammenfügen könnte.


    Dann habe ich bei "Zahlungsverkehreingang" eine Datenkonsistenzprüfung mit "protokollieren und versuchen zu korrigieren" gemacht. Das Protokoll ergab viele Fehlermeldungen und Reparaturen.


    Danach ließ sich "Zuordnung verbuchen" ausführen, keine Fehlermeldungen mehr, offene Posten ausgeglichen und alle Zahlungsverkehrseingänge sind nun im Archiv.


    Das ist nur eine temporäre Lösung, die für mich bedeutet vor jeder "Zuordnung verbuchen" eine Datensicherung machen.


    Hat jemand eine Idee, wie ich alte "Acrhiv Zahlungsverkehreingange" wieder zusammen bekomme, mittels Export, Import etc.?

  • Hallo "Gast42398",


    ich poste mal zu diesem Thema eine Rückmeldung der Entwickler um deutlich zu machen, dass es sich hier um kein Fehlverhalten der Software handelt.


    "Bezügliches Ihres Sachverhaltes teilen wir Ihnen mit, dass für jeden Datensatz im Zahlungsverkehreingang eine eindeutige ID geschrieben (1, 2, 3, ...) wird. Diese ID darf nur einmal vorkommen. Wenn diese doppelt vorkommt, wird die Fehlermeldung "NexusDB: <unnamed TKontoAuszuegeHisTableDef instance>: Key violation. Operation: Insert ..." verursacht.
    Die ID kommt dabei nicht unbedingt vom gleichen Datensatz, da die Möglichkeit besteht einen Datensatz anzulegen und zu verbuchen um anschließend die Datendatei zu löschen (oder zurückzusichern). Danach wird dann wieder mit der ersten freien ID weiter gemacht.
    Im vorliegenden Mandanten wurden sehr wahrscheinlich manuell die Datensätze im Zahlungsverkehr gelöscht oder die Datei zurückgesichert. Sofern dann auch das Archiv Zahlungsverkehrseingang zurücksichert / gelöscht wird, ist das in Ordnung. Man darf dies nur nicht einseitig, das heißt mit einer Datei machen."

  • Hallo "Support"!


    1. Bin ich bin bei weitem nicht der Einzige mit diesem Problem, was 2. dem telefonischen Support bekannt ist und er gleich mit Löschen der Zahlungverkehrseingangshistory daher kommt.


    3. Lösche ich nicht einfach Datensätze und hatte vorher nichts zurückgesichert und 4. können Sie mit "wahrscheinlich" nicht die Unzulänglichkeiten der Software entschuldigen. Wahrscheinlich kann kein Ziel bzw. Ergebnis einer Programmierung oder eines Programms sein. (Ist es aber: es gibt eine Hohe Wahrscheinlichkeit, das die Verbuchung klappt.)


    5. Vergebe ich keine ID's, sondern die Software, die ebenso in Routinen Fehler bei und Fehlen von ID's feststellen und korrigieren muss.


    6. Ist dieses Verhalten, diese Unzulänglichkeit, der Software schon lange bekannt und hätte längst behoben sein können. Sie versprachen es vor langer Zeit!


    Im letzten Fall befanden sich nach der Fehlermeldung 3 Datensätze in der Zahlungverkehrseinganghistory, dann ging nichts mehr. Da nach dem Rücksichern und der Reparatur (Datenbankkonsistenzprüfung) der Zahlungverkehrseingangsdatenbank die Verbuchung, also das schreiben der History möglich war, gehe ich davon aus, dass das Problem durch falsche ID's in der Zahlungseingang entsteht (ich habe nichts gelöscht oder vorher zurück gesichert!). Die Software hat nicht die Intelligenz der Programmierer, so etwas zu erkennen und beim Verbuchen zu reparieren.


    Gut, wenn man über Backups und Export/Import alle Datenbanken mit ihren Datensätzen wiederherstellen kann... Warum immer noch nicht in der Zahlungsverkehreingangshistory? Und wenn, wann?


    Unterm Strich: die Software funktioniert nicht! Es handelt sich um ein Fehlverhalten der Software bzw. Ingnoranz und Beseitigung des Problems seit 2008!

  • Hallo "Support"!


    Ich habe mal Ihren Job gemacht.


    Der Weg dem Kunden zu empfehlen, die "ZahlungsverkehrEingangHis.MBD" zu löschen und damit dem Kunden seiner Daten zu berauben, ist der falsche! :!: Sie können etwas neues in Ihre Support-FAQ-Schreiben:


    Es reicht nach Auftreten des Fehlers: Datei->Einstellungen->DB Manager->Suchbezeichnung: "Zahlungsverkehreingang"->"Zahlungsverkehreingang" auswählen->Prüfen Datenkonsistenz->weiter->protokollieren und versuchen zu korrigieren->weiter. Dann erscheint ein Protokoll mit den Fehlern und Korrekturen. Danach lassen sich die Zuordnungen verbuchen und werden nach die bis zum Auftreten des Fehlers schon verbuchten in die ZahlungsverkehrEingangHis.MBD eingeordnet.


    Leider habe ich hier noch nie das Wort Verwaltungsreferenz gelesen, sondern nur irgendwelche ID-Probleme. Hier aus dem Datenkonsistenzreparatur-Protokoll:



    Ergänzend zum meinen vorherigen Beitrag, kann ich nur sagen: solche internen Routinen kann ein Programm selbst mitbringen und darüber hinaus wäre festzustellen, wodurch das mit den Verwaltungsreferenzen auftritt und dieses zu unterbinden. Es ist einfach zu sagen, der (dumme) User hat Schuld und irgendwas gelöscht, falsch zurück gesichert etc.


    Meiner Meinung nach haben Sie - und das nicht im Sinne Ihres Kunden - vorschnell die Antwort Ihrer Softwareschmiede akzeptiert. Schmieden kann man auch in Grob- und Feinschmieden unterscheiden. Ich verstehe, dass man Ihnen als Nichtprogrammierer alles erzählen und begründen kann.


    Unterm Strich ist die ganze Herangehens- und Lösungsweise und dadurch meine Zeit-, Daten- und Hotlinekostenverluste über die vielen Jahre hinweg ärgerlich.


  • Der Weg dem Kunden zu empfehlen, die "ZahlungsverkehrEingangHis.MBD" zu löschen und damit dem Kunden seiner Daten zu berauben, ist der falsche!


    Die Empfehlung von Seiten des Supports ist in diesem Falle lediglich das Umbenennen, damit das Archiv nicht verloren geht und ein späterer Zugriff darauf bei Bedarf wieder möglich ist.


    Zitat


    Es reicht nach Auftreten des Fehlers: Datei->Einstellungen->DB Manager->Suchbezeichnung: "Zahlungsverkehreingang"->"Zahlungsverkehreingang" auswählen->Prüfen Datenkonsistenz->weiter->protokollieren und versuchen zu korrigieren->weiter. Dann erscheint ein Protokoll mit den Fehlern und Korrekturen. Danach lassen sich die Zuordnungen verbuchen und werden nach die bis zum Auftreten des Fehlers schon verbuchten in die ZahlungsverkehrEingangHis.MBD eingeordnet.


    Die von Ihnen bemängelte Vorgehensweise stellt lediglich die letzte Möglichkeit dar, um den Sachverhalt zu beheben. Selbstverständlich ist vorhergehend wie von Ihnen korrekt beschrieben vorzugehen, um zu prüfen, ob der Sachverhalt sich bereits auf diesem Wege bereinigen lässt.


    Zitat


    ..der (dumme) User hat Schuld und irgendwas gelöscht, falsch zurück gesichert etc.


    Aussagen dieser Art werden vom Support nicht getätigt und Rückmeldungen der Entwicklungsabteilung beziehen sich unmittelbar auf die den Kollegen vorliegenden Datenbanken der Kunden. Als Entwickler sind diese durchaus in der Lage, die Ursachen korrekt einzuschätzen. Sofern Sie uns Ihre Datensicherung zukommen lassen, prüfen wir auch gerne diese.


    Zitat


    Ein heutige Support-Telefonat 15 Minuten x 0,14 Cent/Minute, brachte nur zu Tage das der Fehler bekannt ist und man die entsprechende Datenbankdatei löschen kann. Ein versprochener Rückruf ist bisher nicht erfolgt...


    Rückrufe werden am Telefon nicht spontan zugesichert, sondern mit dem Kunden und in Verbindung mit Rücksprache der Teamleitung terminiert, wenn der Sachverhalt dies erfordert oder zielführend ist. Bitte haben Sie Verständnis dafür, dass wir auch die telefonische Erreichbarkeit für unsere anderen Kunden gewährleisten möchten und dies daher auch in Ihrem Sinne ist. Des Weiteren ist der technische Support seit dem 01.12.2012 auch unter der Ortsrufnummern 02735 / 909620 zu erreichen.