[isotope_stin]

**syncgw** · 16.10.2014, 14:44

Hi Stefan,

schau mal dort vorbei: http://www.bzst.de/DE/Steuern_Intern...Shop_node.html. Da ist alles erklärt. Soweit ich das verstanden habe braucht es ab 2015 "nur" für jedes Land aus der EU bei Privatpersonen die aktuelle MwSt. (http://ec.europa.eu/taxation_customs...tesSearch.html). Muss man halt für jedes Land eine Steuerklasse definieren und die jeweiligen Steuersätze einbauen. Das ist kein Hexenwerk und es braucht keine Programmierung. Kann man direkt in Isotope erledigen. Habe es aber noch nicht ausprobiert.

Wenn ich damit richtig liege hat sich das Thema für mich (in Bezug auf isotope_stin) erledigt. Leider nicht bei den Shops - da wartet noch Arbeit auf alle, die auch ins Ausland verkaufen.

Wenn jemand das anders sieht - bitte melden

**sganz** · 16.10.2014, 15:03

Hi syncgw,

die Regelung gilt für alle (End-)Verbraucher der EU ohne UStID, ja.

Allerdings kann ich - zumindest in Isotope 1.4 - pro Steuerklasse nur einen Steuersatz definieren. Hier komme ich ohne programmiertechnische Erweiterung meines Wissens also nicht weiter. Wie schon erwähnt möchten wir für alle Länder gleichbleibende Bruttopreise auf der Webseite ausweisen, in denen dann die Steuer je nach Land des Käufers variiert.

Wenn ich pro Land eine Steuerklasse definiere, müsste ich für jedes Produkt auch mehrere Steuerklassen angeben können. Auch das geht leider nicht.

Habe ich hier eine Möglichkeit in Isotope übersehen?

VG,
Stefan

**syncgw** · 16.10.2014, 15:55

Ah... da bin falscher Ansprechpartner - ich habe nur das isotope_stin gebaut weil das Isotope-Team keine Lösung für Umsatzsteuer-Befreiung bei Unternehmern angeboten hat (und ich dachte es ginge dabei um eine Erweiterung meines Modules).

Mit Isotope selbst hab ich nix zu tun. Da musste du deine Frage im Anderen Thread posten.

**sganz** · 17.10.2014, 09:31

Hallo syncgw,

ok, ich hab's schon befürchtet, dass da wohl was an Isotope selbst erweitert werden muss. Dann werde ich mal bei Andreas nachfragen.

Danke trotzdem und viele Grüße,
Stefan

**sganz** · 04.12.2014, 17:24

Hallo syncgw,

beim Isotope-Adressbuch-Modul (tl_iso_addresses) erfolgt bei uns keine Prüfung der USt-ID, d.h. hier kann der Kunde einen beliebigen String eingeben, der ungeprüft akzeptiert wird. Somit ist es möglich, dass der Kunde MwSt-frei einkaufen kann, auch wenn er gar keine (korrekte) USt-ID hat.

Lässt sich das irgendwie möglichst schnell fixen?

In der dca-Config konnte ich leider keinen Fehler entdecken (rgxp ist identisch).

Bei Eingabe der USt-ID im Kaufprozess oder bei den Accountdaten (tl_member) erfolgt die Prüfung korrekt - es betrifft nur die Eingabe im Adressbuch.

VG,
Stefan

**syncgw** · 04.12.2014, 19:33

Hei Stefan,

hast du auch eu_stin (und NICHT vat_no) aktiviert? Welche Isotope-Version? Wie wo Adressbuch?

**sganz** · 04.12.2014, 19:36

Hallo syncgw,

ja, eu_stin ist aktiviert und Contao-Version 2.11.17, Isotope-Version 1.4.8.

Mit Adressbuch ist das Isotope-Modul "Adressbuch" gemeint, in dem man die eingegebenen Adressen für Versand bzw. Rechnung bearbeiten kann.

VG,
Stefan

**syncgw** · 05.12.2014, 08:21

Hei Stefan,
sollte gezz funzen...

**sganz** · 05.12.2014, 08:51

Hi syncgw,

die Lösung liegt in Zeile 38, oder?

PHP-Code:


 && substr($st, 0, 14) != 'tl_iso_address')

Hab das jetzt direkt in unsere IsotopeStin.php übernommen, da die 0.3.1 ja nur noch ab Contao 3.2 funktioniert, richtig?

Vielen Dank für den schnellen Fix!

VG,
Stefan

**Spooky** · 05.12.2014, 09:16

@syncgw: könntest du bei der Erweiterung im ER bitte auch eine Lizenz angeben? Sonst wird es nämlich nicht in den contao-legacy Packagist für Composer aufgenommen

(oder du stellst sie direkt über Packagist zur Verfügung).

**syncgw** · 05.12.2014, 09:19

@Spooky
Ach, das Lizenzproblem habe ich verdrängt... Ich mach mich schlau und baue das ein.

@Stefan
Yes

**Spooky** · 05.12.2014, 09:23

Zitat von syncgw

@Spooky
Ach, das Lizenzproblem habe ich verdrängt... Ich mach mich schlau und baue das ein.

Bei Open-source software könnte das helfen: http://choosealicense.com/

**Spooky** · 05.12.2014, 10:05

Habe bei der Erweiterung folgendes Problem: wenn ich als Gast bestelle, eine Rechnungsadresse eingebe und dazu auch die UID, dann kommt immer die Meldung

Das Länderkürzel "AT" entspricht nicht dem gewählten Land!

obwohl ich beim Land "Österreich" ausgewählt habe.

Das Problem ist in der IsotopeStin.php, bei Zeile #56:

PHP-Code:


$c = $obj->Input->post('country') ? $obj->Input->post('country') : $obj->Input->post('billing_address_country');

Weder das POST field 'country' noch 'billing_address_country' existiert. Es existiert jedoch 'BillingAddress_country'. Evt. hat sich das in Isotope > 2.1.3 geändert (da deine Extension ja nur bis 2.1.3 freigegeben ist), ich verwende Isotope 2.1.9.

**syncgw** · 05.12.2014, 10:46

@Spooky
Danke für die Hinweise. Baue ich gleich ein und korrigiere die Isotope Version. Ich habe ja selbst 2.17 laufen und vergessen, dass zu änden....

**Spooky** · 06.12.2014, 12:25

Weiter unten beim generieren der E-Mail wird auch noch auf das alte Feld abgefragt:

PHP-Code:


            $v[] = $obj->Input->post('billing_address_company');

            $v[] = $obj->Input->post('billing_address_street_1');

            $v[] = $obj->Input->post('billing_address_postal');

            $v[] = $obj->Input->post('billing_address_city');

Ich denke das gehört auch noch geändert, oder? Also zB auf

PHP-Code:


            $v[] = $obj->Input->post('billing_address_company') ? : $obj->Input->post('BillingAddress_company');

            $v[] = $obj->Input->post('billing_address_street_1') ? : $obj->Input->post('BillingAddress_street_1');

            $v[] = $obj->Input->post('billing_address_postal') ? : $obj->Input->post('BillingAddress_postal');

            $v[] = $obj->Input->post('billing_address_city') ? : $obj->Input->post('BillingAddress_city');

**syncgw** · 18.12.2014, 12:07

@Spooky Danke für den Hinweis. Neue Version ist online.

**simwac** · 02.06.2015, 10:43

Zitat von syncgw

Das Modul fragt über die API für alle Europäischen Länder die STIN ab

...und verschickt auch gleich eine Bestätigung an den Admin mit einer von der EU zur Verfügung gestellten eindeutigen ID, die auf Wunsch dem Finanzamt vorgelegt werden kann. Das ist wichtig, da der Verkäufer dazu verpflichtet ist, die Gültigkeit der STIN abzufragen und einen Beleg dafür vorweisen zu müssen.

Ja :-) Und das funktioniert auch einwandfrei.
Gibt es die Möglichkeit, die dazugehörige Bestell-Nummer in die Bestätigung an den Admin einzubinden? So wäre es für uns einfacher, diese Bestätigung dem entsprechenden Kunden zuzuordnen.

**syncgw** · 03.06.2015, 15:37

ich schau mal...

**syncgw** · 05.06.2015, 08:29

Ähm.. habt ihr eine Testumgebung, die ich nutzen könnte?

Ich habe in meinen Shops eine Zwangsregistrierung bei dem die Verifikation der STIN läuft. Zu diesem Zeitpunkt gibt es nicht wirklich eine Bestellnummer. Sprich: Extra Shop zum testen bauen ist mir ein wenig mühsam...

Alternativ müsste da jemand bei Euch ran und mir sagen, wo ich die Bestellnummer (optional) abgreifen kann

**albis** · 14.01.2016, 15:17

Hallo, in der neuen Isotope Version ist ja eine Validierung der UID mit drin. Leider steht das Feld bei der "Registrierung" nicht mit zur Verfügung.
Hat jemand Erfahrung ob die letzte Version von isotope_stin (0.3.4) noch mit der aktuellen isotope Version (2.3.2) genutzt werden?

**andreas.schempp** · 15.01.2016, 08:58

Die Implementierung in Isotope 2.3 prüft die UID bei jeder Bestellung, weshalb bei einer Registrierung keinen Sinn machen würde.

**Spooky** · 15.01.2016, 09:00

Sinnvoll wäre ja beides, sodass die Validierung bei der Bestellung deaktiviert wird, wenn ein Mitglied eingelogged ist, das seine UID schon validiert hat.

**syncgw** · 15.01.2016, 11:02

Hei,
ich werde mir das bei Gelegenheit anschauen. Muss allerdings erst einmal die Zeit finden, Isotope in der Testumgebung auf die neue Version zu bringen. Ich bin momentan ein wenig mit Geld verdienen beschäftigt

**andreas.schempp** · 15.01.2016, 11:38

Ich halte nicht beides für sinnvoll. Die Mitgliederdaten werden in der Kasse lediglich als Vorlage für eine neue Adresse verwendet, die aber frei editiert werden kann. Ausserdem kann die UID auch ungültig werden, das würde man nie merken.

Der einzige Vorteil einer Speicherung wäre, dass deutsche Unternehmen auch Nachts bestellen können, weil dann ja der EU-Server nicht läuft

**Spooky** · 15.01.2016, 11:46

Es würde ja reichen, wenn die UID für die Vorlage gespeichert wird. Beim Checkout wird die UID dann einfach wieder validiert. Oder die schon gespeicherte UID wird beim Checkout Vorgang wieder validiert und wenn die Validierung fehlschlägt, wird das Feld wieder angezeigt.

**andreas.schempp** · 15.01.2016, 12:10

wozu dann die Prüfung bei der Anmeldung wenn man sie nochmals validiert?

**Spooky** · 15.01.2016, 12:23

Um dem Kunden gleich mitteilen zu können, wenn er unbeabsichtigt eine fehlerhafte Eingabe gemacht hat.

**andreas.schempp** · 15.01.2016, 12:24

Ah, ok. Das wäre dann aber etwas anderes. Weil Isotope macht das auch nicht, er zieht dann einfach die Steuern nicht ab. Weil wir nicht wissen ob die UID ungültig ist. Beispielsweise kann ich meine Schweizer SteuerID eingeben, die sowieso nie validiert werden kann.

**Spooky** · 15.01.2016, 12:26

Achso, naja irgendeine Form von Feedback wäre schon gut, sonst fragt man sich ja, warum trotzdem die Steuer verrechnet wird.

**andreas.schempp** · 15.01.2016, 12:47

Für die Problematik habe ich leider noch keine Lösung gefunden. Contao kennt nur "Fehler" und dann darf man das Formular nicht absenden.

**syncgw** · 24.01.2016, 18:08

Ich habe die Version in der Contao-Erweiterungsverwaltung aktualisiert. Läuft super mit Isotope 2.3.2

**kissinger** · 24.01.2016, 21:28

Hallo!

Wenn ich im Feld UID eine tschechische UID eingebe und als Land Tschechien gewählt habe erhalte ich die Fehlermeldung "Das Länderkürzel "CZ" entspricht nicht dem gewählten Land!

Warum?

vielen Dank!

**syncgw** · 25.01.2016, 07:42

Hei,
bei mir funzt das. Bitte mal in system/modules/isotope_stin/IsotopeStin.php in Zeile 63 bitte das Fettgedruckte einfügen:

Code:

	    	...
	    	}
	    } else
		$n = 'billing_address_';
var_dump('###'.$usr_country.'###'.$c.'###'); exit;
	    if ($usr_country != $c) {
	    	...

Dann wird dir angezeigt, was da verglichen wird (sollte "cz" und "cz" sein).

**TheDrummer** · 28.01.2016, 09:15

Zitat von kissinger

Hallo!

Wenn ich im Feld UID eine tschechische UID eingebe und als Land Tschechien gewählt habe erhalte ich die Fehlermeldung "Das Länderkürzel "CZ" entspricht nicht dem gewählten Land!

Warum?

vielen Dank!

Hi, same here.

"Das Länderkürzel "AT" ist kein EU Land!"

Erweiterung ist am neuesten Stand: 0.3.5 für c 3.5.6

**syncgw** · 28.01.2016, 10:08

Kann ich ohne die angeforderten Informationen nichts zu sagen...

**TheDrummer** · 28.01.2016, 10:14

Danke für deine rasche Rückmeldung!

das dient also zur Fehlersuche... dachte das wäre eine Lösung für CZ... sry.

Also die Ausgabe für AT:

Code:

string(13) "###at###at###"

edit:
Falls das Feld leer ist und man klickt beim Mitglied auf speichern kommt die Meldung:

Query error: Unknown column 'eu_stin' in 'field list' (UPDATE tl_member SET eu_stin='' WHERE id='28')

**syncgw** · 28.01.2016, 11:35

@TheDrummer

Sorry - ich war auch verwirrt. Hier deine Antworten:

1. Wenn die Spalte eu_stin in t-_member fehlt, dann ist die dort nicht angelegt. Sollte sie aber. Bitte prüfe dass und mache ggf. Datenbank-Update.
2. Das AT kein EU-Land ist, liegt daran dass du das auch in die Liste der "EU Länder Konfiguration" in der Shop-Konfiguration mit aufnehmen musst (Spalte eu_stin_countries)

Gruß

**TheDrummer** · 28.01.2016, 12:28

Hallo,

leider funzt es noch nicht ganz.

@ 1. Datenbank war nicht aktuell (obwohl mir die Erweiterungsverwaltung das gesagt hat nach dem updaten)
@ 2. War nur in einer der Shop-Konfigs "Österreich" nicht in der "EU Länder Konfiguration" - diese ShopKonfig ist aber nicht im Einsatz.

Leider kommen nun noch 2 Punkte dazu…

Ich hab nun in der Shop Konfig. 2 UID-Felder:

Wofür? bzw. was gilt nun?

4.
Wenn ich nun im Frontend die Userdaten ändern will, kommt folgender Error:

Recoverable error: Object of class Contao\FrontendUser could not be converted to string in system/cache/dca/tl_member.php on line 1041
#0 system/cache/dca/tl_member.php(1041): __error(4096, 'Object of class...', '/home/verz/...', 1041, Array)
#1 system/cache/dca/tl_member.php(1037): tl_cm_memberlist->resetCounter(Object(Contao\FrontendUser), Object(Contao\ModulePersonalData))
#2 system/modules/core/modules/ModulePersonalData.php(357): tl_cm_memberlist->resetCounter1(Object(Contao\FrontendUser), Object(Contao\ModulePersonalData))
#3 system/modules/core/modules/Module.php(282): Contao\ModulePersonalData->compile()
#4 system/modules/core/modules/ModulePersonalData.php(60): Contao\Module->generate()
#5 system/modules/core/elements/ContentModule.php(59): Contao\ModulePersonalData->generate()
#6 system/modules/core/library/Contao/Controller.php(476): Contao\ContentModule->generate()
#7 system/modules/core/modules/ModuleArticle.php(213): Contao\Controller::getContentElement(Object(Contao \ContentModel), 'main')
#8 system/modules/core/modules/Module.php(282): Contao\ModuleArticle->compile()
#9 system/modules/core/modules/ModuleArticle.php(67): Contao\Module->generate()
#10 system/modules/core/library/Contao/Controller.php(409): Contao\ModuleArticle->generate(false)
#11 system/modules/core/library/Contao/Controller.php(269): Contao\Controller::getArticle(Object(Contao\Articl eModel), false, false, 'main')
#12 system/modules/core/pages/PageRegular.php(133): Contao\Controller::getFrontendModule('0', 'main')
#13 system/modules/core/controllers/FrontendIndex.php(267): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#14 index.php(20): Contao\FrontendIndex->run()
#15 {main}

**Spooky** · 28.01.2016, 12:56

[vat_no] kommt von [isotope], [eu_stin] von [isotope_stin].

**TheDrummer** · 28.01.2016, 13:01

ok.

Was aktiviert man dann im isotope -> Shopkofig -> Kasse -> "USt-IdNr. [vat_no]"?
In der Mitgliederansicht (Backend & Frontend) kann ich das Feld nicht finden.