Beiträge von kk

Heute hatten wir den ersten Rechnungslauf mit den neuen Steuersätzen (und einer neuen Buchungsssoftware übrigens...).
Da schon die ersten Rückfragen aufgetreten sind, hier nochmal ein kurzer Hinweis:

LiveConfig-Lizenzen ("Softwaremiete") sind eine sogenannte Dauerleistung. Die Umsatzsteuer entsteht somit zum Ende des jeweiligen Leistungszeitraums.
In den neuen Rechnungen ist nun überall der exakte Abrechnungszeitraum sekundengenau aufgeführt (ab Seite 2). Alle Lizenzen, deren Abrechnungszeiträume nach dem 31.06.2020 23:59:59 enden, unterliegen somit schon der Umsatzsteuer von 16%.
Lizenzen mit jährlicher Abrechnung, die somit erst nach dem 31.12.2020 23:59:59 enden, wurden bereits wieder mit 19% abgerechnet.

Da das der erste Rechnungslauf mit einem neuen Buchungssystem war mag ich Fehler nicht grundsätzlich ausschließen, wir haben aber die letzte Woche über sehr ausführlich getestet und hoffentlich auch alle Sonderfälle korrekt abgefangen.
Für Fragen zu Rechnungen am besten unter Angabe der Rechnungsnummer eine kurze Mail an buchhaltung@liveconfig.com schicken.

Viele Grüße

-Klaus Keppler

Zitat von Pexies

Im liveconfig.log gibt es nur diese Info: "Error while connecting to MySQL server: SSL connection error: wrong version number"

Den Fehler hatten wir selbst noch nicht erlebt, im Forum gab's aber vor längerer Zeit einen ähnlichen Fall.
Welche Versionen exakt von LiveConfig und von MariaDB setzen Sie denn ein?
Haben Sie irgendwelche SSL-Einstellungen an MariaDB vorgenommen? Wenn ja, welche? (damit wir das mal versuchen können zu rekonstruieren)

Ja.

Aber: Rechnung im August 2019 für ein Jahr Webhosting (ggf. inkl. Domain) im Voraus. Geld fließt im August 2019. Da Webhosting eine Dauerleistung ist, gilt die USt zum Ende des Leistungszeitraums (=August 2020). Also wäre (theoretisch?) eine USt-Korrektur erforderlich. Aber wo kein Kläger da wohl auch kein Richter - dem Staat/Finanzamt entsteht ja in diesem Fall kein Schaden.
Der Kunde hat aber in diesem skizzierten Fall einen Anspruch auf Erstattung, das kann man im Einzelfall aber sicher auch einfacher lösen als mit einer Korrekturbuchungs-Orgie.

Am besten mal beim eigenen Domainregistrar anfragen, die haben sich sicherlich intensiv mit dem Thema auseinandergesetzt und vielleicht auch schon ein paar Argumentationshilfen bei Hand.

Wir sehen das so: [PERSÖNLICHE MEINUNG - KEINE STEUER-/RECHTSBERATUNG!] eine Domainregistrierung ist eine wiederholende Leistung, aber keine Dauerleistung. Die Dienstleistung an sich ist die Registrierung bzw. Verlängerung der Domain zum jeweiligen Stichtag - maßgeblich ist also die Ausführung der Leistung. Etwas anderes gilt, wenn eine Domain gemietet wird (separater Mietvertrag) bzw. anderweitige Lizenz- oder Nutzungsgebühren vereinbart sind - dann könnte das tatsächlich eine Dauerleistung sein. Aber auch bei Dauerleistungen gilt nur, dass die USt zum Ende des Leistungszeitraums fällig wird - wenn eine jährliche Abrechnung vereinbart ist muss hier also nicht monatlich abgegrenzt werden.

Komplizierter wird es beim Webhosting. Wenn die Hostinggebühr z.B. monatlich berechnet ("xx,xx €/Monat), aber nur alle 3 Monate abgerechnet wird, dann muss hier nach unserem Verständnis tatsächlich eine Abgrenzung stattfinden. Wird die Gebühr aber quartalsweise berechnet ("xx,xx € für 3 Monate") dann wiederum nicht.

Bei vorsteuerabzugsberechtigten Kunden ist die gesamte Diskussion i.d.R. komplett überflüssig, da die ja die gesamte ausgewiesene USt zurückholen können, sofern die Rechnung formal korrekt ist.

Viele Grüße

-Klaus Keppler

Zitat von Febas

Leider erhalte ich eine Fehlermeldung, wenn ich als Partner eine Lizenz ordere: "Error while ordering: Not Allowed (partner.php:170)"

Der Fehler ist nun auch behoben (Inkompatibilität nach einem PHP-Upgrade... )

Zitat von bravesurfer

WIrd es auch noch die bisherigen Wiki Beiträge zum Beispiel zu Multi-PHP und Autodiscover wieder geben?
Da fehlen im Moment ja einige nützliche Beiträge oder habe ich die nur nicht gefunden?

Ja, die werden beide derzeit inhaltlich überarbeitet und in Kürze auch wieder online stehen.

Wird auch in den nächsten Tagen wiederkommen (auch wieder unten auf der Seite, neben der News/Blog-Box).

Hallo!

die Umstellung der Website ist nun zum größten Teil abgeschlossen, lediglich am Shop wird aktuell noch gearbeitet.
Das Forum ist nun auch wieder online - hier wird im Laufe der nächsten Tage die Ausgabe/Darstellung (CSS) noch angepasst.

Viele Grüße

-Klaus Keppler

Das Problem mit dem RoundCube-Installer sollte inzwischen behoben sein. Bitte bei Gelegenheit noch mal testen (LiveConfig aktualisiert das Repository automatisch alle 24 Std, notfalls LC einfach mal kurz neu starten)

Viele Grüße

-Klaus Keppler

Hallo,

heute Nacht und morgen im Laufe des Tages werden an der LiveConfig-Website umfangreiche Änderungen vorgenommen (u.a. aufgrund der neuen MwSt. in Deutschland ab dem 01.07.).
Der Lizenz-Shop ist vorübergehend deaktiviert und soll voraussichtlich spätestens morgen Abend um 18:00 wieder online sein.
Die Backend-Systeme für LiveConfig-Partner sind hiervon nicht betroffen.

Das Forum wird morgen im Laufe des Tages für mehrere Stunden ebenfalls nicht erreichbar sein - auch das soll bis 18:00 abgeschlossen sein. Also bitte nicht wundern.

Die Änderungen werden nicht zu übersehen sein.

Viele Grüße!

-Klaus Keppler

Stimmt, ist tatsächlich die Überlegung ob man den Einsatz von PHP 5.5 mit FPM noch "schmackhaft" machen sollte.
Letztendlich gibt es ja nicht nur Sicherheits- sondern auch Geschwindigkeitsvorteile durch aktuellere PHP-Versionen.

Das Löschen der Verzeichnisse ist vermutlich dem systemd geschuldet, LiveConfig macht sowas nicht.

Viele Grüße

-Klaus Keppler

Wir erleben häufig das Problem, dass Kunden die Server einfach überhaupt nicht regelmäßig aktualisieren. Das Schöne an LiveConfig ist ja, dass es mit einem normalen Aufruf von z.B. "apt upgrade" mit aktualisiert wird ohne dass man sich um irgendwas kümmern muss.
Es gibt Kunden, die Probleme mit LiveConfig 2.1.x melden und auf Debian 7 laufen, weil der Admin "im Urlaub ist und noch keine Zeit für ein Update hatte".

Auf der Wunschliste steht bereits ein Check nach verfügbaren Distributionsupdates und einer entsprechenden Warnung im Dashboard. Das ist zwar nicht primäre Aufgabe eines Hosting-Controlpanels (daher bislang nur Wunschliste und nicht ToDo-Liste), aber ich merke schon dass der Bedarf doch groß ist...

Viele Grüße

-Klaus Keppler

Klingt auch für uns alles vernünftig und ohne großen Aufwand umsetzbar. Wir nehmen das in unsere Arbeitsliste auf (dürfte in einem der kommenden Updates drin landen).

Zu Punkt 4: das prüft nicht LiveConfig, sonder die DNS-Software (BIND). Irgendwo im BIND-Log wird sich ein Hinweis finden, dass sich der gewünschte MX-Eintrag einen ungültigen Zielhost enthält.
Inzwischen "kann" LiveConfig auch DNS-Abfragen durchführen, daher wäre es möglich, beim Anlegen von DNS-Records mit Ziel innerhalb der selben Zone zu prüfen, ob der jeweilige Host schon existiert.
Das ist nicht ganz so trivial wie die anderen genannten GUI-Änderungen, aber im Sinne der Kunden und auch kein Ding der Unmöglichkeit. Wird in der Umsetzung aber leider ein wenig länger brauchen als die anderen Punkte.

Viele Grüße

-Klaus Keppler

PHP 5.5 hatten wir bislang nicht für FPM vorkonfiguriert. Wenn das wirklich zwingend benötigt wird, können wir das Paket für Debian 9 sicher noch mal entsprechend erweitern.

Nachtrag: z.B. unter "Hosting" -> "Domains" einen weiteren Tab "DNS-Zonen" (nur sichtbar wenn Berechtigungen für eigene DNS-Einträge vorliegt).

Eine Idee wäre ein separater "View" auf die DNS-Daten (auch wir haben häufiger Anfragen hierzu).
Es besteht ja ohnehin auch ein Wunsch nach Import und Export von DNS-Daten, das ließe sich über eine separate Maske eleganter lösen als das auch bei der Subdomainverwaltung unterzubringen.

für eventuelle Mitleser: vermutlich war das o.g. Verhalten eine Nebenwirkung aus der Umstellung der PHP-Version via update-alternatives.

Hallo,

zu Frage 1: welcher PHP-Interpreter genau liefert diese Fehlermeldung?
führen Sie nacheinander mal folgende Befehle aus:

php -v
/opt/php-5.6/bin/php -v
/opt/php-7.0/bin/php -v
/opt/php-7.1/bin/php -v
/opt/php-7.2/bin/php -v
/opt/php-7.3/bin/php -v
/opt/php-7.4/bin/php -v

zu Frage 2: update-alternatives hat hiermit nichts zu tun (das betrifft nur Debian selbst, nicht aber LiveConfig).
Haben Sie manuell irgendetwas in einer .lua-Datei (/etc/liveconfig/lua.d/*.lua oder in /usr/lib/liveconfig/lua/custom.lua eingestellt?
Schicken Sie uns bitte ggf. mal die gesamte Ausgabe der PHP-Erkennung von "liveconfig --diag" an support@liveconfig.com

Viele Grüße

-Klaus Keppler

Ich habe das eben mal getestet. Unser ACMEv2-Client hatte noch ein Problem in der Kommunikation mit Buypass CA, ist in v2.10 dann behoben.

Eigentlich sollte das funktionieren (werden wir bei Gelegenheit mal testen).

Es sollte genügen, folgenden SQL-Befehl in der LiveConfig-Datenbank auszuführen:

INSERT INTO SSLPROVIDERS (SP_NAME, SP_LOGO, SP_MODULE, SP_DESCRIPTION, SP_DATA) VALUES ("BuyPass.com", "logo-letsencrypt.svg", "ssl-letsencrypt", "Free domain-validated Buypass Go SSL certificates", "https://api.buypass.com/acme/directory");

bzw. für die Test-Umgebung von Buypass:

INSERT INTO SSLPROVIDERS (SP_NAME, SP_LOGO, SP_MODULE, SP_DESCRIPTION, SP_DATA) VALUES ("BuyPass.com TEST", "logo-letsencrypt.svg", "ssl-letsencrypt", "Free domain-validated Buypass Go SSL certificates - TEST ENVIRONMENT", "https://api.test4.buypass.no/acme/directory");

Wildcard steht auf unserer ToDo-Liste (genauer Zeitpunkt steht aber noch nicht fest).

Viele Grüße

-Klaus Keppler

[UPDATE] Es muss zwingend ein Logo (SP_LOGO) hinterlegt werden, ansonsten zerschießt das in LiveConfig 2.9.x die Darstellung. In v2.10.x kann man auch einen Anbieter ohne Logo hinterlegen.