Системы «1С:Предприятие» стали не просто инструментом бухгалтерского или управленческого учета, а «кровеносной системой» современного бизнеса. Сбой в работе базы или потеря данных может парализовать компанию за считанные часы.
Регулярное техническое обслуживание 1С не страховка, а обязательное условие. Рассмотрим три ключевых столпа поддержки: обновление конфигураций, резервное копирование и доработку печатных форм, без которых эксплуатация 1С невозможна.
Обновление типовых конфигураций
Обновление конфигурации - процесс загрузки изменений от разработчика (Фирмы «1С») в вашу информационную базу. Это необходимо для соответствия законодательству, получения новых функций и исправления ошибок платформы.
Архитектура поставки и поддержки
Любая типовая конфигурация находится на «поддержке» Стандарт Платформа. Это означает, что внутри вашей базы хранится не только ваш рабочий код, но и «эталонная» копия от поставщика. Когда разработчик выпускает новую версию (например, с новыми декларациями), механизм платформы сравнивает три состояния: старый эталон, новый эталон и вашу текущую конфигурацию.
Как происходит сравнение. Система анализирует каждое свойство объектов метаданных (справочников, документов, отчетов). Если свойство не менялось ни разработчиком, ни вами, или менялось только одной из сторон, система автоматически выбирает правильный вариант (берет новое от поставщика или оставляет ваше). Самый сложный сценарий - «конфликт», когда и вы, и фирма «1С» меняли один и тот же реквизит. В таком случае платформа выделит спорные объекты жирным шрифтом и предложит принять решение вручную.
Стратегии обновления модифицированных баз
Если конфигурация типовая и не трогалась, обновление выполняется в полуавтоматическом режиме за пару кликов. Но если в код вносились правки (добавлены колонки в документ или изменен алгоритм), процесс усложняется.
Подход с правилами поддержки. Для объектов, которые вы меняли, но хотите получать обновления, можно установить правило «Объект поставщика редактируется с сохранением поддержки». Это заставит систему каждый раз при обновлении показывать вам расхождения и помогать переносить ваш код в новую версию.
Если же объект переписан полностью (например, удален типовой отчет и создан свой), его лучше снять с поддержки полностью - тогда обновления по этому объекту приходить не будут, и система не будет выдавать ошибок при сравнении.
Перед любым обновлением обязательно создайте полную резервную копию базы. Даже при автоматическом обновлении конфликты могут возникать неожиданно. Программисты 1С часто используют инструмент «Сравнение и объединение конфигураций» вручную: они берут ваш файл конфигурации (*.cf), старый типовой cf и новый типовой cf.
Сначала переносят ваши изменения в старую типовую, чтобы понять объем правок, а затем «накатывают» их на новую версию.
Форматы файлов обновления
Поставщик распространяет обновления в двух форматах. Файл с расширением cf полная конфигурация. Он большой, но универсальный: позволяет обновляться с любой версии. Файл cfu файл обновления, содержащий только разницу между версиями (дельту). Он легкий, но требует строгого соответствия версии, с которой вы обновляетесь. Если у вас версия 2.0, а файл обновления сделан для версии 2.0 -> 4.0, а версию 3.0 вы пропустили, cfu не подойдет - нужен полный cf.
Бэкапы информационной базы
Резервное копирование - единственная защита от «человеческого фактора» (случайное удаление документов), аппаратных сбоев (поломка SSD диска) и атак шифровальщиков. Однако в 1С есть нюансы: далеко не любой скопированный файл является пригодным бэкапом.
Файловый режим vs Серверный режим
В файловом режиме база представлена одним файлом с расширением «1CD». В этом случае достаточно скопировать этот файл, предварительно убедившись, что все пользователи вышли из системы. Копирование можно настроить стандартными средствами Windows (планировщик задач + bat-файл с командой копирования). Однако главная проблема файлового режима - низкая надежность при обрыве копирования и невозможность восстановления «на лету».
Серверный режим (SQL) требует иного подхода. Здесь данные хранятся в СУБД (PostgreSQL, MS SQL). Копировать файлы данных SQL напрямую, пока сервер работает, нельзя - получите логический сбой. Профессионалы используют штатные утилиты СУБД, например pg_dump для PostgreSQL. Эта утилита создает дамп (файл с SQL-скриптами), который согласован во времени и не блокирует работу пользователей.
Почему выгрузка в .dt - не лучший бэкап
Многие администраторы ошибочно считают выгрузку базы в файл .dt (через Конфигуратор) полноценным бэкапом. Это не так. Во-первых, выгрузка требует монопольного доступа: пока она идет, никто не может работать.
Во-вторых, при повреждении логической структуры базы (например, «битых» ссылок) выгрузка в dt может пройти успешно, но при попытке загрузить эту dt обратно в пустую базу возникнет ошибка. Программа может создать пустой файл или файл, заполненный «000», который не восстановить. Выгрузка в dt предназначена для переноса базы между разными СУБД или сжатия, но не для резервного копирования.
Правильная схема:
- На уровне СУБД: Ежедневный автоматический
pg_dump(илиsqlbackupдля MSSQL). - На уровне файлов: Регулярное резервное копирование самих файлов базы (особенно актуально для файлового режима).
- Контроль: Раз в неделю проверяйте восстановление бэкапа на тестовом сервере. Непроверенный бэкап просто мусор на диске.
Регламентные операции СУБД
Обслуживание 1С включает не только копирование, но и обслуживание самой СУБД. Раз в сутки рекомендуется выполнять перестроение индексов и обновление статистики. Индексы в SQL-таблицах со временем фрагментируются из-за частых записей и удалений данных.
Перестроение индексов (реорганизация) ускоряет работу отчетов, которые фильтруют данные по датам или номенклатуре. Обновление статистики помогает планировщику запросов SQL выбирать оптимальный план выполнения, что критически важно для сложных управленческих отчетов.
Тестирование и исправление базы
В Конфигураторе есть волшебная кнопка «Тестирование и исправление». Это инструмент для «лечения» битых ссылок и нарушения логической целостности. Однако применять его «на всякий случай» нельзя. Опция «Сжатие таблиц» доступна только для файлового режима - она физически уменьшает размер файла 1CD, удаляя пустоты. Для SQL-баз эта опция недоступна (там сжатием занимается администратор SQL).
Если база работает стабильно, достаточно выполнять «Реиндексацию таблиц» и «Проверку ссылочной целостности» раз в месяц или перед крупным обновлением. Правило железное: перед запуском тестирования всегда делайте бэкап, так как функция может удалить «потерянные» данные, и восстановить их будет неоткуда.
Доработка печатных форм
Бизнес редко устраивают типовые бланки. Клиенту нужен специфический дизайн счета, дополнительная колонка в ТОРГ-12 или матричный вывод данных (размеры товаров в колонках, а товары в строках). Вопрос: как это сделать, не убив возможность обновлять конфигурацию?
Внешние печатные формы (механизм БСП)
Современный стандарт (Библиотека стандартных подсистем) предоставляет механизм «Дополнительные отчеты и обработки». Этот способ позволяет подключать новую печатную форму без внесения изменений в код конфигурации. Файл с расширением .epf хранится отдельно или прямо в базе данных как элемент справочника.
Как это работает разработчик. В модуле внешней обработки прописывается экспортная функция
Печать(). Она возвращает табличный документ. Чтобы платформа «увидела» обработку, в модуле объекта описывается функцияСведенияОВнешнейОбработке(), где указывается, для какого документа (например, «РеализацияТоваровУслуг») и в какое меню встроить кнопку. При следующем открытии документа кнопка появляется автоматически.
Преимущества. Обновление типовой конфигурации проходит «в один клик» - строки кода типовых объектов не затронуты. Система остается на поддержке. Если новая версия 1С меняет структуру данных (например, переименовывает реквизит), внешняя форма сломается, но это произойдет изолированно, не обрушив всю базу. Такую форму можно отключить галкой для конкретного пользователя или на время.
Создание «кросс-таблиц» в печатных формах
Самый частый запрос: вывести товары в строки, а свойства (размеры, цвета) - в динамические колонки. Ручное рисование таких таблиц через циклы и области адский труд, так как кол-во колонок заранее неизвестно.
Решение через СКД. Система компоновки данных (СКД) изначально умеет строить кросс-таблицы. Разработчик создает схему, где в ресурсы помещает количественный показатель (например, «Наличие»), в строки - «Товар», а в колонки - «Размер». При формировании отчета СКД сама «повернет» данные, создав нужное количество колонок. Такой отчет также можно оформить как внешнюю обработку, а результат выводить в ТабличныйДокумент, который можно отправить на печать или сохранить в PDF.
Кастомизация типовых макетов
Иногда нужно не создать форму с нуля, а слегка подправить типовую (сдвинуть логотип, добавить подпись). Механизм расширений (также работающий без снятия с поддержки) позволяет «вклиниться» в выполнение типового кода. Вы создаете расширение, находите в типовой конфигурации нужную печатную форму, переопределяете ее макет или модуль. Система будет использовать вашу версию макета, игнорируя типовую, но при этом типовые объекты останутся нетронутыми.
Это технически сложнее, чем внешние обработки, и требует осторожности: при сильном изменении структуры данных в новом релизе расширение может перестать работать.
Ограничения и риски
Доработка без изменений не панацея. Внешние обработки живут своей жизнью. Если в типовой конфигурации изменится имя экспортного метода, который вы вызываете в своей форме, форма упадет. Отследить это можно только функциональным тестированием после каждого обновления. Кроме того, внешняя обработка не может добавить новое поле в табличную часть документа - для этого все равно придется снимать конфигурацию с поддержки и менять метаданные.
Изоляция и безопасность обновлений достигается ценой невозможности изменять структуру данных базы из такой обработки.
Практические рекомендации
Для отдела ИТ и администраторов:
- Автоматизация бэкапов: Настройте регламентное задание на сервере для выгрузки дампа СУБД. Не полагайтесь на человеческую память. Для файловых баз используйте символические ссылки или robocopy в планировщике.
- Мониторинг обновлений: Перед обновлением рабочей базы всегда обновите тестовую копию. Проверьте критичные отчеты и печатные формы. Только потом «накатывайте» на прод.
- Чистота в коде: Если вы все же изменяете типовую конфигурацию, ведите журнал изменений. Записывайте, какой объект и зачем был изменен. Через полгода вы забудете, почему переписали модуль «Проведения», и при обновлении получите критический конфликт.
Для программистов 1С:
- Предпочитайте Внешние обработки изменению типовых объектов. Это дешевле в поддержке для клиента.
- При создании сложных матричных печатных форм используйте СКД, а не костыли с программным заполнением макета. СКД работает с наборами данных быстрее и проще в отладке.
- При обновлении модифицированной конфигурации используйте режим показа «дважды измененных свойств». Так вы не пропустите критический конфликт, просматривая тысячи строк отчета сравнения.
Обслуживание 1С постоянный процесс баланса. С одной стороны - необходимость держать систему в актуальном, безопасном и быстром состоянии (бэкапы, индексы, обновления). С другой - потребность бизнеса в уникальных формах и отчетах, отличающих компанию от конкурентов.
Правильная архитектура доработок (через внешние обработки) и строгая дисциплина бэкапов (через СУБД, а не через dt) превращают 1С из «головной боли» в надежного партнера, работающего 24/7.
