diadoc/diadocsdk-csharp

Обращение к интеграторам

flosca opened this issue · 24 comments

Привет всем интеграторам Диадока.

Появилось ощущение, что документация выглядит довольно непричёсанной и запутанной. Бывают случаи (1, 2), когда за помощью приходят сюда, хотя ответы на эти вопросы должна давать документация.

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

Хочется собрать обратную связь от вас, насколько хорошо описаны наши SDK-клиенты. Часто ли вы обращаетесь за помощью в документацию? Будем очень признательны любому фидбеку. Пожелания, замечания, всё пригодится.

Свои мысли можно высказывать прямо здесь :)

Добрый день.

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

Имею в виду следующее:

  • Статья про подписание документа. Составить список документов, которые нужно подписывать напрямую и через генерацию титула, добавить ссылки на примеры (уже есть в примерах работы с СФ, накладными. С НФ тоже где-то было, кажется). Добавить, что есть возможность отправить документ без подписи, чтобы он висел в отправленных в кабинете.
  • Статья про аннулирование документа. Описать обычный механизм запрос -> аннулирование, описать возможность одностороннего аннулирования, когда документ подписан только с одной стороны. Добавить, что после отказа в аннулировании и повторном запросе сущности от прошлого аннулирования удаляются из сообщения (при обработке изменений через GetNewEvents тогда приходят эвенты, у которых сущность и ее род. сущность не содержится в сообщении, долго разбирались в чем дело). Указать, что в роуминге документ не всегда поддерживает аннулирование и может возникнуть ошибка.

Не помешала бы статья про получение изменений в ящике и соответственно в документах. Разные варианты и решения. В последней интеграции мы все изменения анализируем по BoxEvent, поэтому приходится изучать какие действия как выглядят в эвентах. Простые еще понятно, но одностороннее аннулирование не помню чтоб было описано где-то. До сих пор остались неизвестными некоторые случаи (эвент без патча и сообщения, патч к подписи, которой нет в сообщении и пр.)

Хотелось бы больше примеров.

добрый день. Хотелось бы пример заполнения GenerateSenderTitleXml, а именно что передавать в usercontractdata

@sylfire
Привет.

Но ведь на этой странице есть и пример, и инструкция: http://api-docs.diadoc.ru/ru/latest/http/GenerateSenderTitleXml.html

В теле запроса должен содержаться заполненный XML-файл, соответствующий XSD-схеме контракта для генерации титула отправителя данного типа документа. XSD-схема контракта, необходимого для генерации титула, может быть получена с помощью ссылки, доступной в поле UserDataXsdUrl контракта DocumentTitle, который можно получить с помощью метода GetDocumentTypes.

@flosca
Пример не в виде работы sdk
http://api-docs.diadoc.ru/ru/latest/howto/example_send_invoice.html нужны примеры как тут
SDK
Пример кода на C# для отправки счета-фактуры:

очень удобно и понятно.

Народ, привет..может кто нибудь дать комментарии как метод GenerateSenderTitleXml работает? xml самим создавать и потом в параметр передавать?
"XSD-схема контракта, необходимого для генерации титула, может быть получена с помощью ссылки, доступной в поле UserDataXsdUrl контракта DocumentTitle, который можно получить с помощью метода GetDocumentTypes." - не совсем понимаю, как это в коде должно выглядеть

В документации не хватает примеров типа:
скопировал код --> вставил к себе -->код отработал без ошибок -->
-->понял как работает -->исправил под себя.
Например такой вариант пригодился бы сейчас для 820-го приказа.
Если бы была XML-ка, которую можно было бы подставить в GenerateTitleXml и получить положительный ответ на тестовых ящиках. Было бы здорово!

По ФНС 820 решение выглядит крайне сырым, что в плане кода, что в плане документации. Я б даже не назвал это решением, скорее что-то в духе "вон там XSD схема от ФНС, а вот вам два куска кода из первых ссылок StackOverflow, мы это не проверяли, но вы сами разберетесь". По сравнению с предыдущими решениями, когда Диадок предоставлял человеческое API со строгой типизацией, это ужасно.

MayerS2006, да согласен, решение сырое, но альтернативы к сожалению пока нет.
Хотя нет...
Есть СБИС.

Добрый день. Возник вопрос при формировании УПД для отправки.
В УПД есть строка :
Основания передачи (сдачи) / получения (приемки) (9)
Какое свойство UniversalTransferDocumentWithHyphens отвечает за заполнение этой строки?

i82 commented

@Kofeint вам поможет структура TransferInfo, в частности TransferBases

Мы планируем освежить информацию,

Прошло почти два года, а воз и ныне там...

В документации Диадок API в структуре TransferBase есть поле:
optional string BaseDocumentDate = 3;
То есть, судя по описанию, это поле не является обязательным. Но если я указываю как основание номер договора (BaseDocumentNumber), а поле BaseDocumentDate оставляю пустым, то конечно же получаю ошибку: AdditionalMessage=Invalid data UserContractData:/UniversalTransferDocument/TransferInfo/TransferBases/TransferBase: @BaseDocumentDate is required
Как это понимать? И что делать? Объясняю, почему оно должно быть на самом деле "optional".
В нашей энергосбытовой компании, при заключении договоров с бюджетниками, часто бывает такая ситуация: договор как бы еще не заключен, а электроэнергию уже нужно отпускать потребителю в счет заключаемого договора. договор может заключаться и месяц, и два. Это очень распространённое явление. Как в таком случае я должен указать основание передачи объемов потребления в УПД?

Добрый день!
Таким образом мы поддержали требования 820 формата по заполнению ДатаОсн. В вашем случае форматом предполагается указывать НаимОсн = "Без документа-основания". Тогда в UserContractData не нужно указывать TransferBase либо указывать TransferBase с BaseDocumentName = "Без документа-основания", но без указания BaseDocumentNumber и BaseDocumentDate.

Каким таким образом? И что поддержали? То что документация ни к черту? Коммерческая компания, которой мы платим с каждого отправленного документа, не может привести документацию в порядок!!!

То что можно заполнить "Без документа-основания" я и сам видел. Только вот вы сможете объяснить контрагентам-бюджетникам, почему они должны принять УПД без указания номера договора как документа основания?

i82 commented

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

Проектный номер договора невозможно указать в BaseDocumentNumber без даты договора, я уже об этом написал выше. Пока буду писать номера таких договоров в поле ИнфПолФХЖ1 и "Без документа-основания". Но в документации можно было бы сделать оговорку, что BaseDocumentDate - optional, но только если Без документа-основания", иначе required.

Коллеги, разработчики, подскажите, пожалуйста .

Есть такая задача.

Наши клиенты хотят подписывать заявку на перевозку(это документ формата pdf) в нашем личном кабинете.

Из вашей документации, на примере документооборота с актом, следует:

  1.   Мы должны подписать документ, добавить документ и подпись в сообщение и отправить сообщение в ящик нашего клиента
    
  2.   Клиент получает наше сообщение
    
  3.   Клиент формирует свой «титул», подписывает «титул», формирует «патч» и добавляет к сообщению «патч» со своей подписью
    

Вопрос:

Если мы опустим пункт 2, а просто поставим подпись клиента на его "титул"
(с нашим авторизационными данными, но используя ЭЦП клиента) и
добавим «патч» подписанный клиентом к сообщению из пункта 1.

То в ящике клиента сообщение("цепочка") обновится? Он увидит, что подписал документ?

Если нет, то как реализовать хотя бы на пальцах расскажите? Ключ АПИ используется только наш.

Duplicate of #899

Не понятно как с начала октября генерировать UniversalCorrectionDocument ведь его структура в https://api-docs.diadoc.ru не описана, приходится наугад заполнять ее на основании ранее сделанного кода для 820 и того, что было при использовании UniversalTransferDocumentSellerTitleInfo.
В результате получаю ничего не говорящую ошибку при использовании GenerateSenderTitleXml. Просто чудесно.

@svsavin здесь описана структура UniversalCorrectionDocumentSellerTitleInfo.
Также описание типа документа и его xsd-схему вы можете получить в ответе метода GetDocumentTypes.

Добрый день! Подскажите пожалуйста, есть ли возможность получить наименование роуминга контрагента? А то не нашел такой информации в документации.

@MichaelBlack17 Добрый день!
Вы имеете в виду оператора роумингового контрагента? Если так, то сейчас нет возможности получить его через АПИ.

Добрый день! Подскажите пожалуйста, как добраться до комментариев, которые оставляют пользователи в процессе документооборота, например прb отказе в подписании, при аннулировании документа и прочее (надеюсь, на картинке видно), в структуре DocFlowEventV3

image

При изучении документации по V3 складывается такой алгоритм:

  1. получить статус
    var resStatus = docFlowEventV3.Document.Docflow.Resolution.ResolutionStatus;
  2. получить ResolutionEntityId
    var reId = docFlowEventV3.Document.Docflow.Resolution.ResolutionEntityId;
  3. в зависимости от ResolutionStatus вытащить сущность Entity
    var entity = docFlowEventV3.Document.Docflow.ResolutionEntities.Requests[reId]
  4. вытащить комментарий из entity.Content.Data

Но по факту получается что entity.Content.Data==null всегда.

Подскажите пожалуйста, в чем ошибка или непонимание?

Если кому будет полезно, решение проблемы:

поле Data заполняется в том случае, если в фильтре запроса событий установлен флаг InjectEntityContent = true, по умолчанию он false

var res = _context.Api.Docflow.GetDocflowEvents(
_context.Auth,
_context.BoxId,
new GetDocflowEventsRequest()
{
AfterIndexKey = lastIndexKey,
InjectEntityContent = true,
});