[Gelöst] Zahlung vor Rechnung

@Trollmama:

Wenn du es nicht glaubst:

Code:

ValidateApplyRequirements(TempGenJnlLine : TEMPORARY Record "Gen. Journal Line")
IF (TempGenJnlLine."Bal. Account Type" = TempGenJnlLine."Bal. Account Type"::Customer) OR
  (TempGenJnlLine."Bal. Account Type" = TempGenJnlLine."Bal. Account Type"::Vendor)
THEN
  ExchAccGLJnlLine.RUN(TempGenJnlLine);

IF (TempGenJnlLine."Document Type" = TempGenJnlLine."Document Type"::Payment) OR
  (TempGenJnlLine."Document Type" = TempGenJnlLine."Document Type"::Refund)
  THEN

  IF TempGenJnlLine."Account Type" = TempGenJnlLine."Account Type"::Customer THEN BEGIN
    IF TempGenJnlLine."Applies-to ID" <> '' THEN BEGIN
      CustLedgEntry.SETCURRENTKEY("Customer No.","Applies-to ID",Open);
      CustLedgEntry.SETRANGE("Customer No.",TempGenJnlLine."Account No.");
      CustLedgEntry.SETRANGE("Applies-to ID",TempGenJnlLine."Applies-to ID");
      CustLedgEntry.SETRANGE(Open,TRUE);
      IF CustLedgEntry.FIND('-') THEN
        REPEAT
          IF (TempGenJnlLine."Posting Date" < CustLedgEntry."Posting Date") THEN
            ERROR(
              Text015,TempGenJnlLine."Document Type",TempGenJnlLine."Document No.",
              CustLedgEntry."Document Type",CustLedgEntry."Document No.");
        UNTIL CustLedgEntry.NEXT = 0;
    END ELSE IF TempGenJnlLine."Applies-to Doc. No." <> '' THEN BEGIN
      CustLedgEntry.SETCURRENTKEY("Document No.","Document Type","Customer No.");
      CustLedgEntry.SETRANGE("Document No.",TempGenJnlLine."Applies-to Doc. No.");
      IF TempGenJnlLine."Applies-to Doc. Type" <> TempGenJnlLine."Applies-to Doc. Type"::" " THEN
        CustLedgEntry.SETRANGE("Document Type",TempGenJnlLine."Applies-to Doc. Type");
      CustLedgEntry.SETRANGE("Customer No.",TempGenJnlLine."Account No.");
      CustLedgEntry.SETRANGE(Open,TRUE);
      IF CustLedgEntry.FIND('-') THEN
        IF (TempGenJnlLine."Posting Date" < CustLedgEntry."Posting Date") THEN
          ERROR(
            Text015,TempGenJnlLine."Document Type",TempGenJnlLine."Document No.",
            CustLedgEntry."Document Type",CustLedgEntry."Document No.");
    END;
  END ELSE IF TempGenJnlLine."Account Type" = TempGenJnlLine."Account Type"::Vendor THEN BEGIN
    IF TempGenJnlLine."Applies-to ID" <> '' THEN BEGIN
      VendLedgEntry.SETCURRENTKEY("Vendor No.","Applies-to ID",Open);
      VendLedgEntry.SETRANGE("Vendor No.",TempGenJnlLine."Account No.");
      VendLedgEntry.SETRANGE("Applies-to ID",TempGenJnlLine."Applies-to ID");
      VendLedgEntry.SETRANGE(Open,TRUE);
        REPEAT
          IF (TempGenJnlLine."Posting Date" < VendLedgEntry."Posting Date") THEN
            ERROR(
              Text015,TempGenJnlLine."Document Type",TempGenJnlLine."Document No.",
              VendLedgEntry."Document Type",VendLedgEntry."Document No.");
        UNTIL VendLedgEntry.NEXT = 0;
      IF VendLedgEntry.FIND('-') THEN BEGIN
      END;
    END ELSE IF TempGenJnlLine."Applies-to Doc. No." <> '' THEN BEGIN
      VendLedgEntry.SETCURRENTKEY("Document No.","Document Type","Vendor No.");
      VendLedgEntry.SETRANGE("Document No.",TempGenJnlLine."Applies-to Doc. No.");
      IF TempGenJnlLine."Applies-to Doc. Type" <> TempGenJnlLine."Applies-to Doc. Type"::" " THEN
        VendLedgEntry.SETRANGE("Document Type",TempGenJnlLine."Applies-to Doc. Type");
      VendLedgEntry.SETRANGE("Vendor No.",TempGenJnlLine."Account No.");
      VendLedgEntry.SETRANGE(Open,TRUE);
      IF VendLedgEntry.FIND('-') THEN
        IF (TempGenJnlLine."Posting Date" < VendLedgEntry."Posting Date") THEN
          ERROR(
            Text015,TempGenJnlLine."Document Type",TempGenJnlLine."Document No.",
            VendLedgEntry."Document Type",VendLedgEntry."Document No.");
    END;
  END;

Zoom der Rechnung, aaaaber: ich habe das jetzt nochmals probiert, und auch bei mir ging es nun (*ich blick's selber nicht mehr):
Feld Feldname Wert
Lfd. Nr. Entry No. 2903
Debitorennr. Customer No. 10000
Buchungsdatum Posting Date 19.07.07
Belegart Document Type Rechnung
Belegnr. Document No. G02008
Beschreibung Description Möbel-Meller KG
Währungscode Currency Code
Betrag Amount 116
Restbetrag Remaining Amount 0
Ursprungsbetrag (MW) Original Amt. (LCY) 0
Restbetrag (MW) Remaining Amt. (LCY) 0
Betrag (MW) Amount (LCY) 0
Verkauf (MW) Sales (LCY) 100
DB (MW) Profit (LCY) 0
Rechnungsrabatt (MW) Inv. Discount (LCY) 0
Verk. an Deb.-Nr. Sell-to Customer No. 10000
Debitorenbuchungsgruppe Customer Posting Group INLAND
Kostenstelle Code Global Dimension 1 Code VERKAUF
Kostenträger Code Global Dimension 2 Code
Verkäufercode Salesperson Code PS
Benutzer-ID User ID
Herkunftscode Source Code ZLGEINBUBL
Abwarten On Hold
Ausgleich mit Belegart Applies-to Doc. Type
Ausgleich mit Belegnr. Applies-to Doc. No.
Offen Open Nein
Fälligkeitsdatum Due Date 19.08.07
Skontodatum Pmt. Discount Date 27.07.07
Urspr. Skonto möglich Original Pmt. Disc. Possible 2,32
Skonto gewährt (MW) Pmt. Disc. Given (LCY) 0
Positiv Positive Ja
Geschlossen von Lfd. Nr. Closed by Entry No. 0
Geschlossen am Closed at Date
Geschlossen mit Betrag Closed by Amount 0
Ausgleichs-ID Applies-to ID
Buch.-Blattname Journal Batch Name ALLGEMEIN
Ursachencode Reason Code
Gegenkontoart Bal. Account Type Sachkonto
Gegenkontonr. Bal. Account No. 6110
Transaktionsnr. Transaction No. 216
Geschlossen mit Betrag (MW) Closed by Amount (LCY) 0
Sollbetrag Debit Amount 0
Habenbetrag Credit Amount 0
Sollbetrag (MW) Debit Amount (LCY) 0
Habenbetrag (MW) Credit Amount (LCY) 0
Belegdatum Document Date 19.07.07
Externe Belegnummer External Document No.
Zins berechnen Calculate Interest Nein
Abschlusszinsen berechnet Closing Interest Calculated Nein
Nummernserie No. Series ZE-BUCHBL
Geschlossen von Währungscode Closed by Currency Code
Geschlossen mit Währungsbetrag Closed by Currency Amount 0
Regul. Währungsfaktor Adjusted Currency Factor 1
Urspr. Währungsfaktor Original Currency Factor 1
Ursprungsbetrag Original Amount 116
Restskonto möglich Remaining Pmt. Disc. Possible 0
Skontotoleranzdatum Pmt. Disc. Tolerance Date 27.07.07
Max. Zahlungstoleranz Max. Payment Tolerance 0
Letzte registrierte Mahnstufe Last Issued Reminder Level 0
Akzeptierte Zahlungstoleranz Accepted Payment Tolerance 0
Akzeptierte Skontotoleranz Accepted Pmt. Disc. Tolerance Nein
Zahlungstoleranz (MW) Pmt. Tolerance (LCY) 0
Ausgleichsbetrag Amount to Apply 0
IC-Partnercode IC Partner Code
Ausgleichsposten Applying Entry Nein
Storniert Reversed Nein
Storniert durch Lfd. Nr. Reversed by Entry No. 0
Stornierter Posten Lfd. Nr. Reversed Entry No. 0

@forki:
Aaaalso - da steht aber nicht, dass man nicht mit ælteren Posten ausgleichen darf - sondern nicht mit einem JUENGEREN...
"...IF (TempGenJnlLine."Posting Date" < CustLedgEntry."Posting Date") THEN
ERROR( Text015,TempGenJnlLine."Document ..."

--> heisst, wenn mein Datum in der aktuellen Buch.-Blattzeile kleiner (also ælter) ist als das des auszugleichenden Postens, dann kommt die Fehlermeldung.
Und das ist vøllig korrekt so.
Denn:
Zu dem Datum des ausgleichenden Postens (also der aktuellen Buchblattzeile) wird dann næmlich auch der offene Posten geschlossen. Und das wære nicht korrekt, wenn der auszugleichende Posten ein juengeres Datum hat.
Beispiel:
Zuerst wird eine Rechnung gebucht zum 2.1.2007.
Danach wird eine Zahlung gebucht zum 28.12.2006.
Wenn ich jetzt bei der Zahlung den Ausgleich mit der Rechnung direkt zulassen wuerde, heisst das, dass beide Posten als Datum "geschlossen am" den 28.12.2006 bekommen.
Und das wære falsch.
Ein etwaiges Skonto wuerde bereits zum 28.12.2006 gebucht - obwohl der Erløs erst im Folgejahr eintritt.
Ausserdem stimmt dann auch die OP-Liste per 31.12.2006 nicht, weil da ja der Posten vom 28.12.2006 noch offen sein muss.
In so einem Fall - und das kann ja durchaus vorkommen - muss man dann eben in den Debitoren und dort den Ausgleich manuell vornehmen (in dem man sich auf den juengsten Posten stellt und von da aus ausgleicht).

Nur war das ja nicht Thommes sein Problem - denn so wie er das beschrieben hat, wird zuerst die Zahlung mit Datum 15.7. gebucht und anschliessend die Rechnung mit Datum 17.7. und der Ausgleich gesetzt.
Bei der folgenden Abfrage (s.o.) kann das System eigentlich nicht auf den Fehler stossen...
Næmlich:
IF (TempGenJnlLine."Posting Date"[17.7.] < CustLedgEntry."Posting Date"[15.7.]) --> wird ein FALSE zurueckgeben und der Error wird nicht durchlaufen...

Nur, wenn es von der Reihenfolge her umgedreht gemacht wird:
also erst das Buchen der Rechnung mit Buchungsdatum 17.7. und DANACH das Buchen des z.B. Kontoauszuges mit der Zahlung mit Buchungsdatum 15.7. und gleichzeitigem Ausgleich der Rechnung: das geht nicht. Und das ist auch gut so...

Ich hoffe, das war jetzt nicht zuuuu verwirrend.

Viele Gruesse!


Ach @Thommes: mir ist aufgefallen, dass in deinem Zoom die beiden Felder "Ausgleich mit Belegart" und "Ausgleich mit Belegnr." gar nicht gefuellt waren???

@forki: DOCH, Du hast das Problem auf den Punkt getroffen. Microsoft hat das damals mit dem möglichen Skontoproblem begründet. Da es anscheinend keine andere Lösung gibt, als die Belege dann danach auszugleichen, werde ich diesen Eintrag nun als [gelöst] kennzeichnen.
Grüße @ all
thommes.

@forki: DOCH, Du hast das Problem auf den Punkt getroffen. Microsoft hat das damals mit dem möglichen Skontoproblem begründet. Da es anscheinend keine andere Lösung gibt, als die Belege dann danach auszugleichen, werde ich diesen Eintrag nun als [gelöst] kennzeichnen.
Grüße @ all
thommes.

nochmal: diese Fehlermeldung kommt NUR dann, wenn das Datum der Buchung in der Buch.-Blattzeile kleiner (also ælter) ist als der auszugleichende Posten.
Sprich, wenn deine Buchhalter zuerst die Rechnung zum 17.7. buchen und anschliessend die Zahlung mit Datum 15.7. (weil vielleicht der Kontoauszug eben ein paar Tage spæter kommt...) --> Da klappt der gleichzeitige Ausgleich nicht.
Das ist genau die Stelle, die Forki herausgepickt hat. - Es war nur genau andersherum interpretiert.
Das hatte jetzt also nicht nur mit dem Datum an sich, sondern auch mit der Reihenfolge der Buchungen zu tun.

Aber mit dieser Funktionalitæt hat Microsoft nun sogar eine grosse Fehlerquelle aus dem Weg geræumt. Denn damit duerfte es jetzt auch nicht mehr møglich sein, beim manuellen Ausgleich, auf dem "falschen" Posten zu stehen. Das kam ja schon øfter vor, weil die OP's im Ausgleichsfenster ja nicht nach Datum sortiert sind.....
Klar, und die Auswirkungen waren dann eben: Skonto zum falschen Datum und Schliessen offener Posten zum falschen Datum....
Schøn, dass das jetzt verhindert wird.

Also dann - Viele Gruesse!

@Trollmama:
Also ich dachte es geht die ganze Zeit darum, dass die Zahlung zeitlich vor der Rechnung liegt. So heißt ja auch das Thema. Und das macht meiner Meinung auch durchaus Sinn.

Unsere Kunden bekommen monatlich Rechnungen. Diese werden mit zukünftigen Buchungsdatumswerten gebucht. Manchmal kommen Zahlungen aber früher als die Rechnungen ihr Buchungsdatum haben.
Diese sollen ja aber trotzdem betrachtet werden. Der Ausgleich darf dann natürlich erst zum Buchungsdatum der Rechnung erfolgen - dann stimmt auch das Skonto. Denke ich

Grüße Steffen

@Trollmama:
Also ich dachte es geht die ganze Zeit darum, dass die Zahlung zeitlich vor der Rechnung liegt. So heißt ja auch das Thema. Und das macht meiner Meinung auch durchaus Sinn.
Unsere Kunden bekommen monatlich Rechnungen. Diese werden mit zukünftigen Buchungsdatumswerten gebucht. Manchmal kommen Zahlungen aber früher als die Rechnungen ihr Buchungsdatum haben.
Diese sollen ja aber trotzdem betrachtet werden. Der Ausgleich darf dann natürlich erst zum Buchungsdatum der Rechnung erfolgen - dann stimmt auch das Skonto. Denke ich
Grüße Steffen

Genau.
Der Fall war ja die ganze Zeit so, das die Zahlung vom Buchungsdatum her vor der Rechnung liegt.

Nur macht es eben einen Unterschied, welcher Posten tatsæchlich als erstes eingebucht wird (damit meine ich nicht das Buchungsdatum - sondern welcher Posten physisch zuerst in der Datenbank ist).

Fuer den Fall "Buchungsdatum der Zahlung liegt vor dem Buchungsdatum der Rechnung" gibt es fuer die Erfassung ja 2 Møglichkeiten:

1. Zuerst wird die Zahlung gebucht (z.B. Buchungsdatum 15.7.) - Hinterher wird die Rechnung gebucht mit Buchungsdatum 17.7. - man setzt den Ausgleich auf die Zahlung --> DAS funktioniert und gibt auch keinen Error.

2. Die Rechnung wird bereits vorher gebucht (auch wieder mit Buchungsdatum 17.7.) - Und erst dann die Zahlung (mit Buchungsdatum 15.7.) --> Wenn ich da den Ausgleich auf die Rechnung setzen will, geht das nicht, weil ja dann der OP bereits zum 15.7. geschlossen wuerde.

In beiden Fællen liegt die Zahlung mit dem Buchungsdatum VOR der Rechnung. Aber je nachdem, in welcher Reihenfolge die Dinge gebucht werden - funktioniert es mit dem Ausgleich oder eben nicht.

So, wie du das bei euch beschreibst - verstehe ich so, dass z.B. am Monatsanfang Rechnungen rausgeschickt werden mit z.B. Buchungsdatum am Monatsende. Hier existiert also zuerst der Rechnungs-OP mit einem "spæten" Datum. Wenn jetzt im Laufe des Monats (vor dem Buchungsdatum der Rechnung) die Zahlung kommt, hat die ja dann das "kleinere" Datum. Dann funktioniert das mit dem direkten Ausgleich nicht.
(wie eben im Fall 2)

So wie thommes seinen Fall geschildert hat ("...Kunde überweist am 15.07.07 1000,-- EUR, die Rechnung dazu wird in Navision allerdings erst am 18.07.07 gebucht....") - ist das ja genau andersrum (nicht, was das Buchungsdatum betrifft! - sondern die Reihenfolge) Erst das Buchen der Zahlung und dann irgendwann die Rechnung. Das funktioniert næmlich.

Da haben wir wahrscheinlich bissl aneinander vorbei geredet...

Na denne - ein schønes Wochenende euch allen und vor allem dir, forki eine schøne Feier!!