← На главную

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

Рассмотрим два основных подхода, которые чаще всего применяются в экосистеме 1С: использование регистров накопления и использование регистра бухгалтерии. Разберем их преимущества, структуру и логику работы.

Вариант 1. Использование регистров накопления (Оперативный учет)

Этот подход считается классическим для управленческих систем, где важна скорость работы и простота структуры. Мы разделим учет на два контура: взаиморасчеты (обязательства сторон) и движение денежных средств (фактическое наличие денег на счетах).

Проанализируем структуру первого регистра ВзаиморасчетыПоЗаказам (тип: Остатки):

• Измерения: Проект, Менеджер, Заказчик, Исполнитель.
• Ресурсы: Сумма.

Структура второго регистра ДвиженияДенежныхСредств (тип: Остатки):

• Измерения: Проект, ВладелецКошелька (Контактное лицо), ПлатежныйСчет (банковский счет или электронный кошелек).
• Ресурсы: Сумма.

Рассмотрим логику работы документов в этой модели:

1. Поступление оплаты от Заказчика менеджеру:

Документ делает две записи (движения):

1. Приход в регистр ВзаиморасчетыПоЗаказам. Мы фиксируем, что по данному проекту долг перед заказчиком закрыт (или возник аванс).
2. Приход в регистр ДвиженияДенежныхСредств. Увеличиваем остаток на виртуальном или реальном кошельке Менеджера.

2. Выплата Разработчику:

Документ делает следующие движения:

1. Расход по регистру ДвиженияДенежныхСредств со счета Менеджера.
2. Приход по регистру ДвиженияДенежныхСредств на счет Разработчика (если мы ведем учет его кошельков).
3. Расход по регистру ВзаиморасчетыПоЗаказам, уменьшая задолженность перед Разработчиком за выполненную работу.

Главный минус этого подхода, который мы должны учитывать: при получении отчетов нам придется делать сложные запросы с объединением по полям Отправитель и Получатель, чтобы увидеть общую картину. Чтобы этого избежать, в современных системах вводят понятие Объекта расчетов (например, Договор или Заказ), который выступает ключом связи.

Вариант 2. Использование регистра бухгалтерии (Балансовый метод)

Этот вариант более гибкий и методологически правильный, если нам нужно контролировать «целостность» системы (баланс). Здесь используется механизм двойной записи (Дт — Кт).

Для реализации нам понадобится простой ПланСчетов со следующими счетами:

• Счет «Заказчики» (аналог 62 счета). Субконто: КонтактноеЛицо, Проект.
• Счет «Менеджеры» (аналог 71 или 76 счета). Субконто: КонтактноеЛицо, ПлатежныйСчет.
• Счет «Разработчики» (аналог 60 счета). Субконто: КонтактноеЛицо, Проект.

Разберем проводки, которые будут отражать бизнес-процесс:

1. Передача денег от Заказчика Менеджеру:
   Скопировать код

   
   Дт Менеджер (Субконто: Менеджер Иванов, Кошелек WebMoney) — Кт Заказчик (Субконто: ООО "Ромашка", Проект "Сайт")
   

2. Передача денег от Менеджера Разработчику:
   Скопировать код

   
   Дт Разработчик (Субконто: Петров, Проект "Сайт") — Кт Менеджер (Субконто: Менеджер Иванов, Кошелек WebMoney)
   

Преимущества данного метода очевидны: мы всегда видим баланс. Сумма на счете Менеджера покажет, сколько денег у него «на руках» в данный момент. Мы легко можем добавить новые разрезы учета, просто добавив Субконто к счету, даже не меняя структуру регистра накопления.

Важные дополнения к архитектуре

Независимо от выбранного типа регистра, для качественной системы взаиморасчетов проанализируем следующие аспекты:

Учет прибыли (Маржа)

В схеме «Заказчик -> Менеджер -> Разработчик» неизбежно возникает разница в суммах (доход компании/менеджера). В регистрах накопления для этого рекомендуется создать отдельный оборотный регистр ДоходыРасходы. При выплате разработчику сумма его вознаграждения (например, 70%) списывается с проекта, а остаток (30%) должен фиксироваться как прибыль. Без этого вы не сможете ответить на вопрос: «Сколько мы заработали на проекте X?».

Мультивалютность

Даже если сейчас расчеты идут только в рублях, закладывайте в ресурсы регистра три типа сумм:

1. СуммаВзаиморасчетов (в валюте договора, например, USD).
2. СуммаУпр (в единой валюте базы для отчетов руководству).
3. СуммаРегл (для отчетности, если это потребуется).

Это позволит избежать переписывания всей архитектуры при появлении первого иностранного контрагента.

Детализация платежных систем

Если платежных систем много (разные банки, кошельки, криптообменники), не стоит плодить измерения в регистре накопления. Выясним причину: это раздувает таблицы и замедляет работу. Правильнее использовать справочник БанковскиеСчета или ЭлектронныеКошельки, где в реквизитах будет указана принадлежность к платежной системе, а в регистре хранить только ссылку на этот элемент справочника.

Итоги выбора

Проанализируем ситуацию: если ваша база предполагает огромный объем микротранзакций (тысячи в час), выбирайте регистры накопления из-за их высокой производительности на запись. Если же вам важна аналитическая гибкость, возможность быстро строить баланс и отслеживать, «куда делись деньги», регистр бухгалтерии будет вне конкуренции.

Оптимальным решением для самописной конфигурации среднего масштаба будет использование регистров накопления с четким разделением на «Обязательства» и «Денежные средства», как это реализовано в типовых решениях уровня 1С:Управление нашей фирмой (УНФ) или 1С:Управление торговлей.