Автор |
Сообщение |
|
АС wrote:Вот, к примеру, позвонил мне клиент и говорит:"Милейший, я не принимаю у тебя три позиции по твоей накладной, передумал, будь любезен, аннулируй их!" Мне чтоб это сделать теперь нужно узнать номер ВСД, как? Для этого теперь нужно зайти в транзакции исх.оф, там остался поиск по накладной, ищу эту ттн-открываю-щелкаю по нужной позиции-там узнаю номер всд-копирую и вставляю уже в строчку с номером всд в вет.доках исх. оф. и только так можно аннулировать позицию!
БРЕД!!!!!
Раньше можно было из открытой транзакции правой кнопкой по ВСД щелкнуть и выбрать "открыть в новой вкладе", там и аннулировать можно. Сейчас такое не работает?
|
 |
|
exteris wrote:Приветствую,
При создании ВСД в web-версии Меркурия нахожу предприятие-получатель и тут же могу посмотреть его GUID, я вот для хоз.субъекта GUID не показывается. Его можно каким-нибудь образом получить?
Простого способа не существует. Или ХС сам смотрит его в Цербере или вы делаете запрос через АПИ (в тяжелых случаях оформляется в веб тестовая заявка и ГУИД получаете через АПИ).
|
 |
|
Проблем нет, АПИ работает.
|
 |
|
В тестовом контуре не вся информация отображается, это сделали для снижения нагрузки, но это давно писали, возможно еще немного оптимизировали.
|
 |
|
Возможно начали блокировать пользователей без СНИЛСА и телефона.
|
 |
|
sergmercury wrote:
nmzn1 wrote:
sergmercury wrote:Права доступа к площадке в веб есть и пробовали от разных пользователей отправлять у всех права есть, ошибка все та же.
А по UpdateUserWorkingAreas получаю такой ответ: <apl:error code="MERC79386">Роль пользователя не позволяет изменять зоны ответственности.</apl:error> хотя инициатор является администратором.
а в ветис-=паспорте не проверяли, есть ли у админа роль "управление зонами ответственности пользователей"
Проверил, действительно прав не было у админа, поставил роль "управление зонами ответственности пользователей" и после успешно привязал через API другого пользователя к площадке, но результат получения складского журнала все тот же - "пользователь-инициатор не указан".
Самый простой способ проверить доступ: зайти в веб ХС на все площадки - Настройки - Настройки зон ответственности - выбрать пользователя - доступные площадки будут окрашены в зеленый цвет.
|
 |
|
Проверьте права пользователя на доступ к площадке запрашиваемой записи (через Меркурий.ХС в веб). Если делали работу с пользователями через АПИ, тогда обновите зоны ответственности для пользователя (нужно передать в запросе UpdateUserWorkingAreas все площадки на которые он имеет доступ).
|
 |
|
AleksM6310 wrote:C 08.06.2019 при создании ВСД через API интеграцию Меркурий возвращает ошибку "MERC02481: Условие перевозки не найдено", хотя условие перевозки в XML указано.
- <vd:transportInfo>
<vd:transportType>1</vd:transportType>
- <vd:transportNumber>
<vd:vehicleNumber>Х152МК799</vd:vehicleNumber>
</vd:transportNumber>
</vd:transportInfo>
<vd:transportStorageType>CHILLED</vd:transportStorageType>
transportStorageType - Способ хранения продукции при перевозке.
Может не указано:
|
 |
|
Brnetzenn wrote:Здравствуйте. После 28 числа наша интеграция в 1С с Меркурием сходит сума. Бесконечные ошибки: плохой тип переменной, время запроса вышло. С чем это может быть связано? Проблема самого шлюза меркурия или интеграции?
Вчера проводить ВСД было вообще невозможно из-за ошибки "плохой тип переменной".
Проблема в интеграции, все отправляется нормально. В Меркурии все ошибки с префиксами APLM или MERC.
|
 |
|
Yoreg07 wrote:Всем добрый день. Гашу ВСД через api 2.0. Несколько раз приходит статус заявки IN_PROCESS, затем приходит отказ, что якобы ВСД уже погашен. Обновляю ВСД по его UUID и вижу, что погашен он был именно в то время, когда ушла заявка в шлюз и именно тем пользователем, который был указан в XML заявки. Также были случаи и без статуса IN_PROCESS ... сразу приходил отказ. Согласитесь, не могло быть такого, что этот же пользователь в ту же секунду, что и заявка в шлюзе, зашёл в WEB и погасил там ВСД. Это однозначно КОСЯК разрабов ... исправляйте его !!! Кто-нибудь сталкивался с подобными ситуациями ?
Это всегда было и всегда будет. Для исправления разработчикам придется много менять, а этого скорее всего не будет (во всяком случае еще долго).
|
 |
|
shmuylovich wrote:
serg882 wrote:Зачем указываете период создания? Если вам просто нужно получить все записи, то период можно не указывать.
Как я уже писал, мы рассматривали два варианта сокращения объемов загрузки - по периоду или по смещению (офсету). Ни тот, ни другой способ нормально не работают.
Кстати, техподдержка рекомендует запрашивать интервалом не больше 1 суток.
Там у них какая-то путаница в терминологии. Оказывается, receiptDateInterval фильтрует не по дате создания, а по дате обновления. Но и это не все. В поле createDate, судя по всему, выводится не дата создания записи, а дата редактирования (ата создания актуальной версии). Пока это не точно, нужно проверять и анализировать.
Самый нормальный вариант, ничего не запрашивать в Меркурии. Если у вас работа и в веб-интерфейсе и в апи, тогда это не вариант. Кто-то использует метод GetStockEntryChangesListOperation для получения записей, возможно он и вам подойдет. У меня записи запрашиваются только, если были отправлены дубли документов (заявка на отправку приходит со статусом rejected, но по факту она проходит). У них путаница в коде скорее всего, в самой записи журнала есть поле Дата создания и поле Дата обновления.
|
 |
|
Зачем указываете период создания? Если вам просто нужно получить все записи, то период можно не указывать. Получение записей нормально проходит при указании 500-600 записей в выборке. У меня период создания нормально работал за один день, проблем с получением записей не было, всегда приходили все записи, но я запрашивал только не нулевые. Может быть некоторые записи уже помечены к перемещению в архив и метод не возвращает их.
|
 |
|
oazis wrote:возвращаюсь к теме
запрос продукта по его GUID
хохма в том что на сайте написано
Операция GetProductByGuid предназначена для получения актуальной версии записи продукции по её глобальному идентификатору
что вводит в заблуждение. Почитав исходники нашел что сам товар надо грузить функцией GetProductItemByGuid
В Меркурии есть тип продукта (1 уровень), продукт (2 уровень), субпродукт (3 уровень) и номенклатура производителей (4 уровень номенклатуры). Для каждого уровня свой запрос (кроме 1 уровня).
|
 |
|
СергейБ wrote:
oleg-x wrote:Делайте инвентаризацию и дальше работайте, без разделения, с ЭВСД или без.
А без указания входящего ЭлВСД система разрешит подобную инвентаризацию? Год назад, помнится, с этим были сложности.
По инвентаризации ограничений нет, и год назад проблем не было, входящий эВСД не указывали.
|
 |
|
katerinamcz wrote:Добрый день. Мы только начинаем работать в Меркурии, есть несколько вопросов. Помогите разобраться? Клиент забирает продукцию с нашего склада по доверенности, но дальше продукция едет к клиенту с перегрузами... т.е. получается что это мультимодальная перевозка. Но мы не знаем их пунктов перегруза и транспорта на котором они везут... как нам оформлять транзакцию???
Если право собственности на груз переходит клиенту на вашем складе, то можно выписывать ВСД без перевозки (получатель ХС - клиент, площадка получателя - ваш склад), а дальше клиент сам будет делать ВСД по нужному маршруту. Если право собственности переходит только по прибытии на конечную точку, то как правило, все пункты перегрузки известны заказчику доставки груза.
|
 |
|
|
|