ФИО Физлица при формировании пачки

Или лыжи не едут, или проглядел что-то.<br> <br>Дано:<br>в течение 1 полугодия сдавались сведения в которых у сотрудника попалось "неправильное" ФИО (опечатка в отчестве)<br>в 3 квартале обнаружили и решили исправить...<br>исправили регистр сведений "Фамилия Имя Отчество физического лица"<br>проверили в "наименование" физ лиц и сотрудников.<br> <br>всё верно, всё на месте.<br>формируем пачку.<br>на выходе получили файл.<br>смотрим в файл... там отчество по-старому "кривое".<br> <br>номер релиза должен быть свежий.<br>что за проблема?

1. В спр."Физические лица" сейчас видите правильное отчество?<br> 2. От какого числа в РС "ФИО физлица"поставили новое отчество?<br> 3.<br> <br>>в 3 квартале обнаружили и решили исправить...<br> <br> Сами обнаружили или ПФР? Если СНИЛС был оформлен с неправильным отчеством, тогда пока не выдадут новое , нельзя делать такие корректировки.

как у вас с неправильным отчеством пачки приняли?<br>вы когда пачку формируете какое отчество видите?<br>и как эту пачку выгружаете?

> 1. В спр."Физические лица" сейчас видите правильное отчество?<br>> 2. От какого числа в РС "ФИО физлица"поставили новое отчество?<br>> 3.<br>> <br>> >в 3 квартале обнаружили и решили исправить...<br>> <br>> Сами обнаружили или ПФР? Если СНИЛС был оформлен с неправильным отчеством, тогда пока не выдадут новое , нельзя делать такие корректировки.<br>1. Отчество правильное<br>2. В регистре сведений просто скорректировали единственную имеющуюся запись, там всё верно.<br>Эти моменты я перепроверил.<br> <br>3. Там вообще интересная ситуация.<br>Вкратце. Это проблема у моего клиента. в 1 и 2 кв с базой работал один человек, сейчас работает другой.<br>И каким то образом, тот первый, формировал пачки в течение полугодия с неправильным отчеством (и что самое интересное, либо их приняли, либо он корректировал непосредственно в файле)<br> <br>Новый бухгалтер после отправки отчётности в протоколе получил "неправильно указано отчество, в базе (ПФР) "Васильевич", в файле "Василвевич" <br>Зашёл в регистр сведений, поправил запись, проверил справочники.<br>Вроде всё в порядке.<br>Сформировал пачки... получил в протоколе ту же ошибку.<br> <br>После этого позвонил мне, мы вместе всё проверили, я посоветовал полностью удалить все пачки за 3 квартал и сформировать их по новой.<br>Всё пучком, всё сделали. В справочниках всё верно, в регистре сведений одна корректная запись. В пачке показывается всё верно.<br>Собирает отправку, отправляет, получает в ответ (см. выше)<br>Проверяет xml... точно... опять отчество "кривое".<br> <br>Пока я посоветовал ручками поправить xml и сдать. А с этим вопросом, сам впал в ступор.<br>Вот я и думаю, а может ли каким нибудь образом наличие предыдущих пачек с "кривым" отчеством влиять на формирование файла.<br>Хотя по логике вещей не должно, но глядя на то как механизмы при формировании каких либо сведений берут индекс населённого пункта не из поля "Индекс" и не из поля представления адреса, а напрямую из таблицы классификатора, начинаешь задумываться.<br>У этого клиента в очередной раз с этим столкнулся... Адрес проверили, всё стоит правильно. Протокол ругается на несоответствие индекса. (в начале года разбили два района на отдельные зоны)<br>Обновили классификатор, ничего не переформировывали, просто выгрузили повторно, выгрузилось с уже обновлённым индексом. Хотя по логике вещей, даже если индекс был в контактных данных поправлен ручками, и вообще есть это поле, то значение должно как бы браться из него. Ан нет. Иногда не дано нам понять ход мыслей отдела разработки 1С.<br> <br> <br>Есть правда ещё один вариант... Это уже в понедельник проверю. Юзеры у нас любят забывать "подчищать" за собой.<br>В попытках отправить отчёт навыгружают разные версии в разные места<br>Может она действительно сформировала пачку и выгрузила в один каталог... а отправила предыдущую "кривую" выгрузку из другого.

Перед тем как отправлять отчетность в ПФР, если посмотреть файл XML вот в этом месте как на картинке, видишь правильное отчество?<br> <br> Если да, то дело не в 1С, разбираться нужно с программой электронной отчетности, она любит поисправлять файлы XML по своему разумению.

Прикрепленные файлы

Отчество в XML.jpg (73.58 КБ)

> В пачке показывается всё верно.<br>Можете показать.

вот кстати замечено, что если не удалять комплект выгруженных пачек, то исправленные не записываются в этот же каталог (если нумерацию сохранять)

Всем спасибо, разобрались.<br> <br>Очередной раз не мог понять ход мыслей группы разработки, но потом всё встало на свои места <br>Юзабилити конечно хромает, но логика в продукте железная.<br> <br>Огромное спасибо Дине.<br>Проверил генерацию файла, действительно обнаружилось расхождение между данными в реквизите-ссылке и данными выдаваемыми наружу при печати и формировании xml пакета.<br> <br>Вобщем. Нашёл первым делом, зачем-то заведённый документ от 2011 года в котором этот сотрудник первый раз "проклюнулся". Это оказалась ведомость СЗВ-6-3.<br>Там помимо реквизита - ссылки на справочник, были ещё поля обозначающие ФИО. Там обнаружилась ошибка.<br>Исправил, но дело всё равно не пошло.<br>Решил посмотреть состав табличной части ведомости СЗВ-6. Как и подумалось, там обнаружились поля "Фамилия" "Имя" "Отчество", в которых и засели некорректные данные.<br>Видимо системе хватило данных о том, что одна из предыдущих пачек содержала именно такое "Отчество", более того у пачки стояло true в булеве "Принято в ПФР".<br> <br>Не могу к сожалению провести эксперимент прямо сейчас, но судя по всему, если один раз ПФР "принял" пачку с неправильными сведениями, то в дальнейшем система не утруждает себя сбором информации по регистру "ФИО физического лица" а просто берёт сведения из последней "успешно принятой" пачки.<br> <br>Вот так вот, "утверждённая" пользователем ошибка, может повлиять на все последующие действия.<br>Призадумавшись над действительным назначением флага "Принято в ПФР", ход мыслей группы разработки понял <br>Дал задание клиенту, поснимать флаги "Принято в ПФР", исправить данные ручками, и поднять флаги по новой.<br> <br>Единственное, что хотелось бы предложить группе разработки.<br>Неплохо было бы в процедуры генерации файла и вывода на печать воткнуть вызов функции, которая бы выявляла такие расхождения между данными в пачках ПФР и регистром "ФИО физического лица" и если уж на то пошло, то анализировала, не связано ли такое расхождение с анкетой АДВ-2.<br>В случае нестыковки, выдавала бы предупреждение.<br> <br>Сам не франч, поэтому народ, у кого есть возможность зашлите инфу, пусть подумают над этим.

> но судя по всему, если один раз ПФР "принял" пачку с неправильными сведениями, то в дальнейшем система не утруждает себя сбором информации по<br>> регистру "ФИО физического лица" а просто берёт сведения из последней "успешно принятой" пачки.<br> <br>Нет, не судя , так как фамилия может поменяться.

Кодга фамилия меняется, по сотруднику подаётся АДВ-2, содержащая изменённые сведения.<br>И после того как мы поднимем в АДВ флаг "Принято в ПФР", следующая по очереди пачка возьмёт сведения из АДВ.<br>А вот когда мы один раз "сдадим" (поднимем флаг "принято") пачку СЗВ-6 с изменёнными сведениями, то следующая пачка возьмёт сведения уже из неё.<br>Ведь по сотруднику мы можем изменить сведения в личной карточке, но пока не предоставим изменённые сведения в ПФР, сдавать должны со старыми данными.<br> <br>И программа действительно корректно поддерживает этот процесс.<br>В пятницу. Бегом, бегом. Некогда было надо этим задуматься. А после того как увидел ответ Дины, призадумался, разложил по полочкам, и всё встало на свои места, сразу понял где стоит поискать источник проблемы.<br> <br>Просто, сам иногда забываю, хотя всем и всегда говорю. При поиске источника ошибки надо анализировать не просто источники данных, а процессы.