Kontenplan

Wenn man für einen Debitor ein Konto 11001 anlegt, dann wird das zwischen 1100 und 1101 einsortiert. Heißt das, dass dann die Summe des Konto 1199 (1100..1199) auch die Werte von 11001 einschließt?

Wenn ja wie umgeht man das?

Hallo,

wenn das Konto in der Ansicht so einsortiert ist, dann wird wirklich alles dazwischen aufsummiert.

Umgehen kann man das nur, in dem man vor den anderen beiden Konten eine Null vorsetzt.

Die Sortierung wäre dann wie folgt:

01101
01101
11001

Das bedeutet aber, dass man allen 4stelligen Konten eine Null vorsetzen muss.

Das ist ja gar nicht gut. Dann mußte je der ganze Kontenplan geändert werden. Da es aber ja wohl kein rein nummerisches Feld ist (sonst würde ja richtig sortiert) könnte ich doch auch alphanummerische Werte eingeben, wie z. B. D11001. Spricht da was dagegen, außer der erhöhten Fehleranfälligkeit beim Buchen durch den User.

Das sollte kein Problem sein, da es ein Feld vom Typ "Code" ist. Das erklärt auch die unglückliche Sortierung.
Ich würde allerdings, um eine gewisse Konsistenz zu haben, entweder den Vorschlag von Watchdog nehmen, oder mir einen 4Stelligen Bereich im Kontenplan suchen für die Konten der Debitoren (natürlich wenn Platz ist)

Oder du machst für die Summe ein 1100..11000|11999..1199 (frag mich gerade ob das geht...keine Ahnung)

Das ist ja wahnsinnig viel Arbeit - und saumäßig gefährlich. Das bedeutet nämlich, dass Konto 0027 ein ganz anderes Konto als 27 ist (ja, ich habe es geht). Zu allem Überfluß steht dann 27 mal 200 Zeilen unter 0027. Gibt es dann da keinen Trick dass idotensicher(er) zu machen?

Wie gesagt, das ist ein Code Feld. D.h. die 27 ist nur eine Zeichenfolge, die mit Nummern nicht wirklich was zu tun hat. Da könnte auch AB stehen, wo man nicht auf die Idee kommen würde, dass 00AB das selbe ist.

Mhh, ich habe mir das noch mal überlegt und an sich ist die Idee mit dem "D" vor der Nummer gar nicht verkehrt.
Dann stehen die alle gesammelt hinter dem "normalen" Konten.

Mhh, ich habe mir das noch mal überlegt und an sich ist die Idee mit dem "D" vor der Nummer gar nicht verkehrt.
Dann stehen die alle gesammelt hinter dem "normalen" Konten.

Ich hab mir das auch nochmal überlegt und finde das mit dem D davor überhaupt nicht mehr gut. Welchem Buchhalter kann man klar machen, dass er zum Erfassen von Belegen die komplette Tastatur braucht und nicht nur den Ziffernblock.

Hallo vsnase,

ich verstehe nicht so ganz, warum du einen Debitorenkonto in den SACHKONTENrahmen integrieren möchtest.

Das hat doch da garnichts zu suchen.

So würdest Du dir doch auch bei Buchen in den FibuBuchblättern die Möglichkeit der Unterscheidung zw. Sachkonten, Debitoren und Kreitoren nehmen. Du würdest ja nur zw. Sachkonten buchen.

Ohne es probiert zu haben, fürchte ich, das du damit auch MwSt - Automatiken aushebelst.

Vmtl. hast Du einen guten Grund dies so zu machen. Ich komme nur nicht drauf.

Grüsse
ToKi

Hallo vsnase,

ich verstehe nicht so ganz, warum du einen Debitorenkonto in den SACHKONTENrahmen integrieren möchtest.

Das hat doch da garnichts zu suchen.

Ich glaube wir reden aneinander vorbei. Ich möchte für einen Debitor ein Konto (Forderungskonto) anlegen. Schema sollte z. B. sein 10XXX sind inländische, 11XXX sind ausländische Debitoren.

Ich sehe nicht, dass damit die MWSt.-Automatik ausgehebelt wird, lediglich das Forderungskonto hat eine andere Bezeichnung (z. B. 11001 statt 1402 für einen ausländischen Debitor).

Dumm ist halt dass das feld für die Kontenbezeichnung kein nummerisches Feld ist und deshalb das Konto in den Plan falsch einsortiert wird (bei normalerweise 4-stelligen Kontonummern). Was wiederum zum Problem mit den Summen der Kontengruppen wird, da 11001 zwischen 1100 und 1101 einsortiert wird.

Hi vsnase,

okay Du hast Recht wir reden aneinander vorbei.

Wenn ich Dich Recht verstehe willst Du nicht die Forderungssammelkonten im 14xx Bereich (SKR03) benutzen, sondern für jeden Debitor ein eigenes Forderungskonto anlegen.
Dazu willst Du dann den Personenkontenbereich 10000... verwenden, weil Du ja im 4stelligen Bereich kaum genug Platz finden wirst.

Okay, habe ich so noch nicht gesehen.
Klingt spannend ist aber recht speziell.
Wie sorgst Du dafür, dass wenn Du eine RG auf einen Debitor buchst die Forderung automatisch auf das entspechende Forderungskonto gebucht wird ?

Bzgl. der Sortierung fällt mir auch nichts neues ein, was Dir helfen könnte.
Nur der Hinweis, dass das:
"Oder du machst für die Summe ein 1100..11000|11999..1199 frag mich gerade ob das geht...keine Ahnung)"
durchaus so geht.
Das sieht aber nach viel Handarbeit aus.

Grüsse
ToKi

Dazu willst Du dann den Personenkontenbereich 10000... verwenden, weil Du ja im 4stelligen Bereich kaum genug Platz finden wirst.

Okay, habe ich so noch nicht gesehen.
Klingt spannend ist aber recht speziell.
Wie sorgst Du dafür, dass wenn Du eine RG auf einen Debitor buchst die Forderung automatisch auf das entspechende Forderungskonto gebucht wird ?

Also so speziell nicht. Ich kenne da einige die das so machen. Die richtige Zuordnung ist halt nur über eine entsprechene Buchungsmatrix zu lösen, was natürlich auch wieder Aufwand bedeutet.

Okay, wenn der Kunde das so möchte und bezahlt, warum auch nicht.

Das würde doch aber bedeuten, dass Du für jedem Debitor eine Debitorenbuchungsgruppe in der Martix machen musst, oder ?

Was ist den eigentlich der Vorteil davon, dass ich die Forderungen nach Debitor aufgesplittet in der Bilanz stehen habe ?
Mach die Bilanz ja nur länger.
Und im Anhang der Bilanz steht ja eh eine Liste der Debitoren mit den offenen Posten. Also das selbe nochmals.

Einziger Vorteil, den ich sehe ist der, dass wenn ich die Sachkonten aufrufe ich auch gleich sehen würde, welche offenen Forderungen noch auf den Konten der Debiitoren stehen.
Dazu müsste man im Standard NAV/ENT aber auch nur die Debitorenliste zusätzlich aufrufen.

Grüsse
ToKi

Hallo.

Ich habe eine Lösung für das Problem entwickelt.

Filter wie folgt:

Früherer Filter zum Beispiel:

100..500|600|700..1000|1601..1607

Um jetzt keine Probleme mehr mit der SQL Sortierung zu haben, ist der neue Filter so:

(100..500&???)|(600&???)|(700..999$???)|(1000&????)|(1601..1607&????)

Dieser Filter gibt das Richtige Ergebnis aus. Allerdings kommt die Anzeige von Tabellen damit nicht so 100% klar.

Am besten nur im Code für Filterungen bei Berichten nehmen.


Ciao