Предприятие занимается отгрузкой воды на водовозы. Очень долгое время учет велся по бумажным талонам, с использованием бумажных журналов. Руководством было принято решение – перейти на что-то более современное и вести автоматизированный учет. Ранее учет велся в бумажных журналах путем записей в журнал отгрузок и соответственно с помощью бумажных талонов, которые в момент отгрузки изымались от клиента и прикладывались к журналу.
Был разработан шкаф управления, содержащий в себе контроллер, который управляет движением заслонки. Встал вопрос по учету в программе 1С.
Для того, чтобы понимать, какой из контрагентов заправился водой – решено было использовать магнитные карты, с применением считывателей магнитных карт. На сайте производителя считывателей было несколько примеров по работе с его оборудованием – в том числе и конфигурация подключаемого оборудования. Поэтому за основу взяли эту конфигурацию, чтобы решить проблему со считывателями и не заморачиваться долгим подключением и настройкой.
Основной учет ведется в программе Бухгалтерия предприятия, нам соответственно необходимо получать данные о поступлении денежных средств.
Исходя из потребностей - нам необходимо несколько рабочих мест: Сотрудник, который будет заключать договора и выдавать (прикреплять карты), для руководства рабочее место, где бы они могли видеть основные показатели работы, а также основное рабочее место – это АРМ Оператора.
Первоначально мы пошли стандартным путем 1С – обычный журнал документов, с добавлением новых отгрузок, но – операторы не обязаны разбираться в 1С, заморачиваться проведением документов, они вообще не должны работать в такой логике.
АРМ Оператора за несколько вечеров нарисовал разработчик АСУ и шкафа управления, который имеет опыт работы с различным оборудованием, в том числе с различными панелями управления, но раз нужен был учет отгрузок и ведение баланса по контрагентам – было решено все эти функции передать 1С.
Интерфейс состоит из двух частей – левая часть – данные по оборудованию, и панель управления – это ввод количества кубов, ПУСК ПАУЗА ЗАПИСАТЬ. Соответственно пуск – запуск отгрузки воды, пауза- закрыть на некоторое время заслонку, чтобы можно было перекинуть шланг раздачи воды в другую секцию автомобиля и продолжить отгрузку. Ну и соответственно записать – завершение отгрузки и принятие к учету документа с расходом отгрузки. Операторы в момент получения от нас программы сразу поняли, что в интерфейсе – есть возможность увеличивать масштаб, и с удовольствием воспользовались этой функцией - чтобы лучше видеть на экране процесс и удобно нажимать на нужные кнопки.
Правая часть интерфейса – это данные о контрагенте, балансе и данные о карте. Соответственно при прикладывании карты у диспетчера справа появляется информация о карте, какой баланс – может ли быть произведена отгрузка в соответствии с балансом или нет.
Затем операторы добрались до изменения масштаба и сделали так, как им захотелось. Собственно, мы не возражали, если им так удобно – пусть пользуются!)
Весь учет в отдельной конфигурации решено было построить на кубических метрах, так как учет денежных средств там был не нужен.
Сервер управления работает по технологии WebSocket, то, что как раз в 1С не реализовано, здесь на сайте Инфостарт - мы приобрели библиотеку для работы с сокетами, немного повозившись с установкой в системе, мы получили первый успех – получаем информацию от шкафа управления о счетчике, текущем состоянии оборудования и его статусе. К сожалению, железную часть разрабатывали и проектировал не я - поэтому что-либо рассказать подробнее не могу.
Сначала мы использовали стандартный путь подключения внешних компонент
Принцип работы с интерфейсом диспетчера – при получении баланса по карте мы понимаем, можем ли мы отгрузить данному клиенту или нет. Если можем - посылаем через веб.сокет команду контроллеру - шкафу управления на запуск открытия заслонки. Также соответственно и при закрытии – команда на закрытие, команда на паузу.
Изначально без дела на сервере была уже установлена старая платформа 8.3.8, которая с трудом поддерживала конфигурацию с библиотекой подключаемого оборудования.
При подключении библиотеки с вебсокетами и одновременно работающих библиотеках для считывателей, а также нескольких фоновых заданиях – столкнулись с такой проблемой – при нажатии на клавишу ПУСК – проскальзывало какое-то внешнее событие и дергался курсор и в тот момент, когда информация приходила - выходило так, что мы не нажимаем на кнопку, хотя пользователь уверенно нажимал на кнопку «Пуск», поэтому приходилось это делать дважды. И еще один момент, для того чтобы оператору было удобно работать, нам нужно было выделить для него все окно монитора без дополнительных там данных или видимого рабочего стола – как оказалось, такая возможность была доступна минимум в 1С Предприятии 8.3.10.
Была у нас в запасе еще одна установленная платформа 8.3.17. НО!!! Чтобы решить проблему с дерганием мыши во время обмена по внешним событиям – необходимо было переписать загрузку библиотек. И как выяснилось, более-менее приемлемый вариант загрузки библиотек можно реализовать через асинхронный вызов «Ждать» и «ПодключитьВнешнююКомпонентуАсинх», то есть это опять же свежие версии платформ. Так мы и добрались до 8.3.22))
Сработало и помогло подключать асинхронно внешнюю компоненту – дергания прекратились.
Итак, все взлетело в платформе 8.3.22. Оператору также нужно было вывести данные о текущем времени на экран – и выяснилось, что это какая-то проблемная вещь)) во время работы фонового задания (и да, 1С не рекомендует использовать для этого ПодключитьОбработчикОжидания) – фокус постоянно дергается в активный элемент управления – то есть когда обновляется секунда у часов, фокус уходит куда-то неконтролируемо в элемент управления - эту проблему так и не побороли, но благо, таких элементов управления у оператора несколько.
Хотелось бы, чтобы еще в углу экрана справа выводилось видео с камеры о приезде автомобиля на отгрузку воды, но попробовав несколько скриптов и html-страницу, так нам и не удалось побороть 1С, веб-кит не хотел воспроизводить по тегам <video></video> какое либо видео, и поток приходится конвертировать из rtsp - во что-то более приемлемое для webkit’a. Обратившись в техподдержку 1С – о том, чтобы подсказали, как побороть –ПолеHTMLДокумента – получили ответ – а подскажите, причем тут 1С. Коллеги, у кого получилось нечто подобное, буду рад, если подскажете. Было решено оставить эту затею, так как подходили сроки сдачи работ.
Далее для того, чтобы был факт отгрузки – нам хотя бы сохранять какое-либо фото с камеры. Таких возможностей у 1С нет, но есть возможность запускать какие-либо приложения, допустим батник с командой какому-либо приложению на сохранение картинки с камеры. Этим мы и воспользовались. Чтобы это все дело не выскакивало в момент работы оператора (режим работы базы клиент-серверный) – прописали фоновое задание на сервере – которое в момент прикладывания карты к считывателю – сохраняет картинку с камеры. Из того, что можно было бы применять, мы нашли - ffmpeg – отличная библиотека для работы с видео и снимками с камеры. Выводим оператору – пока картинку, полученную на сервере и переданную обратно в интерфейс оператора на клиент. В момент записи факта отгрузки – мы прикладываем данные в документ отгрузки – о контрагенте, его карте, количестве отгруженной воды и картинку с камеры.
Для ведения минимального учета в программе, где у нас идет работа с картами, налив/отгрузка воды и работа оператора – создали несколько документов – Отгрузка воды, и поступление данных о объемах. В дальнейшем выяснилось, что для того, чтобы перейти с учета талонов на карты, нам необходимо будет забрать и ввести остатки объемов с талонов в нашу новую систему – поэтому напрашивался сам собой документ ввода остатков. Также раз в несколько лет или раз в год меняется тариф на воду, поэтому необходимо учитывать этот момент и уже необходим документ на конвертацию объемов по тарифам.
Учет по приходу денежных средств в 1С: Бухгалтерии ведется несколькими стандартными типовыми документами – Поступление на расчетный счет, Оплата от покупателя платежной картой, Приходный кассовый ордер. Для того, чтобы получать данные о вводе этих документов – мы добавили расширение – с планом обмена – в котором фиксировались изменения по этим документам. Далее эти изменения через фоновое задание мы передаем в нашу конфигурацию по отгрузке воды. Самое удобное средство, которое пришло в голову на тот момент, помимо COM-соединения – использовать HTTP-сервисы. То есть, фоновое задание отправляет json-данные на определенный адрес в локальной сети, а это наша конфигурация, опубликованная на сервере – (конфигурацию с отгрузкой воды) – все сервисы мы разместили в нашей конфигурации, чтобы по минимуму делать какие-либо доработки в базе БП 3. Итак, контрагент (клиент) оплатил через расчетный счет или через кассу, или по карте – сразу же мы получаем сумму, делим ее на текущий тариф и этот объем передаем через http-сервис в нашу конфигурацию отгрузки – получаем приход объемов. Но этого маловато, так как нам нужны еще и контрагенты в нашей конфигурации, чтобы привязывать объемы к контрагентам, поэтому есть еще один http-сервис, который передает контрагентов, у которых есть договоры на отгрузку воды – в нашу систему отгрузки.
И еще один http-сервис, который получает текущий тариф – через установку цен номенклатуры. На случай, если тариф изменится и нужно будет пересчитать старые объемы - на новые объемы.
Чтобы затем создавать УПД (реализацию), в бухгалтерию предприятия – мы используем http-сервис, который отдает объем отгруженной воды за выбранный период.
Далее все это мы фиксируем в регистре накопления, дабы ничего не забыть и вести нормальный учет приход - расход - остаток. Также руководство хотело видеть данные по счетчику ежедневно – для этого нам нужен был ввод остатка текущего по счетчику. Также были данные по счетчику из шкафа управления. Мы их просто фиксировали для того, чтобы сравнивать – вдруг пойдет какая-то разница в показаниях.
Также для просмотра и контроля – понадобились отчеты. Отчет по расходу воды, отчет по счетчикам, отчет по картам – движения в разрезе карт, так как на одного контрагента – был один баланс карты, но количество карт – мы выдавали на количество машин, то есть могла быть не одна карта.
Интерфейс для руководителя и для работы с данными
Выводим и обновляем периодически данные о текущей отгрузке и счетчиках. Если необходимо, выбираем нужную дату и смотрим предыдущие показатели. Что-то в виде – панели управления)
У нас получилось несколько счетчиков – программный счетчик на начало запуска системы, получаемый вводом остатков и дальнейшим расходом воды, и счетчик – который приходит от шкафа управления – от оборудования – решили их контролировать, вдруг пойдут расхождения.
Для надежного контроля на первых порах – приняли решение, подкреплять отчеты – оповещениями на электронную почту. То есть по завершении рабочего дня – руководителю на почту приходит письмо с сегодняшним объемом отгрузки в разрезе контрагентов и данными по счетчику на начало дня и на конец дня. Добавили в письмо на всякий случай еще и недельный график (диаграмму) по отгрузке. Также, чтобы не пропустить данные по поступлениям – в момент поступления объемов – фиксируем и отправляем письмо на почту – что поступила оплата от контрагента.
Есть еще одна небольшая проблема, которую решили вторым считывателем. Для того, чтобы отпускать розницу – решили, что как-то не очень нормально каждому розничному клиенту давать карту, поэтому карта, которой совершается отгрузка, находится у оператора. В момент оплаты на счет розничного клиента – поступает объем - и он этот объем забирает без карты, карту прикладывает сам оператор. Еще есть такая же отгрузка на собственные нужды. То есть в текущем моменте у нас два подключенных считывателя – один уличный для клиентов, второй у самого оператора.
Интерфейс специалиста по работе с картами
Коллеги, если будет интересно, постараемся написать статью о технической стороне вопроса – по шкафу управления.
На этом пока все.
