|
[Search] Поиск   [Recent Topics] Последние темы   [Hottest Topics] Горячие темы   [Members]  Список участников   [Groups] На главную страницу 
[Register] Регистрация / 
[Login] Вход 
Взаимодействие с учетными системами хозяйствующих субъектов  XML
Индекс форума » Компонент МЕРКУРИЙ
Автор Сообщение
Vladimir2017

[Avatar]

Зарегистрирован: 02/10/2017 14:31:03
Сообщений: 362
Оффлайн

v.vlasenkov wrote:
я так понимаю, готово и красивого решения через API нет. Кто как решает данную задачу ?


Есть два варианта:
1. Работа ветупра в интегрированном решении хоза.
2. Отдельный софт для ветупра.

В первом случае компрометируются учетные данные ветупра, во втором хоза.
Корнетт

[Avatar]

Зарегистрирован: 19/09/2017 17:57:20
Сообщений: 383
Оффлайн

v.vlasenkov wrote:
b.ivanov wrote:
sanazarkin wrote:
b.ivanov wrote:
sanazarkin wrote:Не получается отправить заявку на транспортную ВСД через API от имени пользователя ХС
Выдает ошибку «Данная транзакция не может быть оформлена, так как роль пользователя не позволяет оформлять ВСД»

Через Веб-интерфейс (под этим-же пользователем) все получается.

Полагаю, указывается не логин ветеринарного врача, обслуживающего данное предприятие?


Верно. Через Веб-интерфейс (Меркурий.ХС) под этим логином создается заявка и передается в ГВЭ. Через API такой фокус не проходит, не смотря на то, что я формирую запрос по инструкции "...для хозяйствующих субъектов."


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


я так понимаю, готово и красивого решения через API нет. Кто как решает данную задачу ?

А как вы физически это представляете? Вы создадите сотни заявок через API, заявки прилетят в СББЖ и кто их должен сидеть и ждать, а потом согласовывать. Нет так не бывает. Госветврач должен сидеть на вашем предприятии и работать в вашей учетной системе под своим логином.
v.vlasenkov


Зарегистрирован: 26/01/2018 18:19:34
Сообщений: 10
Оффлайн

Корнетт wrote:
v.vlasenkov wrote:
b.ivanov wrote:
sanazarkin wrote:
b.ivanov wrote:
sanazarkin wrote:Не получается отправить заявку на транспортную ВСД через API от имени пользователя ХС
Выдает ошибку «Данная транзакция не может быть оформлена, так как роль пользователя не позволяет оформлять ВСД»

Через Веб-интерфейс (под этим-же пользователем) все получается.

Полагаю, указывается не логин ветеринарного врача, обслуживающего данное предприятие?


Верно. Через Веб-интерфейс (Меркурий.ХС) под этим логином создается заявка и передается в ГВЭ. Через API такой фокус не проходит, не смотря на то, что я формирую запрос по инструкции "...для хозяйствующих субъектов."


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


я так понимаю, готово и красивого решения через API нет. Кто как решает данную задачу ?

А как вы физически это представляете? Вы создадите сотни заявок через API, заявки прилетят в СББЖ и кто их должен сидеть и ждать, а потом согласовывать. Нет так не бывает. Госветврач должен сидеть на вашем предприятии и работать в вашей учетной системе под своим логином.


Вообще, именно так я себе и представляю. Ибо почему в WEB есть функциональность, в API её нет ?! Тогда два варианта:
1) Убирайте функциональность в WEB интерфейсе ХС
2) Добавляйте возможность в API для реализации функционала из УС
А держать ветврача на предприятии - это отдельная штатная единица, навязанная, между прочим.
v.vlasenkov


Зарегистрирован: 26/01/2018 18:19:34
Сообщений: 10
Оффлайн

Vladimir2017 wrote:
v.vlasenkov wrote:
я так понимаю, готово и красивого решения через API нет. Кто как решает данную задачу ?


Есть два варианта:
1. Работа ветупра в интегрированном решении хоза.
2. Отдельный софт для ветупра.

В первом случае компрометируются учетные данные ветупра, во втором хоза.


Спасибо, но в том-то и парадокс, что надо свои данные либо врачу оставлять, либо ХС... что конечно тоже не вариант.
Vladimir2017

[Avatar]

Зарегистрирован: 02/10/2017 14:31:03
Сообщений: 362
Оффлайн

v.vlasenkov wrote:Вообще, именно так я себе и представляю. Ибо почему в WEB есть функциональность, в API её нет ?!


Это искусственная балансировка нагрузки на ветупров, поскольку они, по две тысячи ТВСД, на район, в сутки, по своим правилам-понятиям, не сделают никогда. Наивная надежда на то, что хозы не наймут отряд операторов и не затолкают им эти тысячи заявок через сайт.
v.vlasenkov


Зарегистрирован: 26/01/2018 18:19:34
Сообщений: 10
Оффлайн

Vladimir2017 wrote:хозы не наймут отряд операторов и не затолкают им эти тысячи заявок через сайт.

ну так-то оно так, выгоднее "протолкнуть" ветврача, чем нанимать операторов.
я так понимаю, что питать надежду на реализацию этого функционала в API не стоит...

Это сообщение было редактировано 1 раз. Последнее обновление произошло в 29/01/2018 10:32:01

Корнетт

[Avatar]

Зарегистрирован: 19/09/2017 17:57:20
Сообщений: 383
Оффлайн

v.vlasenkov wrote:
Vladimir2017 wrote:хозы не наймут отряд операторов и не затолкают им эти тысячи заявок через сайт.

ну так-то оно так, выгоднее "протолкнуть" ветврача, чем нанимать операторов.
я так понимаю, что питать надежду на реализацию этого функционала в API не стоит...

Правильно понимаете
Владимир Игнатов


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

v.vlasenkov wrote:ну так-то оно так, выгоднее "протолкнуть" ветврача, чем нанимать операторов.

А это пока кому-то не надоест и он не напишет свою версию интеграции не через vetis.api, а просто через seleniumhq + headless browser или через PhantomJS. Да, возни, безусловно, больше и чаще, но зато возможности...
v.vlasenkov


Зарегистрирован: 26/01/2018 18:19:34
Сообщений: 10
Оффлайн

всё же, неужели все это делают только в web или лично через ветврача ???
потому как разрабатывал механизм и давал/брал свои/врача учётные данные, не думаю, что кто-то делал... могу ошибкать
lesya K


Зарегистрирован: 19/04/2017 13:32:44
Сообщений: 12
Оффлайн

добрый день, вопрос к тем, кто мастерит свою интеграцию.
При попытке получить методы исследования (справочник) по шлюзу выходит ошибка. Тех поддержка игнорит месяца 3 уже. Кто-нибудь получал эти методы, они вообще существуют?
BEA-382513: OSB Replace action failed updating variable "body": Error parsing XML: {err}FORG0005: expected exactly one item, got 0 items
tomilinia


Зарегистрирован: 07/11/2017 14:19:56
Сообщений: 15
От: Холдинг Афанасий
Оффлайн

lesya K wrote:добрый день, вопрос к тем, кто мастерит свою интеграцию.
При попытке получить методы исследования (справочник) по шлюзу выходит ошибка. Тех поддержка игнорит месяца 3 уже. Кто-нибудь получал эти методы, они вообще существуют?
BEA-382513: OSB Replace action failed updating variable "body": Error parsing XML: {err}FORG0005: expected exactly one item, got 0 items



Методы исследования не реализованы на стороне Ветис
Lamer


Зарегистрирован: 22/08/2017 10:40:02
Сообщений: 20
Оффлайн

Блин, кто проектировал это апи?!

Приходится делать тысячу костылей у себя в коде для того, чтобы осуществить простейшие действия...
Ну почему нельзя получить список ВСД предприятия, задав одновременно временные рамки и фильр по типу и статусу? Почему можно только отдельно по времени, либо отдельно по типу и статусу? Ну на крайний случай хотя бы давали возможность запрашивать список сертификатов, упорядоченных по возрастанию/убыванию дат...

Положим, мне нужно список погашенных входящих транспортных ВСД за октябрь 2017. Что делаю - запрашиваю сертификаты за октябрь, потом выдираю из вернувшегося списка транспортные, потом выбираю из списка транспортных те, у которых получатель мой ХС, потом выбираю оттуда погашенные... Это, по-моему, полный отстой!

кстати, кто-нибудь может мне объяснить, почему типы, указывающие направление - "входящий", "исходящий" - находятся в одном энаме с типами, указывающими на вид сертификата - "транспортный", "производственный"... Это что за дичь такая? Можно было бы тогда туда ещё добавить такие типы как "наверх", "фольга" и "муравейник", смотрелось бы вполне гармонично.

Столько лет пилить, денег влить, кардинально изменить апи в версии 2.0 - и при этом всё время что-то не работает, а то, что работает, работает через... через.. то просто треш... Если уж меняете, так почему нормально-то не сделать?

Это сообщение было редактировано 2 раз. Последнее обновление произошло в 01/02/2018 01:34:39

Vladimir2017

[Avatar]

Зарегистрирован: 02/10/2017 14:31:03
Сообщений: 362
Оффлайн

Lamer wrote:Блин, кто проектировал это апи?!

По ВСД могу посоветовать работать через getVetDocumentChangesListRequest, периодически дергаете сервис и собираете новые ВСД к себе в базу. Когда появляется необходимость одним запросом из базы вытаскиваете что вам надо.
mevgenym


Зарегистрирован: 19/05/2017 14:03:42
Сообщений: 312
Оффлайн

отборы по типам вообще не работают, приходится в результате отбор делать
https://github.com/mevgenym/1c_vetis.api_v1.1
https://github.com/mevgenym/1c_vetis.api
Владимир Игнатов


Зарегистрирован: 02/08/2017 09:19:30
Сообщений: 581
Оффлайн

Vladimir2017 wrote:
Lamer wrote:Блин, кто проектировал это апи?!

По ВСД могу посоветовать работать через getVetDocumentChangesListRequest, периодически дергаете сервис и собираете новые ВСД к себе в базу. Когда появляется необходимость одним запросом из базы вытаскиваете что вам надо.

Да и это не работает, как планировалось! Если Вы сделаете запрос "от той же секунды", которая у Вас последняя в базе, вы получите снова одну или несколько записей за эту секунду, которые у Вас уже есть. А если Вы сделаете запрос "со следующей секунды", можете потерять запись, которая была сделана в ту же секунду, когда Вам отдали последние записи на прошлом запросе, но эта последняя (последние) не попала в выдачу Вам, т.к. ее тогда еще не было.
В любом случае - поведение не то, что планировалось! Делать можно только по ID, он там все равно есть, надеюсь (не надо делать первичным ключом базы GUID/UUID, по ним поиск по индексу куда дольше идет). И выдавать в порядке возрастания ID. И "арифметика" в этом случае проста: в начале просим от 0, затем - от последнего пришедшего. Для сервера запрашиваемый ID означает "where ID>$ID order by ID".
Вариант "по времени" - попытка ограничить размер поиска - "в прошлом месяце", "в прошлом квартале". Для цели "скопировать весь справочник себе" не очень подходит.
 
Индекс форума » Компонент МЕРКУРИЙ
Перейти:   

Powered by JForum 2.1.8 © JForum Team