The bug does not take all the fields from the okopa when importing an order
The bug does not take all the fields from the okopa when importing an order. We made two test orders from two online stores - delivery by Ukrposhta - all the fields are in Horoshop, but when importing into Vanbox, only the city remains of all the fields. Postcode, street, house number, apartments are not displayed . then make a mistake so that the address is good to enter correctly - that is, it corresponds to your standard for automatically creating TTN - otherwise you just have to manually adjust it to your standard. Thank you.
Original question is available on version: ru
Answers:
Good afternoon. We form the address from the standard delivery_city+delivery_address fields. To make it work the way you want:
1. Program the delivery_city/delivery_address field in horoshop and write down the full address there
2. For 1 hour of revision on our side, we can make a setting to pull out the rest of the fields.
If you switch to our cloud, we will do the revision for free
1. Program the delivery_city/delivery_address field in horoshop and write down the full address there
2. For 1 hour of revision on our side, we can make a setting to pull out the rest of the fields.
If you switch to our cloud, we will do the revision for free
21.07.2021, 17:09
Original comment available on version: ru
Thanks for the answer.
2 The matter is that until recently pulled out all fields - the address did not correspond to your standard but nevertheless pulled out all data. So I think something is off.
1 Did I understand correctly that you can make a revision so that with good pas it will pull out all the fields in your format to automatically create a TTN? that is, it will no longer be necessary to edit the fields and set the correct sequence and commas?
2 The matter is that until recently pulled out all fields - the address did not correspond to your standard but nevertheless pulled out all data. So I think something is off.
1 Did I understand correctly that you can make a revision so that with good pas it will pull out all the fields in your format to automatically create a TTN? that is, it will no longer be necessary to edit the fields and set the correct sequence and commas?
21.07.2021, 18:13
Original comment available on version: ru
2. We haven't changed anything at home, perhaps you have chosen a different delivery method in which the address was written in one field and not spread by 5.
1. Yes, we will make the index go first, then the city and address. But this does not guarantee that all 100% of addresses will be recognized by Ukrposhta, cases are different
1. Yes, we will make the index go first, then the city and address. But this does not guarantee that all 100% of addresses will be recognized by Ukrposhta, cases are different
22.07.2021, 11:52
Original comment available on version: ru
2 sosmoe interesting that we never changed anything at all) clumsy but it worked and now it’s completely broken.
1 OK, do it, I have 5-6 hours paid there, write off one. If you need anything from me, please call me.
1 OK, do it, I have 5-6 hours paid there, write off one. If you need anything from me, please call me.
22.07.2021, 16:17
Original comment available on version: ru
And please correct all the fields, because there is also incorrect name and post payment
24.07.2021, 17:45
Original comment available on version: ru
Tell me, have you made a fix? My client also needs this upgrade.
https://crm-onebox.com/en/support/online-stores/9725-ne-zagruzilsya-adres-s-horo...
https://crm-onebox.com/en/support/online-stores/9725-ne-zagruzilsya-adres-s-horo...
28.07.2021, 11:32
https://qube-soft.com/ crm erp onebox qubesoft внедрение аналитика 1с интегратор
Original comment available on version: ru
I managed to find out that the bug arose on the side of horoshopa, the api stopped giving the full address, it is already fixed, but the revision is in force.
28.07.2021, 19:02
Original comment available on version: ru
ХШ writes that everything has been fixed, tell me when you can wait for the revision?
30.07.2021, 11:57
Original comment available on version: ru
Tell me, three weeks have passed, but there is still no improvement, is it worth it to expect?
17.08.2021, 10:26
Original comment available on version: ru
Sergey, checked the status of this task and how Horosop is now transmitting the address.
Using the example of the process https://optium.biz.ua/admin/customorder/order/63061/edit/, can you comment on whether the address from Horosop was loaded correctly?
Using the example of the process https://optium.biz.ua/admin/customorder/order/63061/edit/, can you comment on whether the address from Horosop was loaded correctly?
18.08.2021, 17:43
Original comment available on version: ru
Zamogilny Dmitry
OneBox production wrote:
Sergey, checked the status of this task and how Horosop is now transmitting the address.
Using the example of the process https://optium.biz.ua/admin/customorder/order/63061/edit/, can you comment on whether the address from Horosop was loaded correctly?
no, it loads incorrectly - Novopodkryazh, Novopodkryazh, 51046, st. Z.kosmodemyanska, d. x, that is, it loads in the format city, city, index, street, house. and your format is Zip code, city street house, sq. In addition, in the First name field, the Last name is written, but the first name does not write anywhere
18.08.2021, 19:05
Original comment available on version: ru
Changed the logic of transferring the address, the values of the city and the index will change places, wait for the update.
It is difficult to fix the problem with the name, values come from Horosop in one field, full name, IOF, IF, F, etc., i.e. customers fill it in randomly
It is difficult to fix the problem with the name, values come from Horosop in one field, full name, IOF, IF, F, etc., i.e. customers fill it in randomly
19.08.2021, 13:05
Original comment available on version: ru
Zamogilny Dmitry
OneBox production wrote:
Changed the logic of transferring the address, the values of the city and the index will change places, wait for the update.
It is difficult to fix the problem with the name, values come from Horosop in one field, full name, IOF, IF, F, etc., i.e. customers fill it in randomly
For Ukrposhta, in principle, it doesn’t matter full name, IOF, IF, F. You can do it as in the integration of NP - if there are two values in this field, then this is F and O, if one is F, if three, then this is the full name. the main thing is that when creating a shipment, these values \u200b\u200bwould be posted across the integration fields from the full name field for TTN
20.08.2021, 10:39
Original comment available on version: ru
and if the name falls into the surname field - is it not scary?
20.08.2021, 16:39
Original comment available on version: ru
Zamogilny Dmitry
OneBox production wrote:
Full name
Well, there are such surnames and names that we ourselves do not know what is where. I think you need to proceed from the logic that is usually written in the F_I_O format, that is, the first value of F falls into the surname field, the second into the first name and the third patronymic. With the new mail, there are no such problems, I think, and there will be no such problems with the UE. The main thing is that in the form of creating a TTN UE it would be drawn from the field of the client's full name (order.order_clientname) . and while the data from XSh comes in the old way, there is no update.
21.08.2021, 11:49
Original comment available on version: ru
Can you tell me when to expect revision? It's been like a month now with no result.
25.08.2021, 12:06
Original comment available on version: ru
today the revision has earned, in principle, so far everything is fine, but one side effect has appeared if the middle name field was empty, the "?" sign is written into it. Moreover, both for Ukrposhta and for new mail, TTN is not created with this symbol - it gives an error - therefore, you have to manually delete this symbol. please fix this bug.
28.08.2021, 12:01
Original comment available on version: ru
Zamogilny Dmitry
OneBox production
Employee wrote:
Changed the logic of transferring the address, the values of the city and the index will change places, wait for the update.
It is difficult to fix the problem with the name, values come from Horosop in one field, full name, IOF, IF, F, etc., i.e. customers fill it in randomly
Unfortunately, since yesterday, again, in 90% of cases, the U addresses are entered incorrectly.
10.09.2021, 20:02
Original comment available on version: ru
and please correct you did that the address for creating the TTN of Ukrposhta pulls from the client's address, but you need to pull from the address of the process.
13.09.2021, 17:45
Original comment available on version: ru
Zubarev Sergey
Optium
Client wrote:
Zamogilny Dmitry
OneBox production
Employee wrote:
Changed the logic of transferring the address, the values of the city and the index will change places, wait for the update.
It is difficult to fix the problem with the name, values come from Horosop in one field, full name, IOF, IF, F, etc., i.e. customers fill it in randomly
Unfortunately, since yesterday, again, in 90% of cases, the U addresses are entered incorrectly.
Saw the problem
Clients fill in the address in different ways, someone with a house, apartment is recognized correctly, and someone without, someone does not fill out the index
I can try changing the regex that parses the address, but is there a way to make the index and home fields required on the order creation side of Goodp?
13.09.2021, 18:39
Original comment available on version: ru
Zubarev Sergey
Optium
Client wrote:
and please correct you did that the address for creating the TTN of Ukrposhta pulls from the client's address, but you need to pull from the address of the process.
As far as I can see, this address was previously taken from the client field, can you illustrate what you mean by an example of a process?
13.09.2021, 18:47
Original comment available on version: ru
Zamogilny Dmitry
OneBox production
Employee wrote:
and previously taken from the client field
the same value is stored both for the client and in the order_clientaddress process field
13.09.2021, 18:49
Original comment available on version: ru
Zamogilny Dmitry
OneBox production
Employee wrote:
Zamogilny Dmitry
OneBox production
Employee wrote:
and previously taken from the client field
the same value is stored both for the client and in the order_clientaddress process field
yes, but it is saved when creating a business process, but since some orders still come with incorrect data or the client wants to change the receiving address, the manager habitually changes the process address, but still pulls the client's address in the TTN.
14.09.2021, 16:35
Original comment available on version: ru
Please join the conversation. If you have something to say - please write a comment. You will need a mobile phone and an SMS code for identification to enter.
Log in and comment
Copyright © OneBox 2025
