Импорт формы 4-ФСС в CheckXML+2НДФЛ

[vavochkin]

CheckXML+2НДФЛ (от 1 июля) -> 4-ФСС -> Импортировать из XML

Проблем две:

1) После импорта файла за полугодие (xxxxxxxxxx_2010_6.xml) на закладке "Титул" в поле "Код периода" отображается:
3 полугодие
(в заголовке окна правильная надпись "за полугодие 2010")
Если тут же ничего не меняя нажать кнопку "Сформировать файл эл.отчетности", то будет создан файл xxxxxxxxxx_2010_3.xml

В исходном файле xxxxxxxxxx_2010_6.xml соответствующие реквизиты заданы правильно:
QUART_NUM="6" YEAR_NUM="2010"

2) закладка "Таблица 1" строка 16:
пользователи часто заполняют строчки с датой, номером и суммой ПП таким образом:
1-я строка - ПП за 1-й месяц квартала;
2-я строка - ПП за 2-й месяц квартала;
3-я строка - ПП за 3-й месяц квартала;

Если платежки за какой-то месяц не было, то соответствующая строчка остается пустой. Например, если не было платежек за 1-й и 3-й месяцы, то первая и третья строчки будут оставлены пустыми, а во 2-й будет стоять дата, номер и сумма ПП за 2-й месяц квартала.
Ваша программа позволяет заполнять платежки таким образом. И никакого криминала в этом вроде бы нет.

Но! Если для заполненной таким образом формы сформировать xml-файл, а затем его вновь импортировать, нажав кнопку "Импортировать из XML", то произойдет следующее:
платежка второго месяца (дата, номер и сумма) переместится в первую строчку, во 2-й же строке появится та же сумма при пустых дате и номере ПП. Иначе говоря, сумма задвоится.

Наверняка то же самое произойдет и в аналогичном месте Таблицы 10, но я не проверял...

[Игорь Ильин]

Код периода - проверим.

Перемещение суммы строчкой выше - это нормально, как Вы понимаете. У программы не такая логика, как у пользователей, она месяцы не отслеживает.

Задвоение суммы - ошибка. Исправим. Спасибо за сигнал.

[vavochkin]

Перемещение суммы строчкой выше - это нормально, как Вы понимаете.

С этим можно было бы согласиться, если бы ваша программа не поступала при этом следующим образом при создании файла эл.отчетности:
S2R29="0.00"
S2R30="10000.11"
S2R26="0.00"

То есть она считает первую пустую строку как сумму оплаты за 1-й месяц квартала, а вторую строку с ненулевой суммой - суммой оплаты за 2-й месяц квартала.

Но при этом формирует только одну строку:
<PAYM_ORDER NUM="13" DT="2010-01-11" SUM="10000.11" />

При импорте же такого файла единственная строка PAYM_ORDER считается оплатой за 1-й месяц квартала, а наличие суммы в поле S2R30 (оплата за 2-й месяц квартала) приводит к появлению еще одной строки с оплатой (вычислил с помощью экспериментов) .

Я не знаю, какой логикой вы пользуетесь, чтобы определять соответствие полей S2R29, S2R30 и S2R26 и строк PAYM_ORDER (которые вроде явно к месяцам не привязаны), но в данной версии программы она неверна.

[Игорь Ильин]

Ошибка в коде периода - исправлена. Будет доступно в ближайшей версии.

Разбор ситуации с дублированием сумм и перемещением платежек привел к следующим результатам:
При формировании файла графа 16 таблицы 1 используется как для раздела "Перечислены страховые взносы по месяцам", так и для блока "Платежные поручения". Из-за этого появляется неоднозначность. Например, даты платежек могут не совпадать с месяцами, за которые они перечислены. Или в каком-то месяце было перечислено более чем одно платежное поручение. Или пользователь, как часто бывает, вообще не счел нужным вводить даты и номера платежек, ограничившись суммами. Такой файл не пройдет проверку при сдаче, но программа все равно должна импортировать максимально возможное количество информации.

Что происходит в вашем случае:
В файле есть запись, что было перечисление за 2-й месяц квартала (S2R30="10000.11"). Кроме того, есть запись об одном платежном поручении (<PAYM_ORDER NUM="13" DT="2010-01-11" SUM="10000.11" />). Программа сначала записывает во вторую строку графы 16 таблицы 1 сумму 10000.11, а затем - платежное поручение, в первую строку той же графы.

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

[vavochkin]

Что происходит в вашем случае:
В файле есть запись, что было перечисление за 2-й месяц квартала (S2R30="10000.11"). Кроме того, есть запись об одном платежном поручении (<PAYM_ORDER NUM="13" DT="2010-01-11" SUM="10000.11" />). Программа сначала записывает во вторую строку графы 16 таблицы 1 сумму 10000.11, а затем - платежное поручение, в первую строку той же графы.

Но это ваша программа "решила" что перечисление было за 2-й месяц квартала только на основании того, что эта сумма была записана во 2-й строчке и записала ее в поле S2R30 при создании xml-файла.
И ваша же программа импорта не может правильно воссоздать данные из xml-файла, созданные ей же.
Очевидно, что так быть не должно.
Следовательно, логика создания файла и логика импорта из него в вашей программе сейчас не соответствуют друг другу.

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

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

Запись о платежном поручении ничем к месяцу квартала не привязана (дату не считаем - оплатить можно и позже).
Есть сумма (S2R30="10000.11"), явно привязанная ко 2-му месяцу, и есть одна платежка на ту же сумму, не привязанная ни к какому месяцу. Почему эта платежка должна считаться относящейся к 1-му месяцу? Можно привязать ее в таких однозначных вариантах к "правильному" месяцу (в данном случае - ко 2-му).

Что делать в общем случае, когда эти разделы противоречат друг другу - вам решать, но в моем примере никакого противоречия нет, и задваивать сумму не обязательно. Почему бы при импорте не воссоздать данные на форме в том же виде, из которого и был сформирован этот XML:
1-ю строчку ПП оставить пустой
2-ю строчку ПП заполнить теми данными, что имеются в той единственной записи PAYM_ORDER, ведь по полю S2R30 видно, к какому месяцу это ПП относится.