Рубрика: Интернет-магазины

Реализация корзины

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

  1. Корзина хранится в БД
  2. Если пользователь известен (залогинен), то id корзины записывается ему в профиль
  3. Если пользователь неизвестен (гость), id корзины сохраняется в долгоживущую cookie

Надо предусмотреть действие на случай, если гость накидал товаров в корзину, а потом авторизовался и у него оказалась еще одна, непустая, сохраненная корзина.

Нужно предусмотреть механизм удаления старых корзин.

Почему бы просто не хранить все это добро в сессии? Спросите у маркетолога, какие идеи у него появляются при словах «брошенная корзина». :)

Кстати, бегло просмотрел несколько бесплатных скриптов — такого функционала не увидел. Максимум хранят корзину у известного пользователя, а корзину гостя в сессии.

Оформление заказа

В который раз покрутил разные магазинные скрипты, рассматривая процесс оформления заказа. Magento, PrestaShop, Webasyst. Все грустно чрезвычайно. При оформлении заказа все еще запрашивается куча ненужной информации и, похоже, никаких подвижек в сторону улучшения нет. Идея состоит в том, что от клиента для оформления заказа нужен минимум информации — страна и регион (если страна делится на регионы). E-mail опционально. Телефон тоже. Все остальное вообще нужно спрашивать только тогда, когда человек определился с методом доставки. Если самовывоз из офиса, то достаточно просто придти и назвать номер заказа. Если один из пунктов самовывоза курьерской службы, то, например телефон. Если почта — то индекс, адрес, ФИО получателя, если курьер — телефон и адрес. В общем идея в том, чтобы человек заполнял как можно меньше полей. Вот, как у Enter.Ru — указал, что ты в Москве, выбрал пункт самовывоза, написал номер мобильного и жди SMS о том, что заказ можно забирать. Какая в этом случае разница, как человека зовут и какой у него e-mail? Читать далее Оформление заказа

WebAsyst ShopScript убрать авиадоставку из почты

Раз уж я взялся за модули почты, то и до WebAsyst ShopScript руки дошли. Давно хотел убрать из ее «родного» модуля выбор типа доставки — «Наземная» или «Авиа». Все равно почта все по-своему делает, зачем клиента путать? оставим наземную и все. Тем более, что тут на 5 минут занятие.

Изменения надо вносить в файл /published/SC/html/scripts/modules/shiiping/class.russianpost.php. Все изменения вносятся только в метод calculate_shipping_rate()

  1. Закомментарить все присвоения переменной $AirCost. Необязательно, но пусть будет для полноты картины.
  2. Закомментарить все действия с массивом $Rates
  3. После проверки на наличие товара с бесплатной доставкой в заказе убрать все дополнительные проверки и просто вернуть стоимость доставки.

Читать далее WebAsyst ShopScript убрать авиадоставку из почты

Почта России для PrestaShop 1.5: первая рабочая версия

Я ее домучил. Сначала коротко о том, что умеет. Умеет считать доставку по формуле почты: деление на зоны  1-5, цена за первые 0.5 кг, плюс цена за каждые следующие 0.5 кг., 30% наценки за «тяжеловесную» посылку, плюс проценты за объявенную стоимость.

Все очень сыро, надо попробовать на тестовых инсталляциях.

Не стесняйтесь писать о том, что не работает, чего нехватает и как сделать лучше. У меня, кстати, тоже много вопросов по написанию расширений к PrestaShop.

Чего нет:

  • Считает только по России. Можно, конечно, назначить что какой-то штат или область другой страны входят в одну из зон почты, но это белиберда получится.
  • Расчета наложенного платежа. Скажите, как его считать. Знаю, что обратно деньги идут почтовым переводом, т.е. надо просто считать его стоимость и прибавлять к стоимости отправления, только вот мало того, что там целый алгоритм, зависящий от суммы, так и еще есть исключения дл некоторых регионов.
  • Не учитывает, что в некоторые регионы есть т.н. «авиадоставка». Я подумаю над этим. Принимаются пожелания, как это должно быть реализовано, я, пока, склоняюсь с варианту добавления исключений по диапазону индексов.
  • Максимальный вес посылки просит указать, но внимания на него не обращает. Хотел вообще обойтись без настроек PrestaShop, но оно, почему-то, вообще не хотело запускать модуль, если он не использует ее встроенные диапазоны. Поэтому надобность в этой настройке отпала, потом уберу.
  • Подразумевает, что используются килограммы и рубли. Никакой конвертации пока нет.
  • Локализация где-то есть, где-то нет. Не до нее было.

Читать далее Почта России для PrestaShop 1.5: первая рабочая версия

Модуль доставки PrestaShop 1.5

Медленно, очень медленно делаю модуль доставки почтой России для PrestaShop 1.5. Медленно по двум причинам: во-первых мне он сейчас не очень нужен, идет поиск дизайнера, верстальщика и паралелльно согласование хотелок с заказчиком. Во-вторых очень трудно разбираться со скриптом, пусть даже и написанным довольно грамотно, без всякой документации. Английским и французским я владею, конечно, в некоторых пределах чтоб понять, о чем пишут на форумах, но там не слишком много полезного.

Update: первая, вроде, рабочая версия.

Модуль, в начальной версии, будет считать доставку по России по формуле почты, с разделением на тарифные поясы, без запросов к серверу почты — они активно борются с такими вещами (непонятно зачем). Настроек будет довольно много, поскольку, например, надо будет назначить тарифный пояс каждому региону, на который поделена Россия. Поэтому модуль будет интегрироваться в меню «Shipping», вот как-то так:

Пункт верхнего меню с Почтой России

Структура модулей в версии 1.5 прилично изменилась по сравнению с предыдущей версией. Несмотря на то, что сохраняется совместимость, хочется, все-таки сделать именно для 1.5, учитывая максимум новых нововведений.

Очень много времени уходит на то, чтобы понять еще две вещи — ответов в Google на возникший вопрос «как правильно делать» нет, на форуме тоже нет и имеющиеся в распоряжении бесплатные модули используют старый метод, совместимый с 1.4

Пока работаю только над админской частью, тешу себя надеждой, что расчет будет сделать проще — с версии 1.4 там почти ничего не изменилось.

Читать далее Модуль доставки PrestaShop 1.5

One page checkout

Самое забавное то, что в PrestaShop реализовали функцию «оформление заказа на одной станице» (one-page checkout) примерно к тому моменту, когда мода на эту фишку прошла и многие магазины отказываются от такого способа оформления заказа. Слишком много полей, покупатель пугается сложности оформления, путается. Сдается мне, что WebAsyst реализует эту функцию, когда она совсем уже будет не нужна.

Увы, не успевать за тенденциями — свойство большинства, если не всех, коробочных продуктов.

PrestaShop 1.5

Вышла новая версия PrestaShop. Ждали ее с нетерпением, особенно встроенную возможность редактировать заказ из админки и возможность управлять сразу несколькими магазинами. WebAsyst’у есть куда стремиться и на кого равняться. Вот сейчас идет обновление автоматическое скрипта до последней версии, и оно гораздо более толковое. Во-первых создало архив с предыдущей установкой — есть возможность автоматически откатиться на предыдущую версию, если что не так. Во-вторых куча опций — обновлять/не обновлять тему, модули, оставлять-ли в покое сторонние модули или отключить их. В общем, пока очень радует.

Скидки в скриптах интернет-магазина

Готовлюсь сравнивать несколько скриптов интернет-магазинов и CMS, у которых есть соответствующие модули. Пока просто записываю мысли о том, на что обратить внимание. В итоге попробую свести это либо в какую-то таблицу, либо еще как-то систематизировать. Если в процессе я что-то упустил, то не надо стесняться написать в комментариях.

Часто возможность раздачи скидок выпадает из факторов, которые рассматриваются при выборе платформы. И зря. Трудно себе представить, какие фантазии могут придти в голову владельцам, маркетологам или рекламщикам магазина. Поэтому при выборе скриптов для интернет-магазина этот параметр никак нельзя упускать из виду. Во многих случаях я натыкался на жестко фиксированный набор различных скидочных программ, который причинял изрядные неудобства уже спустя несколько месяцев после запуска сайта. Зачем далеко ходить? Например, после установки модулей приема платежей с кредитных карт владельцу пришло в голову дать скидку за платежи наличными — те самые 3-4%, которые забирает себе эквайрер. А автор скрипта этого не предусмотрел. В таких случаях часто требуется вмешательство в основной код скрипта, что, конечно, расстраивает. И не просто расстраивает! Многие скрипты сейчас имеют возможность автоматического обновления, при котором либо все внесенные изменения, конечно, теряются, либо просто блокируют саму возможность обновления.

Модульность этого компонента скрипта интернет-магазина даст возможность комбинировать и видоизменять, гибко настраивать скидочную систему. Это очень важная составляющая, от которой, во многом, зависит успешность проекта. Читать далее Скидки в скриптах интернет-магазина

Почтовые адреса

Рассматривая кучу платных и бесплатных скриптов для создания интернет-магазинов, обратил внимание на то, что у большинства процесс оформления заказа далек от идеала. Это очень важный этап, который должен быть очень простым для покупателя, с минимумом заполняемых полей.

Сейчас хочу остановиться конкретно на блоке данных с почтовым адресом. Обычно это адрес доставки, но также это может быть адресом плательщика и отличаться от адреса доставки. Платит один человек, получает другой или как-то так. Не важно.

Здесь также пользователь должен с минимумом усилий указать максимум полезной информации. Во всех скриптах обычно заполняются такие поля:

  1. Почтовый индекс
  2. Страна
  3. Регион, штат или другая территориальная единица (если есть)
  4. Город
  5. улица, дом, квартира и т.д.

Для крупных городов, например, для Москвы или Санкт-Петербурга можно дополнительно спросить ближайшую станцию метро. В Webasyst Shop-Script это реализуется дополнительным полем.

Применительно к России возникает вопрос к 3-му пункту, у нас весьма пестрое административное деление. Самое простое — воспользоваться списком кодов субъектов РФ из Википедии. Но тут надо иметь в виду, что некоторые субъекты могут входить в состав других — автономные округа могут входить в состав краев и областей. Большинство реализаций скриптов этого не предусматривают, а зря. Деление на регионы должно быть не плоским списком а древовидным!. Стоп, не надо бежать срочно добавлять поле «parent_id» в существующую базу. Надо сначала погуглить на тему nested sets и проникнуться.

При этом регион «Москва» не идентичен городу Москва. При заполнении списка регионов об этом тоже надо помнить, Зеленоград также входит в состав Москвы, а доставка туда, как правило, отличается ценой.

Также имеет смысл хранить список наиболее крупных населенных пунктов каждого региона, чтобы пользователь мог выбрать город из списка или написать, если в списке нет нужного населенного пункта. Минимум опечаток — максимум точности при определении стоимости доставки.

Update. Раз уж речь зашла о древовидном хранении, то список страны-регионы_(области, края и т.д.) можно хранить в единой таблице. В ней корневыми элементами или элементами первого уровня (корень тогда будет «World» :) ) будут страны. Для классификации можно воспользоваться стандартом ISO 3166 и его подразделами относительно административных единиц.