2 декабря 2019 в 16:47
Приветствую, велосипедисты!
Прошу поделиться наработками по созданию системы учета заказов созданных на Друпал.
Глобальные вопросы
-Какие типы материалов создавал?
-Какие типы друпаловских полей использовал?
Детальные вопросы
-Как реализовал задачу добавления товаров к Заказу/Сделке
-Как сделал автозаполнение цен товаров
-Как реализовал расчет цен, итого, скидок
И другие вопросы
Хотя бы в общих чертах интересно было бы узнать, кто с помощью чего реализовывал подобные функционал.
У меня сейчас проблема реализовать товары заказа. А именно не проблема по ссылке на сущность добавлять товары, но как привязать при этом количество к каждой позиции?
В общем очень интересно, кто как подошел к решению данных вопросов на Друпал.
Комментарии
Заказ - это что?
Если заказ созданный в Уберкарт или Комерц - их можно куда-то вывести, что-то делать.
Заполение вебформ - тоже можно.
Создание ноды "заявки" - да и такое встречается.
Вот это правильный вопрос.
Заказа на самом деле нет (в той системе над которой я работаю). Есть сделка.
Сделка - это когда покупатель передает мне деньги, а я ему выдаю товар. Это единичный обмен товара на деньги.
Что считать отдельной сделкой?
Единичный это достаточно обособленный от других сделок по времени, по потребности, по оплате. Критерии определения, что является отдельной сделкой пока еще не до конца изучены.
Если человек купил хлеб сегодня, а затем завтра, то это разные сделки. Если человек оплатил хлеб на год вперед и получает его каждый день по две булки, то это одна сделка (одна оплата, но много отгрузок).
Если человек открыл вчера сделку и добавил в нее товары, а завтра перезвонил и еще, что то добавил, то это одна сделка (одна потребность, одна отгрузка, одна куча разом, одна оплата).
Если человек хочет разбить одну сделку на несколько оплат, то это одна сделка все равно.
Если человек час назад открыл сделку по одному товару. А затем через час по еще одному товару. То по каким то критериям заметно, что будет идти речь о совершенно разных сделках. Человека интересует первый товар в совершенной не зависимости от второго товара.
Покупатель может признавать, что это отдельная сделка, но конечное слово за продавцом. Продавец фиксирует сделку и определяет отдельные сделки.
У покупателя может быть некий проект для которого он закупает товары. Продавец может зафиксировать, что существует проект и по нему возможны некоторое количество сделок.
Сделка это отдельная потребность, волеизъявление, намерение, потребность, проявленный интерес.
В общем сделка сложная сущность и является еще пока объектом пристального изучения.
Заявок в системе тоже нет. Есть акт переговоров. Акт являвшийся началом сделки есть заявка. То есть, то первое общение не важно с какого канала связи послужившее началом сделки это есть заявка. Заявка тут ограничивается плоскостью коммуникаций и принадлежит
Наибольшую сложность представляет Товар или Продукт. Продукт все, что обменивается на деньги.
Продукт принадлежит к Сделке. В связи с чем встает задача, как связать Продукт со Сделкой. Да еще и желательно автоматизировать, юзабилизировать все это дело.
С учетом самих сделок и заявок не так сложно. Но с Продуктами много функций возникает, как например указание рядом с продуктом его количества, единиц измерения, цены. А в последующем и проверка наличия, резерв, автозаполнение цен с возможность ручного вмешательства, скидок, типов цен и т.д. Вообщем от сделок постепенно уходим в другой функционал системы связанный с Продуктами, Складами, Ценами и т.п.
Пока, что мне визуализируется система Цен, система Продуктов, система Сделок. И теперь я думаю, как я смогу это на Друпал воплотить. Однако с Друпалом я знаком пару месяцев, а программированием не часто балуюсь. Поэтому в первую очередь прикидываю, что я могу сделать с помощью того, что мне сейчас доступно из ядра Друпал, что можно прикрутить (не сложно) и учитывая мой уровень навыков.
Пока я знаком с Views, Материалами, Таксономией, немного Меню, краем глаза с Формами, Комментариями и т.п.
Ну а тема сделок, товаров, цен это вообще тема глобальная и для всех бизнес систем базовая, поэтому думаю следует ее здесь обсуждать. Поэтому речь не обязательно идет о том, как это сделать с минимум знаний.
Но буду осваивать по полной программе с годами. Так, что советы можно давать с учетом будущего. Для продвинутого уровня.
Про формы очень интересно узнать.
Про Уберкарт спасибо я только о нем узнал. Гляну, что за штука и как я могу его применить.
Не надо его применять, он старый
Он и под 8-ку есть и чуть полегче Комерца, но он действительно не для вашей задачи.
"Сделка - это когда покупатель передает мне деньги, а я ему выдаю товар. Это единичный обмен товара" когда реализуете хотя бы это - позовете, продолжим тему.
Но чувствую тут надо углубленное обсуждение вопроса. Возможно времени тут не много у кого найдется на такое. Поэтому я пока не буду масла в огонь подливать. Подождем, посмотрим может еще кто ни будь, что то напишет.
Ладно если, кто делал товары заказа пишите на чем реализовали (тип материала, тип полей, тип данных, какие связи сделали, супер модули и т.п.) если время будет конечно и желание.
И спасибо за участие в обсуждении, что время свое потратили и прочие ресурсы.
Я имею ввиду когда сделаете процесс покупки продукта. Если продавец один - это интернет-магазин. Если продавцов много - это что-то другое, что быстро не сделаешь.
Возможно я что-то не до конца понял, но по-моему все просто и все давно придумано до нас.
По сути, как я понимаю, нужна система учета движения материальных и не очень средств в процессе взаимодействия продавца с покупателем.
Т.е. банальная бухгалтерская система.
Большинство бухгалтерских систем работают по такому принципу: каждое движение материальных средств, т.к. заказ товара, поставка товара, оплата товара, возврат товара и т.п. фиксируется "документом".
"Документ" это такая сущность, в которой храниться информация о каком-то действии.
Например, документ "Заказ" содержит информацию о продавце и покупателе и о заказанных наименованиях товара и их количестве. Документ "Оплата" содержит информацию о плательщике-получателе и сумме и т.п.
А "Сделка" это вообще просто-)
Сделка это договор между продавцом и покупателем на совершение каких либо действий , необходимых для для "перемещения" товара от продавца к покупателю.
А если рассматривать "сделку" как сущность информационной системы учета движения товара от продавца к покупателю, то это сущность, связывающая "документы", фиксирующие этапы движения товара.
Т.е. каждый "документ", относящийся к какой-либо "сделке" должен быть связан с этой сделкой.
Например:
1.Покупатель выбрал список и количество товара и составил Заказ.
Создаем сущность Сделка и присваиваем ее полю "Сделка" Заказа.
2.Заказ отправляется на Склад на комплектацию. На Складе создается документ "Комплект заказа" и связывается со Сделкой. В "Комплект заказа" добавляются товары имеющиеся в наличии.
3.После комплектации заказа формируется документ "Счет" содержащий список товаров, их количество и цены. Счет связывается со Сделкой.
Счет направляется покупателю.
4.Покупатель оплачивает Счет, после чего формируется документ "Оплата заказа" который опять же связывается со Сделкой.
5.После оплаты товар отправляется покупателю и формируется документ "Товар в доставке" и связывается со Сделкой.
6.Покупатель получает товар и формируется документ "Товар получен" и связывается со сделкой.
Сделка получает статус "закончена"
Если покупатель отказался от товара, формируется документ "Возврат товара" и далее любой необходимый алгоритм дальнейших действий, каждое из которых фиксируется соответствующим документом.
Просто, гибко и легко расширяемо.
Надеюсь, у меня получилось объяснить суть достаточно понятно.
Тут, конечно, для удобного хранения и расчетов движений-остатков товаров-денег напрашивается План счетов и Проводки, но это можно пока вынести в отдельную тему-)
Текстовые простынки выше не читал. Но предполагаю, что ТС говорит о транзакциях и построении функционала на их основе... Не надо так делать. Меняйте логику, пока не поздно.