Ошибка возникает, если в базе есть у каких-то объектов, реквизитов, субконто - значение NULL, а у них такого значения быть не может. И появляется такая ошибка только в SQL базах. Т.е. если такую базу выгрузить в файловую, то там уже этой ошибки не будет. Т.к. у файловой базы свои таблицы (всего 4 шт.), а у SQL свои. И SQL база критично реагирует на такие значения в своих таблицах.
Эта проблема не решается никакими тестированиями (ни внешним, ни внутренним) ни в каких вариантах баз (SQL или файловая) и даже Процедурой _1sp_DBReindex в менеджере SQL, которая вроде как должна проводить реструктуризацию таблиц в SQL.
Разберём решение проблемы на примере перехода с Бухгалтерии 3.0 ПРОФ на КОРП. После перехода у счёта 68.01 появляется новое субконто РегистрацияВНалоговомОргане. И тогда, в базах на SQL, все создание в ПРОФ версии документы которые используют этот счёт, не будут перепроводится. Будет выходить выше показанная ошибка. Т.к. это новое субконто у старых документов, в проводках, запишется со значением NULL (хотя должно быть Пустое значение, ну или как-нибудь налоговый орган).
Чтобы устранить эту ошибку, нужно убрать значения NULL там, где их не должно быть. В данном случае в документах, где используется субконто РегистрацияВНалоговомОргане. Сделать это можно, написав обработку, которая заменит NULL на Пустое значение (готовую обработку можно скачать из этой статьи). Делать обработкой, т.к. попытка изменить значение этого субконто в проводках документа вручную, приводит к всё той же ошибке.
Обработку для замены NULL'ов во всех субконтах РегистрацияВНалоговомОргане можно скачать из этой статьи, внизу.
.НО так заменить NULL в SQL базе не получится, во время выполнения обработки будет выдана та же самая ошибка. Поэтому необходимо сделать так:
1. Выгрузить уже рабочую, переведённую на КОРП версию, SQL базу в dt’шник (в конфигураторе Администрирование – Выгрузить базу – выберите куда выгрузить базу в виде файла *.dt)
2. Загрузить dt’шник в файловую базу (в ненужной или заранее подготовленной, чистой, файловой базе, в конфигураторе Администрирование – Загрузить базу – выбрать выгруженный ранее dt’шник)
3. Выполнить обработку в файловой базе (там ошибки не будет и все NULL’ы корректно заменяться) (как выполнить обработку описано ниже)
4. Выполнить внешнее и внутреннее тестирование базы. Это обязательно нужно сделать иначе при загрузке базы обратно в SQL будет выходить та же ошибка. (как выполнить эти тестирования можно посмотреть тут: http://kb.stspp.ru/software/inner_and_outer_1c_testing)
5. Теперь наоборот выгрузить dt’шник из файловой базы и загрузить его в SQL базу. Теперь при проведении обработанных документов ошибки выходить не будет.
Обработка из этой статьи находит все документы, за указанный период, у которых в проводках фигурирует субконтно РегистрацияВНалоговомОргане (которое появляется в КОРП версии), у которого значение NULL. И заменяет это значение на Пустое значение.
В обработке необходимо указать период, за который необходимо обработать документы (можно за весь период в котором ведётся учёт в базе) и нажать «Заполнить табличную часть». После чего можно галками пометить какие документы обработать (можно выбрать все) и нажать кнопку «Выполнить обработку».
Соответственно если у кого-то такая же ошибка, но НЕ после перехода на КОРП, а на пример после обмена, загрузки каких-то данных, выполнения каких-то обработок и т.д. То необходимо выявить, где присвоилось значение NULL в конкретном документе/справочнике и подобным способом убрать этот NULL но уже своей обработкой, но в том порядке, как описано выше. Помните, что NULL может быть, как в проводках документа, в т.ч. не только бухгалтерских, так и где-нибудь на форме документа/справочника, в каком-нибудь реквизите, но в таком случае он наверно даже не откроется.
Также если это ошибка появилась у вас при проведении документа, после того как вы перевели файловую базу Бух КОРП на SQL (а база когда-то изначально была ПРОФ), то значит у тех документов что были созданы в ПРОФ версии, сейчас также в субконто РегистрацияВНалоговомОргане значение NULL и SQL база такое не приемлет. И при загрузке базы в SQL будет выходить такая ошибка. Тут на самом деле в файловой базе значений NULL по факту не будет, но SQL в свои таблицы загрузит именно такие значения. Поэтому тут надо заставить базу SQL создать эти NULL'ы и потом в файловой базе их исправить. Но как это сделать, уже не подскажу.
