Jump to content

Separate base and invoice currency


Andreix

Recommended Posts

Hi ,

I have a shop base currency in EUR. A customer puchases someting in USD, conversion rate is applied, invoice is in USD, payment in USD all ok. Customer remains with USD in his/her account.

One year later my EUR price is the same, but the conversion rate has changed. I update the conversion rate daily, so all products have current prices in all currencies.

What happens when the customer gets invoiced: does he/she get the same amount as last year or does he/she get the current price in USD as per the latest conversion?

Thank you!

Andrei

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

regardless of the currency, it means if I understand corectly that whmcs stores the number xx,yy and for the following invoices it just uses that number even if I change the product price. So its disconnected from the product in a way.  Could I use the bulk price updater to actualize the prices for all customers?

I think I will let it run once every moth for all customers to push the corect amount in USD.

 

Link to comment
Share on other sites

15 hours ago, Andreix said:

I have a shop base currency in EUR. A customer purchases something in USD, conversion rate is applied, invoice is in USD, payment in USD all ok. Customer remains with USD in his/her account.

if you had USD pricing on your WHMCS site, then the renewal price is set at the time of ordering and is usually the same as the purchase price (doesn't necessarily need to be and i'm thinking of products rather than domains).

so if they purchased something for $100 USD and that was its renewal price at the time of order, then the renewal price a year (or whatever) later would still be $100 USD.

if your base price is EUR, but WHMCS is updating your USD product pricing via the exchange rate updater in the cron each day, then even if the current purchase price of that same product is now $125, the renewal price for the existing service won't change (e.g it's still $100).

if you needed to keep your existing service renewal prices the same as the current pricing, then there are addons available for that - one being Auto Recalculate Prices.

Link to comment
Share on other sites

23 minutes ago, brian! said:

if you had USD pricing on your WHMCS site, then the renewal price is set at the time of ordering and is usually the same as the purchase price (doesn't necessarily need to be and i'm thinking of products rather than domains).

so if they purchased something for $100 USD and that was its renewal price at the time of order, then the renewal price a year (or whatever) later would still be $100 USD.

if your base price is EUR, but WHMCS is updating your USD product pricing via the exchange rate updater in the cron each day, then even if the current purchase price of that same product is now $125, the renewal price for the existing service won't change (e.g it's still $100).

if you needed to keep your existing service renewal prices the same as the current pricing, then there are addons available for that - one being Auto Recalculate Prices.

To my mind the WHMCS logic is wrong here - the renewal price should be the current not historical price.

I'm curious to know other peoples views on the behaviour and if they think it is correct the rationale for that 

Link to comment
Share on other sites

2 hours ago, MrGettingRatherFrustrated said:

To my mind the WHMCS logic is wrong here - the renewal price should be the current not historical price.

Yes I also think this is very arhaic, thought at the time when the world was much smaller.  As we move towards electronic invoices and direct payments this should be reconsidered from the groud up.

However to my problem I found a module Billing Extension . Lets see if they are able to sell that as it looks very good on the description. If i read corectly the docs you can also have multiple currencies on the invoice but its not 100% clear.

Link to comment
Share on other sites

7 hours ago, MrGettingRatherFrustrated said:

To my mind the WHMCS logic is wrong here - the renewal price should be the current not historical price.

I'm curious to know other peoples views on the behaviour and if they think it is correct the rationale for that 

I always renew at the same cost, Most of our suppliers do the same - I don't believe in jacking the prices up, the only fluctuation being exchange rates! I do of course change prices from time to time, but that affects new customers so it is exactly the logic I use 🙂

Edited by UnwilfulExpenditure
Link to comment
Share on other sites

On 08/06/2021 at 12:16, Andreix said:

regardless of the currency, it means if I understand correctly that whmcs stores the number xx,yy and for the following invoices it just uses that number even if I change the product price.

correct - it stores the renewal price (recurring amount) at the time of ordering in the database, and when the renewal time comes, that's the value that WHMCS pulls for the invoice.... it doens't update when you change your prices, nor on account of any exchange rate changes.

On 08/06/2021 at 12:16, Andreix said:

Could I use the bulk price updater to actualize the prices for all customers?

personally, I wouldn't... but if you do, take a backup of the database table before, because it's effectively just running SQL update queries directly on the table and there is no undo button. ⚠️

19 hours ago, Andreix said:

However to my problem I found a module Billing Extension . Lets see if they are able to sell that as it looks very good on the description.

I wouldn't see that module as having a long-term future... i'm not suggesting not to buy/test it, just to do so with your eyes open to the fact that no new features are being planned for it and that the developer is ultimately moving away from WHMCS (though he's not alone on that score!).

Link to comment
Share on other sites

1 hour ago, brian! said:

I wouldn't see that module as having a long-term future... i'm not suggesting not to buy/test it, just to do so with your eyes open to the fact that no new features are being planned for it and that the developer is ultimately moving away from WHMCS (though he's not alone on that score!).

I didn't have that information but they were quite slow and unattentive to new customers, but at least its a point to start. We could code everything from scratch, which remains an option for a bit later, but for start seems like a fair deal. I think it would work for at least a year at least.  Maybe until tan someone else will do something new.

yes optimism dies last ... 😄

Link to comment
Share on other sites

19 hours ago, Andreix said:

Maybe until then someone else will do something new.

I like optimism as much as the next guy, but I think on this, you should temper it - I don't think anybody will ever produce anything like Billing Extension in the future... certainly not from scratch (as Kian says, there is years of work gone into that and there will be things he knows in greater depth that not even WHMCS own development, or nearly any other third-party developer would know... the only caveat to that would be if/when Kian ever makes the source code available, there will be certain vultures (developers) nibbling on the carcass to strip out bits of his code to sell separately as commercial addons.

I think there is a valid argument that some of the features of it adds should be within an invoicing program by default rather than relying on a third-party addon to add them... with is a far more severe criticism of WHMCS and it's "unique" interpretation of invoicing than anything else.

On 08/06/2021 at 20:07, Andreix said:

If i read correctly the docs you can also have multiple currencies on the invoice but its not 100% clear.

you can do that anyway with modifications to the templates/hooks etc - but if BX does it out of the box, then that's one less customisation to make.

Link to comment
Share on other sites

  • 2 weeks later...

 

On 10/06/2021 at 7:29 PM, brian! said:

you can do that anyway with modifications to the templates/hooks etc - but if BX does it out of the box, then that's one less customisation to make.

I purchased the module and after some time I got it working ... mostly. It had some errors first but after a lot of trial and error it works ... except the part i needed in the first part.

So I need anybody that got BX working and uses snapshots and exchange rates. Basically there are 2 variables that seem not to initialize $bx_currencies and $notes that we would need.  This here is the main description: https://katamaze.com/docs/billing-extension/58/whmcs-historical-currency-rate-invoice 

Any help would be greatly appreciated. Yes I know we could use hooks and program this, but i want to avoid custom code as much as possible.

Andrei

P.S. We have tried support, we even purchased support with one day guaranteed response, but we have not received any non automatic feedback so far -1 week

Link to comment
Share on other sites

 Make sure you completed this step. Basically you need to place some snippets on top of your invoicepdf.tpl file. Same goes for Notes section and invoice logo (it's part of invoice snapshot). Just follow the instructions of the article I just linked.

1 hour ago, Andreix said:

P.S. We have tried support, we even purchased support with one day guaranteed response, but we have not received any non automatic feedback so far -1 week

I'm going to send you a refund right now. I will probably remove Support Pro & Business plan since I can no longer stand WHMCS.

Edited by Kian
Link to comment
Share on other sites

46 minutes ago, Kian said:

Make sure you completed this step. Basically you need to place some snippets on top of your invoicepdf.tpl file. Same goes for Notes section and invoice logo (it's part of invoice snapshot). Just follow the instructions of the article I just linked.

Hi Kian,

I did all that of course,  we also completed "Header and Footer Integration" as we use that. We also tried without header and footer and nothing.

 

49 minutes ago, Kian said:

I will probably remove Support Pro & Business plan since I can no longer stand WHMCS.

Reading thru older posts I understand what you say. Nevertheless there are still some of us that like and use what you do as it is very good. You and the Katamaze products do improve WHMCS in many ways and yes you are doing for many years now.  So thank you in any case!

Link to comment
Share on other sites

If bx_currency variable is empty it means two things:

  • There's no currency snapshot yet on your database. The module stores rates every time daily cron job runs and can't do anything for invoices issued before you installed it (past rates can't be retreived retroactively)
  • There's no snapshot for the given date. If you're viewing or downloading an invoice from 2019 (before you installed BX) there are still no currency rates to rely on

Basically this is the structure of the table in question on a system where I installed BX few hours ago.

sample404.png.90c43840d480b57bf940932f5b6e6b5a.png

As you can see there are yesterday's and today's rates meaning that I can include additional information about rates on invoices issued starting from 2021-06-18.

Edited by Kian
Link to comment
Share on other sites

1 hour ago, Kian said:

If bx_currency variable is empty it means two things:

  • There's no currency snapshot yet on your database. The module stores rates every time daily cron job runs and can't do anything for invoices issued before you installed it (past rates can't be retreived retroactively)
  • There's no snapshot for the given date. If you're viewing or downloading an invoice from 2019 (before you installed BX) there are still no currency rates to rely on

Basically this is the structure of the table in question on a system where I installed BX few hours ago.

sample404.png.90c43840d480b57bf940932f5b6e6b5a.png

As you can see there are yesterday's and today's rates meaning that I can include additional information about rates on invoices issued starting from 2021-06-18.

Yes this explains it.  have installed it several days ago, , but the table was empty indeed:

image.png.05b242c32f5e600f07762e7ad3083c08.png

cron is running as I can see, I ran it now by hand and I have 2 values now in bx_currencies table: 

image.png.0e4781e65a059b05dd1aecc128d150e9.png

I created now a new invoice,and I noticed that the php time was wrong, must be set separatly from server time .... anyway I created a new invoice on the 19th and on viewinvoice,tpl it works. 🙂

For the pdf it works as well with the file inclusion directly in invoicepdf.tpl and not in invoicepdfheader.tpl. 

Thank you all very much especially @Kian !

Edited by Andreix
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • 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