Взаимодействие retailCRM и 1С:УНФ для интернет-магазина Тканей
Взаимодействие retailCRM и 1С:УНФ для интернет-магазина Тканей
Интеграция retailcrm и 1С:УНФ («1С: Управление нашей фирмой») является абсолютно типовой, функционал УНФ по возможностям уступает заметно УТ (Управлению торговли).
Но что было необычно — это тематика, интернет-магазин тканей, и как мне удалось решить нестандартную проблему.
Взаимодействие retailCRM и 1С.
Не буду описать все процессы — согласование, предоплаты, подбор. Только то, что касается логики обмена retailCRM и 1С.
Менеджеры принимают и обрабатывают заказы в retailCRM, заказы поступают преимущественно через соц. сети. Заказ после подтверждения в retailCRM выгружается в 1С и резервируются.
В retailCRM переводят статус на «Передан в комплектацию» — заказ распечатывают и отдают на сборку кладовщикам. Когда заказ укомплектован — в 1С автоматически изменяется статус на «готов к отгрузке».
Если по предоплате ,то оплата выставляется из retailCRM через наш модуль эквайринга. Оплата сразу передается в 1С как документ эквайринга.
И когда в retailCRM изменили на «передан в доставку» — происходит команда отправки в транспортную компанию, и в 1С создается документ реализации. Также могут быть реализованы возвраты из retailCRM в 1С.
Самое интересное — отрезы.
Это уже был мой четвертый клиент в этой тематике, но почему он первый рассказал о боли этой тематики, причем проблема отрезов уже не первый год.
Суть проблемы.
Ткань закупается в рулонах от 30 до 100 метров. Клиенты же заказывают столько метров, сколько необходимо. Соответственно на складе со временем накапливаются большое количество обрезов 1-5 метров, которые было бы легко продать, если бы о них знали менеджеры. Ведь часто клиент заказывает, например 4 метра, а по факту ему надо 2 отреза по 2 метра, а на складе может быть как раз такой остаток. Я был удивлен, но в «коробке» 1С нет решения такой проблемы.
Как работал клиент.
В свойства товара писали какие есть кусочки, когда их продавали или обрезали — меняли эти свойства вручную. А т.к. каталог в retailCRM обновляется раз в 3 часа, актуальность очень быстро терялась. Крутили по разному, и как товарные предложения разные, и как ячейки, и как партии — все было громоздко и не удобно. И пришла такая отличная идея: из одного рулона ткани мог остаться только этот же рулон но с меньшим количеством ткани, за редким исключением — возврата, и это очень важный момент.
Решение задачи
Я предложил на основном складе сделать условное деление на склады (для быстрого поиска), а в 1С при каждом приходе товара создавать Новый склад и приходовать на него. Т.к. приход происходит раз в 1-2 месяца, и одинаковые модели приходят не часто, это не приводит к большому количеству складов. Т.е. фактически даже несколько приходов можно приходовать на один склад. Метровые же отрезки помещались на единый склад и их количество суммировалось, т.к. они всеравно метровые.
Если происходил возврат — он помещается на свободный склад.
Как результат — менеджер видит сколько каждой ткани есть целой, и какой есть метраж отрезов, и прямо в retailCRM можно выбрать сколько метров надо отрезать или использовать целиком — с каждого отреза.
Пример остатков-отрезов.
На примере видно, что есть один целый рулон, один на 8 метров и два метровых, и сразу в заказе выбрать сколько надо с каждого отрезать.
Получилось идеальное решение — товары и аналитика работают, менеджеры видят всегда актуальную информацию (товар сразу резервируется с нужного отреза) и остатки используются эффективно.
