Мини-кейс retailCRM+1C с адресным хранением
Летом 2018 года мы начали разрабатывать бизнес-процессы, внедрение retailCRM и 1C для клиента www.mastershop.store/ Клиент сразу предупредил, что товар мелкий, и для многих товаров на складе используется адресное хранение, а также что все процессы — заказы, оплаты, комплектация, документы, возвраты должны проводиться в retailCRM, 1C — “серый кардинал”. Ранее не работали с адресным хранением, поэтому решили сделать очень просто: передавать адреса ячеек в каталог retailCRM, чтоб возле каждого товара было видно место его хранение. Но практически сразу обнаружились недостатки данной схемы, а при возвратах и вовсе не ясно — куда возвращать товар, ведь ячейка уже может быть заполнена. Пришлось срочно вносить коррективы. И тут столкнулись с новым “сюрпризом” — адрес ячеек необходим на этапе комплектации, а по логике 1C, отбор ячеек можно получить только после ордера, а его же можно получить только после создания реализации, а согласно бизнес-процессам это еще не реализация, а только комплектация, и товар могут не забрать. Но с другой стороны — у нас были полностью развязаны руки со стороны 1C — главное чтоб в retailCRM и у в 1с бухгалтерия было все красиво, как будет работать в УТ не важно.
Итого, как это заработало в retailCRM
Заказ поступает с сайта или создается менеджеров в retailCRM — заказ сразу поступает в 1C и если это “физик”, то сразу ставится резерв. Если “юрик” то резерв ставится после выставления счета. Когда товар становится в в резерв, на каждый товар проставляется статус “в резерв”. Если какой-то позиции недостаточно, заказ попадает на закупщика. Для упрощение отчетности, все заказы физических лиц создаются в 1C как на единое физическое лицо и без НДС, на юридические лица — создаются на контрагента как в retailCRM с выбором НДС.
При переводе заказа в статус “передано в комплектацию”, в 1C создаются автоматически документ реализации, счет + УПД, происходит отбор ячеек товаров, и возвращается это как комментарий к статусу товара. Если в заказе много одинаковых товаров, и они находятся в разных ячейках, то в комментарий просто перечисляются несколько ячеек через точку с запятой.
Кладовщик в retailCRM печатает специальный документ “сборочный лист”, который помогает собрать заказ и некоторые напоминалки :
Кстати, кладовщики частенько забывали положить некие документы в заказ, или поставить маркировку. Для этого мы просто в заказе поставили необходимые чек боксы, а валидация запрещает менять статус заказа, пока кладовщик не отметить все пункты.
Заказы отправляются на самовывоз или транспортными компаниями.
В случае возврата, менеджер в retailCRM сначала одобряет возврат (меняет статус), информация о необходимости возврата передается в 1C, срабатывает очередной каскад, и в retailCRM возвращается адрес ячейки, куда необходимо сейчас вернуть товар.
Все оплаты с сайта или наложки транспортный компаний попадают в retailCRM, и оттуда создаются платежи в 1C.
Все обмены происходят очень быстро, менее минуты, этого добиваемся благодаря обмену только изменившихся заказов, и только для статусов участвующие в обмене.
Так произошло наше первое знакомство с адресными ячейками.
Заинтересовал кейс? Наша расширенная интеграция retailCRM-1C