Я недавно организовал сдачу отчетности в налоговую в электронном виде - теперь хочу поделиться своими наблюдениями по этому поводу и описанием решений возникших проблем.

Статья ориентирована в основном на ИТшников-СПДшников, но может быть полезна и остальным, если опустить технические детали.

Update от 2009.01.04: бОльшая часть статьи в связи со сворачиванием приема отчетности, подписанной ключами Нотар, уже неактуальна, детали см. ниже.

Update от 2009.01.04: “Звітність підписана ключами СКЗІ “Нотар” не приймається. В прийомі відмовлено.” - ну, вот и моя Дарницкая налоговая перестала принимать отчеты, подписанные Нотарем. Насколько я понял - точно такая же ситуация во всех остальных налоговых, кто еще принимал отчеты с нотаревскими ключами.

Комментировать это все у меня уже нет ни желания, ни даже злости, каждый делает выводы для себя сам. Почему я не собираюсь платить за то, чтобы налоговой было легче работать - я уже описывал в первоначальном варианте статьи, повторяться не буду.

Для тех, кто не совсем “в теме”: теперь для подачи электронной отчетности обязательно использование электронного ключа, полученного в одном из центров сертификации. Список см., например, здесь. Насколько я понял, минимальная стоимость на одного ЧП-шника на один год - порядка 60-100 грн. Дополнительно см. комментарии к этой статье, а также неофициальный сайт поддержки OPZ.

Quick links

Судя по гугловской статистике довольно большое количество людей, которые переходят по результатам поиска на эту страницу, ищут где скачать OPZ. Дабы не заставлять их прочитать пол-статьи для нахождения нужного линка: скачать OPZ можно например вот здесь.

Второй по популярности запрос: креш в ZpltCrypt, про него читаем здесь.

Про проблемы с OPZ в 2008 году и с типом отчетности в отчете F01/033/02 читаем здесь.

Update от 2008.01.17: как оказалось существует даже целый неофициальный сайт поддержки OPZ, есть ссылки на свежие версии OPZ и инструкция по работе с ним. Контента не очень много, но по крайней мере инструкция показалась вполне вменяемой. Инсталяции OPZ почему-то лежат на rapidshare (repackaged?), но есть и ссылки на официальные инсталяции на сайте налоговой.

Update от 2008.03.25: неофициальный сайт поддержки OPZ по старому адресу (opz.1000mb.ru) недоступен, ссылка выше исправлена и указывает на новый сайт.

Предыстория вопроса

Много. Не по делу. Спекулятивные предположения, не подтвержденные фактами. Язвительные замечания в адрес госорганов и некоторых частных компаний. Слабонервным и тем, кого интересует результат, а не лирика - читать начиная со следующей главы.

Электронной отчетностью я заинтересовался относительно давно.

Во-первых, поскольку “программист - это человек, который за два часа напишет программу, которая за пять минут сделает то, что руками можно было сделать за час” - для большинства программистов автоматизация это стоящая цель сама по себе, независимо от достигаемой (или нет) экономии. Естественно, я в данном случае не исключение. Во-вторых, у меня, как и у 90% населения, психофизиологическая несовместимость с атмосферой государственных учреждений - поэтому любая возможность избежать посещения госучреждения стоит того, чтобы за нее бороться.

С другой стороны, платить деньги за подобную “привилегию” я не был готов принципиально - справедливо, как мне кажется, предполагая, что налоговая должна быть заинтересована в электронной подаче отчетности мной не меньше, чем я сам.

Поэтому первый вариант - подача отчетности с помощью системы БестЗвіт, который стал доступен достаточно давно (возможно, уже даже в 2000м, кода я зарегистрировался как ЧП) - я даже не рассматривал.

Нет, я, конечно, не против поддержки отечественного производителя программного обеспечения, и все такое - но ИМХО в цивилизованном государстве не должна возникать ситуация, при которой некоторая частная компания вступает в сгов сотрудничает с государственным учреждением путем, который противоречит как интересам государства (т.к. платная сдача электронной отчетности уменьшает количество желающих ее сдавать в электронном виде), так и интересам граждан (тут понятно почему, я думаю). Я бы сделал предположение, что тут попахивает откат немного странными отношениями между такой компанией и государством - но так как соответствующих фактов у меня, естественно, нет - просто ограничусь тем недоумением, которое уже успел высказать

С другой стороны, нужно учитывать реалии нашей грустной украинской действительности - возможно, что если бы требовать “сделать все по нормальному”, т.е. силами самой налоговой (или какой-то частной компании по заказу налоговой - собственно, того же БестЗвіта, например) разработать спецификации и хотя бы минимальную референс-реализацию, опубликовать их, а дальше уже дать возможность всем, кому хочется, разрабатывать и продавать свои программные продукты с дополнительным added value, удовлетворяющие этой спецификации - то, возможно, “воз был бы и ныне там”.

Так или иначе, через несколько лет были приняты (и опубликованы в открытом доступе) несколько спецификаций, описывающих формат данных для обмена документами с налоговой (текущие версии документов доступны, например, здесь). Судя по всему, за основу спецификаций был взят тот XML формат, который уже использовался в БестЗвіте. Это, безусловно, был шаг в правильном направлении. Однако практической пользы от данного шага было не очень много по двум причинам:

1. Спецификации описывали общий формат документов, а не шаблоны конкретных документов, принимаемых налоговой. Пользы от этого было почти столько же, как от факта “налоговая администрация принимает электронную отчетность в виде XML документов”. Да, все классно, но что в них писать-то?
2. Передаваемые документы должны быть зашифрованы. Это, конечно, правильно, но выдачей ключей организациям и частным лицам на тот момент занималась некая организация (уже даже не помню названия), которая хотела что-то около $100 в год за предоставление этого самого ключа. Комментировать не буду, см. выше насчет взаимоотношений между частными фирмами и госорганами и искусственной организации монополии …

Наконец, в 2007 году была осуществлена третья попытка - на этот раз гораздо более успешная чем все, что было сделано до этого.

Была разработана и выложена в открытый доступ программа OPZ, которая, насколько я понимаю, содержит шаблоны всех (ну или большинства) документов, принимаемых налоговой - т.е. исправлена проблема (1), указанная выше. Кроме того, генерацию ключей теперь можно осуществлять самому с помощью программы GenKeys, которая также была выложена для свободного доступа - т.е. исправлена проблема (2).

На это предложение я уже “купился”, так как все выглядело достаточно честно. И насколько я могу судить на данный момент - все оказалось действительно более-менее так, как и обещалось, за исключением мелких технических деталей, но о них ниже.

Резюмируя вводную часть: “Наш путь извилист, но перспективы светлые” (С) Мао Цзе Дун.

Общая информация

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

Повторю только основные шаги и дам пару рекомендаций по тем пунктам, которые либо вызвали у меня затруднения, либо кажутся мне неочевидными для других.

Так как я СПД и описывать буду именно свой опыт и возникшие проблемы, то самостоятельно делайте поправки в нужных местах в случае, если вы - физлицо или “полноценное” юрлицо.

Кроме того, я оформлял договор и сдавал отчеты в Киеве, Дарницкая ДПА (Державна Податкова Адміністрація, если кто не в курсе . Поскольку у нас у каждой налоговой свои заморочки, не факт что 100% сказанного ниже будет относиться к вашей налоговой.

Заполнение договора

Вам необходимо заполнить договор с вашим ДПА на подачу отчетности в электронном виде.

Несмотря на то, что общий текст договора можно скачать здесь, все же рекомендую сходить в ДПА с дискетой и попросить записать шаблон договора и программы для генерации ключей / шифрования и подписи документов, так как у них уже есть заготовленный шаблон договора с вписанными данными о налоговой, а в комплекте программ для генерации ключей прописан ключ данной ДПА. Ключи ДПА также есть в Сети, но сходу не вижу ссылки, если кому-то нужно будет - напишите в комментах, попробую найти.

С заполнением особых проблем возникнуть не должно, единственное неочевидное для меня было то, что в “реквизитах сторон” необходимо указывать номер расчетного счета. То, что в договорах с заказчиками его указывать нужно - это понятно, но вот то, что он обязателен и в этом договоре - я не ожидал. Судя по всему, мне катастрофически не хватает юридического образования Данные про бухгалтера я не заполнял, “посада” директора написал “приватний підприємець”.

Генерация ключей

Для генерации ключей нужна программа GenKeys. Ее дают в налоговой, либо можно скачать в Сети - официального адреса именно для этой программы не знаю, но она входит в пакет OPZ, доступный здесь, вам его все равно качать придется.

Понадобятся 3 дискеты. Да, я тоже такие же глаза сделал Путь к дисководу “А:” намертво прописан в программе. Тем, кому лень искать дискеты или ставить эмулятор, могу порекомендовать распаковать GenKeys.exe (запаковщик UPX, запустить с ключом “-d”), в распакованном файле hex-редактором заменить все строки “A:” на “Z:”, например, и использовать старую добрую ДОСовскую команду “subst” для маппинга Z: на каталог по вашему усмотрению.

Альтернативный вариант: во время генерации программа создает каталог C:\ZVITCRP, куда складывает сгенерированные файлы, и уже оттуда копирует их на дискеты. Можно просто скопировать ключи из этого каталога. Минус - ключи будут лежать вперемешку, вам придется читать исходник GenKeys чтобы понять, какие ключи к чему относятся.

Еще один альтернативный вариант - пересобрать GenKeys из исходников, прилагающихся к нему, заменив “A:” на нормальный выбор каталога, и помещая ключи в подкаталоги выбранного каталога. Самый правильный вариант, но я этого не делал, так как ключи генерируются только 1 раз - вариант с subst’ом для меня был проще

После чего - заполняете в договоре поля открытых ключей, и несете 2 копии договора плюс дискету с открытыми ключами в налоговую. Дискету они не забирают, только копируют с нее открытые ключи к себе в базу прямо при вас, т.е. если нужно принести несколько ключей - то, похоже, можно их все записать на одну дискету и пальцем тыкнуть что и куда (в этом случае лучше всего назвать каталоги по идентификационным кодам). Возможно, даже на ЮСБ стике можно было принести - не спрашивал.

Генерация документов

Генерация документов осуществляется программой OPZ, нужна Java машина. Может, даже заведется под *никсами? Не проверял (update: без напильника - крайне маловероятно, как минимум JavaScript код непортабельный, используется Jscript.Encode и куча ActiveX компонент). Использование программы достаточно интуитивно, сделаю только несколько замечаний.

1. С точки зрения программы СПД - это физлицо, отдельного вида организации “СПД” у нее нет.

2. Обращайте внимание на “тип звітного періоду”! Для меня он оказался совершенно не интуитивным - например, отчет F01/033/02 (ЗВІТ суб’єкта малого підприємництва - фізичної особи - платника єдиного податку) несмотря на то, что в самом тексте пишется “за … квартал” по мнению Дарницкой ДПА подается за:

   1. Первый квартал
   2. Первое полугодие
   3. Девять месяцев
   4. Год

   При попытке подать отчет за 3 квартал с типом отчетного периода “квартал” мне его завернули.

   Особую пикантность ситуации придает то, что OPZ не поддерживает никакие другие типы отчетного периода для документа F01/033/02, кроме квартального!

   К счастью, ситуация лечится достаточно просто: файл spr\SPR_TERM.XML описывает предельные сроки подачи отчетности и типы их периодов, находите секцию <C_DOC>F01</C_DOC> <C_DOC_SUB>033</C_DOC_SUB> <C_DOC_VER>2</C_DOC_VER> для интересующего вас периода и модифицируете ее. Например, для модификации типа отчетного периода за 3й квартал 2007 года с “поквартального” на “9-месячный” изменения будут выглядеть так:

   • Было: <ROW> <C_DOC>F01</C_DOC> <C_DOC_SUB>033</C_DOC_SUB> <C_DOC_VER>2</C_DOC_VER> <D_TERM>05102007</D_TERM> <PERIOD_MONTH>9</PERIOD_MONTH> <PERIOD_TYPE>__2__</PERIOD_TYPE> <PERIOD_YEAR>2007</PERIOD_YEAR> </ROW>
   • Стало: <ROW> <C_DOC>F01</C_DOC> <C_DOC_SUB>033</C_DOC_SUB> <C_DOC_VER>2</C_DOC_VER> <D_TERM>05102007</D_TERM> <PERIOD_MONTH>9</PERIOD_MONTH> <PERIOD_TYPE>__4__</PERIOD_TYPE> <PERIOD_YEAR>2007</PERIOD_YEAR> </ROW>

   На всякий случай, типы периодов в PERIOD_TYPE, от 1 до 5:

   1. Месяц.
   2. Квартал.
   3. Полугодие.
   4. 9 месяцев.
   5. Год.

   Update от 2008.01.04: мало того, что эта проблема не была исправлена в обновлении OPZ 1.8 - в нем вообще не были добавлены периоды отчетности на 2008 год! В результате при запуске OPZ 1.8 в 2008 году при попытке создания нового отчета вылетает сообщение об ошибке, так как по умолчанию в поле “звітний рік” подставляется текущий год, на который нет ни одной записи в конфиг файле для типа отчета, выбираемого по умолчанию.

   Для решения проблемы самостоятельно необходимо сделать следующее:

   1. Добавить периоды отчетности на 2008 год для интересующих типов отчетов в файле spr\SPR_TERM.XML.
   2. При создании нового отчета не обращать внимания на сообщения об ошибках (нажимать “Yes” и выбирать нужный тип документа, после этого все должно работать нормально.

   Если не хочется заморачиваться - то можно взять мой SPR_TERM.XML, в нем добавлены периоды отчетности для всех отчетов на 2008 год, так что ошибка возникать вообще не должна, и кроме того исправлена проблема с типами периода для F01/033/02, описанная выше. Исправления сделаны только в периодах отчета за 2008 год, более ранние уже все равно вряд ли кого-то заинтересуют.

   Обратите внимание на то, что хотя периоды были добавлены для всех отчетов, реально я их проверил только для отчета F01/033/02, правильные они для остальных отчетов или нет - я понятия не имею, т.к. добавлялись они автоматически копированием данных 2007го года, если какие-то периоды задаются по нашим законам в стиле “последний нечетный вторник третьего месяца после Пасхи” - то однозначно они будут неправильные. Кроме того, возможность ошибки в копирующем скрипте, написанном за 5 минут, тоже исключить нельзя.

   Update: проблема с 2008 годом в последних версиях OPZ (начиная с 1.9?) уже вроде бы исправлена (сам не проверял).

Шифрование и подпись

Полученные из OPZ XML документы необходимо зашифровать и подписать с использованием ваших private ключей.

Сделать это можно программой ZPltCrypt, которая идет в комплекте все с тем же OPZ.

Если вы при этом не заметите каких-либо неудобств, то пропустите весь остаток этого раздела

Неудобство заключается в том, что если на этапе генерации ключей еще можно было одноразово смириться со вставкой дискет, то заморачиваться дискетами каждый раз при подписи документов мне кажется недопустимым. Естественно, решение с “subst” работает и здесь, но все равно неудобно.

Но есть две новости, как обычно:

• Хорошая: в комплекте с OPZ идут исходники ZPltCrypt.
• Плохая: они не собираются.

Причина несобирабельности - отсутствие утилитных файлов, в которых объявлены функции BestOem2Char и s_Crc32. Если с первой все просто (заменяем ее на библиотечную OemToCharBuff; непонятно, зачем было изобретать велосипед? Ну да ладно), то со второй возникли определенные проблемы - все собралось, но стандартная реализация CRC32, подставленная вместо s_Crc32 давала результат отличающийся от того, который генерировался исходным экзешником.

Пришлось посмотреть на исходный екзешник “вооруженным глазом” - в результате чего выяснилось, что s_Crc32 представляет собой самый обычный и стандартный CRC32, но без инвертирования результата в конце вычислений.

В итоге исходник был приведен к собирабельному и работающему виду, и вместо прошитых “A:” был добавлен диалог выбора каталога, который должен иметь следующую структуру:

• Подкаталог private_accountant с private ключами бухгалтера.
• Подкаталог private_manager с private ключами директора.

По умолчанию каталог инициализируется путем запуска ZPltCrypt, так что рекомендуется положить каталог с ключами где-то поблизости от него, чтобы не так долго по дереву было ходить

Поскольку ни в файлах, ни в дистрибутиве OPZ нигде ничего не сказано ни про лицензию на эти исходники, ни про копирайт (чтобы можно было хоть связаться и узнать по какой лицензии они идут), то я беру на себя смелость предположить, что они или в public domain, или распространяются по любой другой лицензии, которая не запрещает публиковать модификации этих исходников и бинарный файл, полученный из модифицированных исходников.

ZPltCrypt_0.1_alpha - скомпилированный екзешник (готовая для использования версия), ZPltCrypt_0.1_alpha_src - исходники (требуют компиляции С++ Билдером), ZPltCrypt_0.1_alpha.patch - патч для исходников, поставляющихся с OPZ.

В случае сомнений, какой именно файл Вам нужен - наверняка нужен первый

В каталоге запуска ZPltCrypt должен присутствовать файл ZCrypt.dll (брать из стандартной поставки ZPltCrypt).

За качество своего добавленного кода не извиняюсь, так как он написан примерно в том же стиле, что и все остальное, таким образом гармонично вписываясь в общую картину

Внимание: естественно, я ни за что не отвечаю! Никаких гарантий и чего-либо подобного - за что купил, за то и продаю Все претензии отправляйте сразу в ДПА - возможно, они тогда зачешутся и сами выпустят более удобные версии этих утилит …

Отправка

Зашифрованные и подписанные файлы необходимо отправить в налоговую по е-мейлу. Е-мейл адрес должен быть указан у вас в договоре с налоговой. Файлы просто добавляются в аттач к письму, содержание и subject письма, насколько я понял, неважно - я отправляю пустые письма.

В случае использования аутлука, я так подозреваю, все будет нормально, можете пропустить остаток этого раздела.

В случае использования мало-мальски standards-conformant е-мейл клиента у вас могут возникнуть определенные затруднения. Дело в том, что .xml файлы, зашифрованные с помощью ZPltCrypt - они уже не совсем .xml, а точнее - совсем не .xml, это просто бинарник. В тоже время, у него остается расширение .xml, более того - если вы его переименуете, то робот в налоговой, на который вы будете слать письмо, не воспримет этот файл как документ, который он должен распарсить.

В то же время, судя по результатам обработки моих отчетов, робот понимает только base64 encoding - тогда как для MIME типа text/xml разумнее использовать quoted-printable, что мой почтовый клиент Horde/IMP, например, с успехом и делает, приводя тем самым робота в легкую панику.

Так как почтовый клиент по такому незначительному поводу я менять не собираюсь, то пришлось пропатчить IMP чтобы ему можно было принудительно задать MIME тип файла, если кому-то нужен - то вот патч. Использование: после аплоада аттача пропишите в поле “description” для этого аттача строку вида “force-mime-type: application/octet-stream”.

Отчеты о доставке

Через некоторое время после получения вашего письма (у меня варьировалось в пределах от получаса до нескольких часов) вам должно прийти подтверждение получения документов. Обязательно прочитайте отчет - может оказаться, что документ не принят, тогда в отчете будет указана причина.

Если ваш документ не удалось расшифровать с серверной стороны, то отчет придет в незашифрованном виде, т.е. его нужно читать просто как plain text. Если ваш документ расшифрован, то отчет будет зашифрован, для его расшифровки используйте ZPltCrypt.

Обратите внимание, что если вы попробуете открыть незашифрованный отчет с помощью ZPltCrypt, то он скрешится. В принципе, имея компилящиеся исходники, это можно исправить, но мне это сильно не мешает

Обязательно сохраняйте все отчеты об успешной доставке и зашифрованные документы, которые вы отослали! Эти отчеты позволяют подтвердить факт подачи вами документов в налоговую.

Кстати, я пока что так и не смог понять какие фазы обработки выполняются автоматически, а какие - человеком. Надо будет попробовать ночью послать документ

Заключение

В целом, несмотря на некоторые технические проблемы, следует признать, что система электронной отчетности, предложенная нашей налоговой, достаточно адекватна и юзабельна (пока что не буду употреблять слово “удобна” ). Будем следить за дальнейшим развитием событий.

P.S.А Пенсионный Фонд, насколько я понимаю, до сих пор находится на стадии номер один: т.е. электронную отчетность в ПФ можно подать только через сторонний платный софт

Дополнительные ссылки

В основном “для себя”, если вдруг когда-то придется ковыряться более детально со всем этим делом.

1. Кросс-платформенная версия генератора отчетов, на QT, GPL: “Arilot - Звіт”
2. Описания некоторых из форматов отчетов (похоже уже не особо актуально, нужную инфу можно выковырять из ОПЗ).
3. Комбинированные программы, объединяющие шифрование и отсылку отчетов. Внимание: я эти программы не тестировал, используйте на свой страх и риск!
   • OPZ Mail
   • Zvit by email