31 марта 2013 в 17:52
Добрый день.
В ближайшем будущем возможно, будем разрабатывать для одной организации корпоративный сайт, который будет включать в себя электронный магазин.
Эта организация торгует довольно специализированным радиооборудованием и специализированным же ПО для него.
Сайт планируется многоязычный и это оборудование планируется через этот эл. магазин продавать как в России, так и за её пределами.
Разработкой электронных магазинов на Drupal я, к сожалению, еще не занимался. Тем более, если магазин будет многоязычный.
Сейчас разбираюсь с Drupal Commerce, которую решил под это дело использовать, и уже возникли такие вопросы.
1. Стандартная процедура оформления заказа, которая в DC - она для клиентов нормальная ? Или есть хорошие решения по её упрощению ?
2. Можно ли человеку, регистрируясь на сайте, одновременно регистрировать и свой профиль клиента для этого магазина. Например, чтобы при заходе на страницу user/UID были не только поля "логин", "пароль" и т.д., но и поля, относящиеся к профилю клиента - адрес, телефон и т.д. ?
3. Как лучше решить вопрос с методами оплаты ? Я предполагаю, что покупателями будут в основном не физические лица, а предприятия и организации.
Подключать кучу всяких методов оплаты по отдельности или лучше использовать какое-нибудь универсальное решение, например, как-то интегрироваться с сервисом типа "Робокассы" ?
3.1 Есть ли в DC решение, которое позволило бы сформировать счет к оплате через банк (хотя бы в виде документа для распечатки), чтобы там были банковские реквизиты организации-продавца ?
Комментарии
Да в принципе нормальная, проходють, оплачивають
Упрощать можно - я вот как-то накидывал модулёк, который корзину отключает: щёлк на кнопке "купить" - и сразу в оформление. А в целом - конечно, можно, на http://drupalcommerce.org/ и примеры были. В коммерце профиль клиента отвязан от профиля юзера - это разные сущности. Но их можно без особого труда связывать рулзами или через код: при выводе формы оформления заказа брать из профиля юзера под это дело заполненные поля. Тоже делал, проблем никаких не составляет.
Если оплачивает юр.лицо - далеко не каждому из них подойдет онлайн-решение. Надо генерить как минимум квитанцию ПД-4, а по-хорошему еще договор. Но и это тоже сделать можно.
А, вот, как раз, ПД-4
А если, к примеру, клиент где-нибудь за рубежом ? Например, в Китае или во Вьетнаме. Ну, или даже на Украине.
Таким, наверное, лучше оплачивать через PayPal ?
По идее, у организации должен быть счет в банке. Разве обычный счет к оплате не подойдет ?
Просто, чтобы на нем были указаны реквизиты, позиции и сумма.
И такой еще вопрос, возможно, уже многократно заданный.
Скажите пожалуйста, а есть ли возможность каким-то образом избавиться от путаницы, связанной с разделением понятий product и product display ?
А то уверен, что многие заказчики начнут возмущаться - типа, "как-то всё запутанно, непонятно, почему надо два раза вводить ? что это такое вообще ?" и т.д.
А, да, действительно, юр.лицу обычный счет подойдет
Помимо уже посоветованного, есть commerce bulk product creation, который в частности позволяет создавать дисплеи для product-а на лету.
inline_entity_form
Кстати, попробовал - похоже, то, что надо.
Спасибо большое !
причем тут заказчики?
ты путаницу не вноси
от клиента тебе нужно:
схемы по трем вопросам - что, как, кому продаем
первое - это структура продукции
второе - детальное описание моделей продажи и учета продаж
третье - интерфейсы витрины
первое - это обычные сущности друпала
второе - сущности которые добавляет комерц
третье - поиски подборы и т.п. вьюсы просыпаные текстами и картинками, выносящими мозг целевой группе
не нужно думать что список прост - каждый пункт это горы макулатуры)
и клепай ему админку, зачем ему знать, какая сущность за что отвечает,
клиент видит картинки кнопки и таблицы.
+1
рулс, фидс, и немного своего.
Если сайт многоязычный готовтесь к геморою с переводами. Например переводы названий валют. По дефолту в Commmerce например на любом языке грн. будет грн. я чтоб побороть сие мучался долго но до конца так и не победил.
Понял, спасибо за предупреждение.
Думаю, или фильтр напишу для этого, который в тексте будет это переименовывать, или хуками буду решать, если по другому не получится.
плюс еще будет гемор что названия продуктов не переводятся... разве что через Entity translation но тогда... Вам надо будет сделать при 3 языках - 3 перевода 1 продукта и 3 перевода ноды к которой тот продукт привязан
Кстати, я сегодня в процессе разбирательства с переводом Drupal Commerce думал, как лучше всего организовать многоязычность и вот пока к чему пришел ...
Товар (product) многоязычным не делать, а многоязычным делать Product Display.
Также многоязычность включить для полей характеристик товаров.
В этом случае всё удобно, при переводе Product Display не нужно заботиться о синхронизации записей с product.
Но здесь, как Вы и указали, возникает неприятная вещь - заголовок Product не переводится.
И из-за этого хотя бы некорректно отображается корзина - ибо какому-нибудь вьетнамцу или французу не нужно показывать русское название товара.
Но здесь у меня возникла одна идейка, как это дело обойти.
А именно, в product завести еще одно поле "Перевод заголовка" и разрешить для него Field Translation.
В этом случае товар будет один, а переводов заголовков будет несколько.
После этого подправить views, который формирует корзину, чтобы там отображался не реальный заголовок товара, а вот это самое поле - "Переводимый заголовок"
Также при добавлении товара в Inline Entity Form в Product Display, отвечающей за отображение данного типа товара (или при сохранении Product Display - с этим надо будет еще разобраться), вызывать хук, который будет автоматически формировать значение вот этого самого поля, исходя из текущего языка, заголовка Product Display и т.д.
Как-то так ...
Модулёк есть, Title
Этот - http://drupal.org/project/title ?
Загрузил, установил, мало что понял ... тем более, альфа-версия, и с кого спрашивать, когда начнет глючить ?
Копаться в чужом коде и глюки устранять как-то не всегда интересно.
А так - всё легко, просто и красиво будет.
с Title я более-менее разобрался, во всяком случае, руками переводы заголовка делать могу.
Такой остается вопрос.
А как сделать так, чтобы при вводе перевода Product Display автоматически генерировался перевод title ?
Например, я ввел Product Display на русском под названием "Туфли мужские арт. 6005", затем с помощью Inline Entity Editor задал несколько товаров - туфлей с разными размерами. У них title сгенерировался (например, Туфли мужские арт. 6005 (43)), всё нормально.
А теперь добавляю перевод этого Product Display под названием, ну например, "Men's shoes art. 6005". Товары уже введены и привязаны на этапе ввода русского Display, всё нормально.
Но вот, к сожалению, английская версия title автоматически не генерируется.
Скажите, это я что-то недоразобрался с title или есть еще какое-нибудь уже готовое решение ?
Или это дело решается написанием хука ?
Иди на Битрикс, там есть с кого спрашивать
Ну да, есть с кого спрашивать, но некому отвечать
Ну а если серьезно, то если проблему решить можно путем написания небольшого кусочка кода, то в таком случае я не сторонник навешивания лишнего модуля, причем, еще и альфа-версии.
вот ты и ответил на свой давний вопрос про DvsB
кеп))
зачем в бухгалтерских записях многоязычность?
Не знаю, зачем.
Многоязычность нужна для тех данных, которые будут показываться пользоветелю.
вот и оставляй мультиязычность на стороне сущностей друпала (node, taxonomy etc), и не трогай product
у меня по второму вопросу есть дополнительный вопрос.
тут утверждают, что можно переносить информацию со страницы регистрации в профили клиентов магазина при помощи rules..
возможно ли такое сделать используя модуль profile2?
то есть 2 профиля - shipping + billing - при регистрации вводим все поля, дальше rules сохраняет информацию в профили магазина.. так?
и более специфический (хотя и довольно справедливый и логичный в данном контексте) вопрос: когда я заполняю адрес доставки (или billing), то там есть такое поле - Country (страна) - так вот drupal commerce предлагает выбрать страну из списка (список хороший, переведённый судя по всему).. вот как быть с этим полем? реально ли его скопировать и как?
у меня по второму вопросу есть дополнительный вопрос.
тут утверждают, что можно переносить информацию со страницы регистрации в профили клиентов магазина при помощи rules..
возможно ли такое сделать используя модуль profile2?
то есть 2 профиля - shipping + billing - при регистрации вводим все поля, дальше rules сохраняет информацию в профили магазина.. так?
и более специфический (хотя и довольно справедливый и логичный в данном контексте) вопрос: когда я заполняю адрес доставки (или billing), то там есть такое поле - Country (страна) - так вот drupal commerce предлагает выбрать страну из списка (список хороший, переведённый судя по всему).. вот как быть с этим полем? реально ли его скопировать и как?
Кстати, что не так с альфой? Если никто не тестит версии, то откуда появятся релизы? В вашей позиции 100% шаровизм и потребительство. Тестирование - это то малое, что могут сделать юзеры, коль пользуются готовым. И ещё: я почти всегда качаю дев версию, тк новое почти всегда лучше старого, пусть даже зелёного.
Я полностью согласен с тем, что нужно понимать, что это бесплатно, что нужно тестировать и т.д.
Но в боевых условиях, когда заказчик требует результат, а разработчик вынужден заниматься копанием в коде таких альфа-модулей, лазанием по форумам и устранением глюков, возникает двойственное отношение.
Кстати, если я, к примеру, нахожу в модуле глюк и нашел решение по его устранению, то куда писать по этому поводу ?
На странице модуля есть блок Issues - туда.