Jump to content

Kian

GearHead
  • Content Count

    2004
  • Joined

  • Last visited

  • Days Won

    81

Kian last won the day on June 7

Kian had the most liked content!

Community Reputation

350 Excellent

About Kian

  • Rank
    Senior Member

Recent Profile Visitors

12145 profile views
  1. Not all developers implement _deactivate() function that's why you end up with unused tables in database. Of course you can delete all tables prefixed with crm_ but be advised that there's a chance this triggers fatal errors somewhere. It depends on how the module was coded. For example if for some crazy reason the module uses an action hook outside its folder (includes/hooks) and the hook performs a query on a deleted table... Oops something went wrong. Or again if the module needed some file to be included in configuration.php it will probably cause troubles. Simply put, delete all these tables but make sure that front & backend still load correctly.
  2. You better read this before making changes. In essence WHMCS doesn't keep historical currency rates and as we know rates fluctuate on a daily basis. On the invoice you must print the rate in effect on the date on which the invoice is issued. You can't do the math on the fly otherwise your numbers on invoices will fluctuate causing more than one billing error. In fact the same invoice will give different exchange rates depending on when customers download/view it. There are third-party modules that bla bla bla... good luck.
  3. Of course and it is actually really easy. Years ago I had a WHMCS page that was showing on Google Maps the location/address of all the authorized resellers of a provider (it was taking data from a specific client group). Openstreet is pretty much the same.
  4. On one hand numbers don't change but on the other you are left with no information about what rates were used for conversions. From a billing perspective this is a big issue since every accountant needs exchange rates. WHMCS doesn't give this information so in your example your accountant needs to manually retreive EUR/USD rate based on invoice date. The problem is that not only this is a boring process but also doesn't work properly due to currency fluctuations. The thing is that your accoutant should be using your conversion rates (the one set in WHMCS). Same goes for your own customers. They should know what currency rate you are using on their invoices. There are modules that allows to keep track of historical currency rates but that's a story for another time.
  5. That's the plan. The day I get rid of WHMCS and stop supporting all the nonsense I'll open source that. The only two problems are: I need to find a way to ensure that some unethical competitors don't steal the code for scammy stuff or to damage me. I have already experienced it multiple times for things ranging from SEO to my own blog and code I posted for free on Github. Shameless people. They stole my stuff, tried to take me down on Google and few weeks ago they even had the nerve to ask me to link to their website with rel="follow" so that I can pass my SEO juice to them 🤯 It's like the man who stole your car comes back to ask if you can pay for the annual vehicle inspection I'm not proud of my code in BX. The code is stupidly convoluted but that's not my fault. This is what happens when you work with the many bugs and silly things of WHMCS. It's like trying to tune an F1 car for Monaco GP and find out that it will be driven in a rally competition followed by drag race and moto GP 🤦‍♂️ The module is a cluster**** of super-long if() and hacks needed to prevent WHMCS from doing stupid things. I don't see how someone can understand/change it. I have troubles myself and every update of WHMCS forces you to play the russian roulette 😨🔫 I don't think so. How can you do that when WHMCS purposely issues invoices that make absolutely no sense? I mean, it even asks customers to pay wrong amounts. Of course you can find ways to fix such problems externally but the thing is that there will be a disrepancy between what you're recording and the reality. Fines and troubles are just around the corner.
  6. Probably a typo. Check console for js errors.
  7. Every multi-brand is not the same so the right one for you depends on what you're trying to do. Pure cosmetic? SEO? Domain-based restrictions? Invoice from multiple business numbers?
  8. You can find all information about electronic invoicing & WHMCS here. I understand that it's a 10000-words article but there's everything you need to know. There are no alternatives and will never be since the profit / complexity ratio is hugely unbalanced. As brian said, I'm no longer in the mood to work this hard on this platform. I'm focusing on a small group of customers and working on new projects not connected to WHMCS. If you have any question, probably this is the best place to ask 😅
  9. Just in case, here's the link to Price Discrimination section from europa.eu. I don't think so. That's not about server location but you being an EU-based company. Anyway I suppose there's a workaround. As long as you respect Automatic redirection on a website, you can have multiple "versions" of your website with different pricing. You should do like OVH. As an Italian citizen I can freely purchase anything I want from ovh.fr, ovh.de, ovh.it etc. Let's take a look at VPS. The same VPS costs: 5.47 € in Germany 4.60 € in Italy, Netherlands and Portugal 5.52 $ (4.52 euro) in Spain - I have no idea why they use USD in Spain 🤔 In essence you can have different prices for each country but you can't force people to use this or that website (or pricing structure) based on their location.
  10. Do you know when they made this change? I'm curious.
  11. Let me quote something I wrote somewhere else. If you are from Europe... Only very few people are aware of these rules. For sure big companies like GoDaddy and Amazon know that. That's why they operate using multiple websites. As for your other question about how to do that in WHMCS, I confirm you that it is possible but I won't share any details. Nothing against you 🙂
  12. It is a "feature" of WHMCS that causes billing errors. It can't be disabled and there's no workaround. According to WHMCS having empty invoices or ones with wrong amounts is an elegant solution to avoid another problem (I won't explain it). The funny thing is that this crazyness doesn't even anything. The problem they were trying to address with this solution still occurs.
  13. As a quick solution you could hide that line from viewinvoice.tpl and invoicepdf.tpl based on description (or tblinvoiceitems.relid and tblinvoiceitems.type if possible). Probably you should also spread the cost of this line (your 5%) over all other existing items. It's simple math. When foreach() invoice items sum its value to your markup / (number of invoice items - 1).
  14. Tax comes from WHMCS default settings on page load. You can't change that by switching country. You have different options. First. You could .click with jQuery the button that updates estimated tax. You will also need to display:none page body before .click fires to avoid visitors seeing the page loading twice. Second. Override tax name, rate and value in Smarty with ClientAreaPage action hook. You need to retrieve such values manually from database based on your brand. It's pretty boring. Third. This is a bit of overkill but you could replace default estimated tax logic with your custom one. It's super boring and depressing.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated