Автор |
Сообщение |
|
Yoreg07 wrote:
lalex23 wrote:
Yoreg07 wrote:Добрый день. Скажите, пожалуйста, имеется ли возможность в данный момент, или может быть это будет в перспективе, получать данные для печати сжатой формы ВСД через шлюз с целью реализации это печати в учетной системе ХС?
храните данные о транспортной транзакции непосредственно в учётной системе и печатайте сжатую форму по этим данным, мало того - эта форма произвольная, важно указание ИД ВСД, прочая информация идёт как сопроводительная и не столь важна.
Меня больше интересует двумерный QR-код (может это какой-то другой формат двумерного кода) в этой форме, не могли бы Вы более подробно описать способ его формирования?
Разве там закодирована не прямая ссылка на детали по ВСД? ВСД под рукой нет (ах, отпуск), но зато нашёл итоги в истории сканера на андроиде.
Это стандартный QR, который можно сгенерировать стандартными же способами. Вопрос лишь в том, какие из них доступны в конкретном случае. Код можно генерировать на лету, ведь нужно помнить только uuid ВСД, а остальная часть кодируемой ссылки статичная. Вопрос только в том, зачем вообще этот код хранить и генерировать, если можно напрямую получить сам ВСД для печати..
|
 |
|
Max wrote:Сотрудники ФГБУ, - подскажите:
1. Какой функционал предоставляется для сторонних системам, подключённых через Ветис.API?
2. Работает ли ограничение функционала (профили доступа) в подключённой системе при входе пользователей с различными учётными данными?
Я не сотрудник ФГБУ, но ответ вполне могу дать:
1) функционал для сторонних систем http://help.vetrf.ru/wiki/%D0%92%D0%B5%D1%82%D0%B8%D1%81.API - уже по ссылке информации для ответа достаточно
2) если речь о веб-интерфейсе, то ответ - определённо, на тестовом сервере можно частично заглянуть и со стороны администрации. Если речь о "подключенной системе" (своё решение по интеграции), то доступ определяется отсылаемыми в запросе реквизитами.. Работать с информацией, отношения к которой конкретный набор реквизитов не имеет, не получится.
|
 |
|
maltsev wrote:а можно в этой кучке единой понять, какая ВСД была создана через вэб, какая через шлюз?
Подобный вопрос возникал и у меня. Если создаётся своей же программой, то её разумно было бы и помнить все сформированные ВСД. Когда-то этот же вопрос у меня решился просто - созданные вручную операции отличались укороченной версией номера ТТН, а машина же отправляла полное наименование. На тот момент решение вполне было простым. Также были некоторые менее заметные отличия при просмотре деталей по ВСД от машины и от человека (должность врача машиной отправлялась корректно, но не отображалась или что-то вроде того). Думаю, сейчас это уже исправили. Для случайно взятой ВСД способа определить "авторство" с нашей стороны нет. А было бы интересно, да.
Если вспомнить следующее сообщение в этой же теме, вполне можно ожидать и технической возможности удалённо увидеть, кто или что создало ту или иную ВСД. Полагаю, о публикации этой информации через АПИ стоит просить разработчиков.
Николай Власов wrote:В связи с тем, что количество интеграционных модулей у нас растет в геометрической прогрессии, к разработчикам большая просьба. Пожалуйста сделайте своим интеграционным программным продуктам подпись (не имею в виду ЭЦП), по которой можно было бы идентифицировать автора (разработчика) интеграционного решения и площадку, где установлена и работает его данная n-я копия.
|
 |
|
Gorkova wrote:
Попробую своими словами написать как понимаю что там написано:
1) Когда оформляется ВСД через шлюз - это делается одной заявкой к шлюзу на операцию (через API).
Т.к. ее отправляет ИС хоз.субъекта - там говорится, что надо как-то ХС озабоиться тем, чтоб вет.врач мог это действие из ИС сделать.
2) когда оформляется ВСД средствами веб-интерфейса - это проходит в 2 этапа - ХС оформляет заявку на ВСД, а вет.врач подтверждает/отклоняет.
(Они заходят в веб-интерфейс под разными пользователями с разными полномочиями)
Но в итоге созданные и первым, и вторым способом ВСД - в Меркурии в одной "кучке" у предприятия.
Об этом я и говорю же. Веб-интерфейс - это то же самое, что делаем мы. Своего рода, модуль интеграции, но без учётной системы. Веб-интерфейс через тот же шлюз или даже напрямую обращается к основной базе данных, формируя "прослойку" с заявками, "номерами" ВСД и прочим функционалом, который, по идее, нам и надо было повторить. Вот только все эти особенности не являются частью шлюза, да и храняться отдельно, наверное.
Другими словами, заявки нельзя создать через апи. Разве что разработчики специально дадут такую возможность. Между прочим, это был один из первых вопросов к ним, когда всё это дело начинал писать. Я тогда и хотел создавать заявки, чтобы избавить людей от ручной работы с веб-интерфейсом.. Если особо запариться, к веб-интерфейсу можно получить программный доступ, но оно того не стоит.
|
 |
|
"Заявки" - функционал самого веб-интерфейса и только, а не системы в целом.
|
 |
|
А программное аннулирование всд (withdrawVetDocumentRequest) на боевом уже работает?
Ответ от 1 августа был "сейчас работаем над этим", хотелось бы узнать данные поактуальнее. Лишний раз на реальных данных тестировать как-то нехорошо - если метод не работает, то придётся отвлекать ветеринарных врачей с просьбой аннулирования. Ждать первую реальную ошибочную выписку ВСД тоже можно долго.
|
 |
|
Егорова Ирина wrote:Борис, не вводите, пожалуйста, в заблуждение. Для сервисных запросов достаточно HTTP-авторизации. Заголовки однотипны. Пример из нашей документации, запрос к EnterpriseService:
Не согласен, отправить изучать документацию не есть вводить в заблуждение всё же. Как и фраза "если ApiKey, serviceId, issuerId имеются, значит они и обязательны" применительно к конкретному запросу. Но да, ответил чутка не по теме, хоть и рядом.
|
 |
|
Yoreg07 wrote:Спасибо, понял ... просто в примерах из PDF документации (Dictionary_service, Product_Service и т.д.) ничего не упоминается про ApiKey и т.д.
То документация по справочной информации, для которой с авторизацией попроще.
|
 |
|
Yoreg07 wrote:Здравствуйте, подскажите пожалуйста, необходимо ли в сервисных запросах указывать ApiKey, serviceId, issuerId и issueDate? Если можно, то приведите пример любого сервисного запроса.
Это часть процесса авторизации, как без этого? Обязательность параметров и примеры есть в документации. Как правило, если ApiKey, serviceId, issuerId имеются, значит они и обязательны в конкретно этом запросе.
|
 |
|
lalex23 wrote:
b.ivanov wrote:
lalex23 wrote:
b.ivanov wrote:Также стоит отметить, что упомянутый номер можно получить по uuid 
не понял, номер который присваивается в Меркурии? только что ведь говорили что никак?
Я говорил, что этот номер не нужен.
По uuid можно отобразить детали по ВСД и печатную форму. В деталях есть номер всд.
похоже мы друг друга не понимаем...
я понимаю что номер не нужен, вменяемые вет. врачи понимают, для невменяемых хотел сделать печатную форму идентичную той что в Меркурии, не хватает только номеров, которые выводятся в шапке и назначаются Меркурием
невменяемые не наши вет.врачи, а те что получают продукцию, ради этих экземпляров пока печать идёт из веб-интерфейса
Но для этого и нужен uuid всд, позволяющий получить печатную форму меркурия.
|
 |
|
lalex23 wrote:
b.ivanov wrote:Также стоит отметить, что упомянутый номер можно получить по uuid 
не понял, номер который присваивается в Меркурии? только что ведь говорили что никак?
Я говорил, что этот номер не нужен.
По uuid можно отобразить детали по ВСД и печатную форму. В деталях есть номер всд.
|
 |
|
lalex23 wrote:
минутка рекламы
не проблема найти, проблема в том что на это тратится время, не основная но неприятная
основная проблема в том, что распечатать бумажку 1:1 как из Меркурия, средствами 1С не получится, тупо из-за невозможности получить полный пакет информации
очень тяжело убеждать некоторых упоротых вет.врачей, которые и на Меркурий смотрят с опаской, а в случае каких-либо отличий и вовсе впадают в ступор
это исключительно человеческий фактор, который решился бы просто передачей этого номера сервисом вовне в описании вет.документа
Поэтому я шёл путём иным, не привязанным к недостаткам конкретных учётных систем. Информации для печати уже достаточно предоставляется. Номер всё ещё не нужен, uuid с головой хватает для печати. К слову, со случаями буквально саботажа тоже сталкивался, но всё решается пряником В частности, реализовывался спец.функционал для экономии времени самих вет.врачей на рутинные проверки, отчёты и анализ, что позволяет сделать дополнительный перерыв на чай с упомянутым пряником.
Также стоит отметить, что упомянутый номер можно получить по uuid
|
 |
|
Через веб простейший способ найти ВСД - искать по номеру ТТН. Способ долгий, не особо удобный.
Номер из 5-6 знаков является внутренней частью веб-интерфейса меркурия. По сути, это их реализация того же самого, чем занимаемся мы. Но для доступа извне действительно достаточно упоминавшихся uuid документов. Этот 5-6-значный номер и не нужен.
Пару сообщений назад я как раз говорил про организацию печати сторонними средствами. У меня ничего не надо искать вообще - все ВСД автоматом группируются для пакетной печати одной кнопкой по различным признакам.
|
 |
|
dfurtsev wrote:Подскажите, кто как решает вопрос печати ВСД?
Я так понимаю, есть вариант печатать сразу из 1С на официальных бланках.
А можно ли печатать, используя шлюз и Ветис.API?
Пришлось предусмотреть целую пачку разных вариантов печати документов. У каждой организации свои методы печати ВСД, разные варианты группировок (по времени, по транспорту, по точке доставки/складу/позициям).. Есть даже пакетная печать одной кнопкой. Вот только не совсем понятно, что есть печать через "шлюз" и "ветис.апи". Речь о тех ссылках, что открывают информацию с деталями по всд?
b.ivanov wrote:Напоминаю, что можно снять с себя всю головную боль по созданию модуля интеграции:
b.ivanov wrote:День добрый, коллеги.
Имеется реализованный модуль интеграции произвольной учётной системы и Меркурия, позволяющий автоматизировать оборот документов целиком и полностью, сохранив управляемость процессом. Успешно работает уже довольно долгое время с несколькими различными учётными системами, в том числе с 1С и с учётной системой на базе СУБД Oracle9, а количество обрабатываемых документов исчисляется тысячами ежесуточно. При этом учётные системы практически не нужно изменять. Буквально - не понадобится устанавливать никаких программных продуктов или модулей.
Собственно, совершенно не критично, на чём конкретно строится учёт в Вашей компании - мы готовы решить вопросы со всем этим за Вас, избавив от изучения документации и разработки.
Обращаться можно сюда: электронная почта
К этому всему теперь прилагается довольно весёлый набор инструментов из тонкостей, хитростей и костылей, собранных тут и там.
|
 |
|
Gorkova wrote:
lalex23 wrote:чего-то обязательного сильно не хватает
Да уж 2 раза прошлась по обязательным полям - все есть. Если только не считать поля для входящего vetCertificate, у которых формально стоит обязательность 1, но сказано, что если заполнено UUID, остальные заполнять не нужно. Вот этот вариант и пробую - UUID подставляется, остальные поля нет (как и в одном из примеров). Может быть в этом причина?
Отталкивайтесь от того, что обязательно всё. Не всегда известно, в каких ситуациях там "0..1" означает "1".
|
 |
|
|
|