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