HikaShop > Seblod > J2Store

  • Posts: 257
  • Thank you received: 17
  • Hikaserial Subscription Hikashop Business
11 months 1 week ago #275779

Hi Nicolas,
as always many thanks!

Address
As you know we have to or more addresses for each user:
- The Fiscal Address, the legal one where to emit the Invoice, the residence (this is valid for persons and companies)
- The Delivery Address, where to delivery the goods in that moment, the domicile (can be the Fiscal Address, so 1 address in total, or another one, or more than one...)
Now, as far as I understand the selected "default" one, is only the preselected address where I want to delivery the goods in that moment. But in any case we need the fiscal address to emit the invoice.
Right now, How is the Invoice Address managed ?

Solution:
1 - The first address should be the Fiscal Address and should be always "the first", undepending if selected as default or not.
2 - This one, the first, should be:
---- A - Configurable, through a plugin to handle the synchronization both ways. Somethin like the second plugin solution you mentioned.
---- B - Configurable, where I can select from other Extensions the HikaShop table where I have read and store datas just for this first Address.
3 - Anyway, ss you explaned, a guide explication on How to store format fields datas should be too useful for a lot of users here, a real need.

Now, I have to add two things:
1 - new Joomla 3.7 release brought to us the Custom Fields feature, we are seriuosly evaluating to leave Seblod for the new Joomla standard feature. Custom Fields mean that a new Address Profile tab can be created. This will be the new standard Profile Address where all Extensions, as HikaShop, can pick datas. The one where an Invoice manager have to pick the address. One time more, I think a development in this way is the future for HikaShop.
2 - Together with the Custom Fields it is been released the way to add / implement the Custom Fields to "your" component . What about to see this integration soon on HikaShop ?

Thanks for your attention!

Please Log in or Create an account to join the conversation.

  • Posts: 62779
  • Thank you received: 9005
  • MODERATOR
11 months 1 week ago #275816

Hi,

In HikaShop users have only one set of addresses. There is no distinction between billing or shipping.
And they can select one address as default among these. By default, it's the first one.
Then, when they checkout, they can select among these addresses the address they want for the billing and for the shipping. And by default, the default one is selected for both billing and shipping.

So since you're synching user accounts, and not orders, I think it's the default address that you want to synch.

The custom field feature of Joomla doesn't change the fact that a synchronization plugin would be needed. The custom fields feature of Joomla is not adapted for multiple addresses so we just can't use them directly, like it was already the case for the profile fields.

Intergating the custom field types in HikaShop so that you can create custom fields in HikaShop using the types available for Joomla is something we're currently looking at. It looks cool !

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 17
  • Hikaserial Subscription Hikashop Business
8 months 1 week ago #282335

Hi Nicolas,
I red around the forum that, may be, we can expect som news about Billing / Shipping addresses managing. Are you working on news ?

If not and in any case (Seblod) we have to work on a syncronization plugin. So:

1 - I'm going crazy because I'm not able to have back in the checkout the Billing and Shipment address as in Hika Demo . I have back only the Billing one, Please, What am I forgetting ?

3 - Is there a way to permit only 1 billing address, the default one. So, in our case thinking on a Seblod syncronization, the first one will be always the Billing address and with HikaShop will be able to add and select only more Shipping addresses ?

Please Log in or Create an account to join the conversation.

  • Posts: 22544
  • Thank you received: 3510
  • MODERATOR
8 months 1 week ago #282336

Hello,

In HikaShop 3 core we changed some elements in the structure so it is possible to have addresses only for shipping or only for billing.
But all interfaces are not fully compatible with that new database structure so the feature is not enable by default ; it still requires some development even if the core is ready.

Afterwards please understand that if your order do not have need of a shipping method, there is no shipping address asked neither.
You need to set weight on your products or force the usage of shipping methods.
That part is still the same since HikaShop 1.0 !

Regards,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 17
  • Hikaserial Subscription Hikashop Business
8 months 1 week ago #282392

Hi Jerome,
many thanks for your reply

Jerome wrote: In HikaShop 3 core we changed some elements in the structure so it is possible to have addresses only for shipping or only for billing.
But all interfaces are not fully compatible with that new database structure so the feature is not enable by default; it still requires some development even if the core is ready.

Please, When will be released approximately ? And, in special, Do you have any more information about the "new HikaShop 3 structure" ? (Thinking to work yet on a Seblod/HikaShop plugin)

Afterwards please understand that if your order do not have need of a shipping method, there is no shipping address asked neither.
You need to set weight on your products or force the usage of shipping methods. That part is still the same since HikaShop 1.0 !

Yes, we know that, thanks. We are investigating and testing it before to report the issue.

Last Edit: 8 months 1 week ago by joomleb.

Please Log in or Create an account to join the conversation.

  • Posts: 62779
  • Thank you received: 9005
  • MODERATOR
8 months 1 week ago #282400

Hi,

We don't have any release date for that yet. It will require a lot of work and we have other more pressing things planned for the near future. So I don't expect it to be released before at least 6 months or more.

The new HikaShop structure is basically the fact that we added an address_type column to the hikashop_address and that we already have some code to handle it in the core code of HikaShop.

If you want to allow only one billing address and one shipping address, you'll have to change the address bloc views of the checkout and maybe some of the code in the administrator/components/com_hikashop/helpers/checkout/address.php file, or implement the HikaShop checkout API in order to add your own view to the checkout in order to handle the addresses exzctly the way you want.

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 17
  • Hikaserial Subscription Hikashop Business
7 months 2 weeks ago #283781

Hi Nicolas,
"HikaShop checkout API", Please, Where can I read and learn more about it ?!?

Please Log in or Create an account to join the conversation.

  • Posts: 22544
  • Thank you received: 3510
  • MODERATOR
7 months 2 weeks ago #283782

Hello,

There is no documentation about it for the moment.
But the files can be found in the folder "helpers/checkout/".
Basically, it's an abstraction of the checkout blocks in order to have a common entry point for the future improvements.

Regards,


Jerome - Obsidev.com
HikaMarket & HikaSerial developer / HikaShop core dev team.

Also helping the HikaShop support team when having some time or couldn't sleep.
By the way, do not send me private message, use the "contact us" form instead.

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 17
  • Hikaserial Subscription Hikashop Business
4 months 4 weeks ago #288436

Hi guys,
we want and ready to work on the Seblod / HikaShop profile integration (syncronization).
As you know, we like to do something useful for HikaShop team. So, Recapitulating:

joomleb wrote: Address
As you know we have to or more addresses for each user:
- The Fiscal Address, the legal one where to emit the Invoice, the residence (this is valid for persons and companies)
- The Delivery Address, where to delivery the goods in that moment, the domicile (can be the Fiscal Address, so 1 address in total, or another one, or more than one...)
Now, as far as I understand the selected "default" one, is only the preselected address where I want to delivery the goods in that moment. But in any case we need the fiscal address to emit the invoice.
Right now, How is the Invoice Address managed ?

Solution:
1 - The first address should be the Fiscal Address and should be always "the first", undepending if selected as default or not.
2 - This one, the first, should be:
---- A - Configurable, through a plugin to handle the synchronization both ways. Somethin like the second plugin solution you mentioned.
---- B - Configurable, where I can select from other Extensions the HikaShop table where I have read and store datas just for this first Address.
3 - Anyway, as you explaned, a guide explication on How to store format fields datas should be too useful for a lot of users here, a real need.


The old Nicolas suggestion was:

nicolas wrote: ...Doing that properly would still require a plugin to be developed to handle the synchronization both ways.
We didn't start any work on that and don't have plans for now for that.

1 - If I was doing it for my own website, I would do a simple version without any settings. Just a plugin which would implement the triggers of HikaShop, Joomla, Seblod when a user is saved in order to convert and copy the data to the 2 others each time.
2 - If I wanted to do a cleaner solution, I would add settings to the plugin to be able to do some configuration on what field correspond to what field.
3 - If I wanted to do a releasable solution that I could potentially sell, I would actually create a component so that I could have a real configuration interface with a listing of rules and the creation/edition of these rules. One rule would allow you to select a "custom field" for each supported extension detected. It would also embed one or several plugins to integrate with the supported extensions. The extension would have triggers so that your could develop plugins to add support to other extensions.

If we were to work on that, we would of course do the last version so that it would be easy to maintain and grow in the future. But that would be a lot of work (a few times more than the first solution with a static plugin, which would already be quite some work).

Regarding the address, we now have a "address_default" field which tells the address that is selected by default when you go to the checkout. So I would synchronize with that address.
The tricky part would be when the customer try to change his default address in his addresses manager in HikaShop...


3 months 1 week ago Jerome confirmed a good news with HikaShop 3.x release

Jerome wrote: ...In HikaShop 3 core we changed some elements in the structure so it is possible to have addresses only for shipping or only for billing.
But all interfaces are not fully compatible with that new database structure so the feature is not enable by default ; it still requires some development even if the core is ready...


And Nicolas clarified

nicolas wrote: ...The new HikaShop structure is basically the fact that we added an address_type column to the hikashop_address and that we already have some code to handle it in the core code of HikaShop.

If you want to allow only one billing address and one shipping address, you'll have to change the address bloc views of the checkout and maybe some of the code in the administrator/components/com_hikashop/helpers/checkout/address.php file, or implement the HikaShop checkout API in order to add your own view to the checkout in order to handle the addresses exzctly the way you want.


Now, the questions are:

1 - Thinking on Seblod (or other components) / HikaShop (HikaMarket) profiles integration we still think on a Billing Address Profile syncronization that in our opinion should be one Billing Address for each account, while the Shipping Address could be more then one (one setted by default), maybe the same Billing Address, and, in case of more, only added through HikaShop interface.
How will work the Billing Address / Shipping Address Profile in the HikaShop 3.x point of view ?
At what point is the development ?

2 - A syncronization plugin still is needed, right ?
How should it works in your opinion to be a "fully integrated HikaShop new feature" ?

3 - What about the "HikaShop checkout API" ?
Can this news change what we discussed before about this sync profile need ?
Do you have any news on documentation about ? When the "HikaShop checkout API" will be useful ?

Last Edit: 4 months 4 weeks ago by joomleb.

Please Log in or Create an account to join the conversation.

  • Posts: 62779
  • Thank you received: 9005
  • MODERATOR
4 months 4 weeks ago #288477

Hi,

1. With the next version we'll introduce a new checkout workflow editor which will allow you to separate the billing and shipping editions on the checkout.
However, the addresses will still be usable for both billing and shipping.
We're planning on adding an option in the future to be able to restrict to only billing or only shipping addresses using the address_type as explained before.

2. Yes, it is still needed. Even as fully integrated to HikaShop, I would still make it as another extension/plugin.
HikaShop/system plugins can add their own menu elements in the backend with their own controllers and views. You can see an example of that with the email history plugin. The plugin itself embeds the controller, the views and its menu element in the Customers menu.
So you could add that way your own interface to configure rules to synchronize fields together between different extensions/Joomla.
You would also implement the different triggers (like onAfterAddressCreate and onAfterAddressUpdate for HikaShop) in your plugin so that it could synchronize the data of the address with other extensions when the addresses are changed in HikaShop.

3. The checkout APi of HikaShop is one of the best documented API we have:
www.hikashop.com/support/documentation/6...tation.html#checkout
You can also check the code of the user points plugin plugins/hikashop/userpoints/ which implements these triggers to be able to add a user points block to the checkout workflow.

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 17
  • Hikaserial Subscription Hikashop Business
4 months 3 weeks ago #288754

Hi Nicolas,
trying to build a standard (not only for Seblod) Profile integration.
In our point of view "Profile" should be the "Billing address" that sometimes, the most of times, could also be the "Shipping address".

Right now HikaShop define the address_default that is the one pre selected.
Is in development to split Billing and Shipping address through the new address_type field.

But, as far as we can understand, still there are some things to "solve" from HikaShop to permit integrations. Ok, we syncronize the X Profile with the HikaShop Address, but:

1 - How to limit the Billing address only to one address ? (A must also without the profile integration syncronization need).

2 - And, in case HikaShop users decide to permit more than one Billing Address per user, How to have the "default_address" just as an order display where the "1", the default one, is always the first one displayed in the dropdown Billing Address durig the checkout, but when another, let me say the Billing Address "2", will be selected, the Order and the Invoice will be emitted for the "2" Billing Address.
In this way we can perform a Profile syncronization always with address_default "1" and address_type "Billing".

3 - How to restrict the Billing Address only to be visualized and not "input" or "modified" from HikaShop ?
In this way some both ways syncornizations should be solved, pressing users to add/modify the default Billing Address in the Profile integrated extension (Seblod in my case).
At least for the "1" default one. While from HikaShop users can add a second/third... billing address.

4 - About "Format fields": as far as we can see, the problem appear to be only for address_state and address_country fields.
@Nicolas: you explained

HikaShop actually stores the zone namekey in the custom field value, not the name or english name of the field. That way, when you decide to change a zone name, you don't loose the connection between the address and the zone (otherwise, the users with already an address with that zone wouldn't get the taxes/shipping methods/payment methods/coupons zone restriction to match with them anymore). But we can't just put the namekey in the state/country field of CB or Joomla or Seblod as they won't understand it and will just display it as is.

Well, I really have some difficulties to understand this, because nobody can decide to change a zone name. Only a government. When happen I don't understand where is the problem to modify and/or change and/or add a new one in the zones.
So, for example I have the problem here in Panama, from 1st january 2014 a new " Panama Oeste Province " has been created. How we should "split" the old Panama province and add the new one ?
Anyway, please, How HikaShop perform that storing ?

Thanks for support!

Please Log in or Create an account to join the conversation.

  • Posts: 62779
  • Thank you received: 9005
  • MODERATOR
4 months 3 weeks ago #288769

Hi,

1. Such limitation will also be part of the improvments when we add the possibility to have addresses with an address_type.
The problem if you try to do that now is that addresses are used for both shipping and billing. If you restrict the addresses to only one for a customer, then it will be the same for billing and shipping as they use the same addresses.

2. I'm not sure I understand your text here... However, I would recommend to only synchronize the default address for now. And in the future, when address_type can be enforced, then you can synchronize the default address of the address_type billing.

3. It will be possible with the next version of HikaShop to have the billing address not modifiable on the checkout. In the registration form, you can remove the address fields with the setting "Ask address on registration" of the HikaShop configuration.
And in the user control panel of Hikashop, you can use CSS or a view override to remove the button to access the address manager of HikaShop.

4. The advantage of using a key instead of the direct name is that when the government decide the change of the name of a state, you can change the zone name in HikaShop and all the addresses which already had the old name will automatically get the new name. If we were using directly the zone name, then each user with the old zone name would have to edit its address in such event.
Anyway, that doesn't change much for you if you want to do a synchronization. You just need to search for the zone_namekey with the value in address_state or address_country in the hikashop_zone table and get its name or 2 or 3 letter code (based on what the other extension requires) and give it to the other extension instead of the value in the address_state or address_country.

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 17
  • Hikaserial Subscription Hikashop Business
4 months 2 weeks ago #289015

Hi Nicolas,

1

If you restrict the addresses to only one for a customer, then it will be the same for billing and shipping as they use the same addresses.

Please, How to restrict it now ?
When will be available the new release of HikaShop with improvement?

2

I would recommend to only synchronize the default address for now

As far as I understood, the issue is that in HikaShop users can always change the default address, this can cause unwanted addresses deleting / overwriting.
The first billing address added, the "default" address, should always be "the same", (a fixed list from first the "default" to the last added). The HikaShop could select the one to use during checkout and, at least, set which one will be the "pre-selected" there...

3

It will be possible with the next version of HikaShop to have the billing address not modifiable on the checkout.

Please, When will beavailable the new release of HikaShop with improvement?
A - The task here was and should be to have the "first 1" added, the "default one", billing address not editable, not only during checkout, but also in the HikaShop User Control Panel while from HikaShop users can add a second/third... billing address.
B - In other case, I'll have to find the lower address_id for the address_user_id. Should be good do it only one time to find the address_id to use and filling, but the first address entered, a must, shouldn't be deletable (the same for the first Shipping address entered, that is the billing one, for a mirroring reason.

4

The advantage of using a key instead of the direct name is that when the government decide the change of the name of a state, you can change the zone name in HikaShop and all the addresses which already had the old name will automatically get the new name.

Really, I don't understand. Sound like a really unnecessary complication: at least, there is always the zone_id you added in the #_hikashop_zone...
A - a government can decide the change of the name of a state, but also can be occuped, deleted, chenge name, splitted etc. etc. and this is valid not only for states, but also forcountries, regions and province.
B - the only official way would be to follow the international Country Codes rules: ISO 3166-1 - I noted there are a lot of uncompleted fields into the #_hikashop_zone, Why not update them with the Current Codes ?
C - You divided the countries / states in a strange way, not the international standard one, that I really do not understand: for example you assigned for "Country" Italy the "States" with Provinces, but Italy is organized in "Country" Italy > "Regions" > "Provinces"... doesn't mind the name (if states or regions), but is based on a three levels organization... Why ?

PS - In the same way I never understood the need to double the Joomla user id creating the HS user_id into #_hikashop_user, when HikaShop yet import the Joomla standard one as user_cms_id in the table for a HikaShop usage...

Last Edit: 4 months 2 weeks ago by joomleb.

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 17
  • Hikaserial Subscription Hikashop Business
4 months 2 weeks ago #289073

PPSS As you know I write all these things because I love HikaShop and I'm a collaborative spirit.
HikaShop born in an "unripe" joomla and has the merit to has solved a lot of "issues" bringing a lot of new feature, but now the things have canged:
- User Profile / Billing Addresses / Shipping Addresses: Joomla has internal Custom Fields (and a lot of CCKs) = just a connection with it with the joomla user id would be sufficient (joomla user id is already imported in HikaShop as user_cms_id). ( See previous post ). A new approach here,i have some ideas, is the first step for which I hope there is a serious reconsideration by HikaShop.
- Products: the Joomla "Section/Category" left space to the unlimited "Categories". Again, Custom Fileds (that can be integrated into other components). Joomla Articles are ready to be the base for an HikaShop products , each product should be an article, each article can be a product.
- Multilanguage: When a Product is an Article the standard joomla multilanguage is yet integrated. If users want and need can always use a third party like Falang
- Brands > TAG: In a situation like this one, for example, "Brands" they would not be any more than a TAG category...

"A new point of view" from HikaShop is needed. A new big step. A simplification on the path of integration.
All this would mean more integration, a quick development and in special new energies for the eCommerce issues with its Payments system that have began so complex that all the HikaShop efforts should be for those... (without forgive eTickets, Bookings, Reservations, Statistics and the Mobile future... a must)

Last Edit: 4 months 2 weeks ago by joomleb.

Please Log in or Create an account to join the conversation.

  • Posts: 62779
  • Thank you received: 9005
  • MODERATOR
4 months 2 weeks ago #289031

Hi,

1. Well, you'll need to modify core files of HikaShop here and there to support that. I don't have a list with the necessary changes to do that. Otherwise, that means I would have already developped that functionality... So I can't say more.
We plan the next release of HikaShop in 2 weeks. However, it won't handle the address_type yet. We don't have a date for that yet.

2. Well, you could remove the radio to select the default one in the customer area. It's just a bit of CSS or a view override.
That will, the default address will always be the first one of the list.

3. 2 weeks
This feature will only concern the checkout.

4.
A. If we weren't using the address_namekey, we would have used the address_id.
Using something else than the zone name, like a namekey or id, allows you to display differently the selection based on the situation.
For example, you could translate the zone names in different languages with Falang and that way, you could adapt the names based on the language of the customer.
Besides that, different zones in different countries can potentially have the same name. Using the name directly in the address_state field would be inpractical for zone restrictions of coupons, shipping, etc.
B. Because it takes time, it's not fun, and it doesn't have much use since they are normally not used by any shipping or payment plugin. But if you do (you can fill them in in the administrator/components/com_hikashop/_database/zones.sql file), we'll be happy to integrate them by default in HikaShop.
C. We used a pre-existing database of states and countries and links between. So there is no deep meaning regarding what we chose.
Note however that for most countries there is no use in selecting a state. The post code is enough for the country's post. Many merchants will thus deactivate the state field if they only sell locally.
For the countries where it really matters, like the USA for example, we used the states that are needed for the routing of packages for the post.

PS: That's because users in HikaShop doesn't necessarily have a Joomla user account. This is used for the guest mode of the checkout where the customer doesn't has a Joomla user account, but we still need a user id and his email address to identify him.

Please Log in or Create an account to join the conversation.

Time to create page: 0.282 seconds
Powered by Kunena Forum