Сообщения, отправленные пользователем: mevgenym

nsnt wrote:При оформлении возврата через api получатель не видит причину возврата в веб-интерфейсе. Это у всех так или я что-то недозаполняю?
В discrepancyReport передаю причину reason и описание description.

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

ZDmitry wrote:Для версии 2.1 в схемы добавлен новый фильтр для получения списка записей журнала:
Фильтр по интервалу создания записей журнала - элемент receiptDateInterval.

Предлагаю сделать фильтр не по дате создания, а по дате изменения записи журнала! Кто согласен? Интеграторы, скажите, кому нужен фильтр по дате создания записи? Для чего? Может я совсем идиот? Как вообще проектируется эта система?

дата создания тоже меняется от версии к версии, уже ничего не удивляет в этом бардаке, "усилия оппортунистов и жулья принесли свои плоды"

Владимир Игнатов wrote: По времени создания, а не изменения.

хренасе...

кстати заметил что критдейт меняется, в каждой версии разный, не понял в чем прикол

Владимир Игнатов wrote:Понаблюдайте, мне кажется, что GetStockEntryListOperation v2.0 и GetStockEntryChangesListOperation v2.0 возвращают разные списки актуальных записей при одинаковых интервалах дат и отсутствии фильтрации.
Не все записи, которые возвращаются GetStockEntryChangesListOperation с last=1 active=1 приходят в ответе на GetStockEntryListOperation.

+ status != 201 и 4хх, т.е. тоже надо смотреть, хотя не сравнивал, но вполне может быть

alexey-zmey wrote:В нынешней ситуации получаем список изменённых StockEntry, а почему эти изменения произошли, какой ВетДокумент их вызвал - ХЗ.

в ответах на гашение и транспортировку есть и стокентри и ветдокумент, оттуда можно усилием воли все связать

ТатаТар wrote:У нас дня три уже нет связи( постоянно выдает ошибку.

мерк работает в штатном режиме, выводы сами делайте

Алексей Баранов wrote:И по списку измененных уже посылали бы только guid'ы измененных, чтобы уж совсем "оптимизировать"!

+ хорошая тема
видимо решили совсем уж не шокировать

430 DELETED_WHEN_ATTACH - Запись была удалена в результате присоединения.

loki wrote:
во входящих 3 ТТН. каким образом мне указать эти 3 ТТН?

У вас на входе некий блок referencedDocument. В вашем случае их 3.

В этом referencedDocument вы сами должны найти то чем вы будете заполнять свой waybill при гашении.
По справке http://help.vetrf.ru/wiki/DocumentType_v2.0
1 - Товарно-транспортная накладная
8 - Разрешение ветеринарного управления субъекта страны ТС на ввоз продукции

т.е. выбираете один, например, тип первого блока больше похож на ТТН

loki wrote:
пытаюсь погасить. так же указываю эти ТТН:

по справке Waybill не список http://help.vetrf.ru/wiki/ProcessIncomingConsignment_v2.0
<vd:waybill> vd:Waybill [0..1]

как вы умудрились три Waybill воткнуть туда?

Андрей52 wrote:... все входящие ВСД т.к их в день по 300- 500 штук приходит

https://youtu.be/fAXR49Qnvv0?t=211

вы похоже бездельничаете ...

Владимир Игнатов wrote:
Видимо, имеется в виду весь ответ, сумма ответов по каждому окну.

так то, согласитесь, это уже разные запросы, в сумме так много из чего может набраться

Владимир Игнатов wrote:
Вариант с кешем очень ресурсо-затратный. Весь объем выборки нужно получить и где-то хранить.

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

Николай Власов wrote:до сотен мегабайт по одному запросу, например на историю изменений журнала по всем видам продукции года за три.

Vsevolod_Omsk wrote:
т.е. что входящие ВСД, что журнал читаем партиями по 50 штук (в середине июня и по 1000 работало).

Тут трактовать можно по разному, три года это период выборки запроса. Вот как готовится ответ непонятно. То ли сразу делается запрос к ИБ на весь период в параметрах операции и складывается где то в кеше, пока не прийдет запрос со смещением, то ли только на окно выборки в вашем случае - 50. Во втором случае, объем выборки данных всегда ограничен окном (максимальное окно = 1000). Если окно маленькое, то увеличится количество запросов, вот что более критично объем данных или количество запросов? Вообще мы как пользователи не должны были задаваться такими вопросами. Система не отрабатывает свои задачи.

ограничение для выравнивания нагрузки в виде ответов с кодом APLM0012

Сейчас вечер, отгрузок и приходов давно нет, операция getVetDocumentChangesList с диапазоном за последние 15 минут через раз выдает

либо как положе пустой ответ

зачем что то там выравнивать когда надо просто отправить пустой ответ?