Neu Kunde hat mehrere Ustid Identifikationsnummern - kann nicht in der Wawi dargestellt werden.

[boeco-gmbh]

Hi,

wir haben folgendes Problem (ich kann mir nicht vorstellen, daß wir die einzigen sind):

Einer unserer Kunden sitzt in Belgien und lässt von uns Ware an seine Kunden in Belgien und seine Kunden in den Niederlanden schicken. Es sind immer IGL ohne MwSt. Bei den Aufträgen die nach Belgien gehen muß seine belgische UstId Nummer auf die Rechnung. Bei den Lieferungen an seine niederländischen Kunden muß die niederländische UstId unseres belgischen Kunden auf die Rechnung. Der belgische Kunde hat auch UstIds für beide Länder.
Leider kann man in der Wawi pro Kunde nur eine UStId erfassen.

Das macht diese Vorgänge extrem aufwendig. Jedesmal wenn z.B. eine Rechnung gedruckt oder per Email verschickt wird, muß manuell die UstId richtig beim Kunden eingetragen werden. Automatisch abgewickelte Bestellungen, via Shop, sind unter diesen Bedingungen nicht möglich. Es muß immer manuell eingegriffen werden,

Ganz fatal ist das beim Export von Rechnungen für die Datev. Da geht es gar nicht.
Z.B wir exportieren die Rechnungen für einen Monat, in dem wir für unseren belgischen Kunden, in beide Länder geliefert haben. Dann steht bei allen Rechnungen für ihn, die UStId die gerade im Kundendatensatz eingetragen ist. Dann muß jede falsche UstId von Hand in der Datev exportliste durch die richtige ersetzt werden.

Robert Sinkovic

 

[seven39]

Hi,

wir haben folgendes Problem (ich kann mir nicht vorstellen, daß wir die einzigen sind):

Einer unserer Kunden sitzt in Belgien und lässt von uns Ware an seine Kunden in Belgien und seine Kunden in den Niederlanden schicken. Es sind immer IGL ohne MwSt. Bei den Aufträgen die nach Belgien gehen muß seine belgische UstId Nummer auf die Rechnung. Bei den Lieferungen an seine niederländischen Kunden muß die niederländische UstId unseres belgischen Kunden auf die Rechnung. Der belgische Kunde hat auch UstIds für beide Länder.
Leider kann man in der Wawi pro Kunde nur eine UStId erfassen.

Das macht diese Vorgänge extrem aufwendig. Jedesmal wenn z.B. eine Rechnung gedruckt oder per Email verschickt wird, muß manuell die UstId richtig beim Kunden eingetragen werden. Automatisch abgewickelte Bestellungen, via Shop, sind unter diesen Bedingungen nicht möglich. Es muß immer manuell eingegriffen werden,

Ganz fatal ist das beim Export von Rechnungen für die Datev. Da geht es gar nicht.
Z.B wir exportieren die Rechnungen für einen Monat, in dem wir für unseren belgischen Kunden, in beide Länder geliefert haben. Dann steht bei allen Rechnungen für ihn, die UStId die gerade im Kundendatensatz eingetragen ist. Dann muß jede falsche UstId von Hand in der Datev exportliste durch die richtige ersetzt werden.

Robert Sinkovic

Das einfachste wäre hier für jede Ust.Id. einen eigenen Kunden mit eigenen Shopzugang anzulegen. Dann sollte auch der Rechnungsexport klappen.

Alles andere wird wohl im Moment nicht funktionieren.

 

[Simone_die_Echte]

Das wäre vllt. für JTL das Einfachste weil nichts geändert werden müsste...
Für den Händler nicht (Auswertungen verfälschen z.B.)
Und für den Kunden schon mal gar nicht!

Also eine Bitte an JTL: Nehmt doch das Feld Umsatzsteuer-ID mit in der Lieferadresse auf! Dann können die Kunden alles korrekt hinterlegen.

 

[Marc Völker]

Man könnte diese auch einfach in ein bestellattribute schreiben, jtl2datev besitzt dafür eine Einstellung. Und kommt damit zurecht, und in der Formular Vorlage lässt es sich auch anpassen


Gesendet von iPhone mit Tapatalk

 

[MichaelH]

Die Lieferschwellen werden fallen und jeder wird steuerpflichtig in der Ust-Abrechnung in jedes Land ab 10.000 Euro.
Insofern sollte JTL in Summe und Gesamthaft solche Anforderungen prüfen und es derart flexibel gestalten.

Wobei ich vermute dass mit "Auftrag neu" sich nicht nur die Oberfläche ändert, sondern auch einiges darunter.
- Bruttopreise fix, also Brutto auf Netto
- Beliefern von Filialen eines Kunden
- Lieferschwellen beachten, melden, abrechnen
- Sammelrechnung
- Proformarechnung
...

 

[Simone_die_Echte]

@Visitmedia | Marc: Es geht doch darum, dass die Kunden Ihre Daten im Shop korrekt eingeben können.
Oder kann ich diese Attribute auch zum Shop in die Eingabemaske bei den Lieferadressen übertragen?

Kunde mit Wohnsitz in der Schweiz bestellt
in die Schweiz -> Ausfuhrlieferung
nach Belgien mit belgischer Umsatzsteuer-ID -> IGL
in die Niederlande ohne USt-ID -> steuerpflichtig

Das muss doch alles schon bei der Bestellung berücksichtigt werden. Da nutzt das eine Feld mit der USt-ID bei der Rechnungsadresse recht wenig.
Und ja - solche Kunden mit mehreren IDs in unterschiedlichen Ländern gibt es und wir müssen dann erklären, warum die Steuer nicht korrekt berechnet wurde.

 

[Marc Völker]

Hallo,

ich müsste das testen, ob man auch bestellattribute über den Shop technisch setzen kann. Aber generell sprechen wir hier über die Thematik des Strecken oder Dreiecks Geschäfts, wie man mir damals mal erklärte, daher kenne ich auch die möglichkeit das anzupassen und in JTL 2 Datev auch einzustellen, falls es nicht nur für den Kunden eine sonderlösung ist, was ich meine auch in anderen Versionen schon gesehen hab.

Daher ist es abbildbar. Das thema dann aber noch in den Shop durch zu ziehen würde bisschen arbeit bedeuten, die Frage ist aber ehrlich wieviele solcher Fälle liegen wirklich vor? Unser Kunde ist hier im B2B bereich tätig, und hat es daher relativ oft. Aber wickelt das tatsächlich ohne Shop integration ab, sprich wenn die fälle auftreten, benachrichtigt er sich per Workflow (bzw die mitarbeiter) und es wird dann nachgepflegt.

Grundsätzlich sind das halt Probleme die natürlich langsam kommen. Und wo ich auch der Meinung bin, wenn ich mir so manche Konkurenz Produkte angucke, da ist JTL ganz weit vorne. Die frage wäre hier, sind es echt so viele die die Problematik haben? Bei uns bisher tatsächlich nur 1 Kunde. Und wir haben so manche Große Unternehmen, welche EU / Welt Weit aktiv sind, und sehr viele Sonderfälle bzw Spezialfälle Steuerlich haben.

 

[Simone_die_Echte]

Wie viele Kunden von JTL das betrifft vermag ich nicht zu beurteilen. Generell bin ich der Meinung, das alles was mit Steuern zu tun hat einfach korrekt im Shop abgebildet werden muss - egal ob und wie viel Arbeit das bedeutet! Wobei ich damit nicht Arbeit für Servicepartner und Shopbetreiber sondern für die Entwickler des Shopsystems meine. Sorry, aber bei dem Thema sehe ich nicht wirklich Spielraum.

Wir haben es schon gehabt, dass der Shop eine IGL generiert hat, wo es einfach nicht zutreffend war (weil die ID für ein anderes als das Lieferland galt). Der Kunde hat sich gefreut. Wir müssen halt die Steuer obendrauf abführen und sind not amused.

 

[Marc Völker]

Ja gebe ich dir recht. Und ich hab da noch nicht mal die bauchschmerzen das JTL es umsetzt, aber es muss halt auch eingebaut werden.

 

[MichaelH]

Viele Wege führen nach Rom und der Aufwand für Einzelfälle muss schon abgeschätzt werden, da gibt es vieles mehr was JTL programmieren könnte, als diesen Sonderfall.

-> Wir prüfen jede Bestellung mit UID-Nummer vor Versand, denn man kann und darf sich gar nicht auf die Angaben der Kunden verlassen, man ist ja in der Pflicht die Angaben zu prüfen.

Und warum es für einen regelmäßigen Kunden zu kompliziert sein sollte mehrere Kunden-/ Shop-Konten zu verwenden mit unterschiedlichen UIDs erschließt sich mir nicht. Er wird ja wohl wissen was er tut und wohin er es senden will mit entsprechenden Angaben zum RE-Empfänger und UID. Das ist für mich eher ein organisatorisches als technisches Problem.
Und sollte er unfähig sein, dann muss er eben mit Mail bestellen.

 

[Marc Völker]

Also ich teile da Michaels Meinung, und grundsätzlich ist es heut zu tage ja problem los möglich solche Fälle automatisiert per Workflow zu Prüfen, und wenn ich das Richtig in Erinnerung habe bist du doch eh ein Update verweigerer Und noch immer auf deiner 99922 wie im Footer steht unterwegs oder? Und wenn er es selbst da hin bekommt. Dann sollte das jeder auf der aktuellen auch hin bekommen.

Wie gesagt grundsätzlich richtig, ja JTL sollte alles korrekt abbilden, was es auch tut, und da gibt es viele Konkurenzprodukte die das bis heute nicht sauber, wenn überhaupt hin bekommen. Wir haben hier einfach einen Steuerlichen Sonderfall. Der aber tatsächlich mit ein bisschen Handarbeit umsetzbar ist. Falls man nicht mit mehreren Kunden arbeiten möchte.
Grundsätzlich muss ich aber natürlich sagen, dass es Auftragsbezogene Informationen welche einfluss auf diesen haben, wie eben die UstId, und diese wird nicht direkt im/am Auftrag hinterlegt. Ist schon schlecht. Und da ist JTL mit Auftrag 2.0 echt auch im Zuge, den die Ust Id sollte defintiv, sowohl in der Rechnungsadresse als auch in der Lieferadresse gespeichert werden. Und sich nicht aus dem KUnden referenzieren.

Einfaches beispiel:
Kunde ist heute Privatkunde, bestellt was. Dann zahlt er auch ins EU ausland seine Ust.

Nun ist ein jahr später, der Kunde ist aber mittlerweile Selbstständig (Einzelunternehmer) und denkt auch nicht dran, sich ein neues Konto anzulegen um privat und geschäft zu trennen, also hinterlegt er nur seine UstId, um zukünftig die UstId die er ja sparen darf zu sparen.
Der Alte auftrag mit Ust, hat nun auf einmal auch eine ustId, und es ist nicht nachvollziehbar, warum er damals nicht bereits eine IGL Lieferung erhalten hat. Daher bitte nach arbeiten.

P.S. Reiche das auch direkt als Ticket rein.

 

[MichaelH]

@marc
Ich bin keine Verweigerer !
Aber Aufwand und Nutzen muss gegeben sein und bis Frühling 2017 hätte ich mit der 1.x gar nicht arbeiten können.
Unsere jahrelang bewährte Arbeitsweise (inkl. Umsatzvervielfachung / Wachstum) war bis dahin nicht abbildbar.

Seit da bin ich aber wieder am Schauen. Aktuell halten mich die Spalteneinstellungen die man nicht zentral machen kann von einem Wechsel ab, das ist derart viel Arbeit für jeden User und Arbeitsplatz - sorry - und vorbereiten kann man nichts, das muss man alles nach dem Update machen. Und die Vorbereitung zum Test dauert ja auch 1-2 Tage und das mache ich eben nur ab und zu und nicht jede Woche.
Wechseln würde ich schon, aber wie sagt man: "Gut Ding braucht Weile", an einem reibungslosen Betrieb hängt mittlerweile zu viel dran.
Ich würde es sogar von einem SP machen lassen, aber bei mir in der Nähe gibt es nix und so muss ich immer noch selber dran.