Добрый день.
Начало тут: Падает "карлик" при выводе результата..., начиная с сообщения 116:

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

На текущий момент сделана авторизация, получение ID сессии по КЭП, все работает:



А вот дальше - застрял... Целый день сегодня бьюсь, и не в какую...
Пытаюсь получить список документов с сервера, сам запрос такой:



Отличий не вижу, кроме параметра - у них в примере даты, у меня тип документов(по талмуду только он обязательный, остальные можно опустить).
Получаю в ответе:
"Ошибка {"jsonrpc":"2.0","error":{"code":-32700,"message":"","details":"Error while decoding the request","type":"error","data":{"classid":"{f4101a18-9ea7-447d-9f98-9a951643f9f0}","error_code":-1,"addinfo":null}},"id":null}"
Типа ошибка декодирования запроса... Кодировки запроса пробовал и в UTF-8 и в Windows-1251, разницы в ошибке нет...
Не понимаю, что я не так делаю...
Кто разбирался с этим, подскажите, дайте толчек, дальше я уже сам как нибудь :-)

у СБИС нет типа документа НакладнаяВх. может ДокОтгрВх ? https://sbis.ru/help/integration/catalog/guide#1

(1) Да, все верно сделал: "ФактураВх" и получил:

"{"jsonrpc":"2.0","result":{"Документ":[],"Навигация":{"ЕстьЕще":"Нет","РазмерСтраницы":"25","Страница":"0"}},"id":1}"

Все верно. Даже не знаю, откуда я "НакладнаяВх" вычитал, много "писанины" перелопатил, уже сейчас и не вспомню... Но, откуда-то скопировал, не руками-же я его писал :-) ...

В общем - работает, спасибо за подсказку :-)

Просьба - кому не жалко, киньте пожалуйста мне любой документ, лучше УПД, в СБИС, что-бы дальше отладить... Мой ИНН ИП 507500091972.
Заранее спасибо :-)

Так: "ДокОтгрВх" тоже работает.

(2) отправил тестовый упд

Да, увидел, спасибо! :-)

Фильтр по "ДокОтгрВх".

Пока так:



На большее сил пока нет, завтра продолжу...

Нужно 2 табличные части: Пакеты (конверты) и вложения
получение документов в принципе не сложно, сложнее подписывать и отправлять. Я не заморачивался, скачал их обработку и переделал под себя.
https://ibb.co/QHv8kb5
Уже несколько лет все работает

(7) Две табличных части - не проблема. Только я не пойму, а зачем мне пакеты и конверты?
Отправлять я ничего никому не собираюсь, это 100%. Это под мелкие розничные магазинчики.
Только принять и подписать, служебную квитанцию о просмотре и сам документ. Если и будут редкие возвраты, отправят пешком из ЛК.
А для приема и подписания - зачем пакеты и конверты?
А вложения? Зачем они мне? Мне нужно принимать только формализованные документы, печатную форму можно в ПДФ получить. А если пришлют какие-то договора или что-то в этом роде - зайдут в ЛК и скачают.
По крайней мере в ЭДО лайт от ЦРПТ, я спокойно обхожусь без этого... Тут, разъве такое не прокатит?
Или я чего-то не понял в отличиях СБИС от ЭДО лайт ЦРПТ - ?

(8) Пакеты(конверты) у СБИСа для минимизации тарификации на отправку. Деньги взымаются только за ПАКЕТ, а сколько и каких документов в пакете для выбранного контрагента не важно.
Также в пакетах и вложениях есть много нужной информации... прохождение направления статусы и т.д.

Да все прокатит) я думал Вам нужен полный обмен, чтобы лишний раз в ЛК не лазить. Т.е. вам нужно просто посмотреть сумму и контрагента и подписать? Без загрузки данных в базу? Но тогда мне кажется это проще в ЛК сделать. Там хоть вложения можно посмотреть (товарный состав УПД).
А подписать можно только пакет целиком и без вложений вы увидите только сумму и контрагента. или я просто не понимаю что вы хотите добиться.

(10) Без загрузки данных в базу?

Да нет. Загрузка в базу - это основная фишка. И с этим как раз проблемы я не вижу. Все давно отлажено для ЭДО лайт и для ручной загрузки ХМЛ. Особой проблемы с этим не вижу.
А вот исходящие - действительно не нужны.

(4) (2) отправил тестовый упд

Спасибо еще раз... Но можно "понаглеть" чуть-чуть - ?
Нужна еще одна, что-бы правильно понять список JSON, на каком уровне вложения идут отдельные документы, для формирования списка...

+(12) понять список JSON, на каком уровне вложения идут отдельные документы, для формирования списка...

В принципе понял - тег JSON называется "Вложение". Каждое "Вложение" - это документ в списке. Я сначала подумал по названию, что "Вложение" - это какие-то присоединенные файлы, но нет.
Скопировал свою обработку клиенту, у которого СБИС, получил запросом JSON списка доков, и сохранил его в файл. Все стало понятно.
Так, что вторая накладная "себе" - уже не так актуальна, но, все равно - не помешает, по возможности...

(13) у СБИСа хороший учебник по API
https://sbis.ru/help/integration/api/all_methods/read_doc

(13) А не жалко поделиться обработкой? Можно на почту в профиле.
У нас 90% документов это отправка, поэтому делал через сбис-коннект, очень удобная штука.
Но сейчас надо доработать на прием и разбираться просто некогда. А клюшки совсем не типовые.

(13) вот про структуру Документа и поля "вложения"
https://sbis.ru/help/integration/api/all_methods/object

(14) Спасибо, видел, им и пользуюсь. Просто некоторые моменты проще на примере разбирать.
В (13) я немного не так понял... Все-таки надо парсить список на уровне "Документ". А "Вложение", это подчиненные "Документ" узлы. Например, мне попался док, который пришел как "Документ ЕГАИС"(х.з., надо проверить, есть он-же а УТМ?), сам документ "Поступление", а к нему еще 4 "Вложения" - всякие Справки F1 и F2, и т.п...
Мне для построения списка нет смысла перебирать вложения, достаточно самого "документа".

(15) Поделиться - не жалко, совсем. Просто это пока "полуфабрикат", и кроме того, там куча всяких процедур и функций в ГМ конфы, все, что связано с запросами, работой с ЭЦП и т.п... Сама обработка не "самодостаточна", вне моей конфы не заработает. Но, если скажете, какие процедуры/функции аналогичные моим у Вас отсутствуют и нужны - тоже поделюсь, не жалко :-)

На текущий момент вот так это выглядит:



Сама обработка вот: https://cloud.mail.ru/public/yDDd/Y5YvgdXda
Но, еще раз повторюсь - просто так она не заработает. Она под мою конфу. А конфой целиком, я не поделюсь... Слишком много туда трудов вложено, там целая ЕРП на базе 7.7. :-)... Отдельными фрагментами пожалуйста, не вопрос.

(17) Спасибо, посмотрю!

Вообще, конечно, сильно концепция ЭДО СБИС отличается от концепции ЭДО лайт от ЦРПТ... В ЭДО лайт, JSON списка проще, но, там все нужно получать запросами - сами документы в XML, печатные формы в PDF, и т.п... Сдесь же, можно тоже так-же, отдельными запросами, а можно просто получать их по ссылкам - все ссылки есть в JSON списка... Пока не решил, что лучше, и как буду делать дальше...

И еще не понятно...
Что такое - "НашаОрганизация" - ???
Мы, как получатель???
Если так, то почему в файле JSON, загруженном из СБИС по ИД_Сессии, в свою очередь полученному по КЭП, кого только нет??? Десяток разных фирм в этом теге... Как так может быть?

Или там идет какая-то привязка не к КЭП, а к какому-то "абстрактному" пользователю(подозреваю, что это может быть какая то бух на оутсорсе, ведущая несколько предпринимателей) - ???
Такое вообще в ЭДО возможно?
Странно.

(20) в СБИС на один логин могут приходить документы для кучи организаций, привязанных к этому логину. А вот подпись - сработает только для документов той организации, на кого она выпущена.

(19) Контур "унутре" тоже отличается.
в каждой избушке свои погремушки...©

(21) Ясно, спасибо!
Сейчас отбор по "своему" ИНН сделаю, пользователь, сидящий на оутсорсе в Красноярске,  меня не интересует... И я и конкретный клиент, в Московской обл. Если ей надо, в ЛК она и так все увидит, а меня интересует только ЭДО по API конкретного ИП.
(22) Ну... Контур, тоже можно было-бы сделать. Но, не буду - нет у меня клиентов сидящих на Контуре, и готовых платить 13000 в год всего-лишь за доступ к API. Пешком, через файл скачанный из ЛК загрузят(это все работает и давно, я с этого начинал "знакомство" с ЭДО).

>> Мне для построения списка нет смысла перебирать вложения, достаточно самого "документа".
Для списка документов да, для загрузки данных вам придется получать вложения. Вернее пользователь должен выбрать какое именно вложение нужно загрузить.
Во вложении может быть несколько УПД, или счет и упд.
Вот поэтому нужна 2-ая табличка, в которой будут вложения. И по нажатию на ней - загружается нужный док.
Если док не формализованный (не xml), то просто его открываем средствами системы (pdf,doc и т.д.).
Ну или 2 вариант, при нажатии загрузить - перебирать все вложения, и все xml загружать, остальные пропускать. Мне кажется так себе решение. Далеко не все-же документы загружаются в базу.

(24) Да, уже столкнулся, спасибо. В ЭДО лайт такого нет, там всегда один документ - одна его XML, так как обмен неформализованными документами у них не поддержан, на то он и "лайт".
Здесь же, попадаются документы с кучей вложений(как я выше уже писал - например параллельный с ЕГАИС ДО), и в каждом своя XML может быть... Сначала ломал голову, как автоматом загружать нужное, но, наверное доверить выбор пользователю через вторую табличку будет правильнее.

В общем, на ваш суд, если кому-то это еще интересно, выношу видео, коротенькое, меньше 2-ух минут, как сейчас это у меня работает. Оно в облаке майл.ру, поэтому лучше не просматривать по ссылке, а скачать на комп, посмотреть, и удалить потом - иначе майл.ру облако отдает видео на просмотр "замыленное", как-бы "не в фокусе". Скачанный файл при просмотре стандартными виндовыми средствами - качество идеальное. Вот: https://cloud.mail.ru/public/mSuK/F1SCQS2t5

Критика и советы очень приветствуются :-)

а не проще блин поставить 1С:ЭДО (это типовая восьмерочная конфига для ЭДО) и законнеектиться клюшками с ней и не морочиться всей этой хренью...?

(26) а привязка товаров "сохраняется", на следующей УПД товар автоматом привяжется?

(26) у видео можно вручную поставить разрешение 720, и оно становится вполне нормальным.
По поводу обработки - неплохо. Но почему бы сопоставление товаров не сделать либо отдельным справочником типа "товары контрагентов" (ну или - свойством номенклатуры, если не хочется типовую корежить?)

(27) СБИС не умеет в несколько ID

(27) Не проще. Восьмерошный ЭДО нужно покупать, как минимум платформу(конфа вроде бесплатная). И опять-же завязывать с не типовой конфой 7.7, те еще пляски с бубном. А тут, вроде готовое решение в конфе, как ее часть.
(28) Привязка товаров - по ШтрихКодам(или GTINам, если есть маркировка), контрагентов по ИНН. В примере, который на видео, естественно нет - так, как ШтрихКода в УПД из ЭДО просто нет.
(29) Ну... Не знаю, зачем все усложнять. Есть ШК, уникальый, по сути - ключевое поле. По нему сопоставляется не плохо, и кроме того, в базе есть поле "НаименованиеЕГАИС"(называется так, как наследие от того, с чего начинал :-) ), записывается в базу при создании/или сопоставлении полученного по ЭДО товара, и если товар без ШК, например весовуха, ищется в базе по нему, и предлогает именно найденный товар. А пользователь может или согласиться, или создать новый(ну, или сопоставить, если в базе есть такой созданный "пешком" ранее товар).

Вообще, эта часть(сопоставление товаров и контрагентов, загрузка накладных) у меня уже давно сделана была - еще когда из файлов скачанных из ЛК грузил, потом ЭДО лайт, теперь СБИС... Не менял ничего, пользователи привыкли и успешно работают.

Вот, список доков из файла сохраненного(просто сохранил для отладки на компе клиента, так, как у меня нет ее КЭП), там видны доки с несколькими вложениями:



XML тут не открываются, так, как он их получить не может из-за отсутствия у меня КЭП клиента.
Открывается только моя, которую прислали здесь, под моей КЭП.

По сути, в первом приближении все работает, надо теперь с подписанием разбираться...

(31) В обычном ЭДО ШК очень редкая штука. По крайне мере у себя не припомню чтобы кто от из поставщиков ШК присылал.

+(31) По нему сопоставляется не плохо, и кроме того, в базе есть поле "НаименованиеЕГАИС"(называется так, как наследие от того, с чего начинал :-) ), записывается в базу при создании/или сопоставлении полученного по ЭДО товара, и если товар без ШК, например весовуха, ищется в базе по нему, и предлогает именно найденный товар. А пользователь может или согласиться, или создать новый(ну, или сопоставить, если в базе есть такой созданный "пешком" ранее товар).

Иллюстрация как это работает: https://cloud.mail.ru/public/eLhr/d1JfDG3hz

(32) Ну, не знаю... У моих, это скорее исключение, чем правило... Тем более, сейчас все больше маркированное идет, а там если не ШК ЕАН, то GTIN передается, даже если учет по ОСУ...

https://online.sbis.ru/news/8816f3ae-5a06-40c0-9fbd-40d2b850936d

>> надо теперь с подписанием разбираться
тут начинается самое интересное) все эти этапы, действия ..
я полпути прошел и бросил, скачал их sdk с ним гораздо легче. Он сам все подписывает и отправляет. Ну попробуйте, может все получится.

(34) эта самая "СБИС Бухгалтерия (Saby Bu)" - это вообще пьяный бред укуренного шизофреника.

(36) Это понятно. Похоже на то, что 1С и Сбис зарубились не по-детски и пока верхи не договорятся - будут проблемы в совместной работе )

(35) Ну, "дорогу осилит идущий!"

SDK - это хорошо, но, это "черный ящик"... А я не люблю черные ящики. Хочу сам контролировать процесс, и видеть, что происходит.

Сейчас, мои клиенты у кого СБИС или Диадок, работают так:
1. Заходят в ЛК.
2. Скачивают XML нужного документа, сохраняя его во временном каталоге на компе.
3. Загружают в 1С из этого файла.
4. делают там все "сопоставления", создание новых элементов справочников и т.д.
5. После этого, формируют и проводят приходную накладную в 1С, автоматически.
6. Возвращаются в ЛК, и подписывают там эту накладную, завершают ДО по ней.

Моя доработка уже сейчас позволяет выкинуть из этой цепочки первые три этапа.
Сегодня допилю некоторые "мелочи", и можно ставить реальным клиентам.
Подписать пока смогут и в ЛК, тот-же этап 6, из того, как сейчас работают и привыкли.

А подписание - разберусь постепенно, не горит, подпишут в ЛК.
На крайняк, если уж так все там намудрили - для этого можно будет и SDK прицепить. Хотя, я сомневаюсь, что так уж "Он сам все подписывает и отправляет."... Все равно, что-бы это заработало правильно, придется разбираться как его заставить это делать. ИМХО не далеко ушло от прямого использования API. По крайней мере, тут все "прозрачно" и никаких "черных ящиков".

(37) пока верхи не договорятся - будут проблемы в совместной работе )
Вот, это еще одна причина, почему я не хочу ничего типового, типа конфы восьмерочной 1С:ЭДО...
В моем варианте - все их "договоры" по боку. Есть API, и его использую.
А сам формат доков - не они утверждают, а гос-структуры типа ФНС и т.п... И он теоретически един для всех(с небольшими отклонениями допустимыми), как бы они не "договаривались".

вот вопрос, если я в 1Сине формирую XML УПД, то надо ли мне там указывать идентификатор отправителя? или когда этот УПД пользователь закачает в ЛК - оператор сам вставит?

(39) не надо, сам вставит
мало того, операторы рекомендуют не хранить идентификаторы в базе, они не нужны. Там все по ИНН/КПП связывается

(40) то есть идентификаторы участников ЭДО можно не указывать или вписать туда "нулевое" значение?

(39) если сформировал голый xml документа по формату ИФНС - там и вставлять некуда. А если уде формируешь полный xml для отправки - нужно указывать и свой идентификатор, и идентификатор клиента, и оператора ЭДО.  Ибо и у отправителя, и у получателя может быть несколько операторов ЭДО, и, следовательно, несколько идентиификаторов.

(42) формат ИФНС, описывающий тот же xml УПД для ЭДО - вполне себе содержит описание тегов идентификации участников ЭДО, таблица 5.2
Сведения об участниках электронного документооборота (СвУчДокОбор)
https://www.nalog.gov.ru/rn77/related_activities/el_doc/el_bus_entities/8335278/

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

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

вот выдержка из сбиса
Если отправляемый документ является формализованным (счет-фактура, накладная, акт, счет и другие), СБИС Коннект автоматически определит отправителя и получателя по содержимому файла документа и дозаполнит служебные атрибуты документа, в которых должны быть указаны идентификаторы отправителя и получателя:

В имени файла документы проставит идентификаторы получателя и отправителя;
Заполнит атрибуты «ИдФайл», «ИдОтпр», «ИдПок»;
Заполнит реквизиты элемента «Подписант» по данным из ЭП.

https://sbis.ru/help/integration/catalog/agent_send/sender

(45) угу, только в описании ФНС СвУчДокОбор - являются обязательным и хз как будет вести себя оператор когда вручную например тиксемель без этого тега подсунуть.
.
по идее туда тупо можно написать нули в формате ИД, оператор это блок прсото переформирует, а проверка по схеме допустим локально у себя - пройдет...
.
За пояснения спасибо

(47) Выгружаем из 7-ки через сбис коннект в xml файле упд пишу так
<СвУчДокОбор ИдОтпр="5506020778550401001" ИдПол="5534010704552801001">
<СвОЭДОтпр ИННЮЛ="7605016030" ИдЭДО="2BE" НаимОрг="ООО &quot;Компания &quot;Тензор&quot;&quot;"/>
</СвУчДокОбор>
т.е. ИННКПП отправителя и получателя. Все прекрасно работает
в конверте для отправки тоже указываем инн и кпп, все доходит
Если у получателя несколько провайдеров, то можно в конверте указать Идентификатор получателя конкретного провайдера, тоже все доходит

(45) Да, так делает именно СБИС (большой его недостаток). Другие операторы ЭДО этим не грешат.

(48) В этот блок вы можете что угодно прописать, СБИС его просто игнорирует, заменяет своим. поэтому "все прекрасно работает".
(49) ну тема про СБИС, а почему это недостаток? Зато не нужно хранить эти ИД в базе

(50) читаем у сбис
https://formats.sbis.ru/docFormatCardEdo/117134/help?version=117134&scrollTo=formats
и видим что тег Сведения об участниках электронного документооборота
Формат
T() Строка
Тип элемента
Обязательный
а уж как сбис его использует фиг знает. Сегодня не использует, завтра использует

(51) для загрузки xml именно в СБИС - этот блок не обязателен, можете сами убедится, удалите этот тег из файла и загрузите. А вообще для обмена (для ЭДО как такового) этот тег, конечно, обязателен.
У вас ИдОтпр и ИдПолуч это ИННКПП, они совершенно не соответствуют реальным ИД в базе оператора ЭДО. Загрузите свой файл в сбис и выгрузите его в формате xml. Увидите реальные ИД отправителя и получателя. К вашим ИННКПП не имеют никакого отношения.
Может другие операторы требуют этот блок, просто потому-что проверяют файл по схеме xsd перед загрузкой, если его нет - ошибка, но операторы эдо не ориентируются на ИД которые вы им передадите. Сами подумайте, тогда вы можете "подсунуть" в файле ИД одной конторы, а сама УПД от другой конторы.
Но для большей универсальности можно этот блок добавить)

(45) Т.е. оператор сам оперирует этими ИД. Пользователям (нам) не нужно этим заморачиваться.

Вообще конечно странно... Мы формируем файл, ПОДПИСЫВАЕМ его ЭЦП, и получатель должен получить его в том виде, который мы подписали. Никакие изменения в файле недопустимы, в этом смысл ЭЦП.
Я предпологаю, что эти "редактирования" файла на стороне СБИС происходят когда используются всякие "коннекты" и т.п. приблуды, и подписывается уже обработанный СБИСом файл... При использовании API, скорее всего нужно полностью подготовить файл, со всеми обязательными реквизитами(в том числе и данные отправителя/получателя), подписать его и отправить через команды API. После этого его менять уже никто не может - иначе ЭЦП будет невалидна...

Хочу вернуться к сабжу...
Сделал сохранение ИД сессии в файл с датой временем создания, по тому-же принципу, как токен для ЭДО лайт храню. Только в ЭДО лайт токен живет 10 часов, а тут до 7 суток... с одной оговоркой - если не было запросов по текущему ИД сессии, то его "прибивают" через 24 часа.
Контролировать, были или нет запросы, т.е. живой ли ИД сессии - ну, как-то замудрено.. Поэтому решил ограничиться 24 часами по любому, не зависимо от активности. И если истекли 24 часа, то получать новый.

PS В связи с этим, обнаружил интересную особенность - если взять файлик ИД сессии у клиента, то можно работать и отлаживать интеграцию со СБИС у себя, все открывается, как и у клиента на компе, но, конечно подписание без реальной КЭП не пройдет. Но, хоть получение доков можно отладить "у себя", в комфортных условиях.

(53) при отправке документов (через АПИ) и при подписании на стороне клиента - да, вам "придется" получать эти ИД. Ну или хранить их в базе, что в принципе не правильно, т.к. клиент может поменять оператора эдо. Есть методы для получения ИД. Но проще подписывать на стороне сбиса. Ну мне так показалось в свое время)
Вообще подписание очень "увлекательное" занятие в сбисе через апи, и учебник по апи не очень хороший на самом деле. Вроде методы есть и описание есть, а последовательность не совсем понятная. По этапам и событиям особенно.
у victuan1 вроде есть обмен с сбис, только не знаю по апи или нет.

(55) Но проще подписывать на стороне сбиса.

Для исходящих - скорее всего так и есть. Я даже заморачиваться с этим не хочу, просто не стоит оно того, те редкие исходящие, которые могут быть в розничных магазинчиках, это только возвраты если будут... Их не так много, отправят файл пешком через ЛК, XML у меня формируется, по всем правилам, с ИД получателя/отправителя. А будет их СБИС использовать, или проигнорирует, подставив свои - мне по большому счету все равно.

А вот входящие подписывать лучше у себя... И придется разбираться со всеми их заморочками, хочешь-не хочешь. Для ЭДО лайт сделал, и это работает, хотелось бы и тут так-же.

(48) речь не об ИНН/КПП, а о наличии тега СвУчДокОбор в хмл и его заполнении. Наблюдал такую штуку что ИД участникв прописано нули, загружают такой иксемиель в ЛК и оо уходит/становится с правильными Идами.
.
я когда для себя писал формирование иксемеля по формату ФНС - пришлось подсистемку в 77 мелкую сделать с Идами учатников документооборота

(50) а если не толькло по СБИС, апро и остальных профайдеров?

(51) у сбис простая калька с сайта ФНС. там точно то же написано. и везде где на частных сайтах приводится формат УПД - там тоже кальки с ФНС.

(52) "Но для большей универсальности можно этот блок добавить)" - вот именно, прописав ИД как нули "000...."

А кстати, вопрос про указание адресов.
В схем е есть возможность указывать как формализованный адрес, так и адрес в свободном формате. У клиентов по клюшкам почти часто - норма - адрес в базе указан не по КЛАДР/ФИАС, а в свободном формате.
Отсюда вопрос:
допускается ли для внутрироссийского клиента указание адресов в свободном формате в сформированном иксемеле? для формализованного адреса вообще достаточно только регион указать.
.
но на стороне операторов ЭДО могут быть свои внутренние проверки иксемеля и могут требовать и наличие необязательных реквизитов (вроде сталкивался с таким не помню)..
.
у кого какая парктика хождения ЭДО с адресами в свободном формате?

(61) у кого какая парктика хождения ЭДО с адресами в свободном формате?

Первая попавшаяся УПД от какого-то поставщика, в разных тегах по разному, и из кладра и произвольный:





Могу в других посмотреть, но, думаю, там будет так-же.

О, карлик еще раз помог :-)

Заметил, что когда открываешь печатные формы(PDF) старых(нпример, 2022 год) документов, то срабатывает открытие PDF не с первого раза... Странно, что за нах... Посмотрел отладчиком и оказлось, что вместо PDF прилетает JSON с описанием ошибки, что файл еще формируется, и попробуйте позднее(пара секунд, как показала практика)...
Не проблема, распарсим, и предупредим пользователя!
А вот тут и облом - ошибка в JSON прилетает в utf-8, и 1С выводит кракозябрами... По идее, можно было-бы у карлика указать кодировку вывода, но я заранее не знаю, что он отдаст - ссылку на файл PDF, или строку JSON ошибки + файл с заданным именем, но содержимым JSON вместо PDF...
И вот тут я вспомнил об:
СтрокаASCII  = Карлик.FromUTF8(СтрокаUTF8)
Уже готовую строку ответа - конвертит идеально!

Djelf, спасибо! У меня конечно были и до этого инструменты конвертации в/из utf-8, но карликом удобнее на порядок :-)

Это все хорошо, но, как так можно:



Столкнулся, не парсится JSON ответа... Сама по себе ошибка правильная, в отбор включен ИНН организации, у которой нет регистрации в СБИС, но ответ в JSON прилетает "кривой" :-(
Текстовое значение, и без кавычек...
Думал, может у меня кривой парсер JSON в программе, но нет, онлайн-валидатор тоже самое говорит:



Так то все замудрили, еще и с ошибками :-(

В UTF8 есть в Formex, обратно - нет

(64) "Пи..ы, сэр!" ;-)

(65) Да, все так.
А в карлике с этим круче:

# Встроенные конвертеры
СтрокаUTF8   = Карлик.ToUTF8(СтрокаASCII)
СтрокаASCII  = Карлик.FromUTF8(СтрокаUTF8)
СтрокаURL    = Карлик.ToURL(СтрокаASCII)
СтрокаASCII  = Карлик.FromURL(СтрокаURL)
СтрокаBASE64 = Карлик.ToBASE64(СтрокаASCII)
СтрокаASCII  = Карлик.FromBASE64(СтрокаBASE64)

Куа хочешь, и откуда хочешь :-)

(67) это хорошо

(64) А интересно 1sqlite этот json сожрет? Мне очень понравилось работать с json sql запросами через sqlite, ну и это офигенно быстро. Скоро станет еще быстрее: https://www.sqlite.org/draft/releaselog/current.html

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

(69) А интересно 1sqlite этот json сожрет?

Не пробовал, но он явно косячный...
Сейчас в чате со службой поддержки СБИС, посмотрим, что ответят.
Пока так:

Добрый день!

12:20
Воронов Антон
Добрый день. Чем я могу Вам помочь?
12:22
А куда написать письмо по ошибке в API в ответе сервера? Невалидный JSON возвращается, не соответствующий правилам формирования JSON - ? Явная ошибка... Хотелось-бы, что-бы разработчики это письмо увидели...

12:23
Воронов Антон
Уточните, вы пользуетесь API ЭДО?

12:24
Да

12:24
Воронов Антон
Мы получили ваше сообщение и уже занимаемся поиском сотрудника для решения вопроса. Подождите, пожалуйста, мы обязательно вам ответим.

12:24
Сейчас чат немного загружен, и мы отвечаем дольше обычного. Спасибо за понимание!
Беляков Андрей
Добрый день!

Пришлите запрос и ответ в чат для проверки.

12:32
Запрос:

12:33
12:34
Ответ:

12:34
12:34

12:35
Скриншот

Метод "СБИС.СписокДокументов", при передаче в Фильтр ИНН организации, заведомо не имеющей

регистрации в СБИС, возвращает строку JSON ошибки. Все верно, так и было задумано для

тестирования своей интеграции.

НО!!! Именно этот JSON невалидный... Реквизит "code" содержит: -32.txt.txt.txt

Что это такое? Если это число -32, то там не должно быть строки .txt.txt.txt, если это

строка - то весь реквизит должен быть в кавычках, так: "-32.txt.txt.txt".

Иначе, этот JSON не возможно распарсить... И любой он-лайн валидатор, пишет, что он

невалиден.

И дальше, это:

"classid":

"{.txt.txt.txt.txt.txt.txt.txt.txt-.txt.txt.txt.txt-.txt.txt.txt.txt-.txt.txt.txt.txt-

1fa.txt.txt.txt.txt1.txt.txt.txt.txt}",

Тут что? Если это объект, в фигурных скобках, то почему он в кавычках?

Эта строка не должна вызвать ошибку парсинга, но, все равно не верно, просто парсер

спотыкается на первой ошибке и до сюда не доходит...

Больше вроде пока ошибок не видел, все остальные ответы сервера, вроде парсятся нормально.

12:35
Сейчас чат немного загружен, и мы отвечаем дольше обычного. Спасибо за понимание!
Оператор
Уточняю информацию, ожидайте.

12:37

+(70) Если кому-то интересно, то все вложения этого чата тут: https://cloud.mail.ru/public/Wfmt/RGsBFwfMQ

(70) Довольно шустро тебя отфутболили, всего 13 минут.
Интерсно когда ответят на баг, и будут ли чинить.

Пришлите пожалуйста так же заголовок запроса.

12:59
Вот:

Content-Type: application/json-rpc;charset=utf-8

X-SBISSessionID: 01e81060-01e81061-0bce-5055d4ec6eb*****

Accept: */*, application/json-rpc

13:12

Ну, да... Пока так.
Тут я те-же 13 минут думал, как ему передать заголовки в удобочитаемом виде... Но, опять карлик помог, методом Карлик.ПолучитьЗаголовки(), потом ТЗ в файлик текстовый сохранил :-)

(69) Мне очень понравилось работать с json sql запросами через sqlite
Антон, а можешь поделиться примерчиком под 7.7, как через SqlLite парсить JSON - ? Чего-то с наскока не получается...

(72) Ну, да... Футбол начинается...

Оператор
Уточняю информацию, ожидайте.

13:19
Оператор
Под каким пользователем выполняете запрос, так же пришлите скриншот прав пользователя и проверьте правильность указания реквизитов организации .

13:45
Пользователь - я как ИП,один.

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

Вопрос в неверном формате ответа сервера на эту ошибку...

13:53

Блин, при чем тут пользователь, права и реквизиты организации???? Ну, да, ошибка возвращается, я не против, так и было задумано... НО!!! она по любому должна быть в виде валидного JSON, а не непойми-чего...
Явно пытаются "съехать с темы" :-(

+(75) Телефон запросили:
Оператор
Подскажите Ваш контактный телефон. Вопрос потребует дополнительного анализа.

13:56

(75) Проще надо для начала.
.
Формирую запрос. Передаю.
Приходит джсон-ответ.
Распарсить джсон не удается, анализ паказал что джсон не валидный, тест на валидность не проходит.
Прикладываю невалидный джсон.
Прошу пояснений - в чем причина получения от вашего сервера невалидного джсон.
.
типа так.
все. Иногда не надо давать лишней инфы, пока явно не запросят. Я бы так делал.

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

А, прислали.Это не какая-то их программка, а "стандартный" FiddlerCap... Сейчас сделаю и отправлю.

(74) Вроде есть в примерах карлика, диадок и еще что-то там.
Это но не сложно, это проще чем в xpatch (чуток похоже, но мне так нравится больше).
С xml сложнее, можно закрутить через вк для sqlite которая переведет xml в json, валяется сборка в моем каталоге, но пространсвта имен она не умеет убирать, т.е. для егаис напрямую без костылей не сработает.

(79) Спасибо, посмотрю.
С XML проблем нет, привык через DOM, или через 1cpp, на крайняк через v7plus, вариантов много...
С JSON сложнее, есть в конфе функци на JS скриптах, и успешно работают, но, хочется еще вариантов.

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

Думал, с "галочками" связано:
Хм... Может по тому, что "галочки" сохранять двоичные данные и HTTPS не были установлены...
Повторил с "галочками", файл в три раза больше, но, не знаю, попало туда что-то или нет...

Но, нет:
Нет. Пока что хватит имеющейся информации.

Да оно и понятно - при чем тут запросы и сетевой трафик, если сервер в неверном формате отдает ответ...
Надеюсь, что поправят.
Пока сделал "костыль", парсю ответ в попытке, и если исключение, вывожу строку как есть... Это не красиво конечно, но лучше, чем никак...

(69) А интересно 1sqlite этот json сожрет?

Нет... Тоже ошибку дает:



"уродливый" JSON :-)  Точно сформулирована ошибка.

"Нормальный" JSON этой-же обработкой парсится без ошибок.

Но, вообще как-то странно он ее парсит... Те обработки, на JS скриптах, чем я сейчас пользуюсь, "за один проход" выдают список значений, в котором в виде значений или строки, если это последний уровень, или списки, если дальше можно раскрывать. Тут-же, ТЗ, в которой все значения строки. И если какое-то значение это объект, то эту полученную строку опять надо парсить... Может я конечно в чем-то не разобрался, х.з... раньше таким не пользовался.

(35) >> надо теперь с подписанием разбираться
тут начинается самое интересное) все эти этапы, действия ..

Фух... Да, уж, накрутили, и главное описание не очень удобное...
Но, вроде справился, где-то многократным перечитыванием оного, где-то методом "проб и ошибок":



Если я правильно понимаю, то все подписалось успешно :-)




Уважаемый sdf, это я с Вашим тестовым документом "игрался", проверьте пожалуйста по возможности у себя, все ли там нормально?

- Чувак, я нихрена не понял! Но ты сказал и достучался до сердца!

Но это только СБИС.
а как остальные?
.
не правильнее было бы сделать "оболочку" в 1С для "верхнего" отображения состояния ЭДО, в внутренние транспорты и действия, специфичные для оператора, реализовывать как "плугины" к этой "оболочке"...

(84) Теоретически это возможно, практически видимо нет, все выдумывают такие тэги что хрен знает как их утоптать в единый интерфейс.
В принципе можно и через плагины этим рулить, но это сложно, проще 10 обработок склепать, чем одну на все случаи жизни.
Класс Поставщик данных https://www.1cpp.ru/forum/YaBB.pl?num=1273512019 это кандидат для решения такой проблемы, но обвязка этого много потребует, MWWRuza вообще все на тз делает, а тут ТП, поставщики всякие, сложно, у нас же лапки, или нет?

(80) Не будут такое чинить, имхо.
Те кто работают уже прикрутили костыли для их НЕСОВСЕМ`json`а, и если испрвят сломается в 100500 местах. Оно им надо?

(86) Ну, если грамотно прикрученный костыль, то даже не заметят, что он уже не нужен, на то он и костыль :-)
У меня например, парсинг этого ответа завернут в попытку, и если она удачная - то все работает как должно, а если вывалилось в исключение - то костыль, вывод ответа "как есть" без парсинга, строкой НЕДО-JSON, со всеми "разных видов скобочками и кавычками"... Если у кого-то не так, то это, на самом деле их проблемы.
А поддержка ответила, что взяли в работу и обязательно донесут до разработчиков... А уж починят или нет - посмотрим. Ну, даже если нет - не критично, хоть и некрасиво.

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

(84) Сергей, понимаешь... Тут как посмотреть... Чисто технически, можно было-бы, если бы решение было тиражное... Но, кому оно сейчас нужно, на 7.7 - ? Я точно писать такое не буду, не оправдает потраченных времени и сил.
Я делаю это для поддержки имеющихся клиентов, под их конкретные задачи.
А у них, операторы ЭДО "распределились" по популярности так:

1. Диадок.
2. СБИС.
3. ЭДО Лайт ЦРПТ.

Других, у моих ни у кого нет, соответственно, даже если я захочу еще какого-то оператора встроить - не смогу, так, как не на чем тестировать и отлаживать.
Ну, а среди этих трех - Диадок - мимо, из-за платного доступа к API... Да, вот так, через WEB ЛК можно принимать неограниченно и отправлять(50 пакетов доков в квартал, но без роуминга) бесплатно, а хотите через API - купите доступ(ключ) за 13000 в год!
Ну никто из моих не будет этого покупать(еще раз - клиенты у меня только розничные магазинчики, отправлять им ничего не нужно, только входящие), будут продолжать грузить из файлов, скачанных из ЛК или уйдут от Диадока на ЭДО лайт или СБИС. Обработка загрузки УПД в базу 1С(все сопоставления, создание справочников и т.д.), у меня единая, общая для всех операторов или загрузки "пешком" через файл XML из ЛК. Работает давно, и к ней уже привыкли.
А ради двух оставшихся операторов, СБИС и ЭДО Лайт ЦРПТ, делать что-то универсальное не стоит, проще две отдельных обработки(на самом деле, довольно сильно они отличаются по концепции самого ДО), тем более, обработка для ЦРПТ уже давно сделана и успешно работает... А результат работы этих двух обработок все равно сводится к одной общей - загрузка УПД в базу.

(85) " проще 10 обработок склепать, чем одну на все случаи жизни."
ну почему - общей на всеслучаи жизни остается только оболочка визуального интерфейса жокументов ЭДО (список, подписание итд, общее для всех провайдеров и для пользователя 1С) а в плагиный выносится конкретная специфика конкретных обмекнов с конкретными провайдерами. Тем более, что если какому-то провайдеру надо влепить какой-нить специфический тег или специфическое содержание атрибута - места расположеняи этих "частностей" известны отсносительно неизменного формата ИФНС и влепить можно что угодно, когда угодно.

(88) ну, в части ТиС и торговли на 77 еще сидит достаточно клиентов.

(88) Понятно, слился ;-) Костыли и велосипеды - наше в все! ;-)

(88) Вик осилил на ТП из 1с++, но там у него Дима просто огонь.
Правда молодость только раз бывает, дальше чуток тупеем ;)
И!!! он вроде осилил все 3 этих оператора. Думаю демку он тебе даст,а может и не демку, это вопрос веры.

(91) Для 7.7 уже достаточно стрероидов сделано, можно еще чуток сделать, главное чтобы там что-то внутри ничего не разорвалось и не сломало всю  вселенную.

(93) Эффект бабочки...

(93) Это уменя сейчас на проекте так.
Вношу изменения вообще минимальные типа косметических и сразы мысл: "А как народ..?!" Вот сейчас от клиента завонили - говорят косяки пошли... ХЗ, то ли я косячнул-тупанул в косметике, то ли исходные данные кривые. Скорее второе - пока все ошибки класса "возвраты раньше реализаций"...

(92) И!!! он вроде осилил все 3 этих оператора.

Да с Диадоком чисто технически проблем нет. Можно было бы сделать, даже в одной обработке со СБИС, не вижу больших сложностей... Они похожи.
Проблема чисто одна - платный API. Мои никто покупать не станут, а самому выкидывать на ветер 13000, делая себе платный аккаунт для отладки и тестов, ну, как-то слишком "кучеряво"... Дали-бы они "на халяву", типа как NFR, для разработчика - тогда другое дело. Хватит с меня и того, что у меня куплены и так все виды ККТ, с которыми работаю у клиентов - себе под тестовые стенды, с тестовыми эмуляторами ФН, и другое оборудование под стенды(сканеры, ТСД, ДП, клавы - я не жадный, все есть :-) )... Нехватало только у Контура еще ключ для API Диадока КУПИТЬ за 13К, без какой-либо перспективы, что затраты отобьются :-(

(96) У меня где то валяется обработка 7.7 интеграции со сбисом. Нужна?

(97) Не, спасибо. Уже своя написана и работает. А типовая, от самого СБИСа у меня есть, мне она не понравилась, она на их ВК SDK сделана, а это "черный ящик". У меня на чистом API, без использования SDK, все прозрачно.

(97)так она на сайте СБИС'а в свободном доступе, ну по крайней мере год назад была, может сейчас и убрали конечно ...

(99) Да есть и даже выпустили обновление под работу через
Версия 2.0.28

    Добавили способ обмена ExtSDK2.
НО это на мой взгляд очень затормозило вывод информации на получение "Отправленных" документов.
Теперь возвращается массив JSON, который 1С парсит ОООЧЕНЬ долго.

(86) (80) Не будут такое чинить, имхо.
Те кто работают уже прикрутили костыли для их НЕСОВСЕМ`json`а, и если испрвят сломается в 100500 местах. Оно им надо?

Не будут... Потому, что чинить то и нечего, как бы не прискорбно это звучадо, но, это карлик уродует ответ :-(

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



Ошибки никакой нет, ответ число -32000, естественно без кавычек, так, как это число. И никакого мусора.

Ладно, предположим это так...
Проверяю этот-же запрос без карлика, через MSXMLHTTP:


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

(101) Скинь ответы, в тексте, а не скрины. Не очень верю, без текстов. Скрины так себе сравнивнивать, тем более что один из филера, а второй из 1С.

Фидлер:
{"jsonrpc":"2.0","error":{"code":-32000,"message":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5075031407/507501001/-/643","details":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5075031407/507501001/-/643","type":"warning","data":{"classid":"{00000000-0000-0000-0000-1fa000010000}","error_code":-1,"addinfo":null}},"id":1}

МелкоСофт XMLHTTP:
СтрОшибка = "{"jsonrpc":"2.0","error":{"code":-32000,"message":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5075031407/507501001/-/643","details":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФи"

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

Карлик:
{"jsonrpc":"2..txt","error":{"code":-32.txt.txt.txt,"message":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5.txt75.txt314.txt7/5.txt75.txt1.txt.txt1/-/643","details":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5.txt75.txt314.txt7/5.txt75.txt1.txt.txt1/-/643","type":"warning","data":{"classid":"{.txt.txt.txt.txt.txt.txt.txt.txt-.txt.txt.txt.txt-.txt.txt.txt.txt-.txt.txt.txt.txt-1fa.txt.txt.txt.txt1.txt.txt.txt.txt}","error_code":-1,"addinfo":null}},"id":1}

Отбросил лень, дописал, вот из мелкософтовского XMLHTTP полностью:
{"jsonrpc":"2.0","error":{"code":-32000,"message":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5075031407/507501001/-/643","details":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5075031407/507501001/-/643","type":"warning","data":{"classid":"{00000000-0000-0000-0000-1fa000010000}","error_code":-1,"addinfo":null}},"id":1}

Один в один с фидлером. Ошибка там 500 возвращается, а строка в описании ошибки.

Если нужно, сам запрос:
{"jsonrpc": "2.0", "method": "СБИС.СписокДокументов", "params": {"Фильтр": {"Тип": "ДокОтгрВх", "НашаОрганизация": {"СвЮЛ": {"ИНН": "5075031407", "КПП": "507501001", "КодСтраны": "643"}}, "ДатаС": "01.01.2024", "ДатаПо": "31.01.2024", "Навигация": {"РазмерСтраницы": "20", "Страница": "0"}}}, "id": 1}

(103) Очешуенно. Это кошмар! Ну реально кто-то лезет у тебя в память карлика, количество "txt" зашкаливает. Деодирование из xml (utf8->1251), видимо так глючит, похоже похоже на это, но оно же как-то без сбоев было. Не понимаю как так глючит.

Ты знаешь, в остальных местах все идеально работает. В строки ответов нормально выводит и JSON и XML. Это только там проявляется, где ошибка "-32000"...
Есть идея, сейчас сделаю у карлика Приемник.Тип = 1, и посмотрим, что он сам в файл выведет..

(105) Филиал мне не нравится (минус в ответе). Может вставить "КодФилиала":""
?

(107) Ты знаешь, в файл выводит правильно:
https://cloud.mail.ru/public/ZnYd/CkbhHKT65
это только в строку уродуется ответ...

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

(108) Можно попробовать, но, вроде по описанию параметр не обязательный, обязательный там только "Тип", в моем случае: "Тип": "ДокОтгрВх"...

(109) И на картинке /-/ вместо кода филиала. Дубль два - попробуйте всё же поиграться с пустым значением. Пруф:
https://sbis.ru/help/integration/api/all_methods/our_company

Вот:

{"jsonrpc": "2.0", "method": "СБИС.СписокДокументов", "params": {"Фильтр": {"Тип": "ДокОтгрВх", "НашаОрганизация": {"СвЮЛ": {"ИНН": "5075031407", "КПП": "507501001", "КодФилиала": "", "КодСтраны": "643"}}, "ДатаС": "01.01.2024", "ДатаПо": "31.01.2024", "Навигация": {"РазмерСтраницы": "20", "Страница": "0"}}}, "id": 1}

Ответ:

{"jsonrpc":"2..txt","error":{"code":-32.txt.txt.txt,"message":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5.txt75.txt314.txt7/5.txt75.txt1.txt.txt1//643","details":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 5.txt75.txt314.txt7/5.txt75.txt1.txt.txt1//643","type":"warning","data":{"classid":"{.txt.txt.txt.txt.txt.txt.txt.txt-.txt.txt.txt.txt-.txt.txt.txt.txt-.txt.txt.txt.txt-1fa.txt.txt.txt.txt1.txt.txt.txt.txt}","error_code":-1,"addinfo":null}},"id":1}

Еще раз, если кто-то не в теме: данные организации там умышленно не те, что в получении "ID_Сессии", так, что - ошибка возникает верно. Вопрос, почему она в таком виде возвращается в строку ответа.

(112) Чудес не бывает. Приёмник не съедает блок НашаОрганизация
Ройтесь в нём. Например, вообще оставить только ИНН и КПП:
{"ИНН":"5075031407", "КПП":"507501001"}

(113) Ну Вы даёте )

(115) (113) Ну Вы даёте )

А чего даю? :-)  Тестирование и отладка во всех варитантах, которые могут встретиться в работе. Вот оно и "вылезло" :-(

(114) Приемнику вообще по барабану блоки запроса. Это дело источника. Приемник должен глотать прилетевшую с сервера строку и передавать ее как есть, без изменений.

Вообще, из другой базы, тоже с заполненным блоком "НашаОрганизация", правда не ЮЛ а ИП:

Запрос:

{"jsonrpc": "2.0", "method": "СБИС.СписокДокументов", "params": {"Фильтр": {"Тип": "ДокОтгрВх", "НашаОрганизация": {"СвФЛ": {"ИНН": "240402520755", "КодСтраны": "643"}}, "ДатаС": "01.01.2024", "ДатаПо": "31.01.2024", "Навигация": {"РазмерСтраницы": "20", "Страница": "0"}}}, "id": 1}

Ответ:

{"jsonrpc":"2.0","result":{"Документ":[],"Навигация":{"ЕстьЕще":"Нет","РазмерСтраницы":"20","Страница":"0"}},"id":1}

Ошибки нет, но и данных там не за этот период, все так.
Т.е, блок "НашаОрганизация" обрабатывается.

А вот, предыдущий тест, тело запроса то-же, но ID_сессии я "левый" для той организации подсунул(свой):

{"jsonrpc":"2..txt","error":{"code":-32.txt.txt.txt,"message":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 24.txt4.txt252.txt755/-/-/643","details":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 24.txt4.txt252.txt755/-/-/643","type":"warning","data":{"classid":"{.txt.txt.txt.txt.txt.txt.txt.txt-.txt.txt.txt.txt-.txt.txt.txt.txt-.txt.txt.txt.txt-1fa.txt.txt.txt.txt1.txt.txt.txt.txt}","error_code":-1,"addinfo":null}},"id":1}

Все то-же самое.

(112) Скинь бинарные данные из загруки через файл, они без декодировки должны быть. И ты откатил тестовую на последнюю 1.0.0.14? Тестовая совсем еще не готова - слишком много изменений. Так быть не должно в принципе, у тебя 0 заменяется на ".txt", я такое не кодил, это маразм какой-то.

Версия 1.0.0.14, последняя стабильная. 15 у меня на Win-7 падает сразу, не зависимо от порядка загрузки компоненты/создания объекта.

А что значит "Скинь бинарные данные" - ? Как их получить? Или это файл из приемника с параметром Тип = 1 - ??? Если так, то файл в (109), в нем внутри все ОК, если нет, то напиши как...

Или вот это надо добавить: Карлик.Приемник.Кодировка = 1 - ???

(120) Да, вот файл без перекодировки, в utf-8 прилетел, но без мусора: https://cloud.mail.ru/public/z9ve/KPL9LHJFN

+(121) Ну, на самом деле и с Карлик.Приемник.Кодировка = 0 все то-же самое прилетает, файл без без мусора в utf-8.
Ошибка только если Тип = 0 в возвращаемой строке...

(119) Нашел, через файл все ок, тогда это внутренний глюк libcurl, декодирование идет почти на автомате, давай трассировку из 1с, может хидеры дурные? Файл в uft8, но без bom, поэтому декодирование может сбоить.
Почему замена на ".txt" на "0"? "0" это же символ. Это интересная загадка.
Ну раз через файл работает, ну тогда так и придется, это и не приятно, но лучще так чем никак.

Дальше, если в Карлика передать параметры:

Карлик.Приемник.Тип = 0
Карлик.Приемник.Кодировка = 1

То строка возвращается нормально:

{"jsonrpc":"2.0","error":{"code":-32000,"message":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 240402520755/-/-/643","details":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 240402520755/-/-/643","type":"warning","data":{"classid":"{00000000-0000-0000-0000-.txtfa0000.txt0000}","error_code":-.txt,"addinfo":null}},"id":.txt}

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

(123) Ща сделаю...

Вот, там "мульен строк", поэтому файлом: https://cloud.mail.ru/public/ZNQY/EaJUJ2rzz

(123) Ну раз через файл работает, ну тогда так и придется, это и не приятно, но лучще так чем никак.

Это да, но как выяснилось и строкой работает, если перекодировку отключить, цитата из описания: "Карлик.Приемник.Кодировка = 1 перекодировки не происходит"

(126) но как выяснилось и строкой работает

А вот и нет :-(  Работает, но не до конца:

{"jsonrpc":"2.0","error":{"code":-32000,"message":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 507503.txt407/50750.txt00.txt//643","details":"Не найдена действующая, доступная по правам наша организация ИНН/КПП/КодФилиала/КодСтраны 507503.txt407/50750.txt00.txt//643","type":"warning","data":{"classid":"{00000000-0000-0000-0000-.txtfa0000.txt0000}","error_code":-.txt,"addinfo":null}},"id":.txt}



Такой фигни ".txt" меньше, в первом реквизите ответа все ОК, а дальше все равно вылезает...

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

(128) Ну, ты оптимист, надеяшься на следующую :-)

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

А ты все равно, рано или поздно будешь собирать следующую версию, подумай, может получится обойти этот глюк...
Если от меня нужно будет что-то, какие-то файлы, логи и т.п. - пиши, я как пионер(блин, пенсионер :-((( ), "Всегда готов!" :-)

PS Но, отключение перекодировки Карлик.Приемник.Кодировка = 1 все равно оставлю. Пусть будет...

Всем здравствуйте :-)
Подниму тему...
Все работает - получение доков, загрузка в 1С, подписание(утверждение в их терминах), получение печатных форм в PDF при желании, в том числе "Справки по прохождению документа".
Осталось сделать "Отказ" и "Запрос уточнения".
И если с отказом более менее понятно, это бычный этап утверждения, только действие "Отклонить", осталось сделать и протестить, то с запросом уточнения ни где не могу найти как правильно его делать...
Кто работает со СБИС через API, пожалуйста ткните носом где почитать про это действие, или "на пальцах" объясните как это у них делается?

+(130) то с запросом уточнения ни где не могу найти как правильно его делать...

Нет, ну, я так понял из "талмуда", что это делается отправкой акта о разногласиях, в котором по проблемным позициям вносятся изменения и он отправляется поставщику. Поставщик при получении его утверждает, и высылает новую редакцию документа отгрузки.
Но, позвонил сегодня клиентам - говорят - "какие еще акты??? Не делаем мы ничего такого, просто отказываем накладную и в комментариях(в ЛК СБИС он делается обязательным, если отказ) просто пишем "ВЫЧЕРК""... А говорю, как они узнают, что именно не так? А говорят, бумажку с водителем/экспедитром передаем, или по телефону согласовываем...
В общем, упростили схему, практически как в ЭДО лайт работают, только там в таких случаях идет не отказ, а запрос уточнения, тоже без конкретики по каким позициям, что не так. Тут, похоже такого нет.
Имеет эта схема право на жизнь? Так и сделать "Отказ с обязательным комментарием", или все-таки городить "Акт разногласий", как это задумано по НПА - ???

PS НПА - конечно "закон", но в ЭДО лайт от ЦРПТ обходятся без этого, значит можно и тут обойти? Чем это чревато?

(130) И если с отказом более менее понятно, это бычный этап утверждения, только действие "Отклонить", осталось сделать и протестить.

Сделал... Но, как тут выше и говорили, путано очень в "этапах и действиях".
Формирую документ "СБИС.ПодготовитьДействие" этап "Утверждение", действие "Отклонить".
Потом, пытаюсь "СБИС.ВыполнитьДействие", взяв данные из предыдущего... Не тут-то было, документ сформировон как "Уведомление об уточнении", а не нак документ поступления... С чего-бы-? Нигде ни слова об уточнении не было, делал просто как "Отклонить"... Ладно, не проблема, вот только что с ним делать, отклонять или утверждать? По логике - надо бы утвердить, но... Логике это не поддается, делаю действие "Отклонить", и весь документ отклонен, в таком-же статусе как они раньше из ЛК делали... Может правильнее его былобы утвердить, и тогда статус стал-бы что-то типа "Запрошено уточнение" - ?
Кто-нибудь сталкивался с этой "кухней" - ?

(132) Разобрался, и сегодня отладил у клиента.
В общем, может будет кому-то полезным:

В отличии от ЭДО лайт, у СБИС нет команды "ЗапроситьУточнение", это у них все "Отклонение", с обязательным комментарием поченму отклоняем. Оно подписывается(Этап "Утверждение", действие "Отклонить").
В ответ поставщик присылает корректирующий документ, содержащий только позиции по которым корректирповка. В свою очередь, мы его подписываем точно так-же, как обычный входящий. В базу его грузить нет смысла, так, как все давно загружено и откорректировано в своей накладной при получении первого(с вычерками) документа. Но, можно распечатать или сохранить при желании.
Вот как-то так.
Буду считать, что "этап внедрения СБИС в свою УС" успешно завершен, без всяких "ихних черных ящиков"(SDK)  :-)

(133) кривая концепция. получается вы ведете два учета - один "похер на эдо", второй "эдо наше все".
.
Накладная С ВЫЧЕРКАМИ сделанными на бумажном экземпляре - исходная накладная АННУЛИРУЕТСЯ КАК БУДТО ее не было. Вы же документ НЕ ПОДПИСАЛИ (в т.ч. и по эдо - отклонили). Вместо нее делается новая накладная. Без всяких корректировок. Если вы "вычерки" оформили правильным образом - с выставлением офиуиального акта претензий - тогда исходная накладная не перевыставляется, вы ее подписываете вместе с актом, на основании акта выставляется корректировка.
.
примерно так.
вообще все это эдо - полня ху..я, извините за выражение. И имеет смысл только если все оформляется и ходит без бумажных дублирующих копий, а во многих случаях без них не обойтись. и начинается тряхомудия. если бумажную копию подпислаи, а ЭДО - нет - где правда? что в договоре сказано насчет того, какой документ является определяющим - ЭДО или бумажный?
.
короче хрень это. Только лишняя работа дублирующая.

(134) исходная накладная АННУЛИРУЕТСЯ КАК БУДТО ее не было

Я тоже раньше так думал, но нет. Она не анулируется, а запрашивается уточнение, хотя команда "Отклонить"... При этом комментарий - обязательный реквизит.
В ответ поставщик присылает корректирующий документ, только на позиции "вычерков".

Со всем остальным - согласен, но, не я это придумал и не мне менять...
С тем, что первично - "курица или яйцо", я х.з., я не юрист их договара читать и вникать в их суть. Я сделал так как и "пешком" без API, в WEB-интерфейсе ЛК это работает. А кому надо юридические тонкости, пусть сами вместе со СБИС решают :-)

Мне больше другое не нравится...
При получении списка входящих документов, можно задать фильтр. В фильтре есть реквизит "Тип"*: строка, тип документа, обязательный параметр...
Строка блин!!!
Я не могу туда передать список типов, которые хочу видеть в списке, и не могу не указать его совсем - он обязательный...
Да и фиг бы с ним, но, и в самом списке косяки:



Позиция "Договор" повторяется дважды, и для обеих пунктов есть оба направления и "Входящий" и "Исходящий"...
Чем они отличаются?
И почему не сделать возможность отображения всех документов как в ЛК - ??? Зачем обязательность фильтра по типу доков...
Если передать туда "", то возвращается:
"Не допускается запрашивать список документов без фильтра по типу документа. Укажите в фильтре тип документа"

(136) При работе черз их dll можно передать список документов указав их через запятую без пробелов. типо так "УпдСчфДоп,УкдКсчфДис,СчФктр,ЭДОНакл,счФактКор"
Может и через api так сработает?

(137) Спасибо!
Но, нет... Через API так не заработало...

Ошибки не пишет, но и список пустой, ни одного документа в отбор не попадает, если делаю так:
Фильтр.ДобавитьЗначение("ДокОтгрВх,CorrIn,АктСверВх",     "Тип");
Если вставляю Ваши значения, так:
Фильтр.ДобавитьЗначение("УпдСчфДоп,УкдКсчфДис,СчФктр,ЭДОНакл,счФактКор", "Тип");
То ошибка:
"Указан неизвестный тип документа 'УпдСчфДоп'"
Так: Фильтр.ДобавитьЗначение("ДокОтгрВх",     "Тип"); работает, один документ у меня там есть, его показывает.

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

(138) Получается через апи и длл работает по разному :( жаль
мои значения вот отсюда
https://sbis.ru/help/integration/catalog/guide
из раздела Типы вложений документа
Т.е. при работе через их компоненту я просто указываю типы вложений которые хочу получить и сбис отдает мне документы только с этими типами.

(139) Ну, да... У них даже в талмуде разные ветки для API и СбисКоннект. Мои значения отсюда: https://sbis.ru/help/integration/api/doc_guide

Я тоже указываю нужное значение, и сбис отдает только доки с этим типом. Но, только одно значение принимается.
Вообще, странная у них логика... Где надо и не надо, принимаются значения в виде объектов(массив JSON). А тут, строка, и соответственно одно значение, хотя сюда массив значений прямо "просится" :-(

(140) Ну там тоже есть раздел Типы вложений, и все, что я приводил для примера. Может надо где-то указать не только тип документа ДокОтгрВх но и тип вложений перечисленных через запятую Документ.Вложение.Тип = "УпдСчфДоп,УкдКсчфДис,СчФктр,ЭДОНакл,счФактКор";

(140) Попробуйте получать документы через СБИС.СписокДокументовПоСобытиям Там есть типы вложений
https://sbis.ru/help/integration/api/all_methods/events_doc

(140) Так пообщайтесь с их техподдержкой, может укажут - как правильно обращаться.

(135) Вы, блин, определитесь с какими вы документами работаете? если вычерки делаются в бумажной накладной - какого фига сюда приплетать эдо? отправляйте эдо, когда отработаете  бумажный вариант с вычерками - отправляйте уже исправленную ЭДИО как первоначальный оригинал.
Нафиг этот гемороой?

Если работа идет по ЭДО - пусть там хоть навычеркивают дохрена всего. Пока по эдо не дадут ответ - пофиг на все вычерки в бумаге.
как-то так..?

(145) Так. Только вычерки мы делаем. У меня мелкие розничные магазинчики, только входящие доки. Никому ничего мы не отправляем, только получаем и продаем через ККТ. И если вычерки и бывают, то на нашей стороне.

(143) Пообщаюсь. Чуть позже, это пока не самое важное. С двумя строками "Договор" выяснил у них. Там есть три типа документа "Договор". В двух, явно указано направление, а в третьем, который ДоговорДок, нужно указывать дополнительно. В общем, для моей задачи достаточно ДоговорВх.

Я что-то столкнулся с проблеммкой, откуда не ждал... Пятый день бьюсь, и никак не могу понять - что я не так делаю???
Когда стандартный входящий документ, например УПД или накладная, с одним вложением - все хорошо, нет проблем, все подписывается(Утверждается в их терминах), или отклоняется(Создается запрос уточнения).
Но, как только документ содержит несколько вложений ПЕРВИЧНЫХ ДОКУМЕНТОВ - например, три - Счет, Акт вып. работ, и СчетФактура, то хотоь ты тресни, при попытке выполнить действие, возвращается ошибка:

"{"jsonrpc":"2.0","error":{"code":-32000,"message":"При закрытии события на утверждение возникла ошибка:\nНет подписи под первичным документом (ON_SCHET___20220305_64e422e0-d807-4785-9b2c-47d3513a55f1) с идентификатором - e2f7d8e2-e56c-4547-a05f-21d46eec5c61","details":"При закрытии события на утверждение возникла ошибка:\nНет подписи под первичным документом (ON_SCHET___20220305_64e422e0-d807-4785-9b2c-47d3513a55f1) с идентификатором - e2f7d8e2-e56c-4547-a05f-21d46eec5c61","type":"warning","data":{"classid":"{00000000-0000-0000-0000-1fa000100000}","error_code":-1,"addinfo":null}},"id":1}"

Что значит нет подписи??? Все я подписываю, каждое вложение из прилетевшего от них дока-ответа на запрос "Подготовки действия", в том числе и этот пресловутый счет, все ЭЦП вложений валидны, проверил, и передаю строками "двоичных данных" в запрос выполнения действия...
Во вложении файлы:

PodgEtap_1a02bb50-ba2d-4539-9d07-30310a07039c.txt - подготовленный этап, то, что "прилетело от них".
ТелоЗапрВыпДействие.txt - Запрос, который я отправляю на последнем этапе выполнения действия.
ВыпДействиеКарл.txt - ответ сервера на этот запрос
Так-же, там в отдельных подкаталогах сами вложения с их ЭЦП и протоколами их проверки.

Вроде все красиво, но не работает... Убей, не пойму, что я не так делаю?

Архив со всеми файлами: https://cloud.mail.ru/public/tCFp/UAStXN7ny

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

Техподдержка пока молчит :-(

Ответила техподдержка :-)
В общем, косяк у меня в синтаксисе JSON.
Там список вложений нужно в виде массива передавать, т.е. все значения этого списка должны быть одним массивом, в квадратных скобках:



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



А без этого, их сервер воспринимает первое значение, а остальные не видит.
В общем, поправил у себя в программе, теперь подписывает все, не зависимо от количества вложений :-)

(148) ты прям сильный колдун
Ещё бы сделал чтобы эта подсистема ставилась на типовую ТИС...?

(149) на типовую ТИС...?

Теоретически, конечно можно все собрать в кучу, что у меня по всей конфе раскидано... Но, влом...Я не уверен, что на закате эры семерки, кто-то в типовых работает. Много еще народа работают, но большинство именно по тому, что их конфы пилены/перепилены, и от типовых там мало что осталось.
Потом, перенести часть обмена со сбис можно, и не сказать что-бы сильно сложно, даже можно в виде внешней обработки сделать, а вот часть работы с номенклатурой, все сопоставления, создания новых товаров и контрагентов, поиск и привязка старых... Ну, очень там наворочено, сложно будет с типовой подружить. А без этого теряется половина смысла всей этой затеи, с таким-же успехом можно и их типовую обработку использовать.

(149) Так есть же у нас для типовой ТИС. Не только для приемки, но и для отгрузки. Через АПИ.

(151) это да...

Всем доброго дня! Подниму тему.
Пользуемся обработкой СБИС для работы с ЭДО (ну как пользуемся, очень мало, для особо вредных клиентов), вопрос можно как то используя функционал обработки выгрузить в формате XML - документ реализация ?

(153) Там ведь есть кнопка с дискетой - сохранить пакет, чем не устраивает?

(154) в упор не вижу "дискетки"

(155) У тебя древняя обработка

(156) самая последняя с сайта СБИС

(155) Зайди в просмотр документа, там есть и для полученных, и для отправленных

(158) просмотр по дабл клику на документ ? У меня ничего не происходит.

Я здесь - пас... Типовую толком и не смотрел. Пользуюсь своей. Но, и то у меня по специфике клиентов, только входящие.

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

(161) да спасибо, разобрался.