Beiträge von gwinger

Kann mal jemand von Euch genauer erklären wie man das über Produkt Bundles löst?

$myAddonmodule
Origin: "Smarty object"
Value
null

Ds hier ist in der Smarty {debug} Ausgabe drin, von dem Modul, an dem ich arbeite.

Was ich möchte, daß die config Variablen des Moduls, die ich im Adminbereich im eigentlichen Modulfile

mittels der function:
function myBytesCheckout_config() {//Eingabefelder etc$option1 usw}angelegt habe, auch in dem Smarty Object auftauchen und im Clientbereich verfügbar sind.Hat jemand eine Erklärung wie das gemacht werden kann?

Hi, wie sieht es denn mit dem InternetX SSL Modul aus? Kann man das alte verwenden oder wartet Ihr da auch auf ein Update?

Hi Dennis, es ist nicht Lauffähig auf php7 bei mir gewesen und auch bwenn ich auf php 5.6 umsachlte funktioniert es nicht.
Eigentlich ein Unding von InternetX.
Ich überlege den Anbieter zu wechselnv. Andere Domain Registrare könnt Ihr mir gerne empfehlen.
Es ist halt so, daß das nächste mal wieder damit zu rechnen ist, daß man nicht zeitnah updaten kann.

Die Pflicht dazu ergibt sich angeblich aus dem Umsatzsteuergesetz.

Ich glaube es müsste §6a Absatz 4 Umsatzsteuergesetz sein.

(4) Hat der Unternehmer eine Lieferung als steuerfrei behandelt, obwohl die Voraussetzungen nach Absatz 1 nicht vorliegen, so ist die Lieferung gleichwohl als steuerfrei anzusehen, wenn die Inanspruchnahme der Steuerbefreiung auf unrichtigen Angaben des Abnehmers beruht und der Unternehmer die Unrichtigkeit dieser Angaben auch bei Beachtung der Sorgfalt eines ordentlichen Kaufmanns nicht erkennen konnte. In diesem Fall schuldet der Abnehmer die entgangene Steuer.

Jedenfalls nimmt das Bundesfinanzamt im Schreiben vom
6.01.2009 (BMF v. 06.01.2009 - IV B 9
-S 7141/08/10001 - NWB Datenbank) klaren Bezug darauf.

Unter "Warnhinweise" kann man hier: Überprüfung einer Umsatzsteuer-IdNr.: MIAS eine alternative Nachweisform? - Recht-Steuern-Wirtschaft - Verlag C.H.BECK

nochmal genau lesen was tatsächlich aktuell gängige Praxis ist. Wozu einem insbesondere geraten wird.

Im Prinzip gilt für elektronische Dienstleitungen dasselbe wie bei "Sonstigen Leistungen" analog zur Lieferung innerhalb der EU. Jedenfalls behauptet das mein Steuerberater. Dieser ist Fachsteuerberater für Auslandsbesteuerung und war erst kürzlich auf einem offiziellen Seminar wegen MIAS und VAT MOSS und dem ganzen Hirnriss.

Zur Überprüfung ist man aber auch seitens des Handelsgesetzes verpflichtet, soweit ich mich erinnere.

Jedenfalls ist es so, daß insoweit der Nachweis nicht erbracht werden kann, daß man den Unternehmensstatus des B2B Kunden nicht qualifiziert geprüft hat, schnell für hinterzogegene Mehrwertsteuern des Kunden, die volle Verantwortung befürchten muss. Und dann gibt es dabei sogar einen strafrechtlichen Aspekt, der da auch noch hinzukommt. Denn als "ordentlicher Kaufmann" ist man zu dieser Sorgfalt verpflichtet. Siehe GmbH Gründung usw. Das unterschreibt man das sogar beim Notar. Das man als Geschäftsführer die Geschäfte im Sinne eies ordentlichen Kaufmannes führt.

Im Grosshandel werden B2B Shops grundsätzlich so gehandhabt, daß man seinen Handelsregisterauszug zuschicken muss. Vorher gibt es keine Login Daten, keine Preise oder keinen Zutritt. Genau aus demselben Grund.
Das gilt für die Metro, sämtliche Computer Supplier und so weiter. Aber gerade bei Hosting Providern verschwimmt der Kontrast zwischen B2B und B2C zunehmend.

Als Provider oder Reseller sollte man solche Nachweise immer in der Tasche haben. Das gilt genauso für das Überprüfen der USt-Id's wie auch für den Inhalt der gehosteten Seiten.

Nicht nötig allerdings für den Umgang mit den deutschen B2B Kunden.
Denn da besteht ja ohnehin die Pflicht zum Einbehalt der 19% Mehrwertsteuern.
In dieser Konstellation kann nicht dazu kommen, daß dem Staat die Mehrwertsteuern durch die Lappen gehen. Deshalb ist ihm das auch egal.

Aber bei B2B Kunden aus dem EU Binnenland sieht die Sache eben ganz anders aus.

Es flattern gerne mal Ordnungsgeld-Verfügungen für falsche Rechnungsstellung ins Haus. Dagegen kann man sich leider nur zur Wehr setzen, wenn man so vorgesorgt hat, wie oben beschrieben.

PS: Dies ist keine Rechtsberatung sondern meine aktuelle persönliche Auffassung

Ich hab die Prüfung bereits implementiert. Würde ich ja auch zur verfügung stellen. Aber aktuell hab ich noch ein paar kleinere Probleme. Bekomme ich auch gelöst.

Schöner wäre es, wenn man noch einen Step mehr im Checkout hätte. Das wird eine Art Workaround werden. Aber notwendig ist das wirklich.

Keine Ahnung warum sich niemand dqffür interessiert, wobei das natürlich noch ernsthafter werden wird.
Die entsprechenden Ordnungstrafen werden wohl irgendwann verhängt werden und es wird Abmahnungen
regnen.

Übrigens bietet das Bundesamt für Finanzen unter BZSt: USt-IdNr. Bestätigung

eine XML-RPC Schnittstelle an, über die man eine amtliche Bestätigung des Geschäftspartners aus dem
EU Ausland erhält.

Diese Bestätigung ist pflichtgemäss nachzuweisen.

Zitat:

Muss ich bei Anfragen über die XML-RPC-Schnittstelle zusätzlich zur elektronischen Antwort immer eine schriftliche Mitteilung des BZSt anfordern?Bei Anfragen über die XML-RPC-Schnittstelle kann die vom BZSt übermittelte elektronische Antwort (Datensatz) unmittelbar in das System des Unternehmens eingebunden und ausgewertet werden. In diesen Fällen kann der Nachweis einer durchgeführten qualifizierten Anfrage einer USt-IdNr. – abweichend vom Grundsatz einer qualifizierten amtlichen Bestätigungsmitteilung – über den vom BZSt empfangenen Datensatz geführt werden (siehe auch Umsatzsteuer-Anwendungserlass Abschnitt 18e.1.).

Mit anderen Worten muss ein qualifizierter Nachweis darüber vorliegen, daß wir als Dienstleister eine "qualifizierte Anfrage" einer Umsatzsteuerid durchgeführt haben, bevor wir eine solche in Rechnung stellen.

Dies gilt in allen Fällen, wo commerziell nutzbare elektronische Dienstleitungen einem Unternehmer im EU Binnenland angeboten werden.

Beim Bundeszentralamt für Steuern kann diese Abfrage für alle EU Staaten gemacht werden und auch automatisch eine schriftliche Bestätigung angefordert werden. Das Amt schickt diese Bestätigungen dann an die Adresse, die hinter unserer eigenen Umsatzsteuer ID gespeichert ist. Also an unsere Geschäftsadressen.

Dieser Nachweis ist Pflicht. Wenn dennoch etwas in Richtung Betrug geht, ist man damit aus dem Schneider, wenn man den Nachweis besitzt, daß man den Kunden geprüft hat. Also qualifiziert geprüft.

Es ist im übrigen nicht legal, als Anbieter von Dienstleitungen Unternehmer aus dem EU-Binnenland auszuschliessen. Vo daher sollte man sich jetzt darauf einstellen, daß wir unter verschärften Bedingungen am Markt agieren.

Ich habe noch kleinere technische Probleme bei der Umsetzung.

Die Abfrage habe ich automatisiert und speichere diese in einer Tabelle ab.

Ein Problem ist immer noch die fehlende Checkout Confirmation Page.

Beim WHMCS wird zwar eine Confirmation angezeigt, jedoch kommt diese erst nach der erfolgten Bestellung.

Wir in Deutschland sind jedoch verpflichtet, jedem Kunden vor der endgültigen bestellung sämtliche Endpreise, nebst ausgewiesener Mehrwertsteuer etc.pp sauber aufzulisten
und in unmittelbarer Nähe einen (kostenpflichtig bestellen Button) zu plazieren.

Diese Page wäre eine zusätzliche Stufe im Checkout.

Hat jemand einen Tip, wie man eine Seite dieser Art in den Checkout einbauen könnte?

Hi Denis, kurzes Update:

Ich nutze mehrere Hooks und komme mittlerweile dahin, daß qusi Bestandskunde und Neukunde nach Verifizierung des Leistungsortes und des Status (B2B/EU, B2B/DE,B2C/EU oder B2C/DE) die entsprechenden
Daten in der Session vorhanden sind und über Smarty ausgeworfen werden können.

Wenn der Neukunde entweder einen CompanyName oder eine VAT Id eingibt, wird entsprechend dvon ausgegangen, daß es ein B2B Verhältnis wird.
Natürlich ist das komplexer insgesamt, aber ich habe sämtliche Konstellationen bedacht. Zusätzlich habe ich eine Tabelle angelegt, wo diverse landessprachliche Informationen bereitstehen, wie zum Beispiel der "Reverse Charge"Hinweis. Ich habe das jetzt mit 2 Steuerberatern und einem Juristen der IHK abgeklärt. Der Hinweis muss in der Landessprache des Leistungsempfängers erscheinen.
Ebenso werden für VATMOSS eingezogene Steuern mit dem Steuersatz des Leitungsempfängers und der landessprachlichen Abkürzung für MwSt angegeben.

ICh habe nkch dafür entschieden, beide Bezeichnungen jeweils anzuwenden: Also derart:

MwST/MOMS 25% (Dänemark),
Reverse Charge: Omvendt betalingspligt (Steuerschuldnerschaft des Leitungsempfängers)

Momsregistreringsnummer / Umsatzsteuer Identifikationsnummer

und für die Rechnung: SE-Nr. beim Dänen und beim eigenen Unternehmen USt-Id

Deer Ablauf ist wie folgt gedacht:

Neukunde oder Bestandskunde geht zur Kasse.

Zuerst wird der Button angezeigt: "Anmelden/Registrieren"

Kunde meldet sich mit Bestandslogin an oder füllt die Maske aus
In beiden Fällen werden die Daten geprüft. Entweder aus der DB beim Bestandskunden oder aus dem POST Array beim Neukunden
Nach durchlaufen der Checks wird der Status komplett per SESSION bereitgestellt.
Wenn checked_all = true wird der "Jetzt verbindlich betsellen" Button und die AGB'S etc. pp entsprechend dem Status B2B Agb's oder B2C AGB's angezeigt.

Ansich sollte das so stimmen.

Im Prinzip kann man nun wahlweise für jeden Status eine Cart Übersicht machen. Die Netto Preise müsste man allerdings im Template errechnen. Die stellt WHMCS unglücklicherweise nicht zur Verfügung.
Also die Netto Preise für die CART VIEW.

Diese Geschäftslogik funktioniert anscheinend zuverlässig.

Weiss schon jemand, ob die beiden InteretX Module endlich auf WHMCS 7.x angepasst wurden? Bzw wie die timeline da ausschaut?

Hallo Denis,

ich hab die Lösung gefunden für das Problem.....
Bin gerade dabei es umzusetzen

Es geht doch über einen einzigen Hook.

Für
den nicht eingeloggten Bestandskunden hab ich ein redirect. Die Preise
ind nachher ok, Es gibt nach dem Hook dann eine zusätzliche Smarty $var,
als Flag, so dass angezeigt werden kann, "Ihre Rechnung wurde geänder
auf Geschäftskunde" oder so ähnlich.
Denk ich noch drüber nach.

Wenn der Kunde sich neu anmeldet muss ich noch. Das wird aber funktionieren so wie es ausschaut. Das lässt sich auch direkt auf jeden Checkout anwenden. Ich schau mal, wie das am Ende mit der PDF Rechnung funktuioniert.

Hi, such mich mal bitte im Skype: gwinger (Hamburg),

ich würde Dir gerne meinen Bildschirm übertragen und Dir genau zeigen was das Problem an der Checkout Pipe ist.
Mit Ajax kenn ich mich aus, das könnte ich sehr fix machen. Nur wie an die Werte kommen...
Es muss einfach eine sogenannte Checkout Confirmation Page zusätzlich her, wo dann der "Verbindliche Bestellen" Button drauf erscheinen muss.
Diese Page muss die komplette Rechnung enthalten mit sämtlichen Positionen und den enthaltenen Steuern.
Da wir im WHMCS erst feststellen können, ob der Kunde B2B ist, wenn er eingeloggt wurde müssen wir die für ihn dann geltende Zusammnfassung erst anzeigen.
Ansonsten ist das illegal. Wenn man das hinbekommen könnte, dann wäre es kein Problem an dieser Stelle auch die AGB (B2B-Version) abzufragen.
Im Prinzip ist das Hauptproblem, daß die Checkout Confirmation Page nicht existiert. Das Registrieren/Einloggen des Kunden muss vorher passieren.

Ich habe mir da überlegt, daß falls es einen Hookpoint gibt, der genutzt werden könnte, dort wo der User sich einloggt oder registriert während der Bestellung, und sobald die
VAT ID gecheckt wurde bzw zur Verfügung steht, noch einmal redirected würde auf die "Übersicht" der normalen Checkout Seite.
Die Preise und Abrechnung wäre dann ja angepasst vom WHMCS EU VAT Modul.
Im diesem Template prüfen wir dann einfach, ob der Kunde eingeloggt ist und ob er
eine VAT ID hat. Erst nach diesem Redirect zeigen wir den "Jetzt kostenpflichtig kaufen" Button.
Ich muöchte Dir mal genau zeigen was da Sache ist. Es ist auch wirklich kein kleines Problem sondern eine tickende Zeitbombe.
Sobald irgendein mieser Abmahn Anwalt dahinter steigt, wird er nicht zögern geziehlt nach diesem Aufbau zu suchen. Wie schon so oft in der Vergangenheit.
Und das kann sehr teuer werden für viele WHMCS Benutzer.

Übrigens muss der Reverse Charge Hinweis in der Landesprache des Leistungsempfängers erscheinen. Die Bezeichnung für den VAT Tarif auch.

Da habe ich aber eine schöne Collection angefertigt, die ich gerne zur Verfügung stelle. Diese wnthält ebenfalls die Tresholds, bzw die kann man dort ja gut einfügen.

Ich würde meinen, daß man den Reverse Charge Hinweis und die VAT Bezeichnung (short) einfach auf Basis der ersten 2 Lettern der Umsatzsteuer ID abfragen kann.
Entweder aus einem Smarty Array oder direkt über einen Hook. Der Punkt wäre leicht zu lösen.

Hallo Denis,

ich habe gestern versucht bei Plambee anzurufen um Dich zu sprechen. Versuch ich heute nochmal.

Also Quelle für die Threshold Direktive:

EU country specific information on VAT - European Commission

genaue Auflistung der Thresholds(selbige Seite unten):
vat_in_ec_annexi.pdf

Das grössere Problem für uns "Provider" ist jedoch die fehlende Zusammenfassung der Bestellung mit dem angepassten Tarifen und Steuern vor dem endgültigen "Jetzt kostenpflichtig bestellen" klick

Sagen wir einfqch der Kunde sein ein Business Kunde im EU Binneland, jedoch nicht in Deutschland ansässig. Er betreibt eine E-Commerce Seite oder ähnliches.
Er hat eine VAT ID die er angeben kann und wir hätten ein Pflichtfeld, daß sobald die VAT ID eingetragen wird, der Firmenname ebenfalls Pflicht wird und wir hätten eine Checkbox: "Ich bestelle für die Nutzung im oben genannten Unternehmen.".
Halt so ähnlich könnte das laufen. Dann werden die Preise üblicherweise (netto) auf der Rechnung aufgelistet. Dann "zzgl. MwSt." darauf ausgewiesen und zwar in etwa so:

Posten 1 Hosting: 219€ pro Rata 112,56€

Das ist schön, dqß die Leute bei WHMCS fleissig programmiere. Leider haben sie den Knall nicht gehört. Denn der Checkout des Systems ist extrem abmahnfähig und keineswegs für den Handel in dDeutschland oder der EU geeignet.
Ein Beispiel:
Kunde besucht die Webseite und solange noch unklar ist, ob der User ein B2B oder ein B2C Geschäft abwickeln möchte, kann man ja die Steuern inclusive und das EU Tax Addon aktiviert laufen lassen. Die Preisangaben Verordnung lässt 1. nicht zu, daß die Preise überall ohne den Zusatz: (inclusive 19% MwSt) angezeigt werden. Das gilt bis in die Details wie monatlich/jährlich etc. Auch bei der kleinsten Angabe wo ein Preis steht, muss dieser Hinweis erfolgen.

Im Checkout kommt dann die ernsthaftere Problematik. Wenn der Kunde nicht eingeloggt ist, jedoch in der Cart Übersicht im Dropdown für die Taxes das Land ändert, so wird neu geladen und der vornehmlich noch als Endverbraucher anzusehene User bekommt entsprechende Preise angezeigt. Die Angabe unter Subtotal ist immer (netto) was irritierend als Zwischensumme angezeigt wird. Mit etwas Aufwand kann man das im template jedenfalls dahingehend faken, daß man diese Aufrechnung in der Cart Overview halbwegs legal hinbiegen kann.
Nun kommt aber der Checkout und wir wandern zum Eingabeformular bzw wahlweise Login. Und bekommen denselben non B2B Cart Overview angezeigt wie eingestellt wurde in der Auswahl des Leitungsempfängerlandes.

Problem 1: Wenn sich der User neu registriert und in der Maske seine USt-id einträgt, sein Land auswählt und dann auf kostenpflichtig Bestellen klickt wird direkt die Registrierung und die Bestellung ausgelöst. Das ist allerdings illegal.Zum einen muss der Kunde seine neu berechneten Preise vorher angezeigt bekommen, und zwar inlusive der kompletten Postenliste inklusive Addons usw. Es muss ersichtlich sein, daß er nun als B2B Kunde einen Vertrag bucht.

Problem 2: B2B AGB sollten abweichend sein. Denn normale AGB's gelten zwar im B2B Bereich, sind aber für diesen Zweck meistens zu eng gefasst und teilweise nicht anwendbar. Sollten jedenfalls nicht dem Geschäftskunden unnötigerweise sämtliche Gewährleistungsrechte des BGB Verbraucherschutzes zubilligen.

Problem 3: Einem zukünftigen Geschäftskunden wird die Preisberechnung für die Zusammenfassung nicht ordnungsgemäss angezeigt. So bestellt jemand eine Dienstleistung für seinen Onlineshop (also B2B Hosting) und sieht als letzte Abrechnung noch die Endverbraucherpreise, da er ja erst noch einloggen oder sich registrieren muss.
Es ist schier unmöglich während des Checkouts zuerst den Warenkorb anzuzeigen, danach zum Registrierungsformular zu gehen und sich dort anzumelden, um danach in einem weiteren Schritt die Bestellübersicht mit korrigierten Preisen zu sehen und zu entscheiden: Ja, jetzt buche ich verbindlich. Bei B2B muss netto und Steuern ausgewiesen werden, auch wenn die Endpreise inclusive Umsatzsteuern erhoben werden, beispielsweise weil wir in Deutschland für deutsche B2B Kunden die Steuern abführen müssen.
Eine anders lautende Rechnung zu verschicken als diejenige die vor dem Kauf gezeigt wurde ist hochgradig illegal. Das ist abmahnfähig hoch drei.

Problem 4: Der Button "Verbindlich buchen" oder "Jetzt kostenpflichtig bestellen" muss sich in unmittelbarer Nähe zum ausgewiesenen Endpreis befinden. Das ist ansonsten ebenfalls ein Verstoss gegen das Wettbewerbsrecht.

Naja, um es auf den Punkt zu bringen: Da ist viel Nachbesserungsbedarf seitens WHMCS. Aber der gesamte Checkout ist furchtbar naiv.

Zum Thema VAT Moss:
Was unbedingt abgefragt und danach für 10 Jahre sicher verschlüsselt verfügbar gehalten werden muss sind mindestens 2 Absicherungen bezüglich des Unternehmensstatus vom Kunden.
a) USt-ID alleine abfragen reicht nicht. Deshalb muss Unternehmensname ein Pflichtfeld sein und zusätzlich muss dies gespeichert werden. Pflichtfeld wird Pflichtfeld bei Angabe der USt-ID
b) Beim Buchen muss abgefragt werden, ob der Kunde für sein Unternehmen einkauft bzw ob er die Dienstleistung oder Ware auch für das Unternehmen nutzen will und man sollte sich dies ebenfalls bestätigen lassen.

Desweiteren müssen für VAT Moss demnächst auch dei Thresholds für den EU Binnemarkt dringend Beachtung finden. Das bedeutet, daß jedes EU Land eine Schwelle in Euros hat, die man im EU Zielland maximal erwirtschaften darf ohne in diesem Land Steuerpflichtig zu werden. Das geht dann auch über die Umsatzsteuern hinaus. Dise darf man dann nicht mehr über MOSS abführen hier in Deutschland sondern muss sich steiuerlich im EU Zielland erfassen lassen und dort die Steuern zahlen.

Also müssten theoretisch jedes Kalenderjahr die Einnahmen aus den EU Ländern aufgerechnet werden und bei überschreiten der jeweiligen Freigrenze müsste das System umstellen.

Doof dabei ist, daß es ebenfalls nach EU Auffassung illegal ist, andere EU Businesskunden auszugrenzen. z.b. durch geobasierte IP Sperren.

Alles in allem.... Sehr dünnes Eis

Habt Ihr hier eventuell eine Lösung oder vernünftige Workarounds für die einzelnen Schwachpunkte? Man hat halt kaum Alternativen.

Wir haben deswegen echte Probleme.