Взаимодействие с учетными системами хозяйствующих субъектов

Yoreg07 wrote:Доброе утро, коллеги. Объясните мне непонятливому, пожалуйста, каков принцип оформления ВСД (входящих, производственных или транспортных) через шлюз? А именно: какую роль здесь играет вет. врач? и нужен ли он вообще?
Как вообще происходит этот процесс через шлюз? Пока у меня два предположения:
1. Для оформления ВСД через шлюз в XML запросе достаточно указать логин или UUID вет. врача в соответствующих полях и заявка на оформление будет исполнена. Но тогда вопрос: насколько это безопасно и законно? Логин можно ведь и украсть, и подобрать и т.д.
2. Отправляется XML запрос в шлюз, вет. врач, увидев его в web интерфейсе меркурия, одобряет запрос на оформление или отказывает (ну как то так). Тогда вопрос: такая схема нисколько не ускоряет процесс оформления ВСД через шлюз.

?????????????????????????

И, да, про безопасность ... как-то схема HTTPLogin + HTTPPassword + APiKey + IssuerID при отправке запроса в шлюз вообще не безопасна. Планируются ли какие-нибудь ключи, как в ЕГАИС, или ещё что-то?
(все наверное уже знают что такое IssuerID и APiKey ... IssuerID = GUID ХС, APiKey = GUID ХС + Дата и время по Москве или подачи заявки на доступ к шлюзу, или регистрации в шлюзе ... ну в общем какая-то дата ...)

Кто-нибудь может ответить, прокомментировать? А именно про вет. врачей ...

Yoreg07 wrote:

Yoreg07 wrote:Доброе утро, коллеги. Объясните мне непонятливому, пожалуйста, каков принцип оформления ВСД (входящих, производственных или транспортных) через шлюз? А именно: какую роль здесь играет вет. врач? и нужен ли он вообще?
Как вообще происходит этот процесс через шлюз? Пока у меня два предположения:
1. Для оформления ВСД через шлюз в XML запросе достаточно указать логин или UUID вет. врача в соответствующих полях и заявка на оформление будет исполнена. Но тогда вопрос: насколько это безопасно и законно? Логин можно ведь и украсть, и подобрать и т.д.
2. Отправляется XML запрос в шлюз, вет. врач, увидев его в web интерфейсе меркурия, одобряет запрос на оформление или отказывает (ну как то так). Тогда вопрос: такая схема нисколько не ускоряет процесс оформления ВСД через шлюз.

?????????????????????????

И, да, про безопасность ... как-то схема HTTPLogin + HTTPPassword + APiKey + IssuerID при отправке запроса в шлюз вообще не безопасна. Планируются ли какие-нибудь ключи, как в ЕГАИС, или ещё что-то?
(все наверное уже знают что такое IssuerID и APiKey ... IssuerID = GUID ХС, APiKey = GUID ХС + Дата и время по Москве или подачи заявки на доступ к шлюзу, или регистрации в шлюзе ... ну в общем какая-то дата ...)

Кто-нибудь может ответить, прокомментировать? А именно про вет. врачей ...

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

Кроме программиста и самого ветврача никто доступ не имеет к паролю и логину.

Подразумевается что вет. врач работает в учётной системе ХС? Ну т.е. формирует кто-то расходную накладную в УС и отдаёт её врачу, который на основании её данных оформляет список транспортных ВСД?

Добрый день.
Подскажите насчет списка ХС, обслуживаемых программной системой, которые нужно указывать в заявке на подключение к шлюзу Ветис API.
Я так понимаю, что для указанных ХС приходит issuerID, который необходим для авторизации при работе через нашу ИС. Верно?
Если это так: мы являемся сервисом, работающим с большим количество ХС и сразу в заявке не можем указать всех, кто будет с нами работать. Можно ли как-то дополнять этот список потом?

IrinaK wrote:Добрый день.
Подскажите насчет списка ХС, обслуживаемых программной системой, которые нужно указывать в заявке на подключение к шлюзу Ветис API.
Я так понимаю, что для указанных ХС приходит issuerID, который необходим для авторизации при работе через нашу ИС. Верно?
Если это так: мы являемся сервисом, работающим с большим количество ХС и сразу в заявке не можем указать всех, кто будет с нами работать. Можно ли как-то дополнять этот список потом?

Мне кажется, не вы должны подавать список, а каждый ХС должен подать заявку от себя, ему предоставляют доступ, а дальше уже в своей системе настраиваете ему подключение с предоставленными ему данными. Ну или он сам все вводит.

.

Добрый день, коллеги. Меня сейчас стал интересовать следующий вопрос: а планируется ли после полного перехода всего рынка на оформление ВСД через шлюз отключить web-интерфейс для работы в меркурии? Поясню ... на данный момент есть возможность оформлять ВСД как через шлюз, так и через web-интерфейс. Для интеграции с УС однозначно придётся остатки и журнал ВСД хранить в базе данных УС и работать в УС, опираясь на эти данные (ну есть конечно вариант каждый раз загружать их из меркурия, так сказать оперативные данные, но мне кажется это не очень хорошо ... сколько пользователь будет ждать чтобы открыть журналы??? ... пока всё быстро работает, а если все перейдут на ЭВСД, то нагрузка на сервера очень подскочит) ... дак вот, что делать если кто-то сделал что-то в меркурии через web-интерфейс (погасил ВСД или оформил транспортную партию) ? В данных учётной системы ничего не изменится ... получается опять таки необходимо каждый раз синхронизировать данные в УС с данными в меркурии, чтобы быть уверенным в синхронности данных???
Я понимаю что это вопрос организационного характера при работе в УС, но ведь бывают всякие случаи ... например, сбой работы УС, а накладная уже собрана и водитель ждёт ВСД (конечно здесь web идёт в помощь, но ...) ???

У кого есть какие-нибудь мысли по этому вопросу? Кто может поделиться опытом?

У нас, например, это решено так:

Мы поддерживаем одновременную работу от одной учетки и в шлюзе и в веб и с различных баз данных.

Меркурий достаточно бодро отдает изменения складского журнала через docFlow.
А в нем - подробнейшее описание всех изменений. (GetStockEntryChangesListOperation)

Поэтому перед каждой операцией (или пакетной операцией) спрашиваем изменения и отражаем их в закэшированной таблице. (ответ меркурия на GetStockEntryChangesListOperation приходит примерно за 0,5 сек ну или за 2-3 сек, если вы за несколько часов спросите)

Там по факту остается только дать инструменты управления точкой актуальности docFlow (больше для отладки алгоритмов, кстати, нужной)
Ну и на случай "все сломалось" - уже перечитывание всего склада через GetStockEntryListOperation. (операция самая тормознутая во вселенной и возвращающая 98% шлака, который сразу же будет забыт)

Такая архитектура самопроизвольно протестировалась где-то с месяц назад, когда тестовый сервер был деградирован по производительности примерно в 50 раз. - работать было неприятненько, но возможно.

Запрещать веб - имхо не вариант, нужен он. А даже если запретить, то проблему не решит - привет распределенным базам, например.

С ВСД история точь-в-точь.

Павел Большаков wrote:У нас, например, это решено так:

Мы поддерживаем одновременную работу от одной учетки и в шлюзе и в веб и с различных баз данных.

Меркурий достаточно бодро отдает изменения складского журнала через docFlow.
А в нем - подробнейшее описание всех изменений. (GetStockEntryChangesListOperation)

Поэтому перед каждой операцией (или пакетной операцией) спрашиваем изменения и отражаем их в закэшированной таблице. (ответ меркурия на GetStockEntryChangesListOperation приходит примерно за 0,5 сек ну или за 2-3 сек, если вы за несколько часов спросите)

Там по факту остается только дать инструменты управления точкой актуальности docFlow (больше для отладки алгоритмов, кстати, нужной)
Ну и на случай "все сломалось" - уже перечитывание всего склада через GetStockEntryListOperation. (операция самая тормознутая во вселенной и возвращающая 98% шлака, который сразу же будет забыт)

Такая архитектура самопроизвольно протестировалась где-то с месяц назад, когда тестовый сервер был деградирован по производительности примерно в 50 раз. - работать было неприятненько, но возможно.

Запрещать веб - имхо не вариант, нужен он. А даже если запретить, то проблему не решит - привет распределенным базам, например.

С ВСД история точь-в-точь.

Спасибо за ответ ... я совсем забыл что в шлюзе есть история изменений

Коллеги, а вот прямо сейчас на рабочем сервере у всех всё работает?

update

вот с утра тупило, потом умерло на пол-часа, теперь продышалось, что за лихорадка?

Что-то не так с Меркурием. Делаю запрос входящих ВСД. Приходит ответ в нем количество ВСД написано 50. Хотя на самом деле в веб интерфейсе их больше 1000.

my.vetrf-forum wrote:Что-то не так с Меркурием. Делаю запрос входящих ВСД. Приходит ответ в нем количество ВСД написано 50. Хотя на самом деле в веб интерфейсе их больше 1000.

у меня другая ситуация: оформляется транспортная трназакция, смотрю по получателю входящие ВСД - нет ни через шлюз, ни через веб, минут через 4-5 появляется в веб-е и тут же можно запрашивать через шлюз

lalex23 wrote:Коллеги, а вот прямо сейчас на рабочем сервере у всех всё работает?

update

вот с утра тупило, потом умерло на пол-часа, теперь продышалось, что за лихорадка?

а потом задержки отгрузок, штрафы, ну вы поняли...

lalex23 wrote:

my.vetrf-forum wrote:Что-то не так с Меркурием. Делаю запрос входящих ВСД. Приходит ответ в нем количество ВСД написано 50. Хотя на самом деле в веб интерфейсе их больше 1000.

у меня другая ситуация: оформляется транспортная трназакция, смотрю по получателю входящие ВСД - нет ни через шлюз, ни через веб, минут через 4-5 появляется в веб-е и тут же можно запрашивать через шлюз

походу начались тормоза в меркурии ... ведь людей всё больше начинают работать через шлюз ... а может профилактика какая-нибудь идёт на серверах