Проставлялись даты января 2015 года.
Я проверила настройки по мануалу. Нашла ошибки, исправили. И теперь строки появились как нужно.
Всем большое спасибо.

Извините за перебор с цитатами)))
нота 2303710 - Form 6-NDFL: incorrect organization data.
Пока еще не ставил, но должна корректно обработать признак 33OKT, и вернуть корректные данные из T7RU9A

Коллеги, всем привет.

После установки ноты по 6-НДФЛ обнаружены следующие ошибки:
- в столбце FactIncomeTax (TXREC/6ND00010) не подтягиваются суммы, если был перерасчет у сотрудника. Например, в январе 16-го был перерасчет за декабрь 15-го года, в этом случае выводится сумма только за декабрь, выплаченная в январе.
- в колонке CalculatedTax (TXCAL/6ND00004) подтягиваются налоги по межрасчету, поэтому происходит задвоение суммы налога
- в расчете ЗП возникает ошибка в правиле RUE4, если сотруднику делать перерасчет или проводить моделирование за будущий период.

Проверил настройки по нотам еще раз, настроено в соответствии с требованиями SAP. У кого-нибудь есть или были подобные ошибки. Если да, каким образом их устранили?

Спасибо за помощь!

Коллеги, приветствую,
После установки нот 2295281, 2303710 получился не вполне ожидаемый результат. При наличии кода возврата признака 33OKT соответствующего существующему ИдОбъекта в T7RU9A (в формате /DDDDDDDD) табельный номер исчезает из формы 6-НДФЛ, оставаясь при этом успешно обработанным. Например для ТН в ЮЛ 1111 признак возвращает /11111111, строка с ИдОбъекта 11111111 имеется в T7RU9A также для ЮЛ 1111 – такой сотрудник перестал выводится в отчет. Как только попадания значения признака в T7RU9A не происходит (делаем искусственно) табельный выводится, но с параметрами основного ЮЛ (пустой ИдОбъекта), что для этого случая в принципе верно. Иными словами в отчете только те кто не был обработан признаком 33OKT или признак отослал к не корректному объекту.

Полагаю, что через 3 ноты сотрудники пропадут из PA30.

Если серьезно, то с каждой нотой новая бага.
Это ненормально.

Ну, да. Если раньше для разбора возвращаемой из признака строки достаточно было использовать простую команду split, то теперь идет вот такая конструкцияМеня особенно паттерн '(?:(?:[^/]*\/{1})|(?:[^\d]*))(\d{0,8})' здесь восхищает.
Регулярные выражения - это конечно круто, но не чрезмерно ли конкретно для этой задачи?

Поставил ноту 2303710, описанных вами багов не нашел, если что попадется, то озвучу.

Коллеги, добрый день.

Поставили ноту 2303710, однако ОКТМО в отчет подтягивается неверно. В программе почему-то идентификатор объекта определяется как сам ОКТМО (причем верный), и по нему пытается в T7RU9A найти нужную запись, но естественно не находит. Правильно я понимаю логику работы вывода ОКТМО?

Выходит нота нам не помогла. Скажите, пожалуйста, у кого-нибудь осталась еще проблема неверного ОКТМО в отчете?

PennyWise
Признак 33OKT как настроен? Что он возвращает, точный вид строки какой?

У нас этот признак зазечен. но идет так: он находит по соединению А002 вышестоящие орг.единицы, если нашел, то в BACK возвращает ОКАТО из T7RU9A. Но как я понимаю, потом основная программа, которая вызывает этот признак, пытается ОКАТО использовать как objid. И получается в отладчике я вижу верное ОКАТО, а в отчете вижу неверное.

Простите, если не совсем понятно. Я в коде не очень хорошо разбираюсь. Коллеги помогают.

to PennyWise
Сделайте проверку в вашей Z-программе, чтобы для 6НДФЛ вернулась ОЕ по соединению A002 (если конечно t7ru9a для этой ОЕ настроен).
ОКТМО же откуда то берете.

Здравствуйте. коллеги.
Подскажите, пожалуйста, кто сталкивался с проблемой несоответствия с 2-НДФЛ из-за отсутствия в 6-НДФЛ обработки по последнему орг.присвоению L? Как решали?

Так работать не будет. 6НДФЛ работает только с кодом ОргЕдиницы в строке возврата. Код ОКАТО/ОКТМО он не воспримет. Вам придется менять подход в этом решении.

Спасибо большое. Будем пробовать.

Коллеги, а почему по половине сотрудников ошибка "Невозможно считать данные заработной платы для сотрудника"?