|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сообщения, отправленные пользователем: serg882
Индекс форума » Профиль для serg882 » Сообщения, отправленные пользователем serg882
Автор Сообщение
АС 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:Добрый день. Мы только начинаем работать в Меркурии, есть несколько вопросов. Помогите разобраться? Клиент забирает продукцию с нашего склада по доверенности, но дальше продукция едет к клиенту с перегрузами... т.е. получается что это мультимодальная перевозка. Но мы не знаем их пунктов перегруза и транспорта на котором они везут... как нам оформлять транзакцию???


Если право собственности на груз переходит клиенту на вашем складе, то можно выписывать ВСД без перевозки (получатель ХС - клиент, площадка получателя - ваш склад), а дальше клиент сам будет делать ВСД по нужному маршруту. Если право собственности переходит только по прибытии на конечную точку, то как правило, все пункты перегрузки известны заказчику доставки груза.
 
Индекс форума » Профиль для serg882 » Сообщения, отправленные пользователем serg882
Перейти:   

Powered by JForum 2.1.8 © JForum Team