Рассмотрим сложную техническую и методологическую задачу: реализацию функционала заявок на денежные средства и механизмов бюджетирования внутри конфигурации 1С:Зарплата и управление персоналом 2.5. В практике часто возникают ситуации, когда руководство настаивает на использовании уже внедренной системы для нецелевых задач. Разберем, насколько это целесообразно, какие «подводные камни» ожидают разработчика и в каких типовых решениях 1С нужный функционал уже реализован «из коробки».
Проанализируем структуру конфигурации 1С:ЗУП 2.5. Эта программа была создана исключительно для расчета заработной платы и ведения кадрового учета. Несмотря на то, что в ней присутствуют справочники, названия которых созвучны финансовым терминам, их методологическое назначение совершенно иное.
Выясним причину, по которой использование типовых справочников ЗУП для бюджетирования является рискованным:
Подразделения в ЗУП 2.5 жестко привязан к штатному расписанию и кадровому учету. Финансовая структура организации (Центры Финансовой Ответственности — ЦФО) зачастую не совпадает с кадровой структурой. Попытка переделать справочник под нужды казначейства приведет к конфликтам в кадровой отчетности.Разберем по шагам, почему разработка собственного функционала («велосипеда») в ЗУП 2.5 — это создание «системы-монстра». ЗУП 2.5 работает на обычных формах и давно снята с полноценной поддержки. Любые серьезные доработки придется поддерживать вручную при каждом обновлении законодательства, что критично для расчета налогов и сдачи отчетности.
Если «наверху» решение принято и отступать некуда, посмотрим на те объекты, которые могут стать фундаментом для вашей подсистемы:
Однако помните, что для полноценной реализации заявок вам придется создать:
// Примерный список новых объектов:
// 1. Документ "ЗаявкаНаРасходованиеСредств"
// 2. Документ "УстановкаЛимитовПоБюджету"
// 3. РегистрНакопления "ЛимитыБюджетирования" (Остатки)
// 4. РегистрНакопления "ДенежныеСредстваКВыплате" (Обороты)
Вместо того чтобы изобретать функционал в неподходящей среде, проанализируем современные системы 1С, где подсистема казначейства является ключевой. Это позволит аргументированно донести до руководства необходимость использования специализированного софта.
Это флагманское решение для автоматизации казначейства. Рассмотрим его преимущества:
В этих системах (версии 2.4 и 2.5) реализован полноценный цикл управления деньгами. Разберем механизм работы:
Заявка на расходование ДДС создается как первичный документ. Она может иметь различные статусы (Не согласована, Согласована, К оплате). При проведении система автоматически проверяет наличие свободного остатка по бюджету данной статьи и подразделения. Если лимит превышен, документ не проведется без специального разрешения. Это именно то, что автор темы пытался реализовать в ЗУП.
Посмотрим на это решение как на надстройку. Это популярный модуль, который интегрируется в типовые конфигурации (чаще всего в «1С:Бухгалтерию»). Он добавляет в интерфейс знакомые финансовым директорам инструменты: казначейство, бюджетирование, управленческий баланс. Если компания не готова к переходу на ERP, внедрение БИТ.ФИНАНС на базе Бухгалтерии — самый рациональный путь.
Проанализируем правильную архитектуру взаимодействия информационных баз. Лучшая практика — разделение функций между системами:
Такой подход гарантирует чистоту данных и исключает риск поломки критически важных механизмов расчета налогов в ЗУП. Выясним причину, по которой это выгодно разработчику: вам не придется поддерживать огромный объем самописного кода в системе, которая обновляется 1С каждый месяц из-за изменений в законодательстве.
Подводя итог, можно сказать следующее: реализовать заявки в 1С:ЗУП 2.5 технически возможно (как и в любой конфигурации на платформе 1С), но методологически это тупиковый путь. Рассмотрим основные тезисы для защиты этой позиции перед заказчиком:
Если решение об использовании ЗУП 2.5 окончательное, рекомендуем ограничиться созданием минималистичного справочника СтатьиДДС и простого документа Заявка, не пытаясь внедрить в ЗУП сложный бюджетный контроль.