автор статьи: Фёдор Езеев
опубликовано: апрель 2003
Необходимое примечание:
Идея названия "ГоризонтУчетаКредитов"
возникла после прочтения ветки
Трёхвалютный
учёт на 1С.
Чего хочется (оглянемся на предметную область).
В современной российской торговой организации в большинстве случаев отгрузки осуществляются по предоплате.
При этом существует ограниченное количество постоянных клиентов, которым возможна отгрузка в кредит. Часто с такими клиентами заключены соответствующие договора поставки, в которых оговорены четкие лимиты задолженности, а так же сроки и порядок ее погашения.
Всем же остальным клиентам может быть осуществлена разовая отгрузка товара без реального поступления денег на расчетный счет, однако только в том случае, если есть гарантия такого поступления. Гарантией чаще всего выступает копия платежки и/или гарантийное письмо.
Вдобавок, нужно уметь различать проведение расходной накладной в реальном времени от перепроведения ее через пару месяцев в целях корректного составления квартальной отчетности. Очевидно, что в первом случае проверка "кредитоспособности" клиента необходима, тогда как во втором случае она является не только излишней, но и вредной. Ибо для массового перепроведения документов каждый раз приходится отключать режим контроля за задолженностью клиентов, а после (что весьма критично) перепроведения не забывать включать его обратно.
Что есть (посмотрим на типовые конфигурации).
Возможность учета крупных, "договорных" клиентов реализована полностью и даже с некоторым избытком. В старых типовых (8.х ТиС, 3.х КК) мы можем открывать и регулировать одну кредитную линию каждому покупателю с помощью периодических реквизитов "СуммаКредита" и "ГлубинаКредита" справочника "Контрагенты". В новых (9.х ТиС, 4.х КК) таких кредитных линий каждому покупателю можно открывать неограниченное количество, так как соответствующие реквизиты перекочевали в справочник "Договора", подчиненный справочнику "Контрагенты".
Почему этого недостаточно?
Возьмем для простоты "старую" типовую – третью редакцию комплексной. Что делает пользователь, чтобы корректно отпустить накладную по которой денег еще нет, а копия платежки с исполнением уже предоставлена? Он находит в списке контрагентов покупателя, и устанавливает нужное значение реквизита "СуммаКредита" на дату расходной накладной. Все, накладная проведена, через пару дней приходят деньги, все довольны и обо всем забыли.
Но через месяц приходит этот же клиент и просит отгрузить ему товар по другой накладной, на сумму, меньшую, чем была в предыдущей. Денег нет. Однако накладная проводится!
Ошибка очевидна – после прихода денег нужно было зайти в историю реквизита "СуммаКредита" еще раз, и установить там нулевое значение на дату прихода денег. Однако считать это ошибкой пользователя было бы не до конца корректно, ибо перед нами классический пример мартышкиного труда, избавление от которого и является основной целью автоматизации учета.
Таким образом, мы видим, что нынешняя реализация учета взаиморасчетов с контрагентами не только неполна, но еще и провоцирует пользователя на создание ошибок в учете.
Как реализовать недостающее.
Для учета "одноразовых" кредитов, очевидно, отлично подойдет реквизит в шапке расходной накладной "ОтпускатьВКредит". При наличии этой галочки при проведении накладной вообще не проверяются никакие взаиморасчеты с клиентом, поскольку предполагается, что накладная уже оплачена, просто деньги до нас еще не дошли. Очевидно, что доступ к этой галочке должен быть только у ответственных товарищей (бухгалтерия, дирекция).
Для того чтобы различать оперативное проведение и проведение "сильно задним числом" в административных целях, имеет смысл ввести понятие "Горизонт учета кредитов". Это дата, значение которой хранится в соответствующей константе. При проведении документа с датой, позднее горизонта, производится учет кредитов покупателя. Если документ записан датой, раньше горизонта, при его проведении такой проверки не производится.
Вдобавок, такая схема позволяет немного ускорить процесс массового перепроведения
документов (админы гигабайтных баз меня поймут).
Начать дискуссию