Рано или поздно перед ИТ-отделом любой растущей компании встает вопрос оптимизации ИТ-ландшафта. Классический сценарий: в компании функционирует типовая конфигурация 1С:Бухгалтерия предприятия 3.0 (БП 3.0) для регламентированного учета и полностью самописная база («нетленка») для ведения оперативного управленческого учета, производства и интеграции с телефонией. Между базами настроен обмен.
Но вдруг от руководства поступает задача: «Давайте объединим всё в одну базу! Мы хотим обелить процессы, уйти от обменов и видеть всё в едином пространстве». На первый взгляд идея кажется логичной, но на практике такое решение может стать миной замедленного действия для бизнеса. Давайте подробно разберем, какие подводные камни скрывает этот процесс, проанализируем технические риски и выясним, как правильно аргументировать свою позицию перед руководством.
Типовая 1С:Бухгалтерия 3.0 — это одна из самых часто обновляемых конфигураций. Изменения в законодательстве, новые формы отчетности, новые форматы выгрузки заставляют фирму «1С» выпускать релизы по несколько раз в месяц (а в период сдачи отчетности — еще чаще). Если ваша БП 3.0 полностью типовая, ее обновление занимает считанные минуты и происходит в автоматическом режиме.
После того как вы внедрите в БП свою «нетленку», конфигурация автоматически снимется с поддержки (или перейдет в режим редактирования с сохранением поддержки). Рассмотрим, к чему это приведет:
Проанализируем пример. Предположим, в вашей управленческой части вызывалась процедура оповещения пользователей, заимствованная из общего модуля БП:
// Так код работал до обновления БП
ОбщегоНазначенияКлиент.ПоказатьПредупреждение(ОписаниеОповещения, "Документ успешно проведен!");
После очередного обновления разработчики «1С» перенесли этот метод в другой модуль или изменили состав его параметров. В результате вы получаете критическую ошибку выполнения (Runtime Error) прямо посреди рабочего дня у десятков пользователей:
// После обновления этот вызов вызовет ошибку: Метод объекта не обнаружен
// Придется срочно переписывать интеграционный код во всех ваших документах
Когда базы живут раздельно, обмен переносит только строго определенные данные. При объединении баз «в лоб» вы неизбежно столкнетесь с конфликтами ключевых справочников: Номенклатура, Контрагенты, ДоговорыКонтрагентов, Склады.
В управленческой базе номенклатура может иметь свою специфику (сложные спецификации производства, технические свойства для телефонии, внутренние артикулы). В бухгалтерии эти данные не нужны, там важна лишь финансовая составляющая и ставки НДС. При объединении вам придется:
УпрНоменклатура), что сводит на нет саму идею «единой базы».Выясним причину: если вы оставите один справочник Номенклатура, то любое изменение логики работы с ним со стороны «1С» (например, изменение форм или механизмов подбора) потребует от вас полной переработки форм управленческого учета.
Часто звучит предложение: «Давайте не будем трогать конфигурацию, а всю нетленку перенесем в расширение!». Это опасное заблуждение. Расширения конфигурации отлично подходят для кастомизации интерфейса или небольших доработок бизнес-логики, но они пасуют при попытке развернуть в них крупную учетную систему.
Рассмотрим основные проблемы расширений в данном сценарии:
Объединение баз приведет к резкому росту объема базы данных и количества одновременно работающих пользователей. В одной базе окажутся менеджеры по продажам, операторы телефонии, производственники и бухгалтеры.
Посмотрим на типичный конфликт интересов на уровне СУБД:
Кроме того, резко возрастают требования к аппаратному обеспечению (серверам приложений и СУБД) и время на создание резервных копий (бэкапов).
Если руководство настаивает на прозрачности («обелении») процессов и оперативности получения данных, совсем не обязательно устраивать опасное техническое слияние. Разберем более безопасные архитектурные альтернативы.
Вместо обмена файлами по расписанию мы можем реализовать синхронизацию данных в режиме реального времени. Настроим в 1С:Бухгалтерия HTTP-сервис, который будет принимать данные из управленческой базы в момент проведения документов.
Рассмотрим пример простого HTTP-сервиса на стороне БП для создания документа отражения производства:
Функция ОтразитьВыпускПродукции(Запрос)
// Получаем тело запроса в формате JSON
ДанныеJSON = Запрос.ПолучитьТелоКакСтроку("UTF-8");
Чтение = Новый ЧтениеJSON;
Чтение.УстановитьСтроку(ДанныеJSON);
СтруктураДанных = ПрочитатьJSON(Чтение);
Чтение.Закрыть();
// Создаем документ в Бухгалтерии на основе полученных данных
ДокВыпуск = Документы.ОтчетПроизводстваЗаСмену.СоздатьДокумент();
ДокВыпуск.Дата = ТекущаяДата();
ДокВыпуск.Организация = Справочники.Организации.НайтиПоРеквизиту("ИНН", СтруктураДанных.ИНН);
// ... Заполнение табличной части ...
Попытка
ДокВыпуск.Записать(РежимЗаписиДокумента.Проведение);
Ответ = Новый HTTPСервисОтвет(200);
Ответ.УстановитьТелоИзСтроки("Успешно проведено в БП");
Исключение
Ответ = Новый HTTPСервисОтвет(500);
Ответ.УстановитьТелоИзСтроки(ОписаниеОшибки());
КонецПопытки;
Возврат Ответ;
КонецФункции
Этот подход позволяет пользователям работать в разных базах, но информация переносится мгновенно, без задержек. Бухгалтерия остается полностью типовой и обновляется без проблем.
Если бизнес перерос рамки простой связки «БП + нетленка», правильным стратегическим решением будет переход на единую типовую ERP-систему от «1С». В продуктах класса КА или ERP блоки производства, оперативного учета и регламентированной бухгалтерии изначально спроектированы в единой базе и работают по общим правилам. Перенос функционала вашей «нетленки» в типовые механизмы ERP — задача сложная, но это даст стабильную систему на долгие годы вперед.
Для общения с бизнесом программисту нужно использовать язык цифр и рисков. Подготовим следующие аргументы:
Резюме: объединение глубоко кастомизированной управленческой базы и типовой БП 3.0 в одну информационную базу — крайне рискованный шаг. Стремитесь сохранять регламентированный учет чистым и типовым, а задачи оперативного управления и интеграции решайте через современные механизмы бесшовного обмена данными (HTTP/Web-сервисы, очереди сообщений).