Мини-кейс RetailCRM+1C с адресным хранением

Мини-кейс RetailCRM+1C с адресным хранением

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

Итого, как это заработало в RetailCRM

Заказ поступает с сайта или создается менеджеров в RetailCRM — заказ сразу поступает в 1C и если это “физик”, то сразу ставится резерв. Если “юрик” то резерв ставится после выставления счета. Когда товар становится в в резерв, на каждый товар проставляется статус “в резерв”. Если какой-то позиции недостаточно, заказ попадает на закупщика. Для упрощение отчетности, все заказы физических лиц создаются в 1C как на единое физическое лицо и без НДС, на юридические лица — создаются на контрагента как в RetailCRM с выбором НДС.

При переводе заказа в статус  “передано в комплектацию”, в 1C создаются автоматически документ реализации, счет + УПД, происходит отбор ячеек товаров, и возвращается это как комментарий к статусу товара. Если в заказе много одинаковых товаров, и они находятся в разных ячейках, то в комментарий просто перечисляются несколько ячеек через точку с запятой.

История заказа, с возвращенными адресами ячеек.
История заказа, с возвращенными адресами ячеек.

Кладовщик в RetailCRM печатает специальный документ “сборочный лист”, который помогает собрать заказ  и некоторые напоминалки :

Сборочный лист RetailCRM для кладовщика.
Сборочный лист RetailCRM для кладовщика.

Кстати, кладовщики частенько забывали положить некие документы в заказ, или поставить маркировку. Для этого мы просто в заказе поставили необходимые чек боксы, а валидация запрещает менять статус заказа, пока кладовщик не отметить все пункты.

Чек-лист напоминалка.
Чек-лист напоминалка.

Заказы отправляются на самовывоз или транспортными компаниями.

В случае возврата, менеджер в RetailCRM сначала одобряет возврат (меняет статус), информация о необходимости возврата передается в 1C, срабатывает очередной каскад, и в RetailCRM возвращается адрес ячейки, куда необходимо сейчас вернуть товар.

Ячейка для возврата товара.
Ячейка для возврата товара.

Все оплаты с сайта или наложки транспортный компаний попадают в RetailCRM, и оттуда создаются платежи в 1C.

Все обмены происходят очень быстро, менее минуты, этого добиваемся благодаря обмену только изменившихся заказов, и только для статусов участвующие в обмене.

Так произошло наше первое знакомство с адресными ячейками.

https://im-business.com | Автоматизация от профессионалов

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *