Не правильно формирование имени файла при экспорте документа

[slasher]

Добрый день
Столкнулся с проблемой что при экспорте документа с версии 1.29.22 программа не правильно формирует имя файла, а именно не соответствует "Додаток 1
до наказу ДПА України від 03.05.06 № 242 (у редакції наказу ДПА України від 11.02.2011 № 90)" , в котором указана что позиция
• позиції з 26 по 32 містять порядковий номер документа, що може подаватись декілька разів в одному звітному періоді (значення елемента C_DOC_CNT, доповненого зліва нулями до 7 символів). Якщо звіт подається лише один раз, то позиції 26...32 міститимуть значення 0000001;

Что происходит:
Создал документ выгрузил на диск, сформировалось имя файла ........................0000001.............XML , где 0000001 - C_DOC_CNT. Поправил документ выгрузил повторно позиция C_DOC_CNT не изменилась, как в имени фала так и в теле XML. Хотя согласно "Додаток 1 до наказу ДПА України від 03.05.06 № 242 (у редакції наказу ДПА України від 11.02.2011 № 90)" должно было изменится, и принять значение - 0000002.

Подскажите когда будет исправлена данная проблема?

[mh_mh]

так можна ж поставити порядковий номер документа в періоді у той момент, коли Ви зберігаєте звіт

[vol]

Добрый день
Столкнулся с проблемой что при экспорте документа с версии 1.29.22 программа не правильно формирует имя файла, а именно не соответствует "Додаток 1
до наказу ДПА України від 03.05.06 № 242 (у редакції наказу ДПА України від 11.02.2011 № 90)" , в котором указана что позиция
• позиції з 26 по 32 містять порядковий номер документа, що може подаватись декілька разів в одному звітному періоді (значення елемента C_DOC_CNT, доповненого зліва нулями до 7 символів). Якщо звіт подається лише один раз, то позиції 26...32 міститимуть значення 0000001;

Что происходит:
Создал документ выгрузил на диск, сформировалось имя файла ........................0000001.............XML , где 0000001 - C_DOC_CNT. Поправил документ выгрузил повторно позиция C_DOC_CNT не изменилась, как в имени фала так и в теле XML. Хотя согласно "Додаток 1 до наказу ДПА України від 03.05.06 № 242 (у редакції наказу ДПА України від 11.02.2011 № 90)" должно было изменится, и принять значение - 0000002.

Подскажите когда будет исправлена данная проблема?

Вы сами себе противоречите:
1. Якщо звіт подається лише один раз, то позиції 26...32 міститимуть значення 0000001 и C_DOC_CNT = 1
2. должно было изменится, и принять значение - 0000002 - в честь чего, если документ предназначет только один раз в периоде.

[валенки]

2. должно было изменится, и принять значение - 0000002 - в честь чего, если документ предназначет только один раз в периоде.

тут у нас (да и у топикстартера) наблюдается глюк в совместимости логики ПО шлюзов/местного ПО налогововй, опз и медка/беста(про софт остальных цск ничего сказать не могу - нет опыта). Вам, вероятно известно об упорном нежелании медка импортировать в себя документы с одним и тем же именем. где-то тут на форуме я уже об этом растекался мысию по древу по этому поводу, продублировав у медковцев в этой ветке.
и таки да.
а)опз дизейблит поля для изменения документа в периоде для отчетов, подающихся один единственный раз (бест и шлюз повторные с тем же номером всасывает).
б)при создании в опз нового звитнего шлюз не пропускает, т.к. не принял звитний.
в)медок для звитнего требует новой нумерации в периоде, т.к. у него уже есть документ с квитанциями для старого звитнего о непринятии, которые он бережно хранит. а изменение C_DOC_CNT слегка противоречит ПОРЯДКУ ПОДАННЯ... руками блокнотом опзшный xml и его название - спасают ситуацию.

круг замкнулся, потому что порядок, опз, медок, бест, шлюзовое ПО (простите, остальные цск не упомянул) писали абсолютно разные программисты со своим виденьем конкретных ситуаций. а программисты-прикладники, написавшие порядок глядели на него со стороны налоговых инспекторов и шлюзового сервера. и в стандарте отчета не отображена понятная простому человеку и всем остальным прогерам блок-схема действий "если-то".
"если не принят по причине 1 <да/нет> - то <1/2> и тд"
как-то так

[vol]

2. должно было изменится, и принять значение - 0000002 - в честь чего, если документ предназначет только один раз в периоде.

тут у нас (да и у топикстартера) наблюдается глюк в совместимости логики ПО шлюзов/местного ПО налогововй, опз и медка/беста(про софт остальных цск ничего сказать не могу - нет опыта). Вам, вероятно известно об упорном нежелании медка импортировать в себя документы с одним и тем же именем. где-то тут на форуме я уже об этом растекался мысию по древу по этому поводу, продублировав у медковцев в этой ветке.
и таки да.
а)опз дизейблит поля для изменения документа в периоде для отчетов, подающихся один единственный раз (бест и шлюз повторные с тем же номером всасывает).
б)при создании в опз нового звитнего шлюз не пропускает, т.к. не принял звитний.
в)медок для звитнего требует новой нумерации в периоде, т.к. у него уже есть документ с квитанциями для старого звитнего о непринятии, которые он бережно хранит. а изменение C_DOC_CNT слегка противоречит ПОРЯДКУ ПОДАННЯ... руками блокнотом опзшный xml и его название - спасают ситуацию.

круг замкнулся, потому что порядок, опз, медок, бест, шлюзовое ПО (простите, остальные цск не упомянул) писали абсолютно разные программисты со своим виденьем конкретных ситуаций. а программисты-прикладники, написавшие порядок глядели на него со стороны налоговых инспекторов и шлюзового сервера. и в стандарте отчета не отображена понятная простому человеку и всем остальным прогерам блок-схема действий "если-то".
"если не принят по причине 1 <да/нет> - то <1/2> и тд"
как-то так

Медок сейчас думает над этим вопросом, как правильно его решить.
Я со своей стороны считаю, что правильным в такой ситуации должно быть изменение позиции C_DOC_TYPE на +1 и соответственно нумерация в имени файла в позиции с 24 по 25 тоже +1.