Ошибка Формирования имени файла xml при повторной сдаче отче

[vol]

Программистам ОПЗ.
Считаю. что Вами допущена серьезная ошибка формирования имени xml файла отчетов, которые предназначены для сдачи только один раз в отчетном периоде.
Основываясь на Приказ ГНАУ №90 от 11.02.2010 года которым внесены изменения в формат (стандарт) электронного документа отчетности плательщика налогов утвержденный приказом ГНАУ от 3 мая 2006 года №242 "Про затвердження формату (стандарту) електронного документа звітності платників податків" (с изменениями и дополнениями, внесеннымиприказом ГНАУ то 5 декабря 2007 года №670). рассмотрим некоторые моменты такого формирования:
1. Согласно Стандарта есть 3 поля влияющие на уникальный номер файла
C_DOC_TYPE Номер виправного документа Для першого поданого в звітному періоді документа значення даного елемента дорівнює 0, кожний наступний виправний документ цього ж типу в даному звітному періоді має значення цього елемента, збільшеного на одиницю
C_DOC_CNT Номер однотипного документа в періоді Якщо в одному звітному періоді подається кілька однотипних документів, то значення даного елемента містить порядковий номер для кожного документа в даному періоді. Перший (звітний) документ має номер 1. При формуванні електронного документа, що є новим звітним (уточнюючим) до поданого раніше (звітного) (значення елемента C_DOC_TYPE >0), нумерація однотипних документів в періоді (значення елемента C_DOC_CNT) повинна залишатись незмінною щодо нумерації звітного документа, показники якого виправляються
C_DOC_STAN Стан документа Приймає фіксовані значення:

1 - звітний документ

2 - новий звітний документ

3 - уточнюючий документ
и позиции данных значений в имени файла
• позиція 23 містить ознаку стану документа (значення елемента C_DOC_STAN);

• позиції з 24 по 25 містять номер нового звітного (уточнюючого) документа у звітному періоді (значення елемента C_DOC_TYPE, доповненого зліва нулем до 2 символів). Для звітного документа позиції 24...25 міститимуть значення 00;

• позиції з 26 по 32 містять порядковий номер документа, що може подаватись декілька разів в одному звітному періоді (значення елемента C_DOC_CNT, доповненого зліва нулями до 7 символів). Якщо звіт подається лише один раз, то позиції 26...32 міститимуть значення 0000001.

Итак имеем стандартную ситуацию например Декларации НДС - она сдается один раз в периоде (месяц или квартал)
C_DOC_STAN = 1, C_DOC_TYPE = 0, C_DOC_CNT = 1 и Имя файла имеет вид ****J0200111 1 00 0000001 ***.xml для ЗВИТНОГО документа
C_DOC_STAN = 2, C_DOC_TYPE = 1, C_DOC_CNT = 1 и Имя файла имеет вид ****J0200111 2 01 0000001 ***.xml для НОВОГО ЗВИТНОГО документа
C_DOC_STAN = 2, C_DOC_TYPE = 2, C_DOC_CNT = 1 и Имя файла имеет вид ****J0200111 2 02 0000001 ***.xml для следующего НОВОГО ЗВИТНОГО документа т.е уникальность файла определяется значением поля C_DOC_TYPE и соответственно позицией цифр 24 и 25 в имени файла.

Теперь рассмотрим нашу ситуацию когда документ создан и отослан, но не принят на Центральном уровне (в районную налоговую он не попал, поэтому отметки о приходе ЗВИТНОГО документа нет и посылать НОВИЙ ЗВИТНИЙ невозможно, т.к. придет ответ, что документа ЗВИТНОГО нет и подача НОВИЙ ЗВИТНИ невозможна.
Вы предложили создать еще один документ с номером 2 (доступно в версии 1.29.22)в текущем периоде т.е
C_DOC_STAN = 1, C_DOC_TYPE = 0, C_DOC_CNT = 2 и Имя файла имеет вид ****J0200111 1 00 0000002 ***.xml для ЗВИТНОГО документа чем нарушили Стандарт т.к C_DOC_CNT Номер однотипного документа в періоді и позиції з 26 по 32 містять порядковий номер документа, що може подаватись декілька разів в одному звітному періоді (значення елемента C_DOC_CNT, доповненого зліва нулями до 7 символів). Якщо звіт подається лише один раз, то позиції 26...32 міститимуть значення 0000001..
Считаю, что для такой ситуации нужно использовать C_DOC_TYPE Номер виправного документа и соответственно позиції з 24 по 25 містять номер нового звітного (уточнюючого) документа у звітному періоді (значення елемента C_DOC_TYPE, доповненого зліва нулем до 2 символів). Для звітного документа позиції 24...25 міститимуть значення 00;
и файл будет таким:
C_DOC_STAN = 1, C_DOC_TYPE = 1, C_DOC_CNT = 1 и Имя файла имеет вид ****J0200111 1 01 0000001 ***.xml для ЗВИТНОГО документа поданного второй раз.

Программисты МЕДОК, основываясь на Ваше разрешение в программе присвоить следующий номер в периоде для документа, который может быть подан только один раз в периоде и сделали такой же алгоритм.

[валенки]

это в опз запараллелили C_DOC_STAN и C_DOC_TYPE что ли? чтобы не заморачиваться

[vol]

это в опз запараллелили C_DOC_STAN и C_DOC_TYPE что ли? чтобы не заморачиваться

Нет они сделали автоматом изменение C_DOC_CNT на +1 для второго отчета.

[валенки]

Программистам ОПЗ.
Считаю. что Вами допущена серьезная ошибка формирования имени xml файла отчетов, которые предназначены для сдачи только один раз в отчетном периоде.

Программисты МЕДОК, основываясь на Ваше разрешение в программе присвоить следующий номер в периоде для документа, который может быть подан только один раз в периоде и сделали такой же алгоритм

это не разрабы опз и медка, это те, кто xsd схемы пишет. запрет на изменение C_DOC_CNT описан именно там.

Код: Выделить всё

<xs:element name="C_DOC_CNT" type="xs:nonNegativeInteger" minOccurs="1" maxOccurs="1"/>

сравните, например F0100103.xsd и F0100105.xsd

[medoc_help]

валенки
minOccurs="1" maxOccurs="1" --- минимальное и максимальное количество вхождений тега , в ХМЛ документ.
Никакого запрета на его измение нет!
Буквально написано так: "В документе не может быть больше или меньше одного <C_DOC_CNT>. Он всегда один"
сравните с количеством допустимых строк для любого документа, допускающего более одной строки. Например, накладной:
<!--BODY-->
<!--TABLE №1-->
<xs:element name="RXXXXG2D" type="DateColumn" nillable="true" maxOccurs="9999"/>
Значение может не быть. Если будет, то не более 9999 тегов.

vol
Программисты Медка не основываются на программе ОПЗ, у нас собственные ТЗ от ГНСУ.
И если разработчики ТЗ ГНСУ для разработчиков ОПЗ дали ТЗ, отличающееся от ТЗ, предоставленного ими же разработчикам Медка... , тогда подготавливают новое ТЗ (для одной из сторон), которым предоставили ранее неправильное ТЗ. Чтобы обе программы соответсвовали друг другу (в части налоговой отчетности).

[валенки]

minOccurs="1" maxOccurs="1" --- минимальное и максимальное количество вхождений тега , в ХМЛ документ.

ээээ, да. касательно minOccurs и maxOccurs вы правы, а я ошибся

[medoc_help]

Ничего, бывает. А вот что хотел сказать своей темой vol, я так и не понял
"Кто виноват и что делать?"

[vol]

vol
Программисты Медка не основываются на программе ОПЗ, у нас собственные ТЗ от ГНСУ.
И если разработчики ТЗ ГНСУ для разработчиков ОПЗ дали ТЗ, отличающееся от ТЗ, предоставленного ими же разработчикам Медка... , тогда подготавливают новое ТЗ (для одной из сторон), которым предоставили ранее неправильное ТЗ. Чтобы обе программы соответсвовали друг другу (в части налоговой отчетности).

Да я совсем не это хотел сказать, а что счетчиком C_DOC_CNT нельзя пользоваться налево и направо - это не правомерно. Он используется только для однотипных документов в отчетном периоде (например Налоговая накладная) И Вы и ОПЗ используете один и тот же Стандарт, но почему то читаете по разному.

[валенки]

счетчиком C_DOC_CNT нельзя пользоваться налево и направо - это не правомерно

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

PS из подконтрольных мне предприятий есть одно, удачно попавшее под акцию бест-звита и вместе с ключами усц невозбранно почти нахаляву использовавшее годовую лицензию. в процесссе эксплуатации выяснилось, что абсолютно все импортированные (новые в бесте не создавались в силу привычки бухов к опз) документы имеют СКВОЗНУЮ нумерацию в поле C_DOC_CNT. то есть любой импортируемый документ, независимо от названия файла и тегов внутре, по выходу на подпись имел название и C_DOC_CNT, увеличенный на 1 по отношению к любому предыдуще импортированному. письма и звонки как платного клиента в бестзвит закончились обещаниями передать нашу проблему разрабам. был ли пофиксен глюк и в какой версии -лениво уже искать, но произошло (мобыть) это не раньше чем через полгода после обращения (а у нас тогда уже и лицензия кончилась, да и шлюз упорно продолжал принимать звиты с любыми циферями в этом поле, потому стало неинтересно).