search

diadoc / diadocsdk-csharp

Official Diadoc SDK for C#
MIT License
35 stars 64 forks source link

Где взять BoxId в GUID формате для УПД по 820 приказу? #576

Open Edward72 opened 5 years ago

Edward72 commented 5 years ago

В теле запроса GenerateTitleXml нужно заполнять BoxID продавца и покупателя. Формат требуется GUID. API Диадока позволяет нам получить идентификатор ящика вызовом GetBox. Но в ответе мы получаем идентификатор вида "97be5d3704394d62bf40442dcb2489b8@diadoc.ru", что совсем не похоже на GUID. Вопрос: где брать идентификатор ящика в GUID формате?

OlgaPetushina commented 5 years ago

@Edward72 Добрый день. Вы не тот метод используете для получения boxid. GetBox в качестве параметра на вход принимает boxid, если вы его не знаете - метод бесполезен. В вашем сценарии нужно использовать метод http://api-docs.diadoc.ru/ru/latest/http/GetOrganization.html Полученный идентификатор следует преобразовать в guid самостоятельно. Guid.Parse(fullyQualifiedBoxId.Substring(0, fullyQualifiedBoxId.IndexOf('@')))

Edward72 commented 5 years ago

В части получения идентификатора ящика вы правы. Это я неправильно указал метод, конечно же GetOrganization и далее по списку ящиков получаем их идентификаторы (непонятно только, зачем список, если ящиков всегда один). А вот в части преобразовать самостоятельно можно подискутировать. Да это не сложно, да, я это в итоге так и сделал. Но возникает вопрос о единообразии данных в API Диадока. Почему в одном случае BoxId должен быть такого вида "97be5d3704394d62bf40442dcb2489b8@diadoc.ru", а в другом "97be5d37-0439-4d62-bf40-442dcb2489b8"? Уважаемые разработчики, объясните вашу логику!

OlgaPetushina commented 5 years ago

@Edward72 boxid возвращается в таком виде в целях обратной совместимости. Мы планируем поднять версию метода и возвращать BoxId как guid. Сроков нет пока.

Edward72 commented 5 years ago

Ок. Поясните тогда по списку ящиков. Зачем в структуре Organization ящики представлены в виде списка? Бывают ли ситуации когда их больше одного?

OlgaPetushina commented 5 years ago

Да, бывают. Если запрос не по конкретным orgId или boxId, а по ИНН или ИНН-КПП, то могут вернуться - роуминговый (если есть), тестовый ящик (если есть), все ящики с данным ИНН, но разными КПП (филиальная структура).

Edward72 commented 5 years ago

Тогда объясните в чем смысл плодить контрагентов в справочнике? Например контрагент с ИНН 7740000076 КПП 997750001. В справочнике он представлен два раза. Первый: ID участника ЭДО: 2KY-7740000076-997750001-1702201 - Роуминг (МТС), второй: ID участника ЭДО: 2BM-7740000076-2012060107272343894520000000000. Почему не как один контрагент с двумя ящиками?

alogicman commented 5 years ago

Ок. Поясните тогда по списку ящиков. Зачем в структуре Organization ящики представлены в виде списка? Бывают ли ситуации когда их больше одного?

Это опять для обратной совместимости: когда-то давно у одной организации могло быть несколько ящиков. Сейчас понятия организации и ящика фактически смешались, так как их отношение 1:1 — у организации ровно один ящик.

Когда-нибудь мы приведем все в единообразное состояние — везде будет использоваться нормальный boxId, а у организации не будет массива ящиков :)

Edward72 commented 5 years ago

Да, бывают. Если запрос не по конкретным orgId или boxId, а по ИНН или ИНН-КПП, то могут вернуться - роуминговый (если есть), тестовый ящик (если есть), все ящики с данным ИНН, но разными КПП (филиальная структура).

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

А на вопрос:

Тогда объясните в чем смысл плодить контрагентов в справочнике? Например контрагент с ИНН 7740000076 КПП 997750001. В справочнике он представлен два раза. Первый: ID участника ЭДО: 2KY-7740000076-997750001-1702201 - Роуминг (МТС), второй: ID участника ЭДО: 2BM-7740000076-2012060107272343894520000000000. Почему не как один контрагент с двумя ящиками?

никто не ответил. С каким контрагентом мне работать? Если их два, с одинаковым ИНН/КПП?

NataliaShumikhina commented 5 years ago

Никаких противоположных мнений нет. Организация=Ящик=уникальная связка ИНН-КПП-Id участника ЭДО-признак тестовая/роуминговая/реальная

Это всё нормальные ситуации.

Если вы получили в ответе несколько ящиков, то вы сами выбираете, с каким работать:

Edward72 commented 5 years ago

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

i82 commented 5 years ago

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

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

Edward72 commented 4 years ago

Опять про ящики. Есть контрагент. Подразделение ПАО "Ростелеком" ИНН 7707049388 КПП 860143001. GetOrganization ищем по ИНН/КПП, находим, отправляем приглашение. И что? И ничего. А почему? А потому что, этот ящик они когда-то использовали, но потом все поменялось. У них теперь другой ящик. А старый остался висеть, непонятно зачем. А новый ящик где? А внутри ящика другого контрагента, у которого КПП 66854300. Это Макрорегиональный филиал «Урал». Но господа, в договоре с этим контрагентом КПП 66854300 не прописан! У нас есть КПП головы 770545001 и собственно грузополучателя КПП 860143001. Руками конечно все можно настроить, но мы говорим об интеграции. Итак, есть ИНН/КПП головы и грузополучателя. Ищем GetOrganization по ИНН/КПП грузополучателя, находим, приглашаем и тишина. Что дальше? Ок. Ищем только по ИНН. Находим 66 организаций! Куда дальше? Мне что, нужно лепить в программе костыль, где указывать, что в Диадоке работаем через конкретный КПП? Ок. Допустим. Следующий вопрос. В поддержке мне объяснили, что направляя формализованные документы с КПП грузополучателя в ящик филиала "Урал", документы перенаправятся в ящик нашего потребителя. А что делать с неформализованными документами? Куда их слать? На деревню дедушке? Когда наконец логику работы с Диадоком приведут в нормальный вид?

i82 commented 4 years ago

Структуру филиалов каждая компания формирует самостоятельно, как и принимает решения об удалении ящиков. Мы не можем гарантировать работу Ростелекома, информация о том, куда следует отправлять документы вам необходимо согласовать с контрагентом.

Маршрутизация неформализованных документов не производится т.к. Диадок не может определить из контента, куда его требуется смаршрутизировать. Для маршрутизации таких документов нужно явно указывать подразделение получателя при отправке.

Edward72 commented 4 years ago

Речь идет не о структуре филиалов. А о том, что Диадок не позволяет работать с филиалами, не заморачиваясь с той самой структурой филиалов. Мне то какое должно быть дело до их структуры? Сегодня она одна, завтра другая. Есть ИНН/КПП получателя. Все. Больше ничего не должно быть нужно. И слова "Диадок не может", которые звучат из уст разработчиков того самого Диадока, выглядят как минимум неубедительно. Как максисмум: типа, мы тут сделали кое как, пользуйте как хотите и как можете, мы ничего переделывать не будем...

i82 commented 4 years ago

ToDepartmentId в методе отправки.

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

Edward72 commented 4 years ago

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

i82 commented 4 years ago

Попрошу вас воздержаться от оценочных суждений.

Это пожелание по доработке тоже зафиксировал, но в ближайшие задачи она не попадёт

Edward72 commented 4 years ago

Как и вот это:

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

Originally posted by @i82 in https://github.com/diadoc/diadocsdk-csharp/issues/525#issuecomment-585645116

Это значит только одно: Никогда.