Автоматизация учета договоров с Заказчиками и соисполнителями в рамках Государственного оборонного заказа

В данной статье мы рассмотрим технологию работы с договорами заказчиков и соисполнителей в рамках Государственного оборонного заказа (ГОЗ) в системе «1С:ERP Управление предприятием 2» (далее по тексту - 1С:ERP). Особый акцент сделаем на том, какие возможности системы 1С:ERP позволяют сразу же реализовать специфичные требования предприятий оборонно-промышленного комплекса, а какие требования ведут к доработке системы.

Накопленный опыт работы на конкретных проектах показал нам, что на предприятиях ВПК не получается запустить бухгалтерский учет без нормальной автоматизации договоров в программе.

Почему не получается? Можно выделить ряд причин:

Как показывает практика, обычно нужная информация хранится в бумажном варианте у ответственных исполнителей в разных подразделениях, что создает трудности для бухгалтерии по ее обработке.

Когда мы запускаем систему, то 2-3 месяца идет только сам сбор первичной информации по открытым договорам и заказам, чтобы занести их в систему. Без этого бухгалтерский учет мы запустить не можем, так как, например, те же затраты мы должны привязывать к заказам.

В процессе реализации проектов нами был накоплен опыт и реализованы доработки, упрощающие работу с контуром учета договоров.

В 1С:ERP существует два справочника: справочник партнеров и справочник контрагентов. Справочник партнеров больше относится к управленческому контуру, для целей регламентированного учета для нас более важен справочник контрагентов. Под контрагентом в системе понимается любое юридическое лицо, с которым предприятие имеет договорные отношения и взаиморасчеты. Клиенты, заказчики, соисполнители, поставщики – все они в системе выступают в качестве контрагентов.

Выглядит карточка контрагента таким образом. Рис.1.

В карточке контрагента есть перечень реквизитов: Наименование контрагента, ИНН, КПП, ОКПО. В ней же указывается – кем данный контрагент является для нашего предприятия: клиентом, поставщиком. При работе с одним контрагентом как с поставщиком и как с заказчиком нужно в одной карточке установить оба статуса. Дальше в рамках этой карточки открывается несколько договоров, в которых разделяются взаиморасчеты с данным контрагентом как с поставщиком и как с клиентом.

Также в карточке контрагента указываются юридический адрес, телефоны и другая контактная информация. Обычно заполнение данной информации отдается в договорный отдел, а используется бухгалтерией при печати счетов-фактур, накладных и т.д. Рис.2

Здесь возникает важный организационный момент – как добиться, чтобы договорный отдел либо ТСО вовремя актуализировал информацию по контрагентам. Это достаточно значимый момент с точки зрения регламентированного учета. При несвоевременном обновлении данной информации формируемые первичные документы будут не соответствовать требованиям законодательства и предприятие столкнется с необходимостью переделывать первичные документы: накладные, счета-фактуры и т.д.

Для удобства пользователей в системе реализован механизм проверки контрагентов, с помощью веб-сервиса ФНС. Рис.3.

Включается данная опция в специальных настройках системы. При использовании опции в момент ввода нового контрагента система связывается по интернету с базой ФНС и в случае наличии ошибок в реквизитах контрагента выдаёт сообщение, что КПП не соответствует, контрагент отсутствует в базе, неверный ИНН и т.д. Рис.4

Помимо возможности проверять контрагента в момент ввода также есть опция проверять уже введенных в систему контрагентов по расписанию, например – раз в неделю. Таким образом можно упростить актуализацию информации о контрагентах.

Например, у контрагента поменялся КПП, при очередном обновлении информации система подсветит данного контрагента в справочнике желтым или красным треугольником, тем самым сигнализируя, что по нему существуют отличия в реквизитах между базой ФНС и данными, введенными в систему. Рис.5

Открыв карточку контрагента можно получить информацию о том, какой реквизит устарел или не соответствует данным в базе ФНС. Рис.6.

При использовании данного сервиса есть нюанс – необходимо подключение к интернету. Для предприятий ОПК данное условие может быть ограничивающим фактором, т.к. обычно сервера таких предприятий не имеют доступа к интернету. В таких случаях мы рекомендуем использовать отдельный компьютер, например в договорном отделе с отдельно информационной базой, подключенной к интернету, которая делает необходимую проверку контрагентов, и настраиваем обмен с основной информационной базой, в которой ведется учет.

Информация по договорам с клиентами и заказчиками хранится в справочнике «Договоры». Рис.7.

В типовой программе 1С:ERP данный справочник является линейным. Т.е. нет возможности учитывать структуру подчинённости договорных документов. Как правило, в работе любого предприятия возникает необходимость заключить дополнительное соглашение к действующему договору и видеть взаиморасчеты, как по договору в целом, так и отдельно по каждому дополнительному соглашению. Для реализации данного требования нами была сделана доработка, позволяющая вести иерархический справочник договоров. Таким образом, у договорного отдела появляется возможность регистрировать как сами договора, так и все дополнительные соглашения к данным договорам, не теряя структуру. На Рис.8 показан пример, в котором есть договор 7112 и три дополнительных соглашения к нему. Договор 7112 выглядит как группа, на самом деле это обычный элемент справочника. По нему вы можете осуществлять платежи, по нему можете осуществлять отгрузку и смотреть взаиморасчеты. Рис. 8

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

Карточка договора с заказчиками представлена на Рис.9.

На форме видно достаточно много полей, выделенных желтым цветом. Данные поля были добавлены нами при доработке системы. Эти поля не накладывают никаких ограничений на действия в системе. Они необходимы для формирования отчетности по договорам.

Первое поле, которое мы добавили – это вид документа. Рис.10.

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

Договор имеет номер и дату заключения; период действия (с какого по какое число он действует); подразделение, которое за него отвечает; основного менеджера, который является ответственным лицом за данный договор. Также в комментарии можно написать информацию о том, что мы планируем по этому договору отгружать. Эта информация выводится в отчет «Реестр договоров». Реестр договоров делают очень многие предприятия. В данном отчете выводится список договоров, кому, что, когда мы должны отгрузить, какие работы выполнить, суммы по данным договора и по этапам.

В карточке договора указывается статус. Статусов по умолчанию в системе два: не согласован и действует. Мы ввели дополнительные статусы. Закрытый, Расторгнут, Приостановлен.

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

Установка статуса договора также достаточно важный момент, когда требуется взаимодействие договорного отдела, бухгалтерии и других подразделений предприятия. Договорной отдел может установить статус «закрыт»  когда подошли сроки окончания действия договора или еще по какой-то причине. А заплатил ему заказчик или не заплатил, договорный отдел не обязан отслеживать. И получается, если договорной отдел закроет договор раньше, чем мы получили оплату по данному договору, и мы не сможем выбрать этот договор в платежном документе. Регламент взаимодействия подразделений в данном вопросе нужно прописывать достаточно четко.

Есть сумма договора, сумма НДС, сумма вне бюджета, если договор каким-то образом финансируется с внебюджетных средств. Дальше указывается информация о военной приемке. Будет ли она осуществляться, номер удостоверения, сумма военной приемки. Все эти реквизиты нужны нам для построения отчетности. Также добавлен реквизит направления договора, в разрезе направлений формируется главный отчетный реестр. Там может быть прямой ГОЗ, косвенный ГОЗ, Договора с Мин.Обороны и т.д.. Это уже специфичный справочник, который наполняется предприятиями индивидуально. Рис.11

Также в системе указываются условия продажи, валюта, в которой фиксируются цены, вид цен. Рис.12

Дополнительно в этом случае указываются варианты оплаты. Они содержат информацию, об условиях реализации – процент предоплаты, процент и срок кредита. Все варианты оплаты, которые на предприятии предусмотрены, в договоре не всегда получится отразить. Для этого есть этапы договора, о чем расскажу далее.

Так как договор – это объект, который используется в работе многих подразделений, пришлось сделать доработку, чтобы ограничить изменение данных, потому что за договор обычно отвечает договорной отдел, но при этом в нем содержится бухгалтерская информация, в частности на каком счете учета этот договор будет учитываться. Рис.13

Данная доработка позволяет ответственным пользователям бухгалтерии вносить ограниченные изменения в карточки договоров, на уровне отдельных реквизитов, например, устанавливать группу финансового учета, что относится к компетенции бухгалтерии. При этом у данных пользователей нет возможности поменять остальные данные в форме договора.  Таким образом, каждое подразделение может работать с одной карточкой договора, имея возможность поменять только те реквизиты, за которые они несут ответственность.

Кроме этого в системе может храниться история изменений, можно посмотреть каждую версию в момент записи: какого числа, кто и что изменил. Выделяются две версии, нажимается кнопка «сравнить» и отчет показывает, какие реквизиты были изменены, кем и когда. Если необходимо, то можно восстановить одним нажатием кнопки предыдущую версию.

К договору можно прикрепить электронные копии документов (скан оригинала договора, скан оригинала акта и т.д.). Обычно данные файлы хранятся на сервере не в информационной базе, на объем и быстродействие самой базы в этом случае это не влияет.

Обычно договора с заказчиками ведутся не в целом, а по этапам либо по спецификациям поставки. Если договор заключается на выполнение работ, то это обычно этапы, а если на поставку однотипной продукции, то обычно договор делится на спецификации. (Рис. 14.)

Для такого разделения на этапы мы используем документ системы «Заказ клиента». Отдельная поставка или отдельный номер этапа – это отдельный заказ клиента. Рис.15

В нем есть код заказа, номер этапа, вид цены. Отдельно стоит сказать, что здесь мы можем уточнить условия оплаты (рис. 16.), указать конкретные суммы, которые мы планируем получить по этому заказу в указанные даты. Данная информация из заказов клиентов в дальнейшем отображается в блоке бюджетирования и БДДС. Также из заказа можно просмотреть все документы, которые по нему в системе отражены. Все, что привязывается к заказу, будет видно (рис. 17.). По этапу можно посмотреть взаиморасчеты, когда и какие отгрузки были, на какие суммы, какие платежи и в какие сроки проходили. (Рис.18)

 

Далее поговорим про поставщиков и соисполнителей.

Договора с поставщиками тоже хранятся списком, список точно так же является иерархическим (рис. 19.), здесь также можно вводить дополнительные соглашения.  Реквизиты у договоров с поставщиками практически те же что и у договоров с клиентами.

Есть одно отличие. У договора с поставщиком можно выбрать контракт-основание, например, договор с заказчиком, указать, под какой контракт вы открываете этот договор с поставщиком. И тогда структуру договоров по кооперации вы можете сформировать в типовом списке, настроив группировку по контракту-основанию, будет видно все открытые договора с поставщиками, по каждому контракту-основанию (рис. 20)

По взаиморасчетам с поставщиками существует типовая ведомость. (Рис.21) В ней наглядно отображаются все взаиморасчеты с поставщиками, зафиксированные в системе, кроме этого справочно отображается сумма договора, указанная в карточке договора.

Есть возможность учитывать в системе закупочные цены, и формировать соответствующие отчеты. По каждой номенклатуре можно вывести цену с расшифровкой до накладной, а также посчитать среднюю стоимость за период. Данная информация, как правило, используется планово–экономическим отделом для расчета плановой калькуляции. (Рис. 22.)

Отчет «Реестр договоров» (рис. 23.).

В системе реализован отчет, который показывает список договоров (как с поставщиками, так и с заказчиками), сроки их выполнения, суммы, этапы их выполнения: плановые и фактические, также показывает финансовые показатели по каждому договору и по группам (Рис.24).

Также есть информация по плану поступления денежных средств по договору и факту, который отражен в бухгалтерском учете (какой датой, кокой платежкой и по какому этапу прошло).

В данной статье мы рассмотрели методологию автоматизации на базе 1С:ERP договорной работы на предприятиях оборонно-промышленного комплекса.

Дополнительные вопросы по теме можно отправлять на почту: info@razdolie.ru.