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

+ к 28 Сам использую
1. Для выгрузки в МеДок XML
2. Обмен с некоторыми клиентами MMO или его вариация EXT
3. С другими клиентами ТХТ (зараннее оговоренного вида) или DBF (в некоторых частных случаях применения = самый быстрый, особенно если к ДБФ-у присобачиваю индексный файл).

(0) обмен чего? одна-две таблицы с простыми типами - TXT
иначе XML.

Однохренственно.

После нескольких случаев выгрузки контрагентов с непечатаемыми символами в названии (из Excel или с web-сайтов копировали при заведении) - только XML. Он их хоть как-то поедает.

(32) обмен документами "поступление товаров и ислуг", а именно таб. частью "Товары"

Небольшое пояснение к п.31_3: "ТХТ (зараннее оговоренного вида)" - имеется в виду строго фиксированный текстовый формат, где расписаны форматы как каждой строки так и последовательность строк.
Например:
1-я строка
поз. 1-7 - номер документа
поз. 8-16 дата
и т..д.

(8)
"xml гумно жрет гигабайты памяти фстопку негодуэ"
Эксель гумно, жрет память, поэтому рисую таблицы в нотепаде.
Автокад гумно, поэтому проектирую в паинте.

XML однозначно рулит

да

(33) Ненаучно выражаешься. ПО-научному "монопенисуально".

(37) Ну да. А 1С так вообще... на кривых запросах ложит сервер или сама выпадает.

(40) Да изофаллически мне, "однохренственно" или "монопенисуально"...

XML - только потому что стандарт обменов самой 1С

Для своих уникальных обменов есть вагон и маленькая тележка вариантов вне XML

(35) На вопрос "В каком стандарте XML выгружает 1С" надо отвечать - Одинэс настолько крутая программа, что может выгружать в любом стандарте. В том числе и gs1. Пусть от зависти подавятся и не считают тут нас за лохов которые только с текстовыми файлами справится могут.

интересно, сможет ли буржуйская прога съексть то, что ей 1с нагенерит в xml. И vice versa (1с-овский xml не все парсеры понимают и в дерево развернуть могут)

(45) Дело не в буржуйской проге, дело в радиусе кривизны рук топикстартера. Яндекс же смог сожрать иксымельку, которую, я ему подсунул и не подавился, хотя изначально 1С об Яндексе ни ухом ни рылом.

(45) вот и я подумал что с TXT будет намного проще и меньше рисков, а то сделаю а мне скажут что у них не грузится, в итоге вернемся к TXT, так еще и я буду в этом виноват.

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

(47) так у тебя же есть поля по которым ты должен выгружать.
Сделай более универсальным его, что бы можно было в хмл или в тхт :).

фигли тут размышлять

http://www.gs1.org/ecom/xml Оно?
(47) Будь мужиком, блеать, сделай по человечески! Пусть буржуи описание стандарта скинут и всё. Ты же только табличную часть товаров передавать будешь, там всего то несколько полей, чё ты ссышь так.

(0) А чего не печатные копии? Проверять ту ли тебе txt прислали, тоже прикольно, а тупые xml схемы, чтобы код не писать - ацтой!

(0) похрен

не так давно сам стал делать

xml

иностранное или межпланетное? они по-моему грузят в XRVGTYUIOSD

ТС, тут ответа не дождешься, тем более с голосовалкой.
Каждый любит свои сигареты...

тут дело в том, что
1. Структурированные данные удобнее обрабатывать XML
2. Чтение/ЗаписьXML генерят XML с тегами укороченной формы. Косяк (хотя фиг знает -- возможен ли) может быть в том, если буржуинам понадобятся непременно теги полной формы. Тогда XML надо будет генерить через простые текстовые файлы. Что уже сложнее, чем текстовый обмен

Почему я так волнуюсь за буржуйскую прогу? Потому что 1с-ники бесплатны по сравнению с буржуями, и всю работу будет делать ТС. А некоторые файлы, которые генерит 1с через XML-запись НЕ открываются парсерами XML. Возможно, парсеры кривые... но проблема только с xml от 1с возникает, хотя и не всегда

(58) За XML, генеренный через текст надо руки отрывать. Валидатор охреневать будет местами, и парсер вслед за ним.

(59)  пример файла в студию

(8) ну, никто не заставляет юзать ДОМ-модель

(60) XML суть текст. а руки надо отрывать горе-писателям, которые не в состоянии сгенерить валидный хмл

Проще так

(63) Чтобы сгенерить валидный XML в общем случае - надо учесть все нюансы и фактически написать абсолютно стандартные вещи заново.

(65) дануна! и что же такого придётся писать? пару-тройку функций на 20-30 строк? экая задача

(61) Это было около 3-ех лет назад. Из КД-2. Пробовал микрософтовским парсером, он выдал попап, что может открыть только как plain-текст.... не сохранился, к сожалению. Но случай запомнился

(67) версия парсера, поди, 3-я была?

(68) Я и не помню... оно в браузер встроено было, в ослик 6-ой

Хотя, файлы xml обмена с логистикой акселотовской открывались нормально с сохранением структуры.

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

(66) Я тоже так думаю. Но на практике, если уж генеришь XML как сырой текст - то хоть через валидатор пропусти после этого...

(71) ну, это без базара. две лишних строчки в коде не помешают

+(72) но после отладки их лучше убрать, ибо, если использовать их в повседневке, то смысл прямой записи хмл теряется

(66) Хочешь сказать что твои строчки запишут хмл валиднее чем годами оттестированные библиотеки?

(74) Библиотеки тоже люди писали...

(74) посмотрю я на тебя, что ты будешь делать, когда годами оттестированные библиотеки отожрут всю память и вывалятся на самом интересном месте

+ xsd

Аминь

чо тут думать?..

(0) Чего тут думать? Если кодировка UTF-8 для простых типов данных - формат TXT. Если структурированные данные - XML.

Всем спасибо за советы!

У xml есть символы которые 1с не читает и сваливается по ошибке к примеру "&". Делал обмен с интернет магазином столкнулся с таким.

(82) &amp

Сделать схему и сообщения валидировать перед отправкой.

У меня уже давно алгоритмы написаны чтения/записи XML или TXT - зачем такое обсуждать? Берешь, пользуешься.
В XML можно хранить несколько табличных частей...

(82) спасибо, поржал

XML - это все-таки стандарт

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

Плюс, для определенных объемов передаваемых данных XML в принципе не подходит

CSV - там разделение вроде как ";"
и он открывается в екселе
и в итоге получается, что-то типа ДБФ
приходилось как-то для САПа делать.

(89) wiki:CSV

Фактический стандарт для 1С.

(91)+ Отточишь навыки.

(88) "Плюс, для определенных объемов передаваемых данных XML в принципе не подходит"  мягко говоря, неправда

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

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

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

Построчное чтение txt-файла оказывается быстрее, чем чтение xml-файла.

(94) > есть готовые парсеры, которые чаще всего загружают весь файл в память и там его разбирают


не все же сразу в память

(95) Дерево объектов строится в памяти - поэтому, файл чаще всего или целиком в памяти или читается много раз по кусочкам (что даже медленнее, чем файл в памяти).

Последовательное чтение хмл никто не отменял. Можно хоть по одной записи выдергивать если есть желание.

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

ИМХО

(100)

XML с использованием фабрикиXDTO

(101) На больших файлах - нет!

тупая ветка... пока нет внятных требований к носителю - все выборы бессмысленны

(103) Угу
И вроде не раз обсуждали уже , например
Обмен в формате XML, DBF, TXT?

Все равно - большую часть кода что в тексте, что в иксемеле  занимает не чтение и разбор данных а распихивание ппрочитанного по нужным местам/объектам - поэтому, в общем по барабану. иксемель может быть чуток понятнее за счет наличия тегов/атрибутов - ДА И ТО, В РЕДКИХ СЛУЧАЯХ. ну а так как периодически случается невозможность работы парсера - то приходится извращаться.. Текст - прочитается всегда.
.
так что - текст...

(105) Предлагаю и всякие SQL отменить, они ж на дисках хранятся.

(106) а фигли делать.. грузиишь например v7+ - 1ска падает... и вместо того, чтобы грузить данные - кучу времени убиваешь на поиски бодяги...
.
хотя мну пофиг.. обменов у меня мало - что наружу что внуть - отдам/загружу в каком надо формате...
все равно - что под каждый текстовик, что под каждый иксемель - писать свою загрузку данных...

(83) И что это?
(86) Смари не абассыся от смеха.

Как передать наименование товара которое содержит данный символ к примеру "проктер & гэмбэл"

(86) Дерзай http://zalil.ru/32909240

   ЧтениеXML = Новый ЧтениеXML;
   ЧтениеXML.ОткрытьФайл("c:/1.xml");
   Пока ЧтениеXML.Прочитать() Цикл
   // Обработка узла XML
   КонецЦикла;

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

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

Голосую за:

+ Сам разрабатываешь структуру файла. Используешь спец знаки в строке.
Потом разбираешь строку по этим знакам и получаешь все что необходимо.

(109) Ну где же дерзкий чел из (89)?

3. Вэб-сервис

3. JSON
4. YAML

(114) а как делсть схему?

(86) ANDREWKS ответь на (109)

объемы данных не указаны

в голосовалке нет кг/ам

(121) Согласен.

имхо проще

(125) у тебя не валидный xml, это тоже самое что в dbf запишешь в заголовок мусор всякий, а потом жалуешься, что не открывает.  http://screencast.com/t/05jb8LDWeqO

Без вариантов, сам боялся, но уже теперь нравиться после N-выгрузок/загрузок в налоговую :)))

Насчет спец.символов, учите мат.часть ХМЛ-а:
& ==== &

(120) почитай-ка здесь: wiki:XML, раздел "Спецсимволы"

привычно да и лучше