ФИО Физлица при формировании пачки
Показывать по
10
20
40
сообщений
- 1
- 2
23.11.2012
16:19
#1
Или лыжи не едут, или проглядел что-то.
Дано:
в течение 1 полугодия сдавались сведения в которых у сотрудника попалось "неправильное" ФИО (опечатка в отчестве)
в 3 квартале обнаружили и решили исправить...
исправили регистр сведений "Фамилия Имя Отчество физического лица"
проверили в "наименование" физ лиц и сотрудников.
всё верно, всё на месте.
формируем пачку.
на выходе получили файл.
смотрим в файл... там отчество по-старому "кривое".
номер релиза должен быть свежий.
что за проблема?
Дано:
в течение 1 полугодия сдавались сведения в которых у сотрудника попалось "неправильное" ФИО (опечатка в отчестве)
в 3 квартале обнаружили и решили исправить...
исправили регистр сведений "Фамилия Имя Отчество физического лица"
проверили в "наименование" физ лиц и сотрудников.
всё верно, всё на месте.
формируем пачку.
на выходе получили файл.
смотрим в файл... там отчество по-старому "кривое".
номер релиза должен быть свежий.
что за проблема?
23.11.2012
16:40
#2
1. В спр."Физические лица" сейчас видите правильное отчество?
2. От какого числа в РС "ФИО физлица"поставили новое отчество?
3.
>в 3 квартале обнаружили и решили исправить...
Сами обнаружили или ПФР? Если СНИЛС был оформлен с неправильным отчеством, тогда пока не выдадут новое , нельзя делать такие корректировки.
2. От какого числа в РС "ФИО физлица"поставили новое отчество?
3.
>в 3 квартале обнаружили и решили исправить...
Сами обнаружили или ПФР? Если СНИЛС был оформлен с неправильным отчеством, тогда пока не выдадут новое , нельзя делать такие корректировки.
23.11.2012
20:01
#3
как у вас с неправильным отчеством пачки приняли?
вы когда пачку формируете какое отчество видите?
и как эту пачку выгружаете?
вы когда пачку формируете какое отчество видите?
и как эту пачку выгружаете?
25.11.2012
12:12
#4
> 1. В спр."Физические лица" сейчас видите правильное отчество?
> 2. От какого числа в РС "ФИО физлица"поставили новое отчество?
> 3.
>
> >в 3 квартале обнаружили и решили исправить...
>
> Сами обнаружили или ПФР? Если СНИЛС был оформлен с неправильным отчеством, тогда пока не выдадут новое , нельзя делать такие корректировки.
1. Отчество правильное
2. В регистре сведений просто скорректировали единственную имеющуюся запись, там всё верно.
Эти моменты я перепроверил.
3. Там вообще интересная ситуация.
Вкратце. Это проблема у моего клиента. в 1 и 2 кв с базой работал один человек, сейчас работает другой.
И каким то образом, тот первый, формировал пачки в течение полугодия с неправильным отчеством (и что самое интересное, либо их приняли, либо он корректировал непосредственно в файле)
Новый бухгалтер после отправки отчётности в протоколе получил "неправильно указано отчество, в базе (ПФР) "Васильевич", в файле "Василвевич"
Зашёл в регистр сведений, поправил запись, проверил справочники.
Вроде всё в порядке.
Сформировал пачки... получил в протоколе ту же ошибку.
После этого позвонил мне, мы вместе всё проверили, я посоветовал полностью удалить все пачки за 3 квартал и сформировать их по новой.
Всё пучком, всё сделали. В справочниках всё верно, в регистре сведений одна корректная запись. В пачке показывается всё верно.
Собирает отправку, отправляет, получает в ответ (см. выше)
Проверяет xml... точно... опять отчество "кривое".
Пока я посоветовал ручками поправить xml и сдать. А с этим вопросом, сам впал в ступор.
Вот я и думаю, а может ли каким нибудь образом наличие предыдущих пачек с "кривым" отчеством влиять на формирование файла.
Хотя по логике вещей не должно, но глядя на то как механизмы при формировании каких либо сведений берут индекс населённого пункта не из поля "Индекс" и не из поля представления адреса, а напрямую из таблицы классификатора, начинаешь задумываться.
У этого клиента в очередной раз с этим столкнулся... Адрес проверили, всё стоит правильно. Протокол ругается на несоответствие индекса. (в начале года разбили два района на отдельные зоны)
Обновили классификатор, ничего не переформировывали, просто выгрузили повторно, выгрузилось с уже обновлённым индексом. Хотя по логике вещей, даже если индекс был в контактных данных поправлен ручками, и вообще есть это поле, то значение должно как бы браться из него. Ан нет. Иногда не дано нам понять ход мыслей отдела разработки 1С.
Есть правда ещё один вариант... Это уже в понедельник проверю. Юзеры у нас любят забывать "подчищать" за собой.
В попытках отправить отчёт навыгружают разные версии в разные места
Может она действительно сформировала пачку и выгрузила в один каталог... а отправила предыдущую "кривую" выгрузку из другого.
> 2. От какого числа в РС "ФИО физлица"поставили новое отчество?
> 3.
>
> >в 3 квартале обнаружили и решили исправить...
>
> Сами обнаружили или ПФР? Если СНИЛС был оформлен с неправильным отчеством, тогда пока не выдадут новое , нельзя делать такие корректировки.
1. Отчество правильное
2. В регистре сведений просто скорректировали единственную имеющуюся запись, там всё верно.
Эти моменты я перепроверил.
3. Там вообще интересная ситуация.
Вкратце. Это проблема у моего клиента. в 1 и 2 кв с базой работал один человек, сейчас работает другой.
И каким то образом, тот первый, формировал пачки в течение полугодия с неправильным отчеством (и что самое интересное, либо их приняли, либо он корректировал непосредственно в файле)
Новый бухгалтер после отправки отчётности в протоколе получил "неправильно указано отчество, в базе (ПФР) "Васильевич", в файле "Василвевич"
Зашёл в регистр сведений, поправил запись, проверил справочники.
Вроде всё в порядке.
Сформировал пачки... получил в протоколе ту же ошибку.
После этого позвонил мне, мы вместе всё проверили, я посоветовал полностью удалить все пачки за 3 квартал и сформировать их по новой.
Всё пучком, всё сделали. В справочниках всё верно, в регистре сведений одна корректная запись. В пачке показывается всё верно.
Собирает отправку, отправляет, получает в ответ (см. выше)
Проверяет xml... точно... опять отчество "кривое".
Пока я посоветовал ручками поправить xml и сдать. А с этим вопросом, сам впал в ступор.
Вот я и думаю, а может ли каким нибудь образом наличие предыдущих пачек с "кривым" отчеством влиять на формирование файла.
Хотя по логике вещей не должно, но глядя на то как механизмы при формировании каких либо сведений берут индекс населённого пункта не из поля "Индекс" и не из поля представления адреса, а напрямую из таблицы классификатора, начинаешь задумываться.
У этого клиента в очередной раз с этим столкнулся... Адрес проверили, всё стоит правильно. Протокол ругается на несоответствие индекса. (в начале года разбили два района на отдельные зоны)
Обновили классификатор, ничего не переформировывали, просто выгрузили повторно, выгрузилось с уже обновлённым индексом. Хотя по логике вещей, даже если индекс был в контактных данных поправлен ручками, и вообще есть это поле, то значение должно как бы браться из него. Ан нет. Иногда не дано нам понять ход мыслей отдела разработки 1С.
Есть правда ещё один вариант... Это уже в понедельник проверю. Юзеры у нас любят забывать "подчищать" за собой.
В попытках отправить отчёт навыгружают разные версии в разные места
Может она действительно сформировала пачку и выгрузила в один каталог... а отправила предыдущую "кривую" выгрузку из другого.
26.11.2012
09:31
#5
Перед тем как отправлять отчетность в ПФР, если посмотреть файл XML вот в этом месте как на картинке, видишь правильное отчество?
Если да, то дело не в 1С, разбираться нужно с программой электронной отчетности, она любит поисправлять файлы XML по своему разумению.
Если да, то дело не в 1С, разбираться нужно с программой электронной отчетности, она любит поисправлять файлы XML по своему разумению.
26.11.2012
09:57
#7
вот кстати замечено, что если не удалять комплект выгруженных пачек, то исправленные не записываются в этот же каталог (если нумерацию сохранять)
26.11.2012
10:26
#8
Всем спасибо, разобрались.
Очередной раз не мог понять ход мыслей группы разработки, но потом всё встало на свои места
Юзабилити конечно хромает, но логика в продукте железная.
Огромное спасибо Дине.
Проверил генерацию файла, действительно обнаружилось расхождение между данными в реквизите-ссылке и данными выдаваемыми наружу при печати и формировании xml пакета.
Вобщем. Нашёл первым делом, зачем-то заведённый документ от 2011 года в котором этот сотрудник первый раз "проклюнулся". Это оказалась ведомость СЗВ-6-3.
Там помимо реквизита - ссылки на справочник, были ещё поля обозначающие ФИО. Там обнаружилась ошибка.
Исправил, но дело всё равно не пошло.
Решил посмотреть состав табличной части ведомости СЗВ-6. Как и подумалось, там обнаружились поля "Фамилия" "Имя" "Отчество", в которых и засели некорректные данные.
Видимо системе хватило данных о том, что одна из предыдущих пачек содержала именно такое "Отчество", более того у пачки стояло true в булеве "Принято в ПФР".
Не могу к сожалению провести эксперимент прямо сейчас, но судя по всему, если один раз ПФР "принял" пачку с неправильными сведениями, то в дальнейшем система не утруждает себя сбором информации по регистру "ФИО физического лица" а просто берёт сведения из последней "успешно принятой" пачки.
Вот так вот, "утверждённая" пользователем ошибка, может повлиять на все последующие действия.
Призадумавшись над действительным назначением флага "Принято в ПФР", ход мыслей группы разработки понял
Дал задание клиенту, поснимать флаги "Принято в ПФР", исправить данные ручками, и поднять флаги по новой.
Единственное, что хотелось бы предложить группе разработки.
Неплохо было бы в процедуры генерации файла и вывода на печать воткнуть вызов функции, которая бы выявляла такие расхождения между данными в пачках ПФР и регистром "ФИО физического лица" и если уж на то пошло, то анализировала, не связано ли такое расхождение с анкетой АДВ-2.
В случае нестыковки, выдавала бы предупреждение.
Сам не франч, поэтому народ, у кого есть возможность зашлите инфу, пусть подумают над этим.
Очередной раз не мог понять ход мыслей группы разработки, но потом всё встало на свои места
Юзабилити конечно хромает, но логика в продукте железная.
Огромное спасибо Дине.
Проверил генерацию файла, действительно обнаружилось расхождение между данными в реквизите-ссылке и данными выдаваемыми наружу при печати и формировании xml пакета.
Вобщем. Нашёл первым делом, зачем-то заведённый документ от 2011 года в котором этот сотрудник первый раз "проклюнулся". Это оказалась ведомость СЗВ-6-3.
Там помимо реквизита - ссылки на справочник, были ещё поля обозначающие ФИО. Там обнаружилась ошибка.
Исправил, но дело всё равно не пошло.
Решил посмотреть состав табличной части ведомости СЗВ-6. Как и подумалось, там обнаружились поля "Фамилия" "Имя" "Отчество", в которых и засели некорректные данные.
Видимо системе хватило данных о том, что одна из предыдущих пачек содержала именно такое "Отчество", более того у пачки стояло true в булеве "Принято в ПФР".
Не могу к сожалению провести эксперимент прямо сейчас, но судя по всему, если один раз ПФР "принял" пачку с неправильными сведениями, то в дальнейшем система не утруждает себя сбором информации по регистру "ФИО физического лица" а просто берёт сведения из последней "успешно принятой" пачки.
Вот так вот, "утверждённая" пользователем ошибка, может повлиять на все последующие действия.
Призадумавшись над действительным назначением флага "Принято в ПФР", ход мыслей группы разработки понял
Дал задание клиенту, поснимать флаги "Принято в ПФР", исправить данные ручками, и поднять флаги по новой.
Единственное, что хотелось бы предложить группе разработки.
Неплохо было бы в процедуры генерации файла и вывода на печать воткнуть вызов функции, которая бы выявляла такие расхождения между данными в пачках ПФР и регистром "ФИО физического лица" и если уж на то пошло, то анализировала, не связано ли такое расхождение с анкетой АДВ-2.
В случае нестыковки, выдавала бы предупреждение.
Сам не франч, поэтому народ, у кого есть возможность зашлите инфу, пусть подумают над этим.
26.11.2012
10:33
#9
> но судя по всему, если один раз ПФР "принял" пачку с неправильными сведениями, то в дальнейшем система не утруждает себя сбором информации по
> регистру "ФИО физического лица" а просто берёт сведения из последней "успешно принятой" пачки.
Нет, не судя , так как фамилия может поменяться.
> регистру "ФИО физического лица" а просто берёт сведения из последней "успешно принятой" пачки.
Нет, не судя , так как фамилия может поменяться.
26.11.2012
10:58
#10
Кодга фамилия меняется, по сотруднику подаётся АДВ-2, содержащая изменённые сведения.
И после того как мы поднимем в АДВ флаг "Принято в ПФР", следующая по очереди пачка возьмёт сведения из АДВ.
А вот когда мы один раз "сдадим" (поднимем флаг "принято") пачку СЗВ-6 с изменёнными сведениями, то следующая пачка возьмёт сведения уже из неё.
Ведь по сотруднику мы можем изменить сведения в личной карточке, но пока не предоставим изменённые сведения в ПФР, сдавать должны со старыми данными.
И программа действительно корректно поддерживает этот процесс.
В пятницу. Бегом, бегом. Некогда было надо этим задуматься. А после того как увидел ответ Дины, призадумался, разложил по полочкам, и всё встало на свои места, сразу понял где стоит поискать источник проблемы.
Просто, сам иногда забываю, хотя всем и всегда говорю. При поиске источника ошибки надо анализировать не просто источники данных, а процессы.
И после того как мы поднимем в АДВ флаг "Принято в ПФР", следующая по очереди пачка возьмёт сведения из АДВ.
А вот когда мы один раз "сдадим" (поднимем флаг "принято") пачку СЗВ-6 с изменёнными сведениями, то следующая пачка возьмёт сведения уже из неё.
Ведь по сотруднику мы можем изменить сведения в личной карточке, но пока не предоставим изменённые сведения в ПФР, сдавать должны со старыми данными.
И программа действительно корректно поддерживает этот процесс.
В пятницу. Бегом, бегом. Некогда было надо этим задуматься. А после того как увидел ответ Дины, призадумался, разложил по полочкам, и всё встало на свои места, сразу понял где стоит поискать источник проблемы.
Просто, сам иногда забываю, хотя всем и всегда говорю. При поиске источника ошибки надо анализировать не просто источники данных, а процессы.
- 1
- 2
Читают тему
(гостей: 1)