Оплачиваем закупку. Логика закупок при внедрении ERP на предприятии - шаг 5.1

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

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

Предыдущая статья: Логика закупок - начало. Внедрение ERP на предприятий - шаг 5.

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

График оплаты заказов на закупку.

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

Дальнейшая работа службы финансов сводится к стыковке остатков на счетах предприятия с суммами оплат по графику. Отчет по остаткам на счетах предприятия мы уже разработали в ERP в материале «Учет расходов денежных средств. ERP на предприятий - шаг 4.3.», однако этот отчет для данной задачи нам не очень подойдёт.

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

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

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

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

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

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

ВАЖНО. Пассивная реакция системы вынуждает пользователя обратить внимание на отклонение, но не осуществляет каких-либо действий по устранению отклонения без участия человека. Применяется при возможности установления признака отклонения от какого-либо заданного и/или контролируемого параметра.

ВАЖНО. Активная реакция системы позволяет устранить возникшие отклонения при расчетах без участия человека, полностью в автоматическом режиме. Не должна использоваться без пассивной реакции системы, выраженной в обозначении исправленных системой значений любым доступным для демонстрации пользователю системы способом. Применяется при возможности идентификации и использования  признака устранения отклонения без создания отклонения-следствия.

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

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

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

1. Приостановить (вернуть) заказ на закупку, для переноса подразделением договородержателем закупки данных позиций на более поздний срок. Может быть осуществлено только по согласованию с подразделением договородержателем.
2. Перенести оплату заказа на закупку на более поздний срок самостоятельно. Вариант реализуем в условиях, когда финансовой службе предприятия в день переноса известна будущая дата и сумма поступления денежных средств на предприятие на выделенные для оплаты закупок расчетные счета организации.
3. Разрешить исполнение заказа на закупку без оплаты. Данный вариант осуществляется после согласования с предприятием поставщиком и будет рассмотрен в данной статье в разделе «осознанная кредиторка» чуть ниже.

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

Интерфейсных вариантов решения задачи переноса срока оплаты по заказу на закупку непосредственно сотрудниками финансовой службы предприятия довольно много, начиная от правки срока оплаты непосредственно в заказе на оплату и заканчивая операцией drag & drop прямо в графике оплат. Какой вариант реализации выберите Вы, не принципиально. Важным является одно универсальное правило – разделение полномочий через правила авторизации.

ВАЖНО. Прозрачную, понятную и пользователям, и программистам реализацию принципа разделения полномочий по управлению данными в одном сеансе или роли, в ERP может обеспечить ввод понятия «состояний процесса». Каждому состоянию процесса соответствует своё состояние доступа к данным и полям сеансов этого процесса для каждой отдельной роли в системе.

Отвлечение. Состояние процесса

Звучит это довольно сложно, поэтому я поясню непосредственно на примере заказа на закупку:

• заказ на закупку создан менеджером – состояние процесса «проект». Заказ на закупку в этом состоянии доступен на изменение только менеджеру на закупку, который его создал и его непосредственному руководителю;
• заказ на закупку подтвержден менеджером – состояние процесса «активен». Заказ на закупку в этом состоянии доступен на чтение и изменение статуса заказа на закупку только менеджеру на закупку, который его создал и его непосредственному руководителю;
• заказ на закупку подтвержден непосредственным руководителем менеджера – состояние процесса «согласован». Заказ на закупку в этом состоянии доступен на чтение менеджеру на закупку владельцу заказа, его непосредственному руководителю и руководителю службы этих специалистов. По этому же статусу заказ на закупку доступен для изменения статуса заказа и даты заказа – непосредственному руководителю менеджера и руководителю этой заказывающей службы;
• заказ на закупку подтверждает руководитель заказывающей службы – статус заказа «на оплату». Заказ на закупку в этом состоянии доступен на чтение всем лицам, участвовавшим в его электронном изменении статусов и сотрудникам финансовой службы предприятия. По этому же статусу заказ на закупку доступен для изменения статуса заказа и даты заказа – руководителю заказывающей службы и специалистам финансовой службы предприятия;
• сотрудник финансовой службы самостоятельно перенес срок оплаты заказа – статус заказа остался прежним «на оплату». Доступы к заказу соответствуют доступам к заказу со статусом «на оплату»;
• позже, всё таки было принято решение о переносе срока заказа на ещё более поздний, неопределенный срок, при этом, один из пользователей, имеющих право изменения статуса заказа на оплату, находящегося в состоянии процесса «на оплату»
• приостанавливает заказ – состояние процесса «согласован». Доступы к заказу соответствуют доступам к заказу со статусом «согласован», а следовательно,  сотрудники финансовой службы больше не могут изменить заказ, не видят его и он перестал присутствовать в графике оплаты заказов на закупку.

ВАЖНО. В процессах, имеющих обратные организационные петли (откат принятого решения, возврат в исходное состояние и т.д.) для нового состояния после петли, лучше использовать состояние процесса в ERP, которое он имел бы, если бы оказался в этой организационной точке процесса сразу, при его прямом прохождении (см. выше «согласован» - «на оплату» - «согласован»).

ВАЖНО. Присвоение статусов процессам позволяет ввести в ERP электронное согласование любого документа или процесса, автоматически подтвержденное уникальным логином, ФИО, именем машины, датой и временем изменения статуса.

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

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

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

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

Осознанная кредиторка.

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

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

Уход в такое решение для самого предприятия заказчика я называю «осознанной кредиторкой», поскольку уходит в неё предприятие, учитывая совокупность следующих факторов:

• возможность привлечения для оплаты закупки денежных средств из резервов – наличие у компании денежных средств, достаточных для оплаты заказа на закупку;
• риски от не своевременной поставки закупаемой номенклатуры – что будет, если, скажем МКИ, придут на 1-3 месяца позже;
• наличие и объем кредиторской задолженности по этому поставщику – у предприятия с одним поставщиком может быть не один, а целая группа договоров или один рамочный договор на огромную гамму номенклатуры, и предприятие заказчик вполне может оказаться в ситуации, когда на момент рассмотрения вопроса об уходе в «осознанную кредиторку», по данному заказу у него уже есть какая-то кредиторская задолженность перед поставщиком;
• наличие и объем дебиторской задолженности по этому поставщику.

Если по совокупности факторов, принимается решение о:

• переводе заказа в осознанную кредиторку, то финансовая служба предприятия должна иметь возможность в ERP перевести заказ на оплату в статус «отложенная оплата»;
• оплате, то финансовая служба предприятия должна иметь возможность в ERP перевести заказ на оплату в статус «в банк».

Оба состояния процесса «отложенная оплата» и «в банк» могут запустить процесс уведомления службе инициировавшей закупку о том, что поставщик может начинать изготовление заказанной продукции.

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

В ERP дополним условия формирования графика оплаты по заказам на закупку:

• показывать все заказы на закупку со статусом «на оплату»;
• показывать все заказы на закупку со статусом «отложенная оплата» и выделить цветом;
• на каждый день показывать общую сумму к оплате по заказам и в том числе, сумму заказов на оплату, сумму отложенной оплаты;
• от остатков на расчетных счетах вычитать общую сумму к оплате за день по заказам с обоими статусами, при отрицательной сумме выделять цветом и её, и сумму остатков на расчетных счетах.

Оплата.

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

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

Статья будет иметь продолжение…

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