nopCommerce 1.8 roadmap. Let's discuss.
- 437
- 3231
- 2010/6/24
- United States
https://www.nopcommerce.com/boards/t/4434/ajaxjquery-cart-update.aspx
Check out this thread to see my progress with a jQuery/Ajax cart...
B
Check out this thread to see my progress with a jQuery/Ajax cart...
B
- 248
- 1446
- 2010/5/4
- United Kingdom
nopCommerce team | a.m. wrote:
It's implemented quite well. In order simplify tax rate confgiuration we'll improve "Fixed tax rate" provider to allow store owner to specify a tax rate for each of existing tax categories.
That's a good solution Andrei. It keeps things simple while allowing the store owner to use a non-standard VAT rate for certain products such as zero-rated books. Thanks very much.
It's implemented quite well. In order simplify tax rate confgiuration we'll improve "Fixed tax rate" provider to allow store owner to specify a tax rate for each of existing tax categories.
That's a good solution Andrei. It keeps things simple while allowing the store owner to use a non-standard VAT rate for certain products such as zero-rated books. Thanks very much.
- 248
- 1446
- 2010/5/4
- United Kingdom
paliktar wrote:
In that scenario it may be easiest to open two accounts?
Multiple account levels would be good though. We have a potential customer in the b2b sector who wants to have a master account (controlled by purchasing manager) with sub accounts below that, and he wants to be able to generate reports across the whole account and for the sub accounts. I've not been able to find even a pay-for off the shelf product that does that. We've had to quote for a bespoke solution. If there were sub accounts they could perhaps have seperate VAT numbers although I'd be concerned at the possible complexity.
Regarding VAT number I think that that it should stay at the address level not at client level.what if a client has 2 EU companies with 2 VAT numbers?
In that scenario it may be easiest to open two accounts?
Multiple account levels would be good though. We have a potential customer in the b2b sector who wants to have a master account (controlled by purchasing manager) with sub accounts below that, and he wants to be able to generate reports across the whole account and for the sub accounts. I've not been able to find even a pay-for off the shelf product that does that. We've had to quote for a bespoke solution. If there were sub accounts they could perhaps have seperate VAT numbers although I'd be concerned at the possible complexity.
- 248
- 1446
- 2010/5/4
- United Kingdom
ap3000 wrote:
The 0% for VAT registered customers inside the EU outside of the Netherlands is I believe catered for in Andrei's implementation of my submission. NopCommerce will charge 0% if the customer is shipping outside the EU and it will charge 0% if the user is shipping outside the Netherlands but inside the EU if the customer has a validated VAT number.
For all other customers (domestic customers and to EU customers who aren't VAT registered) it will call the active tax manager to calculate the VAT. Charging them different rates depending on what products they ordered wasn't going to be easy to set up but it would appear that Andrei's changes to the fixed rate provider has taken care of that :) So, once the store has calculated that VAT must be charged the 0%/6%/19% rate will come from the tax rate assigned to the product's tax category, using the fixed rate tax provider. That's my understanding from what Andrei has said, without yet looking at the code. I hope I'm right as that seems a good solution to me.
It's also a legal requirement for the invoice to display the shop's VAT number and the customer's VAT number if charging them 0%.
Beyond that the only thing that might be missing now is some UI goodness, in particular the ability for the store owner to manually check the web service results in the admin area, to have customers VAT numbers automatically or manually validated as they prefer, and to receive an email when a new number is submitted and/or validated. I provided some user controls and logic to do this. Not sure if it's been wired in or not.
In The Netherlands we have 4 VAT tax levels – 0%, 6%, 19% and 0% for EU outside The Netherlands. And those levels are not the same as in UK or Germany. Is this been implemented in way that I can manage this in easy way?
The 0% for VAT registered customers inside the EU outside of the Netherlands is I believe catered for in Andrei's implementation of my submission. NopCommerce will charge 0% if the customer is shipping outside the EU and it will charge 0% if the user is shipping outside the Netherlands but inside the EU if the customer has a validated VAT number.
For all other customers (domestic customers and to EU customers who aren't VAT registered) it will call the active tax manager to calculate the VAT. Charging them different rates depending on what products they ordered wasn't going to be easy to set up but it would appear that Andrei's changes to the fixed rate provider has taken care of that :) So, once the store has calculated that VAT must be charged the 0%/6%/19% rate will come from the tax rate assigned to the product's tax category, using the fixed rate tax provider. That's my understanding from what Andrei has said, without yet looking at the code. I hope I'm right as that seems a good solution to me.
It's also a legal requirement for the invoice to display the shop's VAT number and the customer's VAT number if charging them 0%.
Beyond that the only thing that might be missing now is some UI goodness, in particular the ability for the store owner to manually check the web service results in the admin area, to have customers VAT numbers automatically or manually validated as they prefer, and to receive an email when a new number is submitted and/or validated. I provided some user controls and logic to do this. Not sure if it's been wired in or not.
- 248
- 1446
- 2010/5/4
- United Kingdom
mikeal7 wrote:
On the subject of SSL, personally I'd like to be able to configure the site in IIS to require SSL for everything and have it "just work". From my tests it would seem that auth cookies flow across an open channel even when SSL is on.
The benefits of this would be consistent appearance and improved functionality with many payment gateways, at a lower cost and efficiency than SSL'ing the whole site. This should also help with PCI compliance. Actually this would be good for login as well (just a thought).
On the subject of SSL, personally I'd like to be able to configure the site in IIS to require SSL for everything and have it "just work". From my tests it would seem that auth cookies flow across an open channel even when SSL is on.
- 248
- 1446
- 2010/5/4
- United Kingdom
nopCommerce team | retroviz wrote:
I agree with you on 3 and 4. WRT to 5, I think source control can help here. Perhaps you guys should work in a branch and only copy to trunk when the code compiles and works. Then interested parties can get interim releases from trunk or you can offer nightly builds.
May as well have my say.
Mine are just architectural suggestions - have made these already Andrei, but to reiterate
1) If we are using POCOs and not the entity framework generated classes, then lets go code first (part of EF CTP4) and do away with the EDMX. Development should be domain driven, not database driven.
2) Implement the repository pattern, as now the business layer is tightly coupled with data access. We've gone from one extreme (bloated provider model where people could add their own database specific providers, but probably wouldn't want to) to another (simplified data access where people may want to implement their own data access layer (say L2S, NH, Subsonic or even back to classic ADO.NET and Stored Procs) but can't).
3) Implement dependency injection. Believe me, this does make development easier and makes your application more testable. If you were looking at using a different data access technology, and you had implemented the repository pattern, and you were using DI, you could migrate each repo one by one rather than all or nothing. My preference, StructureMap. And regarding pluggable architectures, it doesn't get much better than StructureMap's assembly scanning capabilities. Just drop in a dll containing a plugin and your application can load it and use it.
4) Testing, testing, testing. nopCommerce is becoming quite a large application and yet to this day we do not have even one unit test. Yes the community will help submit bugs when they are found but we need to make sure that nopCommerce is tested as well as it can be before a new version is released and people start upgrading.
5) More frequent releases. Why not release new versions more frequently, especially when bugs have been found and fixed. There is nothing wrong with releasing a new minor version that just contains a couple of bug fixes and maybe a single new feature. I think people would rather have this than wait months for each release.
Okay, those are my suggestions.
It's great that the community has so many suggestions for new features but for me, these are the points that should be addressed.
Mine are just architectural suggestions - have made these already Andrei, but to reiterate
1) If we are using POCOs and not the entity framework generated classes, then lets go code first (part of EF CTP4) and do away with the EDMX. Development should be domain driven, not database driven.
2) Implement the repository pattern, as now the business layer is tightly coupled with data access. We've gone from one extreme (bloated provider model where people could add their own database specific providers, but probably wouldn't want to) to another (simplified data access where people may want to implement their own data access layer (say L2S, NH, Subsonic or even back to classic ADO.NET and Stored Procs) but can't).
3) Implement dependency injection. Believe me, this does make development easier and makes your application more testable. If you were looking at using a different data access technology, and you had implemented the repository pattern, and you were using DI, you could migrate each repo one by one rather than all or nothing. My preference, StructureMap. And regarding pluggable architectures, it doesn't get much better than StructureMap's assembly scanning capabilities. Just drop in a dll containing a plugin and your application can load it and use it.
4) Testing, testing, testing. nopCommerce is becoming quite a large application and yet to this day we do not have even one unit test. Yes the community will help submit bugs when they are found but we need to make sure that nopCommerce is tested as well as it can be before a new version is released and people start upgrading.
5) More frequent releases. Why not release new versions more frequently, especially when bugs have been found and fixed. There is nothing wrong with releasing a new minor version that just contains a couple of bug fixes and maybe a single new feature. I think people would rather have this than wait months for each release.
Okay, those are my suggestions.
It's great that the community has so many suggestions for new features but for me, these are the points that should be addressed.
I agree with you on 3 and 4. WRT to 5, I think source control can help here. Perhaps you guys should work in a branch and only copy to trunk when the code compiles and works. Then interested parties can get interim releases from trunk or you can offer nightly builds.
- 248
- 1446
- 2010/5/4
- United Kingdom
theonlylawislove wrote:
Thanks for the heads up. This looks great!
So, we get a reference using EventContext.Current and then attach event handlers and that's all there is to it? That's going to be so useful for developing plugins. And yes, of course, the more events the merrier :)
Also, I noticed the new EventContext which is making my plugin/addon easier to install
Thanks for the heads up. This looks great!
So, we get a reference using EventContext.Current and then attach event handlers and that's all there is to it? That's going to be so useful for developing plugins. And yes, of course, the more events the merrier :)