|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Сообщения, отправленные пользователем: lalex23
Индекс форума » Профиль для lalex23 » Сообщения, отправленные пользователем lalex23
Автор Сообщение
Алексей Баранов wrote:lalex23 - спасибо за ответ.
А если uuid почти не используется, то и следить за актуальностью объектов вроде бы нет большого смысла.
А то я уже было подумывал об ежедневной синхронизации всех справочников.

не вижу причины не хранить в своей информационной системе статическое значение uuid на момент синхронизации, можно вытянуть из сервиса все версии объекта и проследить историю его изменений, ну если вдруг понадобится
з.ы.
за 8-9 месяцев промышленной эксплуатации системы интеграции 1С-Меркурий потребности в отслеживании guid-ов не возникало
Алексей Баранов wrote:Вопрос к создателям Ветис.API:
Для чего во всех справочниках и документах используется два идентификатора: uuid и guid?

Я сейчас разрабатываю структуру данных для своей УС, и думаю, какой индекс делать для поиска
по uuid, по guid, или составной по обоим полям, или может быть один общий длиной 72 символа.

Какой физический смысл в использовании двух статистически уникальных полей?


guid - идентификатор объекта, uuid - идентификатор версии объекта, при изменении объекта uuid меняется
поиск по guid возвращает актуальную версию объекта, поиск по uuid возвращает какую-то версию объекта
большинство операций в ВетИС требуют guid, но есть одна какая-то, где требуется указать uuid единицы измерения, хотя в справке написано что можно обойтись и guid
в 1С храню на всякий случай оба идентификатора, но пользуюсь везде guid, кроме случаев когда без uuid не обойтись

Алексей Баранов wrote:
lalex23 wrote:Ёлки зелёные, там вона что появилось: Первые шаги в проектах интеграции с ФГИС Меркурий. и на первый взгляд - это та вещь которая год назад сэкономила бы мне такое количество времени и нервов, что лучше и не думать.


То что нужно!
"Первые шаги" в Ветис.API надо вынести в самое начало и выделить громадным шрифтом.
Интересно давно ли появилось?
Я этой странице бывал несколько раз на дню и "Первых шагов" не замечал (что в общем-то не мудрено - одна строчка мелким шрифтом в середине кучи текста).

Не знаю, я туда давно не заглядывал, для меня это пройденные шаги, но в своё время это бы так помогло...
Алексей Баранов wrote:Так, с ХС, и предприятием в первом приближении понятно. Осталось посмотреть, как это выглядит в Меркурии.

Следующий вопрос:
Как мне начать работать с API-интерфейсом?


Начните с получения доступа к этой весёлой системе
Ёлки зелёные, там вона что появилось: Первые шаги в проектах интеграции с ФГИС Меркурий. и на первый взгляд - это та вещь которая год назад сэкономила бы мне такое количество времени и нервов, что лучше и не думать.
Алексей Баранов wrote:

lalex23-спасибо за ответ!
По справочникам: какие справочники нужно синхронизировать?
Вероятно первый справочник - Номенклатура. Однако непонятна структура справочника Номенклатура в Меркурии, чтобы это таки была синхронизация.

Я буду интегрировать в СБиС.

Сейчас напишу, как понял:
ХС - головная организация;
Предприятие - обособленное подразделение;
Один ХС может иметь несколько предприятий;
Так?
И что такое площадка?

Может быть у кого-нибудь есть реляционная модель данных Меркурия? (вопрос в первую очередь к разработчикам Меркурия)


Справочники - понадобятся практически все классификаторы что есть в web сервисах плюс часть описана только в pdf файлах, начинайте с классификаторов номенклатуры, он 4-х уровневый, три уровня в сервисе, четвёртый вы создаёте самостоятельно - регистрируя номенклатуру и классифицируя её по трём вышестоящим.

ХС - юр.лицо, физ.лицо, ИП, по сути Контрагент
Предприятие - адрес с/на котор(ый/ого) выполняется перемещение подконтрольной продукции с ВСД
например есть Магнит - это ХС, десяток-другой магазинов в городе - Предприятия

С площадкой точного определения не дам, боюсь где-то соврать
kiv1c wrote:
Алексей Баранов wrote:какие запросы мне нужно сделать в API Меркурий, чтобы в Меркурии же на остатках нашей организации появился товар.


я вот руководствуюсь разделом "бизнес-операции" вот здесь
Подсистема_обработки_заявок_в_Ветис.API
для начального ввода остатков нужна операция Инвентаризации ResolveDiscrepancyOperation
однако там нужно указать guid вашего предприятия (ХС в терминах Меркурия) и площадки где произведена продукция (Enterprise).
если у вас нет площадки, ее надо создать с помощью modifyEnterpriseOPeration



Я бы порекомендовал начать в первую очередь с синхронизации справочников, в любом случае понадобятся.
Да, если разработчики 1С-ники - для меня путали термины, если приводить к 1С-ным, то:
Предприятие в Меркурии = Адрес доставки в 1С
Хозяйствующий субъект в меркурии = Контрагент в 1С
И снова здравствуйте, господа разработчики, есть вопрос и я его думаю.
В соответствии с описанием формата при оформлении транспортной транзакции заполнил три поля объекта vetCertificate: issueSeries, issueNumber, issueDate.
Обнаружено следующее:
1. в справке указан тип поля issueDate - строка, на самом деле это дата
2. после исправления типа поля - транзакция успешно оформлена, но никакой информации о бумажном бланке через веб-интерфейс не наблюдается, только при сканировании QR кода и переходу по ссылке видна информация о бумажном ВСД
так и задумано?
Александр Осминин wrote:
lalex23 wrote:Господа разработчики, возникла следующая ситуация:
При оформлении транспортной транзакции через шлюз в описании транспортной партии указываем информацию о лабораторных исследованиях в поле expertiseInfo, при отправке различных видов продукции - у нас номера и даты лабораторных исследований разные.
В ответе на заявку о выполнении транзакции приходят списки ВСД и оформленных партий продукции, в структуре ответа ВСД также присутствует поле expertiseInfo хотя в справке по операции оно и не описано.
Проблема в том, что если отправляется несколько партий, то описание лабораторных исследований ВСД первой партии распространяется абсолютно все партии оформляемой транспортной транзакции.

В случае если вы передаете в запросе несколько объектов consignment ("..Request/delivery/consignment") и несколько объектов vetCertificate ("..Request/delivery/accompanyingForms/vetCertificate") то связь между ними должна быть установлена путем указания атрибутов "id" - у элемента consignment и "for" - для элемента vetCertificate. Разъяснения по применению добавили в справочную систему.
В случае если вы передаете в запросе несколько объектов consignment и один объект vetCertificate, то атрибуты id и for могут быть не указаны, но в этом случае информация из единственного элемента vetCertificate будет распространяться на все ВСД, оформляемые в этом запросе.

Спасибо за информацию, попробовал на рабочей базе заполнить поля id для consignment и for у vetCertificate одинаковым значением идентификатора, выхватил ошибку APLM0007, видимо где-то накосячил, завтра буду пробовать на тестовом сервере
или может есть ещё какие нюансы?

Александр Осминин wrote:
lalex23 wrote:В своей учётной системе я конечно могу использовать отправляемые данные для печати ВСД, хотя и придётся немного менять логику, но что будет делать получатель ВСД - у него на все виды продукции одни и те же исследования?

Исправлять сведения локально чтобы получить правильную форму печати совсем не вариант, только наличие сведений в Меркурии подтверждает их легальность.

конечно же нет, я так не делаю
Господа разработчики, возникла следующая ситуация:
При оформлении транспортной транзакции через шлюз в описании транспортной партии указываем информацию о лабораторных исследованиях в поле expertiseInfo, при отправке различных видов продукции - у нас номера и даты лабораторных исследований разные.
В ответе на заявку о выполнении транзакции приходят списки ВСД и оформленных партий продукции, в структуре ответа ВСД также присутствует поле expertiseInfo хотя в справке по операции оно и не описано.
Проблема в том, что если отправляется несколько партий, то описание лабораторных исследований ВСД первой партии распространяется абсолютно все партии оформляемой транспортной транзакции.
В своей учётной системе я конечно могу использовать отправляемые данные для печати ВСД, хотя и придётся немного менять логику, но что будет делать получатель ВСД - у него на все виды продукции одни и те же исследования?
Это так задумано или косяк?
ошибся темой
СББЖ Пермь wrote:клиент едет по маршруту Пермь- Москва -Пермь

Он таким образом развлекается? всю продукцию возит туда-обратно?
похоже накипело
Urylin wrote:http://help.vetrf.ru/wiki/%D0%92%D0%B5%D1%82%D0%B8%D1%81.API.

Ветис.API.
В настоящее время на этой странице нет текста. Вы можете найти упоминание данного названия в других статьях, или найти соответствующие записи журналов.

Добрый! ПО ссылочке ничего нет.

точку в конце адреса уберите
b.ivanov wrote:Интересно и то, что два разных сервера выдают мне два разных IP для api.vetrf.ru..

Ошибка возникает на 195.2.72.155, а вот на 62.76.145.99 всё в порядке.

у меня определяется как 62.76.145.99, но всё равно не работает...
Господа, а вот прямо сейчас - 30.12.2017 в 08:20 сервис работает? у меня с 2-ух часов ночи перестали оформляться транзакции через модуль интеграции, хотя веб-интерфейс работает без проблем.
Раньше при попытке зайти по адресу api.vetrf.ru:443 - всплывало окошко авторизации в браузере, а теперь наблюдается 400 Bad Request
 
Индекс форума » Профиль для lalex23 » Сообщения, отправленные пользователем lalex23
Перейти:   

Powered by JForum 2.1.8 © JForum Team