CRM для логистики на базе Tickets
Всем привет, в который раз удивляюсь возможностям применения Tickets.
Цель — Сделать crm систему, чтобы менеджеры тратили минимум времени на заведение контрагентов, заявок и тд
Что мы имеем на данный момент. Готовность примерно 60-70%, самые сложные моменты готовы
Калькулятор — Тут особо ничего интересного нету, воспользовался уже существующими сервисами, чтобы сэкономить время
Контрагенты — Самый интересный и сложный раздел. Если контрагент ИП или ООО, то при заполнении наименования или ИНН, данные подтягиваются из DaData. Контрагенты могут быть как физ. лица, так и юр. лица, которые в свою очередь могут быть заказчиком, перевозчиком, водителем, а могут быть и заказчиком и перевозчиком.
Если это перевозчик, к нему сделал возможность добавлять водителей (которые выбираются из общего числа контрагентов с типом «водитель», использован Tickets+migx) и авто (Использован migx).
Если контрагент — заказчик или гибрид, у него в свою очередь формируется пакет заполненных документов, на основе его данных (спасибо phpoffice).
К разделу настройки в дальнейшем будет доступ только у директора. + некоторые моменты по сайту типа «удаление заявок, „удаление рейсов“, будет тоже только у директора.
Разделы заявки и рейсы еще менее доработаны, но можно уже потыкать.
В общем, убил много времени на xpdo (Илье отдельное спасибо за уроки — не сарказм), пока не зашел в тупик и попробовал сделать на Tickets и все пошло — поехало.
crm.limstudio.ru
Логин — kibborg_2005@mail.ru
пароль — modx2020
Цель — Сделать crm систему, чтобы менеджеры тратили минимум времени на заведение контрагентов, заявок и тд
Калькулятор — Тут особо ничего интересного нету, воспользовался уже существующими сервисами, чтобы сэкономить время
Контрагенты — Самый интересный и сложный раздел. Если контрагент ИП или ООО, то при заполнении наименования или ИНН, данные подтягиваются из DaData. Контрагенты могут быть как физ. лица, так и юр. лица, которые в свою очередь могут быть заказчиком, перевозчиком, водителем, а могут быть и заказчиком и перевозчиком.
Если это перевозчик, к нему сделал возможность добавлять водителей (которые выбираются из общего числа контрагентов с типом «водитель», использован Tickets+migx) и авто (Использован migx).
Если контрагент — заказчик или гибрид, у него в свою очередь формируется пакет заполненных документов, на основе его данных (спасибо phpoffice).
К разделу настройки в дальнейшем будет доступ только у директора. + некоторые моменты по сайту типа «удаление заявок, „удаление рейсов“, будет тоже только у директора.
Разделы заявки и рейсы еще менее доработаны, но можно уже потыкать.
В общем, убил много времени на xpdo (Илье отдельное спасибо за уроки — не сарказм), пока не зашел в тупик и попробовал сделать на Tickets и все пошло — поехало.
crm.limstudio.ru
Логин — kibborg_2005@mail.ru
пароль — modx2020
23 января 2020, 09:39
Поблагодарить автора
Отправить деньги
Комментарии: 43
пока не зашел в тупик и попробовал сделать на Tickets и все пошло — поехалоЗдорово, конечно, только что будет с этой системой на Tickets и MIGX при сотнях тысяч записей, а то и миллионах, за несколько лет?
Это же создание ресурсов для каждой заявки, которые падают в кэш системы, карту сайта и т.д.
На данный момент у них несколько программ. Грубо говоря в одной заводят заявки, в другой ведут контрагентов, в программах много лишнего функционала и тд. Поэтому задача была собрать нужны функции в одном месте и ускорить/упростить процессы заведения данных. Ну и бонусом получится удаленный доступ
Полностью согласен. Но отсутствие бесконечного времени и ограниченный бюджет заставили меня найти более быстрый, альтернативный способ, у меня даже получилось сделать грубо говоря половину из того, что уже есть, но дальше упёрся в недостаток своих знаний. Буду курить в дальнейшем xpdo
По всей видимости бюджет был очень маленький, раз решили создавать CRM на базе CMS и бесплатного готового компонента, который бог знает когда последний раз обновлялся, требует рефакторинга, предназначен совсем для других целей изначально и хранит в себе много лишнего функционала для вашего кейса. Я для таких вещей изучаю Laravel.
А то что на тикетах можно построить даже космический корабль — это не новость. Вопрос в том, когда он летать перестанет. Если с клиентом были обговорены условия и он в курсе что будет с их CRM при большом кол-ве ресурсов, то конечно вопросов нет.
Но лайк однозначно пост заслуживает.
А то что на тикетах можно построить даже космический корабль — это не новость. Вопрос в том, когда он летать перестанет. Если с клиентом были обговорены условия и он в курсе что будет с их CRM при большом кол-ве ресурсов, то конечно вопросов нет.
Но лайк однозначно пост заслуживает.
Эм, нет. Но есть задачи и инструменты. Один инструмент для всего конечно не получится, хотя конечно как его готовить. К примеру даже если делать CRM на MODX то конечно лучше использовать решение написанное с нуля, без использования Tickets, так как он в принципе для такого не предназначался. Но то, что у вас получилось в прницпе все это связать это круто
Неужели на нем можно делать только интернет-магазины и он больше ни на что не годитсяНа самом деле даже интернет — магазин более-менее достойный ты врятли сделаешь, элементарное отсутствие очередей без которых любому интернет — магазину тяжко, перегруженная БД ненужными полями и таблицами, устаревший и медленный код, отсутствие нормально реализованных событий, кэширования и т.д.
Да, это PHP и все можно прикрутить, да, можно много логик переписать или дописать, но зачем, когда есть фреймворки где за тебя уже продумали большую часть моментов и реализовали это быстро и хорошо?
А что на счет CRM, вам повезет если бизнес загнется или поймет что ваше самописанное решение не нужно, но если все же нет и придется масштабировать под реальные потребности бизнеса, я не завидую тому, кто будет этим заниматься
А так, было время я тоже говорил что на modx можно сделать что угодно, что нет никаких ограничений и вообще зачем фреймворки, есть же MODX, он же чуть ли не фреймворк и ни капли не устарел, но все мы потом вырастаем, учимся программировать по настоящему и понимаем что для реальных задач, нужны реальные решения, а не игрушечные
У него есть своя ниша, на которой банкует WP, Joomla и Bitrix. Чтобы туда влезть, нужно приложить усилия. А это уже не про MODX хозяев. Их тяжело растолкать даже чтобы закрыть дырки безопасности. Так что разработчикам советую учить фреймворки. Ибо MODX закончится на второй версии. Не он первый, не он последний.
Осенью работа встала по причине полной загруженности и предновогодней суеты. Сейчас постепенно время высвобождается и я, глядя трезвым взглядом на задачу, не могу найти причину, чтобы возобновить работу над ней. Как я уже говорил, главной причиной почему я взялся за это — прокачать скилы. Стэк уж очень вкусный — Slim4, PHPUnit, Swagger.
Но демотивирующих факторов огромное количество. Главная — я не верил и продолжаю не верить в MODX3. А работы по REST API минимум на год. Но я вижу полную её бессмысленность по причине невостребованности. Ибо никто в здравом уме не будет использовать MODX в качестве RESTful сервиса. Кроме того…
Блин, в общем, тут на целую статью наберётся. В ближайшее время постараюсь запилить у себя, чтобы тут народ не баламутить.
Но демотивирующих факторов огромное количество. Главная — я не верил и продолжаю не верить в MODX3. А работы по REST API минимум на год. Но я вижу полную её бессмысленность по причине невостребованности. Ибо никто в здравом уме не будет использовать MODX в качестве RESTful сервиса. Кроме того…
Блин, в общем, тут на целую статью наберётся. В ближайшее время постараюсь запилить у себя, чтобы тут народ не баламутить.
Сергей, позволю себе возразить. С нуля, наверное никто не будет делать RESTFul сервис на MODX, когда есть Laravel, но вот для существующих проектов, когда нужно пробрасывать запросы к API MODX из мобильного приложения, или JS приложения какая никакая RESTful болванка все таки нужна.
Другое дело что в здравом уме расчитывать оправдать трудозатраты какой то выручкой — это бред. Здесь может быть только собственный интерес, который у каждого разный. Это уже конечно личное дело.
Другое дело что в здравом уме расчитывать оправдать трудозатраты какой то выручкой — это бред. Здесь может быть только собственный интерес, который у каждого разный. Это уже конечно личное дело.
Мнения могут не совпадать. Тут нет правильного или неправильного. Даже у одного человека мнение может измениться.
В общем, свою позицию постараюсь изложить в статье.
но вот для существующих проектов, когда нужно пробрасывать запросы к API MODX из мобильного приложения,Есть мнение, что таких проектов «кот наплакал» и количество их не растёт, а сокращается. RESTful болванка в MODX есть. Хотя с формальной точки зрения — это совсем не REST. Ибо использование сессий не соответствует концепции REST.
Другое дело что в здравом уме расчитывать оправдать трудозатраты какой то выручкойМой профит был в прокачке навыков и получении дополнительных знаний. Я не собирался это продавать!
В общем, свою позицию постараюсь изложить в статье.
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Здесь упомянуты:
| Компонент | Текущая версия | Закачки |
| Tickets | 1.13.0-pl от 10.03.2020 | 19 560 |
| DaData | 1.0.10-beta от 25.06.2018 | 113 |
3 часа назад
Моя кофейная гуща говорит о том, что это код html и там есть смайлики, а кодировка бд не utf8mb4.
22 ноября 2024, 21:57
Лучше деинсталировать и установить новую версию. Там полностью переписан JS.
22 ноября 2024, 20:33
Фильтрация как правило предполагает точное совпадения значений, а тебе нужен поиск.
22 ноября 2024, 19:55
Все исправилось, после замены на 'parents' => $_modx->resource.id
22 ноября 2024, 09:31
А кто подскажет, как в форму Создания/Редактирования ресурса, через ms2Form, добавить возможность выбирать несоклько параметров в одном TV?
Ну то-ест...
