[Gelöst] Fehlermeldung: Fibu Buch.-Blattzeile kann nicht g

Hallo Zusammen,

beim Versuch des Verbuchens eines Bankkontoauszuges erhalten wir die Meldung:

"Fibu Buch.-Blattzeile kann nicht gebucht und angewendet werden, da das entsprechende Saldo die MwSt. enthält."

Löschen wir alle Postenausgleiche, dann lässt sich der Auszug verbuchen. Doch das kann nicht die Lösung sein.

Zuletzt geändert von anjaadomeit am 13. Januar 2017 15:45, insgesamt 3-mal geändert.

Herzlich willkommen im Forum!

Aus dem NAV-Standard stammt diese Fehlermeldung nicht, kann also nur von einem Add-on oder einer Individualanpassung kommen, die Supportabteilung des NAV-Partners ist hier der richtige Ansprechpartner.

Herzlich Willkommen im Forum!

Aus dem NAV-Standard stammt diese Fehlermeldung nicht, kann also nur von einem Add-on oder einer Individualanpassung kommen, die Supportabteilung des NAV-Partners ist hier der richtige Ansprechpartner.

Da muss ich dich leider korrigieren,
die Fehlermeldung ist mit einem CU in die NAV 2015 Versionen gekommen (ich meine CU10, bin aber nicht 100% sicher)..
In NAV 2016 ist diese auch seit dem RTM drin.

Die Fehlermeldung kommt aus CU13 "Gen. Jnl.-Post Batch" - Textkonstante "PmtApplnErr".

Wie diese nun generiert wird kann ich leider auf die Schnelle nicht beantworten..

die Fehlermeldung ist mit einem CU in die NAV 2015 Versionen gekommen (ich meine CU10, bin aber nicht 100% sicher)..

Stimmt, die kam mit CU10 für DACH dazu. Es heißt ja eigentlich "der Saldo" (danach hatte ich gesucht) und nicht "das Saldo", aber es steht dort so leider falsch in der Übersetzung in NAV 2015, in NAV 2016 stimmt es.
Ursache dürfte diese Änderung sein:

If you use a profit and loss account as balance account for a payment and have the Adjust for Payment Disc. option activated, the system creates too many VAT entries on unapply in the DACH version.

Da "Adjust for Payment Disc." = "Skonto berichtigen" im DACH-Bereich grundsätzlich immer eingeschaltet sein muss, betrifft das alle derartigen Buchungen mit GuV-Konto als Gegenkonto.

Vielen Dank für die Hinweise! Als Workaround müssen die Kontoauszüge in "Häppchen" verbucht werden - dann kommt die Meldung nicht. Ist schon eine Korrektur in Sicht?

Ist schon eine Korrektur in Sicht?

Wenn mit dieser Zusatzprüfung in bestimmten Szenarien Probleme auftauchen, ist der übliche Weg, das seinem NAV-Partner zu melden, der versucht das dann unter normierten Bedingungen (auf Grundlage der Cronus bzw. Extended Cronus-Mandanten mit Massendaten) zu reproduzieren. Wenn der Fehler auch unter diesen Bedingungen auftritt und sichergestellt ist, dass keine Fehlbedienungen oder fehlerhafte Daten vorliegen, wird dafür dann ein Supportcall bei Microsoft eingereicht.

Eine Korrektur für das schlechte Deutsch der Fehlermeldung kann man natürlich unabhängig davon anfordern .

Es gibt inzw. einen Hotfix von MBS für die Codeunit 13 mit zwei Zeilen (siehe Bild).

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

Danke für den Hinweis. Der dürfte dann wohl auch im nächsten Cumulative Update mit enthalten sein, falls nicht wegen dem anstehenden Jahreswechsel schon vorzeitiger "Redaktionsschluss" war.

Hallo in die Runde,

interessant, dazu habe ich ein Ticket beim Microsoft Support offen: Nr. 115112013400067, Bearbeiter ist Dirk Reeps. Es betrifft tatsächlich nur die DACH-Lokalisierung, was ein wenig widersinnig ist. "Offen" ist auch leider nur halb richtig... unsere Diskussion war zwar gut, das Feedback aus der Entwicklung war aber wenig ermunternd. Ich verfasse gerade eine (englische) Diskussion dazu mit Vorschlägen was man sinnvoll ändern kann.

Zur eigentlichen Ursache: Dieser Code ist jetzt drin um zu verhindern, dass man einen Ausgleich in einer Buchblattbuchung erzeugt, bei dem in der selben Transaktion auch Mehrwertsteuer gebucht wird. Ein Beispielfall wäre ein Dreizeiler:

1. Zeile: Debitor oder Kreditor mit Augleich-mit Belegnummer und Skonto
2. Zeile Bankspesen mit MWSt.
3. Zeile: Gegenbuchung auf Bankkonto

Ja ich weiss, richtig realistisch ist das nicht, geht aber. Wenn man versucht, diesen Ausgleich aufzuheben, wird der Mwst.-Posten der Bankspesen durch die "Ausgleich Aufheben" Funktion mitgezogen und Unfug veranstaltet. Und deswegen soll es jetzt diese neue Prüfung geben. Die aber, sagen wir mal, "suboptimal" funktioniert, vom eigentlichen Kernproblem mal abgesehen.
Der Fall der bei einem Kunden aufgeschlagen ist, war die Bankauszugabstimmung mit mindestens einer Position an Bankspesen, die MwSt.-pflichtig sind. Diese Buchblätter haben eigentlich eine Belegnr. und pro Zeile ein Gegenkonto, und damit auch pro Zeile eine eigene Transaktionsnummer. Sprich: Die neue Prüfung sollte in diesem Fall nicht anschlagen. Tut sie aber auch nach diesem Hotfix.
Das Kernproblem ist, das hier mittels Vorprüfung verhindert werden soll, ein mögliches späteres Problem zu vermeiden. Das aber nicht am Buchungssatz liegt, sondern wie die Buchungsfunktion arbeitet (CalcPmtDiscIfAdjVAT(), Unapply*LedgEntry()). Was man durch ein entsprechendes Redesign der Buchungsfunktion aus der Welt schaffen könnte (und einen gefühlten Stapel anderer Probleme gleich mit).
Ein weiteres Teilproblem sind die bereits erfolgten Buchungen, die zum fehlerhaften Ausgleich Aufheben führen können. So wie es jetzt ist würde sich daran nichts ändern. Mit dem Redesign wäre es wahrscheinlich möglich, auch diese Buchungen korrekt zu behandeln.

LG Jens

Hallo zusammen,

mit CU 15 wurde der Fix übernommen.....
Nur leider an einer anderen Stelle und dort funktioniert es nicht *peinlich*

VG

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

Der deutsche Text der Fehlermeldung wurde in CU 15 geändert, der englische ist unverändert.
Nun lautet die Fehlermeldung wie folgt:

Die Fibu Buch.-Blattzeile kann nicht gebucht und der Ausgleich kann nicht vorgenommen werden, da das entsprechende Ausgleichskonto MwSt. enthält.

PmtApplnError.png

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

@jglathe:

Gibts schon was neues zu dem Thema?

Gruß Fiddi

Moin,

Gibts schon was neues zu dem Thema?

naja nicht wirklich. Mein "Hotfix" für dieses Problem war, die Prüfung aus CU13 zu entfernen. An meiner Diskussion konnte ich noch nicht weiterarbeiten. Bisher wars ein eher typischer Januar - also etwas unuhiger

Vielleicht ganz kurz wieso ich die Prüfung entfernt habe:

1. Das Problem ist nicht neu.
2. Die Prüfung ist viel zu breit angesetzt und liefert eigentlich nur "false positives".
3. Die Prüfung ist nur in der DACH-Version drin. Andere Länder haben das Problem also weiterhin

Um das Problem nachhaltig zu korrigieren, müsste man entweder:

- die Ausgleichsfunktion "umdrehen", im Sinne von Ausgleich erzeugt erst die Detailposten und dann aus den Detailposten alle Sachposten, und dabei dann (wie bei einer Buchblattbuchung eines Sachkontos) die MwSt.-Posten. Das ist aber ein heftiges Refactoring, und wird ziemlich sicher nicht beim ersten Release komplett funktionieren. Interessant ist, das für diesen Weg die nötigen Felder bereits seit langem in der Datenbank sind. Aber anscheinend traut sich keiner ran das Skonto-Geraffel nachhaltig zu ändern. Es würde aber auch alle Altfälle mit abdecken, soweit ich das sehen konnte.

oder:

- Ausgleichstransaktionen als solche kennzeichnen, und diese Ausgleichstransaktionsnummer auch in die MwSt.-Posten mitschreiben. Dann kann man sie eindeutig selektieren ohne die Ausgleichs/Skontofunktion umzudrehen, und das Problem beim Ausgleich Aufheben wäre gelöst. Interessanter weise ist auch für diesen Lösungsansatz schon ein Feld in den Detailposten da (Application No.), nur nicht in den MwSt.-Posten. Da aber alle zusätzlichen MwSt.-Posten während einer Skonto Ausgleichstransaktion entstehen und die selbe Ausgleichstransaktionsnummer haben, wäre es kein Problem das man nicht weiss von welchem Detailposten diese denn erzeugt wurden - man kann CalcPmtDiscIfAdjVAT() einfach die für den Ausgleich vergebene gesonderte Transaktionsnummer mitgeben und gut ist.
Nachteil: Bei dieser Lösung wären die Altfälle nicht automatisch gelöst. Man könnte aber bei den unklaren Fällen das Ausgleich Aufheben verbieten (wäre ja schonmal was).

Tjo. Danke fürs nachfragen, das werde ich in der Diskussion so ergänzen und bei Microsoft einreichen.

LG Jens

Hallo,

ein Update zu diesem Thema: Wir haben die Diskussion bei Microsoft eingereicht, und auch einen Fix entwickelt, die Reaktion von Microsoft war aber eher wie immer. Der Fix lebt jetzt in unserem AddOn P/4 BuildingBlocks weiter und macht soweit wir sagen können keine Probleme. Er ist etwas umfangreicher; wir haben uns entschieden zur Sicherstellung der Unterscheidbarkeit von Ausgleichen und sonstigen in der selben Transaktion vorhandenen Posten eine Ausgleichstransaktionsnummer zu vergeben, die nur in den am Ausgleich beteiligten Posten gefüllt ist. Damit kann man beim Ausgleich Aufheben den Ausgleich eindeutig vom Rest abtrennen und die Prüfung in CU13 wird überflüssig.

LG Jens

Der Fix lebt jetzt in unserem AddOn P/4 BuildingBlocks weiter und macht soweit wir sagen können keine Probleme.

Wir setzen bei uns im Unternehmen z.Zt. noch NAV 2013 ein. Unsere Buchhaltung hat nun leider genau das gleiche Problem, also kein gleichzeitiges Verbuchen von Sachposten und Debitoren/Kreditorenposten wg. besagter Fehlermeldung. Wäre es denn für Dich ggf. möglich, Euren Fix zur Verfügung zu stellen? Ich würde nur sehr ungern den weiter oben genannten Hotfix verwenden wollen, da ich nicht ganz abschätzen kann, welche anderen Probleme dieser evtl. verursacht.

Vielen Dank im Voraus!

VG Alex

Hallo al3x,

Wäre es denn für Dich ggf. möglich, Euren Fix zur Verfügung zu stellen? Ich würde nur sehr ungern den weiter oben genannten Hotfix verwenden wollen, da ich nicht ganz abschätzen kann, welche anderen Probleme dieser evtl. verursacht.
VG Alex

ich habe nachgeschaut: P4BB für NAV2013 haben wir noch nicht, wollte bisher keiner :) Das Erstellen ist dann schon Aufwand, nur den einen Fix rüberzunehmen auch - der ist auf NAV2016 entstanden, durch das Refactoring ab NAV2013R2 ist es dann trotz Mercurial aufwendig ein Rebase zu machen. Da wie hier diskutiert die Ursache in der W1 auch nicht behoben ist, wäre meine Empfehlung eher, die Prüfung in CU13 herauszunehmen. Diese kam mit CU #27 dazu, es gibt nur eine weitere kleine Änderung in CU #29, alle anderen bis CU #36 sind nochmal Änderungen an der Steuerprüfung. Soll heissen: Man nimmt sich die CU13 aus dem CU #24, und fügt wenn man möchte noch die Änderung aus CU #29 hinzu, und schon hat man das Problem wie die Jahre davor auch, nur eben ohne diese komische Prüfung die nicht wirklich funktionert.

LG Jens

Hallo Jens,

vielen Dank erstmal für Deine Rückmeldung. Ich werde mir das morgen dann nochmal genauer anschauen und wahrscheinlich dann so zusammenmergen, wie Du vorgeschlagen hast. Kann man nur hoffen, dass MS hier noch einmal nachbessert in Zukunft.

Danke und VG
Alex

Hallo Alex,

Kann man nur hoffen, dass MS hier noch einmal nachbessert in Zukunft.

kann man. Muss man aber nicht Das war bisher eine frustrierende Erfahrung. Schon der Ansatz, nicht das eigentliche Problem zu lösen, sondern Buchungen, die zu dem Problem führen können, zu unterbinden, ist interessant.

LG Jens

Hallo Zusammen,

ich habe die Fehlermeldung jetzt auch in einer NAV 2016 Umgebung Gibt es da schon einen Fix von MS oder bleibt es bei der selbstgestrickten Lösung (Code rausnehmen)?

Danke und LG
Anke