Erlöskonten Lösungsvorschlag

[Janusch]

Folgendes wurde Überlegt:

für Artikel:

Einführung Warengruppen. Jeder Artikel kann nur einer Warengruppe angehören!

In der Warengruppe werden Erlöskonten pro Steuersatz hinterlegt.
(Steuersätze werden frei definierbar sein)

Folgende Kontenarten sollten dort angegeben werden (korrekte Namen werden noch benötigt!).

Inland
EU
Drittland
Inland-USt
EU-Ust
Rabatt

Es wird eine Globale Einstellung für alle Versandkosten geben:

Inland
EU
Drittland
ermäßigt Inland
ermäßigt EU
Steuerfrei

Der Export der Buchungsdatensätze erfolgt pro Position.

Exportiert werden:

- Alle Rechnungen pro Monat
- Alle bezahlten Rechnungen im Monat

Bitte um Erweiterung... geplannt ab Do.

 

[Alexander]

Der Export der Buchungsdatensätze erfolgt pro Position.

Exportiert werden:

- Alle Rechnungen pro Monat
- Alle bezahlten Rechnungen im Monat

Bitte um Erweiterung... geplannt ab Do.

bitte nicht auf Monat festlegen, datumsabhängig machen von/bis, es gibt Firmen da kommt der Steuerfuzzi mehrmals und will die Buchungsdaten haben, der wird zu vieh, wenn der jedesma auch die bereits verbuchten Rechnungsdaten nochma zu gesicht bekommt

 

[gerhard5302]

...bitte nicht auf Monat festlegen, datumsabhängig machen von/bis, es gibt Firmen da kommt der Steuerfuzzi mehrmals und will die Buchungsdaten haben, der wird zu vieh, wenn der jedesma auch die bereits verbuchten Rechnungsdaten nochma zu gesicht bekommt

*unterschreib* Das sag ich schon lange. Bitte alte und sinnvolle Sachen zuerst umsetzen bevor man wieder neue Baustellen aufreißt.

lg
Gerhard

 

[opti61]

Hi,
schließe mich an - ein monatlicher Export kann nur eine Option sein; wichtig wäre ein Export von - bis ... wie oben gefordert und auf alle Fälle ein einschaltbarer permanenter Export. Dies muss auch für die Kundenkonten gelten. In den globalen Exporteinstellungen muss eine Exportdatei in einem Export-Verzeichnis definiert werden. Beim erfolgten Import in eine Fibu wird diese Datei normalerweise automatisch gelöscht. Also muss die Regel lauten - Datei existiert -> nächste Buchung anhängen; Datei existiert nicht -> Datei erstellen + Buchung einfügen.
Hierbei sollte als Exportformat auf alle Fälle der DATEV 2 - Standard unterstützt werden, mit welchem die meisten Buchhaltungsprogamme zurechtkommen sollten. Gleiches gilt auch für die Debitoren-und Kreditoren-Konten. Nur so ist ein Import in Fibu-Programme wie z.B Fibunet effizient.

 

[Henryk]

weiß nicht wie weit ihr schon seid, aber die erlöskonten an warengruppen fix zu binden ist nicht undedingt genial.
denn wir definieren die erlöskonten zb. nach vertriebskanälen (ebay, shop usw.).
dies sollte dann auch weiterhin wählbar sein.

 

[bofh]

Hallo

Warum nicht Erlöskonten an den Artikel Binden ?
Man könnte ja der Warengruppe ein Preset anbieten sprich wenn feld leer dann nimm nimm das Std Erlöskonto.

Wie wird das dann eigentlich gespeichert?
Ich nehm doch an wenn die rechnung verbucht wurde das diese dann je position einen eintrag in der journaltabelle bekommt. dann würde es reichen einfach ein weiteres datenfeld im gespeicherten journal zu haben das man dann exportieren könnte

 

[senior006de]

weiß nicht wie weit ihr schon seid, aber die erlöskonten an warengruppen fix zu binden ist nicht undedingt genial.

Warengruppen wären für die Kasse nicht schlecht.
Die kommt bei vielen auch noch dazu. Oder seh ich das falsch?
Gruß Jürgen

 

[bofh]

ich reis mal das alte thema nochmal auf

Warum nicht default per Warengruppe aber im Artikel nochmal wählbar.
ausserdem wärs nicht schlecht wenn man gleich bei den adressen debitoren und kreditorennummer hinterlegen könnte für ein zukünftiges einkaufsmodul (als vorbereitung sozusagen)

das exportmodul würde es ja auch reichen wenn man selbst die felder und reihenfolge anwählen könnte wäre wohl das kompatibelste (zb auch für Österreich hehe)

und wenn wir schon erlöskonten hinterlegen aufwandkonto nicht vergessen (eben für den einkauf).

ausserdem die splitbuchungsthematik nicht ignorieren.
pro erlös/aufwandskonto pro zahlung ist eigentlich eine buchungszeile nötig

ausserdem wäre dann in der thematik ein import von kontenrahmen nicht uninteressant die dann für den export in die fibu nötig sind.

das ist eigentlich die hauptarbeit. wenn das steht stünde einem einkaufsmodul und die gesamte finanzielle verwaltung über jtl nichts mehr im weg (jaja kassabuch fehlt dann immernoch ist aber wohl eher iene kleinigkeit)

jaja sicher soll ja keine fibu werden gehört aber eigentlich zur wawi dazu. grad bei kleinen firmen die nicht alles über die fibu machen wärs so möglich praktisch 9)% vorarbeit zu leisten und auch komplette übersicht zu haben

 

[rascob]

jaja sicher soll ja keine fibu werden gehört aber eigentlich zur wawi dazu

Wawi ist Wawi und Fibu ist Fibu - für mich ist eine externe Buchhaltung immer noch das Beste (kein Freund der Schnittstelle bzw. integrierte Lösung) - hatte in Vergangenheit viel Ärger mit Programmen weil nix lief (da war auch sage GS Auftrag, GS Buchhalter und GS Shop dabei).

Entwickelt lieber die Warenwirtschaft ordentlich weiter. Jeder noch so kleine Tante Emmaladen wird sich doch ein Buchhaltungs- oder EAR-Programm (siehe Data Becker oder Wiso Buchhalter) für nen Fufziger leisten können.

Wir sind weg von sage, eben wegen der vielen Fehler in den Programmen. Die Newsgroup von sage wurde aufgrund der vielen User-Beschwerden aufgelöst.

Haltet bitte die Wawi auf Kurs, von mir aus auch kostenpflichtig. Wichtig ist, es muss funktionieren.

Viele Grüße
rascob

 

[xelles]

jaja sicher soll ja keine fibu werden gehört aber eigentlich zur wawi dazu

Wawi ist Wawi und Fibu ist Fibu

Kann ich so nicht bestätigen, wenn man sich die großen ansieht SAP, Oracle etc. dann stellt man fest, dass es doch sehr sinnvoll ist das in einer Anwendung zu lösen. Klar sind aber Sage und Lexware nicht unbedingt die künstler auf diesem Gebiet, aber wir haben hier evtl. die möglichkeit das ganz mit unseren Vorschlägen gleich zu "erschlagen" und es richtig zu machen.

Ich finde es sehr sinnvoll, was o. g. wurde und biete wenn es die JTL Mannschaft möchte an einige sachen aus SAP zu nennen, wie sie dort laufen, weil ich sowohl die R/3 als auch MySAP ERP 2005 kenne. Und man muss ja das Rad nicht neu erfinden oder?

Gruß
xelles

 

[Null-Ahnung]

Hallo,
ok- dann mal eine Frage:

Wie kann ich für einen Fibu-Export ein entsprechendes Ertragskonto pro Land verwenden.

Also Beispiel:

Berechnung einer Lieferung oder Leistung Artikel z.B. "Pullover rot" inkl. Frachtkosten an einen Abnehmer.

Jetzt gibts folgende Varianten:

Lieferung nach Deutschland:
Erlöskonto 4400 (19%)

Lieferung nach EU-Land ohne ID-Nummer
Erlöskonto 4415 (19%)

Lieferung nach EU-Land mit ID-Nummer
Erlöskonto 4425 (EU ohne Steuer)

Lieferung Drittland
Erlöskonto 4100 (0% Steuer)


Wie kann ich das lösen ohne daß ich den Artikel 4 x anlege, sondern daß der im Grunde das Konto aus den Angaben des Steuersatzes und der Kundenstammsatzinformation gezogen wird.

Bin mal neugierig auf eine Lösung.

Viele Grüße

Uwe

 

[rascob]

Hallo, das wird nicht gehen. Ich denke, die Konten müssten in den Stammdaten hinterlegt werden und immer in Bezug mit dem Besteller (wie Du erwähnt hast, Inland, EG mit/ohne ID, etc.) stehen. Ist bestimmt aufwändig. Aber andere haben es ja auch geschafft .

Gruß
rascob

 

[xelles]

Ja es müsste in den Stammdaten bei der Kundenanlage gepflegt werden.

Beispiel:

Kennzeichen:
11 Inland Dritte
12 Ausland EU Dritte
13 Ausland nicht EU Dritte

Und dann müsste man noch ein Feld für die Steuer haben wie z.B.

Steuerplichtig:
Vorsteuerfplicht:

Da dann z.B. 0 für Steuerbefreit und 1 für Steuerpflichtig.

So ist es in SAP gelöst und wird direkt bei der Kundenanlage angegeben, dazu muss auch das Feld USD ID gepflegt werden können (kein MUSS Feld)

 

[Null-Ahnung]

Hallo,

naja- JTL mit SAP zu vergleichen, das wäre ja so, als wenn ein Ford Fiesta gegen einen Ferrari antritt zum Kräftemessen.

SAP kann das, weil es da Buchungslogiken gibt. Hier werden zudem auch Buchungsschlüssel usw. schon mitgegeben. Also das zu vergleichen wäre schon etwas vermessen.

Aber soweit ich weiß bekommt das sogar so eine Popelsoftware wie Sage in den Griff.
Und eigentlich sollte es doch kein Problem sein, drei oder vier Kontierungsfelder in einen Artikel vorzusehen oder sogar Steuerschlüssel abhängig.

Aber ok. Dann muß das eben die FIBU-Software umsetzen. Sollte auch gehen. Aber eigentlich ist es schade, daß die Software die Schnittstelle zur FIBU hier total vernachlässigt.

Viele Grüße

Uwe

 

[rascob]

@Null-Ahnung

Leg Dir doch SAP zu, es zwingt Dich doch keiner mit dieser Software zu arbeiten. Hat denn SAP auch eine Shopschnittstelle?

Und ist der Preis auch so günstig :lol: ?

Gruß
rascob

 

[xelles]

Hallo,

naja- JTL mit SAP zu vergleichen, das wäre ja so, als wenn ein Ford Fiesta gegen einen Ferrari antritt zum Kräftemessen.

SAP kann das, weil es da Buchungslogiken gibt. Hier werden zudem auch Buchungsschlüssel usw. schon mitgegeben. Also das zu vergleichen wäre schon etwas vermessen.

Aber soweit ich weiß bekommt das sogar so eine Popelsoftware wie Sage in den Griff.
Und eigentlich sollte es doch kein Problem sein, drei oder vier Kontierungsfelder in einen Artikel vorzusehen oder sogar Steuerschlüssel abhängig.

Aber ok. Dann muß das eben die FIBU-Software umsetzen. Sollte auch gehen. Aber eigentlich ist es schade, daß die Software die Schnittstelle zur FIBU hier total vernachlässigt.

Viele Grüße

Uwe

Ich vergleiche JTL nicht mit SAP, habe nur gesagt wie es dort gelöst ist.

Und das ganze auf Artikelebene zu lösen ist wahnsinn, da der auffand pro Artikel passiert und wie will man das auf Artikelebene überhaupt realisieren? Es mus in den Kundenstammdaten hinterlegt werden, dass war der einzige grund wieso ich das geschrieben habe.

Der Kunde ist immer A: Steuerpflichtig, B: Steuerbefreit EU, C: Steuerprlichtig EU, D: Steuerpflichtig nicht EU

(OK es gibt noch ein paar weitere ausnahmen, aber das sind denk ich mal die am häufig verwendeten.)


@rascob

SAP hat Schnittstellen ohne Ende und auch leicht anzupassen (relativ) ist aber natürlich nicht Kostenlos wie JTL.

Gruß
xelles

 

[gerhard5302]

...Und das ganze auf Artikelebene zu lösen ist wahnsinn, da der auffand pro Artikel passiert und wie will man das auf Artikelebene überhaupt realisieren? Es mus in den Kundenstammdaten hinterlegt werden...

Unterschreib ich sofort! Wenn ich es auch nicht wirklich brauche, denn bei uns macht das der Steuerberater bzw. eine seiner Angestellten schon fast im Halbschlaf beim buchen der Rechnungen.

lg
Gerhard