← На главную

Ситуации, когда после планового обновления конфигурации 1С:Бухгалтерия предприятия 3.0 перестают записываться или проводиться документы, не редкость. Одной из самых коварных ошибок является технический сбой на уровне базы данных SQL, сопровождающийся сообщением о невозможности вставки значения NULL в определенное поле таблицы. В нашем случае мы разберем проблему с документом Поступление на расчетный счет и полем Fld33747 в таблице Document181.

Выясняем причину возникновения ошибки

Рассмотрим ситуацию подробнее. При попытке сохранить документ система выдает ошибку уровня СУБД. Это происходит потому, что в структуре SQL-таблицы для конкретной колонки установлен признак NOT NULL (запрет на пустые значения), но программный код платформы при выполнении команды Записать() не передает данные для этого поля. В итоге SQL-сервер отвергает транзакцию.

Проанализируем, почему это случается именно после обновления. В релизах линейки 3.0.60–3.0.64 разработчики активно внедряли изменения в подсистемы учета по подразделениям и раздельного учета НДС. Поле Fld33747 в таблице _Document181 (которая соответствует документу Поступление на расчетный счет) чаще всего отвечает за реквизит ПодразделениеОрганизации или новые технические разрезы учета. Если процесс обновления метаданных завершился с микро-сбоем, структура таблицы в SQL может не соответствовать логике объектов в конфигурации.

Шаг 1: Диагностика и сопоставление полей

Прежде чем приступать к лечению, нам необходимо точно определить, за какой реквизит отвечает проблемное поле. Для этого мы можем воспользоваться встроенными средствами или SQL-запросом. Разберем способ через консоль запросов в 1С или поиск в таблице _ConfigTable.

Выясним внутреннее имя поля, выполнив следующий алгоритм:

1. Откроем Конфигуратор.
2. Перейдем в меню "Администрирование" — "Выгрузить информационную базу" (всегда делайте бэкап перед манипуляциями!).
3. Воспользуемся обработкой "Просмотр структуры базы данных" или программным кодом для получения имени таблицы:
   Скопировать код

   
   Сообщить(ПолучитьСтруктуруХраненияБазыДанных().Найти("Документ.ПоступлениеНаРасчетныйСчет", "ИмяМетаданных").ИмяТаблицыХранения);
   

Если мы работаем напрямую в SQL Server Management Studio (SSMS), мы увидим, что поле Fld33747 действительно помечено как NOT NULL, но при этом в него не записывается значение по умолчанию.

Шаг 2: Обновление технологической платформы

Проанализируем используемую платформу. Ошибка часто проявляется на версиях 8.3.10.2580 и ниже. Данные ветки платформы имеют известные проблемы с механизмом реструктуризации таблиц при обновлении современных конфигураций. Мы рекомендуем обновить платформу до версии 8.3.12, а лучше до актуальных стабильных релизов (например, ветки 8.3.18 или 8.3.22).

Новые версии платформы более корректно обрабатывают добавление новых реквизитов в существующие таблицы, автоматически проставляя значения по умолчанию (например, "0" для чисел или пустую ссылку для справочников) там, где SQL ожидает данные.

Шаг 3: Принудительная реструктуризация таблицы

Если стандартное Тестирование и исправление (ТиИ) вылетает с ошибкой или не приносит результата, нам нужно заставить систему перестроить таблицу _Document181 "с нуля". Рассмотрим, как это сделать без потери данных:

1. Зайдем в Конфигуратор.
2. Найдем документ ПоступлениеНаРасчетныйСчет.
3. Найдем любой строковый реквизит (например, Комментарий) и временно изменим его длину (например, с 0 на 100 или со 150 на 151).
4. Нажмем "Обновить конфигурацию базы данных" (F7).

В этот момент 1С инициирует процесс реструктуризации: создаст временную таблицу, перенесет туда данные, удалит старую таблицу, создаст новую с корректной структурой и вернет данные обратно. Это часто исправляет "фантомные" ограничения NOT NULL, которые мешают работе.

Шаг 4: Манипуляции на уровне SQL (для опытных администраторов)

Если конфигуратор не справляется, а работать нужно срочно, разберем метод прямого исправления в СУБД. Внимание: этот метод является крайней мерой.

Посмотрим на последовательность действий в SQL Server Management Studio:

1. Найдем нашу таблицу dbo._Document181.
2. Развернем список колонок и найдем _Fld33747.
3. Щелкнем правой кнопкой мыши — "Design" (Проектировщик).
4. Найдем строку с этим полем и установим галочку в колонке "Allow Nulls" (Разрешить NULL).
5. Сохраним изменения в таблице.

После этого документ Поступление на расчетный счет начнет записываться. После успешной записи рекомендуется запустить полное Тестирование и исправление в 1С с включенными галочками "Реиндексация таблиц" и "Реструктуризация таблиц", чтобы платформа привела схему в соответствие со своими эталонами.

Шаг 5: Очистка серверного кэша и работа с расширениями

Выясним, не мешают ли нам дополнительные факторы. Иногда расширения конфигурации могут "блокировать" правильное обновление структуры метаданных. Попробуем выполнить следующие действия:

1. Отключим все расширения, связанные с банковскими документами.
2. Очистим кэш сервера 1С. Для этого необходимо остановить службу 1C:Enterprise 8.3 Server Agent и удалить содержимое папок snccntx и config в каталоге профиля пользователя, под которым запускается служба (обычно в C:\Program Files\1cv8\srvinfo).
3. Перезапустим службу.

Шаг 6: Проверка настроек учета по подразделениям

Проанализируем настройки самой программы. Часто ошибка записи в поле подразделения возникает, когда в базе включен учет по подразделениям (меню "Администрирование" — "Параметры учета"), но в самом документе это поле скрыто или не заполнено. Попробуйте временно выключить и снова включить настройку "Учет по подразделениям". Это заставит систему пересчитать видимость и обязательность заполнения соответствующих полей в формах и модулях объекта.

Подводя итог, можно сказать, что проблема носит чисто технический характер и связана с "недообновлением" схемы БД. Сочетание обновления платформы и принудительной реструктуризации через изменение длины реквизита является самым безопасным и эффективным решением данной задачи.