Технолаб: внедрение 1С с нуля и интеграция с интернет-магазином

При разработке Интернет-магазина далеко не все зависит от самого сайта. Каталог товаров/услуг, цены, остатки, заказы, данные о клиентах — значительная часть информации, с которой работает интернет-магазин, хранится и обрабатывается в 1С. Поэтому процессы и настройки на стороне Учетной системы (1С как вариант) в какой-то момент неизбежно начинают влиять и на разработку сайта.

Особенно заметно это на этапе интеграции. Чтобы настроить корректный обмен данными между сайтом и учетной системой, недостаточно определить, какие данные одна система должна передавать другой. Важно понимать, как устроены сами процессы в 1С: откуда берутся цены и остатки, как ведется номенклатура, как обрабатываются заказы, какие данные должны передаваться с сайта в 1С для оперативной обработки заказов и отгрузки товара клиентам.

По нашему опыту, именно здесь возникает значительная часть сложностей при разработке интернет-магазинов. Если 1С изначально не подготовлена к интеграции, команде приходится сначала разбираться с процессами и данными внутри учетной системы и только после этого двигаться дальше с интеграции к настройке обмена.

Именно так произошло в проекте «Технолаба». Компания обратилась к нам за разработкой нового интернет-магазина, однако в процессе работы задача постепенно вышла за рамки сайта.

О компании

Заказчиком проекта стала компания «Технолаб» — поставщик цифровой техники и электроники. Изначально компания обратилась к нам за разработкой нового интернет-магазина. Работы по 1С велись параллельно другой командой, а на нашей стороне предполагалась интеграция сайта с учетной системой.

Однако по ходу проекта стало понятно, что для запуска интернет-магазина недостаточно просто настроить обмен с 1С. Требовалась доработка самой учетной системы: необходимо было правильно организовать работу в 1С с каталогом, ценами, остатками, заказами и сервисным обслуживанием, а также подготовить все эти процессы к интеграции с сайтом. В итоге заказчик передал нашей команде и работы по 1С.

Такая ситуация для проектов интернет-магазинов скорее типична. По нашему опыту, около 70% сложностей с интеграциями так или иначе связаны с 1С. Многие процессы на сайте строятся на данных из учетной системы, поэтому проблемы внутри нее быстро отражаются и на разработке. Если данные, бизнес-процессы и архитектура 1С не подготовлены к интеграции, часть работ по сайту приходится откладывать до тех пор, пока эти вопросы не будут решены.

В случае с «Технолабом» работа с 1С в итоге стала отдельной большой частью проекта. Необходимо было не просто обеспечить обмен данными с интернет-магазином, а выстроить учетную систему так, чтобы она поддерживала ключевые процессы компании и стала надежной основой для дальнейшей работы сайта.

На практике сначала необходимо понять:

• кто будет работать в системе;
• какие документы используются в работе;
• какие действия выполняют сотрудники;
• какие данные должны передаваться между сайтом и учетной системой;
• какие результаты должен получать бизнес на каждом этапе процесса.

Поэтому первым этапом стало описание и согласование будущих процессов работы компании. При их реализации мы стремились максимально использовать возможности типовой конфигурации 1С и дорабатывать систему только там, где это действительно было необходимо.

Такой подход позволил сохранить баланс между гибкостью системы и возможностью ее дальнейшего обновления.

В нашем случае часть информации о товарах не укладывалась в типовой набор параметров обмена. При этом создавать отдельные механизмы передачи данных или усложнять архитектуру интеграции не хотелось — такой подход увеличивает стоимость поддержки и усложняет дальнейшее развитие системы.

Поэтому было принято решение использовать дополнительные реквизиты 1С — специальные пользовательские поля, которые позволяют хранить нестандартные данные без изменения типовой структуры системы. Если определенная характеристика требовалась сайту, она сохранялась в учетной системе и автоматически включалась в обмен вместе с остальной информацией о товаре.

При этом на сайт нужно было передавать не всю номенклатуру из 1С. Для этого добавили признак «Не выгружать на сайт» — его можно было установить непосредственно в карточке товара.

При обмене 1С учитывала этот признак и не передавала такие позиции на сайт.

Состав передаваемых данных также настраивался отдельно в подключении к сайту: можно было определить, какие реквизиты номенклатуры участвуют в выгрузке, а какие нет.

Отдельно доработали передачу некоторых стандартных данных. Например, код товара в 1С формировался по правилам Типовых 1С и содержал префикс, который не требовался на сайте. В механизме обмена сделали доработку, чтобы на сайт передавался код уже в нужном
формате — без префикса.

Названия и штрихкоды также передавались через типовой механизм обмена с необходимыми доработками в 1С.

Обмен работал и в обратную сторону — с сайта в 1С.

Для загрузки заказов в 1С с сайта настроили передачу дополнительных реквизитов, в том числе тех, которых не было в стандартной схеме. Например, добавили склад отгрузки и признак пробития чека. Для таких полей задавалось соответствие между данными сайта и 1С, после чего модуль практически полу-автоматически переносил их в нужный заказ.

Аналогичный принцип использовался при загрузке заказов: дополнительные реквизиты, добавленные на сайте, сопоставлялись с соответствующими полями в 1С и автоматически переносились в заказ. Это позволяло учитывать специфику интернет-магазина без отдельной разработки нового механизма обмена для каждого изменения.

Такой подход позволил гибко учитывать специфику интернет-магазина без создания отдельного механизма обмена для каждого нового реквизита.

Здесь задача заключалась не только в настройке стандартных механизмов 1С, но и в адаптации их под процессы заказчика. Сначала вместе с заказчиком прорабатывали сценарии работы кассиров, оформления продаж и чеков, а затем определяли, как реализовать их в системе с учетом возможностей ERP/Управление торговлей (в этой части функционал идентичен).

В типовых решениях 1С:Управление торговлей 11 для розничного сценария чек оформляется через рабочее место кассира. Однако если продажа начинается с заказа клиента, возникает ограничение: чек нельзя полноценно использовать для ведения взаиморасчетов по заказу.

Поэтому компании, работающие по схеме «заказ → реализация товаров и услуг/продажа → вывод чека». Т.е. исключили типовую РМК и вынуждены либо серьезно дорабатывать диалоговое окно пробития чека из документов реализации товаров и услуг, и возврат товаров от клиента, чтобы кассиру было проще проверить операцию перед проведением и снизить риск ошибок.

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

Подключение специализированного модуля позволило менеджерам сразу резервировать товар на складе, не откладывая оформление заказа до завершения согласования коммерческих условий. Благодаря этому удалось ускорить обработку заявок и снизить риск продажи зарезервированного товара другому покупателю.

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

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

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

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

Благодаря этому поиск истории конкретного устройства выполняется практически мгновенно даже при большом объеме данных.

Помимо стандартного учета гарантийных обязательств была автоматизирована продажа дополнительной гарантии.

Для каждой папки (группы) номенклатуры в системе задается процент и рассчитывается стоимость расширенной гарантии. Например, для группы «iPhone 17 Pro Max» не имеет значения, идет ли речь о версии с разным объемом памяти или цветом корпуса — все эти позиции объединяются в одну папку, для которой задается единый процент расчета. В результате стоимость расширенной гарантии определяется не отдельно для каждого SKU, а для всей товарной группы.

Такой же принцип используется и в интернет-магазине, благодаря чему стоимость услуги остается одинаковой независимо от канала продажи.

При оформлении заказа менеджер может выбрать товары, для которых необходимо оформить дополнительную гарантию. На специальной форме система автоматически рассчитывает стоимость услуги, устанавливает признак гарантии для выбранной номенклатуры и сразу записывает рассчитанную сумму в документ «Заказ клиента», что полностью исключило ручной расчет стоимости.

А для выдачи гарантийных документов была реализована возможность печати непосредственно из документа «Реализация товаров и услуг». Это позволило существенно упростить и ускорить оформление сопроводительных документов.

Как проектировали права доступа

Одной из наиболее трудоемких задач стала настройка прав пользователей.

На первый взгляд права доступа кажутся второстепенным вопросом по сравнению с обменом данными или настройкой продаж. Однако на практике именно они определяют, насколько комфортно сотрудники смогут работать в системе после запуска.

Стандартный набор ролей редко полностью соответствует структуре конкретной компании. Поэтому настройка началась с описания реальных должностей и обязанностей сотрудников.

Заказчик сформировал перечень основных ролей — кассиры, менеджеры, специалисты по закупкам и руководители подразделений. После этого была сформирована матрица прав доступа, в которой для каждой категории пользователей определялись разрешенные действия, доступные разделы системы и ограничения по работе с документами.

На основе этой матрицы в 1С сформировали группы доступа. Каждая группа объединяла определенный набор ролей и функций. Затем пользователю назначалась нужных группы, а не отдельные права вручную. Назначение нескольких заранее определенных групп пользователю 1С позволяет исключить сложное задание прав доступа при развитии компании. При этом для одной группы было недостаточно единого уровня доступа.

Даже у сотрудников одного отдела набор задач мог различаться: например, для отдела продаж отдельно предусмотрели доступ только к продажам и расширенный вариант — с возможностью работать также с заказами покупателей. Это позволило заранее учесть такие различия и не перестраивать всю систему прав при изменении процессов.

Дальше права распределили между подразделениями в соответствии с их задачами: менеджеры магазина могли проводить заказы покупателей, реализации и перемещения на свой склад, сотрудники закупок — работать с заказами поставщикам и поступлениями, а кассиры — создавать и проводить ПКО и РКО. Для старших сотрудников и руководителей предусматривались расширенные права: перепроведение документов, редактирование, работа с инвентаризациями и контроль остатков.

Такой подход был важен не только на момент запуска. Если в компании появлялся новый сотрудник, ему достаточно было назначить соответствующую группу доступа — не настраивать права заново по отдельности. При изменении правил работы также можно было скорректировать саму группу, и изменения применялись ко всем пользователям, которым она назначена.

Часть ограничений потребовала доработки типового функционала 1С. В частности, право на распроведение отдельных документов зависело от роли пользователя.

Так сначала были согласованы реальные правила работы сотрудников, а уже затем эта модель перенесена в 1С.

Такой подход позволил заранее согласовать правила работы сотрудников и избежать большого количества организационных вопросов после запуска системы.

Проблема такого подхода проявляется позже, когда выходит очередное обновление типовой конфигурации. Чем больше изменений внесено в типовую конфигурацию, тем сложнее становится сопровождение системы и тем дороже обходится ее развитие.

Поэтому в рамках проекта был выбран другой подход. Все необходимые изменения реализовывались через механизмы расширений и внешние доработки без изменения базовой конфигурации.

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

Такой подход сокращал сроки внедрения, снижал стоимость разработки и позволял сохранить совместимость с последующими обновлениями 1С.

Одним из таких решений стало расширение списка номенклатуры от TN Soft. Оно значительно расширило возможности стандартного интерфейса без вмешательства в типовую конфигурацию.

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

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

Оперативная аналитика для руководителей

Помимо автоматизации ежедневной работы сотрудников проект решал еще одну важную задачу — предоставление руководителям актуальной информации для принятия управленческих решений.

Когда данные о заказах, продажах и прибыли находятся в разных отчетах, руководителю приходится тратить время на их сбор и сопоставление. При этом одной информации о валовой прибыли недостаточно: важно понимать, за счет каких продаж формируется результат, что происходит с объемом продаж и какие товары или направления дают основной вклад в выручку.

Поэтому в рамках проекта были разработаны управленческие отчеты, которые позволяют смотреть на продажи сразу с нескольких сторон. Руководитель может сравнить продажи за аналогичные периоды, увидеть динамику, сформировать рейтинг продаваемых товаров и одновременно оценить валовую прибыль.

Такой подход позволяет не просто получать итоговые цифры, а быстро находить изменения, которые требуют внимания: например, увидеть снижение количества Заказов клиентов ранее чем будет произведены продажи по ним относительно прошлого периода, определить позиции с наибольшим объемом продаж и оценить, как изменения в продажах отражаются на валовой прибыли.

По сути, в системе появился оперативный аналитический контур, близкий по логике к BI. Руководителю не нужно собирать данные вручную из нескольких отчетов — необходимые показатели доступны в одном месте и могут использоваться для принятия решений практически в режиме реального времени.