Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Recommended Posts

Well, I'm finally working on this. So far I've added language id, customers gender and order status id to the class, table and checkout process, those are easy additions.

 

I'm now working on shipping and payment methods; I'm studying both classes as I'm not familiar with them. Storing their ids on the orders table is easy, but is there already a function already into core to retrieve class title by providing class id or do I need to write my own?

Link to comment
Share on other sites

  • Replies 69
  • Created
  • Last Reply

For shipping, not just the title. Enabled shipping modules return a quote to the shipping class, called from checkout_shipping. The quote is (if the method is valid for the order) an array that includes the title, along with the cost.

 

I think the title currently gets stored for the order, but if you need a function to get only a module title, I believe that you'd need to add one to every shipping module to return it. 

 

On the other hand, if you need to know the class name of the module, you'd just have to change the shipping class to return it in the array of methods to checkout_shipping, and then you'd need to change checkout_payment to store the selected shipping class in the order. 

 

 

And now, the elephant in the room: what are you intending to do with a function that returns class title by providing class id (whatever that is)? As previously discussed, it won't always work. It will have to cope with the class not existing.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

Both payment and shipping modules have the title as a public var, so if you can instantiate the class, you can get the title in your current language without a function. If you can't instantiate the class, you're screwed anyway.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

For shipping, not just the title. Enabled shipping modules return a quote to the shipping class, called from checkout_shipping. The quote is (if the method is valid for the order) an array that includes the title, along with the cost.

 

I think the title currently gets stored for the order, but if you need a function to get only a module title, I believe that you'd need to add one to every shipping module to return it. 

 

On the other hand, if you need to know the class name of the module, you'd just have to change the shipping class to return it in the array of methods to checkout_shipping, and then you'd need to change checkout_payment to store the selected shipping class in the order. 

 

 

And now, the elephant in the room: what are you intending to do with a function that returns class title by providing class id (whatever that is)? As previously discussed, it won't always work. It will have to cope with the class not existing.

 

Yes storing the class is easy and I've done it. I have to look at why the shipping class returns the class id as two words (XXX_XXX)"0 or whatever it does.

 

I had tought to check for the name, and if it doesn't exists then add a class "0", "notfound" or "other". Hopefully the method will not be deleted but just uninstalled, so it should work fine in most cases.

Link to comment
Share on other sites

Both payment and shipping modules have the title as a public var, so if you can instantiate the class, you can get the title in your current language without a function. If you can't instantiate the class, you're screwed anyway.

 

Thanks, that's what I was wondering. I'll see if it's better to call the class or read the language file directly.

Link to comment
Share on other sites

Thanks, that's what I was wondering. I'll see if it's better to call the class or read the language file directly.

 

You still haven't said what you want to do with it.

 

Assuming:

- you want the title in the admin language, consistently

- you want to use it in the admin interface as a label for something (perhaps when you've created your own shipping method by copying another one and not bothered renaming it sensibly?)

- you really think it's worth all the bother to do this

 

A solution would be to store somewhere, presumably a config variable, a mapping of class name to title, and interrogate that to get the title.

 

You would populate it by amending the admin interface, so that when you install a method (payment or shipping), it gets set (or updated) for the class you're installing. When a module is uninstalled nothing changes. 

 

You would need a take-on script to populate it for all currently installed methods. You'd need to fix the distributed install database to match too.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

For shipping I've just used to make a report that displays each shipping method usage. I've done in the past with some hardcoded language titles in the report.

 

In fact, for my personal use it would onle be needed to have the class name, but I thought it would be a good idea to retrieve the class title and put it in the orders class; I'm thinking you're right and maybe as you said it's not worth the effort and the extra code added, and if someone needs it for an addon it can be programmed later.

 

For payment method I've used it several times, one of the applications I found was making a paypal button on the account history to allow preparing orders before asking for payment. This time I also had to hardcode the payment method names in all languages and I could not figure how to make it a real addon to share because of that.

 

What is really important I think is having a class name or id instead a localized name; from that point you can do anything.

Link to comment
Share on other sites

I just found another use for shipping method id: You can't know if a certain postage method is taxable or not as only the final cost is stored on the orders_total table.

If you want the invoice to reflect tax collected you can't include postage taxes as you don't know if the total has any tax added.

 

Do you consider it should be added to the database in any way?

Link to comment
Share on other sites

I just found another use for shipping method id: You can't know if a certain postage method is taxable or not as only the final cost is stored on the orders_total table.

If you want the invoice to reflect tax collected you can't include postage taxes as you don't know if the total has any tax added.

 

Do you consider it should be added to the database in any way?

 

Have a check through the forums, there's quite a lot of discussion on this. If I recall correctly, the shipping amount held in the order class during the checkout process doesn't have tax in it, so it's a pain if you want to use it during checkout, but it all gets sorted out at the end and the order total is the shipping including tax, or if your settings are to show tax separately, the shipping order total is without tax but the tax total includes shipping tax. In short, it comes out right on customer orders.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

Yes I'm reading all those issues, especially with paypal.

 

What I meant is a problem with the invoice, that is generated after the order is placed; When you print the invoice you can see tax for each product, but you can only see the total postage cost, with tax added if applicable, but you don't even know if it has the tax added or not. So, for example, you can't calculate the total tax of the order.

 

It's a real problem ie. in EU exists VAT-exemption for public postal services in EU VAT law, while other services are charged with VAT.

Link to comment
Share on other sites

(continue)  There are several ways it could be done: I think the easier way (it requires less changes) is adding a shipping_tax_rate column to the orders table that is filled when the order is processed, so you may know the tax amount that has been charged for postage and make any calculations needed.

Link to comment
Share on other sites

@@piernas, in my opinion, you're thinking about this backwards, but I can see why you want to do it that way.

 

We should be producing an invoice that represents a tax calculation that has already been performed. We should just be displaying information that was recorded when the order was created. If you perform another calculation, there is a significant risk that you will not get exactly the same results as the first time, either through rounding errors or because your code isn't the same. 

 

In the UK, we're supposed to keep a record of the transactions, not work them out again. That said, I think a lot of shop and even accounting software cuts corners on this.

 

If what you want to know is the amount of tax that's charged on the shipping, that's what you should store at the time that it's calculated, as well as the rate (but only so you can display it). 

 

However, if I remember right, that's not the only thing missing. Maybe you don't know if the tax order total includes shipping tax or not too, because that depends on your store settings at the time of the calculation. This seems to me to be a horrible cludge that's probably ended up being there because tax requirements have got more complicated over the years and it was too hard to sort it out properly. I know about this on 2.2 rather than 2.3, but I'll bet it's the same. Is it different in 3?

 

I think, in an ideal world, I'd like to see:

- tax order total is always that, a total of all the tax on the order. I don't know if other places have other requirements. Perhaps in some places you need more than one line for the total tax to different collectors (state/federal)? I don't know.

- a way of making sure you can show all the items on the order, including shipping, with corresponding tax rate (each line either inc or ex tax, depending on store settings at the time of order)

- producing an invoice is just printing off the data in the order.

:wacko:

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

We should be producing an invoice that represents a tax calculation that has already been performed. We should just be displaying information that was recorded when the order was created. If you perform another calculation, there is a significant risk that you will not get exactly the same results as the first time, either through rounding errors or because your code isn't the same. 

I think, in an ideal world, I'd like to see:

- tax order total is always that, a total of all the tax on the order. I don't know if other places have other requirements. Perhaps in some places you need more than one line for the total tax to different collectors (state/federal)? I don't know.

- a way of making sure you can show all the items on the order, including shipping, with corresponding tax rate (each line either inc or ex tax, depending on store settings at the time of order)

- producing an invoice is just printing off the data in the order.

:wacko:

 

@@BrockleyJohn you're right, this is how it should be. All the calculations should be done at once on the order processs and saved then into the tables.

 

But I fear these modifications requires deeply changing  the order process. From what I've seen some people are reluctant to introduce simple changes like adding a field to the orders table and class; Can't imagine what they'd say about this...

 

I just know how VAT is applied within Spain and partly in the rest of the EU (it's a pain in certain cases like B2B intracom, universal postal service, VAT-exempt states or some other exemptions) but I don't know anything about other countries, so it's possible that in some particular places are higher requirements as you mention.

 

The real thing is, with just the information contained in the order, it's impossible for me to get the data for the VAT invoice without making manual calculations and inspecting postage one by one (unless I charge VAT on all postage costs by default). You need to know the tax applied to postage cost at least.

Link to comment
Share on other sites

@@piernas, in the UK it's not an issue. If we offer a shipping service and we're VAT registered, then we have to charge tax on our service of shipping, whether the carrier charges to us include tax or are exempt. We have exemptions for certain classes of goods that might be sold, but I've never worked with a store that sells any of them.

 

Maybe we also need a non-EU perspective on the this. @@Gyakutsuki do you care about shipping tax? I guess even if you ship to US you'll have a different set of requirements than they do there.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

Hi Brockley,

 

In Canada, the taxe is not simple, but you have a tax on the goods and you have a tax on the shipping. There is one year ago, the tax has simplified in one taxe for numerous states or 2 taxes others states (like Quebec).

Depends what you sell, the final price  can be with tax or not, there is lot of exceptions. In Quebec, for example, the tax on the the foods are very weird.


Regards
-----------------------------------------
Loïc

Contact me by skype for business
Contact me @gyakutsuki for an answer on the forum

 

Link to comment
Share on other sites

@@piernas, in the UK it's not an issue. If we offer a shipping service and we're VAT registered, then we have to charge tax on our service of shipping, whether the carrier charges to us include tax or are exempt. We have exemptions for certain classes of goods that might be sold, but I've never worked with a store that sells any of them.

 

Maybe we also need a non-EU perspective on the this. @@Gyakutsuki do you care about shipping tax? I guess even if you ship to US you'll have a different set of requirements than they do there.

 

I'll have to talk to a VAT specialist about this, as I'm not 100% sure if I should charge VAT on postage or not. I've heard contradictory opinions and I didn't find a real proof for now. Someone has told me it can be considered as suplementary expenses, some others told me it mus be subject of VAT.

 

Anyway, if both of us sell outside UE we don't charge VAT, so it's still important for UE shops to know if the shipping has tax or not if you don't want to do it manually one by one.

 

@@Gyakutsuki, so you have two different tax rates for products and for shipping in Canada? Any other from different countries could tell us how it works in their country?

Link to comment
Share on other sites

In reality at Quebec, we have 2 taxes, one to apply on the product, one to apply on shipping for example, but the rates is the same. Also the rates can change if you send in other states (Ontario) like in Europe for the Numeric services.

 

ex if the products have not taxes but when you apply the shipping, you must apply the rates !! That's the regulation, but  also you can do apply the taxe on the invoice product price + shipping = total + taxes.

ex

product

tax1

tax 2

 

shipping

tax 1

tax2

 

or

 

product

shipping

tax 1

tax 2

 

or

 

product

shipping

tax

total

 

detail tax 1 and tax 2

 

 

You can also apply  the sum of the taxe but on the invoice, the taxes must appear (details).

 

In France all the product have one taxe, .

If you sell outside of France, there are no taxes

but you must apply the taxe of another country if you sell numeric services (new europe law since /01/2015))


Regards
-----------------------------------------
Loïc

Contact me by skype for business
Contact me @gyakutsuki for an answer on the forum

 

Link to comment
Share on other sites

In France all the product have one taxe, .

If you sell outside of France, there are no taxes

but you must apply the taxe of another country if you sell numeric services (new europe law since /01/2015))

 

I missed that one. What's a numeric service?

Link to comment
Share on other sites


Regards
-----------------------------------------
Loïc

Contact me by skype for business
Contact me @gyakutsuki for an answer on the forum

 

Link to comment
Share on other sites

I missed that one. What's a numeric service?

 

digital - downloads, streaming and so on

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...