Модуль оплаты QIWI для osCommerce

[SS20]

Что же касается описанной Вами ситуации, то это форс-мажор

Ошибаетесь, к форс мажору это никак не относится. Случай был описан на форуме ОЗПП, и там магазин давил на злоупотребление правом, и хорошо что судья вменяемый попался. А на самом деле суды по потребительским делам в основном решаются в пользу потребителя. Если Вы не нарывались еще то просто радуйтесь. А от ошибок никто не застрахован, да и телефон мог быть заявлен по той цене какой нужно, но быть последним и с браком, результат был бы тем же. Так что лучьше проверять. Если есть желание просвятится в области ЗоЗПП, пожалйте на форум Для просмотра ссылки Войди или Зарегистрируйся

Скажите лучьше как Вы решили проблему с регионами, у почты России и EMS почты названия несовподают. В частности у EMS еще есть ряд АО которых уже нет. Если оставить базу почты то регионы EMS не будут работать. Пока что склоняюсь сделать названия регионов полностью совподающими с EMS, а почтовые регионы уже к ним подтянуть. И еще, как у Вас с лимитом времени выполнения скрипта? Сайт EMS тормозит, у меня 60 сек на локалхосте нехватает соответственно вываливается ошибка php. А на хосте лимит времени вообще мизерный.

 

[Razgildjay]

Ну у меня несколько оффлайновых магазинов уже 19 лет. поэтому и о ЗПП имного еще о ком я наслышан. Поверьте, никто не станет подавать в суд, если вы ей прямо скажете, что последний экземпляр был с браком и деньги будут возвращены в течение 3 дней полностью. Покупателей бывает разных. Ежедневно кто-нибудь пытается угрожать судом. Ну вперед, пусть подают, я посмотрю на сколько их хватит. Работать можно по-разному. Вы идете на встречу клиенту, вы честны и открыты, тогда чего вы боитесь?
Кстати у друга была такая же история. Он купил аудиоколонки, но пока банковский платеж шел, колонки закончились в продаже. магазин предложил вернуть деньги на карточный счет или сберкнижку, или купить другие. Он выслал реквизиты картсчета и через пару дней деньги пришли. Все почти довольны и никакого суда.


Проблему с регионами я пока не решал. Но наметил путь действий. Введу дополнительную таблицу соответствий регионов почты (они у меня соответтсвуют основным регионам магазина) и EMS. Это позволит укрупнить раздробленные регионы EMS, которыми они уже и сами наверняка давно не пользуются.

Проблему с лимитом времени решить не удалось. Сервера EMS работают из рук вон плохо. Пробовал указать

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 3);

чтобы больше 3 секунд запрос прерывался, но он все равно думает доолго. Но это в Денвере, а на хостинге одновременно нормально летает. Однако именно по этой причине я использую кэш на города и регионы. 1 раз в неделю оно как-нибудь обновится, а чаще смысла нет. Есть подозрение, что данный список изменению не подлежит, новых городов-то не появляется, а старые все давно освоены.

Была еще мысль кешировать удачные запросы, чтобы лишний раз сэкономить на обращениях к серверу EMS. Скажем, часов на 6-12. За это время тарифы маловероятно, что изменятся. В крайнем случае, 1-2 отправки мимо кассы переживабельно. Все равно наложкой идет больше, а там на штарфных санкциях заработок. Но пока это только планы. Других задач хватает.

 

[SS20]

Короче добавил в таблицу zones еще одну колонку zone_ems и слил туда ems зоны. Несоответствие фактически только в названиях республик. Почта используем Алтай респ., а ems Республика Алтай. Теперь клиент регистрируемся по зонам почты, а в модуле ems дергаю регион из зон ems. Все гуд. Но блин как тормозит, на локале пришлось выставить 3600 сек на время выполнения скрипта. Что будет на хосте

 

[Razgildjay]

Что-то сервер EMS второй день не в духе Скрипт на хостинге успевает в отведенные 30 секунд, но расчет доставки не производится. Возможно срабатывает ограничение в 3 секунды на запрос ответа cURL. Хотя, почему тогда скрипт отрабатывает за существенно большее время не понятно.

В общем есть мысль плюнуть на все эти технические новшества почты. Толку от них 0 и реализовать отдельный скрипт, который запускать, например, по крону. Скрипт будет пробегаться по всем городам/регионам из списка EMS и передавать в каждый город вес с интервалом 0,5 кг. Словом пройтись по всей весовой таблице, а результат закешировать и юзать.
Даже если тарифы изменят, это произойдет, во-первых заранее, а во-вторых отправок EMSных немного, пару отправок можно и пережить (это на случай, когда все же тарифы изменят, а мы проспим).
За 2 года тарифы еще ни разу не менялись, дергать сервак каждый раз не айс. У меня стоит shipping estimator, он же при каждом изменении корзины запрос на одни и теже значения на сервер отправляет. Вывод очевиден - кешировать результат ответа.

 

[SS20]

Хотя, почему тогда скрипт отрабатывает за существенно большее время не понятно.

Может на серваке EMS что то типа очереди организовано.