«Поле „Подразделение“ должно быть пустым»: считаем долю прибыли по обособленным подразделениям в 1С:Бухгалтерии ПРОФ

17 сентября 2026 года у нас тут был разбор про то, что механизм расчета доли прибыли по обособленным подразделениям в ПРОФ есть, но стоит пустой. Статью прочитали, в личку пришли вопросы вида «ладно, а руками-то как». Вот про руками.

Заодно придется исправить два места, где наврал в прошлый раз, и три, где наврал прямо в этой статье, пока ее писал: ошибся в предсказании про тихую потерю данных, оставил в собственном запросе ровно ту ошибку, о которой пишу, и неверно описал блок для декларации в справке-расчете. Начнем с прошлых, чтобы никто не унес из того текста неправду.

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

 

Если читать некогда

Имущество берется из регистра МестонахождениеОСБухгалтерскийУчет, налоговый орган подразделения — из ИсторияРегистрацийВНалоговомОргане; одноименный реквизит справочника в моей базе ПРОФ 3.0.191.41 тремя пробами записать не удалось. Два подвоха: счет 01.К внутри иерархии 01 и строки 050 и 070 — расчет их только обнуляет, а кто заполняет их в отчете, я не проверял.

Результат, ради которого все это затевалось: расчет сошелся с типовым расчетом КОРП в ноль по восьми сценариям, а снимок базы до и после прогона под активной датой запрета изменения показал ноль расхождений на 4 075 контролируемых величинах.

 

Поправка первая: флажок обособленности в ПРОФ есть

В прошлый раз написал, что в ПРОФ у подразделения нет признака «Обособленное подразделение», а значит, связку «подразделение — КПП» придется держать у себя в блокноте. Это неправда.

Идем в «Зарплата и кадры» → «Настройки зарплаты» → «Расчет зарплаты» и находим там флажок «Расчет зарплаты по обособленным подразделениям». За ним стоит константа РасчетЗарплатыПоПодразделениямДляНебольшихОрганизаций. После включения в карточке подразделения появляется группа с флажком обособленности, а вместе с ней КПП, регистрация в налоговом органе и ОКТМО:

УчетПоПодразделениям = БухгалтерскийУчетПереопределяемый.ВестиУчетПоПодразделениям();
РасчетЗарплатыПоПодразделениям = БухгалтерскийУчетПереопределяемый.РасчетЗарплатыПоПодразделениямДляНебольшихОрганизаций();

Элементы.ГруппаОбособленноеПодразделение.Видимость = УчетПоПодразделениям;
Элементы.ГруппаОбособленноеПодразделениеДляНебольшихОрганизаций.Видимость = РасчетЗарплатыПоПодразделениям
	И НЕ УчетПоПодразделениям;
...
Элементы.ГруппаРегистрацияВНалоговомОрганеКодПоОКТМО.Видимость =
	Объект.ОбособленноеПодразделение И Не УчетПоПодразделениям;

Ответ — в двух последних присваиваниях. Не УчетПоПодразделениям — это ветка интерфейса для случая, когда функция вернула Ложь. В ПРОФ она Ложь и возвращает, почему — разберем ниже, в разделе про одну строку присваивания. Ветку кто-то написал осознанно, а вот зачем именно, вопрос не к нам.

Сама 1С комментирует это в подсказке к флажку, и лучше нее не скажешь:

Поддерживается отчетность по НДФЛ для организаций с численностью до 60 человек. Полная поддержка обособленных подразделений реализована в 1С:Бухгалтерии КОРП.

Про 60 человек любопытно вот что: проверки на это число в коде найти не удалось. Искал по всем общим модулям сочетания «60» рядом со словами «численность», «работник», «сотрудник» — пусто. Похоже, это условие поддержки, а не программное ограничение. Утверждать не берусь, мог смотреть не там.

Реквизиты проверил записью в живой базе: ОбособленноеПодразделение = Истина, КПП = "770101001". Читал обратно не из своего же объекта, а из базы, через ОбщегоНазначения.ЗначениеРеквизитаОбъекта — это важно, ниже станет понятно почему. Оба значения на месте.

Значит, про КПП в прошлый раз был неправ: место для него есть. А вот с третьим реквизитом из той же группы вышло интереснее, и блокнот, похоже, все-таки понадобится.

 

Флажок есть, КПП есть, а налоговая регистрация не держится

Связка «подразделение — КПП» нужна не сама по себе. В Приложении 5 подразделение опознается по налоговому органу, и в карточке для этого есть реквизит РегистрацияВНалоговомОргане. Флажок обособленности включен, поле видно, значение выбирается из справочника. Казалось бы, все.

25 сентября маленькая диагностическая обработка подставила подразделению другую регистрацию и записала. Три пробы на той же базе ПРОФ:

 

Проба	Что делал	В объекте после записи	В базе
Подразделение не обособленное	присвоил ФНС 5099	ФНС 7799	ФНС 7799
Флажок и регистрация одной записью	присвоил ФНС 5099	ФНС 5099	ФНС 7799
Сначала флажок, потом регистрация	присвоил ФНС 5099	ФНС 5099	ФНС 7799

 

Исходное значение — ФНС 7799, это регистрация головной организации. Ни одна проба не прошла, и ни одна не выдала ошибки.

Обратите внимание на разницу между двумя последними колонками. В первой пробе значение подменяется прямо в объекте: присвоил 5099, после Записать() читаю свой же объект — там уже 7799. Во второй и третьей объект остается с моим значением, а база его не принимает. Два разных механизма, и второй противнее: код, который проверяет себя чтением записанного объекта, ничего не заметит.

Первый механизм лежит в подписке УстановитьЗначенияРеквизитовПодразделенияБазовая, она зовет ЗарплатаКадрыСобытия.ПодразделенияОрганизацийПередЗаписью:

Если Источник.ЭтоНовый() Или Не Источник.ОбособленноеПодразделение Тогда

	Если ЗначениеЗаполнено(Источник.РегистрацияВНалоговомОргане)
		И Источник.ОбособленноеПодразделение Тогда
		СписокПолей = "РайонныйКоэффициент,РайонныйКоэффициентРФ";
	Иначе
		СписокПолей = "РегистрацияВНалоговомОргане,РайонныйКоэффициент,РайонныйКоэффициентРФ";
	КонецЕсли;
	...
	Источник.РегистрацияВНалоговомОргане = РеквизитыИсточникаСведений.РегистрацияВНалоговомОргане;

Нет флажка обособленности — регистрация подтягивается от владельца или родителя. Логично: подразделение, которое не обособлено, стоит на учете там же, где организация.

Второй механизм — при записи, через ЗарплатаКадры.УстановитьРеквизитыВПодчиненныхПодразделениях. Там среди прочего есть строка:

РегистрыСведений.ИсторияРегистрацийВНалоговомОргане.ОбновитьПодчиненныеСтруктурныеЕдиницы(
	ПодчиненныеСтруктурныеЕдиницы, ИсточникДанных = Неопределено);

Реквизит справочника приводится к регистру. А в регистре у моего подразделения лежала одна запись:

[31.12.1899: ФНС 7799 КПП 779901001]

Дата 31.12.1899 — это «пустая дата» платформы, а регистрация там головной организации. К ней реквизит и вернулся ))

Источник истины — регистр, а не реквизит справочника. Проверено на БП ПРОФ 3.0.191.41, тремя пробами; остальное здесь — чтение кода. Это видно и по тому, как типовая читает регистрацию подразделения: ЗарплатаКадры.РегистрацияВНалоговомОрганеПодразделения начинается с ИсторияРегистрацийВНалоговомОргане.ПолучитьПоследнее, и только если там пусто, идет смотреть реквизиты. В самом расчете доли КОРП обращается туда же: в модуле НалоговыйУчетОбособленныхПодразделений регистр ИсторияРегистрацийВНалоговомОргане встречается и срезом последних, и прямым соединением. Пока история показывает регистрацию головной организации, аккуратно заполненный справочник не значит ничего.

Пробовал и четвертое, сверх таблицы: реквизит записался только через ОбменДанными.Загрузка = Истина, то есть с отключенной бизнес-логикой записи. Других способов не искал: для разовой починки данных этот годится, а для продукта правильный путь все равно лежит через сам регистр.

Почему это стоит отдельного раздела: механика ровно та же, вокруг которой построена остальная статья. Поле на месте, форма его показывает, значение принимается, исключения нет — и результата тоже нет.

Одна оговорка, чтобы дальше не путаться. Ниже будет раздел, где платформа на записи как раз не молчит и честно бросает исключение. Это другой объект: там запись движений в регистр бухгалтерии, контроль признаков учета, платформенная проверка. Здесь — запись реквизита справочника, где вместо контроля работает прикладная логика типовой, и она предпочитает молчать.

 

Поправка вторая: документ «Ввод начальных остатков» регистр все-таки пишет

Второй промах — объяснение, почему в моей базе нечего читать из регистра МестонахождениеОСБухгалтерскийУчет. Написал, что документ ввода начальных остатков его не трогает. Оказалось, трогает. Регистраторов у этого регистра восемь, если верить составу движений в метаданных:

ВводНачальныхОстатков, ВозвратОСОтАрендатора, ОперацияБух, ПередачаОСВАренду,
ПеремещениеОС, ПоступлениеВАренду, ПоступлениеТоваровУслуг, ПринятиеКУчетуОС

И в модуле менеджера документа прямым текстом:

НоваяСтрока.Организация      = СтрокаОС.Организация;
НоваяСтрока.ОсновноеСредство = СтрокаОС.ОсновноеСредство;
НоваяСтрока.МОЛ              = СтрокаОС.МОЛРегл;
НоваяСтрока.Местонахождение  = СтрокаОС.ПодразделениеОрганизации;

Здесь ПодразделениеОрганизации — реквизит шапки самого документа «Ввод начальных остатков». В состав функциональной опции ВестиУчетПоПодразделениям он не входит: там лежат два других одноименных реквизита — у обработки-помощника «Ввод начальных остатков» и у документа «Принятие к учету ОС». Разные объекты с одинаковым именем, и на этом легко запутаться (я и запутался, спасибо въедливому читателю черновика).

Значит, на строки регистра рассчитывать можно, а вот с чем они лягут — зависит от того, заполнили подразделение в шапке или нет. Заодно уточню формулировку: регистр в демобазе не пустой. В нем две записи, просто у обеих пустое местонахождение, и обе от другого документа — «Принятие к учету ОС КП00-000001 от 11.01.2016». Для расчета это все равно что пусто, но чинится по-разному.

«Документ не пишет» означает перепроведение всего года. «Поле не заполнили» означает ручное заполнение подразделений: на моих двух объектах это минуты, на сотнях будет иначе.

 

Доступность механизма держится на одной строке присваивания

В профильном модуле расчета нет: НалоговыйУчетОбособленныхПодразделений в ПРОФ — это 130 строк, 32 процедуры, и ни одной с непустым телом не нашел, против 4 255 строк в КОРП. Искать расчет где-то еще по конфигурации не стал. А доступность держится вот на чем. Переопределяемый модуль ВариантыПриложенийПереопределяемый, ПРОФ, целиком, 206 байт:

Процедура ОпределитьДоступностьФункциональностиКОРП(ФункциональностьДоступна) Экспорт

КонецПроцедуры

Он же в КОРП — там, кроме этой строки, еще шапка с комментариями:

Процедура ОпределитьДоступностьФункциональностиКОРП(ФункциональностьДоступна) Экспорт

	ФункциональностьДоступна = Истина;

КонецПроцедуры

Дальше по цепочке, разобранной в прошлый раз: ЭтоВерсияКОРП() → РазрешенУчетОбособленныхПодразделений() → ВестиУчетПоПодразделениям() → функциональная опция → видимость доброй половины интерфейса.

Мысль «да там же все есть, только выключено» напрашивается сама. Она верна ровно наполовину: интерфейс, перечисление показателей и место под выбор в регистре настроек есть, а расчета в профильном модуле нет, как нет и регистра, куда КОРП кладет его результат. Дальше начинается рассуждение, а не наблюдение: расширения не собирал и не применял. По коду выходит, что подменить строку нетрудно и что получится интерфейс над пустотой — поля появятся, а заполнять Приложение 5 будет нечем. Так ли это на самом деле, не знаю. Плюс лицензионное соглашение, которое пересказывать не стану.

 

Почему запрос из КОРП переносится дословно и врет

В КОРП стоимость амортизируемого имущества собирается так (сокращенно):

ВЫБРАТЬ
	ХозрасчетныйОстатки.Организация КАК Организация,
	ХозрасчетныйОстатки.Подразделение КАК Подразделение,
	ЕСТЬNULL(ХозрасчетныйОстатки.СуммаНУОстаток, 0) КАК СтоимостьОССледующегоМесяца
ИЗ
	РегистрБухгалтерии.Хозрасчетный.Остатки(
		&НачалоСледующегоМесяца,
		Счет В (&СчетаАмортизируемогоИмущества),
		ЗНАЧЕНИЕ(ПланВидовХарактеристик.ВидыСубконтоХозрасчетные.ОсновныеСредства),
		Организация В (&СписокОрганизаций)) КАК ХозрасчетныйОстатки

Подразделение берется прямо из измерения регистра бухгалтерии. Измерение Подразделение есть в обеих редакциях, так что текст запроса переносится дословно и в моем прогоне отработал без ошибок. Параметр &СчетаАмортизируемогоИмущества при этом готовится отдельно, в коде, и что в него класть — разговор ниже.

Внутри это устроено так. У измерения Подразделение регистра «Хозрасчетный» стоит признак учета:

Измерение	Признак учета
Организация	—
Валюта	Валютный
Подразделение	УчетПоПодразделениям

Признак — это свойство счета. Если у счета он выключен, платформа не дает записать движение с заполненным измерением — это видно в прогоне ниже. И вот раскладка по поставке 3.0.206.19, две выгрузки одного релиза, 490 счетов:

	ПРОФ	КОРП
Счетов с признаком «учет по подразделениям»	30	324
01, 01.01, 01.09, 02, 02.01, 03, 03.01, 08	нет	да
20, 20.01, 23, 25, 26, 28, 29, 97	да	да
40, 44, 44.01, 44.02	нет	да
01.11, 02.11 (групповые объекты ОС)	да	да

 

Слово «по поставке» здесь важное: в моей живой базе часть этих значений оказалась другой, и ниже будет раздел про то, почему.

Последняя строка — забавный островок: у групповых объектов основных средств признак в ПРОФ проставлен. Откуда он там взялся, выяснять не стал; за сам групповой учет отвечает отдельная опция ВедетсяУчетГрупповыхОС, но связывать одно с другим не берусь. Если у вас ОС заведены групповыми, подразделение по 01.11 может оказаться заполненным. Может и не оказаться: как видно из следующего раздела, признака у одного счета мало, нужен и у корреспондирующего. Сам этого случая не проверял.

 

Что будет, если положить подразделение в проводку руками

Здесь ждал тихой потери данных и ошибся в третий раз подряд )) 24 сентября запустил в той же базе ПРОФ диагностическую обработку, теперь она создает документ «Операция», кладет в проводку подразделение и пытается записать. База БП 3.0.191.41, все изменения откатил в том же прогоне. Три пробы:

Проводка	Признак у счетов	Что вышло
Дт 26 Кт 60.01	26 — да, 60.01 — нет	исключение
Дт 44.01 Кт 60.01	44.01 — да, 60.01 — нет	исключение
Дт 01.01 Кт 08.04.2	нет у обоих	исключение

 

(Да, у 44.01 в этой базе признак стоит, хотя в таблице поставки его нет. Почему так — тремя разделами ниже, в «Почему моя таблица поставки не совпала с живой базой». У 26 он стоит и там и там.)

Текст ошибки везде один:

Запись не верна! Поле "Подразделение" должно быть пустым!
(Регистр бухгалтерии: Журнал проводок (бухгалтерский и налоговый учет); Номер строки: 1)

То есть на записи платформа не молчит. И хватает одной стороны: в первых двух пробах признак у дебетового счета был, а запись все равно не прошла из-за кредитового. Зеркальный случай, признак у кредита и нет у дебета, не ставил.

Сами типовые документы до этого не доводят: в модуле набора записей регистра «Хозрасчетный» перед заполнением смотрят СвойстваСчетаДт.УчетПоПодразделениям и СвойстваСчетаКт.УчетПоПодразделениям, и без признака значение не кладут. Это чтение модуля: прогона, в котором значение обнулил бы сам модуль, у меня нет — моя проба на «Операции» дошла до исключения платформы, а не до тихого обнуления.

 

А на чтении платформа молчит

Берем тот самый запрос из КОРП, подставляем в &СчетаАмортизируемогоИмущества иерархию счетов 01, 02 и 03 (запомните этот момент, он мне еще аукнется), дописываем группировку по подразделению и счетчик объектов. Получаем одну строку:

[пусто: 30 085 734,46 руб, объектов 2]

Тридцать миллионов на пустом подразделении, ноль предупреждений, ноль исключений. Красивая аккуратная строка, которую хочется скопировать в Excel и пойти дальше. Ошибка сидит в чтении: платформа отдает результат, который выглядит успешным, и заметить подвох можно только по слову «пусто» в первой колонке.

А вы бы на такой строке остановились? У меня она провисела минут двадцать.

 

«А если просто поставить галочку на счете 01?»

Этот вопрос задали двое из троих, кому рассказывал про первую статью, так что пришлось проверить. Ставится. Признак учета — это данные, а не метаданные, и он редактируется:

СчетОбъект = ПланыСчетов.Хозрасчетный.НайтиПоКоду("01.01").ПолучитьОбъект();
СчетОбъект.УчетПоПодразделениям = Истина;
СчетОбъект.Записать();

Прошло. Дальше включаем признак обоим счетам пробы — и 01.01, и 08.04.2, — повторяем ту же проводку, и она записывается: подразделение легло в регистр и прочиталось обратно и по дебету, и по кредиту. Механизм работает. Признаки потом вернул на место, пробные документы «Операция» удалил там же в прогоне.

И все равно так делать не надо.

Во-первых, остаточная стоимость нужна на первое число каждого месяца с начала года, то есть по уже записанным движениям. Проверял только запись новой проводки после включения признака; что старые движения сами не переписываются, я предполагаю, а не знаю. Если предположение верное, понадобится перепроведение документов ОС за год — ради одной цифры в квартал сделка сомнительная.

Во-вторых, и это главное, заполнять новую колонку, похоже, будет некому. Дальше рассуждение из состава функциональной опции, прогоном закрыта только его половина. Реквизит ПодразделениеОрганизации документа «Принятие к учету ОС» входит в состав функциональной опции ВестиУчетПоПодразделениям — а раз опция в ПРОФ выключена, платформа этот реквизит в форме не показывает. Вывод этот из состава опции, а не из наблюдения: проводки типовых принятий к учету в моей базе пустые,

[01.01 -> пусто] [01.03 -> пусто] [01.К -> пусто]

но записаны они при выключенном признаке, так что доказывают ровно половину. Опыт «включить признак и провести типовое принятие к учету» не ставил.

Если рассуждение верно, то после включения признака колонка появится, а документы будут писать в нее пустоту — то есть получится поле, которое выглядит заполняемым и не заполняется. Если рассуждение неверно, буду только рад: напишите, какой документ ПРОФ все-таки кладет подразделение в проводку по 01, это меняет дело.

 

Почему моя таблица поставки не совпала с живой базой

В таблице поставки у счетов 44, 44.01, 44.02 признака нет, а в базе, на которой шли все пробы, он есть. Сначала решил, что дело в релизах: выгрузки сравнивал на 3.0.206.19, а живая база 3.0.191.41, между ними пятнадцать релизов. Версия не прошла: открыл выгрузки 3.0.206.19 и 3.0.191.41 и сверил признак у каждого счета — по 30 счетов с признаком в обеих, ни одного расхождения на 488 общих счетах. Значит, дело не в релизе.

Признак у затратных счетов управляется штатно — настройкой «Учет затрат ведется: по каждому подразделению» (План счетов → Настройка плана счетов). За ней константа ВестиУчетЗатратПоПодразделениям, а список счетов, которые она переключает, зашит в БухгалтерскийУчетПереопределяемый.СчетаУчетаЗатратПоПодразделениям(): 20, 20.01, 20.04, 23, 23.01, 23.05, 25, 26, 28, 29, 40, 44, 44.01, 44.02, 76.01.2, 76.01.9, 97, 97.01, 97.02, 97.21.

В моей базе константа включена — отсюда и признак у 44. А вот в поставке список размечен непоследовательно: у 20, 20.01, 20.04, 23, 23.01, 23.05, 25, 26, 28, 29, 76.01.2, 76.01.9 и всех 97-х признак стоит, у 40 и всех 44-х не стоит. Это не моя опечатка, это так в обеих выгрузках ПРОФ — и 3.0.206.19, и 3.0.191.41.

Объяснение нашлось в модуле обновления, в процедуре с говорящим названием УстановитьВестиУчетЗатратПоПодразделениямПриПервомЗапуске:

// При первом запуске значение константы и план счетов рассинхронизированы.
// Опция - отключена, на плане счетов ведется учет по подразделениям.
// Нужно настроить план счетов в соответствии с опцией.

Это 1С про свою же поставку, не я )) Судя по коду, при первом запуске база берет константу и приводит к ней весь список — то есть в свежей базе ПРОФ признак должен сняться и с 20, и с 26, и с 97. Чистую базу не разворачивал и своими глазами этого не видел, так что это чтение кода, а не наблюдение.

Признаки счетов смотрите в своей базе, а не в выгрузке конфигурации. Моя таблица выше показывает состояние поставки. Откройте свой план счетов и посмотрите колонку «Подразделения» глазами, это минута.

 

Где в ПРОФ лежит подразделение основного средства

В регистре сведений МестонахождениеОСБухгалтерскийУчет. Измерения: ОсновноеСредство и Организация. Ресурсы: Местонахождение (тип СправочникСсылка.ПодразделенияОрганизаций), МОЛ и Контрагент. Регистр подчинен регистратору, периодичность — по позиции регистратора, то есть СрезПоследних работает как обычно.

А на счетах 01, 02 и 03 в ПРОФ есть субконто «Основные средства» — прошел по выгрузке плана счетов и проверил каждый субсчет. Значит, стоимость разворачивается до конкретных объектов, а объект привязывается к подразделению через регистр:

ВЫБРАТЬ
	ЕСТЬNULL(М.Местонахождение, ЗНАЧЕНИЕ(Справочник.ПодразделенияОрганизаций.ПустаяСсылка)) КАК Подразделение,
	СУММА(ЕСТЬNULL(О.СуммаНУОстаток, 0)) КАК Стоимость
ИЗ
	РегистрБухгалтерии.Хозрасчетный.Остатки(
			&Дата,
			Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.ОсновныеСредства),
				ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.АмортизацияОсновныхСредств),
				ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.ДоходныеВложенияВ_МЦ)),
			ЗНАЧЕНИЕ(ПланВидовХарактеристик.ВидыСубконтоХозрасчетные.ОсновныеСредства),) КАК О
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.МестонахождениеОСБухгалтерскийУчет.СрезПоследних(&Дата,) КАК М
		ПО О.Субконто1 = М.ОсновноеСредство
СГРУППИРОВАТЬ ПО
	ЕСТЬNULL(М.Местонахождение, ЗНАЧЕНИЕ(Справочник.ПодразделенияОрганизаций.ПустаяСсылка))

Амортизацию отдельно вычитать не пришлось: таблица остатков отдает свернутое сальдо. В моем прогоне 02.01 и 02.03 пришли с минусом (−25 423,74 и −58 333,33), и сумма трех счетов сразу дала остаточную стоимость. Данных, правда, было два объекта, так что у себя это стоит увидеть глазами, а не принять на слово.

Чтобы не рассуждать, в том же прогоне подставим подразделение одной записи регистра и выполним этот запрос еще раз. До:

[пусто: 30 085 734,46 руб, объектов 2]

После:

[Головное подразделение: 483 050,84 руб, объектов 1] [пусто: 29 602 683,62 руб, объектов 1]

Потом вернул запись как была и получил первую строку обратно. Разрез по подразделениям запрос дает, и никакого КОРП для этого не требуется. Методическую правильность двумя объектами в демобазе не докажешь — это скелет, который дальше надо обвешивать условиями. Первым же условием, на котором сам и попался.

 

Моя собственная ошибка в этом самом запросе

24 сентября, уже на вычитке черновика, мне указали, что запрос выше берет Счет В ИЕРАРХИИ (01, 02, 03), а в иерархию счета 01 входит 01.К — «Корректировка стоимости арендованного имущества». Тот самый 01.К, с которого начинается следующий раздел.

В том виде, в каком запрос был написан, заметить это было нечем: субконто «Основные средства» на 01.К есть, строка приходит такая же, как от 01.01, и в итог складывается молча. Пошел смотреть, что на нем лежит в базе:

[01.01: 508 474,58] [01.03: 20 000 000,00] [01.К: 9 661 016,95] [02.01: -25 423,74] [02.03: -58 333,33]

Читается это так: 0,5 млн на 01.01, 20 млн на 01.03 «Арендованное имущество», 9,7 млн на 01.К и минус по амортизации на 02.01 и 02.03. Один только 01.К дает почти треть суммы, которую разделом выше с гордым видом называл остаточной стоимостью. После его исключения выходит 20 424 717,51 вместо 30 085 734,46 — и это еще не итог, дальше по тексту из расчета вылетят земельные участки и капитальные вложения.

Заодно видно, сколько вопросов прячется за одной итоговой строкой. Двадцать миллионов на 01.03 — это арендованное имущество, и надо ли оно в расчете доли прибыли, не разбирался: у меня демобаза, а не живой учет. В своей базе такой разворот по счетам стоит сделать первым делом, до всякой арифметики.

То есть написал статью про ошибку, которую легко не заметить, и сделал ее в первом же собственном примере. Запрос выше остается скелетом, и первое, что в него надо дописать, это исключение 01.К:

Счет В ИЕРАРХИИ (...) И НЕ Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.КорректировкаСтоимостиАрендованногоИмущества))

В КОРП эту проблему обошли до запроса. Там собирают массив счетов, разворачивают его до субсчетов и вычитают из него иерархию 01.К отдельной операцией:

СчетаАмортизируемогоИмущества = БухгалтерскийУчет.СформироватьМассивСубсчетов(СчетаАмортизируемогоИмущества);

// На счете 01.К отражается сумма будущих расходов, подлежащих признанию в соответствии
// с подп. 10 п. 1. ст. 264. Эти суммы не включаются в стоимость ОС.
КорректировкаСтоимостиАрендованногоИмущества = БухгалтерскийУчетПовтИсп.СчетаВИерархии(
	ПланыСчетов.Хозрасчетный.КорректировкаСтоимостиАрендованногоИмущества);

СчетаАмортизируемогоИмущества = ОбщегоНазначенияКлиентСервер.РазностьМассивов(
	СчетаАмортизируемогоИмущества,
	КорректировкаСтоимостиАрендованногоИмущества);

Разница не в защите от будущих субсчетов. СформироватьМассивСубсчетов разворачивает иерархию в момент вызова: внутри цикл по переданным счетам и отбор Ссылка В ИЕРАРХИИ(&МассивСчетов). Значит, новый субсчет под 01 подхватят оба варианта — это чтение кода, проб с добавленным субсчетом не ставились. Разница в одном — 01.К вычтен явно, отдельной строкой, которую видно при чтении кода. В моем варианте его не видно вообще.

Проверить себя тут стоит ровно одним запросом: тот же отбор, но с группировкой по счету, а не по подразделению. Пять строк вывода показывают больше, чем одна аккуратная итоговая.

 

Что считать имуществом, а что не считать

Кроме 01.К, КОРП выкидывает из расчета:

• объекты с ГруппаОС = КапитальныеВложенияВАрендованноеИмущество;
• объекты с ГруппаОС = ЗемельныеУчастки;
• объекты с ТипОС = КапитальноеВложение.

В комментарии к этому куску стоит ссылка на письмо Минфина от 23.05.2014 № 03-03-РЗ/24791. Формулировку в коде передаю как есть: для целей статьи 288 под амортизируемым имуществом понимаются только основные средства, капитальные вложения из расчета исключаются. Номер письма сверял по открытым источникам, содержание — по комментарию 1С; первоисточник целиком не читал.

Земельные участки — отдельная засада, и тут пересказ общего места учета, а не того, что видно в прогоне. Участок лежит на 01.01, амортизация по нему не начисляется, остаточная стоимость равна первоначальной, и если у одного подразделения участок есть, а у другого нет, доли разъезжаются на ровном месте. А у вас в базе земельные участки на балансе есть? Если да — проверьте первым делом, что они не уехали в расчет.

Одна тонкость для ПРОФ. Реквизит ТипОС тоже входит в состав функциональной опции ВестиУчетПоПодразделениям, а значит, в карточке основного средства его быть не должно. В карточку не смотрел, это опять вывод из состава опции. Полнотекстовый поиск по конфигурации дает два места, где ему присваивают значение: обработчик обновления и загрузка данных из другой учетной системы. Обработчик выводит значение из ГруппаОС:

Если Строка.ГруппаОС = Перечисления.ГруппыОС.КапитальныеВложенияВАрендованноеИмущество Тогда
	ОСОбъект.ТипОС = Перечисления.ТипыОС.КапитальноеВложение;
Иначе
	ОСОбъект.ТипОС = Перечисления.ТипыОС.ОбъектОС;
КонецЕсли;

В моей базе ТипОС заполнен у всех объектов — их, правда, всего два. Что будет у объекта, заведенного руками уже после обновления, не проверял. Практический вывод от этого не меняется: фильтруйте по ГруппаОС. В состав функциональной опции она не входит, значит, в карточке должна быть видна. А условие по ТипОС, перенесенное из КОРП, на моих данных не отсеяло бы ничего; что оно даст на ваших, зависит от того, прогоняли ли вы обработчик обновления.

 

Арифметика: доля прибыли как среднее двух удельных весов

Основание — пункт 2 статьи 288 НК РФ: доля прибыли подразделения есть средняя арифметическая двух удельных весов, по труду и по имуществу. Формулировку беру из комментариев в коде КОРП, текст статьи целиком не читал. В коде КОРП это выглядит так:

Если ИтогПоказательОпределенияДолиПрибыли = 0 И ИтогСредняяСтоимостьИмущества = 0 Тогда
	Запись.ДоляНалоговойБазы = 0;
ИначеЕсли ИтогПоказательОпределенияДолиПрибыли = 0 Тогда
	Запись.ДоляНалоговойБазы = СтоимостьАмортизируемогоИмущества / ИтогСредняяСтоимостьИмущества;
ИначеЕсли ИтогСредняяСтоимостьИмущества = 0 Тогда
	Запись.ДоляНалоговойБазы = ПоказательОпределенияДолиПрибыли / ИтогПоказательОпределенияДолиПрибыли;
Иначе
	Запись.ДоляНалоговойБазы =
		(СтоимостьАмортизируемогоИмущества / ИтогСредняяСтоимостьИмущества
		+ ПоказательОпределенияДолиПрибыли / ИтогПоказательОпределенияДолиПрибыли)
		/ 2;
КонецЕсли;

Три ветки из четырех — вырожденные случаи: нет ни того ни другого, нет труда, нет имущества. В ручном расчете это ровно те клетки, где вылезает деление на ноль.

Средняя стоимость имущества считается по аналогии с пунктом 4 статьи 376 НК:

КоличествоМесяцевКалендарногоГода = Месяц(КонтекстРасчета.КонецПериода);
...
СтоимостьАмортизируемогоИмущества =
	(Запись.СтоимостьОСПрошлыхМесяцев + Запись.СтоимостьОССледующегоМесяца)
	/ (КоличествоМесяцевКалендарногоГода + 1);

Переменная названа КоличествоМесяцевКалендарногоГода, а лежит в ней номер месяца конца периода. Пока период считается от 1 января того же календарного года, номер месяца и количество месяцев совпадают: за девять месяцев там будет девятка, знаменатель — десять, и все сходится. Случай, когда это не так, — сразу ниже. Это разбор кода, не прогон: сам расчет на разных периодах не гонял. На месте разработчиков имя переменной поменял бы: читается как «двенадцать».

Отдельно про первый год. В комментариях рядом с этим кодом 1С разбирает организацию, зарегистрированную в декабре: в первый месяц средняя считается как одна тринадцатая суммы на конец декабря, и это значение в показатели декларации не идет, а используется только для прикидки ставки по ПБУ 18. Сам этот случай не проверял; если у вас организация или подразделение появились в середине года, считайте, что тут нужна отдельная проверка.

И кусок, до которого при ручном счете доходят не всегда:

РасчетДействующихПодразделений.Сортировать("НалоговаяБаза УБЫВ, ДоляНалоговойБазы УБЫВ, ...");

// Отклонение округления добавляем в самую большую долю
ПогрешностьОкругления = 1 - РасчетДействующихПодразделений.Итог("ДоляНалоговойБазы");
Если ЗначениеЗаполнено(РасчетДействующихПодразделений) И ПогрешностьОкругления <> 0 Тогда
	ЗаписьМаксимальнойДоли = РасчетДействующихПодразделений[0];
	ЗаписьМаксимальнойДоли.ДоляНалоговойБазы = ЗаписьМаксимальнойДоли.ДоляНалоговойБазы + ПогрешностьОкругления;
КонецЕсли;

Сумма долей обязана давать единицу. Недостачу после округления не размазывают поровну и не дописывают в последнюю строку — ее кладут в первую строку отсортированной таблицы. Комментарий 1С называет ее «самой большой долей», хотя первый ключ сортировки — НалоговаяБаза, а не ДоляНалоговойБазы. Обычно это одна и та же строка, но совпадают ли они всегда, не проверял.

 

Показатель по труду — и почему учетную политику у вас выбирает план счетов

Что брать — среднесписочную численность или расходы на оплату труда — организация решает сама и закрепляет в учетной политике. Пункт 2 статьи 288 добавляет важное: выбранный показатель не меняется в течение налогового периода.

Место для этого выбора в ПРОФ есть. Регистр сведений НастройкиУчетаНалогаНаПрибыль существует в обеих редакциях, и у него есть ресурс ПоказательОпределенияДолиПрибыли типа ПеречислениеСсылка.ПоказателиДляОпределенияДолиПрибыли. Перечисление тоже на месте, с двумя значениями. Не показывают его, судя по всему, потому что ресурс включен в состав функциональной опции ВестиУчетПоПодразделениям — снова вывод из состава опции, в форму не смотрел:

InformationRegister.НастройкиУчетаНалогаНаПрибыль.Resource.ПоказательОпределенияДолиПрибыли

В прогоне записал туда «Среднесписочная численность», прочитал обратно: значение легло и прочиталось, потом запись убрал. Хранилище работает, показывать его в интерфейсе просто некому.

Численность по подразделениям в ПРОФ считается штатной экспортной функцией:

Таблица = УчетЗарплаты.СреднесписочнаяЧисленностьДетальная(
	Организация, НачалоПериода, КонецПериода, ПоГоловнойОрганизации, ПоПодразделениям, Точность);

Вызвал ее в том же прогоне: отработала, вернула таблицу с колонками Организация, Подразделение, СреднесписочнаяЧисленностьСотрудников, СреднесписочнаяЧисленностьВнешнихСовместителей и еще восемью. Внутри развилка: если зарплата ведется в этой же программе, данные берутся из учета, если во внешней — из документов «Статистика персонала». Вторую ветку в прогоне не проходил, это чтение кода. Второй случай стоит проверить заранее: документов может просто не быть.

В комментарии к функции в КОРП лежит готовое обоснование для налоговой — письма Минфина от 20.11.2013 № 03-03-06/1/49980 и от 27.12.2011 № 03-03-06/2/201, и ориентир на правила Росстата по форме П-4.

А вот со вторым показателем в ПРОФ интереснее. КОРП собирает расходы на оплату труда из оборотов счетов затрат по статьям с ВидРасходовНУ = ОплатаТруда, в разрезе измерения Подразделение.

Две детали этого запроса легко пропустить при переносе. Первая: статьи затрат отбираются не только по виду расходов, но и по виду деятельности.

ГДЕ
	СтатьиЗатрат.ВидРасходовНУ В(&РасходыПоОплатеТруда)
	И СтатьиЗатрат.ВидДеятельностиДляНалоговогоУчетаЗатрат = ЗНАЧЕНИЕ(Перечисление.ВидыДеятельностиДляНалоговогоУчетаЗатрат.ОсновнаяСистемаНалогообложения)

В перечислении три значения: «Основная система налогообложения», «Особый порядок налогообложения» и «Распределяемые затраты». В расчет идет только первое, а статьи с двумя другими в показатель по труду не попадают. Потеряете этот отбор при переносе — сумма завысится у тех, у кого по таким статьям в периоде были обороты. Если раздельного учета нет, ничего не изменится.

Вторая: нормируемые расходы на оплату труда КОРП добирает отдельным запросом. Они в налоговом учете косвенные, поэтому сумма берется по кредитовому обороту счетов затрат в корреспонденции со счетами Продажи_УправленческиеРасходыНеЕНВД, Продажи_УправленческиеРасходыЕНВД, Продажи_РасходыНаПродажуНеЕНВД и Продажи_РасходыНаПродажуЕНВД. Один запрос по дебету счетов затрат этих сумм не увидит. Это чтение запроса КОРП: на своих данных разницу дебетового и кредитового сбора не мерил.

Признак УчетПоПодразделениям у счетов затрат в ПРОФ стоит — но только пока включена настройка «Учет затрат ведется: по каждому подразделению». Здесь сразу оговорюсь: в моей базе эта настройка включена, выключенное состояние не прогонял, дальше идет вывод из кода и из устройства признака. А вывод такой: при выключенной настройке обороты по 20, 26, 44 придут одной кучей без подразделений, и показатель по оплате труда из оборотов счетов затрат не соберешь. Останется численность — или зарплатные регистры, но этот путь не разбирал.

Отсюда тезис, с которым готов спорить в комментариях. Повторю оговорку, она тут важнее самого тезиса: базы с выключенной настройкой под рукой не было, это вывод из кода. А тезис такой: в ПРОФ учетную политику по доле прибыли фактически выбирает не бухгалтер, а настройка плана счетов. На бумаге у нас свобода выбора из статьи 288. На деле, если учет затрат ведется сводно, вариант «расходы на оплату труда» штатным путем не собирается, пока настройку не поменяешь и не перепроведешь год. Мне возразят, что настройку можно включить — можно, но это решение об учете затрат, а не о декларации, и принимать его ради одной строки Приложения 5 странно.

 

Чего я не нашел даже в КОРП

Пункт 2 статьи 288 разрешает организациям, перешедшим на нелинейный метод амортизации, определять остаточную стоимость по данным бухгалтерского учета. Это право организации, а не обязанность.

В процедуре ПодготовитьРасчетРаспределенияНалоговойБазы в КОРП упоминаний метода амортизации найти не удалось: ни МетодНачисленияАмортизации, ни «нелинейн», ни СуммаБУОстаток. В этой процедуре стоимость берется как СуммаНУОстаток, других веток там не видно. Перечисление МетодыНачисленияАмортизации со значением Нелинейный в конфигурации есть, регистр настроек этот метод хранит — а до расчета доли он, похоже, не доходит.

Искал грепом по модулю, полнотекстово. Возможно, это учтено где-то выше по стеку, и смотрю не в то место. Если кто-то знает, где именно, напишите — мне правда интересно.

 

Что меняется с 2027 года

Сразу про источники: официальная публикация закона и разъяснение ФНС от 19.05.2026; текст закона целиком не читал. Федеральный закон от 28.11.2025 № 425-ФЗ отменяет декларации по месту нахождения каждого ОП: с 1 января 2027 года головная организация сдает одну. Про статью 288 в разъяснении ничего нет, поэтому считаю арифметику прежней — это мое чтение разъяснения, а не позиция ФНС. Меняется цена ошибки: все подразделения теперь в одном документе. Форму под новый порядок ФНС утверждает отдельным приказом, и до его выхода номер приложения лучше не заучивать. Если в тексте закона есть что-то про сам расчет, поправьте: его не читал.

 

Что типовая на самом деле пишет в Приложение 5

Этот кусок нашелся последним, и без него статья ушла бы с неверным утверждением.

Кажется, что КОРП заполняет Приложение 5 целиком: доля, база, ставка, налог. Открываем ЗаполнитьЛист2Приложение5ДекларацииПоПрибыли и смотрим, что там присваивается на каждую страницу:

СтраницаЛист02_Прил5.П002050000100 = "1";
Если ЭтоОбособленноеПодразделение Тогда
	СтраницаЛист02_Прил5.П002050001000 = "2";
	СтраницаЛист02_Прил5.П002050002003 = ДоляНалоговойБазы.ОбособленноеПодразделение;
	СтраницаЛист02_Прил5.П002050002001 = ДоляНалоговойБазы.КПП;
Иначе
	...
КонецЕсли;
СтраницаЛист02_Прил5.П002050004003 = ДоляНалоговойБазы.ДоляНалоговойБазы * 100;
СтраницаЛист02_Прил5.П002050006003 = ДоляНалоговойБазы.СтавкаСубъектРФ;

Из показателей самой таблицы здесь присваиваются только два: П002050004003 — строка 040, доля налоговой базы, и П002050006003 — строка 060, ставка в бюджет субъекта. Остальное в этом фрагменте — служебное: номер страницы, признак «организация или подразделение» и КПП.

А где 050 и 070, налоговая база и налог? Полнотекстовый поиск по модулю НалоговыйУчетОбособленныхПодразделений дает на коды П002050005003 и П002050007003 два вхождения, и оба в одной процедуре — ОбнулитьПоказателиЛист2Приложение5ДекларацииПоПрибыли:

КоллекцияПоказателей.П002050005003 = 0;
...
КоллекцияПоказателей.П002050007003 = 0;

То есть в этом модуле типовая их обнуляет и больше не трогает. Дальше начинается объяснение, а не наблюдение: раз расчет их не пишет, значит, базу и налог по подразделению считает сама форма регламентированного отчета, из доли и ставки. Форму отчета мы не вскрывали и за руку ее на этом не ловили. Заодно там же КОРП обнуляет на Листе 02 строки П002000016003 и П002000017003 — ставки для тех, у кого есть обособленные подразделения, с комментарием, что такие налогоплательщики проставляют только федеральную ставку.

Практический вывод отсюда осторожный: 040 и 060 переносите, а 050 и 070 считайте для сверки. Вашу цифру налоговой базы вы получите из доли, отчет получит ее своей арифметикой, и совпадут они не обязательно — навскидку разойдутся там, где в декларации есть инвестиционный вычет. На данных этого не проверял, так что последнее предложение — предположение, а не измерение.

 

Чек-лист: десять шагов ручного расчета

Если собираетесь считать сами, вот порядок, который получился:

1. Посмотреть в своей базе признак «учет по подразделениям» у счетов 01, 02, 03 и у счетов затрат: в базе, а не в выгрузке конфигурации.
2. Посмотреть в МестонахождениеОСБухгалтерскийУчет не число записей, а заполненность ресурса «Местонахождение». Записи есть, а местонахождение пустое — считать нечего.
3. Считать стоимость ОС через субконто «Основные средства» плюс срез местонахождения, а не через измерение Подразделение.
4. Исключить счет 01.К из иерархии — я на этом попался, вы не попадитесь.
5. Выкинуть земельные участки и капитальные вложения: по ГруппаОС, а не по ТипОС.
6. Определиться с показателем по труду и не менять его до конца года.
7. Сложить остатки на первое число каждого месяца с начала года плюс на первое число месяца после отчетного периода, поделить на количество месяцев плюс один.
8. Округлить доли и добавить погрешность в строку с наибольшей налоговой базой.
9. Проверить, что сумма долей по действующим подразделениям — ровно единица. Закрытое подразделение в эту единицу не входит: в коде КОРП погрешность округления считается от РасчетДействующихПодразделений, а закрытые идут отдельной таблицей.
10. В декларацию перенести строки 040 и 060. Строки 050 и 070 посчитать для сверки, но в Приложение 5 их, судя по коду расчета, заполняет форма отчета; сам не проверял.

Десять пунктов, и каждый — место, где в Excel можно ошибиться и не заметить. На четвертом попался сам, показал выше )), а десятый узнал уже после того, как собрал обработку.

 

Что вошло в обработку и как она проверена

В прошлой статье был вопрос, есть ли смысл делать внешнюю обработку. Смысл, судя по вопросам в личку, есть, и она готова. Три закладки: расчет, соответствие подразделений и налоговых органов, справка-расчет.

На первой закладке организация, период и переключатель показателя по труду — численность или расходы на оплату труда. На выходе таблица долей со средней стоимостью имущества и выбранным показателем по каждому подразделению:

Вторая закладка — то самое соответствие, которое, как мы выяснили выше, в справочнике не держится. Третья — печатная справка-расчет.

В справке есть блок для декларации, и после находки про строки 050 и 070 он называется не «значения для Приложения 5», а «контрольные значения обработки для Приложения 5 к листу 02». Рядом печатается пояснение: 040 и 060 переносятся как есть, 050 и 070 обработка считает сама, и их надо сверять с тем, что посчитает форма отчета, а не подставлять вслепую. Формулировку пришлось менять уже по ходу: в первой редакции статьи стояло «чтобы переносить в декларацию не пересчитывая», и это было неверно.

Чем проверена

Сверку с типовым расчетом КОРП делал так: в базе КОРП того же релиза 3.0.206.19 напрямую вызывал НалоговыйУчетОбособленныхПодразделений.ПодготовитьРасчетРаспределенияНалоговойБазы и сравнивал результаты программно, по семи полям построчно. Сошлись в ноль восемь сценариев: три действующих ОП по оплате труда и то же по численности, снятие с учета в середине года и в первом отчетном периоде, смена ИФНС у подразделения и у головной организации внутри года, два закрытых ОП одновременно, убыток.

Это сверка на одних данных, а не доказательство методики: она говорит, что обработка считает то же самое, что типовая, а не что мы вдвоем считаем правильно.

Про запись в базу отдельно, потому что вопрос законный и словам тут верить нечего. Проверка такая: снимок базы до и после прогона, 4 075 контролируемых величин — записи всех регистров и документов, константы, итоги и обороты по счетам, — и все это под активной датой запрета изменения. Расхождений ноль. Плюс поиск по сборке: ни одного вызова Записать, НаборЗаписей, СоздатьМенеджерЗаписи, Провести, ПолучитьОбъект, СоздатьЭлемент, СоздатьДокумент.

Обработка сохраняет только одно: настройку соответствия подразделений и налоговых органов, по кнопке «Сохранить настройку», в хранилище общих настроек по ключу ДоляПрибылиОП/Подразделения.

Расчет доли прибыли по обособленным подразделениям для 1С:Бухгалтерии 3.0 ПРОФ

 

Где обработка спотыкается

Раздел, которого сам в описаниях не встречал. Пишу, потому что на каждый из этих пунктов кто-нибудь наступит, и лучше здесь, чем в отзыве.

Одно место, где данные придется вводить руками. Если подразделение снято с учета, в таблице появляются колонки «Замороженная доля» и «Замороженная база». Заполняет их человек, из своей же справки-расчета за последний период перед снятием. Достать их из системы не вышло: КОРП держит замороженные показатели в регистре РасчетДолейБазыНалогаНаПрибыль, а в выгрузке ПРОФ 3.0.206.19 такого регистра нет — это один из объектов, которые в редакцию не поставляются вовсе, в отличие от тех, что просто закрыты опцией.

И сразу первая грабля, на которую наступил сам. Чтобы попасть в эту ячейку, нужен двойной клик или F2. Если начать набирать цифры сразу, платформа примет их за поиск по таблице: на форме повиснет бейдж вида «Замороженная доля закрытого ОП: 0», а значение не введется. Выглядит это ровно как «колонка не заполняется». Поймано живым вводом в тонком клиенте. На снимках выше этих колонок нет: в той базе все подразделения действующие, а появляются они только при снятом с учета.

И там же вторая: минус в числовой ячейке набирается после цифр. Начнете с минуса — получите 1 500 000 вместо -1 500 000.

Сумма долей может выйти больше 100%, и это не ошибка. На данных с закрытым подразделением обработка показала доли 0,607142, 0,392857 и 0,2, то есть в сумме 1,2. Типовой КОРП на тех же данных дает столько же, и причина в коде, который мы уже смотрели: погрешность округления доводит до единицы сумму по действующим подразделениям, а закрытое идет отдельной таблицей поверх. Если сложить показанные разряды, выйдет 1,199999 — это округление в выводе, внутри доли точнее. Столбец «Доля» складывается сам собой, поэтому говорю об этом заранее.

Уплата налога по группам обособленных подразделений не поддерживается. Когда налог за всю группу в регионе платит ответственное подразделение, обработка считает по каждой регистрации отдельно, и результат применять нельзя. Она читает признак из настроек налога на прибыль и выводит красное предупреждение до расчета, но знать об этом лучше до покупки.

У сохраненного соответствия «подразделение — ИФНС» нет даты. Если соответствие сохранено, оно перебивает срез истории регистраций, и расчет задним числом за ранний период даст не то распределение: подразделение, переведенное в свою инспекцию с июля, за первый квартал все равно пойдет по собственному КПП, хотя история на март показывает головную. В сверке со сценарием «смена ИФНС внутри года» этого не видно по одной причине: там соответствие не сохранялось и обе стороны читали историю.

И то, что не проверял. Филиалы на отдельном балансе, где знаменатель по численности берется по группе, а имущество по одной организации. Федеральная территория Сириус. Дробная среднесписочная численность при приемах и увольнениях в середине месяца. Внешние совместители и договорники ГПХ: в долю идет только СреднесписочнаяЧисленностьСотрудников, как и в КОРП, но на данных этого не гонял.

Ограничение по базе закрытого ОП. Не реализовано ограничение из письма ФНС от 28.05.2019 № СД-4-3/10244@. Смысл такой: если база по закрытому ОП один раз снизилась, последующий рост общей базы организации ее не восстанавливает. За периоды после закрытия база и налог по этому ОП не поднимаются выше уже рассчитанного минимума. Формулировку беру из комментария в самом КОРП, где 1С ссылается на это письмо дважды; первоисточник не читал. Обработка не хранит историю своих расчетов и на этом месте предупреждает.

Платформа 8.5. Прогнал отдельно. Повторил на 8.5.1.1343 тот же расчет на тех же данных и сравнил файлы результата: совпали побайтно. Форму смотрел в тонком клиенте — таблица рисуется так же, снимки с двух платформ расходятся только мигающим курсором в полях ввода. Сверка с КОРП по восьми сценариям шла только на 8.3.

Веб-клиент. Совместимость не заявляю: в безголовом прогоне форма открывалась, кнопки работали и расчет шел, но рабочим режимом считаю тонкий клиент.

Производительность. Остатки ОС собираются парой запросов на каждый месяц периода, у КОРП на весь период один. На тысячах основных средств, скорее всего, будет медленнее типового; замеров нет.

 

Зачем в ПРОФ поставляют 130 строк пустых заглушек

Если вы дочитали досюда, вы и без обработки посчитаете. Нам с вами важнее другое: до сих пор непонятно, зачем в ПРОФ поставляются 130 строк пустых заглушек вместо того, чтобы не поставлять модуль вовсе. В профильном модуле расчета нет, по остальной конфигурации я его не искал. Картина вышла смешанная: интерфейс, перечисление показателей и место под выбор в регистре настроек — на месте и закрыты опциями, а расчет и регистр его результата не поставляются. То есть не «функциональности нет» и не «все есть, только выключено», а что-то посередине, и любопытно, как эта середина выглядит с той стороны.

Что думаете?

И отдельный вопрос к тем, у кого обособленные подразделения на ПРОФ: вы местонахождение основных средств вообще заполняете? Подозреваю, что во многих базах он пустой, и тогда весь разговор про запросы начинается не с того конца.