Проектирование финансового контура — одна из самых ответственных задач при разработке корпоративной системы на платформе 1С. Когда в цепочке участвуют три стороны (Заказчик — Менеджер — Разработчик) и расчеты ведутся в разрезе множества проектов и платежных систем, стандартных справочников становится недостаточно. Разберем детально, как построить надежную архитектуру денежного оборота, которая обеспечит прозрачность для всех участников и исключит ошибки в балансе.
Первый вопрос, который возникает у разработчика: использовать ли регистр бухгалтерии с планом счетов или ограничиться регистрами накопления? Проанализируем оба подхода.
Регистры накопления (вида «Остатки») являются стандартом для оперативного учета в 1С. Они работают быстрее, проще в конфигурировании и позволяют легко строить отчеты по остаткам и оборотам. Для большинства задач управленческого учета, как в нашем случае, их вполне достаточно.
Регистр бухгалтерии стоит внедрять только в том случае, если вам критически необходим механизм двойной записи. Двойная запись гарантирует, что деньги не могут возникнуть из ниоткуда или исчезнуть бесследно: дебет одного счета всегда равен кредиту другого. Если ваша система предполагает сложные внутренние переброски средств между виртуальными кошельками менеджеров, бухгалтерский подход поможет автоматически контролировать целостность системы.
Однако в данной задаче мы рекомендуем остановиться на регистрах накопления, так как они обеспечивают гибкую аналитику без избыточности, свойственной плану счетов. Мы разделим учет на две составляющие: денежные средства (факт наличия денег) и взаиморасчеты (обязательства сторон).
Для корректной работы системы нам необходимо правильно определить аналитические разрезы. Рассмотрим оптимальную иерархию НСИ:
Проекты, либо отдельным документом (Заказ), который выступает объектом расчетов.Рассмотрим пример структуры регистра для учета взаиморасчетов. Нам потребуется два регистра накопления (или один универсальный с дополнительным измерением):
Регистр ВзаиморасчетыСЗаказчиками:
Заказчик, Проект, Менеджер.Сумма.Регистр ВзаиморасчетыСРазработчиками:
Разработчик, Проект.Сумма.Важно понимать, что денежный оборот — это не только движение купюр или цифр на счетах. Выясним причину, почему нельзя вести учет только по документам оплаты. Если мы будем фиксировать только приход и расход денег, мы никогда не узнаем, сколько работы выполнено, но еще не оплачено, и наоборот.
Поэтому в системе должны присутствовать два типа движений:
ПоступлениеДенежныхСредств и СписаниеДенежныхСредств. Эти документы уменьшают или увеличивают долг в регистре взаиморасчетов и одновременно меняют остаток в регистре ДенежныеСредства.АктВыполненныхРабот. Для заказчика этот документ «закрывает» его аванс или создает задолженность перед нами. Для разработчика — фиксирует, что мы теперь должны ему денег за выполненную задачу.Проанализируем пример кода для проведения документа оплаты от заказчика:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
// Движения по фактическим деньгам (у менеджера на счету стало больше)
ДвижениеДС = Движения.ДенежныеСредства.ДобавитьПриход();
ДвижениеДС.Период = Дата;
ДвижениеДС.СчетОплаты = Объект.БанковскийСчет;
ДвижениеДС.Сумма = Объект.СуммаПлатежа;
// Движения по взаиморасчетам (задолженность заказчика уменьшилась)
ДвижениеРасчеты = Движения.ВзаиморасчетыСЗаказчиками.ДобавитьРасход();
ДвижениеРасчеты.Период = Дата;
ДвижениеРасчеты.Заказчик = Объект.Заказчик;
ДвижениеРасчеты.Проект = Объект.Проект;
ДвижениеРасчеты.Сумма = Объект.СуммаПлатежа;
КонецПроцедуры
При расчетах через электронные кошельки или разные банки неизбежно возникают комиссии. Если заказчик отправил 1000 рублей, а менеджер получил 980, в системе может возникнуть «зависший» долг в 20 рублей.
Чтобы этого избежать, в документах оплаты необходимо предусмотреть реквизиты для комиссии. Сумма, на которую уменьшается долг заказчика (1000), должна отличаться от суммы, которая реально поступила на счет (980). Разница в 20 рублей должна списываться на специальную статью расходов КомиссииПлатежныхСистем.
Для реализации аналитики по платежным системам используем План видов характеристик. Это позволит пользователям добавлять новые типы кошельков (криптовалюты, новые банки) без участия программиста и изменения структуры метаданных.
Согласно постановке задачи, каждый участник должен видеть только свои данные. В 1С это реализуется через механизм RLS (Record Level Security). Мы не просто фильтруем данные в отчетах, а ограничиваем выборку на уровне SQL-запроса платформы.
Разберем, как настроить ограничения:
ГДЕ Заказчик = &ТекущийПользовательКонтрагент. Таким образом, даже если разработчик попытается открыть общий список транзакций, платформа вернет ему только записи, относящиеся к нему лично.В проектной работе часто используется схема, при которой деньги «замораживаются» до момента принятия работы. Для реализации этого механизма добавим в регистр Взаиморасчеты ресурс СуммаЗаблокированная.
Рассмотрим цепочку событий:
СуммаЗаблокированная. Разработчик видит, что деньги в системе есть, но вывести их не может.ПодтверждениеРабот делает перемещение внутри регистра: Расход по ресурсу СуммаЗаблокированная и Приход в ресурс СуммаКВыплате.Для менеджера самым полезным отчетом будет «Управленческий баланс» или «P&L по проектам». Используя данные из наших регистров, мы можем рассчитать чистую прибыль по каждому проекту:
Прибыль = (Сумма актов с Заказчиком) - (Сумма актов с Разработчиками) - (Комиссии систем).
Важно разделять отчет по ДДС (Движение денежных средств), который показывает «кассовый метод» (сколько денег физически пришло и ушло), и отчет по Доходам и Расходам, который показывает финансовый результат независимо от факта оплаты.
Таким образом, комбинируя регистры накопления для учета денег и обязательств, используя аналитику в разрезе проектов и настраивая права доступа через RLS, мы получаем гибкую и масштабируемую систему денежного оборота, готовую к расширению под любые задачи бизнеса.