DA LEGGERE prima di lanciare un sito WHMCS

Ho iniziato ad usare WHMCS nel 2008. Se guardo al passato e alla situazione odierna c'è qualcosa che non mi torna. Ricordo WHMCS come un software vecchia scuola. Non era particolarmente bello ma era comunque affidabile.

Quello che abbiamo adesso è un software dove la forma è diventata più importante della sostanza. Lo staff di WHMCS dedica enormi quantità di tempo nel creare funzioni che nessuno ha richiesto. Al contempo nessuno si occupa di affrontare i veri problemi che abbiamo.

Premetto che questo post contiene un po' di lamentele. Dopo aver lavorato così a lungo su questo software, mi sono imbattuto in bug e decisioni terribili che mi hanno portato a chiedermi se WHMCS meriti ancora il mio tempo ed impegno.

Non vorrei essere frainteso. Se parliamo di gestire un servizio hosting non ci sono opzioni migliori. Le alternative a WHMCS sono mediocri ma le cose possono sempre cambiare. Specialmente se WHMCS continua a tirarsi la zappa sui piedi ad ogni release.

La miserabile vita di un programmatore WHMCS

Uno dei fattori che determinano il successo di un software come WHMCS, è la sua capacità di attrarre sviluppatori disposti a contribuire ad aggiungere valore alla piattaforma.

Anche se WHMCS non è open source, e comunque riuscita ad attirarne molti. Tutto grazie alle API e agli action hook che sono parte integrante del sistema.

Ricordo molte software house attive in WHMCS. La situazione odierna tuttavia ha poco a che fare con quella di pochi anni fa. Siamo rimasti con meno di 10 aziende che si stanno gradualmente spostando su altre piattaforme. A questo ritmo nei prossimi anni sarà rimasto ben poco.

Come sviluppatore che ha programmato per 14 anni in WHMCS, credo di poter dire un paio di cose sull'argomento ed anche spiegare perché gli utenti si lamentano con noi sempre per le stesse cose:

• Non rispondere ai ticket di supporto e alle domanda prevendita
• Non aggiornare i moduli o abbandonarli
• Non creare moduli definitivi e ad ampio raggio
• Non scrivere documentazione changelog
• Non aggiornare le informazioni dei moduli
• Non segnalare bug a WHMCS
• Non reagire alle nuove release di WHMCS
• Non preoccuparsi della retrocompatibilità

Il punto è che una release di WHMCS passa dalla beta all’end of life alla velocità della luce. Come può un programmatore esterno come lo sono io tenere passo con così tanti cambiamenti in un così breve lasso di tempo?

Tutto mentre WHMCS ancora fa l'hardcoding delle variabili negli script. Per non parlare dei bug critici e delle funzionalità mancanti che potrebbero riempire un libro.

Su questa piattaforma ogni sviluppatore deve affrontare così tanti bug, decisioni imposte dall'alto e cambiamenti con una frequenza che pochi possono sostenere.

Ovviamente non tutti gli sviluppatori ne sono affetti nello stesso modo. Se ti capita di essere il creatore di un modulo la cui complessità pareggia quasi quella di WHMCS, ogni nuova release è insostenibile.

Ma c'è di più. WHMCS ha la cattiva abitudine di svegliarsi la mattina e decidere che una funzione che stiamo usando da anni deve essere sostituita con una nuova che è peggiore. Non ci vengono fornite date nè documentazione. È tutto nella loro testa.

Non penso sia normale che anche aziende con decine di sviluppatori debbano investire mesi per rendere i propri moduli compatibili con l'ultima stupida versione di WHMCS. Mi piacerebbe andare avanti e smettere di reinventare la ruota ad ogni aggiornamento.

Voglio ancora lavorare con WHMCS ma stanno rendendo le cose davvero difficili.

Il problema principale è che il processo di sviluppo di WHMCS è simile a una marcia forzata. Continuano a tirare fuori aggiornamenti pieni di bug che si aggiungono ai precedenti al punto che è impossibile dire se certi bug esistono ancora.

Le cose hanno iniziato a prendere una brutta piega dopo l'acquisizione di WHMCS da parte di cPanel ovvero da quando si è iniziato a seguire la filosofia di sviluppo software che dà grande rilievo al rilascio di aggiornamenti frequenti e rapidi. Questo approccio punta ad aumentare la qualità in quanto le release frequenti:

• Avvicinano il software alle esigenze degli utenti
• Permettono i feedback tra sviluppatori e utenti
• Aiutano a rilasciare release prive di bug

Tutto questo non avviene in WHMCS dal momento che viviamo nell'era del «Please, submit a feature request». È il loro modo gentile di dire che non gliene frega nulla della tua opinione. La sezione delle Feature requests è Infatti il posto dove tutte le buone idee vanno a morire.

Oggigiorno WHMCS basa il suo lavoro più sulle necessità dei suoi partner che sulle nostre esigenze. Hanno da tempo smesso di ascoltare i clienti e si affrettano ad archiviare la maggior parte dei bug segnalati come "funzione" o qualcosa che funziona come previsto.

Sembra come se a loro interessi tutto quello che non interessa ai propri clienti. Ho una elenco di note riguardanti bug, hack, workaround e segreti. Scommetto che ogni sviluppatore ne ha uno ma ho smesso di segnalarli in quanto non sembra interessare allo staff di WHMCS.

Tutto quello che fanno è insistere con la loro frenesia di rilasciare bug e funzioni appena testate. Ancora peggio sembra che non facciano ricerche prima di introdurre novità lasciandoci a settimane, mesi o anni di problemi.

La prossima volta che ti lamenti di uno sviluppatore che non risponde ai tuoi ticket di supporto, ricordati di questo post e di quanto sia esasperante programmare su questo sistema. Penso che parte del problema sia che nel contesto generale siamo una sorta di valvola di sfogo.

Lo staff di WHMCS non ascolta pertanto molti provider in un certo senso reindirizzano la propria frustrazione sugli sviluppatori esterni. Ma non c'è molto che uno sviluppatore possa fare quando questo software continua ad annichilire ogni sforzo.

Per quanto mi riguarda, la mia disaffezione verso WHMCS ha raggiunto il culmine. Lavoro duramente per compensare tutte le mancanze di questo software ma le cose sono ben lungi dall’essere soddisfacenti. Prendersi la colpa perché qualcosa su cui non abbiamo alcun controllo non funziona come previsto, e la prassi. Francamente è insopportabile.

Alla luce di tutto questo, oggi ci penso due volte prima di mettermi a lavore su cose nuove. I bug di WHMCS già mi tengono abbastanza impegnato. Ho anche smesso di lavorare a soluzioni personalizzate e integrazioni.

Infine non ho più voglia di condividere le mie scoperte con lo staff di WHMCS. Stanno riempiendo questo software di bug che non vengono mai corretti. Se a loro non frega niente, non vedo perché debba occuparmene io.

Nei seguenti capitoli descriverò alcuni di questi bug e problemi.

WHMCS al suo meglio

Lasciatemi mettere subito in chiaro una cosa. Non c'è niente di male nel voler migliorare un software ma WHMCS lo fa in un modo strano:

• Nel 2020 festeggiano l'introduzione dell’uploader per le immagini
• Nel 2021 l'implementazione di Bootstrap 4 con 6 anni di ritardo
• Non sanno nulla di SEO e continuano a seguire miti SEO
• Il mondo si è evoluto agli Structured Data ma noi ancora manca un generatore di sitemap
• Gli Announcement e la KB sembrano venire dagli anni 90
• Ancora parliamo di integrazione Wordpress con WHMCS

Meglio tardi che mai ma non si può migliorare alcunché a questa velocità. È come trasportare acqua in un setaccio. WHMCS è sempre in ritardo nella tecnologia e manca di competenze in argomenti fondamentali come la fatturazione e il SEO.

Ogni tanto mi domando come sia possibile che riesca a creare più funzionalità nei miei moduli lavorando da solo dell'intero staff di WHMCS al completo. Cerco di dare un'idea di quello di cui sto parlando:

• Trasformare WHMCS in un CMS con blog, news, docs, feature request, commenti…
• SEO per WHMCS con inclusione di URL SEO, sitemap, GeoIP, OG Tag…
• Tracciamento delle vendite con Facebook Pixel e LinkedIn Insight Tag
• Riduzione dell'80% delle fatture e del 18% delle tariffe con la fatturazione mensile
• Fornire assistenza in base al Service Level Agreement
• Cash flow per tracciare il flusso di cassa in entrata e in uscita
• Customer Retention e Churn Rate
• Snapshot fatture avanzato che include i tassi di cambio
• Perfetta integrazione con il VIES, GST Australiana, marca da bollo
• Emissione delle note di credito
• Soppressione fatture non necessarie
• Esportazione automatica fatture. I PDF vengono inviati via FTP e/o via email come allegato
• Sistema di affiliazione con molteplici modelli di attribuzione

L'elenco va avanti ma penso di aver reso l'idea. Riesco anche a mantenere una documentazione (in due lingue) più estesa di quella di WHMCS. Andando oltre, cerco di risolvere problemi reali.

Mentre WHMCS ancora ci dice di utilizzare phpMyAdmin per ricavare determinati dati, ho creato SorTable per permettere alle persone di visualizzare filtrare ed esportare facilmente tutto quello che vogliono. Mi ci sono volute un paio di settimane ma ne è valsa la pena.

HereLang è stata la mia risposta alla multilingua e al SEO. Tradurre i contenuti in una vista affiancata al riparo dal contenuto duplicato è una cosa di cui in WHMCS non hanno mai sentito parlare.

Con MagicInput ho notevolmente migliorato la user-experience con decine di input di nuova concezione. Nel frattempo WHMCS ci ha dato solo il calendario... 5 anni dopo di me... che velocità!

Nessuno mi ha obbligato a creare tutte queste funzioni o mi ha puntato la pistola alla tempia quando ho deciso di risolvere questi problemi e di scrivere una documentazione esaustiva. L'ho fatto perché il mio lavoro.

Quello che mi preoccupa è cosa diavolo sta facendo WHMCS. L'aggiornamento medio di WHMCS contiene (senza contare i bug) funzioni microscopiche di cui non parlerei neanche nel changelog.

Voglio dire, ci hanno presentato il CALENDARIO come se fosse andare su Marte. È una libreria jQuery gratuita. Un qualsiasi sviluppatore decente può implementarlo in un paio d'ore in qualsiasi sistema.

Non riesco a credere quanto il loro apporto sia ininfluente e lento. Abbiamo da anni dei bug che potrebbero essere risolti in un paio di minuti. Allo stesso modo ancora attendiamo funzionalità che un qualsiasi sviluppatore competente potrebbe introdurre in un paio di giorni.

Non voglio sembrare presuntuoso ma devo dirlo. Trovo incredibile che un'azienda delle dimensioni di WHMCS ancora non riesca a risolvere certi problemi. Inclusi i quelli che sono riuscito a risolvere da me senza nemmeno vedere il codice sorgente.

Continuo ancora a supportare i clienti che eseguono WHMCS v5 nonché moduli e template creati dai miei competitor. Al contrario WHMCS con tutte le risorse che ha a disposizione mette tutto in "End of life" deprecando funzionalità come se non nulla fosse.

Certe volte mi domando cosa avrebbero fatto per integrare la fatturazione elettronica. Già solo dando uno sguardo all’articolo ci si può rendere conto della complessità del progetto. Immagina la mole di lavoro che c'è dietro. Facciamo un confronto veloce.

Ho completato un progetto di simili dimensioni in circa 3 mesi lavorando da solo. Nello stesso arco di tempo e chissà quanti dipendenti, WHMCS sta ancora cercando di aggiustare la GDPR che ha rotto lei stessa nella v8.

WHMCS v11: Anteprima esclusiva

Scherzi a parte ultimamente ogni software cerca di diventare Instagram incluso WHMCS. Nonostante abbiamo bisogno di gestire più dati, il design di WHMCS ricorre largamente al minimalismo con pessimi risultati.

Diamo uno sguardo al nuovo template twenty-one di WHMCS v8.1. Ho un monitor da 34 pollici con un rapporto 21:9 (3440x1440 pixel). Tutto sembra come uno scontrino fiscale: stretto e piccolo.

A che serve avere monitor più grandi se i designer inseriscono margini che si estendono da New York a Roma? È come se creassero le pagine per ospitare i margini anziché i contenuti in un enorme oceano di bianco. Passiamo la pagina dei domini.

Qui abbiamo la situazione opposta. 34 pollici non sono sufficienti per avere la barra di ricerca e i pulsanti allineati sulla stessa riga. Intanto uno spazio enorme viene occupato da un inutile lucchetto e non posso aprire le righe della tabella in una nuova scheda.

In più WHMCS ospita due valori nella stessa colonna (nome dominio e auto rinnovo on/off). Il motivo stesso per il quale si utilizzano le tabelle è avere una colonna per ogni parametro ma in WHMCS siamo pieni di colonne che ospitano un miscuglio di valori.

Potrei andare avanti per giorni con altri esempi. Per me questo non è minimalismo ma una scorciatoia verso un pessimo design. Scommetto che un giorno WHMCS sostituirà il nome a dominio con un'icona solo per soddisfare la propria voglia di minimalismo. O rimuoveranno la pagina di registrazione per "pensare fuori dalla scatola".

Snapshot ordini WHMCS

Lascia che ti presenti uno dei problemi più subdoli che solo pochi conoscono.

WHMCS non preserva i dati del cliente all'atto della creazione dell'ordine. Potrebbe non sembrare un grande problema ma lo è specialmente per la registrazione dei domini.

Supponiamo che un cliente trasferisca 100 domini utilizzando le seguenti informazioni in qualità di registrante:

Fiorenza Panicucci
TIM S.P.A.
[email protected]
Via Callicratide 24
Ussel
AO
11024
IT - Italy
+39.03102578690

Come saprai, possono occorrere diverse ore o giorni prima del completamento dei trasferimenti. Nell'attesa il cliente è libero di aggiornare i propri dati in qualsiasi momento dall'area clienti. Supponiamo che questo modifichi l'email come segue:

Fiorenza Panicucci
TIM S.P.A.
[email protected]
Via Callicratide 24
Ussel
AO
11024
IT - Italy
+39.03102578690

Subito dopo procede al trasferimento di altri 100 domini in un nuovo ordine. È del tutto normale dal momento che il cliente ha bisogno di utilizzare dati di registrazione diversi per questo ultimo acquisto.

A questo punto abbiamo due ordini ciascuno con 100 trasferimenti. Entrambi sono collegati allo stesso cliente ma presentano dati di registrazione diversi:

• Il primo ordine ha [email protected]
• Il secondo ordine ha [email protected]

Ci aspetteremmo che WHMCS processi ciascun ordine con i rispettivi dati di registrazione ma questo non avviene. Entrambi gli ordini saranno evasi utilizzando l'ultimo indirizzo email fornito. Questo perché i dati di registrazione non vengono memorizzati quando l'ordine viene aggiunto.

Le conseguenze sono distruttive in quanto si andranno a trasferire domini con dati errati violando le regole ICANN. In più i clienti possono farci causa o obbligarci a correggere tutti gli errori il che costa denaro e tempo prezioso.

Questo era un esempio estremo ma immagina cosa accade quotidianamente nel tuo sistema a tua insaputa. Prima che tu pensi che la soluzione sia utilizzare i sub-account, sappi che questo non risolve il problema. Come se non bastasse il problema si estende anche alle funzioni API.

Solo lo staff di WHMCS può approntare una soluzione. I dati dei clienti devono essere "bloccati" al momento della creazione dell'ordine in modo che eventuali modifiche non abbiano effetti retroattivi. Si dovrebbero anche modificare i comandi API DomainTransfer e DomainRegister in modo che accettino i dati di registrazione completi.

Non è difficile ma hanno altre priorità. Sicuramente avranno qualcosa di meglio da fare che impedire che i propri clienti subiscano cause legali e costi extra.

Reset della password in WHMCS v8

Prima di entrare nel merito di questioni più complesse, diciamo un paio di parole riguardo  il prendere decisioni pessime. Prima della v8  resettare la password dei clienti era un'operazione di un click. Ora invece devo affrontare un processo intricato che sembra quasi che stia hackerando il mio stesso sistema:

• Sostituisco l'email del cliente con la mia
• Eseguo l'accesso come cliente
• Inizializzo il reset della password per ricevere il link sulla mia email
• Reimposto l'email del cliente e gli invio manualmente il link

È ridicolo che un amministratore non possa modificare la password dei propri clienti ma è così che funziona. L'ultima tndenza di WHMCS è quella di imporci come secondo loro dovremmo gestire le nostre aziende. Non ti sta bene? A loro sicuramente non interessa ma ti diranno di aprire una richiesta di funzionalità.

Fatturazione WHMCS

È comprensibile che WHMCS non voglia avere a che fare con cose come la Brexit, la fatturazione elettronica, Tenerife e le normative che cambiano ogni anno. Ciò spiega perché nel software mancano molti concetti di fatturazione.

WHMCS preferisce lasciare a noi questa incombenza in modo che possano dedicarsi al rilascio di nuovi bug e funzioni inutili. Ho basato la mia carriera sulle mancanze di fatturazione di questo software creando Billing Extension dove affronto ogni problematica.

Sebbene sia chiaro che WHMCS non ha alcun interesse nell'avventurarsi nella giungla della fatturazione, di tanto in tanto fanno dei disastri prendendo decisioni senza senso basate sulla loro superficialità.

Credono di essere nella posizione di poter cambiare quello che vogliono anche senza studiare. Non hanno bisogno di verificare niente né di contattare un commercialista per chiarirsi le idee. Preferiscono usare noi tutti come come topi da laboratorio.

Ricordo quando un giorno decisero unilateralmente di calcolare le tasse per riga fattura. Supponiamo di avere 5 righe ciascuna con un costo di 12.98 euro più il 22% di tasse. Facciamo i calcoli: 12.98 x 5 = 64.9 euro. Il 22% di di 64.9 sono 14.28 euro di tasse.

Secondo WHMCS invece erano 2.86 euro (22% di 12.98) da moltiplicare per 5 per un totale di 14.30 euro. Per un paio di settimane tutti emettemmo fatture con importi errati. Ricordo ancora di averne dovuto correggre a migliaia.

Upgrade e Downgrade automatici

Mi riferisco alla funzione Upgrades/Downgrades. Come suggerisce il nome, viene utilizzata dai clienti per cambiare le configurable options. Purtroppo il modo in cui funziona causa errori di fatturazione. Prima di iniziare un paio di informazioni preliminari.

WHMCS non gestisce le ricariche credito in modo corretto. Quello che fa è considerato illegale nella maggior parte dei paesi. Quando un cliente decide di caricare dei fondi, WHMCS emette una fattura priva di tasse causando più di un problema.

Passaggio	Descrizione
Ricarica credito	It's 2020, VAT rate is 22% and WHMCS issues and invoice that looks as follows: Subtotale: 100 € Tasse: 0 € Credito: 0 € Totale dovuto: 100 €
Pagamento	Il cliente paga 100 € e riceve un credito di 100 €. Ciò dà luogo al primo problema. Nella maggior parte dei paesi le tasse devono essere applicate ogni volta che si riceve un pagamento. Una fattura priva di tasse non è corretta a meno che non ci sia uno specifico motivo (es. VIES, regimi di tassazione speciale).
Applicazione credito	Parte del credito viene utilizzato per rinnovare un servizio che costa 10 € / anno. Ecco la fattura risultante: Subtotale: 10 € 22% tasse: 2.20 € Credito: 12.20 € Totale dovuto: 0 € Ecco che abbiamo un secondo problema. L'importo della fattura è zero. Nessun pagamento è richiesto. In alcuni paesi questo tipo di fattura non solo non è necessaria ma non può essere contabilizzata
Rinnovi	Utilizziamo il credito residuo di 87.80 € per i successivi rinnovi: Nel 2021 WHMCS deduce 12.20 € incluso il 22% di tasse Nel 2022 l'aliquota passa dal 22% al 23% e WHMCS deduce 12.30 € Nel 2023 WHMCS deduce 12.30 € incluso il 23% di tasse Questo è sbagliato su più livelli. Primo. Si deve attendere il 2028 prima che l'applicazione delle tasse abbia effetto su tutto l’importo del pagamento inserito 8 anni prima. Secondo. Il cliente è soggetto a diverse aliquote IVA, regole e anni fiscali per un pagamento inviato nel 2020

Per risolvere questa follia, ho ideato una funzione che applica le tasse alle ricariche credito. Fondamentalmente emetto una fattura di ricarica credito che include le tasse come segue:

• Subtotale: 100 €
• Tasse: 22 €
• Credito: 0 €
• Totale dovuto: 122 €

Quando arriva il momento del rinnovo e si utilizza il credito, WHMCS emetterebbe un documento a importo zero ecco perché ho creato un'altra funzione per sopprime la fattura a importo zero.

Ora che conosci il contesto, torniamo agli Upgrade/Downgrade. La funzione si basa sul rimborsare le risorse non utilizzate per il ciclo di fatturazione corrente. So che può sembrare complicato quindi faccio un esempio.

Oggi ordino un piano hosting con il backup che costa 50 euro annui. Pochi minuti dopo cambio idea. Voglio liberarmi del backup e attivare l'antispam che ha lo stesso identico prezzo.

Anche un bambino capirebbe che non è dovuto alcun pagamento. Il prezzo di entrambe le opzioni è infatti lo stesso ma WHMCS ha un'opinione diversa. Ecco la fattura risultante:

• Subtotale: 50 €
• 22% tasse: 11 €
• Credito: 50 €
• Totale dovuto: 11 €

Il totale dovuto e le tasse sono entrambe inspiegabilmente sbagliate. Per maggiore chiarezza, ecco come sarebbe dovuta essere la fattura:

• Subtotale: 0 €
• 22% tasse: 0 €
• Credito: 50 €
• Totale dovuto: 0 €

Non è dovuto alcun pagamento quindi non sarebbe nemmeno necessario emettere fattura. Ora farò un altro esempio che ti farà impazzire.

Questa volta sostituiremo un'opzione che costa 10 € con una che ne costa 50. In sintesi stiamo facendo un -10 +50 senza considerare le tasse ma ecco quello che fa WHMCS:

• Subtotale: 50 €
• 22% tasse: 11 €
• Credito: 10 €
• Totale dovuto: 51 €

Mentre doveva essere così:

• Subtotale: 40 €
• 22% tasse: 8.8 €
• Credito: 10 €
• Totale dovuto: 38.8 €

Come se non bastasse i calcoli sono anche inconsistenti. Questo è il costo che mi prospetta WHMCS quando voglio fare l'upgrade.

Vuole che paghi 68.93 euro. È sbagliato ma per il momento non consideriamolo e premiamo il tasto continua per ricevere la fattura.

Cosa diavolo sta succedendo? il totale dovuto è ora di 92.40 euro. C'è una differenza di 23.47 euro. Da dove salta fuori? Come si spiega? Tieniti forte. WHMCS utilizza formule diverse per calcolare lo stesso numero.

Formula upgrade	Formula fattura
Totale dovuto = (Totale pagato - Totale rimborsato) + 22%	Totale dovuto = (Total pagato + 22%) - Totale rimborsato
(163.2 - 106.7) + 22% = 68.93	(163.2 + 22%) - 106.7 = 92.40

Nessuno script può risolvere il bug in quanto è radicato nel core di WHMCS. Quando l'ho segnalato mi hanno detto che lo avrebbero risolto. Erano 3 anni fa. L'unica soluzione che abbiamo adesso è di non utilizzare questa funzione e pregare Zeus.

Sottoscrizioni e pagamenti in eccesso

Il problema dei pagamenti ricorrenti che danno luogo a pagamenti in eccesso e uno dei più frustranti che abbiamo in WHMCS. Ecco un'altra tabella che descrive il nostro nemico.

Passaggio	Descrizione
Ordine	È il 2020, le tasse sono al 22% e registro un dominio a 12.20 € (10 € + 2.20 € tasse)
Pagamento	Decido di pagare la fattura risultante creando un pagamento ricorrente. Il numero della fattura è #2020-500
Rinnovi	Ora è il 2021. Non ricordo neanche cosa ho mangiato ieri. Dopo 12 mesi mi sarò sicuramente dimenticato del rinnovo automatico. Non appena inizierò a ricevere notifiche di scadenza, invierò subito il pagamento manualmente perché non voglio correre il rischio di perdere il mio dominio
Pagamento in eccesso	PayPal (o un qualsiasi altro gateway di pagamento) non sa che ho già provveduto al saldo. Pochi giorni più tardi il pagamento automatico arriva ugualmente. Dal momento che la fattura è già pagata, il pagamento automatico determina un pagamento in eccesso che viene accreditato come credito nel mio account

Siamo davanti ad un orrore di fatturazione.

Prima di tutto WHMCS registra il pagamento in eccesso sulla fattura dell'anno precedente il che significa che la fattura #2020-500 si sposta dal 2020 al 2021. Se questo ti lascia senza parole, c’è di più. Viene anche modificato l'importo incasinando le tasse.

L'importo della fattura è ora di 20 euro. WHMCS dà per scontato che l'aliquota IVA sia sempre uguale ogni anno e che i clienti non cambiano mai la propria ragione sociale. In sintesi applicherà l'aliquota del 2021 su una transazione del 2020.

Le cose peggiorano nel caso in cui il cliente non utilizzi tutto credito (il pagamento in eccesso) prima del successivo rinnovo. WHMCS infatti lo utilizza per saldare le successive fatture.

Ciò non impedisce a PayPal di inviare comunque il pagamento automatico che ogni anno darà luogo ad un altro pagamento in eccesso. Lascia che lo ripeta ancora una volta: OGNI ANNO.

Ho visto sistemi dove la stessa fattura si è spostata dal 2012 al 2013, 2014, 2015 ecc. È un ciclo infinito che non si ferma mai fino a quando qualcuno non rimuove il credito o cancella la sottoscrizione.

La bella notizia è che sono riuscito a risolvere il problema emettendo fattura per i pagamenti in eccesso. In questo modo WHMCS non cambia né sposta le fatture degli anni precedenti.

La brutta notizia è che c'è un tipo di pagamento in eccesso che non si può fermare né correggere. Per saperne di più leggi il capitolo successivo.

Voci fattura scomparse

Qui parliamo di cose davvero serie. Se già utilizzi WHMCS da un paio d'anni e prmetti la registrazione dei domini, è possibile che tu abbia già avuto a che fare con questo problema.

Sto parlando delle voci che scompaiono dalle fatture esistenti lasciandoti con fatture vuote o con altre che si presentano come segue (da notare il bilancio negativo).

In origine questa proforma aveva due voci:

• Silver - example.com
• Domain Renewal - example.com

Che fine ha fatto il rinnovo del dominio? WHMCS lo ha rimosso silenziosamente perché il cliente ha rinnovato il dominio in questione da un'altra proforma. Vediamo cosa è accaduto.

In passato era possibile per i clienti rinnovare inavvertitamente due volte uno stesso dominio. Da una parte c'era WHMCS che emetteva la proforma per il rinnovo un certo numero di giorni prima scadenza. Dall'altro il cliente era libero di rinnovarlo in qualsiasi momento dall'area clienti.

Oggi è ancora possibile avere due proforma rifrite allo stesso dominio. La differenza è che quando una delle due viene pagata, WHMCS rimuove la sua controparte nell'altra proforma. In questo modo il cliente non può rinnovare due volte lo stesso dominio. Questa tuttavia è una soluzione stupida che apre a problemi ben più grandi.

Come posso spiegare e contabilizzare la fattura risultante? Gli importi sono sbagliati. È semplice matematica. Tra l’altro se la fattura in questione non aveva altre voci, si finisce con l'avere una fattura vuota.

Stando a quello che dice WHMCS, questo non è un problema né un bug ma (cito testualmente) "Un modo elegante" di risolvere il problema dei doppi rinnovi. Sinceramente non vedo come creare errori di fatturazione possa essere definita una "soluzione elegante".

Ci sono molte discussioni dove si chiede come poter disattivare questa funzione ma il punto è che non si può. Non dimentichiamo WHMCS adora imporre le cose dall'alto. La cosa triste è che i doppi rinnovi avvengono ugualmente per via dei pagamenti automatici.

Calcoli strani

WHMCS non ha superato l'esame di matematica ed il seguente screenshot ne è la prova. Quella che vedi qui è una fattura che contiene due transazioni. Una positiva e l'altra negativa.

Che tu ci creda o meno in WHMCS 12.20 più -12.20 fa 24.40. Lo scenario si può riprodurre aggiungendo una transazione negativa e si verifica perché il segno meno viene ignorato ed è così che la fattura risulta dovuta mentre in realtà non lo è.

Inconsistenza del VIES

Lo staff di WHMCS crede che la fatturazione sia un gioco infatti non è un segreto che il loro VIES abbia dei seri problemi. Ignora concetti come il tipo di attività e lo split payment. Lascia che ti dia un esempio che riguarda l'esenzione delle tasse.

L'esenzione dipende da vari fattori e controlli che WHMCS ignora. Con il codice sono riuscito a "spiegare" a WHMCS come comportarsi quando si verificano determinati eventi (es. cron, modifica dati cliente, registrazione cliente) ma c’è un pulsante che non rispetta alcuna regola.

La modifica dell'esenzione da questa pagina non fa entrare in funzione l’hook point ClientEdit il che significa che non può essere eseguito alcun controllo. La bella notizia è che ho segnalato il bug che è stato risolto nella v8. Che rarità!

Navbar e Sidebar

Non sono i miglior sviluppatore al mondo ma certe cose in WHMCS sono tortuose. Per darti un'idea, dai un'occhiata al diagramma di flusso in basso che mi tocca seguire per correggere determinate cose. È un tantinello ironico ma è la realtà a cui sono sottoposto quotidianamente.

Navbar e sidebar non fanno eccezione. Non è accettabile che si debba imparare il PHP o assumre un programmatore per cambiare un pulsante. Dovrebbe essere un'operazione semplice che si può fare da interfaccia.

Benvenuto, nome sbagliato

Supponiamo che tu abbia un account con i seguenti sub-account.

Ora prova ad effettuare il login nell'area clienti con il sub-account Mark White ed ecco come WHMCS ti darà il benvenuto.

Non importa quale subaccount utilizzi. Per WHMCS sei sempre "Anna", il primo sub-account in elenco.