При администрировании RDP-сервера, к которому ежедневно подключается, примерно 100 человек, возникает проблема не закрытых сеансов. Пользователи не утруждают себя правильным отключением от RDP-сервера и, просто, закрывают окно подключения к удаленному рабочему столу, на крестик, что в свою очередь приводит к тому, что сессия переходит в статус “Отключена” и продолжает висеть на сервере, процессы внутри этой сессии продолжают выполняться и со временем она начинает потреблять значительно больше оперативной памяти, чем сессия, созданная только что. Решение для данной проблемы следующее:

Перейти к статье »

Чтобы для определенного исследования при его направлении распечатывался не общий, а какой-то отдельный шаблон, нужно добавить этот шаблон через сущность “Шаблон печати анализов”. Затем зайти в то исследование, для которого мы хотим изменить шаблон, перейти на вкладку “Шаблоны печати” и выбрать в нужном поле наш шаблон.

В сущности WORK_SCHEDULE_ITEM (График работы) сохраняется расписание врачей только за последнюю неделю. Чтобы оставлять в ней расписание за другой период, нужно в конфигурационный файл сервера AKUZ.Service.exe.config, в секцию <AKUZ.Server> добавить ключ:

Если не открывается превью при печати больничных листов или файл .tpx пытается открыться в какой-либо другой программе, например Microsoft Word, нужно создать .REG файл, внести в него следующий код и запустить, согласившись на внесение изменений в реестр:

Перейти к статье »

Проблема: не идет звонок на внутренний номер, возвращается статус “486:Busy here”, всё на первый взгляд нормально, но нет же, звонок на этот номер не идет!!!

Перейти к статье »

Для настройки REST-сервиса на сервере CentOS в качестве службы нужно выполнить следующие действия:

Перейти к статье »

Updater 2.8 с версии … до версии 3.127

Updater 3.0 с версии 3.128 до версии 3.163

Updater 3.1 с версии 3.164 до версии …

 

Настройка сканера штрих-кодов:

Перейти к статье »

Краткое описание логики: Модуль интеграции с кассой собирает данные и отправляет их в очередь RabbitMQ – CashMachineQueue. На кассе, в свою, очередь должна быть установлена служба Cash machine service, которая будет слушать очередь RabbitMQ, при появлении сообщения в прослушиваемой очереди и отсутствии файла FileFlag.txt, путь до которого задан в конфигурационном файле службы Cash machine service, забирает это сообщение, затем на его основе формирует файл Check.txt, который кладет в заранее определенное место, где кассовая программа готова его подгрузить себе. Индикатором того, что появился новый чек, который необходимо подгрузить в ПО кассы, также является наличие файла FileFlag.txt, другими словами, после того, как будет создан файл check.txt, создаётся файл FileFlag.txt и система понимает, что появился новый чек. Файл FileFlag.txt будет существовать до тех пор, пока кассовая программа не обработает файл check.txt и не удалит файл FileFlag.txt. Затем, после обработки чека на кассе (в отложенных чеках) кассовое ПО даёт ответ в виде файла oper.txt, появление которого мониторится службой Cash machine service на кассе, как только он появится, служба перемещает его в свой каталог и отправляет в очередь RabbitMQ – FromKassaToAKUZ. Служба AKUZ слушает, не появилось ли сообщение в очереди FromKassaToAKUZ и, если появилось, то сажает это сообщение в виде результата в Витакарту.

Перейти к статье »

Здесь я буду в структурированном виде описывать возможности автоматизированной информационной системы “Витакарта”, со ссылками на статьи.

Перейти к статье »