Рано или поздно многие компании сталкиваются с ситуацией, когда учет по разным организациям исторически ведется в разрозненных информационных базах устаревшей конфигурации Бухгалтерия предприятия 2.0 (БП 2.0). Принятие решения об объединении учета в единую информационную базу на современной платформе Бухгалтерия предприятия 3.0 (БП 3.0) — это стратегический шаг, который позволяет централизовать нормативно-справочную информацию (НСИ), упростить подготовку консолидированной отчетности и снизить затраты на администрирование системы.
Однако процесс слияния баз таит в себе множество технических и методологических трудностей. Как избежать массового задвоения контрагентов и номенклатуры? Какую стратегию объединения выбрать? Как не потерять остатки по сложным регистрам учета НДС и УСН? В этой статье мы подробно разберем оптимальные алгоритмы, пошаговые инструкции и лучшие практики для решения этой задачи.
Перед началом работ необходимо определиться с архитектурным подходом. Существует два принципиально разных сценария объединения:
Давайте проанализируем, почему Сценарий Б является гораздо более безопасным и предпочтительным на практике:
ПоискИУдалениеДублей в БП 3.0 работает на порядок быстрее и корректнее аналогичных разрозненных обработок для БП 2.0. Она позволяет гибко настраивать правила поиска (по ИНН, КПП, похожим наименованиям) и безопасно заменять ссылки во всех проведенных документах.Прежде чем выгружать данные, необходимо провести тщательную техническую чистку баз-источников. Если этого не сделать, весь накопленный за годы работы «мусор» перейдет в новую систему, многократно усложнив процесс сопоставления данных. Выполним следующие шаги:
Шаг 1. Префиксирование кодов справочников и номеров документов. Это критически важная процедура. Каждой исходной базе необходимо назначить свой уникальный префикс (например, «М1», «М2», «М3»). Настроить префикс организации можно непосредственно в карточке организации. После этого с помощью обработки «Групповое изменение реквизитов» следует переименовать коды ключевых справочников и номера существующих документов, добавив к ним префикс базы-источника. Это гарантирует, что при слиянии документов и справочников в целевой базе не возникнет конфликтов уникальности номеров и кодов.
Шаг 2. Тестирование и исправление (ТиС). Перед выгрузкой запустим конфигуратор каждой исходной базы и выполним полное тестирование и исправление информационной базы. Настроим параметры обработки «битых» ссылок: при наличии несуществующих элементов установим значение «Очищать ссылки» или «Создавать объекты» (в зависимости от критичности данных).
Шаг 3. Удаление помеченных на удаление объектов. Очистим базы от всех документов и справочников, помеченных на удаление. Если этого не сделать, помеченные объекты будут выгружены вместе с основными данными по ссылкам, что создаст дополнительный хаос в целевой базе.
Шаг 4. Закрытие отчетных периодов. Слияние баз и перенос остатков оптимально производить на стыке отчетных периодов (например, на 31 декабря прошедшего года). Перед выгрузкой убедимся, что во всех базах-источниках полностью закрыты все месяцы, рассчитана себестоимость, закрыты счета затрат и отсутствуют отрицательные остатки («краснота») на счетах бухгалтерского учета.
Давайте разберем неочевидный, но крайне опасный подводный камень, с которым часто сталкиваются технические специалисты при слиянии баз.
Очень часто «куча баз» у клиента исторически создавалась путем простого копирования одной и той же исходной базы (сделали копию базы, переименовали организацию, стерли «лишние» документы и продолжили работу). В этом случае базы являются «базами-клонами».
В чем заключается опасность? У элементов справочников (контрагенты, номенклатура, договоры), которые были созданы в исходной базе еще до момента ее копирования, будут абсолютно одинаковые уникальные идентификаторы — GUID (УИД). Хуже того, из-за особенностей автогенерации идентификаторов, элементы, созданные в разных базах уже после копирования, также могут случайно получить одинаковые GUID.
Если мы попытаемся выполнить перенос остатков и НСИ через стандартную универсальную выгрузку/загрузку XML (которая по умолчанию сопоставляет данные именно по GUID), то программа просто перезапишет данные одного контрагента данными другого из последующей базы. Это приведет к фатальной путанице в учете и искажению баланса.
Решение проблемы: При настройке правил обмена в специализированной конфигурации Конвертация данных 2.1 (КД 2.1) необходимо принудительно отключить поиск по уникальному идентификатору (снять галочку «Находить по GUID» в настройках правил сопоставления объектов справочников). Вместо этого мы должны жестко зафиксировать поля поиска, по которым система будет находить и сопоставлять элементы.
Рассмотрим пример настройки обработчика «Поля поиска» в КД 2.1 для справочника Контрагенты:
// Пример алгоритма сопоставления контрагентов по ИНН и КПП в Конвертации данных 2.1
Если СвойстваПоиска.Получить("ЭтоГруппа") = Истина Тогда
// Группы справочника сопоставляем только по наименованию
СтрокаИменСвойствПоиска = "Наименование, ЭтоГруппа";
Иначе
// Для элементов проверяем ИНН
Если ЗначениеЗаполнено(СвойстваПоиска.Получить("ИНН")) Тогда
СтрокаИменСвойствПоиска = "ИНН, КПП, ЭтоГруппа";
Иначе
// Если ИНН не заполнен, сопоставляем по наименованию
СтрокаИменСвойствПоиска = "Наименование, ЭтоГруппа";
КонецЕсли;
КонецЕсли;
Для каждого ключевого справочника необходимо выстроить индивидуальную стратегию переноса и сопоставления, чтобы не допустить дублирования НСИ:
Основным идентификатором контрагента (юридического лица или ИП) является связка реквизитов ИНН + КПП. Для физических лиц сопоставление выполняется по связке ФИО + ИНН (при наличии).
Сопоставление номенклатуры — наиболее трудоемкий процесс. Попытка автоматического сопоставления только по наименованию часто приводит к ошибкам из-за различий в написании (например, «Болт М8» и «Болт М8 оцинкованный»).
Артикул или Штрихкод (если на предприятии ведется строгий учет номенклатуры по этим параметрам).Договоры жестко привязаны к своим владельцам — контрагентам и организациям. Сопоставление договоров по умолчанию по GUID проводить категорически нельзя.
Владелец (Контрагент) + Организация + ВидДоговора + Номер + Дата.Наименованию договора.При слиянии баз стандартными обработками обмена XML существует высокий риск задвоения предопределенных элементов справочников, ПВХ (например, «Статьи затрат», «Статьи движения денежных средств») и Планов счетов. Это критическая ошибка, которая приведет к сбоям в алгоритмах проведения документов и формировании регламентированной отчетности.
ИмяПредопределенныхДанных.Перенос начальных остатков на выбранную дату (например, на 01.01.2024 00:00:00) нельзя ограничивать только лишь заполнением бухгалтерских проводок по счетам через документ ВводОстатков. В БП 3.0 параллельно с бухгалтерским учетом функционирует сложная система регистров накопления и сведений, данные которых напрямую влияют на расчет налогов.
Рассмотрим ключевые области повышенного внимания:
Если организации находятся на Общей системе налогообложения (ОСНО), то для корректного формирования Книги покупок и Книги продаж в БП 3.0 крайне важно перенести остатки по специализированным регистрам накопления:
НДС предъявленный (остатки по неподтвержденному НДС от поставщиков, счет 19);НДС Авансы по договорам / НДС авансы по ставкам 18% (20%) (для корректного зачета НДС с полученных и выданных авансов, счета 76.АВ, 76.ВА);НДС Продажи и НДС Раздельный учет (при ведении раздельного учета НДС).Если перенести только сальдо по бухгалтерским счетам 19 и 76, программа БП 3.0 в последующих периодах не сможет автоматически принять эти суммы к вычету при регистрации счетов-фактур или зачете авансов.
Для организаций, применяющих УСН с объектом налогообложения «Доходы минус расходы», ведение Книги учета доходов и расходов (КУДиР) полностью базируется на регистрах накопления. При вводе остатков необходимо перенести детальные данные по регистру:
Расходы при УСН. В этом регистре хранятся сведения о неоплаченных поставщикам товарах и материалах, которые уже были приняты к учету. Без этих данных программа не признает расходы в отчетном периоде, когда фактически пройдет оплата с расчетного счета уже в новой объединенной базе.Давайте пошагово разберем, как выглядит финальный процесс слияния баз на практике:
Шаг 1. Создание чистой целевой базы БП 3.0. Создаем пустую информационную базу актуального релиза БП 3.0. Заводим в ней карточки всех объединяемых организаций, указывая их реквизиты, учетную политику и префиксы.
Шаг 2. Выгрузка и загрузка справочной информации (НСИ). С помощью правил обмена, разработанных в КД 2.1 (с отключенным поиском по GUID и настроенным сопоставлением по ИНН/артикулам), поочередно выгружаем справочники из каждой подготовленной базы БП 3.0 и загружаем их в целевую базу. Для переноса используем обработку УниверсальныйОбменДаннымиXML.
Шаг 3. Запуск обработки поиска и удаления дублей. В целевой базе БП 3.0 переходим в раздел «Администрирование» — «Обслуживание» — «Корректировка данных» — «Поиск и удаление дублей». Настраиваем поиск для справочника Контрагенты (по совпадению ИНН) и справочника Номенклатура (похожие наименования). Объединяем найденные дубли. При этом система автоматически перепривяжет все ссылки на правильные элементы.
Шаг 4. Ввод начальных остатков. После того как справочники объединены и очищены от дублей, выполняем перенос остатков по каждой организации. Это можно сделать следующими способами:
ВводОстатков и перенести их XML-обменом в целевую базу.Шаг 5. Контроль и сверка результатов. Это важнейший этап проверки качества переноса. По каждой организации в базе-источнике и в новой целевой базе БП 3.0 необходимо сформировать Оборотно-сальдовую ведомость (ОСВ) по всем счетам на дату ввода остатков. Показатели дебетовых и кредитовых сальдо по всем субсчетам должны совпадать до копейки. Также следует сверить аналитические отчеты: ведомости по взаиморасчетам с контрагентами, остатки товаров на складах и отчеты по разделу учета НДС.
Разработка собственных правил обмена в конфигурации Конвертация данных 2.1 — это процесс, требующий высокой квалификации программиста 1С, глубокого понимания структуры метаданных и сотен часов на тестирование алгоритмов сопоставления сложных регистров НДС и УСН.
Если бюджет проекта и сроки ограничены, экономически более выгодным решением является приобретение готовых коммерческих правил переноса и слияния баз от профильных разработчиков. Такие продукты уже содержат:
Какой бы путь вы ни выбрали — написание собственных правил или использование готовых инструментов, строгое соблюдение предложенной методологии, предварительная чистка данных и сверка остатков гарантируют успешное и безопасное объединение ваших информационных баз.