Привет, Коллеги!

Поставили задачу реализовать таковую выгрузку стандартных форм бухгалтерской отчетности(Форма 1, Форма 2, Декларация по налогу на прибыль организации) из САП.

Форматы файлов для налоговой - нашел: http://www.nalog.ru/document.php?id=255 ... l_otch_400

Кто-нибудь сталкивался с подобным? как решали? Неужто садиться и программировать создание файла тег-за тегом?

Заранее всем спасибы за подсказки!

Да, возможно придется разбирать xsd-схему, по ней генерить тэг за тэгом файл. Готовых решений не видел... Делал что-то подобное для казахстанской отчетности (там тоже xml определенной структуры выгружается): тэг за тэгом, замаялся.
Также делал выгрузку поставок сбытовых в xml (но тут формат xsd я уже сам придумал).
Если делать всё с нуля, то объем работы получается немаленький совсем...


Мое решение такое было:
Чтобы не забивать гвоздями тэги, можно написать XSLT-преобразование для xsd-шаблонов, сами шаблоны с сайта закачать в репозиторий (например, SMW0), затем в программе вызывать ваше преобразование (через CALL TRANSFORMATION), которое вернет структуру документа в виде внутренней таблицы, по этой структуре генерить xml, заполняя нужными значениями определенные тэги.
XSLT возвращает структуру в виде внутр. таблицы со строкой

Была также написана объектная обертка, которая по таблице структуры строила объектную иерархию документа xml, у которой были методы по заполнению xml определенными значениями.

Т.е. в программе, которая заполняет данными, вызов выглядел примерно так:


document - класс управления объектной иерерахией (тоже Z), метод render_xml обходит иерархию и, используя стандартные классы CL_IXML, генерит xml в виде бинарных данных, которые выгрузить куда-то - дело техники уже.

Вообщем, очень сложно и объемно получилось, но универсально (в случае изменения формата новый файл xsd закачивается в систему, правится немного программа заполнения данными, но тэги гвоздями нигде не перебиваются).
Это я вам описал свое решение.

Возможно, как-то проще сделать можно.

P.S.
1) ядро должно быть не ниже 7.00 (если не ошибаюсь), чтобы xslt там работали
2) NODE | PARENT_NODE будет работать, если имена тэгов с первого по n-1 уровень будут уникальны (иначе поле PARENT_NODE в таблице не будет правильно отражать иерархию). Или сделать структуру NODE_KEY | PARENT_NODE_KEY | NODE | PARENT_NODE, где NODE_KEY и PARENT_NODE_KEY - некие "суррогатные" ключи, например, натуральные числа, а NODE и PARENT_NODE - реальные имена тэгов

Огромное спасибо за развернутый ответ и интересное решение!

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

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

UPD. Естественно я не рисовал файл руками, а делал это через CL_IXML.
Т.е. я формирую структуру с данными, а мои друзья - методы и объекты, формируют сам текст XMLя.

может, я чего не понимаю по задаче, но исходя из общих соображений - что мешает сгенерить по XSD-схеме каким-нибудь внешним инструментом шаблонный XML-файл и использовать его как основу для XSLT или Simple Transformation, прописать в шаблоне, куда и как должны попадать данные, и передавать их в трансформацию непосредственно при вызове CALL TRANSFORMATION?

Можно и так, но в моем случае мне удобнее было сделать по-моему.

А если бы еще и шаблонный xml-файл имел бы не статическую структуру (в плане "куда и как должны попадать данные")? Ну это так, размышления уже

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

Делал Тег за тегом .Делал Деклараци учета полученных и выданных счетов-фактур для Налоговой Инспекции. Так Как структура ХМL была цикличной много кода не получилось.

SAP CIS уже реализовал велосипед под названием J_3RF_REPORT для отчетов в XML. И структура там настраивается через гуевый тул.

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

А как он у вас в дампы падал? Я просто на стыке 2014-2015 заставлял разработчика оптимизировать эту байду. Он вроде сначала использовал DOM, а потом перешел на stream. По 10-50мб (до-после) файлы генерились, правда медленно ух...

Kengur: по всякому он падал. Не из-за памяти. Из-за нот было. Приходит нота - а при установке нормально не встает. Из-за необрабатывания различных вариантов ведения настроек - тоже было: выбрали не тот (с точки зрения разработчика) провайдер данных - оно опять падает. Без какой либо обработки экспшенов. Выкатывает сел. экраны с длинным списком параметров, но без истории и сеч-хелпов (или без вариантов? не помню. но дружелюбие интерфейса и тулзы запомнилось. да). Что-то уже и забывать начал как оно разнообразно глючило-то.