Integer Überlauf -MT940-

Hilfe!

Das Einlesen einer MT940 Datei funktioniert nicht mehr, weil das Key-Feld -Integer seine max. Größe erreicht hat. Die Folge ist, dass keine weiteren Bankbelege mehr verarbeitet werden können. Letztendlich werden die Import-Journal-Nr. bis in die Sachposten (G/L Entries) weiterverarbeitet und sind auf Bank Documents referenziert, damit man sich die Original Bankbelege anschauen kann.

Der Grund, weshalb der Integer überläuft, gründet darin, dass in der Einlese-Routine die Belegnummer in 10000 hoch gezählt werden. Inzwischen haben wir den Zähler auf 1 gesetzt, aber noch nicht gelöst, wie wir die "älteren" Bank-Belege vielleicht mit neuer Nummerierung versehen können inkl. der dazugehörigen Tabellen.

Hat Jemand eine Idee?? Vielleicht Export und Import mit Validate???

Grüße
Andrea

Hallo,

die Bankbelege werden bei euch doch sicherlich in ein Buchblatt eingelesen. Wenn in diesem Buchblatt vor dem Einlesen noch eine Zeile enthalten war, wird die Zeilennummer ab dort in 10000er Schritten weiter gezählt.

Versuch den Import mal in ein leeres Buchblatt (keine Filter, vor der 1. Zeile steht ein '*>'), vielleicht klappt es dann.

Gruß, Fiddi

Hallo Fiddi,

das funktioniert bei uns leider nicht so.... es wird die letzte Nummer aus Bank Documents benutzt und hochgezählt. Es geht ja eigentlich auch darum, wie wir unsere alten Daten neu durchnummerieren könnten, damit der Integerwert kleiner wird und wir genug Platz für neue Auszugsdaten haben. Darüberhinaus werden die großen derzeitigen Werte, die in Import Journal ´No. stehen noch Folgen im Sachkonto, weil sie in dieser Tabelle mitgeführt werden und dort ist das Feld ebenfalls Integer.

Andrea

Also, wenn das nicht das übliche Problem ist .

Aber irgendwie habe ich Probleme mit deinen Begrifflichkeiten
Die Tabelle "Bank Document" hat einen Integer- Schlüssel, der aber von den Standardroutinen immer um 1 hochgezählt wird.
Die Belegnummer des Auszugs kommt aus einer Nummernserie. Wenn die in 10000er Schritten konfiguriert ist, dann kannst du die Schrittweite ändern (hast du evtl schon gemacht) oder du definierst einfach eine neue Nummernserie, die mit einer kleineren Schrittweite arbeitet, und das ganze läuft wieder.

Vielleicht kannst du das ganze noch ein wenig klarer beschreiben.
Sollte das Problem tatsächlich nicht auf einfache Art zu umgehen sein, dann wird dir nur euer Partner bleiben, der zunächst einmal herausfinden muss, wo das Feld überall benutzt wird, und muss es dann ändern. Dazu kann ich nur sagen: "Viel Spass";

Gruß, Fiddi

Hallo Fiddi,

ich probiere es noch einmal....

es geht nicht um die Belegnummer des Auszugs, dafür gibt es ja eine Nummernserie, sondern um die einzelnen Zeilen eines Auszugs, die eingelesen werden.
Hier der Auszug aus dem Code

// create BankAccReconLine
WITH BankAccReconLine DO BEGIN
INIT;
"Bank Account No." := BankAccRecon."Bank Account No.";
"Statement No." := BankAccRecon."Statement No.";
LastReconLineNo := LastReconLineNo + 10000; 10000 haben wir auf 1 reduziert und es läuft jetzt
"Document No." := NoSeriesMgmt.GetNextNo(
PaymentSetup."Import No.",CurrentDate,TRUE);
"Statement Line No." := LastReconLineNo;
"Transaction Date" := BankDoc."Posting Date";
VALIDATE("Currency Code",BankAccRecon."Currency Code");

Die letzte lfd. Nummer in Bankbeleg (Table 5001911) ist 2147366471, max. kann das Feld +2147483647 (also haben wir noch 117176 Möglichkeiten einzelne Bankauszugzeilen einzulesen und zu verarbeiten, bis es wieder knallt)
Ja, ich habe mich schon mit den Partner in Verbindung gesetzt und die haben mir mitgeteilt, dass es ein Microsoft Fehler wäre, wir sind aus dem Support beim Partner und wir haben kein Support mehr für diese Version (Linzenzgebühren zahlen wir noch). Vorschläge des Partners sind
1. Integer in Big-Integer (keine Ahnung an wie vielen Stellen und ist ein Riesenaufwand
2. neue Tabelle mit Nummer ob, frei oder besetzt - CodeUnit MT940 umschreiben (scheint mir auch hoch zu sein der Aufwand)
3. Tabelle 5001911 kopieren und aufheben, Table 5001911 leeren (das könnten wir selbst machen, teste ich auch noch)

Ich möchte nicht wissen, welche lfd. Nummern noch voll werden in naher Zukunft, wenn standardmässig in 10000 Schritten in Integer-Feldern hochgezählt wird. Da fragt man sich doch, ob Microsoft will, dass Grenzen schnell erreicht sind, oder?

Andrea

Ich möchte nicht wissen, welche lfd. Nummern noch voll werden in naher Zukunft, wenn standardmässig in 10000 Schritten in Integer-Feldern hochgezählt wird. Da fragt man sich doch, ob Microsoft will, dass Grenzen schnell erreicht sind, oder?

Das hat technische Gründe, damit man nachträglich noch Zeilen zwischen bereits vorhandene einfügen kann. Dann wird die Schrittweite kleiner (10000 am Anfang reicht für 13 Nachträge). Wenn man das nicht braucht, kann man die Schrittweite verkleinern.
Das Integerüberlaufproblem hat man immer, wenn Buchungsblätter zwischendurch nicht komplett durch Buchungsvorgänge geleert werden (können). Dann "pumpt" sich die "Letzte Zeilennr." immer mehr hoch.

Hallo Kowa,

Danke, das teste ich gerade, mit Zeilen einfügen und Zahlungen splitten.

Andrea

So jetzt ist das ganze schon etwas klarer.

Das Problem scheint hier aber nicht die LastReconLineNo zu sein, sondern "Statement No.". Denn "lastReconLineNo" gilt eigentlich nur pro Bankauszug (Statement No."), d.h. bei einem eingelesenen Bankauszug hast du diese Werte erreicht, das scheint mir nicht normal.

Wenn du es also schaffen solltest, die Auszugsnummer "Statement No." hoch zu zählen, sollte dieses Problem verschwinden, und du musst nichts neu nummerieren.

Gruß, Fiddi

NACHTRAG:
Trage doch im Bankkonto unter "Letzte Kontoauszugsnr." mal einen Wert mit einer Zahl am Ende ein, z.B: 'AZ1'. und dann schau mal ob dein Fehler bei dem Konto weg ist.

Gruß, Fiddi

Hallo Fiddi,

mmh, wo finde ich denn die "letzte Auszugsnummer", wenn Du mir das beschreibst, dann teste ich das auch mal?

Aber es ist nicht das Problem eines Auszuges sondern innerhalb eines Auszuges die Auszugszeilen, die in "Bank Document" beim Einlesen einfließen. Die Tabelle ist eigentlich nur eine Referenz, um die Originaldaten der Bank einsehen zu können.

Danke für die Mühe
Andrea

Also den Eintrag findest du unter 'Finanzmanagement\Bankmanagement\Bankkonten' auf dem Reiter 'Buchen' in "Letzte Kontoauszugsnr."

Dein Fehler kann dann auftreten, wenn in dem Feld kein Wert drin steht, den man hoch zählen kann (also falsch 'AUSZUG', richtig 'AUS00001'). Dann liest du seit Jahren immer mit der gleichen Auszugsnummer ein. Beim Einlesen wird dann die zur Auszugsnr. gehörende letzte Zeile gesucht, und darauf 10000 addiert. Zählst du allerdings die Auszugsnummer hoch, dann findet er keinen letzten Datensatz (weil die Auszugsnummer gehört auch zum Schlüssel), und er fängt wieder bei 0 anzzu zählen, und addiert darauf 10000.

Dein Problem kann allerdings auch auftreten, wenn die Bank in der Datei immer die gleiche Auszugsnummer mitliefert.


Gruß, Fiddi

Hallo Fiddi,

ich habe nachgesehen, da steht nix drin. Ich glaube fast, dass die Codeunit zum Einlesen nicht der Standard ist - aber ich teste es mal aus.

Grüße
Andrea

schreib mal eine '1' rein, nichts kann man nicht zählen

Gruß, Fiddi

*lach*... schon klar

Ich vermute trotzdem, dass hier alles am Standard vorbei maschiert, denn es sind auch keinerlei Standardtabellen für Bankschnittstellen gefüllt. Scheint alles unsere CodeUnit für das Einlesen der MT940 Datei zu machen.

Grüße
Andrea

Hallo Fiddi,

... jetzt habe ich mal in die CodeUnit geschaut.... ist von 2004... und wir haben 2007 gekauft, also irgendeine spezielle Anpassung für diesen Zweck, der am jetzigen Standard vorbei geht (gabs vielleicht damals noch nicht, wie mit so vielen individuellen Anpassungen in Navision).

Gruß
Andrea

Hast du deutsche Addon-DB (erweiterte NAV-DB von MS), hast du Bankimport mit MT940 (Dataport 5001906) schon im NAV-Standard. Der verfährt nach der o.g. Methode (Neuer Auszug- >nächste Zeilennr. =0)
Die normale deutsche DB hat mit Bankimport nichts am Hut, da musst du das selbst machen, oder ein Addon erledigt das für dich

Gruß, Fiddi

Ja, wir haben diesen Dataport 5001906... technisch gesehen haben wir 5.0 SP1.

Dann benutzt du hoffentlich auch 'Finanzmanagement\Bankmanagement\Periodische Aktivitäten\Bankbeleg Import\MT940-Format' . Der Dataport zählt normalerweise auch die Auszugnummer hoch, es sei denn er bekommt eine aus dem Kontoauszug selbst. was bei dir wahrscheinlich passiert, wenn ihr Ihn benutzt.

Gruß, fiddi

Hallo Fiddi,

ja den benutzen wir und dieser Dataport hat die Nummern eben mit 10000 hochgezählt...(zu sehen Importjournal Lfd.Nr. und Auszugszeilen Nr.)

Bank Auszugsnr.Auszugszeilennr. Belegnr. Transaktionsdatum Auszugsbetrag Ausgleichsbetrag Art Valutadatum Importjournal Lfd. Nr.
9460 2011-54 2036864737 11FIRM0028459 18.07.2011 20 20 Bankposten 18.07.2011 2036854737
9460 2011-54 2036874738 11FIRM0028460 18.07.2011 25 25 Bankposten 18.07.2011 2036864738
9460 2011-54 2036884739 11FIRM0028461 18.07.2011 102,26 102,26 Bankposten 18.07.2011 2036874739

Mal sehen, wie Du das jetzt findest??
Andrea

Wenn der nicht verwurschtelt ist, gibt es nur 2 Möglichkeiten:
1. Ihr bekommt immer die gleiche Auszugsnummer.
2. euer Datenvolumen ist so hoch, das ihr pro Auszug mehr als 214000 Zeilen habt.

such doch mal nach im Dataport nach:

Code:

LastReconLineNo := "Statement Line No."

, dort siehst du, das er darüber auch auf die Auszugsnummer filtert, was meiner Vermutung von Oben entspricht

Gruß, Fiddi

habs gefunden...., sagt mir aber so erst einmal nichts (ich bin ja auch keine Navision-Crackerin!)

Code:

WITH BankAccReconLine DO BEGIN
        RESET;
        SETRANGE("Bank Account No.",BankAccRecon."Bank Account No.");
        SETRANGE("Statement No.",BankAccRecon."Statement No.");
        IF FIND('+') THEN
          LastReconLineNo := "Statement Line No."
        ELSE
          LastReconLineNo := 0;
        RESET;
      END;


Ach ja unser Datenvolumen ist nicht so hoch... seit 2007 sind nicht mehr als 210000 Datensätze in Bankbelege...

Schau dir mal die Tabellen 274 (sollte eigentlich leer sein, wenn du fertig bist mit der Bankkontoabstimmung, die du ja regelmäßig machst) und 276 an, evtl. fällt dir dort etwas auf, an den Auszugsnummern, bzw. den Daten die dort enthalten sind.

Gruß, Fiddi

273 steht die Nächste Auszug-Nr. drin und der letzte Saldo
274 ist leer
275 ist voll mit allen bisher verarbeiteten Kontoauszügen
Bank Auszugsnr.Auszug Schluss-Saldo Auszugsdatum Saldo letzter Auszug Auftrags Referenznr.
09450 2011-131 101.357,96 12.07.11 104.705,13 STARTUMS

276 ist auch voll mit allen bisher verarbeiteten Zeilen (weiß zwar nicht warum, da sie letztendlich in Bankbelege dann ja noch einmal drin sind)

Gruß Andrea

Was steht denn in der 274 drin, wenn du importiert hast. mit welcher Zeilennummer fängt der an?

274 fang mit lfd. Nr. 173 an .... und in 276 hört es mit lfd. Nr. 172 auf.... (vorher war das in 10000 Schritten). Ergo holt sich die CodeUnit aus 276 die letzte Nummer.

jetzt in 1 Schritten, da ich in der CoduUnit MT940 dies

Code:

// create BankAccReconLine
WITH BankAccReconLine DO BEGIN
  INIT;
  "Bank Account No." := BankAccRecon."Bank Account No.";
  "Statement No." := BankAccRecon."Statement No.";
  LastReconLineNo := LastReconLineNo + 1;

schon herunter gesetzt habe von 10000 auf 1 in unserer TEST-Datenbank.