The future of the address book

[mrbrdo]

So, before I invest too much time into this myself (as far as I need), what are the plans for the AddressBook? I imagine you are aware of its many issues and you are probably not using that for Vendo?
So my question really is if the future will be either of:

• do you already use another solution and do not plan to opensource it?
• do you already use another solution and do plan to opensource it?
• do you plan to rework the implementation in the near future and use that for Vendo?

Bonus question: do you plan to support EU VAT ID (B2B orders)?
@rafalcymerys I'll just tag you in hopes of getting an answer sooner, and also it has to do with the legacy frontend too.
Some of the issues:

• Fix user's shipping & billing address interaction with order #11660
• List all available countries in checkout instead of all countries (even if not listed in any Zone). #11711
  (to be honest, while the PRs above solve many of my problems, I think the AddressBook functionality is quite poorly designed and probably needs a complete rework to really work like it should)

[damianlegawiec]

I think these 2 PRs will significantly improve the experience.

The current address book implementation is quite old and it's actually ported & improved https://github.com/spree-contrib/spree_address_book plugin. Remember that changing / modifying address book behavior without a solid test suite is hazardous and risky. All checkout-related changes should be properly tested beforehand to not introduce breaking changes and business-severe bugs.

In vendo, we use a different checkout flow and heavily modified address book which probably won't work for every scenario (without the new flow).

[mrbrdo]

Is there something Vendo can do to help with that in the OSS version? Maybe to add specs based on the ones you use, in those cases where they apply or can be adapted. Besides already doing the above-mentioned PRs (which maybe can be merged?) I would probably be willing to fix some other issues if they are demonstrated by failing specs.
As mentioned I will probably also implement EU VAT ID (with VIES) at some point as I will need it for myself too. Unless someone already did that. It's quite common for shops in EU to allow B2B orders by entering a VAT number.

[rafalcymerys]

@mrbrdo VAT as a field is fairly simple (a lot of Spree instances have it added as a custom field), however the B2B verification process differs between Spree users from what I've seen.
Being able to do an automated verification via VIES would help though, so maybe you could propose where that would fit in terms of Spree's architecture? I think it would be a good reusable component, but I'm not sure what the extent of B2B support inside spree should/could be. From my experience the needs can differ quite a lot here.

I also looked at the two PRs you linked here - I remember reviewing them some time ago, but I held off with merging it. The one that lists available countries looks fairly safe, but I need to review the impact of the second one again. As Damian mentioned, this part of the system is not that well-tested + this may make upgrading even more difficult for existing users.

It would be great to rethink the address book in general and if we're doing any major changes there, make it a separate release so that it will also make an upgrade of an existing instance easier. Looking at your experiences, what are the major issues you've had with it so far? I have my own list, but it's probably incomplete.

[mrbrdo]

Well now you opened the opportunity too wide not to take advantage of it and I have to start with a little rant which has nothing to do with Vendo 🙂 Honestly it would be a lot harder to list what issues the address book didn't have. From the opened PRs obviously it doesn't even save and reuse the address correctly in the first place, and it effectively does not allow for different Zones for shipping (2nd PR). Even with those PRs I am still observing the issue that for example, if a customer decides to choose a new address, on the next checkout it will again offer only the first saved address, and you are doomed to that one forever it seems (or I'm too dumb to understand it, which says something too). Maybe I like to be a little overdramatic but I couldn't even call that usable if someone gave me that as production-ready code. It's hard to decide if it might be easier to just do it from scratch, I know it's very old code too anyway.
Also honestly after over 5 years of professional work with Rails, at first when I opened my webshop and after trying out Spree I ended up on OScommerce, an ancient PHP framework with pretty awful code. But it just worked. And Spree really didn't (especially memorable is locales and this). But since I have no interest in PHP anymore, I decided it was worth to invest some time in Spree and use my still favorite language & framework. And even though it cost me tens or maybe hundreds of hours I still prefer this to the OScommerce turd. And yeah it seems like all open-source e-commerce solutions are not that great. Either code is good and functionality is too limited, or vice-versa.
// rant off

Ok so to be more factual, about VIES and B2B VAT I have not looked into it enough to give a good answer, I think what I will do is add a column to addresses (billing address) and use some gem to do a activerecord validation on it and check it with VIES. After that I will use the column with the accounting system I use which is private (as you kinda suggested it usually is). I think it's quite enough just to be able to enter the VAT ID and to properly apply (or not) VAT. The hardest part will probably be about including the VAT in price total or not - so at least in Slovenia, if the business is from my country, I will have to charge VAT, but if the business is from another EU country, I have to not charge VAT. Didn't look into a good way to do that yet.

As far as the major issues, to recap from the rant above (and remember I am using the legacy frontend and some of these might be specific to that):

• does not remember correctly last used address without the PR patch
• interferes with having different shipping Zones (does not allow to choose the country correctly in this case)
• does not offer to choose which saved address to use, only to edit it (legacy frontend)
• sometimes it seems like it will remember the address by prefilling the fields, but sometimes it will actually give it as a radio box option (legacy frontend)
• more of a feature request: B2B VAT ID

I think the most logical thing would be to only provide the simplest functionality in core spree, that is only to remember a single address (last used address), and support different shipping zones. I think the address book functionality with multiple addresses should actually go back into a gem. At least if Vendo is not using this functionality anyway. It will not get maintained well enough and the current state is kinda really bad. And it will actually be easier to understand and fix it if it's packed into it's own gem. If you could just extract the simplest use case from your internal codebase and put that into OS Spree, I think it will be far better than this half-assed AddressBook we have now. The rest can be a gem.

[mrbrdo]

@rafalcymerys too much rant? 😄

[rafalcymerys]

@mrbrdo no, I just need to find a moment to sit down to it and analyze - I've been busy with finishing fixes for Spree 4.5 ;) Let me get back to it next week and share some thoughts.

[mrbrdo]

@rafalcymerys ah yes, I saw that. Congrats on the release!