Существует такой отчет как «Ведомость по взаиморасчетам с контрагентами». Это универсальный отчет и позволяет в различной развертке по группировкам показывать данные. В нем видны и начальное сальдо, обороты по приходу и расходу, сальдо конечное. Но вот в процессе работы этот отчет оказался не удобен для текущего контроля состояния взаиморасчетов с условием планирования платежей. Возможно, конечно можно было бы и его доработать под те условия, которые требовались заказчику. Только вот в результате того, что у нас получилось, этого сделать на универсальном не представлялось как. Ничего плохого в универсальном отчете по взаиморасчетам нет. Он однозначно нужен как отдельный инструмент, дополняющий общую систему контроля взаиморасчетов.
Альтернативный подход
Ранее у нас был уже сделан другой собственный отчет «Отчет по контрагентам». В нем присутствует развертка четко зафиксированная. С учетом иерархии показываются группировка по контрагентам, и уже дальше по каждому контрагенту идет расшифровка по документам. Потребовалось внедрить на предприятии оперативный учет по контроль оплаты по каждому документу, то есть по документам расчетов. Требовалось видеть, какие накладные являются не оплаченными, какие уже оплачены, и какие документы стоят в плане (!) для оплаты. При этом сделать так, чтобы это было достаточно легко делать и контролировать.
У нас в базе указаны параметры ведения учета в договорах по документам взаиморасчетов. Поэтому у нас осуществляется контроль за оплатами каждого документа. Выделение цветом таких документов довольно таки сразу помогают ориентироваться в этом процессе. Поэтому мы первым делом это реализовали в самом отчете, то есть выделили цветом оплаченные полностью документы и сами документы оплаты. При этом в отчет также добавили возможность скрывать, то есть не показывать документы, по которым нет остатка по взаиморасчетам.
В универсальном отчете «Ведомость по взаиморасчетам» скрыть документы текущего периода без задолженности не удалось. Если только кординально его не переписать. Конечно, можно постараться и исхитриться сделать в нем, но как оказалось простые пользователи хотят видеть четко зафиксированную форму отчета, чтобы она гарантировала, что останется неизменной и максимально понятной. Универсальный же отчет можно крутить и формировать по-разному. Кто это умеет делать, тот это делает быстро, а кто не умеет, у него вызывает трудности и в результате отторжение отчета. Как не странно, но прислушавшись к таким пользователям понимаешь, что они имеют ввиду.
В нашем отчете видна расшифровка в полном виде. Видно дату и номер документа в отдельных колонках, вид документа, номер и дата входящего документа. Очень интересной является колонка (доп.информация). В ней находится не только комментарий из документа регистратора, но и зависящая от вида документа информация. Допустим, из платежки видно назначение платежа, из расходного кассового ордера (РКО) и приходного кассового ордера (ПКО) основание платежа. Получается, что в этой колонке собирается информация любая по расшифровке операции — все это настраивается в модуле отчета программистом.
Также отчет можно вывести и без группировки по договорам. Скажите, что в универсальном отчете все тоже можно сделать и вывести практически один в один. Да, согласны. Мы тоже предложили первым данный вариант. И настроили. Но никак не смогли убедить заказчика работать с ним. Было очень не удобно. Да и, если что-то случится и сбросятся настройки пользователя, то настраивать каждый раз не сильно приятно. Конечно, есть может умельцы, которые сделают на СКД и будет выглядеть именно также. Не вопрос. Мы здесь рассматриваем вариант, как можно сделать и почему именно так удобней для пользователя, а не удобство с точки зрения программирования. Поверьте — пользователям абсолютно все равно с помощью чего написан отчет. Его интересует как можно быстрее получить понятный для работы результат требуемой информации и дальнейшая его обработка.
Распределение оплат по-документно
«Не все то прибыль, что попало в кошелек»
Лоренс Стерн
Работа по указанию, каким платежным поручением производить оплату, по какой накладной осуществляется не этим отчетом. Отчет только показывает результат работы. Само распределение происходит в документе Платежное поручение исходящее. В нем по операции «Оплата поставщику» в режиме работы в списке можно произвести платеж по оставшимся остаткам по взаиморасчетам. По кнопке «Заполнить» заполняется табличная часть документа всеми данными по остаткам взаиморасчетов. При этом не стандартной обработкой, которая также не устроила, а дорабатывалсь сама форма документа. В ней видны и дата документ расчетов, сам документ расчетов, входящий номер, счет-фактуру, сумму по документу расчетов, сумму остатка оплаты по этому документу, дней отсрочки из договора, срок оплаты, указанный в документе расчета (поступление товара). Остается проставить сумму оплаты по строке, которую хотим оплатить. Для этого существует кнопка «Оплатить», по которой автоматически проставляется сумма из колонки «К оплате» в колонку «Сумма оплаты».
По галочке «Распределять» устанавливается режим распределять, указанную в шапке платежки суммы. Т.е. это режим когда платеж уже произведен и следует распределить сумму по документам расчетов. Без этой галочки сумма в шапке будет изменяться по мере указания сумм к оплате в табличной части. Плюс после указания суммы оплаты внизу формируется «Список счет-фактур» к оплате. Это значение можно скопировать после окончания заполнения списка оплаты в назначение платежа. Это облегчает формирование текста назначения платежа.
Способ планирования платежей
Внизу в документе рядом с кнопкой «ОК» существуют две кнопки «К оплате» и « В план». Если нажать на кнопку «В план», то документ будет сохранен в списке с признаком, что платежка поставлена в план платежа. Префикс у документа будет «АВ». Другими словами эта платежка формируется как бы заранее и, когда производится работа по принятию платежей к оплате, эти платежки видны в реестре сразу. Мы как бы заранее набиваем платежное поручение и делаем отсрочку в его исполнеии. Тем самым такие платежи контролируются в одном журнале документов. К тому же они еще и выводятся в отчете нашем. Другими словами мы избежали ведения отдельного журнала документов по плановым платежам. Плановый платеж при переходе в статус «К оплате» превращался в сам документ оплаты.
В типовых решениях такое действие не предусмотрено. В них существует отдельный документ «Заявка на расход денежных средств». Он формирует данные по плановым платежам и в таких конфигурациях программа сравнивает плановые платежи с фактическими оплатами. На основании этой заявки вводится платежное поручение по наступлению срока оплаты. Мы не говорим, что это не правильно. Это, несомненно более верное решение даже с точки зрения логики. Нами рассматривается вариант, когда предприятию не нужно сравнивать данные по плановым платежам с фактом. По-сути многие предприятия не используют систему заявка на расход денежных средств. Это может быть по причине того, что в их конфигурации этого нет, а может и просто понимают, что это усложнит работу, и им легче это вести где-то в или вообще не вести. Им важно, так сказать,не пропустить срок оплаты и видеть в плане данные оплаты.
Конечно, если плановыми платежами занимается другой отдел в корпоративной структуре предприятия и действительно требуется данное сравнение, то такой способ не для них однозначно. А вот для маленьких предприятий, когда платежи разносит один бухгалтер (чаще главный бухгалтер), то ему достаточно будет этого способа. Немного подправив работу с платежными поручениями.
Контроль задолженности
Конечно мы не придумывали ничего нового, многие заранее подготавливают платежные поручения и оставляют их не проведенными, чтобы потом при наступлении срока воспользоваться ими — провести. Но мы их сразу стали проводить. Когда формируется отчет «Отчет по контрагентам» такие платежки выделяются зеленым цветом и при планировании оплат это стало наглядно видно. В этом отчете можно открыть данную платежку и откорректировать плановую дату оплаты или поставить статус «к оплате». Собственно это на наш взгляд удобно и проще в использовании. Платежка формируется уже заранее с правильными реквизитами и суммами по срокам оплаты, тем самым облегчая работу на будущее.
Допустим мы, по условиям договора, должны сделать платежи по трем датам, мы создаем три платежки с этими плановыми данными и все заполняем правильно заранее. Когда наступает дата оплаты, мы эти платежки видим в реестре. Заходим в документ и нажимаем внизу кнопку «К оплате». Здесь же дополнительно можно проверить правильность реквизитов. После этого номер документа с префиксом «АВ» меняется на тот, по которому положено вестись нумерации, зависящей от префикса информационной базы и префикса организации. Номер становится следующим номером, как и положено. Получается, что планирование оплаты осуществляется через сам документ оплаты. Даже платежный календарь может учитывать такие платежи как плановые (немного изменив код отчета и если его нет, то сделать свой отчет). Отчет «Ведомость по взаиморасчетам» такие документы не покажет, т.к. он показывает только оплаченные платежки. А вот в нашем отчете мы сразу видим и фактические платежи и плановые. Нет необходимости сравнивать план с фактом, так как план плавно переходит в режим факта. И это исключает двойной работы. А именно это было важно.
Такую систему можно еще расширить и внедрить еще систему по утверждению платежей. И мы получим практически такую же систему планирования платежей, как это сделано в заявках на расход денежных средств.
Не стоит критиковать сильно такой способ. Это всего лишь способ максимально упростить планирования платежей и работает на двух предприятиях у нас. Не для всех подойдет. Используется для взаиморасчетов с контрагентами по документам расчетов. Прочие платежи не контролируются, они вносятся по большей части по факту расхода. А вот важные платежи по контролю условия договоров действуют через этот способ.
Вывод
Чем меньше действий в информационной базе мы делаем, тем меньше трудозатрат. Контроль платежей по взаиморасчетам с контрагентами достаточно трудоемкий процесс. Нам очень хотелось найти способ избежать ведения плановых данных, их сравнения с фактом, но все же получить систему планирования платежей. Мы этого добились.