К статье
Практический материал

Автоматизация · 11 мин

Чего не хватает в 1С и как закрыть эти пробелы

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

Типовые конфигурации 1С — «Управление торговлей», «Бухгалтерия предприятия», «Зарплата и управление персоналом» — покрывают стандартные процессы учёта, но почти каждая компания рано или поздно упирается в ограничения. Пользователи жалуются на неудобные отчёты, отсутствие нужных интеграций, перегруженный интерфейс и ручные операции, которые «должны были бы делаться сами». Эти жалобы не прихоть: они сигнализируют о реальных разрывах между типовой логикой программы и бизнес-процессами конкретной организации.

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

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

Как отличить отсутствующую функцию от ненастроенной

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

Практический приём — сформулировать потребность в виде сценария: «пользователь X должен выполнить действие Y и получить результат Z». Затем пройти этот сценарий в демонстрационной базе актуальной версии конфигурации. Если сценарий выполняется — проблема в настройке рабочей базы. Если нет — пробел реальный, и дальше нужно выбирать способ его закрытия.

Проверка перед доработкой
  1. 1
    Сформулируйте потребность как сценарий: кто, что делает, какой результат получает
  2. 2
    Проверьте функциональные опции и настройки в разделе администрирования
  3. 3
    Проверьте права и роли пользователя, который не видит нужную функцию
  4. 4
    Повторите сценарий в демобазе актуального релиза конфигурации
  5. 5
    Только если сценарий не выполняется — планируйте расширение или доработку

Отчёты и аналитика: самый массовый пробел

Типовые отчёты 1С показывают учётные данные, но руководителю обычно нужна управленческая аналитика: маржинальность по направлениям, динамика дебиторки с разрезами по менеджерам, план-факт продаж, ABC-анализ. Часть таких задач решается вариантами отчётов на СКД — в типовых конфигурациях почти любой отчёт можно перенастроить: добавить группировки, отборы, вычисляемые поля и сохранить как свой вариант. Этот инструмент недооценён: опытный пользователь без программирования собирает на нём большинство управленческих срезов.

Ограничение в том, что СКД опирается на данные, которые уже есть в базе. Если нужная аналитика требует показателей, которых в учёте нет (например, данные CRM, сайта или склада маркетплейса), отчёт придётся строить снаружи. Здесь типовые варианты — выгрузка в Excel, подключение BI-инструментов к базе или к регулярной выгрузке, либо доработанный отчёт с обращением к внешним источникам.

Перед заказом нового отчёта у разработчика попросите опытного пользователя собрать нужный срез через «Изменить вариант отчёта». По опыту внедрений до половины запросов на «новые отчёты» закрываются настройкой СКД за один-два часа вместо платной доработки.
ПЗ
Практическое замечание

Интеграции с внешними системами

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

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

Маршрут решения

Как выбрать способ интеграции

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

Права доступа и разграничение ответственности

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

Часть задач закрывается штатными механизмами: датой запрета изменения данных, профилями групп доступа, ограничением доступа на уровне записей (RLS) в конфигурациях, где он реализован. Но RLS заметно замедляет запросы на больших базах, а тонкие сценарии («менеджер видит свои заказы, руководитель отдела — заказы отдела») часто требуют доработки шаблонов ограничений. Это одна из областей, где экономия на настройке оборачивается реальными рисками для данных.

Автоматизация рутинных операций

Многочисленные ручные действия — отдельный класс пробелов: массовое создание документов, пакетная печать, автоматическое выставление счетов по расписанию, напоминания о просроченной дебиторке, контроль заполнения обязательных реквизитов. Типовые конфигурации автоматизируют проведение документов, но сценарии «сверх учёта» — напоминания, согласования, контрольные проверки — в них представлены слабо.

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

Способы закрыть пробел

Настройка типовой конфигурации

Бесплатно и безопасно для обновлений, но ограничено тем, что предусмотрел вендор

Внешние отчёты и обработки

Быстро и не трогает конфигурацию, но не подходит для автоматических проверок при записи документов

Расширение конфигурации

Гибко и совместимо с обновлениями; требует разработчика и контроля совместимости при смене релиза

Изменение типовой конфигурации

Решает всё, но усложняет обновления и повышает стоимость сопровождения

Удобство интерфейса и скорость работы пользователей

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

Когда настройки не хватает — например, нужна отдельная «кнопка-рабочее место» для кладовщика или кассира — делается доработка в виде расширения с собственной формой. Такие узкие рабочие места заметно сокращают ошибки операторов, потому что человек видит только те поля и действия, которые входят в его обязанности.

Типичные ошибки
01
Заказ доработки без проверки функциональных опций — оплаченная разработка дублирует штатную возможность
02
Изменение типовой конфигурации там, где достаточно расширения — каждое обновление превращается в проект
03
Отсутствие тестовой копии — доработка проверяется сразу на живых данных с риском испортить учёт
04
Нет владельца доработки — после ухода разработчика никто не знает, как она работает и что сломается при обновлении

Как организовать работу с пробелами системно

Разовые жалобы пользователей стоит собирать в единый реестр: что не хватает, кому, как часто возникает задача, чем закрывается сейчас (обычно — ручным трудом или Excel). Такой реестр быстро показывает приоритеты: дорабатывать в первую очередь то, что съедает часы работы ежедневно, а не то, о чём громче всех спрашивают.

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

Контрольные точки

Как проверить результат доработки

Сценарий пользователя
Норма

Выполняется полностью на тестовой копии без ошибок

Тревожный признак

Сценарий работает только у разработчика или требует ручных «обходов»

Обновление конфигурации
Норма

Расширение совместимо, обновление проходит штатно

Тревожный признак

Обновление требует ручного переноса изменённых типовых объектов

Производительность
Норма

Формы и отчёты открываются без заметного замедления

Тревожный признак

После доработки списки и проведение документов стали ощутимо медленнее

Частые вопросы

Можно ли обойтись без программиста, если в 1С чего-то не хватает?

Частично да. Функциональные опции, варианты отчётов на СКД, настройки прав и интерфейса, загрузка данных из файлов — всё это доступно подготовленному пользователю или администратору. Программист нужен, когда требуется автоматическая реакция на события, интеграция по API или новая печатная форма со сложной логикой.

Что лучше: расширение или изменение конфигурации?

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

Почему после обновления перестала работать доработка?

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

Как понять, что проблема в правах, а не в отсутствии функции?

Простой тест: зайдите под пользователем с полными правами и повторите действие. Если функция появилась — дело в ролях и профилях доступа. Если её нет и у администратора — проверяйте функциональные опции или версию конфигурации.

Стоит ли покупать готовые модули и обработки со сторонних площадок?

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

Что делать, если потребность уникальна и готовых решений нет?

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

Итог

Что важно запомнить

Большинство жалоб «в 1С этого нет» решаются настройкой: функциональными опциями, правами, вариантами отчётов. Реальные пробелы закрывайте по нарастанию риска: сначала настройка, затем внешние обработки, потом расширения, и лишь в крайнем случае — изменение типовой конфигурации. Любую доработку проверяйте на копии базы и фиксируйте в реестре, чтобы обновления не превращались в аварии.