"Регистрация в налоговом органе" не может быть пустым: почему не проводится начисление зарплаты
Иван Недомолков · Dərc edilib:
Документ “Начисление зарплаты и взносов” не проводится, и 1С пишет:
Запись не верна! Значение поля "Регистрация в налоговом органе" не может быть пустым!
(Регистр накопления: Сведения о доходах физических лиц; Номер строки: 1)
Короткий ответ для тех, кто пришёл из поиска. Проведение берёт регистрацию из регистра сведений “История регистраций в налоговом органе” на конец месяца начисления, и берёт её по подразделению строки начисления. Если история этого подразделения начинается позже месяца, за который считается зарплата, значение пустое. Карточку организации проведение для этого поля не читает, поэтому заполненная карточка ошибку не снимает.
Ниже порядок проверки на пять минут, два способа исправления (руками и обработкой) и то, на чём спотыкаются программисты, когда пишут исправление сами. Всё проверено на 1С:ERP для Казахстана с зарплатной подсистемой, платформа 8.3.27.
Кому что читать
| Вы | Что нужно | Раздел |
|---|---|---|
| Бухгалтер, документ не проводится | понять, где смотреть, и кому передать | ”Проверка за пять минут”, “Исправление руками” |
| Программист на сопровождении | механизм, код, ловушки | ”Три регистра”, “Если пишете исправление сами” |
| Руководитель учёта | риски перед запуском в рабочей базе | ”Когда исправление не подходит” |
Проверка за пять минут
Регистры открываются через “Все функции”.
| Шаг | Где смотреть | Что увидите при этой болезни | Вывод |
|---|---|---|---|
| 1 | Текст ошибки | регистр “Сведения о доходах физических лиц” | если там другой регистр, механизм может быть другим, дальше по этой статье не идите |
| 2 | Карточка организации, поле регистрации | заполнено, код налогового органа стоит | нормально, и именно это сбивает со следа |
| 3 | Документ, месяц начисления и подразделения в строках | ранний месяц: у нас один из первых месяцев после приёма сотрудников | запомните месяц и список подразделений |
| 4 | Регистр сведений “История регистраций в налоговом органе”, отбор по структурной единице | у подразделений из шага 3 самая ранняя запись позже месяца начисления | причина найдена |
| 5 | Регистр “История регистраций в налоговом органе вторичный” | интервалы начинаются с той же поздней даты | подтверждение, после исправления здесь должен появиться ранний интервал |
Главное в шаге 4: смотреть надо подразделения из строк начисления. У организации история может быть в полном порядке, а срез по подразделению всё равно пустой.
Почему в карточке заполнено, а в движениях пусто
Карточка хранит текущую регистрацию, без даты начала. История хранит, с какого дня какая структурная единица стоит на учёте в каком налоговом органе. Проведение спрашивает историю: “какая регистрация была у этого подразделения на последний день месяца начисления”. Если первая запись истории датирована позже, ответ пустой.
Движения по доходам собирает процедура общего модуля УчетНалоговВзносовОтчислений.СформироватьСведенияОДоходахПоНачислениям. Модуль в выгрузке весит 3,1 МБ, так что читать его стоит по имени процедуры. Регистрацию процедура получает таким соединением (фрагмент типового запроса, лишние поля убраны):
// Параметр КонецМесяцаНачисления = КонецМесяца(МесяцНачисления)
ВЫБРАТЬ
Начисления.Подразделение КАК Подразделение,
ИсторияРегистрацийВНалоговомОрганеСрезПоследних.РегистрацияВНалоговомОргане КАК РегистрацияВНалоговомОргане
ИЗ
ВТНачисления КАК Начисления
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ИсторияРегистрацийВНалоговомОргане.СрезПоследних(
&КонецМесяцаНачисления,
СтруктурнаяЕдиница В
(ВЫБРАТЬ
Начисления.Подразделение
ИЗ
ВТНачисления КАК Начисления)) КАК ИсторияРегистрацийВНалоговомОрганеСрезПоследних
ПО Начисления.Подразделение = ИсторияРегистрацийВНалоговомОрганеСрезПоследних.СтруктурнаяЕдиница
Две детали решают всё. Организации нет ни в условии среза, ни в условии соединения, только подразделение. И соединение левое: строка без пары в истории остаётся и уходит в движения с пустой ссылкой. Дальше срабатывает запрет пустого значения у измерения регистра накопления, и платформа останавливает запись на первой же строке. Отсюда “Номер строки: 1” в тексте ошибки.
Три регистра, которые участвуют
| Регистр | Вид | Устройство | Роль в ошибке |
|---|---|---|---|
| Сведения о доходах физических лиц | накопления | 7 измерений, запрет пустых у четырёх: Организация, ФизическоеЛицо, ПериодРегистрации, РегистрацияВНалоговомОргане; у Подразделения запрета нет | отказывает в записи движений |
| История регистраций в налоговом органе | сведений, периодичность “день” | одно измерение СтруктурнаяЕдиница (организация, территория или подразделение), один ресурс РегистрацияВНалоговомОргане | источник значения, срез на конец месяца |
| История регистраций в налоговом органе вторичный | сведений, непериодический | СтруктурнаяЕдиница, ДатаНачала, ДатаОкончания | та же история интервалами, пересчитывается сама при записи основного |
Документ в этой цепочке только носитель. На его месте мог оказаться любой документ, который пишет в “Сведения о доходах физических лиц”.
Какую дату ставить в начало истории
Первое желание: дата регистрации организации. В нашем случае поле “Дата регистрации” было пустым у обеих организаций базы, и гадать не пришлось: мы посмотрели, что делает сама конфигурация. Начальную запись истории она пишет на дату отсчёта периодических сведений, которую возвращает ЗарплатаКадрыКлиентСервер.ДатаОтсчетаПериодическихСведенийСПериодомМесяц(). В типовой это 01.01.1900. Такая запись покрывает любой месяц начисления и не спорит с записями, которые бухгалтер завёл позже.
Регистрацию для новой записи берём из самой ранней существующей записи истории. Если истории у единицы нет совсем, берём из карточки.
Исправление руками
Подходит, когда организация одна и подразделений два-три.
- Регистр “История регистраций в налоговом органе”: у организации найти самую раннюю запись. Если она позже первого месяца начислений, добавить запись с периодом 01.01.1900, той же структурной единицей и той же регистрацией. Начинаем с организации, потому что с неё конфигурация разносит историю на необособленные подразделения.
- Повторить для каждого подразделения из строк начислений. Необособленному ставится регистрация организации. Обособленному своя: если истории у него нет, взять из карточки подразделения, поле “Регистрация в налоговом органе”.
- Открыть вторичный регистр и проверить, что у каждой единицы появился интервал с 01.01.1900.
- Перепровести упавший документ.
Честная оговорка: ручной путь на нашей базе не прогонялся, прогонялась обработка. Запись из формы регистра идёт без режима загрузки, поэтому по коду конфигурации вторичный регистр должен пересчитаться. Если в шаге 3 раннего интервала нет, запись прошла мимо бизнес-логики, и разбираться надо уже с вашей конфигурацией.
Исправление обработкой
Когда организаций и подразделений больше, ручная сверка превращается в работу по списку. Для этого мы собрали обработку исправления истории регистрации с одной кнопкой. Что она делает по шагам:
| Шаг | Действие |
|---|---|
| 1 | берёт организации и обособленные подразделения без пометки удаления |
| 2 | для каждой находит первую запись истории; если её нет или она позже 01.01.1900, добавляет запись на эту дату |
| 3 | единицы без регистрации и в истории, и в карточке пропускает с записью в протокол |
| 4 | разносит историю головной единицы на необособленные подразделения штатной процедурой ОбновитьПодчиненныеСтруктурныеЕдиницы |
| 5 | печатает итоговую историю и просит перепровести документ |
Всё идёт одной транзакцией. Повторный запуск ничего не добавляет: в протоколе будет “история уже начинается с 01.01.1900, запись не нужна”. Документы обработка не проводит и не меняет. Сама обработка лежит на Инфостарте: карточка “Исправление истории регистрации в налоговом органе”, 5 SM.
Если пишете исправление сами
Здесь две ловушки, на обе легко наступить.
Режим загрузки выключает пересчёт вторичного регистра. Вторичный регистр пересчитывает модуль набора записей основного регистра, и первой строкой там стоит выход:
Процедура ПриЗаписи(Отказ, Замещение)
Если ЗарплатаКадры.ОтключитьБизнесЛогикуПриЗаписи(ЭтотОбъект) Тогда
Возврат;
КонецЕсли;
СтруктурнаяЕдиница = Неопределено;
Если Отбор.СтруктурнаяЕдиница.Использование Тогда
СтруктурнаяЕдиница = Новый Массив;
СтруктурнаяЕдиница.Добавить(Отбор.СтруктурнаяЕдиница.Значение);
КонецЕсли;
УстановитьПривилегированныйРежим(Истина);
РегистрыСведений.ИсторияРегистрацийВНалоговомОрганеВторичный.ЗаполнитьВторичныеДанные(СтруктурнаяЕдиница);
КонецПроцедуры
В модуле менеджера регистра есть штатная ЗаполнитьИсториюРегистрацийВНалоговомОрганеНаДатуОтсчетаПериодическихСведенийСПериодомМесяц, и выглядит она как готовое решение. Но она пишет каждый набор с ОбменДанными.Загрузка = Истина, срабатывает Возврат, и вторичный регистр остаётся со старыми интервалами. Соседняя ОбновитьПодчиненныеСтруктурныеЕдиницы включает загрузку, только если передать ей РежимОбновления = Истина, по умолчанию она пишет обычным порядком. Поэтому первую мы повторили своим кодом без загрузки, вторую вызываем как есть.
Набор без отбора заменит весь регистр. Набор записей регистра сведений при записи замещает всё, что попадает под отбор. Отбор по периоду и структурной единице обязателен, и по нему же ПриЗаписи понимает, для какой единицы пересчитывать вторичный регистр:
Процедура ДобавитьЗаписьИстории(СтруктурнаяЕдиница, Период, Регистрация)
Набор = РегистрыСведений.ИсторияРегистрацийВНалоговомОргане.СоздатьНаборЗаписей();
Набор.Отбор.Период.Установить(Период);
Набор.Отбор.СтруктурнаяЕдиница.Установить(СтруктурнаяЕдиница);
ЗаписьИстории = Набор.Добавить();
ЗаписьИстории.Период = Период;
ЗаписьИстории.СтруктурнаяЕдиница = СтруктурнаяЕдиница;
ЗаписьИстории.РегистрацияВНалоговомОргане = Регистрация;
// Как у штатных процедур заполнения истории: запись на дату отсчета
// не должна упираться в дату запрета изменения.
Набор.ДополнительныеСвойства.Вставить("ОтключитьПроверкуДатыЗапретаИзменения", Истина);
// Без режима загрузки: набор сам пересчитает вторичный регистр.
Набор.Записать();
КонецПроцедуры
Мелочь из того же захода: проверочный запрос с сортировкой по псевдониму поля, посчитанного через ПРЕДСТАВЛЕНИЕ(), падает с “Операция не разрешена в предложении “УПОРЯДОЧИТЬ"". Сортировать надо по самому полю.
Случай, на котором это разбиралось
База ERP для Казахстана. В истории регистраций лежали две записи, организация и её основное подразделение, обе с 1 февраля. Сотрудников принимали на 16 месяцев раньше, и упал документ за один из тех месяцев. Срезы мы считали на конец каждого месяца, начиная с месяца перед первым приёмом.
| Показатель | До | После |
|---|---|---|
| Записей в основной истории | 2, обе с 1 февраля | 4: у организации и подразделения по записи с 01.01.1900 и с 1 февраля |
| Интервалов во вторичном регистре | 2, с 1 февраля по 31.12.3999 | 4: с 01.01.1900 по 31 января и с 1 февраля по 31.12.3999 |
| Пустых срезов на конец месяца | 17 из 25 | 0 из 25 |
| Перепроведение упавшего начисления | ошибка | проходит, 41 с (транзакция с откатом) |
Запись организации на 01.01.1900 добавила обработка, подразделению такая же пришла через разнос истории головной единицы. При трёх необособленных подразделениях каждое получит копию истории организации целиком. Интервалы во вторичном регистре у нас резались на каждой записи основного, даже при одинаковой регистрации в соседних записях.
41 секунда здесь время проведения самого документа. Вызов обработки в прогоне с откатом занял 664 мс. При приёмке 26.09 мы отдельно воспроизвели болезнь в транзакции: убрали ранние записи истории, получили 2 пустых среза из 2 и ту же ошибку проведения, после обработки пустых срезов стало 0, документ провёлся, обработка отработала за 178 мс, после отката база совпала со снимком до прогона.
Когда исправление не подходит
| Ситуация | Что будет | Что делать |
|---|---|---|
| Организация меняла налоговый орган, в истории только нынешний | история продлится назад нынешним органом, так же поступает штатное обновление конфигурации | после запуска посмотреть итоговую историю в протоколе и добавить промежуточную запись руками |
| Ошибка про пустую регистрацию идёт из другого регистра | обработка ничего не сломает, но и не вылечит | искать, откуда проведение этого регистра берёт значение |
| Закрытые периоды | запись на 01.01.1900 делается в обход даты запрета изменения; проведённые документы не меняются, история за эти периоды становится другой | если это важно для отчётности, первый запуск на копии |
| ЗУП для Казахстана, Комплексная автоматизация | регистры и процедуры, скорее всего, называются так же, но код мы не сверяли и прогона не было | первый запуск на копии |
Копию под такую проверку удобнее держать постоянно, а не поднимать в день аварии: как это устроено, мы описывали в статье про тестовую базу, которая отстала от рабочей. А если ошибка проведения вылезла сразу после обновления релиза, посмотрите заодно, что ещё меняется в зарплате Казахстана в 2026 году: разбор про отставание релиза ЗУП для Казахстана.
Откуда у подразделений поздняя история
В нашем случае история начиналась на 16 месяцев позже первого приёма. Почему именно с 1 февраля, мы не разбирали: для лечения это не нужно. Если у вас та же ошибка, нам интересно, откуда поздняя дата у вас: ручной ввод, перенос зарплаты из другой базы или что-то третье. Напишите, и если нужна помощь с разбором, это входит в сопровождение типовых конфигураций 1С для Казахстана.