Электронное документирование оказанных услуг на основе стандартов IS-XML

Тенденция развития взаимоотношений внутри бизнеса, а также между бизнесом и регуляторами, направленная на исключение бумажной документации, прослеживается весьма ярко. В России путь каждого проекта, целью которого ставится избавление от бумаги как носителя значимой для бизнеса и регулятора информации, традиционно тернист. Но результат налицо: бумажные авиабилеты заняли небольшую специфическую нишу, уступив рынок электронным билетам. Чего не скажешь об актах по форме "С", содержащих данные об услугах, оказываемых в аэропортах. Быть может, настал и их черед?..

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

1. IATA SIS – цели, история создания, зарубежная практика

2. IS-XML: стандарт, разработанный для организации взаимодействия IATA SIS с системами поставщиков услуг и авиакомпаний

3. Отечественная нормативная база и практика документирования операционных расходов авиакомпаний

4. Возможные причины, по которым IATA-SIS не нашла распространения в отечественной практике

5. Национальные особенности IS-XML

6. Пилотный проект по передаче-приему данных в формате IS-XML

7. Методические рекомендации по созданию файлов стандарта IS-XML

8. Если нельзя, но очень хочется…

9. Придание электронным документам IS-XML юридической значимости

10. IS-XML: дорожная карта поставщика

11. IS-XML: дорожная карта авиакомпании

12. Развитие стандарта IS-XML в России – организационный аспект

1. IATA SIS – цели, история создания, зарубежная практика

Вопросы стратегического развития отрасли авиаперевозок являются предметом постоянного внимания IATA. Одной из инициатив подобного плана явилось решение, разработанное для добровольного использования членами ассоциации и предназначенное для повышения оперативности и достоверности при выставлении счетов за услуги, прямо или косвенно связанные с операционной деятельностью пассажирских перевозчиков - платформа IATA SIS (Simplify Invoicing and Settlement) . В рамках этой инициативы Ассоциация предлагает авиакомпаниям как потребителям услуг и сервисным организациям как их поставщикам сервис выставления и акцепта счетов, обеспечивающий оперативность, прозрачность и юридическую значимость данных, обрабатываемых в рамках этого сервиса. При этом, наряду с возможностью ручной обработки (ввод постредством соответствующих форм и шаблонов с одной стороны и экспорт в формат электронных таблиц – с другой), в рамках решения клиентам предлагается открытый основанный на формате данных XML (eXtensible Markup Language), интерфейс для экспорта и импорта данных, позволяющий осуществить бесшовную интеграцию между учетными и производственными системами поставщика услуг и учетно-транспортной средой SIS с одной стороны и упомянутой средой с учетными системами авиакомпаний (в частности, с Revenue Accounting System / системой учета операционных показателей) с другой. В настоящее время количество участников инициативы IATA SIS превышает 2000. Среди участников присутствуют и отечественные авиакомпании, однако их практика работы в SIS ограничивается взаимодействием с иностранными поставщиками услуг.

2. IS-XML: стандарт, разработанный для организации взаимодействия IATA SIS с системами поставщиков услуг и авиакомпаний

Остановимся подробнее на интеграционном стандарте, именуемом IS-XML (Integrated Settlement XML), используемом для организации входных и выходных потоков данных решения IATA SIS. Стандарт включает в себя набор классификаторов, используемых для описания данных поставщиков и заказчиков, а также полного описания услуг в широком диапазоне допустимых видов. Для описания услуг используется принцип классификации "Вид-подвид". Актуальная версия 3.9.0.1 стандарта предусматривает возможность описания 21 вида  услуг; общее количество допустимых подвидов услуг достигает 272.

Стандарт включает в себя XSD-схему документа XML, набор обязательных или опционных параметров, а также перечень правил и требований к данным. В настоящее время стандарт представляет собой совокупность описательной части в формате файла электронных таблиц и набора примеров формирования XML-файлов применительно к различным видам оказываемых услуг. Описание стандарта можно скачать на странице SIS for Airlines & Intermodal https://www.iata.org/services/finance/sis/Pages/airlines.aspx официального сайта Ассоциации; актуальная на момент написания статьи версия стандарта расположена по ссылке https://www.iata.org/services/finance/sis/Documents/ISPG/3.9.0.1/IS-XML-Record-Structure-v3.9.0.1.zip

Ранее IATA выпускала руководства, касающиеся применения стандартов для услуг различного вида, но после 2014г., к сожалению, от этой практики отошла. Тем не менее, их еще можно найти на сайте Ассоциации. В частности, руководство по формированию файлов IX-XML применительно к наземному обслуживанию можно скачать по ссылке   https://www.iata.org/services/finance/sis/Documents/IS-XML_e-invoicing_standard_Ground_Handlers.pdf . Он весьма полезен для первоначального ознакомления со стандартом, да и актуальности не утерял, поскольку развитие стандарта в уже регулируемой им части заключается, в основном, в расширении классификаторов, атрибутности описания услуг и перевода рекомендуемых положений в статус обязательных.

С примерами составления файлов IS-XML можно ознакомиться, скачав архив, опубликованный по ссылке https://www.iata.org/services/finance/sis/Documents/ISPG/3.9.0.1/MISC-Invoice-Samples-3.9.0.1.zip

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

Файл IS-XML можно просмотреть несколькими способами, самый простой из которых – открыть его в Интернет-браузере. В этом случае будет хорошо просматриваться его структура, о которой говорилось выше:

InvoiceTransmission                <!-- собственно пакет -->
  TransmissionHeader                <!-- заголовок пакета -->
      TransmissionDateTime              <!-- момент формирования пакета -->
      Version                           <!-- номер версии стандарта -->
      TransmissionID                    <!-- идентификатор пакета -->
      IssuingOrganizationID             <!-- идентификатор отправителя -->
      ReceivingOrganizationID           <!-- идентификатор получателя -->
             …
  Invoice                           <!-- один из реестров оказанных услуг в пакете -->
      InvoiceHeader                     <!-- заголовок элемента -->
      LineItem                          <!-- один из видов услуг вместе с общим описанием -->
       …
      LineItem
      LineItemDetail                    <!-- описание одной из фактически оказанных услуг -->
       …
      LineItemDetail
      InvoiceSummary                    <!-- итоговая часть реестра -->
                LineItemCount                   <!-- количество видов оказанных услуг -->
                TotalLineItemAmount             <!-- общая стоимость оказанных услуг -->
                TotalVATAmount                  <!-- общий размер НДС по услугам в реестре -->
                TotalAmount                     <!-- общая сумма к оплате -->
  Invoice               <!-- следующий элемент пакета с аналогичной внутренней структурой -->
   …
  TransmissionSummary               <!-- итоговая часть пакета -->
     InvoiceCount                      <!-- общее количество реестров оказанных услуг по пакету -->
     TotalAmount CurrencyCode="RUB"    <!-- итоговая сумма (с учетом НДС) к оплате -->
     TotalVATAmount CurrencyCode="RUB" <!-- итоговый размер НДС -->

Элементы XML-структуры, которые содержат значения параметров, называются тегами и имеют вид:

<Имя_Тега_со_значением_параметра>Значение_параметра</Имя_Тега_со_значением_параметра>

а элементы, содержащие дочерние теги, называются нодами:

<Имя_Ноды>
                <Имя_тега_1>Значение_1</Имя_тега_1>
                …
                <Имя_тега_N>Значение_N</Имя_тега_N>
</Имя_Ноды>

Данные, описываемые нодой LineItem, включают, наряду с иными,  

Данные, описываемые нодой LineItemDetail, включают общую и специфичную для соответствующего вида услуг, описательные части

Следует отметить, что в файле IS-XML набор видов услуг LineItem должен предшествовать набору их детализаций LineItemDetail.

Ниже приводится перечень услуг, поддерживаемых стандартом IS-XML в наиболее актуальной версии. Для каждого элемента CHARGE CODE TYPE стандартом предусматривается те или иные наборы обязательных и опциональных атрибутов, позволяющих достаточно полно описать контекст оказанной услуги:

Замечание о возможности использования символов кириллицы
Ограниченная конечным перечнем тегов, содержимое которых может быть исполнено символами алфавита национальных языков (т.е. не латиницей), возможность использования русского языка появилась в описании стандарта IS-XML в версии 3.9.0.2. Однако на официальном сайте IATA на момент написания статьи опубликован файл "IS-XML Invoice Standard v3.9.0.1.zip". И лишь прочитав оглавление этого архива, можно обнаружить, что часть файлов описания имеют в своем названии номер версии 3.9.0.2.

3. Отечественная нормативная база и практика документирования операционных расходов авиакомпаний

Взаимоотношения поставщиков услуг, товарно-материальных ценностей и работ (далее услуг), обеспечивающих авиакомпаниям производство полетов на земле, регулируются Статьей 50. "Обслуживание воздушных судов на аэродромах и в аэропортах" Воздушного кодекса Российской федерации.

Проблематика номенклатуры услуг, оказываемых в интересах операционной деятельности авиакомпаний, тарифов и порядка исчисления стоимости их оказания, регулируется приказом Министерства транспорта Российской Федерации от 17 июля 2012 г. № 241 "Об аэронавигационных и аэропортовых сборах, тарифах за обслуживание воздушных судов в аэропортах и воздушном пространстве Российской Федерации" с изменениями и дополнениями от 1 ноября 2012 г., 22 июля 2013 г., 6 февраля 2017 г. Вопросы документирования услуг данным приказом не регулируются.

Порядок оформления и производства расчетов для взимания сборов, тарифов и цен за обслуживание воздушных судов эксплуатантов Российской Федерации изложен в пункте 1.3 Приказа Федеральной авиационной службы России от 11 октября 1996г. №71 "О совершенствовании системы аэропортовых сборов, тарифов и цен за наземное обслуживание воздушных судов эксплуатантов Российской Федерации" и соответствующего Приложения 3 "Порядок оформления и производства расчетов для взимания сборов, тарифов и цен за обслуживание воздушных судов эксплуатантов Российской Федерации в аэропортах Российской Федерации". Именно Приложением 3 предписывается использование акта по форме "С". Однако данный приказ не может считаться вступившим в силу и несущим правовые последствия по причине неисполнения в его отношении требований Правил подготовки нормативных правовых актов федеральных органов исполнительной власти и их государственной регистрации, утвержденных постановлением Правительства Российской Федерации от 13 августа 1997 г. № 1009, предусматривающих государственную регистрацию приказа в Министерстве Юстиции Российской Федерации и его официальное опубликование.

На практике требования исполнения акта по форме "С", который должен оформляться по факту встречи и/или подготовки к вылету, выполняются не в полной мере. Вместо большого количества документов поставщик представляет в авиакомпанию реестр оказанных услуг – сводный отчет за указанный период. Работать с реестром удобнее и поставщику, и заказчику, однако буква не имеющего юридических последствий приказа в этом случае не соблюдается.

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

Уже сегодня ряд поставщиков и авиакомпаний договорились  друг с другом о предоставлении электронных копий реестров оказанных услуг, что позволило значительно повысить оперативность. Существенная проблема при этом состоит в том, что  каждая пара "поставщик-авиакомпания" договаривается о собственном формате данных и механизме их передачи, и это позволяет образно говорить, что фундамент  отраслевой Вавилонской башни уже заложен.

4. Возможные причины, по которым IATA-SIS не нашла распространения в отечественной практике

Следует признать, что усилия IATA по продвижению своей платформы SIS на территории России успехом не увенчалась. Причин тому несколько.

Первая и, видимо, самая главная – недавние сложности с кириллицей. Попытка использования русского языка при работе с IATA SIS еще несколько месяцев назад была обречена на неудачу. Версия 3.9.0.2 , представленная осенью 2018г., содержит явное указание на используемую систему кодировки UTF-8, которая позволяет использовать символы кириллицы в описаниях, а также в ряде других текстовых тегов. Таким образом, это препятствие уже устранено в процессе развития стандарта.

Вторая причина – безальтернативные  принципы системы взаиморасчетов IATA и, в частности, непривычный для россиян платежный календарь Ассоциации. Платежи по альтернативным расписаниям в IATA SIS не предусмотрены, а параметры платежного календаря должны присутствовать в составе контента файлов IS-XML.

Третья причина – недостаточный опыт взаимодействия с IATA в плане развития ее IT-решений и стандартов. Крупные отечественные провайдеры наземного обслуживания используют настолько гибкие схемы ценообразования, что для того, чтобы указать для той или иной услуги набор параметров, исчерпывающе и однозначно определяющим стоимость услуги, может просто не хватить предусмотренных стандартом параметров. Автору не известны случаи, когда предложения по развитию стандарта IS-XML исходили бы от российских организаций, хотя применительно к родственному стандарту электронного взаимодействия - IATA FDSG (Fuel Data Standards Group ) -ситуация иная: рекомендация российской рабочей группы, в состав которой входили представители топливозаправочных организаций и авиакомпаний, были приняты к реализации.

5. Национальные особенности IS-XML

Основная национальная особенность– требование поддержки контента на русском языке. И хотя проблема использования кириллицы в описательных полях уже решена, об этом пока известно не всем.

Еще одна национальная особенность – потребность придания данным, передаваемым посредством IS-XML, юридической значимости. Пока речь идет о передаче-получении оперативных данных, вопрос юридической значимости не первостепенный: главное – быстро получить и сверить перечень оказанных услуг и их выставленную стоимость. В этом случае достаточно располагать доверенной средой формирования-передачи-приема-разбора в информационном пространстве, общем для поставщика и заказчика. Когда же речь идет о предоставлении первичных документов, а в российской практике электронного документооборота речь идет о документах УПД (универсальных передаточных документах), представляющих собой сущность, объединяющую акт выполненных работ и счет-фактуру, возникает настоятельная необходимость иметь еще один электронный документ: аналог бумажного реестра оказанных услуг за отчетный период. Файл IS-XML отвечает всем необходимым требованиям, предъявляемым к реестру: содержит сведения о заказчике и исполнителе, периоде оказания услуг, перечне видов оказанных услуг и совокупности услуг, фактически оказанных соответствующим объектам, для которых указаны свойства, влияющие на исчисление стоимости и налогооблагаемой базы, включая применяемые для этого скидки и наценки. Практика дополнения УПД файлом IS-XML позволит придать юридическую значимость последнему, поскольку, совокупность этих файлов, будучи передаваемой и принимаемой с помощью решений отечественных операторов ЭДО, скрепляется усиленными квалифицированными электронными подписями.

Наконец, есть еще одна особенность практики обмена данными посредством файлов IS-XML, вытекающая из концепции децентрализованного взаимодействия. Ничего не может помешать отправителю и получателю договориться между собой о том, что при формировании файла будут допущены отступления от действующего стандарта в части закрытого списка исключений. В частности, речь может идти как о дополнении контента тегами, не предусмотренными стандартом, или о нецелевом использовании тегов, которые стандартом предусмотрены, но будут использованы не в соответствии с их установленным стандартом предназначением. Однако путь этот очень опасен, ибо есть риск, что различные, а иногда взаимоисключающие отступления от стандарта, предложенные отдельными провайдерами и согласованные отдельными авиакомпаниями, сведут на нет весь положительный эффект от стандартизации: через какое-то время неуправляемого роста отступлений их объем превысит объем стандартных требований – и от стандарта не останется ничего, даже названия. При этом альтернативный путь не запрещен: необходимо принимать участие в развитии стандарта в соответствии с регламентами IATA. Да, результат будет достигнут гораздо медленнее, нежели самочинное отступление от стандарта по предварительному сговору между отправителем и получателем, но в не сразу достигнутом результате отечественная отрасль авиаперевозок будет разговаривать на едином языке, понятном и друг другу, и всему миру (с точностью до описаний видов услуг на русском языке, что при международных коммуникациях проблемой не является).

6. Пилотный проект по передаче-приему данных в формате IS-XML

В течение 2018г. UTG , оператор хендлингового обслуживания в столичном аэропорту "Внуково" и авиакомпания Utair, базирующаяся в этом аэропорту и пользующаяся широкой номенклатурой услуг UTG, осуществляют пилотный проект по внедрению технологий IS-XML:

• с июля 2018г. было налажено предоставление данных об оказанных услугах в формате IS-XML;
• с октября обмен данными был переведен на ежесуточную основу

Началу передачи данных в формате IS-XML предшествовал период, в течение которого технические специалисты UTG практиковались в составлении файлов, которые далее проходили валидацию на соответствие стандарту IATA SIS с использованием интернет-сервисов Ассоциации, а технические специалисты Utair разрабатывали решение, позволяющее производить разбор файлов, устанавливать однозначное соответствие между сущностями, описанными в обменных файлах и сущностями, которыми оперирует Revenue Accounting System (RAS) авиакомпании и осуществлять импорт поступающих данных в RAS.

7. Методические рекомендации по созданию файлов стандарта IS-XML

7.1 Соответствие контента версии стандарта

Содержимое файла IS-XML должно соответствовать одной из версий этого стандарта – актуальной или одной из более ранних. При этом в составе файла предусмотрены теги, декларирующие номер версии стандарта, в соответствии с которой сформированы содержательные данные. Декларации содержатся в самом начале IS-XML файла, в тегах InvoiceTransmission и Version:

…
<InvoiceTransmission xmlns="http://www.IATA.com/IATAAviationInvoiceStandard"
xsi:schemaLocation="http://www.IATA.com/IATAAviationInvoiceStandard
file:///C:/Projects/SQLUpdate2018/IS-XM/IS-
XML%20Record%20Structure/IATA_IS_XML_Invoice_Standard_V3.8.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
…
                <TransmissionHeader>
                               …
                               <Version>IATA:ISXMLInvoiceV3.8</Version>
                               …
                </TransmissionHeader>

Значение тега Version указывает на номер версии стандарта, в соответствии с которой сформировано содержимое файла. Эта же версия стандарта (в данном случае V3.8) должна быть указана в свойстве xsi:schemaLocation  тега InvoiceTransmission.

7.2 Наименование файла

Имя файла IS XML применительно к области формирования счетов к оплате за поставленные ТМЦ / оказанные услуги согласно стандарту IS-XML должно иметь следующий вид:

MXMLF-cccyyyymmppYYYYMMDDHHMMSS.xml

где

ccc – IATA-код поставщика услуги;

yyyy, mm, pp – год, месяц и период выставления инвойса соответственно; период выставления инвойса исчисляется по календарю платежей IATA (тип календаря IS and ICH). Календарь представляет собой таблицу, с помощью которой для каждого месяца заданного года определяется соответствующий период. Например, если документ сформирован за отчетный период с 25 января по 10 февраля 2018 г., месяц выставления инвойса 02, а номер периода, определенный по календарю платежей – 01.

YYYY, MM, DD, HH, MM, SS – год, месяц, дата, час, минута, секунда создания файла.

При этом элемент имени файла, указывающий момент времени его формирования не должен противоречить значениям тега TransmissionDateTime, а элемент имени файла, определяющий код поставщика не должен противоречить значениям тега IssuingOrganizationID

Т.о., имя файла

MXMLF-2982018060320180706122328.xml

говорит о том, что он был сформирован поставщиком Utair (его код 298), за 3-й отчетный период июня 2018 г. (с 22 июня 04:00 UTC по 28 июня 21:00 UTC), а сам файл был сформирован 6 июля 2018 г. в 12:23:28.

Содержимое родительской для TransmissionDateTime  ноды TransmissionHeader, присутствующей в данном файле, приводится ниже:

                <TransmissionHeader>
                            <TransmissionDateTime>2018-07-06T12:23:28</TransmissionDateTime>
                            <Version>IATA:ISXMLInvoiceV3.8</Version>
                            <TransmissionID>fdc685d9-d2ae-4b6b-9034-98ba5067323f</TransmissionID>
                            <IssuingOrganizationID>298</IssuingOrganizationID>
                            <BillingCategory>Miscellaneous</BillingCategory>
                </TransmissionHeader>

Отметим, что TransmissionDateTime и IssuingOrganizationID должны быть согласованы с соответствующими позициями в имени файла.

Значение тега TransmissionID является уникальным и однозначно определяет пакет данных, содержащийся в файле. 

Наконец, в качестве значения тега BillingCategory следует указать Miscellaneous. Это общее требование для инвойсов, выставленных за оказание услуг / выполнение работ.

7.3 Сведения о реестре услуг и сторонах договорных отношений

Стандартом предусмотрен целый ряд тегов, описывающих сведения об участниках договорных отношений – поставщика и заказчика – и о реестре оказанных услуг в целом. Такие свойства реестра, как номер, дата, тип документа, предметная область оказания услуг  указываются в тегах InvoiceNumber , InvoiceDate, InvoiceType,  ChargeCategory  ноды InvoiceHeader:

                <Invoice>
                                 <InvoiceHeader>
                                                <InvoiceNumber>UTG01</InvoiceNumber>
                                                <InvoiceDate>2018-03-01</InvoiceDate>
                                                <InvoiceType>Invoice</InvoiceType>
                                                <ChargeCategory>Ground Handling</ChargeCategory>
                                                …
                                                <SellerOrganization>
                                                …
                                                </SellerOrganization>
                                                <BuyerOrganization>
                                                …
                                                </BuyerOrganization>
                                 </InvoiceHeader>
                                 …
                </Invoice>

Для идентификации сторон поставщика и заказчика предусмотрен два способа их идентификации: с использованием кода и без его использования. В первом случае для указания соответствующего участника отношений указывается единственный параметр код участника проекта IATA SIS; т.о., если одной из участвующих в отношениях сторон является авиакомпания-член IATA, для ее идентификации достаточно указать ее код в теге OrganizationID ; поставщики услуг или ТМЦ, работающие на платформе IATA SIS, имеют аналогичные коды. Если оба участника отношений зарегистрированы в iATA, раздел описания договорных сторон может выглядеть следующим образом:

                     <SellerOrganization>
                             <OrganizationID> A89</OrganizationID>
                     </SellerOrganization>
                     <BuyerOrganization>
                             <OrganizationID>298 </OrganizationID>
                     </BuyerOrganization>

Альтернативой является идентификация сторон с использованием набора свойств. Например, если одна из сторон зарегистрирована в IATA, а другая нет, раздел описания договорных сторон может выглядеть так:

                     <SellerOrganization>
                              <LocationID>VKO</LocationID>
                              <OrganizationName1>Название организации</OrganizationName1>
                              <OrganizationName2> Название (продолжение)</OrganizationName2>
                              <TaxRegistrationID>ИНН</TaxRegistrationID>
                              <AdditionalTaxRegistrationID>КПП</AdditionalTaxRegistrationID>
                              <CompanyRegistrationID>ЕГРЮЛ</CompanyRegistrationID>
                              <ContactName>ФИО</ContactName>
                              <ContactDetails>
                                      <ContactType>Telephone</ContactType>
                                      <ContactValue>+71234567890</ContactValue>
                              </ContactDetails>
                              <ContactDetails>
                                      <ContactType> Email</ContactType>
                                      <ContactValue>a@bcd.ef</ContactValue>
                              </ContactDetails>
                              <Address>
                                      <AddressLine1>Адрес</AddressLine1>
                                      <AddressLine2> Адрес -продолжение</AddressLine2>
                                      <AddressLine3> Адрес -окончание</AddressLine3>
                                      <CityName>Москва</CityName>
                                      <CountryCode>RU</CountryCode>
                                      <CountryName>Russia</CountryName>
                                      <PostalCode>123456</PostalCode>
                               </Address>
                     </SellerOrganization>
                     <BuyerOrganization>
                               <OrganizationID>298 </OrganizationID>
                     </BuyerOrganization>

7.4 Виды услуг, записи об их оказании, итоговые значения

Внутри раздела Invoice после заголовочной и перед итоговыми элементами должны следовать сначала все теги-описатели видов услуг  LineItem, затем все теги детализаций работ/услуг соответствующих видов LineItemDetail. При этом теги строки, содержащие стоимостное выражение указываемой работы или услуги, должны быть согласованными со сведениями, изложенными в детализации:

<InvoiceTransmission … >
     <TransmissionHeader>
     …
     </TransmissionHeader>
     <Invoice>
          <InvoiceHeader>
          …
          </InvoiceHeader>
          <LineItem>
               <LineItemNumber>1</LineItemNumber>
               <ChargeCode>Ramp Handling</ChargeCode>
               <Description>Буксировка (Towing)</Description>
               …
               <Quantity UOMCode="EA">587</Quantity>
               <UnitPrice SF="1">920</UnitPrice>
               <ChargeAmount>540040.00</ChargeAmount>
               <TotalVATAmount>108008.00</TotalVATAmount>
               <TotalNetAmount>648048.00</TotalNetAmount>
               <DetailCount>587</DetailCount>
          …
          </LineItem>
          <LineItem>
               <LineItemNumber>2</LineItemNumber>
               …
          </LineItem>
          …
          </LineItem>
          …
          <LineItemDetail>
               <DetailNumber>1</DetailNumber>
               <LineItemNumber>1</LineItemNumber>
               <Description>Буксировка ВС </Description>
               …
               <Quantity UOMCode="EA">1</Quantity>
               <UnitPrice SF="1">920</UnitPrice>
               <ChargeAmount>920</ChargeAmount>
               …
          </LineItemDetail>
          <LineItemDetail>
               <DetailNumber>2</DetailNumber>
               <LineItemNumber>1</LineItemNumber>
               …
          </LineItemDetail>
          …
          <LineItemDetail>
               <DetailNumber>1</DetailNumber>
               <LineItemNumber>2</LineItemNumber>
               …
          </LineItemDetail>
          …
          <InvoiceSummary>
               <LineItemCount>68</LineItemCount>
               <TotalLineItemAmount>29564235.70</TotalLineItemAmount>
               <TotalVATAmount>5912847.140</TotalVATAmount>
               <TotalAmount>35477082.840</TotalAmount>
          </InvoiceSummary>
     </Invoice>
     <TransmissionSummary>
          <InvoiceCount>1</InvoiceCount>
          <TotalAmount CurrencyCode="RUB">35477082.840</TotalAmount>
          <TotalVATAmount CurrencyCode="RUB">5912847.140</TotalVATAmount>
     </TransmissionSummary>
</InvoiceTransmission>

Как можно заметить, для каждой строки LineItem, содержащей общую информацию для данного вида услуги, тег DetailCount содержит количество записей LineItemDetail о каждом факте ее оказания. В свою очередь, каждая запись о факте оказания услуги LineItemDetail помимо порядкового номера DetailNumber содержит ссылку LineItemNumber на соответствующий вид услуги LineItem.

Сведения об оказанных услугах в денежном выражении приводятся в тегах ChargeAmount (стоимость без налогов) и TotalNetAmount (общая стоимость, включая налоги, скидки и наценки).  Сумма ChargeAmount по LineItemDetail для заданного LineItem должна совпадать с ChargeAmount, указанному в данном LineItem.

Итоговая часть  InvoiceSummary  ноды Invoice содержит общее количество видов услуг LineItemCount, указанных в Invoice выше, их стоимость без учета НДС TotalLineItemAmount, суммарный для данного Invoice НДС TotalVATAmount (если таковой начисляется) и общую сумму TotalAmount, включающую НДС.

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

Для определения стоимости, если не оговорено иное, о чем речь пойдет ниже, используются данные тега Quantity (количество) с его атрибутом  UOMCode (единица измерения) и UnitPrice (цена)  с атрибутом SF (за какое количество указан ценник).

7.5 Непропорциональное ценообразование

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

На практике в целом ряде случаев правила ценообразования более разнообразны (первый час обслуживания по одной цене, последующее время – по другой и т.п.). При попытке валидации посредством сервисов IATA файлов, в которых указанная в теге ChargeAmount стоимость не равна произведению цены на количество, будет получена ошибка. Тем не менее, возможность указания в файле IS-XML стоимости, определяемой иначе, нежели произведение цены на количество, есть. Для этого следует добавить тег MinimumQuantityFlag со значением Y:

<LineItem>
          <LineItemNumber>4</LineItemNumber>
          <ChargeCode>Ramp Handling</ChargeCode>
          <Description>Towing</Description>
          …
          <MinimumQuantityFlag>Y</MinimumQuantityFlag>
          <Quantity UOMCode="EA">477</Quantity>
          <UnitPrice SF="1">4187</UnitPrice>
          <ChargeAmount>2100500.00</ChargeAmount>
          <TotalNetAmount>2100500.00</TotalNetAmount>
          <DetailCount>475</DetailCount>
</LineItem>

При его наличии факт расхождения значений стоимости и произведения количества на цену в процессе IATA-валидации файла IS-XML будет игнорироваться.

7.6 Начало и окончание предоставления услуги

Для ноды LineItem, идентифицирующей результат оказания услуг заданного вида, предусмотрены элементы StartDate и EndDate

<LineItem>
             <LineItemNumber>68</LineItemNumber>
             <ChargeCode>Ramp Handling</ChargeCode>
             <Description>Aircraft Fueling</Description>
             <StartDate>2018-06-22</StartDate>
             <EndDate>2018-06-29</EndDate>
             …
             <DetailCount>23</DetailCount>
</LineItem>

Тег EndDate, определяющий время завершения оказания конкретной услуги, запись о которой образует LineItemDetail,  в схеме документа IS-XML указан как необязательный. Однако попытка IATA-валидации файлов, в которых он опущен, приводит к сообщению об ошибке. Дело в не очень заметной формулировке из описания стандарта, говорящей о том, что нормативные требования некоторых стран, резидентами которых являются поставщики и заказчики IATA, однозначно регламентируют наличие записи о дате окончания услуг – и проверка соблюдения данного требования выполняется для всех участников платформы IATA SIS. Ну что же, добавить дату окончания предоставления услуги технических сложностей не представляет;  с учетом этой оговорки фрагмент файла с тегом EndDate будет выглядеть так:

        <EndDate>2018-06-23</EndDate>

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

Тонкость заключается в том, что тип данных для тега EndDate (и для других атрибутов, предназначенных для указания даты-времени), заложенный в схему документа IS-XML, требует обязательного указания даты и необязательного – времени. Мы не делаем синтаксической ошибки, указывая только дату, но можем сделать ошибку семантическую: что значит указать дату завершения оказания услуги 1 апреля 2018 года: 2018-04-01 ? По правилам умолчания для переменных данного типа не указанное явным образом время будет дополнено нулями в части часов, минут и секунд: 2018-04-01  = 2018-04-01 00:00:00. И если в качестве даты начала оказания услуг, как это в большинстве случаев и бывает, значится та же дата 2018-04-01, то их сопоставление приводит к выводу, что момент окончания предоставления услуги не следует за моментом начала их предоставления – о чем соответствующая ошибка и проинформирует составителя файла. Избежать подобной ситуации позволит либо честное указание времени завершения оказания услуги, либо следующий прием: вместо "только даты" в качестве момента окончания предоставления услуги следует указать последнюю секунду суток этой даты. Итак, корректно сформированный тег EndDate должен иметь следующий вид:

        <EndDate>2018-06-23T23:59:59</EndDate>

7.7 Наценки и скидки

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

К одной записи об оказанной услуге (виду услуги, реестру услуг в целом) может быть одновременно применено несколько видов наценок и/или скидок. Для каждого вида наценок и/или скидок следует применять соответствующие описатели, оформляемые посредством ноды AddOnCharges. В ее составе предусмотрено несколько дочерних тегов: AddOnChargeName (наименование наценки), AddOnChargePercentage (процентная ставка наценки),  AddOnChargeableAmount (сумма, на которую распространяется действие наценки),  AddOnChargeAmount (собственно объем наценки).

Если наценки и/или скидки применяются к конкретной услуге, на уровне записи о факте ее оказания LineItemDetail располагаются ноды AddOnCharges, на уровне описания вида услуги LineItem располагается тег TotalAddOnChargeAmount с суммарным значением AddOnChargeAmount по всем записям об оказании данной услуги, а на уровне InvoiceSummary реестра в целом располагается тег TotalAddOnChargeAmount с суммарным значением всех наценок и скидок, применявшихся в данном реестре.

Если наценки и/или скидки применяются к услуге данного вида, ноды AddOnCharges располагаются на уровне LineItem, за ними следует тег TotalAddOnChargeAmount с итоговым значением наценки-скидки; на уровне InvoiceSummary также присутствует тег TotalAddOnChargeAmount – с итоговым значением наценки-скидки по реестру в целом.

Если наценки и/или скидки применяются ко всему реестру в целом, нода AddOnCharges располагается на уровне InvoiceSummary, а тег TotalAddOnChargeAmount  следует за ней.

Ниже приводится пример применения двух наценок к фактически оказанной услуге и одной скидке к реестру в целом:

…
<LineItem>
          …
          <LineItemNumber>2</LineItemNumber>
          <ChargeAmount>16993.60</ChargeAmount>
          <TotalAddOnChargeAmount>18692.960</TotalAddOnChargeAmount>
          <TotalNetAmount>35686.560</TotalNetAmount>
          <DetailCount>1</DetailCount>
</LineItem>
…
<LineItemDetail>
          <DetailNumber>1</DetailNumber>
          <LineItemNumber>2</LineItemNumber>
          <ChargeAmount>16993.60</ChargeAmount>
          …
          <AddOnCharges>
                    <AddOnChargeName>Обслуживание при низких температурах</AddOnChargeName>
                    <AddOnChargePercentage>20</AddOnChargePercentage>
                    <AddOnChargeableAmount>16993.60</AddOnChargeableAmount>
                    <AddOnChargeAmount>3398.720</AddOnChargeAmount>
          </AddOnCharges>
          <AddOnCharges>
                    <AddOnChargeName>Срочность</AddOnChargeName>
                    <AddOnChargePercentage>90</AddOnChargePercentage>
                    <AddOnChargeableAmount>16993.60</AddOnChargeableAmount>
                    <AddOnChargeAmount>15294.240</AddOnChargeAmount>
          </AddOnCharges>
          <TotalNetAmount>35686.560</TotalNetAmount>
</LineItemDetail>
…
<InvoiceSummary>
          <LineItemCount>6</LineItemCount>
          <TotalLineItemAmount>697119.920</TotalLineItemAmount>
          <AddOnCharges>
                    <AddOnChargeName>Эксклюзиваня скидка </AddOnChargeName>
                    <AddOnChargeableAmount>697119.920</AddOnChargeableAmount>
                    <AddOnChargeAmount>-50000.00</AddOnChargeAmount>
          </AddOnCharges>          
          <TotalAddOnChargeAmount>-31307.040</TotalAddOnChargeAmount>
          <TotalVATAmount>100143.000</TotalVATAmount> 
          <TotalAmount>765955.880</TotalAmount> 
</InvoiceSummary>

Порядок следования тегов:

• на уровне LineItemDetail – ChargeAmount, Tax, TotalNetAmount;
• на уровне LineItemDetail – ChargeAmount, TotalVATAmount, TotalNetAmount;
• на уровне InvoiceSummary – TotalLineItemAmount, (AddOnCharges), TotalAddOnChargeAmount.

7.8 Указание НДС

Для указания данных об НДС стандарт IS-XML предписывает использование ноды <Tax> . При этом НДС не запрещено указывать как на уровне детализации услуги заданного вида, так и непосредственно в ноде, описывающей вид услуги. Тем не менее, рекомендуется указывать сведения о параметрах исчисления НДС на уровне детализации – это сделает электронный документ более прозрачным:

…
<LineItem>
         <LineItemNumber>68</LineItemNumber>
         <ChargeCode>Ramp Handling</ChargeCode>
         <Description>Заправка водой</Description>
         …
         <ChargeAmount>3183.12</ChargeAmount>
         <TotalVATAmount>636.624</TotalVATAmount>
         <TotalNetAmount>3819.744</TotalNetAmount>
         <DetailCount>23</DetailCount>
</LineItem>
…
<LineItemDetail>
         …
         <LineItemNumber>4</LineItemNumber>
         …
         <ChargeAmount>123.45</ChargeAmount>
         <Tax>
               <TaxType>VAT</TaxType>
               <TaxSubType>VAT</TaxSubType>
               <TaxCategory>Standard</TaxCategory>
               <TaxText>НДС 20%</TaxText>
               <TaxPercent>20</TaxPercent>
               <TaxableAmount>123.45</TaxableAmount>
               <TaxAmount>24.690</TaxAmount>
         </Tax>
         <TotalNetAmount>148.140</TotalNetAmount>
         …

В качестве значение тегов TaxType и TaxSubType следует указывать VAT.

Значениями тега TaxCategory следует указывать Zero (НДС не облагается), Standard (стандартная ставка НДС 20%), Lower (льготная ставка 10%); TaxText содержит произвольное описание налогообложения. В тегах TaxPercent,  TaxableAmount, TaxAmount  указываются ставка НДС, облагаемая база, значение НДС соответственно.

Располагаться нода Tax должна внутри ноды LineItemDetail между тегами  ChargeAmount и TotalNetAmount. Для необлагаемых НДС услуг нода Tax не указывается.

Внутри ноды LineItem перед тегом DetailCount  должны располагаться теги ChargeAmount, TotalVATAmount, TotalNetAmount.

Внутри ноды InvoiceSummary теги TotalLineItemAmount, (AddOnCharges), TotalAddOnChargeAmount, TotalVATAmount, TotalAmount должны располагаться в указанном порядке.

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

Замечание о точности указания величин, исчисляемых с помощью операции умножения
Желательно, чтобы результат выполнения операции умножения был представлен с точностью, на один разряд превышающей исходное значение; применительно к НДС для налогооблагаемой базы, указанной с точностью до сотых долей денежной единицы, сумму НДС следует указывать с тремя знаками. Это в дальнейшем исключит возникновение ошибок округления.

7.9 Возвраты

Достаточно важная возможность, предоставляемая IS-XML, касается либо запросов на возврат средств, исходящих от заказчика, либо пояснений по формированию стоимости услуги, указанной в файле, связанных с указанием объема и стоимости не оказанных услуг. В этом случае тег InvoiceType должен содержать значение CreditNote:

…
<Invoice>
         <InvoiceHeader>
                       <InvoiceNumber>SF0001</InvoiceNumber>
                       <InvoiceDate>2017-07-30</InvoiceDate>
                       <InvoiceType>CreditNote</InvoiceType>
                       <ChargeCategory>Ground Handling</ChargeCategory>
         </InvoiceHeader>
         …
</Invoice>
…

Кроме того, значения тегов, отвечающих за описание стоимостных параметров (ChargeAmount, TotalVATAmount, TotalNetAmount, TaxAmount и др.), должны быть указаны с отрицательным знаком.

Если в составе файла IS-XML будут присутствовать несколько инвойсов (InvoiceType=Invoice) и кредит-нот (InvoiceType=CreditNote), значения заключительных тегов TotalAmount  и TotalVATAmount будут формироваться как разность сумм по реестрам типа "инвойс" и "кредит-нота", поскольку суммы по кредит-нотам имеют отрицательный знак.

7.10 Параметры, влияющие на определение стоимости

Стандарт IS-XML обладает достаточной гибкостью, позволяющей обеспечить полноту представления данных, на основании которых осуществляется ценообразование. Поскольку номенклатура услуг широка, а обслуживаемые объекты различны, для каждого элемента классификации ChargeCode ChargeCodeType предусмотрены отдельные наборы обязательных и необязательных атрибутов. Приведем несколько примеров указания параметров, обосновывающих определение стоимости оказанной услуги.

Услуга по выполнению протовооблединительной обработки самолета ATR-72, регистрационный номер  VQ-BMD, вылетавшего рейсом UT163 в 04:10 24 октября 2017г., в соответствии с договором  Z7013:

…
<LineItem>
         <LineItemNumber>1</LineItemNumber>
         <ChargeCode>Deicing</ChargeCode>
         <ChargeCodeType>De-Icing - Fixed</ChargeCodeType>
         …
</LineItem>
…
<LineItemDetail>
         <DetailNumber>1</DetailNumber>
         <LineItemNumber>1</LineItemNumber>
         <Description>Антиобледенительная обработка</Description>
         <ProductID>DeiceProc-ATR72-500</ProductID>
         …
         <TotalNetAmount>100500.00</TotalNetAmount>
         <ContractNo>Z7013</ContractNo>
         <AircraftDetails>
                          <AircraftRegistrationNo>VQBMD</AircraftRegistrationNo>
                          <AircraftTypeCode>AT7</AircraftTypeCode>
         </AircraftDetails>
         <FlightDetails>
                          <FlightNo>UT163</FlightNo>
                          <FlightDateTime>2017-10-24T04:10:00</FlightDateTime>
         </FlightDetails>
</LineItemDetail>

Предоставление питания экипажу воздушного судна

<LineItemDetail>
         …
         <TotalNetAmount>3816.19</TotalNetAmount>
         <ContractNo>Z7014</ContractNo>
         <ReferenceNo Name="Meals">Count</ReferenceNo>
         <FlightDetails>
                        <FlightNo>UT807</FlightNo>
                        <FlightDateTime>2017-06-26T00:00:00</FlightDateTime>
         </FlightDetails>
         <RouteDetails>
                        <LocationCode Type="Origin">VKO</LocationCode>
                        <RouteDateTime Type="Entry">2017-06-26T00:00:00</RouteDateTime>
         </RouteDetails>
         <CateringDetails>
                        <MealType Name="Crew">Lunch</MealType>
…
<LineItemDetail>
        …
        <TotalNetAmount>100500.00</TotalNetAmount>
        <ContractNo>Z7014</ContractNo>
        <ReferenceNo Name="Meals">Count</ReferenceNo>
        <FlightDetails>
                       <FlightNo>UT807</FlightNo>
                       <FlightDateTime>2017-06-26T00:00:00</FlightDateTime>
        </FlightDetails>
        <RouteDetails>
                       <LocationCode Type="Origin">VKO</LocationCode>
                       <RouteDateTime Type="Entry">2017-06-26T00:00:00</RouteDateTime>
        </RouteDetails>
        <CateringDetails>
                       <MealType Name="Crew">Lunch</MealType>
                       <InvoiceOpCode>00</InvoiceOpCode> <!-- Routine Scheduled Service -->
                       <Facility>SKY FOOD VNUKOVO</Facility>
                       <MealCode>Set1</MealCode> <!-- Meal code as required by the airline -->
        </CateringDetails>
</LineItemDetail>

7.11 Примеры документирования отдельных услуг

Аэропорт, оперирующих несколькими перронами, оказывает услуги по антиобледенительной обработке ВС ATR72-500 на стоянке 17 перрона Z, при этом, в соответствии с договором Z7014, за обработку ВС, находящегося на перроне Z, выставляется наценка 10%.

…
<LineItemDetail>
     <DetailNumber>1</DetailNumber>
     <LineItemNumber>1</LineItemNumber>
     <Description>Deicing procedure</Description>
     <ProductID>DeiceProc-ATR72-500</ProductID>
     <EndDate>2017-10-24T23:59:59</EndDate>      <!-- Mandatory due to the legislation -->
     <Quantity UOMCode="EA">1</Quantity>
     <UnitPrice SF="1">5000.00</UnitPrice>
     <ChargeAmount>5500.00</ChargeAmount>
     <AddOnCharges>
              <AddOnChargeName>Надбавка за обслуживание на перроне Z</AddOnChargeName>
              <AddOnChargePercentage>10</AddOnChargePercentage>
              <AddOnChargeableAmount>5000.00</AddOnChargeableAmount>
              <AddOnChargeAmount>500.000</AddOnChargeAmount>
     </AddOnCharges>
     <TotalNetAmount>5500.00</TotalNetAmount>
     <ContractNo>Z7014</ContractNo>
     <AircraftDetails>
              <AircraftRegistrationNo>VQBMD</AircraftRegistrationNo>
              <AircraftTypeCode>AT7</AircraftTypeCode>
     </AircraftDetails>
     <FlightDetails>
              <FlightNo>UT163</FlightNo>
              <FlightDateTime>2017-10-24T04:11:18</FlightDateTime>
     </FlightDetails>
     <ParkingDetails>
              <StandNo>17</StandNo>
              <StandType>Apron</StandType>          <!-- Dictionary defined -->
              <OnStandDateTime>2017-10-24T00:50:00</OnStandDateTime>
              <OffStandDateTime>2017-10-24T04:15:00</OffStandDateTime>
     </ParkingDetails>
</LineItemDetail>
…

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

Допустим, что в одной из авиакомпаний имеется традиция: командир лично преподносит букет цветов чете молодоженов, отправляющихся данным рейсом в свадебное путешествие. Букет предоставляется наземными службами, а за эту услугу выставляется счет. Потребуется ли, внедрив IS-XML, нарушить сложившуюся традицию, если в классификаторах услуг нет позиции Marriage Gift?

Попробуем разобраться. Объектом предоставления подобной услуги являются поименованная пара пассажиров на известном рейсе, вылетающим в указанную дату. Не напоминает ли это предоставление бортпитания в соответствии с предварительным заказом? Разница лишь в том, что еду заказывает себе сам пассажир, а заказ на букет разместит авиакомпания. А раз так, то в IS-XML файле будет нечто подобное:

…
<LineItemDetail>
      …
      <FlightDetails>
                    <FlightNo>UT807</FlightNo>
                    <FlightDateTime>2017-06-26T00:00:00</FlightDateTime>
      </FlightDetails>
      <PassengerDetails>
                    <PassengerName>BrideName</PassengerName>
                    <TicketNo>1234567890123</TicketNo>
      </PassengerDetails>
      <CateringDetails>
                    <MealType Name="MarriageGift">BouquetOfFlowers</MealType>
                    <InvoiceOpCode>52</InvoiceOpCode>  <!-- Facility Additional Charges -->
                    <Facility>SKY FLOWERS INC.</Facility>
                    <MealCode>NewweddiesBouquetOfFlowers</MealCode>
      </CateringDetails>
      …
</LineItemDetail>

8. Если нельзя, но очень хочется…

Оговоримся сразу, что отступать от стандарта допустимо лишь в случае, когда предельно ясны причины и возможные последствия. Понимание и того, и другого приходит только после погружения в допущения, требования и ограничения стандарта. Лишь будучи твердо уверенным в том, что никакими иными способами в IS-XML файл нельзя записать то, что требует практика взаимоотношений между заказчиками и потребителями, можно поступиться теми или иными положениями стандарта. А подобная уверенность приходит с практикой; следовательно, отступления от стандарта это явно не то, что находится в самом начале пути.

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

8.1 Отход от заданных периодов выставления документов

Привязка правил формирования имени файла IS-XML к периодизации по календарю IATA становится необязательной, если транспорт этого файла осуществляется по каналам, отличным от используемых на платформе IATA SIS. Следовательно, ничего не мешает отойти от подхода IATA к указанию в имени файла периода оказанных услуг и ассоциировать с периодом оказания услуг дату последней по времени услуги, фигурирующей в файле:

MXMLF-cccyyyymmppYYYYMMDDHHMMSS.xml

Т.е. в качестве значения pp в спецификации имени файла указывать не период платежного календаря IATA, а день месяца, определяемого значением mm, когда была оказана последняя упомянутая в файле услуга.

8.2 Указание поставщика и заказчика

Поскольку предполагается, что движение файлов IS-XML между поставщиком и заказчиком будет осуществляться по децентрализованной схеме, а к моменту отправки первого файла IS-XML обе стороны не могут не являться субъектами договорных отношений, указание учетных атрибутов поставщика и заказчика (наименование, адрес и .т.п.) не имеет смысла, а для идентификации сторон достаточно указания соответствующих кодов, согласованных обеими сторонами. Ровно такой практики придерживается и IATA, однако в нашем случае коды могут быть произвольными, хотя, при наличии у хотя бы одной стороны кода IATA настоятельно рекомендовалось бы использовать для идентификации именно этот код. Т.о., раздел описания контрагентов мог бы выглядеть так:

<SellerOrganization>
                  <OrganizationID>SF</OrganizationID>
</SellerOrganization>
<BuyerOrganization>
                  <OrganizationID>298</OrganizationID>
</BuyerOrganization>

где SF является кодом поставщика, не имеющего аккредитации в IATA, но согласованным в договорных документах поставщика и заказчика в качестве кода идентификации. При этом для идентификации заказчика используется код IATA, что также следует отразить в договорных документах.

9. Придание электронным документам IS-XML юридической значимости

Вопрос юридической значимости электронного документа, которым является файл стандарта IS-XML, возникает в случае, когда взаимоотношения заказчика и поставщика становятся предметом интереса налоговых органов или независимых аудиторов. Если акты оказанных услуг и, когда хотя бы по части этих услуг начисляется НДС, счета-фактуры поставщик предоставляет в электронном виде, проверяющий вправе запросить данные  из реестра оказанных услуг также в электронном виде. И указанные данные в формате IS-XML проверяемая сторона готова предоставить, однако сегодня этим дело и ограничится. Ограничится по двум причинам. Главная – отсутствие гарантий достоверности и неизменности представленных составителем файла IS-XML данных. И хотя стандарт IS-XML работу с электронной подписью поддерживает, данная функция на территории России может быть задействована только с существенными оговорками, поскольку электронная подпись от IATA не удовлетворяет требованиям федерального законодательства (закон от 06.04.11 № 63-ФЗ "Об электронной подписи"), а оборот электронных документов, представляемых в ФНС в связи с исчислением налога на добавленную стоимость, предполагает использование усиленных квалифицированных электронных подписей. Однако возможность скрепления файла IS-XML усиленной квалифицированной электронной подписью, использование которой предписывается налоговыми органами и дает весомые преимущества в хозяйственных спорах, есть. В отечественной практике юридически значимый электронный документооборот осуществляется посредством уполномоченных операторов ЭДО. Поток юридически значимых электронных документов осуществляется по маршруту "поставщик (ЭД с подписью отправителя)" - "оператор ЭДО" - "заказчик (подписание ЭД на стороне получателя)" - "оператор ЭДО" -"поставщик (ЭД с подписями отправителя и получателя)". Электронные документы, вообще говоря, представляют собой не единичные сущности, а наборы из более, чем одного документа. В составе пакета, как правило, присутствуют формализованные электронные документы, исполненные в предписанном нормативными актами формате, и неформализованные электронные документы. В данном случае акцент следует сделать на том, что и формализованные ЭД и неформализованные ЭД скреплены УКЭП и, следовательно, имеют неоспоримую юридическую значимость. В качестве неформализованных документов, как правило, циркулируют сканированные копии бумажных документов или созданные компьютерным способом файлы формата PDF. Но ничего не мешает вместо распечатанного и отсканированного реестра оказанных услуг вложить в пакет с универсальным передаточным документом (аналогом акта оказанных услуг и счета-фактуры) файл IS-XML, содержащим детализацию оказанных услуг с точностью, обеспечивающей обоснование принятия к учету соответствующих сумм, указанных в УПД.

Итак, первая проблема решена и в распоряжении хозяйствующих субъектов имеются юридически значимые XML-файлы. Теперь приходит очередь решения другой проблемы: каким образом проверяющий сможет удостовериться, что информация в реестре оказанных услуг (т.е. в XML-файле) не противоречит первичным документам, а начисление НДС обосновано? Вариант собственноручного открытия проверяющим XML-файла, поиск и анализ интересующих его тегов, естественно, отметаем сразу. Следовательно, необходима еще и визуализация электронного документа, с которой человеку работать удобнее, чем с ориентированным на машиночитаемость исходным электронным документом. Способов получения визуализации два: либо изначально параллельно с XML-файлом создавать соответствующий человекочитаемый файл, например, в формате PDF, и работать с парой файлов – один для компьютерной обработки, другой для ознакомления человека, либо написать программу, которая в состоянии открыть XML-файл электронного документа и отобразить на экране компьютера или вывести на принтер его содержание в удобном для человека виде. Поскольку мы предполагаем, что для придания юридически значимого статуса файлам IS-XML они передаются посредством операторов ЭДО, резонно поинтересоваться, как решена проблема визуализации для формализованных ЭД, циркулирующих через операторов. А решена она у операторов ЭДО по первому варианту – путем создания PDF-копии, юридическая значимость которой обеспечивается указанными операторами. Следовательно, включение файла формата IS-XML в список формализованных электронных документов позволит в процессе их оборота, помимо машиночитаемости и юридической значимости, воспользоваться и юридически значимой человекочитаемой формой представления данных.

Подведем первые итоги.

• Вкладывать IS-XML файлы рядом с УПД клиенты операторов  ЭДО могут уже сейчас без всяких ограничений – был бы IS-XML файл.
• Наилучший способ получения визуализации ЭД – вовлечение в проект операторов ЭДО, для которых создание визуализации уже разработанного и апробированного ЭД в формате XML – несложная техническая задача из разряда тех, которые им приходится решать не раз и не два.

Кажется, задача ЮЗЭДО в такой конфигурации будет полностью решена: обеспечены машиночитаемость, человекочитаемость, юридическая значимость и, естественно, практически мгновенная гарантированная доставка.

…Что-то не так? Увы. Коснемся вопроса гарантированной доставки. Если стороны, между которыми осуществляется оборот ЭД, являются клиентами одного и того же оператора ЭДО, который включил в состав поддерживаемых им формализованных ЭД файлы, исполненные в стандарте IS-XML, и разработал для них PDF-визуализацию, то беспокоиться не о чем. А если поставщик услуги уже является клиентом одного оператора ЭДО, а заказчик – другого; при этом один из операторов обеспечивает работу с файлами IS-XML, а другой нет?

Самый простой способ – заключить еще один договор на осуществление ЭДО – специально для работы с файлами IS-XML. За простоту придется заплатить издержками на администрирование и техническое сопровождение нескольких соглашений с операторами. Есть ли другой путь, можно ли общаться с оператором ЭДО по принципу одного окна? Можно, но с существенными оговорками. Перед операторами ЭДО поставлена задача создания единого информационного пространства: не важно, чьим клиентом окажется отправитель ЭД, а чьим – получатель, все операторы ЭДО должны обеспечить прозрачность и целостность доставки ЭД – как от клиента к его оператору, так и всем операторам между собой. Подобный процесс межоператорского взаимодействия в процессе движения ЭД от отправителя к получателю именуется роумингом, причем аналогии с мобильной связью более чем уместны. Достаточно вспомнить, что в 90-х годах прохождение SMS обеспечивалось только в ситуации, когда и отправитель, и получатель сообщения являлись абонентами одного и того же сотового оператора. Потребовалось существенное время, чтобы абоненты перестали задумываться о том, какой оператор связи у него и его собеседника.

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

Разговор об ЭДО файлов IS-XML на минорной ноте заканчивать не хочется. Поэтому отметим еще раз, что в целях предоставления оперативных данных противопоказания к использованию IS-XML файлов отсутствуют, юридическая значимость может быть обеспечена, а вот единых рекомендаций по решению задачи визуализации ЭД на данном этапе нет, что можно обобщить и так: "Есть над чем поработать, хотя сделано уже немало".

10. IS-XML: дорожная карта поставщика

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

• изучить стандарт IS-XML
  • сначала по текстовому описанию, содержащемуся в описании ранней версии стандарта в формате PDF (см. ссылку на него выше),
  • затем по актуальной версии, изложенной в файле “IATA IS-XML Invoice Standard-vN N N N.xlsx”, где N N N N - номер версии стандарта, входящем в состав файла описания стандарта “IS-XML Invoice Standard v3.9.0.1.zip”;
• изучить примеры в части, касающейся деятельности отправителя, содержащиеся в файле “MISC-Invoice-Samples- N.N.N.N.zip” (N.N.N.N - номер версии стандарта), опубликованном на странице SIS for Airlines & Intermodal (см. ссылку выше) в разделе Documents по ссылке Sample Files  / Miscellaneous;
• собрать данные о результатах оказания реальных услуг реальному заказчику и на их основе составить файл IS-XML.
• проверить соответствие полученного файла его XSD-схеме, устранить выявленные несоответствия.
• зарегистрировать учетную запись в IATA и получить доступ к личному кабинету на портале https://iata-s.iinet.org
• проверить соответствие полученного файла требованиям IATA; для этого следует воспользоваться функцией проверки файлов в тестовой среде sandbox ("песочнице"), присутствующей в стандартном функционале личного кабинета
• (необязательный и даже нежелательный пункт) уяснить, какие требования стандарта представляются неприемлемыми, а какие не позволяют в полном объеме описать параметры для ценообразования оплаты за оказанную услугу (тегов, предусмотренных стандартом, недостаточно), сформировать закрытый список отступления от стандарта IS-XML и, после его согласования с заказчиком-получателем электронных счетов формировать файлы в соответствии с достигнутыми договоренностями.

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

11. IS-XML: дорожная карта авиакомпании

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

• изучить стандарт по текстовому описанию , а затем по описанию актуальной версии в файле “IATA IS-XML Invoice Standard-vN N N N.xlsx”;
• установить взаимно однозначные соответствия между видами услуг в файле и видами услуг в учетной системе авиакомпании;
• обеспечить парсинг файлов, внедрив программное обеспечение для чтения и преобразования их содержимого в структуры данных, воспринимаемых учетными системами авиакомпании;
• внедрить процедуру импорта данных из файла IS-XML в учетную систему авиакомпании.

12. Развитие стандарта IS-XML в России – организационный аспект

Практика стандартизации показывает, что путь от идеи до относительно полного и непротиворечивого документа стандарт проходит в рамках профессиональных сообществ. Результаты деятельности подобных рабочих групп сначала носят рекомендательный характер и лишь потом, не сразу и не всегда становятся элементом нормативной инфраструктуры. Не является исключением и идея стандартизации взаимоотношений поставщика и заказчика работ и услуг, обеспечивающих операционную деятельность отечественных гражданских авиаперевозчиков. Зарождалась и обсуждалась идея на площадке АЭВТ, методическую и технологическую помощь оказывало российское подразделение IATA. Указанные организации готовы оказывать всяческую поддержку заинтересованным организациям – не только авиакомпаниям, но и сервисным организациям-поставщикам услуг самого широкого спектра. Готовы они и распространять идею электронной стандартизации – и уже делают это на практике.

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

• вопросы потребностей и целесообразности расширения текущей версии стандарта следует обсуждать на площадке АЭВТ, и с авиакомпаниями, и с поставщиками работ, услуг и ТМЦ;
• согласованные на уровне рабочей группы при АЭВТ рекомендации следует доводить до сведения российского представительства IATA, которое готово взять на себя функции продвижения отечественных инициатив. Результатом этого этапа должно стать включение вопроса по рассмотрению выработанных рекомендаций  в повестку заседания рабочей группы IATA по совершенствованию стандартов IATA SIS / IS-XML.

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