Machinima wrote:Вы очень интересные товарищи - вам дали возможность жульничать для "отладки" и "интеграции", а вы считаете, что оно всегда так будет и этим нужно пользоваться. Это послабление временное. И тут возникает нюанс - система логирует ВСЕ транзакции: проходят они мимо вет врачей, не проходят, может их вообще кроме Вас никто не видит, но их логируют, и если вы станете этим злоупотреблять - не сегодня, так завтра, не завтра, так когда вы вызовите подозрения - все это будет возможность просмотреть и отвертеться врядли сможете.

Vladimir2017 wrote:

BFT wrote:Да, свое. Размер последнего отета сейчас посмотрел 4,5Мб.

Возможно это значительный фактор, у нас алгоритм работы примерно такой - раз в минуту запрашиваются данные по складам и документам на всех площадках, временной диапазон - дата последнего документа/записи. Раз в час запрашиваются все непустые складские записи. Помимо этого документы и записи получаем после создания через опрос по ApplicationID. Механизм избыточен, но нам важна точность. Максимальный объем документа получается чуть больше 2 мб. За сегодня 8 ошибок HTTP/500 и не одного APLM12.

*Update - про APLM12 соврал, не туда посмотрел. Сейчас проверил и насчитал около 300. Но работе это не помешало.

leradata wrote:Добрый день.

Дошла информация , что на встрече от 23.07.2018, для получения списков ВСД и склада, было предложено следующее:

"рекомендуют запрашивать список, а потом выдергивать по транзакционно"

вопрос - что это за методы ?
которые выдают только список GUID/UUID транзакции (записи) без ее наполнения.
все существующие возвращают полную информацию о записи, в количестве указанном в count.

или это "испорченный телефон".

leradata wrote:

TWAIN wrote:Не было такого. Там другой смысл был. Рабочая рекомендация была и есть одна, сканировать на входе qr код и по нему запрашивать. А там говорили что списки надо запрашивать реже. Окна запрашивать последовательно, между запросами паузы.

какой КОД?
я в интеграцию по новому клиенту должен загрузить склад и получить входящие ВСД,
ВСЕ.
чтоб синхронизироваться с этим УГ и меньше туда лазать.

а сканировать код - вы получите ссылку по UUID на информацию. а не чистый UUID/ так что его еще вытащить от туда надо.
а у склада его и нет.

на такие встречи не пускают прогеров, боятся.
вот и доходит инфа через чужие уши.

Вячеслав Феньченко wrote:Добрый день.
Формируем ВСД на клиента, выдает ошибку:
Код ошибки: MERC02181. Описание: В запросе для обслуживаемого предприятия указан идентификатор устаревшей версии

Для данного клиента раньше ВСД формировались корректно.
При оформлении транспортной партии передаем guid хозяйствующего субъекта -получателя и guid предприятия-получателя. Именно guid а не UUID.

В чем еще может быть проблема?

Ириала wrote:

Николай Власов wrote:

user100000 wrote:каждый день стране вещает, что у него все хорошо

Спасибо, коллега, но вы не все понимаете. Я пишу, что все хорошо с МЕРКУРИЕМ и это очевидно любому не идиоту, иначе бы проблемы были и в Вебе и в API 1.4. У нас проблемы со ШЛЮЗОМ API 2.0., о чем есть в каждом сообщении и причины чего мы описали.
Понятно?

У кого все хорошо с Меркурием? Прошу поднять руки... Нет таких. Я работаю в вебе, вот ляпы.
Машинка прилетела, открываю-нет ничего. Ладно. Открываю через час-ура. Проверила, гашу (правда в документе 6 производителей, но ничего, наш тоже есть). Погасила - производитель исчезли-ни внести заново, ни отредактировать нельзя. Что делать? Удаляю запись журнала, забиваю вручную (прослеживаемость 0%, затраты по времени-ручкой быстрее-бы написала). Ладно, справилась. Выхожу из журнала - машинка висит-открываю-пустота (машинка висела часа 3, потом я ушла, утром машинки небыло уже). Танзакцию оформила - все, улетела. Через час звонят - Вы почему документ не оформили? И так далее, и т.п.
ВСЕ ХОРОШО С МЕРКУРИЕМ

benzol45 wrote:Похоже API совсем сломался.
На любое обращение к Меркурию возвращает статус: REJECTED (APLM0007)Wrong application data format. Format validation failed due to XML Schema rules: Элемент 'login' не предусмотрен.

drskot wrote:все подписал