Целью данной статьи является демонстрация возможностей настройки конфигурации Управление Нашей Фирмой (УНФ) для отражения в ней операций факторинга наиболее простыми средствами, как в пользовательском режиме, так и с помощью расширения.
1. Что такое факторинг
Приведу классическую схему факторинговых операций, заключающихся в переуступке долга покупателя, возникающего при отгрузке ему материальных ценностей (товаров, работ или услуг) компании-фактору. Фактор – финансовая организация - оплачивает большую часть задолженности, как правило 80-90 % от суммы документа реализации, в зависимости от условий договора факторинга, сразу по получении указанного в договоре факторинга комплекта документов. Оставшуюся часть денег фактор перечисляет после поступления к нему оплаты от покупателя, отнимая от неё часть суммы в качестве своего вознаграждения. Таким образом, договор факторинга трёхсторонний – наша организация отпускает товар покупателю, получает деньги от фактора и отслеживает оплату покупателем суммы накладной фактору, получая после этого оставшуюся сумму.
В мировой практике существует несколько видов факторинга. В нашей стране работает только его регрессный вид, при котором, в случае невыполнения покупателем своих обязательств, фактор не берёт на себя функции коллектора, что имеет место при безрегрессном факторинге, организованном по принципу «продал (задолженность) и забыл». У нас риски выше, поэтому, в случае, если фактор не получит оплату от покупателя, он обратится с требованием о возврате уже выплаченной части к нам. Частично риски снижаются проверкой клиентов при заключении самого договора факторинга, частично они заложены в ставку в договоре между нами и фактором. Финансируются, как правило, только наиболее благонадёжные клиенты. Тем не менее, при задержке с оплатой, в течении некоторого времени фактор будет пытаться истребовать задолженность с покупателя. И эти попытки будет оплачивать продавец, так как процент за пользование деньгами в договорах факторинга обычно растёт вместе с увеличением срока оплаты.
Факторинг также разделяется на открытый (покупатель уведомляется о переуступке долговых обязательств и изменении реквизитов для оплаты задолженности) и закрытый (факторинговая компания распоряжается средствами, поступающими на ваш расчётный счёт). Последний вариант, как правило, не устраивает продавца, поэтому закончу с описательной частью и перейду к реализации открытой схемы факторинга, как наиболее часто встречающуюся в реальной практике.
2. Факторинг в УНФ
Стандартным образом ни одна из схем факторинга в конфигурации УНФ не реализована. Как, впрочем, и в других, даже более дорогих продуктах 1С. Однако, возможности программы позволяют настроить её так, чтобы у пользователя была возможность учитывать эти операции. Более того, вариантов ведения учёта факторинговых операций может быть несколько и они реализуются по-разному. Я нашёл три способа реализации факторинга, которые можно осуществить только с помощью настроек. По всей видимости, пытливые умы, обладающие свободным временем, могут найти и другие подходы, благо УНФ - весьма гибкая конфигурация. В рамках этой статьи рассмотрим один из них и реализуем его настройками и программно. Если тема интересна, то прошу писать об этом и я опишу другие способы также в другой статье.
3. Представление факторинга
Схему факторинга для реализации в УНФ представляю следующим образом:
Покупателю отгружен товар по накладной на общую сумму– С0. При отражении факторинговых она разбивается на три составляющих: С1<С0 – первая «быстрая» часть платежа, С2<С1 – вторая «фактическая» часть платежа и С3<С2 – комиссия фактора.
После отправки уведомления о возникшем долге покупателя фактору тот финансирует часть задолженности на сумму С1. При поступлении платежа от покупателя на сумму С0 фактор оплачивает сумму С2, удерживая сумму С3 на своём счету.
4. Реализация настройками
При работе с УНФ нужно учитывать, что операции по кредитованию в ней не пересекаются с товарно-денежными операциями с контрагентами. Это следствие исторически сложившейся ситуации – в первых версиях программы, когда ещё она называлась Управление Небольшой Фирмой, кредитные операции не были предусмотрены. Введя это понятие позже, разработчики выделили его в отдельный поток данных, чтобы сохранить преемственность с предыдущими версиями конфигурации. В связи с этим в тех местах, где требуется переход от одного типа операций к другим, возникает дублирование информации, которое неизбежно приводит к её искажению в отчётах.
4.1. Описание примера
Для примера возьмём простейшую схему – получаем товар (Товар 1) по приходной накладной от контрагента-поставщика Поставщик 1 по цене (и на сумму) 50 000 руб и продаём его контрагенту-покупателю (Покупатель 1) по цене 70 000 руб. Фактор – контрагент Фактор - финансирует задолженность в размере 90 %. Для удобства будем использовать краткосрочную задолженность – в пределах одного месяца.
Первая операция отражается обычной расходной накладной. После её проведения покупатель становится должным нам сумму С0. Документом Корректировка долга переводим долг с Покупателя1 на Фактора.
4.2. Особенность схемы
Создадим, для реализации схемы, кредитный договор с фактором:
Несмотря на то, что контрагент Фактор указан в качестве банка, выдающего кредит, в УНФ это лишь справочная информация, которая не помогает в дальнейшем. И это представляет собой проблему, которую нужно решить.
Поступление средств от фактора – С1 – оформляем выдачей кредита по кредитному договору, т.е. документом «Поступление на счет» с видом операции «Получение кредита»:
Всё видит программа, что стал должен нам Фактор (после проведения Корректировки долга) и сумму видит, но не хочет связывать кредит с долгом. Это приводит, к сожалению, к необходимости вводить дополнительные документы, уменьшающие долг фактора, так как в этой схеме мы действуем в двух плоскостях – товарно-денежной (по Марксу) и кредитной (по Кейнсу).
До ввода корректирующих документов, отчёт Взаиморасчёты показывает, что долг фактора не меняется после проведения кредитных операций:
Здесь возникает выбор – можно списать долг фактора-покупателя документом «Корректировка долга» с видом операции «Корректировка долга покупателя» или поступлением от фактора дополнительных услуг – кому как удобнее будет видеть эту операцию в отчётах. Причём одним документом на всю сумму накладной С0. А деньгами нельзя, так как через счёт они физически не проходят. Взамен этих неудобств мы получаем возможность автоматического начисления процентов и учёта того факта, что получаемые деньги – кредит.
4.3. Завершение схемы и её отражение в УНФ
Фактор получает оплату от Покупателя, отправляет нам сумму С2, которая регистрируется точно таким же образом, что и С1, по факту поступления на счёт.
Остаётся разобраться с комиссией фактора - С3. Поскольку у нас теперь две плоскости, комиссия возникает автоматически в плоскости кредитных отношений на основании данных кредитного договора при вводе документа «Начисления по кредитам и займам».
За удобства приходится платить и в отчётах возникает дисбаланс. Во-первых, мы только получаем кредиты, а отдать их возможности нет, потому что в УНФ это можно сделать только при оформлении документа «Расход со счёта», что невозможно, так как физически долг отдаётся в другой плоскости. К тому же, в отчёте «Доходы и расходы» списываемый фактору долг в товарно-денежной плоскости программа автоматически относит на расходы, что логично. Посмотрим, что у нас получается в отчётах, введя две накладных:
Доходы и расходы:
Ситуация явно искажена. Чтобы отчёт был достоверным, как в предыдущем месяце, можно поступить следующим образом: в документе «Начисления по кредитам и займам» списать сумму задолженности по кредиту С0, отнеся её на комиссию с отрицательным знаком:
Теперь отчёт «Доходы и расходы» показывает нужную картину:
Отчёт «Взаиморасчёты»:
Отчёт «Оборотно-сальдовая ведомость»:
И, наконец, отчёт «Кредиты (полученные)»:
Данная схема достаточно точно отражает операции во времени, но требует ввода дополнительных документов.
5. Программная реализация схемы факторинга
Для программной реализации, исправляющей недостаток отсутствия связи между плоскостями, выбран способ разработки через расширение конфигурации. Идея проста – обрабатывается процедура проведения документа «Поступление на счёт», в которой добавляются требуемые движения по регистрам. Для работы данного расширения в УНФ потребуется в пользовательском режиме создать 2 дополнительных реквизита типа булево у договоров контрагента-фактора с наименованием «Факторинг».
Без этого расширение не будет знать о том, что нужно включиться в работу.
Для интерактивного взаимодействия с пользователем расширение отображает элемент формы документа в случае, если в договорах фактора присутствуют признаки факторинга.
Соответственно, при изменении типа операции, контрагента или договора срабатывает проверка условий факторинга. Это вся интерактивная часть расширения, срабатывающая в форме документа.
Функциональная часть связана с процедурой «ОбработкаПроведения» модуля объекта документа «ПоступлениеНаСчет». Идея в том, чтобы создать дополнительные движения по регистрам расчётов после отработки процедуры модуля основной конфигурации при наличии признака факторинга. Движения создаются по всем регистрам расчетов с контрагентами, в зависимости от признаков отношений («Покупатель», «Поставщик», «Прочие отношения»), установленных для контрагента, выбранного в качестве фактора. В данном примере – «Покупатель» и «Прочие отношения».
В результате УНФ корректно отражает взаиморасчёты с контрагентами, позволяя деньгам, полученным по кредитным договорам от фактора, учитываться с расчётом процентов. Все остальные движения по регистрам накопления выполняются самой УНФ.
Расчёты по договорам кредита с признаком «Факторинг» ведутся только справочно. Есть возможность автоматического расчёта процентов, но нет возможности их закрытия, так как понадобился бы документ из раздела «Деньги» или движения по регистрам, что, в любом случае, исказило бы картину происходящего больше, чем их отсутствие. Расширение тестировалось на конфигурации Управление нашей фирмой, редакция 1.6 (1.6.13.54).
6. Заключение
Таким образом, конфигурация УНФ, при соответствующих настройках, позволяет достаточно корректно отражать даже такие схемы расчёта, которые не заложены в неё создателями, и оставляет простор для доработок, как на пользовательском уровне, так и на уровне разработчиков.
PS По просьбам пользователей добавлена версия для конфигурации УНФ 1.6.18.88
