Один из способов улучшить рабочий процесс — это делегировать часть полномочий на тех, кто справится также или лучше первоначального исполнителя. Современные тенденции показывают, что это справедливо и для программных продуктов. Например часть рутинных обязанностей можно «передать» сервисам, чтобы освободить сотрудников для более важных задач.
В статье расскажем как доработали штатный модуль интеграции 1С и сайта, и делегировали системе часть полномочий сотрудников. Тем самым сохранили ресурсы бизнеса, снизили риск ошибок и помогли сотрудникам сосредоточиться на важных делах.
Как модернизация штатного модуля улучшила сервис для покупателей и сняла часть обязанностей с менеджеров
Штатный модуль vs задачи клиента
В Luckru обратился интернет-магазин медицинской мебели, оборудования и технических средств реабилитации «ЮкиГрупп» (далее по тексту заказчик, компания, Юки). Одна из целей компании стать еще более удобным сервисом по заказу социально-значимых товаром медицинского назначения и тем самым расширить долю B2C клиентов. Ранее мы уже описывали как для этой цели интегрировали способ оплаты с помощью сертификата ФСС. Проект этим не ограничился: в добавок Заказчик хотел «связать» сайт с 1С, чтобы заказы «оседали» в обеих системах.
В таких случаях специалисты используют штатный модуль интеграции. Однако на момент обращения Юки в Luckru, 1С уже было модифицирована под всевозможные задачи бизнеса.
Мы сделали из 1С: Управление торговлей 10 аналог УТ 11, а местами даже круче.Представитель заказчика
Поэтому штатная интеграция не подходила для задач заказчика:
- автоматического создания контрагента;
- автоматического возврата платежа, снятия резерва и деактивации промокода;
- синхронизации и фиксации эквайринговых операций.
После аудита решили доработать штатный модуль интеграции 1С и сайта. Мы выяснили тонкости бизнес-процессов заказчика и перенесли логику в совместную работу систем.
У Вас похожая задача по разработке бизнес-процесса?
Давайте обсудим
Автосоздание карточки контрагента в 1С
Одна из болей при создании заказа — правильно отразить данные в полях сущности: товар, стоимость, наименование, ИНН контрагента. Штатная интеграция предполагает автоматическое «подтягивание» информации в поля 1С, при условии, что такие сущности уже есть в базе. Например, наименование с сайта «встанет» в поле 1С с корректным наименованием, если такой товар предварительно «завели» в базу. То же самое касается ИНН контрагента. Есть и другой вариант, когда программа автоматически по ИНН заполняет карточку Контрагента по данным из базы Федеральной налоговой службы.
Особенность 1С в сложной структуре подчиненности полей. Каждое поле из справочника может быть связано с другим из второго справочника, который в свою очередь ведет в третьему. И так далее.
Однако ЮкиГрупп требовались заполнять нетиповые поля в сущности Контрагента, поэтому в этой части потребовалось доработать штатный модуль. Например нужно, чтобы в кратком наименовании контрагента, организационная форма стояла после названия (например, «Лакру ООО»). Теперь модуль автоматизировал этот процесс и заполняет данные так, как нужно заказчику.
Для этого мы установили Узел обмена заказами, который срабатывает раз в пять минут, забирает заказ с сайта и создает такой же в 1С. В это время система проверяет по ИНН, есть ли такой контрагент в базе. Если нет, то 1С автоматически создает контрагента (указывая полное и краткое наименование компании), а также относит его к определенной группе контрагентов.
Сравним сценарии, где приходится «заводить» в базу контрагента, чтобы впоследствии создать заказ.
- Сотрудник вручную выполняет последовательно действия: зайти в 1С → затем в справочник → открыть форму → заполнить реквизиты → потом уже система создаст Заказ на основании данных с сайта. Этот процесс займет от 5 минут.
- Система автоматически и практически одновременно создает обе сущности: она самостоятельно заполняет поля. По времени весь процесс займет несколько секунд.
Здесь же мы учли и другие пожелания клиента. Например, изначально система устроена так, что сайт воспринимает ИП (индивидуального предпринимателя) как юридическое лицо (далее юрлицо), а 1С — как физическое (далее физлицо). Но Юки важно, чтобы платформа считала ИП юрлицом, что мы и сделали с помощью скрипта (небольшая программа, которая выполняет определенную задачу).
Описанная логика не работает с созданием физлиц. Здесь важно понимать, что физических лиц, которые делают заказы на сайте в разы больше, однако не все доводят заказ до оплаты. Чтобы не «засорять» базу в 1С, мы придумали другой алгоритм: контрагент (физлицо) создается в базе ПОСЛЕ того, как с сайта поступит информация об оплате заказа (об этом мы написали ниже).
Автоматический учет оплат
Цель синхронизации 1С с другими системами — упростить выполнение задач сотрудникам и организовать бизнес-процесс без накладок. Один из них — фиксация оплат. С оплатой товаров юрлицами вопросов не возникает — они оплачивают счет → бухгалтер «разносит» платежи по соответствующим заказам → система сама создает структуру документов. Однако фиксация оплат от физлиц идет по другой логике.
Для начала вспомним, что контрагент (физлицо) и заказ появятся в базе 1С только после того, как клиент оплатит товар. Для оперативного создания заказа в 1С, надо зафиксировать факт оплаты товара с помощью документа «Оплата от покупателя платежной картой» (далее — документ). Вот здесь и кроется основная проблема — обычно модуль некорректно заполняет поля, поэтому бухгалтеру приходится самостоятельно формировать документ. Представим, что в день поступает несколько десятков заказов и специалист тратит на рутинное заполнение документа львиную часть рабочего дня. Остается либо смирится с ситуацией, либо доработать модуль таким образом, чтобы система самостоятельно фиксировала оплаты и корректно создавала документ.
Заказчик выбрал последний вариант. Мы разработали опцию, при которой система создает эквайринговый и остальные документы по факту оплаты заказа физлицом. В итоге бухгалтеру больше не нужно отслеживать оплаты за каждый заказ и создавать документы, которые к тому же влияют на статусы заказа. К слову, статусы — удобная опция для покупателей, ведь они видят, что происходит с заказом.
Учим 1С снимать резерв
При оформлении заказа, на товары из корзины ставят резерв и они не доступны другим клиентам. Обычно у покупателя есть несколько дней для выкупа товара, в противном случае бронь отменят. Штатный модуль умеет делать резервы товаров, но автоматически не отменяет их. Обычно в случае снятия брони с товаров, менеджер (или другой сотрудник) делает это вручную.
Представьте ситуацию, когда менеджеру приходится каждый день мониторить зарезервированные товары на предмет оплаты. Сколько времени ему понадобиться на учет? Что если есть реальный покупатель на товар, а сотрудник не успел снять с товара бронь? Мы решили проблемы с помощью автоматической отмены брони.
Как это устроено: первоначально при оформлении заказа, то самое количество заказанного товара «исчезает» только на сайте. Однако после оплаты, узел обмена информацией «забирает» с сайта сведения о заказе, и количество товаров в 1С меняется. Суть автоматической отмены брони в том, что система отслеживает создание платежного документа по заказу и снимает резерв с товаров из заказа, если в течение 3 рабочих дней не будет оплаты. Дополнительный бонус, что менеджеру не надо больше вручную отслеживать выкуп забронированных товаров и снимать резерв в 1С. В итоге компания в плюсе: рутинные задачи с сотрудника сняты, информация актуальна, товары доступны реальным покупателям.
Особая опция для холдингов
Сейчас речь пойдет про гипотетическую (но вполне реальную) опцию, которая подойдет холдингам. Холдинги часто оптом закупают товары для дочерних компаний. Когда речь идет о массовом заказе товаров для юрлиц, важно сделать процесс оформления удобным.
Итак, суть (потенциальной) разработки в следующем: одно юрлицо (или представитель разных компаний) создает один аккаунт на сайте, в котором может оформлять заказы для каждого юрлица (дочерних компаний) по отдельности. При этом в 1С документы будут формироваться для отдельных юрлиц, а на сайте заказы будут концентрироваться в одном месте — ЛК. Так оформлять и контролировать заказы проще. Ведь представителю нет необходимости заходить в разные аккаунты, чтобы добавить заказ, оформить возврат или скачать счет.
Конкретно в данном проекты мы не реализовывали такую опцию, однако она теоретически подходит под задачи бизнеса. Поэтому компаниям с похожими процессами и запросами полезно знать о такой возможности.
Доработка штатного модуля: подводим итоги
Проект получился грандиозным. Разработка модуля решила задачи компании:
- автоматизировать рутинные действия менеджеров, тем самым сделало удобной повседневную работу и сэкономить время сотрудников;
- контролировать бизнес-процессы по заказам;
- сократить риск ошибок, когда вводят огромное количество данных и создают «тонны» документов.
Для себя определили, что при работе над подобными проектам надо обязательно докапываться до сути процессов, глубоко погружаться, узнавать все нюансы бизнеса. Иначе можно упустить важный момент и придется тратить дополнительное время обеих команд на еще более глубокий аудит.
