Hallo,
die Buchungsregel sieht mit Buchungsart = 8 im Buchungsbereich 2 einen Ausgleich vor. Während der Interpretation des Kontoauszugs gilt es, den/die offenen Posten zu finden un zuzuweisen, die mit dem aktuellen Posten im Auszug ausgeglichen werden sollen.
Die Meldung deutet darauf hin, dass mind.ein offener Posten gefunden wurde, das System versucht den Ausglich vorzunehmen scheitert aber daran dass der/die auszugleichenden Posten einen anderen Betrag als der Auszugsposten haben.
Dafür kann es ja unterschiedliche Gründe geben:
- Zuordnung der offenen Posten in der Auszugsverarbeitung falsch (es werden z.B. zu viele OP's gefunden)
- es sind die richtigen OP's aber es liegt wirklich eine Minderzahlung/Mehrzahlung vor und die Differenz (+/-) ist grösser als in der Toleranzgruppe festgelegt
- der Betrag mag stimmen, aber SAP denkt die Zahlung wäre skontorelevant und nach Abzug des Skontobetrags stimmt der Betrag doch nicht (oder umgekehrt: bezahlt wurde mit Skonto, aber SAP denkt hier ist kein Skonto zulässig und erwartet daher den vollen Betrag)
- Zahlung erfolgt in einer anderen Währung und durch die unterschiedlichen Kurse sind die Beträge (ausgedrückt in der Ausgleichswährung) unterschiedlich. (etwa Rechnung in USD, bezahlt wird in USD/F110, aber von einem EUR-Bankkonto --> Kontoauszug weist nur den EUR-Betrag aus. Hier sollte im Posten einen Hinweis auf den OCMT-Betrag und -Währung, also eben USD, stehen; wenn vorhanden, muss diese Info ausgewertet werden, dann wird im BuBer 1 in EUR (Kontowhrung), aber im BuBer 2 (Nebenbuch) in USD (OCMT-Währung) gebucht und bei dem richtigen Zahlungsbetrag sind höchstens Kursdifferenzen in HW zu erwarten, dier aber problemlos ausgebucht werden sollen und nicht zu dieser Fehlermeldung führen
Was im konkreten Fall das Problem ist, erfährt man am einfachsten wenn man in dieTransaktion FEBAN geht, dort den Kursor auf den Posten setzt, dann im Menü den Buchungsmodus auf "im Vordergrund" ändert, und schliesslich das Button "Buchen" (Diskette) drückt. Das wird die Verbuchung im Online-Modus (wie Batch-Input) starten.
Hier soll man folgendes beachten (für den Beleg im BuBer 2, ich gehe davon aus das BuBer 1 bereits erledigt ist):
- Was ist Belegwährung? Haben die OP's die ausgeglichen werden wollen die selbe Blegwährung? Wenn nicht, liegt das OCMT-Problem vor. Kontoauszug wird niocht richtig verarbeitet.
- Welche OP's will SAP ausgleichen? Das erfährt man indem man ins Bild "OP's bearbeiten" geht. Es könnte sein dass die Batch-Input dieses Bild nicht enthält, aber nachdem der Fehler gekommen ist, kann man doch wie gewohnt zu dem Bild gehen und sich dort die zugeordneten OP's ansehen. Wenn es nicht die richtigen OP's sind (etwa zu viele, sogar ALLE OP's des Debitoren), dann ist wiederum die Interpretation des Kontoauszugs nicht korrekt.
- Was ist der Zahlungsbetrag? Welche OP's geben diesen Zahlungsbetrag her? (die Fälle "mit Skonto" und "ohne SKonto" sollen beide berücksichtigt werden, man weiss ja nicht was der Debitor im Kopf hatte - SAP könnte hier eine andere Meinung sein. Ggf. Verwendungszweck und/oder Zahlungsavis, vom Debitoren erhalten, heranziehen). Wenn die ausgewählten OP's zwar die richtigen sind, aber der Zahlungsbetrag nicht stimmt, kann es an den unterschiedlichen Interpretation des Skontorechts durch den Debitoren vs., durch SAP liegen.
- Was ist der Differenzbetrag (in Ausgleichswährung)? Wenn es ein relativ kleiner Betrag ist, könnte man noch die Toleranzgruppe im Debitorenstamm prüfen: ist die etwa nicht viel zu streng? Sollten wir nicht kleinere Zahlungsdifferenzen einfach hinnehmen? Man kann in diesem konkreten Fall die Differenz ja auch manuell ausbuchen (noch in der Batch-Input aus der FEBAN).
Man kann den konkreten Beleg auf jeden Fall verbuchen wenn man FEBAN mit Buchungsmodus Vordergrund startet. Wenn sich das Problem immer wieder meldet, dann sollten die Einstellungen zur Kontoauszugsverarbeitung / Toleranzgruppe / Zahlungsbedingung (macht Skonto überhaupt Sinn bei diesem Debitor?) überprüft und ggf. angepasst werden.
Ich hoffe das hilft Dir weiter,
viele Grüße
frakk
die Buchungsregel sieht mit Buchungsart = 8 im Buchungsbereich 2 einen Ausgleich vor. Während der Interpretation des Kontoauszugs gilt es, den/die offenen Posten zu finden un zuzuweisen, die mit dem aktuellen Posten im Auszug ausgeglichen werden sollen.
Die Meldung deutet darauf hin, dass mind.ein offener Posten gefunden wurde, das System versucht den Ausglich vorzunehmen scheitert aber daran dass der/die auszugleichenden Posten einen anderen Betrag als der Auszugsposten haben.
Dafür kann es ja unterschiedliche Gründe geben:
- Zuordnung der offenen Posten in der Auszugsverarbeitung falsch (es werden z.B. zu viele OP's gefunden)
- es sind die richtigen OP's aber es liegt wirklich eine Minderzahlung/Mehrzahlung vor und die Differenz (+/-) ist grösser als in der Toleranzgruppe festgelegt
- der Betrag mag stimmen, aber SAP denkt die Zahlung wäre skontorelevant und nach Abzug des Skontobetrags stimmt der Betrag doch nicht (oder umgekehrt: bezahlt wurde mit Skonto, aber SAP denkt hier ist kein Skonto zulässig und erwartet daher den vollen Betrag)
- Zahlung erfolgt in einer anderen Währung und durch die unterschiedlichen Kurse sind die Beträge (ausgedrückt in der Ausgleichswährung) unterschiedlich. (etwa Rechnung in USD, bezahlt wird in USD/F110, aber von einem EUR-Bankkonto --> Kontoauszug weist nur den EUR-Betrag aus. Hier sollte im Posten einen Hinweis auf den OCMT-Betrag und -Währung, also eben USD, stehen; wenn vorhanden, muss diese Info ausgewertet werden, dann wird im BuBer 1 in EUR (Kontowhrung), aber im BuBer 2 (Nebenbuch) in USD (OCMT-Währung) gebucht und bei dem richtigen Zahlungsbetrag sind höchstens Kursdifferenzen in HW zu erwarten, dier aber problemlos ausgebucht werden sollen und nicht zu dieser Fehlermeldung führen
Was im konkreten Fall das Problem ist, erfährt man am einfachsten wenn man in dieTransaktion FEBAN geht, dort den Kursor auf den Posten setzt, dann im Menü den Buchungsmodus auf "im Vordergrund" ändert, und schliesslich das Button "Buchen" (Diskette) drückt. Das wird die Verbuchung im Online-Modus (wie Batch-Input) starten.
Hier soll man folgendes beachten (für den Beleg im BuBer 2, ich gehe davon aus das BuBer 1 bereits erledigt ist):
- Was ist Belegwährung? Haben die OP's die ausgeglichen werden wollen die selbe Blegwährung? Wenn nicht, liegt das OCMT-Problem vor. Kontoauszug wird niocht richtig verarbeitet.
- Welche OP's will SAP ausgleichen? Das erfährt man indem man ins Bild "OP's bearbeiten" geht. Es könnte sein dass die Batch-Input dieses Bild nicht enthält, aber nachdem der Fehler gekommen ist, kann man doch wie gewohnt zu dem Bild gehen und sich dort die zugeordneten OP's ansehen. Wenn es nicht die richtigen OP's sind (etwa zu viele, sogar ALLE OP's des Debitoren), dann ist wiederum die Interpretation des Kontoauszugs nicht korrekt.
- Was ist der Zahlungsbetrag? Welche OP's geben diesen Zahlungsbetrag her? (die Fälle "mit Skonto" und "ohne SKonto" sollen beide berücksichtigt werden, man weiss ja nicht was der Debitor im Kopf hatte - SAP könnte hier eine andere Meinung sein. Ggf. Verwendungszweck und/oder Zahlungsavis, vom Debitoren erhalten, heranziehen). Wenn die ausgewählten OP's zwar die richtigen sind, aber der Zahlungsbetrag nicht stimmt, kann es an den unterschiedlichen Interpretation des Skontorechts durch den Debitoren vs., durch SAP liegen.
- Was ist der Differenzbetrag (in Ausgleichswährung)? Wenn es ein relativ kleiner Betrag ist, könnte man noch die Toleranzgruppe im Debitorenstamm prüfen: ist die etwa nicht viel zu streng? Sollten wir nicht kleinere Zahlungsdifferenzen einfach hinnehmen? Man kann in diesem konkreten Fall die Differenz ja auch manuell ausbuchen (noch in der Batch-Input aus der FEBAN).
Man kann den konkreten Beleg auf jeden Fall verbuchen wenn man FEBAN mit Buchungsmodus Vordergrund startet. Wenn sich das Problem immer wieder meldet, dann sollten die Einstellungen zur Kontoauszugsverarbeitung / Toleranzgruppe / Zahlungsbedingung (macht Skonto überhaupt Sinn bei diesem Debitor?) überprüft und ggf. angepasst werden.
Ich hoffe das hilft Dir weiter,
viele Grüße
frakk
