Когда клиент переходит с 1С:Бухгалтерии на 1С:ERP, часть привычных инструментов в новой системе просто отсутствует. Так произошло со «Сканером чеков» — мобильным приложением, через которое бухгалтерия каждый месяц проводила десятки документов. Подходящих решений на рынке мы не нашли: в каждом был серьёзный риск по поддержке. Поэтому перенесли типовой сервис 1С из Бухгалтерии в ERP сами. Теперь сотрудники работают тем же приложением, что и раньше, а заполнение авансового отчёта по чекам вместо 5−10 минут занимает пару кликов.
О клиенте
Производственная компания с большим штатом сотрудников, активно ведущих хозяйственные расходы — закупки материалов, командировочные траты, представительские. Бухгалтерия ежедневно работает с авансовыми отчётами и поступлениями товаров через подотчётных лиц — за 2025 год сотрудники отсканировали через сервис около 830 чеков.
С какой задачей пришли
В старой 1С:Бухгалтерии у клиента работал встроенный сервис «1С:Сканер чеков». Сотрудник сканировал телефоном QR-код на бумажном чеке — данные через облачный сервис 1С попадали прямо в учётную систему. Дальше бухгалтерия в пару кликов превращала их в авансовые отчёты и поступления товаров.
К моменту перехода на 1С:ERP инструмент был частью ежедневной рутины бухгалтерии. Отказываться от него никто не собирался.
Но при переносе обнаружилось:
- В 1С:ERP нет ни самого сервиса, ни связанной с ним подсистемы;
- Поддержка типового «1С:Сканера чеков» в ERP не предусмотрена;
- В ERP есть похожий механизм — «Распознавание первичных документов», но он работает со сканами и фотографиями, а не с QR-кодами.
Стандартными средствами задачу было не решить. Нужно было либо переучивать сотрудников на ручной ввод, либо искать обходной путь.
Почему отказались от готовых решений на рынке
Прежде чем браться за разработку, мы изучили готовые расширения от сторонних разработчиков. На рынке нашли несколько вариантов, закрывающих похожие задачи. Изучили и отказались. На это было три причины.
Сотрудники привыкли к уже используемому решению. Любой сторонний продукт работает иначе — пришлось бы переучивать людей на новые сценарии. Для бухгалтерии, где привычка экономит часы в день, это серьёзный аргумент.
Каждое решение пришлось бы отдельно исследовать. Описание найденных решений было довольно кратким, часть деталей оставалась непрозрачной. Велик был риск потратить время и деньги на анализ — и в финале упереться в критичную проблему. Некоторые решения имели закрытый код, что сильно ограничивало возможности по адаптации.
Главное — поддержка. Все эти решения разработаны небольшими командами, чьи планы развития непонятны. Если 1С обновит типовую конфигурацию ERP, и стороннее расширение перестанет работать, нам придётся срочно искать выход. А ждать обновлений от автора решения — это лотерея. Особенно всё грустно для решений с закрытым кодом.
У типового решения от 1С такой проблемы не возникает: оно сопровождается вендором, и вероятность того, что 1С продолжит его развивать, существенно выше.
Что сделали
Решили перенести типовой сервис из БП в ERP — но не «как есть», а оформить расширением, чтобы не вмешиваться в основную конфигурацию ERP.
Разобрали, как устроен сервис в БП
В конфигурации БП за работу со сканером чеков отвечает подсистема «Шина мобильных приложений». На первый взгляд она компактная: несколько общих модулей и пара регистров. Кажется, перенести в ERP — задача на день-два.
На деле детальный анализ показал другое. Внутри модулей — десятки обращений к объектам, которых в ERP просто нет. У функций сканирования чеков обнаружилось около десяти уровней вложенности по стеку вызовов. Сканер чеков в БП — это не отдельный изолированный блок, а часть более широкой подсистемы.
Прямой перенос не работал. Нужно было выделить только то, что относится к чекам, и аккуратно переписать зависимости.
Начали с минимального прототипа
Чтобы не тратить недели на разработку «вслепую», мы собрали микро-ядро — минимальный код, который умел подключиться к облачному сервису 1С и получить данные одного чека. Без формы, без сохранения, без обработки ошибок — только проверка, что мы вообще можем достучаться до данных в ERP.
Через пару дней работы в ERP появились первые «сырые» данные одного отсканированного чека. Это был ключевой момент: стало понятно, что портирование возможно — дальше уже вопрос оснащения.
Развернули решение в полноценный сервис
После прототипа последовательно достроили функциональность.
- Документ «Кассовый чек подотчётного лица» — для хранения данных чека в ERP. Форму сделали по образцу типовых документов: пользователь не должен видеть разницы между сторонним и встроенным.
- Журнал чеков с кнопкой «Загрузить новые» — пользователь сам решает, когда подтянуть свежие данные с шины. Разместили в разделе «Закупки», рядом с основным документом «Приобретение товаров и услуг».
- Загрузка строк из чеков прямо в «Приобретение товаров и услуг» — основной сценарий бухгалтерии. Подотчётник принёс пачку чеков, бухгалтер за пару кликов превратил их в полноценное поступление.
Защитились от двойного учёта: в форме выбора чеков показываются только те, что ещё не загружены ни в один действующий документ. Связь между «Приобретением» и «Кассовым чеком» отображается через структуру подчинённости — бухгалтер видит, какие чеки в какой документ ушли.
Доработали типовой документ без модификации формы
Здесь важная техническая деталь. Чтобы документ «Приобретение товаров и услуг» начал понимать чеки, в его табличную часть нужны были три новых реквизита. Стандартный путь — заимствовать форму в расширение и доработать. Но у этого пути есть минус: при обновлении типовой ERP заимствованная форма не обновится автоматически, и нам придётся каждый раз сверять её вручную.
Поэтому мы пошли другим путём: добавили реквизиты программно, из кода — без заимствования формы. Получилось:
- Новые поля и кнопка «Загрузить кассовые чеки» появляются только при операции «Закупка через подотчётное лицо». Для остальных операций документ выглядит как раньше.
- При обновлениях типовой формы наш код встраивается в неё динамически, не мешая обновлениям.
В форме выбора чеков сразу показываем содержимое каждого — пользователю не нужно открывать чеки по одному, чтобы понять, что в них.
Что получил бизнес
- Сотрудники бухгалтерии продолжают пользоваться тем же мобильным приложением, что и раньше. Никакого переучивания.
- Поступления товаров от подотчётных лиц оформляются за пару кликов вместо ручного ввода. Для типичного авансового отчёта с тремя чеками это разница между 5−10 минутами заполнения 17 реквизитов вручную и парой кликов в форме выбора.
- Решение полностью совместимо с типовыми обновлениями ERP — расширение обновляется отдельно от основной конфигурации.
Выводы
Этот кейс — про то, что «перейти на ERP» не всегда означает «переучить всех сотрудников». Многие удобные инструменты, которые есть в 1С:Бухгалтерии и которых нет в ERP «из коробки», можно перенести — если подойти к этому грамотно: разобраться в зависимостях, выделить минимальное ядро, обернуть в расширение и не трогать типовую конфигурацию.
Сейчас расширение работает в одном учётном контуре клиента: код доступа к шине прикладных приложений был сгенерирован ещё в их 1С:Бухгалтерии и переиспользован при переносе в ERP. Структура объектов внутри расширения — общие модули, регистры, документ «Кассовый чек подотчётного лица», привязка к подсистеме «Закупки" — почти универсальна. Сейчас мы добавляем в неё механизм привязки приложения к базе, такой же, как в типовой 1С: Бухгалтерии. После этого расширение можно будет ставить и на другие контуры клиента, и тиражировать другим компаниям на ERP. Архитектура позволяет адаптировать его и для других конфигураций — «Комплексной автоматизации», «Управления торговлей», «Управления нашей фирмой».
Стоимость и сроки
Этот проект — перенос сервиса в ERP — стоил 275 000 ₽ и занял около месяца. Большая часть времени ушла на разбор подсистемы в БП и сборку минимального ядра в ERP. Эта работа уже сделана: у нас есть готовое расширение, которое мы дорабатываем под конкретного клиента. Поэтому для вас аналогичное решение обойдётся существенно дешевле и быстрее.
Похожая задача? Напишите — обсудим, что нужно перенести и что мы можем переиспользовать из уже готового.
Похожая задача? Напишите — обсудим, что нужно перенести и что мы можем переиспользовать из уже готового.