Ситуация, когда после слияния двух или более информационных баз «1С:Управление торговлей 11.4» (или ERP) документы перестают проводиться, — это настоящий кошмар для администратора и программиста. Одной из самых коварных ошибок является сообщение: «Ошибка в алгоритмах при записи в регистр РезервыТоваровОрганизаций: организация и кор. организация совпадают...». Рассмотрим подробнее, почему это происходит и как по шагам восстановить работоспособность системы, не прибегая к полной выгрузке данных в новую базу.
Проанализируем архитектуру УТ 11. В этой конфигурации учет запасов реализован через сложную систему «ключей аналитики» и механизмов «Интеркампани» (передачи товаров между организациями). Когда вы объединяете две базы, вы часто используете стандартную обработку Поиск и замена дублей, чтобы объединить одинаковые организации, склады или номенклатуру.
Выясним причину сбоя: при замене одной организации на другую в документах, ссылка в «шапке» документа меняется, но данные во внутренних, зачастую скрытых регистрах и табличных частях, остаются прежними. Ошибка «организация и кор. организация совпадают» возникает из-за того, что в регистре накопления РезервыТоваровОрганизаций система видит попытку передать товар от организации «А» организации «А». С точки зрения логики «Интеркампани», это абсурд: организация не может продавать товар самой себе, если это не комиссионная торговля (тип запасов ТоварНаХраненииСПравомПродажи). Если же тип запасов указан как СобственныйТовар, срабатывает жесткая проверка в модуле набора записей регистра, и проведение блокируется.
Первым делом проверим настройки системы. Если после слияния предполагается работа только от одного юридического лица, необходимо полностью деактивировать механизмы многофирменного учета и «Интеркампани».
Организации. Все «лишние» организации должны быть не просто помечены на удаление, но и полностью вычищены из всех документов. Снятие галочки «Использовать несколько организаций» в константах не очищает уже записанные движения.Посмотрим на ситуацию практически: если у нас осталась одна организация, то записи в регистре РезервыТоваровОрганизаций за прошлые периоды (где фигурировали разные фирмы холдинга) могут стать невалидными. Автор темы на форуме нашел решение в полной очистке этого регистра.
Важно: Перед любыми манипуляциями обязательно создайте резервную копию базы!
Рассмотрим пример кода для очистки набора записей регистра накопления РезервыТоваровОрганизаций по конкретному документу, который выдает ошибку:
Процедура ОчиститьДвиженияПоРегиструРезервы(ДокументСсылка)
НаборЗаписей = РегистрыНакопления.РезервыТоваровОрганизаций.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(ДокументСсылка);
НаборЗаписей.Записать(); // Записываем пустой набор, удаляя старые движения
Сообщить("Движения по регистру РезервыТоваровОрганизаций для документа " + ДокументСсылка + " очищены.");
КонецПроцедуры
Если документов много, можно воспользоваться обработкой Групповое изменение реквизитов, но для очистки движений регистров лучше написать небольшую внешнюю обработку, которая очистит регистр РезервыТоваровОрганизаций за весь проблемный период.
Проанализируем еще одну важную деталь. В УТ 11 существует регистр сведений АналитикаВидовЗапасов. В нем хранятся уникальные ключи, связывающие организацию и тип запаса. При слиянии баз ссылки в этом регистре могут «биться».
Рассмотрим порядок действий для исправления аналитики:
АналитикаВидовЗапасов. Система автоматически пересоздаст нужные записи при проведении документов.КлючиАналитикиУчетаНоменклатуры. Однако будьте осторожны: на эти ключи ссылается множество регистров. Лучшим решением будет использование типовой обработки «Исправление ошибок в данных по видам запасов», которую можно найти через меню «Функции для технического специалиста» (в старых версиях — «Все функции»).Выясним, почему простое перепроведение не помогает. В документах реализации, оприходования и перемещения есть скрытая табличная часть ВидыЗапасов. Она заполняется в момент первого проведения. Когда вы меняете организацию в шапке, данные в этой ТЧ остаются старыми (со старой организацией).
Чтобы документ провелся корректно, нужно программно очистить эту табличную часть, чтобы при проведении система заполнила её заново, исходя из актуальных настроек и остатков. Посмотрим на пример кода:
ДокОбъект = СсылкаНаДокумент.ПолучитьОбъект();
ДокОбъект.ВидыЗапасов.Очистить();
// Устанавливаем признак необходимости перезаполнения видов запасов
ДокОбъект.ДополнительныеСвойства.Вставить("ПерезаполнитьВидыЗапасов", Истина);
ДокОбъект.ОбменДанными.Загрузка = Истина;
ДокОбъект.Записать();
После очистки ТЧ ВидыЗапасов документ следует провести в обычном режиме. Система увидит, что табличная часть пуста, и сформирует её заново, используя корректную (новую) организацию.
После того как технические ошибки в алгоритмах при записи (связанные с регистрами резервов) устранены, мы неизбежно столкнемся с проблемой отрицательных остатков. Слияние баз почти всегда приводит к тому, что приходы и расходы «разъезжаются» по времени или складам.
Проанализируем последовательность действий для финального восстановления учета:
Остатки и доступность товаров и Ведомость по товарам организаций. Вам придется либо корректировать даты документов прихода, либо вводить документы Инвентаризация (Оприходование излишков / Списание недостач), чтобы закрыть дыры, возникшие из-за разницы в данных двух баз.Выполнение регламентных операций по закрытию месяца. Это пересчитает регистры себестоимости и окончательно выправит виды запасов.Подводя итог, можно сказать, что решение проблемы слияния баз в УТ 11 заключается не в поиске «волшебной кнопки», а в методичной очистке регистров аналитики. Основной алгоритм действий программиста выглядит так:
РезервыТоваровОрганизаций, если он мешает записи документов.ВидыЗапасов в документах.Помните, что использование обработки «Поиск и замена значений» для таких объектов, как Организации в комплексных конфигурациях (УТ 11, КА 2, ERP), требует последующего программного пересчета всех связанных аналитик. Если объем данных огромен, иногда действительно проще перенести только остатки и справочники в чистую базу, но если важна история — описанный выше метод «реанимации» регистров является единственно верным.