HikaShop > Seblod > J2Store

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!

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 ?

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.

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

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 ?

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!

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...

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)