Обращение к интеграторам
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 отвечает за заполнение этой строки?
Мы планируем освежить информацию,
Прошло почти два года, а воз и ныне там...
В документации Диадок 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.
Каким таким образом? И что поддержали? То что документация ни к черту? Коммерческая компания, которой мы платим с каждого отправленного документа, не может привести документацию в порядок!!!
То что можно заполнить "Без документа-основания" я и сам видел. Только вот вы сможете объяснить контрагентам-бюджетникам, почему они должны принять УПД без указания номера договора как документа основания?
В вашей ситуации я предлагаю заполнять в качестве основания проектный номер договора, который заключается, если он есть, или явно описывать, что договор на этапе заключения.
К сожалению, ваш пример - это один из многих, которые регулятор не учел при разработке формата. Мы не можем отразить все возможные ситуации по формированию документов в документации, к сожалению.
Проектный номер договора невозможно указать в BaseDocumentNumber без даты договора, я уже об этом написал выше. Пока буду писать номера таких договоров в поле ИнфПолФХЖ1 и "Без документа-основания". Но в документации можно было бы сделать оговорку, что BaseDocumentDate - optional, но только если Без документа-основания", иначе required.
Коллеги, разработчики, подскажите, пожалуйста .
Есть такая задача.
Наши клиенты хотят подписывать заявку на перевозку(это документ формата pdf) в нашем личном кабинете.
Из вашей документации, на примере документооборота с актом, следует:
-
Мы должны подписать документ, добавить документ и подпись в сообщение и отправить сообщение в ящик нашего клиента -
Клиент получает наше сообщение -
Клиент формирует свой «титул», подписывает «титул», формирует «патч» и добавляет к сообщению «патч» со своей подписью
Вопрос:
Если мы опустим пункт 2, а просто поставим подпись клиента на его "титул"
(с нашим авторизационными данными, но используя ЭЦП клиента) и
добавим «патч» подписанный клиентом к сообщению из пункта 1.
То в ящике клиента сообщение("цепочка") обновится? Он увидит, что подписал документ?
Если нет, то как реализовать хотя бы на пальцах расскажите? Ключ АПИ используется только наш.
Duplicate of #899
Не понятно как с начала октября генерировать UniversalCorrectionDocument ведь его структура в https://api-docs.diadoc.ru не описана, приходится наугад заполнять ее на основании ранее сделанного кода для 820 и того, что было при использовании UniversalTransferDocumentSellerTitleInfo.
В результате получаю ничего не говорящую ошибку при использовании GenerateSenderTitleXml. Просто чудесно.
@svsavin здесь описана структура UniversalCorrectionDocumentSellerTitleInfo.
Также описание типа документа и его xsd-схему вы можете получить в ответе метода GetDocumentTypes.
Добрый день! Подскажите пожалуйста, есть ли возможность получить наименование роуминга контрагента? А то не нашел такой информации в документации.
@MichaelBlack17 Добрый день!
Вы имеете в виду оператора роумингового контрагента? Если так, то сейчас нет возможности получить его через АПИ.
Добрый день! Подскажите пожалуйста, как добраться до комментариев, которые оставляют пользователи в процессе документооборота, например прb отказе в подписании, при аннулировании документа и прочее (надеюсь, на картинке видно), в структуре DocFlowEventV3
При изучении документации по V3 складывается такой алгоритм:
- получить статус
var resStatus = docFlowEventV3.Document.Docflow.Resolution.ResolutionStatus; - получить ResolutionEntityId
var reId = docFlowEventV3.Document.Docflow.Resolution.ResolutionEntityId; - в зависимости от ResolutionStatus вытащить сущность Entity
var entity = docFlowEventV3.Document.Docflow.ResolutionEntities.Requests[reId] - вытащить комментарий из 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,
});