Здравствуйте! Имеется интернет-магазин на CS-Cart, 1С предприятие для складского и бухгалтерского учета и договор со СДЭК. Хотелось бы реализовать автоматическую передачу заявки на доставку в СДЭК после того, как покупатель оплачивает свой заказ (безналичный расчет, стопроцентная предоплата).
Как это можно реализовать в данной конфигурации? Видел, что при использовании CS-Cart модуля СДЭК отправление заявки на доставку необходимо подтверждать вручную. С другой стороны, если я не ошибаюсь, возможность автоматического формирования заявки на доставку есть в 1С. Поправьте меня, если я не прав.
Заказ оплачивается, меняется статус на Обработан - пример
В смене статуса отсылается запрос в курьерскую службу на регистрацию заказа
В целом вариант рабочий, доделать можно. Конечно сыро выглядит, по хорошему надо делать в момент получения реализации из 1с, это уже разумеется сложнее по реализации, но правильно операционно.
Правильнее их выгружать оттуда, откуда потом пойдет дальнейшая цепочка. 1с убогая изолированная среда. Если выгружать с сайта, можно клиенту послать сразу сообщение - ваш заказ отправлен. Получить номер отправления и по нему трекать посылку, опять же - клиент сможет на сайте узнать статус заказа без всяких костылей и граблей. А 1с пусть остатки считает и реализации проводит, это бы нормально делал.
ну тоесть вы предлагаете в 2 средах работать вместо одной? и в 1с и в админке? Сообщения посылать можно и из 1с и выгружать статусы на сайт тоже и треки опять же через rest.
Не смущает вас, что менеджеру надо будет в 2 окнах прыгать постоянно?
А если клиент заказ изменить хочет, нам как, и в 1с менять и на сайте? он же уже выгружен в 1с…
Нет, не смущает. Складские сотрудники только отгружают заказы, менеджеры магазина меняют их на сайте. Если один человек - тоже самое, поменяли на сайте - через несколько минут информация в 1с актуализировалась.
Если заказ изменился - он сразу автоматически изменяется в 1с, так работает обмен с сайтом.
Я бы честно вам не советовал выгружать треки через rest, вы опять же можете - но по опыту своему могу сказать - правда, не стоит этим заниматься. Это столько лишних манипуляций. 1с это не CRM.
Ну вот вы сейчас предлагаете полностью работать с заказами в CS… но это невозможно физически. Нет реальной интеграции со службами доставки, нет обновления списков пунктов по API этих служб, нет выгрузки, ничего нет по факту для логистики. И еще кучи всего не хватает, вы предлагаете наверное это все с 0 дописать, причем без глюков и ошибок, заодно и склад туда же выгрузить… велосипед.
Вы тут описываете сферического коня в вакууме… как красиво и правильно делать, а на деле выходит не так. Не знаю насчет интеграции как она сделана, но мне сдается что коряво, если у нас идет обмен только в сторону 1с, а обратно нет. Допустим в 1с произошла частичная отгрузка, да или полная, а в этот момент некий одаренный менеджер на сайте пытается что-то делать с заказом, не видя ни его статуса ни товародвижения по нему.
Ваше дело, есть люди и аналитику в 1с строят, даже туда затаскивают учет расходов рекламных. Я вас уговаривать не собираюсь. Этого коня я делал и не раз, могу сказать по опыту, что делать через 1с нехорошо, но если вам нравится - я вообще не имею ничего против.
Нельзя сказать, что мне нравится 1с. Но ее понятно как курить, разработка под нее дешевая. И да, там можно и управленческую аналитику делать и чарты и тд и все работает сразу с минимальными допилами. Общаться с любыми внешними сервисами также можно. Свести из нескольких разнонаправленых магазинов в одну бд тоже не соатвляет труда. Но прям нравится - нет. Но все другие решение дороже даже в первом приближении в несколько раз.
Но я так понял, Вы интегратор. Поэтому наш спор, это спор голодного с продавцом еды.
Это я еще не касался разделения прав к доступу и изменению данных. Чего в CS вообще нет.
Я всегда со стороны бизнеса, я в этом очень давно. Я именно со стороны ритейлеров и только недавно стал делать продукты для владельцев, да и те - для повышения продаж, поэтому сарказм про голодного вообще неуместен. Я 10 лет в рознице работаю - именно в интернет магазинах. Писать можно очень долго, лично было бы в разы проще, честно время тратить на убеждение не хочется, лучше остаться при своих. Делаете через 1с и получается - очень хорошо. Главное чтобы все получилось и все довольны были.
Насколько я понял, для 1С нет бесплатных решений по интеграции СДЭК, и с написанием модулей для 1С я не знаком, в отличие от CS Cart, поэтому я прибегну к варианту “CS Cart -> Мой модуль -> Модуль СДЭК -> СДЭК”. Не хочу напрямую взаимодействовать с API СДЭК (ибо сложно), попробую делегировать эти функции модулю СДЭК. Если этот вариант сработает, то сделаю попытку отправки запроса в СДЭК по получении реализации из 1С.
Спасибо вам за помощь, буду исследовать и копать дальше, уже с большим понимаем проблемы.
Это, конечно, офф-топ, но без костылей иногда проблему не решить. Недавно столкнулся с ситуацией, когда мне нужно было создать разные макеты для двух витрин. Панель администрирования и редактор тем сами по себе тут абсолютно бессильны, поскольку необходимые изменения невозможно в их рамках реализовать (тот же баннер во всю страницу - не реализуем, из-за особенностей внешних контейнеров). Пришлось через модуль “Мои изменения” полностью переопределять файл location.tpl, добавлять в нем новый контейнер и уже потом через редактор тем его привязывать к целевому элементу (баннеру). Этот способ, прошу заметить, предлагается из официальной документации и сопроводительных видео. Как потом выяснилось, этот модуль (как и любой другой) действует исключительно для всех витрин, соответственно, переопределенный location.tpl загружался и в другой витрине, где, вообще-то, предполагается совсем другой дизайн. Что же делать? Придумывать костыли, только и всего, ведь иного решения разработчики не предлагают. Пришлось на скорую руку (время все-таки поджимает) придумывать механизм разделения location.tpl (про пользовательские css-файлы я уже не говорю, к ним это также относится, а еще ко многим другим файлам). Таким образом, родился очередной костыль с выбором location.{company_id}.tpl для нужной витрины (как раз по company_id) из переопределенного location.tpl (в нем содержится Smarty-код для выбора шаблона), и я надеюсь, что, все-таки, разработчики обратят на это внимание и каким-нибудь образом реализуют индивидуальное включение/отключение модулей для разных витрин, а не для всего движка в целом. Я ведь и сам не в восторге от ситуации - тратить время на выдумывание велосипедов и костылей.
Мораль в чем? Дело в не в том, что костыль или не костыль, а в том, хорош костыль или плох. Я надеюсь, что костыль выйдет, по крайней мере, неплохим, а то и хорошим, возможно, отказоустойчивым и с минимальным вмешательством в работу платформы.
И опять же вот, как допустм делать аналитику в CS если он подробную информацию о заказах хранит не в отедльных полях, а одним скопом в поле EXTRA ? Тоесть вы захотите отчет за год по красным майкам XS вывести… что придется сделать? Загрузить в память ВСЮ таблицу заказов. Построить из этих полей экстра массивы, а потом уже сделать по ним выборку. Либо тупо перебором по всей таблице брать поле экстра, десериализовывать, и если в нем нужные значения - пихать в отчет. Разница между SQL запросам по 3 таблицам orders orderproducts и cкажем orderproductsoption и вышеприведенными действиями - несколько порядков в скорости исполнения и ресурсах. Это если говорить даже о магазине с 500-1000 заказами в день, а если как вы позиционируется “нескольок тысяч” то там эти отчеты будут строиться очень долго, тоесть не в реальном времени скорее всего даже.
С позиции написания модулей я вижу такой вариант: создать свою таблицу с интересующим меня набором полей, которым соответствуют поля из сериализованной структуры данных (extra). При формировании записей о заказах (или их обновлении) перехватывать операцию через хуки и выполнять дублирование значений в строчку моей пользовательской таблицы. При построении отчета скорость выборки будет исчисляться уже скоростями обработки запросов MariaDB. Статистические функции также можно возложить на СУБД, это, конечно, быстрее. Или, вообще, вариант с предварительным построением/дополнением отчета при создании заказов, но это весьма рискованный вариант.
Если такое есть в 1С (и без дополнительной платы, разумеется), то, конечно, я буду использовать 1С, тут без вопросов.