asirius
Мельник Сергей

При изменении ФИО подтягивается устаревшая фамилия.

Чтобы подтягивалась последняя ФИО, в запрос надо добавить упорядочивание:

К двум строкам

Код
|УПОРЯДОЧИТЬ ПО    |   КадроваяИсторияСотрудников.Период УБЫВ"):

Добавить строчку, чтобы получилось

Код
|УПОРЯДОЧИТЬ ПО    |   КадроваяИсторияСотрудников.Период УБЫВ,         |       ФИОФизическихЛиц.Период УБЫВ"):

Это во всех формах.

А если совсем точно, то нужно переделывать запрос, чтобы бралась актуальная фамилия на дату приказа.
Или использовать штатные методы ЗУП получения ФИО

Восстанавливал я тут недавно учет НДФЛ в одной организации, в которой были задержки выплаты зарплаты некоторым сотрудникам по полгода, и выплачивать начали постепенно в 2023 году. ЗУП оказалась совершенно неготова к такой ситуации.
Хорошенько покопавшись в алгоритмах работоты зуп, с уверенностью могу сказать, что проектировал систему какой-то двоечник, который бы завалил экзамен на специалиста по платформе 1С.
Расчет необходимой суммы удержанния НДФЛ по документу основанию делается запросом к движениям регистра накопления с анализом всех записей и выбором условия по регистратору примерно по следующему алгоритму: если регистратор совпадает с основанием - значит это начисление, а если не совпадает - то удержание. Концепция регистра накопления проектировщику видимо неизвестна. Из-за этого нет никакой возможности изменить сумму НДФЛ по основанию, которую следует удержать в выплатах, даже ручными корректировками не трогая исходный документ-регистратор или его движения.
Отсюда постоянные незакрытые остатки по разным измерениям, что черевато распуханием базы со временем и тормозами.

В целом, архитектура по НДФЛ нуждается в полной переработке. Основным документом расчета ндфл должен стать документ выплаты.
Даже более смелое утверждение. Та сумма начисленного НДФЛ, которая сейчас рассчитывается при начислении зарплаты и выгружается в проводках в конце месяца, не имеет никакой смысловой нагрузки для бухгалтерского учета. Ее тоже надо упразднить, и проводки делать по удержанному ндфл.

Не хватает в расширениях любой ссылки. В данных составного типа ссылаться можно только на типы объектов, которые добавлены в расширение.
К примеру хочу я добавить регистр сведений, в котором хранится статус некой обработки всех бух-проводок. Регистратором проводок может быть практически любой документ, его легко получить из подписки на событие записи проводок. Мне теперь все документы в расширение добавлять, такое себе развлечение... приходится возиться с уникальными идентификаторами.

Надо выпустить гайд для включения в реестр отчечественного ПО (может даже готовые формы на сайте, куда только реквизиты занести), разослать всем авторам и пусть авторы заспамят держателя реестра. После такой спам-атаки, думаю, переговоры по включению всех обработок с infostart.ru по упрощенное процедуре будут идти гораздо проще.

У вас опечатка в правилах "НайтиПоЗнаечнию"

Ошибка в обработчике события ПередВыгрузкойОбъекта
ПКО = СведенияОбИнвалидностиФизическихЛиц (Регистр сведений: Сведения об инвалидности физических лиц)
Объект = (Выборка из результата запроса)
Обработчик = ПередВыгрузкойОбъекта
ОписаниеОшибки = Метод объекта не обнаружен (НайтиПоЗнаечнию)
ПозицияМодуля = (7)
КодСообщения = 41

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

Столкнулся с аналогичной задачей для Комплексной Автоматизации 2.0
В регистре сведений "ЖурналУчетаСчетовФактур" у поля СчетФактураВыданныйПокупателю нет типа "Документ.СчетФактураВыданныйАванс", а без этого раздел декларации 10 по НДС с разделом 11 не сойдется., тк. изначально "СчетФактураВыданныйАванс" попадает в 10 раздел, а соответствие между 10 и 11 разделом идет через этот регистр по этому полю.
Если нет задачи учитывать все это дело у принципала, то там доработок на пол-дня: добавляем в регистр этот тип, в Документ.СчетФактураВыданныйАванс добавляем входящие реквизиты счета-фактуры от контрагента-принципала и пишем в регистр "ЖурналУчетаСчетовФактур" движения по аналогии, как они пишутся в БУХ 3.0.
И декларация по НДС уже работает без всяких доработок.
В моем случае принципалом была собственная организация, где надо еще формировать проводки 76.АВ-68.02 по сводным комиссионным счетам-фактурам, а так же зачитывать эти авансовые счета фактуры, если они зачитываются у комиссионера. Тут уже пришлось доработок на 50 часов выставлять и кастомизовать алгоритмы закрытия месяца по зачету авансов.

Надо бы этого робота страховыми взносами в ПФР и НДФЛ обложить, а то иш что вздумал: работает, рабочие места отнимает, а налоги не платит.

Попробовал запустить, в базе 30 тысяч элементов справочников, за 12 часов перенослось 4 тысячи. Полез отладчиком.... Это шутка такая, устанавливать коннект с базой для каждого элемента?

(18) Wow! Есть повод перейти на 8.3.13