Всем привет! У нас в организации решили ввести электронные накладные от поставщиков. Сейчас стоит вопрос форматов. Понятно что xml, csv,dbf и структурированный эксель.
Но может есть какой-нить условно общий вариант для csv или xml в надежде что у поставщиков уже будет готовая выгрузка. Может кто сталкивался с этим вопросом.

а у кого нет 1с у вас или у поставщиков?

(0) Про ЭДО не слышали?

(1) У поставщиков может быть что угодно. Я из Минска ЭДО нет.

https://v8.1c.ru/tekhnologii/obmen-dannymi-i-integratsiya/standarty-i-formaty/standarty-commerceml/

(3) кто кому формат диктует? Вы поставщикам или они вам?
Поддержу тему формата ЭДО, если даже сейчас не используется в Беларуси 1С будет продвигать его

(0) Свой вариант пилите. Или какой-то вариант EDI. У вас там своя атмосфера. Если накладная не будет юридически значимой, можно запилить свой вариант Desadv.

(0) DBF или JSON
Если вы можете продвинуть свой формат

Если не можете то берете все что угодно от поставщиков ("пришлите пожалуйста накладные в DBF (не путать с PDF) или хотя бы XLS") и пишете две штуки:
1. Конвертер из формата поставщика в свой универсальный формат
2. Загрузка из своего универсального формата в 1С

(4) КоммерцМЛ в топку
По двум причинам:
1. XML тяжел, сложен и неудобен
2. Нет отраслевой специфики, нужных полей/реквизитов

Идея CommerceML замечательная!
Но реализация никакая.

Надо было делать/переходить на JSON вместо XML
Надо было 1С сделать свой сервис обмена и обработки для 1С для типовых
Причем сразу предусмотреть отраслевую специфику

Формат диктуем мы как впрочем и сами электронные ттн

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

(11) см (8) не догадался что ли?
разделить загрузку на две части

(12) * см (7)

(10) Если диктуете вы тогда однозначно JSON
Причем сразу версионирование и описание с примерами, про кодировку UTF-8 не забыть

(14)+ И сразу http rest api поднимать куда можно те же json кидать и получать ответы ))

(0) Я - за XML. Потому что оно - практически стандарт.
ДБФ избыточен для данных сложной структуры. Тоже самое csv.

(16) JSON проще XML

(17) По сложности они одинаковые. По лаконичности JSON конечно впереди.

Но для xml есть парсеры в 1С 7.7/8, а для JSON нет.

(18) Каким местом одинаковые?
У XML есть атрибуты кроме тегов и значений это если не вспоминать про XSD и прочие

(19) в 1С 8 парсер JSON встроен
Для 77 есть или внешние или написанные на ЯП

И да JSON быстрее XML особенно на больших объемах

на 7-ке не встречал может подскажешь где

(11) "у разных поставщиков структура счета-фактуры разная"

А что, у вас налоговая ботфортом консоме хлебает?
В России состав сч-ф фиксирован снизу...

(9) Когда делали КоммерсМЛ - о жисоне никто ещё не слышал.

жисон появился тогда же когда жабаскрипт

но в 1с конечно да

(23) https://expert.chistov.pro/public/1167222/
эта на JS основана вызывает javascript
Есть и другие их куча

(25) смотря какой версии COmmerceML, первой (2000 год) да а так json с 2006

(24) стоит вдумываться в смысл прочитанного, имелось ввиду, что в макетах  xls or mxl столбец наименование не обязательно в C2, в БП3 может в С2, в какой нибудь Альфа-Авто он на С5, а следующий, вообще на С10.