Сообщения, отправленные пользователем: b.ivanov

Yoreg07 wrote:

b.ivanov wrote:

Yoreg07 wrote:Поправьте меня, если не прав. При оформлении заявки на ВСД (входящий, производственный или транспортный ... не важно) принцип работы в учетной системе ХС должен быть примерно таким:
1. ХС в своей УС оформляет заявку на какую-либо партию, наполняя её всеми зависящими от него данными
2. Затем эту заявку в этой же УС получает вет. врач и дополняет её уже своими данными
3. Затем генерируется XML и от ИМЕНИ ВЕТ. ВРАЧА (т.е. Initiator - это вет. врач и целевой сервис ServiceID - это mercury-vu.service) заявка уходит в шлюз ... или от имени ХС она должна уходить
???

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

Про шаги 1-2 - это понятно ... это же в УС ХС ... а вот где, например, в производственной партии указывается вет. врач ... что-то я такого поля не нашёл?

Разве что в качестве инициатора.

Yoreg07 wrote:Поправьте меня, если не прав. При оформлении заявки на ВСД (входящий, производственный или транспортный ... не важно) принцип работы в учетной системе ХС должен быть примерно таким:
1. ХС в своей УС оформляет заявку на какую-либо партию, наполняя её всеми зависящими от него данными
2. Затем эту заявку в этой же УС получает вет. врач и дополняет её уже своими данными
3. Затем генерируется XML и от ИМЕНИ ВЕТ. ВРАЧА (т.е. Initiator - это вет. врач и целевой сервис ServiceID - это mercury-vu.service) заявка уходит в шлюз ... или от имени ХС она должна уходить
???

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

Kano wrote:Добрый день, подскажите... добрался таки до отправки заявки транспортной партии.. встретился такой объект:
Объект ..Response/vetDocument/purpose (Идентификатор версии записи в справочнике целей. Обязательность: 1 - обязательно должно быть заполнено одно из плей, либо UUID, либо GUID) не пойму откуда это брать, помогите пож-та!

Response - данные ответа - они будут предоставлены удалённой стороной. Предоставлять нужно только то, что попадает под Request.

АЙ. Ответ чутка устарел, надо мне чаще проверять форум.

Yoreg07 wrote:Добрый день! Скажите, пожалуйста, что означает фраза "Проверить, как будет происходить процесс смены ветеринарных врачей." при переходе к боевому серверу?
http://help.vetrf.ru/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%BE%D0%B5_%D0%BE%D1%84%D0%BE%D1%80%D0%BC%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B7%D0%B0%D1%8F%D0%B2%D0%BE%D0%BA_%D1%87%D0%B5%D1%80%D0%B5%D0%B7_%D1%88%D0%BB%D1%8E%D0%B7_%D0%92%D0%B5%D1%82%D0%B8%D1%81.API#.D0.9F.D1.80.D0.BE.D0.B2.D0.B5.D1.80.D0.BA.D0.B0_.D0.B2.D1.8B.D0.BF.D0.BE.D0.BB.D0.BD.D0.B5.D0.BD.D0.B8.D1.8F_.D0.BE.D0.BF.D0.B5.D1.80.D0.B0.D1.86.D0.B8.D0.B9_.D0.BF.D0.B5.D1.80.D0.B5.D0.B4_.D0.BE.D1.82.D0.BF.D1.80.D0.B0.D0.B2.D0.BA.D0.BE.D0.B9_.D0.B7.D0.B0.D1.8F.D0.B2.D0.BA.D0.B8_.D0.BD.D0.B0_.D0.B4.D0.BE.D1.81.D1.82.D1.83.D0.BF_.D0.BA_.D0.B1.D0.BE.D0.B5.D0.B2.D0.BE.D0.BC.D1.83_.D1.81.D0.B5.D1.80.D0.B2.D0.B5.D1.80.D1.83.
Какие здесь могут быть подводные камни?

Точно поменяются их логины - на тестовых и на боевом они разные. Точно будут другими и списки обслуживаемых предприятий (вероятность ошибки тут меньше, это всё же реальная работа), что тоже отличие от теста.. Прочие данные тоже не мешало бы проверить - фио, должность...

maltsev wrote:

Yoreg07 wrote:

maltsev wrote:
и главный вопрос, получается я через ВЕТИС API не могу запросить справочник упаковки ?

нет, не можете ... нужно просто вбить его руками и отслеживать его актуальность, если это необходимо

вбить руками в своей УС ? или где ?

В своём модуле интеграции между УС и Меркурием. Если он неотъемлемая часть УС, то да, в УС. К счастью, делается это лишь один раз.

Yoreg07 wrote:Ясно ... будем ждать этот функционал в очередном релизе

Зачем же ждать, если можно уже сейчас создать журнальную запись со всеми нужными типами упаковки, вытащить оттуда все данные и тут же запись удалить?

Yoreg07 wrote:

lalex23 wrote:

b.ivanov wrote:Что делать? Только разработчики в лице Ирины могут предоставить нам актуальный справочник в том или ином виде. Было бы неплохо обновить упомянутый PDF-файлик, конечно.

Лично я бы предпочёл сервис аналогичный тому что есть для единиц измерения, но боюсь что файлик будет оперативнее, если будет.

а какой смысл этого файлика, если завтра он уже может стать неактуальным

Я очень давно уже не трогал этот справочник - никто не жаловался

Yoreg07 wrote:Кстати, насчёт справочников ... в документации подразумевается, что справочник видов упаковки статичен, так как перечислены все данные, в веб-интерфейсе, по-моему есть возможность создавать новые виды упаковки, а API для получения актуального справочника нет (по крайней в документации) ... что делать ... может кто-нибудь ответить?

Аткуального - да, нет. В wiki есть ссылка на устаревший pdf-файлик, в котором нет, к примеру, пластмассовых ящиков. Я справочник заполнил по добавленным в журнал записям, чего вполне хватило. Ввод же упаковок вручную не приветствуется, насколько я знаю, да и в этом случае с отправкой потом вопросы появятся.

Что делать? Только разработчики в лице Ирины могут предоставить нам актуальный справочник в том или ином виде. Было бы неплохо обновить упомянутый PDF-файлик, конечно.

maltsev wrote:на самом деле тема важная, сейчас процента 3 с помощью электронных ВСД работают, а может и того меньше.
А представьте, что все участники рынка будут ходить через "единую точку входа", то по скольку времени будет отрабатывать запрос ?

Я бы больше беспокоился за справочники. А время отклика пока что не особо изменилось за год, на что можно надеяться и в будущем..

Yoreg07 wrote:

Yoreg07 wrote:Добрый день. Скажите, пожалуйста, есть ли на сервере приёма запросов какое-нибудь ограничение по количеству запросов в промежуток времени (ну чтобы сервер не подвисал, например) от одного пользователя, ХС или что-то другое? Просто, тестируя свой интеграционный модуль и отсылая несколько запросов подряд, неоднократно получал ошибку о невозможности подключения ... немного подождав, повторял запросы и они успешно уходили.

Кто-нибудь может ответить?

Я даже параллельно отсылал запросы без особых проблем - лишь бы не пересекались исходные данные (вроде GUID журнальных записей). В обычном последовательном режиме на отправку одного набора данных больше 7-8 секунд не уходит. Сдаётся, проблема локальная или по пути, но не на стороне Меркурия.

maltsev wrote:

Yoreg07 wrote:

maltsev wrote:Позвольте вклиниться! Что значит вносит ? Разве не каждый ХС должен заявлять о себе и подавать за себя документы ?

Т.е. есть я - ХС №1 могу этой операцией добавить в реестр Вас - ХС №2, если Вас там нет ... а затем могу добавлять и удалять связь ХС №2 и Enterprise.

то есть, если фантазировать, то мой конкурент, как Вы привели пример ранее, может меня внести, а я даже знать не знаю об этом до момента пока сам не подам заявку на добавления себя, верно ?

Перед добавлением чего-либо всегда надо проверять, а не сделал ли это кто-то раньше.

Я бы больше переживал за дублирующиеся записи, опечатки и прочее, поскольку можно работать с ХС/предприятием по одному GUID, а сами они будут иметь то же написание даже, но по факту другой GUID. Плюс регулярно бывают изменения всякие, которые довольно сложно держать и тут. К примеру, большой хладокомбинат с кучей всяких сдаваемых складов, секций, которые регулярно меняют арендатора..

Николай Власов wrote:

b.ivanov wrote:
Я предоставляю разные варианты, а уж клиент сам решает, когда ему надо. Простейший вариант - да, через примерно 6-7 секунд после автоотправки уже можно печатать все ВСД по данной накладной (если речь об исходящих, к примеру). Посложнее - почасовые, экономичные, поточечные группировки и тому подобное. Зависит от "толщины" клиента и его запросов. В любом случае, не проблема добавить новых способов печати.

Зря вы это делаете. На печать должен выводится только легальный, т.е. содержащийся в Меркурии эВСД. Так что убирайте из своего решения 6-7 секунд после автоотправки.
В противном случае, если ваше решение позволяет печатать нечто, присутствие чего в базе данных Меркурия им не подтверждено, вы нарушаете правила. Если вы сознательно нарушаете правила, то ваше интеграционное решение будет заблокировано в смысле его возможности работать с Меркурием.
А вот формы для печати того, что в Меркурии содержится, можете генерить сколько угодно.

Определённо, Вы меня не поняли. На печать и выводится легальный, содержащийся в Меркурии ВСД. А 6-7 секунд требуются для того, чтобы Меркурий принял данные и создал этот легальный ВСД. Ничего необычного - это обычная транспортная операция в соответствии с wiki. Разумеется, я не печатаю нечто неподтверждённое и отсутствующее в Меркурии - ведь всё можно проверить. И да, я как раз генерирую различные формы печати на каждый вкус и цвет.

Николай Власов wrote:

Yoreg07 wrote:Могу я вмешаться. b.ivanov скорее всего имел ввиду, что печать осуществляется только после того, как в ответ прийдут идентификаторы ВСД (uuid) ... Разве этот факт не говорит о том, что ВСД уже оформлен в меркурии?

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

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

maltsev wrote:

b.ivanov wrote:

maltsev wrote:что Вы имеете ввиду под модификацией ?

Например, подготовку всяких вариантов пакетной печати, когда нужно одной кнопкой распечатать пачку листов.. Разумеется, речь идёт о модификации печатной формы, а не данных в самом ВСД - они едины для всех, по тому же коду каждый должен суметь "проверить документ".

а вот эти данные самого ВСД в каком формате кодируются ? Я просто не смог найти в wiki, в каком они должны быть.

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

maltsev wrote:

b.ivanov wrote:

maltsev wrote:что Вы имеете ввиду под модификацией ?

Например, подготовку всяких вариантов пакетной печати, когда нужно одной кнопкой распечатать пачку листов.. Разумеется, речь идёт о модификации печатной формы, а не данных в самом ВСД - они едины для всех, по тому же коду каждый должен суметь "проверить документ".

Вы в какой момент печатаете ? Только когда придет подтверждение их ВЕТИС-а, что операция проведена ?

Я предоставляю разные варианты, а уж клиент сам решает, когда ему надо. Простейший вариант - да, через примерно 6-7 секунд после автоотправки уже можно печатать все ВСД по данной накладной (если речь об исходящих, к примеру). Посложнее - почасовые, экономичные, поточечные группировки и тому подобное. Зависит от "толщины" клиента и его запросов. В любом случае, не проблема добавить новых способов печати.

maltsev wrote:что Вы имеете ввиду под модификацией ?

Например, подготовку всяких вариантов пакетной печати, когда нужно одной кнопкой распечатать пачку листов.. Разумеется, речь идёт о модификации печатной формы, а не данных в самом ВСД - они едины для всех, по тому же коду каждый должен суметь "проверить документ".

Yoreg07 wrote:

b.ivanov wrote:

Yoreg07 wrote:

lalex23 wrote:

Yoreg07 wrote:Добрый день. Скажите, пожалуйста, имеется ли возможность в данный момент, или может быть это будет в перспективе, получать данные для печати сжатой формы ВСД через шлюз с целью реализации это печати в учетной системе ХС?

храните данные о транспортной транзакции непосредственно в учётной системе и печатайте сжатую форму по этим данным, мало того - эта форма произвольная, важно указание ИД ВСД, прочая информация идёт как сопроводительная и не столь важна.

Меня больше интересует двумерный QR-код (может это какой-то другой формат двумерного кода) в этой форме, не могли бы Вы более подробно описать способ его формирования?

Разве там закодирована не прямая ссылка на детали по ВСД? ВСД под рукой нет (ах, отпуск), но зато нашёл итоги в истории сканера на андроиде.

Это стандартный QR, который можно сгенерировать стандартными же способами. Вопрос лишь в том, какие из них доступны в конкретном случае. Код можно генерировать на лету, ведь нужно помнить только uuid ВСД, а остальная часть кодируемой ссылки статичная. Вопрос только в том, зачем вообще этот код хранить и генерировать, если можно напрямую получить сам ВСД для печати..

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

Да, это сочетание нескольких технологий, но я не только их получаю оттуда, но и модифицирую по необходимости. Сделать это из учётной системы сложнее, конечно. Хорошо, что моё решение не завязано на одну конкретную уч.систему