Всем доброго времени суток!

Наша компания является разработчиком товароучетного софта (не на базе 1С)
Появилась задача сделать выгрузку в 1С с помощью формата EnterpriseData 1.8.
Для формирования C# классов из XSD схем используем фреймворковский xsd.exe
В данном случае столкнулись с проблемой - формирование классов невозможно в связи с использованным в схемах элементом ##any.

Предупреждение при проверке схемы: Символ шаблона "##any" допускает элемент "http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.8:ДополнительныеРеквизиты" и создает неоднозначность модели содержимого. Модель содержимого должна быть сформирована таким образом, чтобы в процессе проверки последовательности информационных единиц элемента часть, содержащаяся в ней прямо, опосредованно или неявно, с которой должна проверяться каждая единица последовательности, в свою очередь могла быть однозначно определена без изучения содержимого или атрибутов этой единицы и получения дополнительных данных об остальных единицах в последовательности.

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

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

(0) может вам лучше свой XDTO-пакет накидать для 1С.

Типовые и меняются, и устаревают. И сопровождать типовой тяжелее.

Дмитрий, я прошу прощения, а можно с этого момента подробнее?)

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

Буду благодарен за "пинок" в нужном направлении.

(2) пинка в нужном направлении не дам, т.к. подобного не делал

у вас вообще что за решение? фронт-офис какой-то?

(2) +если для разных конф - и для КА/УТ/БП/ЕРП, то, наверное, надо пытаться победить энтерпрайз дату

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

(0) Причина-то ситуации в другом. У вас автоматичесекий инструмент не может автоматически создать код по валидной схеме. При этом то, что валидная схема пришла от 1С вообще никакой роли не играет. Точно также могла прийти и от Оracle какого-нибудь.

Пишите код ручками. Совсем обленились.

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

P.S. "Лень - двигатель прогресса" (с). И ни я это придумал ;-)

может вам нужно другой инструмент раоты со схемами поискать.
схема в 1с вполне валидна

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

> Лень - двигатель
Вот и создатели инструмента автогенерации так и подумали. И решили не заморачиваться с этим сценарием. Теперь шанс подвигать прогресс есть у вас. Что-то не так?

Там ещё проблема в том,что все,что не влезло в формат,как раз и пойдет в эти дополнительные данные,так что их использования не избежать,а также построить модель под любые данные через xdt не просто.
Когда мы делали интеграцию 1с с программой на C# тоже сначала пошли по пути использования схем,но потом плюнули и написали обмен через json,просто реализовав его чтение на стороне 1с,оказалось быстрее,понятнее и универсальные.

(0) Наймите программиста 1С

не ужто с# не поддерживает поля эни?

Может сделать утилиту, которая обработает все ##any

(12) Поддерживает, почему нет. Точно так же как и java. Только если пользоватся маппингом в классы, то их поддержка начинает сильно зависить от прикладного смысла, поэтому и автогенерилки кода на них забивают или в лучшем случае делают тупую привязку к Object. Некоторые, правда в java, позволяют в процессе указать свои биндинги, но это же надо засучивать рукава и их писать.

А тут  "Лень - двигатель прогресса".