1С УАТ (Управление автотранспортом). Практика внедрения.


Сие повествование – есть последовательность шагов внедрения системы учёта и автоматизации бизнес-процессов на предприятии. Все описанные ниже события, происходят в настоящее время. Поэтому данный материал, будет дополняться новой информацией!

По возникшим вопросам, обращайтесь по адресу электронной почты: soft@okolokompa.ru

Подробнее про «Патч для 1С УАТ » (БагФиксУАТ) Вы можете узнать здесь.

Предприятие, описываемое в данной статье, занимается грузоперевозками. Основной системой учёта хранения и движений материальных запасов, кадров, бухгалтерии и логистики является — 1С 7.7 Комплексная конфигурация. Которая, на протяжении нескольких лет, была вся «перепилена» и дополнена новым функционалом.

Для предприятия наступил тот момент, когда потребности ведения бизнеса, давно переросли возможности хорошо зарекомендовавшей себя, но устаревшей платформы 1С 7.

Было продумано много вариантов «на чём и как» работать дальше. В пользу 1С 8.3 выбор был однозначен. А на счёт конфигурации, было рассмотрено масса вариантов, вплоть до написания своей «с нуля». Итогом выбора стал УАТ 2.1.3.1 (Управление автотранспортом), по причине того, что это решение, больше всего подходило под требования организации.

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

Забегая вперёд, скажу, это только впечатление. Вся конфигурация состоит из ошибок… Причём, некоторые из них, настолько лежащие на поверхности, что иной раз приходила мысль – вообще кто ни будь перед релизом, тестировал это решение…

Задуманный функционал, как и логика процессов в УАТ вполне прилична, но ошибки, просто сплошные ошибки и недоработки, сводят положительные стороны на нет. Естественно, поправить и доработать можно всё, но только не закрытые модули, которые также присутствуют в конфигурации. И самое главное – цена лицензии. Она не оправдывает свою цену.

Так почему же УАТ? Как правильно и ёмко сказали на одном из интернет ресурсов: «… Он плох, но безальтернативен…». В общем таковы реалии…

Могу сразу сказать, что в поставке присутствует демоверсия (заполненная виртуальными данными конфигурация). Но посмотреть её возможности без ключа, вы также не сможете. Защита устроена таким образом, если при запуске не обнаружен лицензионный ключ, появляется форма его установки. При отказе от установки ключа — конфигурация закрывается. Поэтому, только купив УАТ, вы сможете ознакомиться с его возможностями.

Назад пути нет. Выбора из программных продуктов, подходящих для нашей деятельности, тоже. Будем работать с тем, что имеем.

Мы усложним себе задачу тем, что по мере возможности, не будем вносить изменений в код конфигурации. Для этого используем возможности платформы 1С 8 –«Расширение конфигурации».

Таким образом, все нижеописанные ошибки, мы устраняли при помощи собственного «Патча для УАТ» (БагФиксУАТ)

Вначале, был произведён перенос необходимых справочников из базы 1С 7 в УАТ, в разрезе учёта транспорта и логистики. Конфигурацией – «Конвертация данных» не пользовались. Уж сильно не стандартен был переезд и в перспективе ожидалась синхронизация между базами с расчетом на то, что предприятию придётся работать в двух базах на этапе тестирования. Для этих целей, была написана собственная внешняя обработка для УАТ, которая через OLE подключалась к базе 1С 7.

Из-за проблем с дублированием кодов и незаполненными обязательными реквизитами справочников в базе 1С 7, пришлось вводить для элементов справочников УАТ, дополнительный реквизит ID элемента. В этом месте, наша внешняя обработка для переезда, превратилась в расширение конфигурации, так как возможности платформы 1С 8.3.11, позволили ввести в справочники новый реквизит , в нашем случае — ID элемента.

Базу 1С 7 не «причёсывали», тащили всё как есть, чтобы не терять время. Помеченные на удаление элементы, переносили в новую конфигурацию тоже, где их также делали «помеченными». По причине того, что в старой базе, эти помеченные на удаление объекты, участвовали в общей ссылочной массе.

В свойствах УАТ установлен режим совместимости с 1С 8.3.10, а нам для полноценной работы расширения, необходимо использовать 1С 8.3.11. Поэтому указанное свойство поменяли на «Режим совместимости – Не использовать».

Тут появилась первая проблема: Общий модуль «УправлениеКонтактнойИнформациейКлиент» при работе с адресами вызывал ошибки:

  • Процедура или функция с указанным именем уже определена (ПобитовоеИ)

  • Процедура или функция с указанным именем уже определена (ПобитовоеИли)

При беглом взгляде, в этом модуле подобных функций не было. Сразу пришла мысль… Да ну!!!. Выделил полностью в тексте кода ПобитовоеИ и ПобитовоеИли, щёлкнул правой кнопкой мыши и вызвал Синтакс-помощник. Точно, в 1С 8.3.11 – это теперь своя собственная предопределённая функция!

Как дальнозорки были программисты))). А, может, и притащили её из стандартных подсистем, там комментарии в коде, вроде чего говорили об этом. Вот верите, лень сейчас открывать БСП и смотреть оттуда ли она. Если надо посмотрите сами.

А теперь представьте, что этот ошибочный модуль даже не инициализируется, то есть перехватить в расширении данную функцию Аннотацией &Вместо невозможно. (Мы же решили не менять код конфигурации).

Поэтому выход один, создать собственный модуль — «Собственный_УправлениеКонтактнойИнформациейКлиент», копировать в него весь код «хозяина», переименовывать функции ПобитовоеИ и ПобитовоеИли , искать все вызовы процедур, в которых они участвуют, заимствовать в расширение все объекты, вызывающие их и перенаправлять на новый собственный модуль. Сделали, всё заработало…

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

К примеру, документ – «Заказ на ТС». Ссылается на справочник «Пункты Назначения», где указываются расстояния между этими пунктами. При попытке внести пункт в заказ, возникает ошибка:

Поле объекта не обнаружено (Расстояние)

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

Удаляем целый клок. Создаём собственный общий модуль, так как расстояния задействованы по всей конфигурации. Пишем свои процедуры. Все обращения из объектов конфигурации к вычислению расстояний, переписываем заново и перенаправляем на наш модуль. Всё работает…

Здесь можно дополнить, что по этой самой причине не работал и документ – «Маршрутный лист»; вываливался в ошибку. Тем более создать его, на основании заказа на ТС, не представлялось возможным. Он даже не открывался…

«АРМ Контроль перевозок» — дал много поводов для размышлений. Он не запускался вообще. Выдавал лишь:

Значение не является значением объектного типа (Получить ТекущиеКоординатыТС)

Было обнаружено, что эта ошибка происходит в закрытом модуле. Который ещё, до кучи, поставляется без исходных текстов. Здесь оставалось только догадываться, или ошибка в самом модуле, но его посмотреть мы не можем. Или ошибка в параметрах, которые передаются в этот модуль.

Убито было много времени. Отладчик использовался на всю катушку. Кое-что выяснить удалось, но только на уровне догадок. Переписав код обращения к этому модулю, «АРМ Контроль перевозок», наконец то запустился… Дальше его «копать» не стали. Ждём новых ошибок, поэтому если они будут. А они будут))) вернёмся к АРМу позже…

Двигаемся дальше.

Форма списка справочника ТС и оборудования, так же была ущербная. При выборе детальной информации по ТС, возникала ошибка:

Преобразование значения к типу Булево не может быть выполнено

Во всём было виновато условие, по которому определялось – учитывать работу ТС по спидометру или моточасам. Здесь всё просто – Если Булево СпидометрУстановлен = Истина, значит считаем по спидометру, = Ложь, значит по моточасам.

Условия были написаны программистом правильно, но почему не работало? Всему причиной послужило то, что справочник ТС иерархический и в проверку по этим условиям, «просачивались» группы. Откуда спидометр у группы справочника?))). Самое интересное, что и в коде была проверка на Ссылка.ЭтоГруппа, но УАТовские чудотворцы сравнили овальное с зелёным. Немного поправив код, буквально пару букв, форма списка справочника ТС заработала…

А этот «баг», я бы назвал поэзией программирования))). Документ Путевой лист имеет несколько табличных частей: заправки, сливы, билеты и прочие.

Проверка заполнения этих таблиц осуществляется процедурой ПередОкончаниемРедактирования, где проверяются различные реквизиты на предмет их заполненности в текущей строке. Вроде бы всё нечего, но «светлые» умы Раруса сделали так, что если какой либо из проверяемых реквизитов не заполнен, Отказ сразу становится Истина и более того, выдаётся Предупреждение!!! (Бла, бла у вас не заполнено это).

Чувствуете поэзию и торжество ума программеров!. Вот и пользователь чувствует, когда при заполнении строки, сразу вылетает предупреждение о незаполненности реквизита, до которого он ещё и не добрался))).

Естественно, даже передвинуть скроллбар в таком случае невозможно. И закрыть форму тоже. И закрыть программу тоже. Только жёсткий выход при помощи диспетчера задач.

Ну а мы заимствуем процедуры табличных частей ПередОкончаниемРедактирования в наше расширение. Безжалостно удаляем оригинальный код (оригинальный — во всех смыслах этого слова). И пишем собственные процедуры проверок.

Всё бы было весело, если не потеря драгоценного времени на поиски ошибок и последующего их анализа. Иной раз, логику УАТ понять вообще невозможно, ввиду её отсутствия.

Ну а пока мы боремся с ошибками, наш переезд продолжается. Готовим самостоятельную конфигурацию, которая в дальнейшем, будет служить мостом между УАТ, базой 1С 7 и другими решениями организации. Для начала создадим в ней функционал, который загрузит и сохранит в себе ИД обьектов УАТ, их наименования, ссылки и коды.

Как можно сразу догадаться — это подготовка к «точечному» обмену между конфигурациями. Не будем же мы из-за изменения одного элемента, синхронизировать или опрашивать запросом весь справочник или вид документа. Постараемся сделать синхронизацию «невидимой» и «нечувствительной» для пользователя. Работать ей предстоит потом в режиме сервиса.

Здесь можно ознакомиться с итогами нашей работы за 1,5 месяца.

На сегодня пока всё. Ждите продолжения…