Beiträge von andy77

OK, dachte es gibt vielleicht eine Alternative?

Im Hosting gibt es ja oft "scammer" Bestellungen.

fraulabs = Malaysia

mindmax = USA

Naja... kennt jemand einen DSGVO konformen Anbieter bzw. nutzt einen der zwei vorhandenen DSGVO konform?

Hi, hat jemand Erfahrung damit?

die zwei in WHMCS verfügbaren Anbieter sind denke ich nicht DSGVO konform.

InterNetX

Zitat

Was mir natürlich zum Modul einfallen würde wäre einfach das "payable date" aus autoDNS zu nehmen und einfach x Tage (welche vielleicht konfigurierbar sind) zu addieren. Damit würde dann das "Expiry Date" im WHMCS immer ein paar Tage in Zukunft zum "payable date" von autoDNS sein, was mehr Zeit für einen Sync bedeuten würde!

Wäre das möglich?

Somit gibt es einfach keine Lösung dafür und wir müssen damit leben bis WHMCS es endlich auf Ihre TODO aufnimmt?

Was mir natürlich zum Modul einfallen würde wäre einfach das "payable date" aus autoDNS zu nehmen und einfach x Tage (welche vielleicht konfigurierbar sind) zu addieren. Damit würde dann das "Expiry Date" im WHMCS immer ein paar Tage in Zukunft zum "payable date" von autoDNS sein, was mehr Zeit für einen Sync bedeuten würde!

Meines Erachtens nach ist es die Kombination der Modul und WHMCS Arbeitsweise.

Wie bekommt Ihr das in den Griff?

Hi@all,

ich habe ein Problem mit dem Modul und der Tatsache, dass Domains auf "Grace" oder "Expired" von WHMCS geändert werden, obwohl diese ja in autoDNS "automatische verlängerung" gesetzt haben.

Ich hab auch das Thema mit dem InternetX Support ziemlich genau diskutiert, jedoch verweist mich dieser auf das Forum.

Hat vielleicht sonst noch jemand das Problem bzw. hatte das Problem?

Hier meine Einstellungen in WHMCS Automatisierung:

2022-01-20-12-32-08 — ImgBB

Meine Crons laufen folgendermaßen:

*/2 * * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/pop.php >/dev/null 2>&1

*/5 * * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php skip --DomainStatusSync >/dev/null 2>&1

*/1 * * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --TicketEscalations >/dev/null 2>&1

00 7 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 8 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 9 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 10 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 11 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 12 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 13 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 14 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 15 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 16 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 17 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

00 18 * * * /usr/local/php74/bin/php74 -q /home/user/domains/whmcsdomain.de/public_html/crons/cron.php do --DomainStatusSync >/dev/null 2>&1

Ein Beispiel mit einer Domain welche von WHMCS auf "Grace Period" gesetzt wurde:

1. Am 03.12.2021 war die Domain xyz.de noch auf ACTIVE weshalb der DomainSync um 08:00 Uhr gestartet wurde.
2. Das Payable Date (also die Verlängerung der Domain) passiert am 03.12.2021 um 16:36 Uhr.
3. Aus diesem Grund steht am 03.12.2021 um 08:00 Uhr weiterhin noch das Datum 03.12.2021 auf "Payable" welches ja in das Expiry Date von WHMCS übernommen wird.
4. Aus diesem Grund wurde in WHMCS das Expiry Date nicht angepasst.
5. Zum nächsten "daily automated actions" welcher um 03:00 Uhr am 04.12.2021 lief, war also das Expiry Date noch auf 03.12.2021 gesetzt, weshalb der corn die Domain auf "grace period/expired" gesetzt hat.
6. Da die Domain nun auf "grace/expired" steht, wird kein Sync mehr gemacht.
7. Die Domain bleibt auf Expiry obwohl im AutoDNS am 03.12.2021 um 16:36 Uhr verlängert wurde.

Ich würde mich sehr über jegliche Hilfe freuen.

Grüße

ZoXx

Ja klar, ist schon sehr ... naja "zornig" der Post.

Wäre ja auch zu schön, wenn es ein Billing Panel gäbe, welches für die Kunden entwickelt wird und nicht nur rein für den eigenen Profit (Stichwort MarketConnect).

Sieht nach einem Interessanten Projekt aus, auch gibt es hier einen Post dazu:

Avoid WHMCS, Blesta, HostBill, ClientExec, Ubersmith Hosting (katamaze.com)

Zumindest dieser wurde im Dezember aktuallisiert.

Hier mal ein neues Projekt:

Katamaze/Leap: Free & Open alternative to WHMCS. Let's see if we can make it (github.com)

Hi@all, nutzt Ihr eine WAF vor WHMCS, und wenn ja welche oder habt Ihr andere zusätzliche Sicherheitsmaßnahmen?

LG Andy

Hi@all,

was habt Ihr für Lösungen für die folgende Problematik, zu welcher es auch schon ein "Feature Request" gibt?

Automatic Product/Service Upgrade/Downgrade without first requiring payment

Wir erhalten z.B. dadurch täglich "Order Cancelations" obwohl die Zahlungsart "Rechnung" ist die Zahlung deshalb einfach nicht gesetzt ist.

VG
Andy

Hi Leute, sorry für die lange Antwortzeit. Hatte nicht gesehen, dass es schon Antworten gibt.

Natürlich hat dies einen Sinn. Was ist, wenn die Firma z.B. von Ust. Pflichtig auf Kleinunternehmen geändert wird, und somit unsere Rechnungen inkl. Ust ausgestellt werden müssen. Oder das Unternehmen eine neue UST-ID erhält, aus welchem Grund auch immer (hatten wir sehr oft). Dann sind alle auf diese UST-ID ausgestellten Rechnungen nicht mehr korrekt und wir sind dann dem Finanzamt die Steuer schuldig, die wir nie eingebracht haben.

Hi @ all,

hat jemand von euch eine "erweiterte UST-ID Prüfung" im WHMCS aktiviert, sodass bei jeder Rechnung diese geprüft wird und nicht nur bei Registrierung?

Hier noch was, dass ich bei der Google Bildersuche geshen habe:

[Blockierte Grafik: https://s19.directupload.net/images/200115/8munu7vl.png]

Das sieht doch nach sowas aus.... Kennt das jemand?

LG

Ist die aktuelle Version des Plugins mit WHCMS 7.7.1 kompatibel?

Hi@all, mir ist aufgefallen, dass Upgrade Bestellungen, bei denen keine Zahlung eingegangen ist, automatisch storniert werden beim nächsten Fälligkeitsdatum des Produktes.
Der Kunde erhält dann eine Email mit "Pending Upgrade Order Cancelled" und das Produkt wurde nicht upgegraded.

Ich finde das ist irgendwie falsch, denn wenn der Kunde einen Tag vor dem nächsten Fälligkeitsdatum des Produktes ein Upgrade bestellt, wird sich die Zahlung des Upgrades nicht ausgehen per Vorkasse z.B., da am nächsten Tag eine neue Rechnung generiert würde, und die Upgrade Bestellung storniert wird.

Gibt es eine Config die das Verhalten verändert? Finde leider nichts in der Doku sowie bei Google dazu.

LG

@Denis Hast du irgendwo eine Liste mit Features des Moduls?

@Denis das Modul würde ich dann sofort nehmen!! Ich benötige es jedoch spätestens morgen
Gibt es irgendeine Chance das zu erhalten? (vielleicht sogar heute)

Ja das ist mir mit dem "Recurring Billing" Mdoul auch aufgefallen. Dies ist natürlich ein "No Go".