1с бит настройка визирования
Рассмотрены основные системы Бюджетирования (УУ и отчетности) на платформе 1С (Инталев УКФ, Бит Финанс, Рарус УКФ, ИТАН). Несколько раз приходилось выбирать из этих систем подходящую для внедрения. Все удалось "пощупать". Некоторую итоговую информацию разместил в статье.
Инталев УКФ
Основные достоинства для пользователя:
Богатые функциональные возможности. Из существующих решений на платформе 1С наиболее независимо от учетной системы.
Механизм построения отчетов полностью настраиваемый, можно задать источники данных и формулу вычисления каждой строки. В отчет так же добавляется возможность детализации по различным периодам
и расшифровки по доступным аналитикам. Отчет позволяет воспроизвести форму большинства финансовых отчетов.
Механизм импорта данных из Excel и других источников очень гибкий, настраиваемый. Позволяет производить проверки, сразу формировать проводки, выполнять регламентный импорт и т.п.
Механизм трансляции данных содержит в себе целую логику программирования. С условиями, выборами, ветвлениями.
Недостатки для пользователя:
В 7 версии уже встречается терминология вида "виртуальная таблица регистра накопления". что окончательно закрывает возможность настройки системы не подготовленным пользователем
Настройка трансляции тоже процесс не тривиальный, и, к сожалению не линейный. Производительность системы может существенно зависеть от выполненных настроек, а для этого уже нужна квалификация уровня хорошего разработчика.
Система казначейства не продумана и работает не лучшим образом.
Достоинства для разработчика:
Всё-таки есть небольшой шанс обойтись без разработчика.
Недостатки для разработчика:
Технологически решение ужасное. Чего стоит только логика использования ПВХ при которой "лёгким движением руки" можно безвозвратно разрушить всю информацию в системе.
Кроме того до 7-ой версии использовались ВК, с которыми вечно были проблемы.
В коде тоже можно найти много "интересного". Каждая строка снабжена авторскими комментариями, что очень актуально для коробочного тиражного решения.
Можно встретить такой код:
Или такую строку (это одна строка):
Ну или подобные запросы:
Здесь вообще интересно реализован "свой" RLS. Все мы знаем сколько проблем возникает даже с RLS который встроен в платформу. А с таким "внешним" RLS количество этих проблем можно смело умножить на 2.
Итого: Основной недостаток Инталев-а на мой взгляд именно в технологичности. Методология правильная и отработанная, функционала более чем достаточно. Проблема только в том что в процессе внедрения находится
уж очень много ошибок, как логических, так и технологических. А код Интаелев-а модифицировать достаточно сложно ввиду его не самой лучшей структуры.
БИТ Финанс
Изображение главного окна:
Основные достоинства для пользователя:
Очень удобная система настройки цепочек согласования. Гибкая, простая и понятная.
Продуманное и отлаженное казначейство.
Недостатки для пользователя:
Отсутствие управляемого интерфейса для всех подсистем. Поддержка управляемых форм заявлена, но пока "не обкатана". На момент написания статьи "рабочей" версией остаётся версия на обычных формах, она же представлена в демке.
Несколько усложненный механизм настройки трансляции и отчетности. Механизм подразумевает написание кода непосредственно на встроенном языке 1С,
что делает его небезопасным и недоступным обычному пользователю.
Достоинства для разработчика:
"Красивый" код, "1С-Совместимо", открытый код.
Недостатки для разработчика:
Приходится участвовать ещё и в настройке.
Итого: Субъективно одно из лучших решений, немного не дотягивает по функциональности до Инталев-а, но зато существенно выигрывает в технологичности. Так же очень плохо что в решении не поддерживаются в полной мере УФ.
РАРУС УКФ (на 90% "бюджетирование в УПП")
Основные достоинства для пользователя:
Ключ защиты не требуется.
Есть в УПП.
Недостатки для пользователя:
Сложный и недостаточно гибкий инструмент настройки.
Привязка трансляции к статьям бюджета.
Нет казначейства в нормальном виде.
Нет цепочек согласования.
Нет экспорта/импорта данных
Нет настраиваемых форм ввода
Нет настраиваемых отчетных форм.
Достоинства для разработчика:
Типовое решение, грамотно написанный код.
Недостатки для разработчика:
Функционал при внедрении однозначно придётся дорабатывать. Точно придётся дописывать отчеты, формы ввода, механизмы импорта.
Итого: Очень мало функционала. Решение вцелом хорошее, но для его полноценного использования потребуются скорее всего весьма существенные доработки. Часть необходимого функционала реализована конечно в подсистеме МСФО. Но как то очень странно выглядит перспектива её использования для бюджетирования.
ИТАН Управленческий баланс
Основные достоинства для пользователя:
Настройки модели бюджетирования приближены к бизнес-логике, а не к технологии.
Недостатки для пользователя:
Недостаточная гибкость настроек.
Нестандартные и кое-где устаревшие интерфейсные решения.
Достоинства для разработчика:
Шанс обойтись без разработки наверное есть на очень простых проектах.
Недостатки для разработчика:
Те же что и в Инталев-е. Код написан несколько лучше, но не намного.
Использование устаревших механизмов снижает технологичность решения.
Итого: Подробно на решении не останавливался, т.к. оно всё менее популярно становится. Для получения демо-версии придётся пережить атаку продажников, поэтому текущую версию смотрел только по описанию на официальном сайте, остальное по памяти, но как ни странно за 2 года в ней вроде как мало что изменилось. Всё-таки стоит отметить что решение достаточно функционально. Все необходимые инструменты в нём присутствуют. Может с немного непривычным интерфейсом и не самым лучшим кодом, но функциональность есть.
Сокращайте количество точек алгоритмов. Чем больше точек в алгоритме, тем дольше будут происходить действия с алгоритмом.
Пример: был настроен простой алгоритм визирования для документа «Проект договора», в котором было 48 точек. Алгоритм состоял из 6 пользовательских условий, которые определяли тип договора и 7 согласующих по каждому типу договора. Т.е. весь процесс согласования договора был введен в один алгоритм визирования в системе.
Этот алгоритм будет работать гораздо быстрее если его разбить на 6 алгоритмов согласно каждому условию.
После такого разбиения алгоритма необходимо каждый алгоритм назначить документу согласно условиям.
Не ограничивайте права на установку виз пользовательскими условиями, если это можно сделать другими способами (RLS, Роли исполнителей).
Пример: в регистре сведений «Права установки виз» у пользователя «Иванов И.И.» есть права на установки визы «Руководитель ЦФО», но с условием - если в документе ЦФО = Атлантика. И аналогичная ситуация по всем пользователям.
Подобные ситуации лучше решать с помощью назначения прав установки виз для Роли исполнителя.
Используя пользовательские условия, можно назначить права установки виз для Роли исполнителя, например, для роли «Руководитель ЦФО». Тогда в маршруте визирования может быть создана одна точка действия – виза «Руководитель ЦФО», а для каждого конкретного документа система будет подбирать пользователя, который должен визировать данный документ, исходя из принадлежности его к определенной роли и конкретному объекту адресации.
В справочнике «Роли исполнителей» задаются роли, которые будут использоваться в организации для механизма визирования, а также могут использоваться для механизма бизнес-процессов (адресация задач исполнителям).
Для каждой роли может быть указано до трех объектов адресации. Виды объектов адресации хранятся в плане видов характеристик «Виды объектов адресации задач», для каждого вида указывается один из трех типов данных: Организация, ЦФО или Проект.
Флаг «Обязательный» устанавливается, если данный объект адресации обязательно должен быть указан при назначении роли исполнителям задач. В нашем примере рекомендуется установить флаг «Обязательный», чтобы избежать ошибок при назначении ролей исполнителям в регистре «Исполнители задач».
Например, для роли «Руководитель ЦФО» объектом адресации будет являться ЦФО. Для добавления объекта адресации, необходимо в колонке «Вид» выбрать соответствующее значение из списка «Виды объектов адресации задач».
В регистре «Исполнители задач» необходимо указать исполнителей, которые будут согласовывать документы, их роли и объекты адресации.
Далее, в регистре «Права установки виз» создается новая запись, в которой будут установлены права для роли «Руководитель ЦФО». В качестве пользователя выбирается группа «Все пользователи».
В справочнике «Пользовательские условия» необходимо добавить новый элемент справочника. Указать для него наименование, контекст=Текущий объект. В конструкторе произвольного условия выбрать «Прочее» – функция «ДоступнаРольИсполнителя», вид сравнения =, значение «Да».
Нажать кнопку «ОК», затем выбрать роль «Руководитель ЦФО».
Теперь для роли «Руководитель ЦФО» назначены права установки визы «Руководитель ЦФО». Причем, несмотря на то, что мы создали пользовательское условие для документа «Заявка на расходование денежных средств», данное условие будет применяться для всех документов БИТ.ФИНАНС, в которых присутствует реквизит «ЦФО, и в маршруте визирования которых присутствует виза «Руководитель ЦФО».
Ограничение прав на установку виз с помощью RLS.
Если пользователь может видеть только документы своего ЦФО (а не все документы) и имеет права установки виз только по своему ЦФО, то эту задачу можно решить с помощью настройки прав доступа на уровне записей, ограничив для пользователя видимость документов (в т. ч. и для согласования) по ЦФО. При таком ограничении пользователь просто не видит в базе документов, в которых теоретически мог бы установить визу «Руководитель ЦФО». Как настроить права доступа на уровне записей читайте в руководстве пользователя БИТ.ФИНАНС.
Указывайте отборы в обработке «Рабочее место визирования».
Так как обработка выполняет достаточно большой и сложный алгоритм по каждому документу, который проходит согласование, то, по возможности, надо ограничивать список документов по которым будет выполняться алгоритм.
Сохраняйте настройку обработки для пользователей с отборами по критериям, которые помогут выделить нужные документы:
Период (вряд ли необходимо согласовывать документы прошлого года, квартала, месяца и т.д.);
Статус (вряд ли необходимо согласовывать документы в статусах – Черновик, Закрыт, Оплачена, Частично Оплачена, и т.д.);
Тип документа (если пользователь согласует только документ Проект договора, не нужно для этого пользователя выполнять алгоритм по всем типам документов);
Тип виз (большинству пользователей нужны документы, в которых есть доступные им визы и по ним не принято решение, т.е. Тип виз = Доступные не установленные);
И другие критерии, которые помогут сократить список документов, по которым выполнится алгоритм.
В программных продуктах «БИТ.ФИНАНС» автоматизирована процедура визирования (согласования и утверждения) документов ответственными лицами организации – менеджерами, руководителями подразделений или ЦФО и т.п.
Визироваться могут документы «Заявка на расходование денежных средств», «Прогноз платежа», «Форма ввода бюджета», «Реестр платежей», «Проект договора» и другие документы системы.
Визирование осуществляется в документах в отдельной форме, которая вызывается по команде «Согласовано» .
Для установки визы необходимо установить курсор на ячейке «Решение» и щелкнуть кнопкой мыши. Решение выбирается из назначенных в регистре « Назначение видов решений » . Полный перечень видов решений хранится в справочнике «Виды решений при согласовании» .
В перечне виз документа отображается дата «Установить не позднее» , которая рассчитывается следующим образом: дата, когда виза стала доступна для согласования, плюс время, установленное для данной визы в справочнике «Визы». При расчете этой даты может использоваться Производственный календарь , в этом случае в расчете не будут участвовать выходные и праздничные дни. Для использования данного функционала необходимо в Настройках программы (БИТ) установить значение «Да» для настройки «Использовать производственный календарь для расчета даты « Установить не позднее » и указать Производственный календарь в настройке «Календарь».
Помимо этого, в Настройках программы (БИТ) можно установить расписание работы предприятия. В этом случае, при расчете даты «Установить не позднее» , также будет учитываться время начала и окончания рабочего дня.
С помощью кнопок:
- «Установить» - пользователь может проставить сразу все доступные ему визы;
- «Очистить» - очистить все доступные визы;
- «Обновить» - происходит заполнение списка виз, если ранее он не был заполнен в документе.
Каждый согласующий по документу может создать Задачу исполнителю по кнопке «Создать задачу» . При этом в Задаче будет ссылка на текущий документ и на конкретную визу, по которой она была создана. Все задачи и все комментарии по согласованию документа можно просмотреть в отчете «История визирования» на закладке «История», формы «Установленные визы».
Принятие решение по визе только с комментарием или задачей
Для того, чтобы при установке решения по визе обязательными были написание комментария или создание задачи согласующим, в регистре «Назначение видов решений» реализован флаг «Необходим комментарий или задача».
Если установить данный флаг, то при принятии данного решения по визе любым пользователем, будет проверяться наличие комментария или созданной задачи по данной визе. Если комментария или созданной задачи не будет, то решение принять невозможно.
Настройку можно устанавливать для определенных типов документов и для определенных Организаций, например, только для Заявок на расходование денежных средств и только для организации «Атлантика».
Примечание. Для того, чтобы пользователь или группа пользователей могли в документах системы принудительно обновлять перечень виз по кнопке «Обновить» (например, в случае изменения маршрута визирования), нужно в Настройке дополнительных прав пользователей (БИТ) (раздел «Настройки (БИТ)» - подраздел «Права доступа» - команда «Настройка дополнительных прав пользователей (БИТ)») установить значение «Да» напротив настройки «Разрешено обновлять перечень виз» .
После того, как документ завизирован, он изменяет свой статус, например, Заявка на расходование денежных средств изменяет свой статус с «Рабочая» на «Утверждена», после чего она может быть передана в оплату. Переход по статусам может осуществляться в произвольном порядке, установленном пользователем. Подробнее об изменении статусов документов читайте в разделе «Алгоритмы визирования и изменения статусов объектов» настоящего Руководства.
С помощью обработки «Рабочее место визирования» можно установить визы для всех объектов, для которых в конфигурации предусмотрено визирование.
В форме «Константы (БИТ)» на закладке «Прочее» выбирается режим обновления перечня виз в документах: «Обновлять при перепроведении» или «Не обновлять».
Для того, чтобы Заявки на расходование денежных средств, Бюджет на очередной год и другие документы прошли в системе процесс согласования и утверждения, необходимо заполнить некоторые справочники и выполнить ряд других настроек в информационной базе.
Настройки визирования документов выполняются в разделе «Управление процессами» .
УПП+БИТ:Финанс 3.0 Настраиваю правила трансляции. Есть документ он делает движения по нескольким регистрам оборотов. Как можно настроить так что бы трансляция "первых" движений не затиралась трансляцией в другой регистр? Или например с начало док делает движение по регистру бухгалтерии, потом по регистру накопления, а потом опять делает движения по регистру бухгалтерии тем самым затирая набор записей сформированных по движения регистра накопления. Как заставить транслировать по каждому из регистров и что бы не затиралось?
Похоже срабатывает очистка движений перед трансляцией.
Тут выходов 3 может быть.
1. очевидно в том что надо транслировать сразу все одновременно, тогда ничего не затрется
2. После проведения документа создать подписку, и работать с движениями уже после проведения документа вручную
3. Выследить по отладчику когда происходит очистка движений, и сделать так чтобы это происходило 1 раз за проведение документа.
Ели вышлете конфигу могу выключить вредоносные строки, в соответсвии с п.3
(2) Sangre1999,
А как можно сразу "всё одновременно" ?
У меня задача из одного документа сделать трансляцию движений из двух регистров.
С конфигой даже и не знаю. Задача ещё стоит без доработок. И работаю на сервере. У меня даже отладчик нет возможности запустить.
Я так и не нашел как это делать не трогая конфы. Нашел в модуле бит_МеханизмТрансляций процедуру ВыполнитьТрансляциюДвижений, там убрал очистку приемника, а в процедуре ВыполнитьТрансляцию поменял порядо обхода правил на сначала приемник (там я его чищу, а потом получатель)
Если существует какой-то добрый вариант решения этой проблемы буду рад услышать.
Кто-нибудь знает, в чем разница между действиями "Провести по регистрам БИТ" и "Выполнить трансляцию" у обработки "Групповая трансляция и редактирование дополнительных аналитик"?
(5) selena72, Выполнить трансляцию - выполняет правила трансляции доступные для выбранных объектов. "Провести по регистрам БИТ" - сначала выполняется трансляция (см п 1.), затем выполняется проведение по регистрам-бит ДДС. Проведение по регистрам ДДС также может формировать записи в регистр бит_ОборотыПоБюджетам.
Помогите разобраться с настройкой правил трансляции (Бух.2.0+БИТ.Финанс).
Не пойму как нужно настроить трансляцию при таком условии:
Оборот Д51 К62.01
транслируем сумму с "+"
но если в документе Поступление на расчетный счет выбрана определенная статья ДДС или определенный контрагент, тогда нужно сумму с "-".
Не могу добиться формирования суммы с минусом.
Добавила еще одну строку Д51 К62.01 добавила условия, сумму умножаю на (-1.00001) - но формируется все равно сумма с + - от первой настройки - без всяких условий.
Если у меня подряд идут друг за другом две настройки: первая без условий, вторая с условием - как отработает программа?
И еще: правила - могут иметь иерархию - как это отражается на функциональности - какая-то логика есть?
В статье рассматривается минимальная доработка конфигурации БИТ Финанс, с сохранением поддержки, для расширения функционала Визирования: Возрат к предидущим точкам алгоритмов. Полезно будет для программистов и специалистов, занимающихся внедрением БИТ Финанс.
В данной статье пойдет речь об алгоритмах визирования в конфигурации Бит Финанс. Многие программисты сталкивались с проблемой, что в Алгоритмах визирования в Бит Финанс отсутствует возможность возвращать алгоритм к предыдущим точкам маршрута. Как только вы попытаетесь это сделать, система выдаст ошибку.
Вопрос, возможно, кем-то и решенный, но я на просторах интернета так и не нашел решения. Пришлось колдовать самому. Представляю вниманию небольшой набор средств для организации возможности условного и безусловного возврата на предыдущие шаги визирования в алгоритме согласования. Я не претендую на истину в последней инстанции, однако система работает. Итак, приступим.
Идея очень простая. Для возврата на предыдущий этап будем использовать «Решение».
Например, что б вернуть Заявку на этап визирования «Руководитель ЦФО», создадим решение «Возврат рук ЦФО», а для возврата в начало инициатору, создадим решение «Возвращено на доработку»
Теперь создаем регистр сведений «ТочкиВозврат».
Заходим в программу , и заполняем регистр.
По решению «Возвращен на доработку» Алгоритм визирования должен вернуться в начало.
А по решению «Возврат рук ЦФО» алгоритм должен вернуться в точку «Проект договора. Рук ЦФО».
Естественно для каждого алгоритма и решения, нужно указывать свои точки.
Теперь приступим к программированию.
Нам нужно написать Функцию которая определит , что алгоритм запущен повторно БылиВозвраты.
Процедура очистки виз ВернутьНаДоработку.
Создадим общий модуль Алгоритмы и в нем пропишем нужные процедуры и функции , которые будем использовать в алгоритмах.
Теперь собственно реализуем наш механизм. Для реализации механизма , мы воспользуемся алгоритмом изменения статусов.
Для начала в создадим колено с условием , где проверим, что есть решения по возврату . Это собственно и будет путь перенаправления маршрута назад.
Ну и самый ключевой шаг , это присвоение статуса "Возращено на доработку". Обработчике , пропишем вызов нашей процедуры возврата . Пожалуй, это и все.
Читайте также: