Финансы: основные реквизиты договоров. ERP на предприятии - шаг 4.1.

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

Охватите автоматизацией ведение в ERP как уже заключенных (подписанных обеими сторонами) договоров, так и проектов договоров.

На этапе отладки модуля к работе лучше привлечь только отделы продаж и закупок. Это позволит:

• выловить и устранить большую часть проблем всех подразделений договородержателей, поскольку через эти службы проходит большое число договоров, содержащих практически все особенности договоров, по которым работает предприятие;
• минимизировать круг конфликтов только тремя службами – ИТ-отделом, отделом продаж и отделом закупок.

Предыдущая статья: Внедряем финансы - справочники. ERP на предприятий - шаг 4.

Для реализации финансового модуля нам достаточно взять из обработки договоров только функции:

• заведение в ERP шапки договоров, разовых счетов, писем или заявок;
• заведение в ERP спецификации договоров: продукция, количество, цена за единицу, ставка НДС, сумма – по каждой позиции спецификации;
• заведение в ERP шапки проекта договора о продаже/закупке;
• заведение в ERP спецификации проекта договора: продукция, количество, цена за единицу, ставка НДС, сумма – по каждой позиции спецификации;
• заведение в ERP шапки дополнительных соглашений к договорам;
• заведение в ERP спецификации дополнительных соглашений к договорам: продукция, количество, цена за единицу, ставка НДС, сумма – по каждой позиции спецификации.

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

Тут главное сразу определиться с терминами.



Термин 1. Проект договора – документ о намерениях заключения сделки по покупке/продаже продукции между несколькими организациями, находящийся в процессе согласования между сторонами предстоящей сделки.

Термин 2. Проект договора, дошедший до стадии обязательного заведения в ERP - Проект договора по которому, на предприятии наступило одно или несколько из следующих событий:

• на расчетный счет предприятия поступили денежные средства от заказчика – аванс или часть аванса;
• для выполнения заказа (когда цикл изготовления изделия больше срока до первой отгрузки по договору) принято решение начать закупку МКИ из собственных средств;
• для выполнения заказа (когда длительность производственного цикла больше срока до первой отгрузки по договору) принято решение о начале производства под проект договора из запасов МКИ и/или НЗП.

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

Термин 3. Разовый счет, заявка, письмо – разовый запрос на поставку/приобретение продукции. К таким запросам можно применить два принципиально разных подхода:

1. Считаем разовый счет, заявку или письмо обычным запросом, в ответ на который высылаем стандартный проект договора для согласования. И дальше процесс идет уже отработанным на предприятии  путём.
2. Считаем разовый счет, заявку или письмо утвержденным договором. Это возможно, если документы содержат все основные реквизиты, присущие договору на поставку/приобретение продукции. В этом случае можно ввести процедуру упрощенного согласования, в котором будет участвовать минимальное число заинтересованных служб предприятия.

В чем собственно разница?

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

• число согласовательных подписей под договором доходит до 12-16 штук;
• суммарное расстояние между подразделениями, которые согласуют договор может доходить до 5-7 км, а то и 20 км. (при наличии удаленных площадок);
• найти 12-16 руководителей, которые должны поставить свои подписи под договором получается не быстрее, чем за 4-15 дней;
• число походов за согласованием может стремиться к бесконечности, поскольку любой из подписантов может дать замечание сколько угодно раз, пока все пункты не будут удовлетворять всех подписантов и ещё другую сторону договора;

а закупить или поставить продукцию нужно срочно, начинаешь ногами и временем ощущать нужность разовых счетов, заявок, писем и упрощенной процедуры согласования.

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

Термин 4. Дополнительное соглашение к договору в ERP – заводится в ERP в случае изменений в дополнительном соглашении относительно основного договора по реквизитам (параметрам) договора, которые заведены в систему.

Например, в систему занесены данные о том, что:

• плательщик по договору и грузополучатель есть одно юридическое лицо с единым фактическим адресом доставки груза. В дополнительном соглашении указано, что столько-то единиц продукции необходимо отгрузить либо другому юридическому лицу, либо по другому фактическому адресу этого же юридического лица;
• количество продукции 1 подлежащее отгрузке в текущем году – 200 единиц, а в дополнительном соглашении – 195 единиц.

Особенностью при заведении дополнительных соглашений в ERP является сам подход к заведению:

• дополнительное соглашение изменяет данные основного договора в ERP и делает новые суммарные изменения в системе единственными активными по данному договору. Информация о наличии дополнительного соглашения, его номере и дате, отмечается в незначащем поле системы;
• дополнительные соглашения заводятся как самостоятельные договора со своими номерами, датами, параметрами и спецификацией, но в системе устанавливается связь с основным договором;
• дополнительное соглашение изменяет данные основного договора в ERP, не являющиеся ключевыми параметрами договора и не меняющие его сути, если же дополнительное соглашение влияет на критичнее параметры договора, то только такое допсоглашение заводится, как самостоятельный договор со связкой с основным.

Термин 5. Нестандартная поставка – заказ продукции, несоответствующей КД, как правило: по комплектности или составу поставляемой продукции.

На практике встречается несколько разных подходов к заведению такой продукции в ERP для исполнения договора:

• инженерные службы разрабатывают варианты исполнения изделия в соответствие с КД и присваивают им другие коды и наименования, на основе кодов и наименований базовых изделий. Этот путь понятен отделу продаж, руководителям всех уровней внутри предприятия, технологам и металлургам, и позволяет избавиться от необходимости доработок в ERP по использованию изделий во всех модулях ERP системы. Однако, он создает и ряд сложностей: дополнительную, достаточно серьезную, нагрузку на конструкторское подразделение по созданию новых модификаций и на конструкторско-технологический блок по  поддержанию их электронной документации в актуальном состоянии для каждой модификации; список таких модификаций неизбежно будет конечным, что означает, что рано или поздно предприятие откажет заказчику в поставке своей продукции, ввиду того, что такую модификацию не производит – хотя технически и могло бы это сделать;
• ИТ подразделение осуществляет доработку ERP системы для создания механизма формирования состава изделия под требования заказчика. Такой подход повышает гибкость предприятия в производстве продукции и лояльность к клиенту, но требует создания (генерации) новых, отдельных кодов и наименований для таких изделий, чтобы отделить их от базовых. Однако и здесь не обходится без сложностей - изделие в новом составе в обязательном порядке должно быть согласовано с: конструкторским отделом на предмет непротиворечивости нового состава возможности изготовления изделия; каждой службой конструкторско-технологического блока для выверки НСИ под новый состав изделия: маршрут, оборудование, технология, контроль, нормы расхода материалов, особенно вспомогательных.

Как и везде ни один подход не является идеальным, однако любой из этих подходов может быть реализован в ERP – выбор, как всегда, за предприятием.

Термин 6. Услуги – поставка/закупка нематериальной продукции или выполнение работ, не порождающих продукции. Говоря очень утрированно – работы, выполненные исполнителем для заказчика, которые невозможно передать по накладной и оприходовать для осуществления количественного учета.

И предприятие оказывает услуги, и предприятию услуги оказываются регулярно, поэтому в ERP услуги должны заводиться в договора наряду (даже в рамках одной спецификации) с основной продукцией.

В PLM услуги не ведутся, поскольку в конструкторском составе изделия отсутствует единица состава - услуга. Это означает, что для применения услуги при обработке договора в ERP необходимо использовать функциональность самой ERP.

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

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

Продукция, получаемая из PLM с конструкторским обозначением, при сохранении в ERP неизбежно получает какой-то код – ERP работает с изделиями по кодам, для обеспечения связи с другими элементами ERP, с которыми изделие должно быть связано функциями или процессно.
Код изделия, чаще всего, является значащим – содержащим набор цифр, букв и специальных символов, каждый из которых или их последовательность несут в себе обозначение из каких либо справочников или ГОСТов, а их местоположение в наборе кода изделия – является обязательным и неизменным.

Такой подход позволяет делать коды:

• «говорящими»;
• легко запоминаемыми специалистами предприятия, для которых справочники и ГОСТы, элементы которых зашифрованы в кодах изделий являются понятной и постоянной частью их основной работы;
• идеальным инструментом разделения однородных предметов и понятий на группы, классы, категории, линейки, направления и т.д.

Достаточно изменить в коде всего один символ, обозначающий, например – «продаваемая продукция» на «продаваемая услуга» и это будет уже совсем другое изделие. В будущем такое отличие позволить вести обработку услуг и при выставлении документов (на услуги нет ТОРГ-12 или М-15, а есть АКТ) и при планировании (услуги не планируются к производству и сдаче на склад, хотя иногда и требуют материалов, инструмента и оснастки).

Услуга, как правило, не имеет КД, она может иметь описание в договоре или ТЗ на исполнение, но в любом случае, в договоре, разовом счет, письме или заявке она присутствует с реквизитами:

• наименование услуги;
• цена услуги;
• ставка НДС;
• стоимость услуги.

Отсутствие количества в описании услуг в ERP заменяется значением - 1 (один). Это не только правильно вписывается в логику ERP, но и выглядит в ERP, и звучит вполне понятно «оказывается одна услуга», «предоставляется одна услуга».



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

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

Результат подпункта.

Отдел продаж заводит в ERP договора и проекты договоров.
Отдел закупок заводит в ERP договора, разовые счета, письма, заявки и проекты договоров.
Подразделения договородержатели, ответственные за продажу продукции и услуг по своим направлениям заводят в ERP договора и проекты договоров.
Подразделения договородержатели, ответственные за покупку продукции и услуг по своим направлениям заводят в ERP договора, разовые счета, письма, заявки и проекты договоров.
Отдел финансов видит в ERP все договора, имеющие в ERP статус утвержденных.
Отдел финансов видит в ERP спецификации ко всем договорам со статусом в ERP - "утвержден".

Следующая статья: Поступление денежных средств. ERP на предприятий - шаг 4.2.

Автор: Андрей Лабутин