Austausch Veränderung der Wiener Ortstaxe per 01.07.

Hallo!

Komme gerne mal vorbei ;-)

LG,

Jean-Philipp.

Liebe Anja! Super Idee! Hätte im Februar für ein Treffen gut Zeit! Liebe Grüße aus dem 7ten! Ah, ihr seid ja die Altstadt. Also gleich ums Eck ;)Christina 

Super! Aus welchem Hotel bist du?

Wir beschäftigen uns auch gerade intensiv damit - Stand jetzt ist technisch in MEWS (aus unserer Sicht) noch keine 100% zufriedenstellende Lösung „out of the box“ sichtbar.

Aktuell läuft es bei uns so, dass die Ortstaxe als eigenes Produkt über eine Produktregel automatisch zur Logis hinzugefügt wird. Am sinnvollsten wäre hier aus unserer Sicht, wenn MEWS Gültigkeitszeiträume für Produkte/Produktregeln unterstützen würde bzw. Automationen, die Zeiträume berücksichtigen (z. B. Regel nach Buchungsdatum oder Regeln nach Aufenthaltszeitraum). Das wäre nicht nur für die Ortstaxe hilfreich, sondern generell für viele Themen.

Da es das im Moment nicht gibt, lösen wir es pragmatisch so:

- Für alle bestehenden Buchungen wird die Differenz über ein zusätzliches Produkt nachverrechnet.

- Ab 01.07. stellen wir die Berechnungslogik der Ortstaxe für neue Buchungen auf 5% um.

Da es sich um eine Abgabe handelt, die vom Gast geschuldet ist, informieren alle Gäste automatisch zum Buchungszeitpunkt, dass bei Abreise (bei Aufenthalten nach dem Stichtag) eine Nachverrechnung stattfinden kann.

Es interessiert mich natürlich sehr, wie ihr das gerade löst bzw. ob jemand einen eleganteren Ansatz gefunden hat.

Zum Thema Nationalitätenstatistik: Ich habe dafür letztes Jahr ein kleines Tool geschrieben, das aus der MEWS-Excel mit der Reservierungsübersicht automatisch eine Datei für Vietour generiert. Das ist kostenlos für alle - hier der Link zum Thread inkl. Anleitung: 

Also ich habe von MEWS die Info, dass man am Tag der Umstellung ein Overwrite über das Produkt mit der neuen Berechnungsformel drüber laufen lassen kann. Also solange es inkludiert bleibt kein Problem. Wenn wir es aber jetzt in unseren Raten anfangen zu exkludieren kommt eine wilde Mischung raus ;-)

Hi Anja, bin auch gerne dabei. Sollen wir uns mal alle treffen und brainstormen. Mir bereitet Mews jetzt weniger Kopfzerbrechen, eher HNS und wie wir das dann darstellen alles. Betreffend dem Override. Ich hab gerade ein praktisches Beispiel am Laufen, wo es um das BF geht. das ist auch gleich mein Testcase für die Ortstaxe - ich nehme an ihr habt es bei euch genauso angelegt wie wir mit der Produktregel?

Liebe Grüße,

Clemens

Bei uns ist die Ortstaxe generell in MEWS exkludiert und wird sowohl im Direktvertrieb als auch bei den OTAs immer on top auf den Netto + USt-Preis aufgeschlagen.

Genau, mit einer Produktregel. Derzeit rechnen wir es als Package ab! Super, bitte berichte dann.

Ich würde gerne den Februar noch abwarten bzgl. etwaiger Richtigstellungen und konkreten Aussagen und das Treffen im März ansetzen?

Bis dahin ändere ich die OT Angabe einfach mal auf exkl. 5% auf den Portalen. Wenn wir dann weniger verrechnen wird sich niemand beschweren und wir haben es uns zumindest mal kommunizieren ...

Erster Terminvorschlag von mir: Dienstag 17.03. 15:00 bei uns im Altstadt Vienna in 1070 Wien? Bitte um Like wer dabei ist! 😊

Perfekt, ja denke März ist früh genug. wir haben unsere Raten ab Juli auch schon vor längerem mal pauschal um 5% angehoben in Form eines Mark-ups. 

Wir haben es aktuell ebenso als Package im Stay inkludiert, ausgewiesen wird es mehr oder weniger eh in der Rechnung bei 0% Steuer. Ich hab noch nicht so ganz verstanden ob man es auch als Posten ausweisen muss in der Rechnung. Macht ihr das derzeit?

Boutique Hotel Kugel. Siebensterngasse/Ecke Neubaugasse 

Sorry, meine Kollegin wäre auch gerne dabei und ist da nicht da. Bitte 24.03 15:00 ;-)

Gehts vielleich auch vorher? in der Woche bin ich nicht in Wien, eventuell Die Woche 09.03.-13.03.? :)

24. 3. geht auch

​@Anja mein Kollege Markus vom IMLAUER Wien wäre auch gerne dabei, ist nun der 24.3 um 15 Uhr, dann leite ich es ihm weiter.

Wir haben die Info von MEWS, dass am 2.7.26 dies von MEWS durch gepusht wird.

da bin ich leider nicht da :(

So, das Interesse ist groß. Freut mich!

Ich lade euch somit herzlich am 24.03. 15 Uhr zu uns ins Altstadt Vienna in der Kirchengasse 41, 1070 Wien ein. Falls noch jemand dazu stößt sehr gern! :)

Hallo!

Es gibt ja zwei Möglichkeiten für die Ortstaxe, wenn diese - wie wohl notwendig - in den Preisen inkludiert ist:

1.) “Hard-coded” mit der Berechnung von MEWS, was auf alle Reservierungen automatisch angewendet wird, wenn die Option aktiv ist. Ich gehe davon aus, das in diesem Fall alles von MEWS automatisch erledig wird.
2.) Produkt und Korrektur-Produkt in Verbindung mit Produkt-Regeln, da die Hardcoded Variante evtl. je nach dem wie die Raten konfiguriert sind nicht wissen kann was an Frühstück in Abzug gebracht werden muss. Daher werden wohl manche (so wie wir) die OT als Produkt mit Korrektur-Produkt aufgesetzt haben. Das sieht dann so aus:

In diesem Fall wäre auf den folgenden Hilfeartikel zu verweisen:

https://help.mews.com/s/article/How-to-update-price-for-posted-products-in-bulk?language=en_US

Ich gehe also davon aus, dass wir einfach im Laufe des Juni - rechtzeitig also - ein Ticket aufmachen müssen um darum zu bitten dass am 1.7. die von uns zu spezifizerenden Produkte (City Tax und City Tax Adjustment) zu ändern sind (neue Schlüsselzahl eintragen) und auf alle künftigen Nächtigungen anzuwenden sind. Und am 1.7.2027 das gleiche Spiel erneut wieder. ​@Mews Community Team Wäre nett wenn Sie uns das so bestätigen könnten, oder evtl. eine zentrale Anlaufstelle oder Online-Formular bereitstellen könntet um das Prozedere geordnet und zeitnah abzwickel zu können - um einen “unerwarteten Andrang” beim Support dann am 1.7. zu vermeiden ;-)

Am 24.3. kann ich voraussichtlich leider nicht, aber zum Thema Nächtigungs-Statistik: Es hat weiter oben schon jemand ein Skript bereitgestellt mit dem das für Wien gut gelöst ist. Alternativ kann man auch den Reservation-Report mit einem pythonscript o.ä. teil-automatisiert auswerten - das ist keine Hexerei, ich habe das für uns intern umgesetzt, bin am überlegen ob ich den Code dazu veröffentliche (mein Code ist allerdings wohl eher ein “dirty hack” ;-) )

LG, 

JP.

Hallo!

Es gibt ja zwei Möglichkeiten für die Ortstaxe, wenn diese - wie wohl notwendig - in den Preisen inkludiert ist:

1.) “Hard-coded” mit der Berechnung von MEWS, was auf alle Reservierungen automatisch angewendet wird, wenn die Option aktiv ist. Ich gehe davon aus, das in diesem Fall alles von MEWS automatisch erledig wird.
2.) Produkt und Korrektur-Produkt in Verbindung mit Produkt-Regeln, da die Hardcoded Variante evtl. je nach dem wie die Raten konfiguriert sind nicht wissen kann was an Frühstück in Abzug gebracht werden muss. Daher werden wohl manche (so wie wir) die OT als Produkt mit Korrektur-Produkt aufgesetzt haben. Das sieht dann so aus:

 

In diesem Fall wäre auf den folgenden Hilfeartikel zu verweisen:

https://help.mews.com/s/article/How-to-update-price-for-posted-products-in-bulk?language=en_US

 

Ich gehe also davon aus, dass wir einfach im Laufe des Juni - rechtzeitig also - ein Ticket aufmachen müssen um darum zu bitten dass am 1.7. die von uns zu spezifizerenden Produkte (City Tax und City Tax Adjustment) zu ändern sind (neue Schlüsselzahl eintragen) und auf alle künftigen Nächtigungen anzuwenden sind. Und am 1.7.2027 das gleiche Spiel erneut wieder. ​@Mews Community Team Wäre nett wenn Sie uns das so bestätigen könnten, oder evtl. eine zentrale Anlaufstelle oder Online-Formular bereitstellen könntet um das Prozedere geordnet und zeitnah abzwickel zu können - um einen “unerwarteten Andrang” beim Support dann am 1.7. zu vermeiden ;-)

Am 24.3. kann ich voraussichtlich leider nicht, aber zum Thema Nächtigungs-Statistik: Es hat weiter oben schon jemand ein Skript bereitgestellt mit dem das für Wien gut gelöst ist. Alternativ kann man auch den Reservation-Report mit einem pythonscript o.ä. teil-automatisiert auswerten - das ist keine Hexerei, ich habe das für uns intern umgesetzt, bin am überlegen ob ich den Code dazu veröffentliche (mein Code ist allerdings wohl eher ein “dirty hack” ;-) )

 

LG, 

JP.

 

 

Bei uns ist es ebenso mit Adjustment Products aufgesetzt und ich hatte das genauso vor ;-)

Das Problem bei der Nächtigungsstatistik ist ja eher das mit dem Bundesland, da es ja bei D und Ö eingereicht werden muss (oder man muss es gut argumentieren wenn nicht) und es mega nervig ist, dass die Postleitzahl das Bundesland nicht automatisch ausfüllt. Wir sehen in diesem Feld einfach sehr oft Bugs. Und dann werden die Bundesländer auch noch komisch gruppiert in Nord / Mittel Süd usw. …

ich schau mir den Dirty Hack gern an ;-)

Anja

Liebe Anja, ich empfehle mein Tool. Das ist easy to use und genau für Wiener Statistik von mir konzipiert. Es erfüllt alle Aufteilungen nach Vorgaben, vorausgesetzt die Gästedaten sind richtig befüllt ;) https://community.mews.com/dach%2Dbased%2Dcustomers%2D42/tourism%2Dreport%2Dfor%2Dtourism%2Dstatistics%2Din%2Dvienna%2Daustria%2D742

​@Anja Hallo!

Mein Python Projekt für die TourismusStatisti Daten findest Du hier https://gitlab.com/jp_vienna/VieTourStatFromMewsReport

Es ist ein kleines Python script, dass im Prinzip ähnlich funktioniert wie das Skript von ​@sorwell . 

Allerdings braucht man für meine Lösung den Reservation Report auf englisch, aber das kann man auch anpassen, wenn man mag …

Zugegeben, die Lösung des Kollegen als Javascript in einer webseite ist auch sehr elegant ;-)

LG,

Jean-Philipp.

​@j.spiess, ich glaube ich habe in deinem analyseReservationData() einen zentralen Logikfehler gefunden, der die Nächtigungen bei monatsübergreifenden Reservierungen (und auch bei out-of-scope/Day-use) verfälscht.

Du berechnest am Anfang pro Reservierung persons, nights und dann sofort person_nights = persons * nights (wobei nights aus "Count (nights)" kommt, also die Gesamtnächte des gesamten Aufenthalts). Danach korrigierst du in mehreren if-Blöcken nights (wegen Report-Start/Report-Ende) und teilweise auch persons (Ankünfte sollen nur gezählt werden, wenn die Anreise im Reportmonat liegt), z.B. bei Aufenthalt überschreitet Report-Ende, Aufenthalt beginnt vor Report-Start (persons=0), out of scope (nights=0, persons=0) und Day-use (nights=0, persons=0).

Das Problem ist: person_nights wird nach diesen Anpassungen nicht mehr neu berechnet. Dadurch werden in der Aggregation am Ende oft die ursprünglichen Personennächte (gesamter Aufenthalt) addiert, nicht die auf den Reportzeitraum gekürzten.

Beispiel: 2 Personen, Aufenthalt 28.01.–03.02. (6 Nächte gesamt). Für den Februar-Report sind korrekt 0 Ankünfte und 2 Nächte im Februar => 4 Personennächte. Dein Code kann nights später zwar auf 2 kürzen, aber person_nights bleibt 12 und wird so aufsummiert, daher sind die gemeldeten Nächtigungen zu hoch.

Minimaler Fix: person_nights erst nach allen Korrekturen berechnen (oder nach jeder nights/persons-Änderung aktualisieren), also person_nights = persons * nights am Ende der Korrekturlogik.

Robuster wäre es, nights_in_report direkt als Overlap zwischen [Arrival, Departure) und [ReportStart, ReportEnd) zu berechnen und dann person_nights_in_report = persons * nights_in_report sowie arrivals_in_report = persons nur wenn Arrival im Reportmonat liegt.

Quick fix habe ich gleich eingebaut ;-) Danke für die Aufmerksamkeit!!!

Intern habe ich bereits vor einiger Zeit auf eine neuere Code-Version umgestellt die die MEWS Connector API verwendet um die Daten zu ziehen, und da war das breits gefixt, hatte ich in der “alten” Version die für die Verwendung eines Reports gedacht war nicht mehr nachgeführt … aber es ist jeder eingeladen sich daran zu beteiligen.
LG, JP.

​@j.spiess, für uns als kleines Haus ist die MEWS Connector API leider (noch) zu teuer, was ich echt schade finde. Ich hätte das extrem gern getestet und damit ein bisschen gespielt, weil man damit sicher coole Sachen bauen kann. ;)