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

В 2009 году в бюджет Санкт-Петербурга поступило более 5 млрд. руб. транспортного налога, что на 1 млрд. руб. больше, чем в 2008-м. Из общей суммы около 4 млрд. руб. составили поступления от уплаты налога физическими лицами. Значительную роль в увеличении поступлений налога сыграла работа, проводимая налоговыми органами Санкт-Петербурга. Законода­тельством Санкт-Петербурга установлено, что транспортный налог уплачивается ежегодно не позднее 1 июня. В связи с этим уже в начале апреля налогоплатель­щики начали получать уведомления о необходимости уплаты налога владельцами транспортных средств, рассылаемые Центром обработки данных (Межрайонная инспекция ФНС России № 6 по Санкт-Петербургу).

Методы информирования налогоплательщиков

Еще до наступления сроков уплаты налогов проводится широкая рекламная кам­пания. Так, в 2009 году о сроках уплаты транспортного налога и необходимости исполнить налоговые обязательства владельцам транспортных средств на улицах города напоминала реклама, размещенная на 254 конструкциях, а также в метро­политене. Кроме того, информация транслировалась на радиостанциях «Дорож­ное радио» и «Авторадио», а также в крупных гипермаркетах города. В торговых точках были вывешены плакаты по данной тематике. Помощь в распространении социальной рекламы Управлению ФНС России по Санкт-Петербургу (далее — Управление) постоянно оказывает администрация города.

Одновременно Управление разместило информацию на своем сайте и в ре­гиональных и местных печатных изданиях.

На сайте Управления создан баннер «Транспортный налог» со ссылкой на ру­брику «Вопрос — ответ», чтобы налогоплательщики могли задать вопросы и в те­чение двух недель получить ответы.

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

Работа с налогоплательщиками, имеющими задолженность

Несмотря на проведенную в 2009 году рекламную кампанию, общая сумма за­долженности физических лиц — владельцев транспортных средств составила более 3 млрд. руб. Для снижения задолженности главам районных администра­ций, в администрацию Санкт-Петербурга, руководителям Главного управления внутренних дел Санкт-Петербурга и Ленинградской области, Управления ГАИ ГУВД по г. Санкт-Петербургу и Ленинградской области, Управления Федеральной антимонопольной службы города и др. были направлены списки сотрудников, имеющих задолженность по уплате транспортного налога от 100 руб. В течение месяца такие должники перечислили в бюджет региона более 4,4 млн. руб.

Одна из мер по принудительному взысканию долгов, применявшихся в 2009 году, — совместные мероприятия представителей налоговых органов и со­трудников дорожно-патрульной службы Управления ГАИ ГУВД по г. Санкт-Петер­бургу и Ленинградской области, проводимые на дорогах города, на станциях тех­нического обслуживания автомобилей с целью выявления должников по уплате транспортного налога. В ходе данных мероприятий сотрудники налоговых орга­нов вручали неплательщикам квитанции на уплату налога и пеней. Совместные мероприятия освещались региональными и общероссийскими телекомпаниями. На сайте Управления размещались фоторепортажи с места событий.

По данным Управления ГАИ ГУВД по г. Санкт-Петербургу и Ленинградской области, в Северной столице зарегистрировано около 1,6 млн. транспортных средств, собственниками которых являются примерно 1 млн. граждан, однако не все они добросовестно и своевременно уплачивают транспортный налог

Кроме того, налоговые органы совместно с представителями регионального Управления Федеральной службы судебных приставов периодически участвовали в рейдах, проводимых на улицах города. С помощью автоматизированной поис­ковой системы «Поток-Д», установленной на служебных автомобилях региональ­ного Управления ФССП России, выявлялись должники по уплате транспортного налога.

Еженедельно в базу данных системы «Поток-Д» региональным Управлением ФССП России вносились данные о транспортных средствах должников, в отношении которых были возбуждены исполнительные производства. В течение 2009 года общее количество должников, внесенных в базу данных системы, составило почти 10 000 человек, а также было выявлено 895 транспортных средств должников

Как правило, неплательщики хорошо осведомлены о дальнейших действиях налоговиков, направленных на взыскание долгов. Поэтому многие из них ста­рались незамедлительно погасить долг по налогу. Так, в ходе указанных рейдов 645 должников добровольно на месте уплатили представителям ФССП России более 12 млн. руб. недоимки по налогу и пеней.

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

Например, в Кировском районе Санкт-Петербурга арестовано имущество пяти должников на сумму 1,8 млн. руб., Василеостровском районе — трех должников на сумму 1,4 млн. руб., во Фрунзенском районе — двух должников на сумму 0,9 млн. руб.

В Центральном районе города при взаимодействии сотрудников ФССП Рос­сии и налоговых органов было установлено местонахождение автомобилей, вла­дельцы которых имели крупные суммы задолженности по уплате транспортного налога. В результате арестовано два автомобиля общей стоимостью 1 млн. руб. После погашения налоговой задолженности арест с автотранспортных средств был снят.

Для проведения исполнительных действий представители регионального Управления ФССП России совместно с сотрудниками налоговых органов систе­матически посещали должников по месту жительства, а также по месту работы. Результатом такой работы, проведенной в Выборгском районе, стало вручение исполнительных документов и квитанций для добровольного погашения долга налогоплательщику, имевшему задолженность в сумме 170 000 руб., после чего он погасил недоимку в полном объеме.

Мероприятиям, проводимым ФССП России по взысканию задолженности в судебном порядке, предшествует очень трудоемкая работа налоговых органов по подготовке документов для направления исковых заявлений в суды

По ходатайствам налоговых органов ФССП России выносились постановле­ния об ограничении выезда должников за пределы Российской Федерации. Всего в 2009 году территориальными подразделениями ФССП России вынесено более 4000 постановлений об ограничении выезда за границу в отношении всех категорий граждан, не исполнивших судебные акты о взыскании налоговой задолженности.

На сайте Управления в августе 2009 года был размещен список должников по транспортному налогу с суммой долга от 100 000 руб., который постоянно обновлялся. Многие налогоплательщики, обнаружив себя в списке, стремились как можно быстрее уплатить недоимку и пени. С августа 2009 года по январь 2010 года 979 налогоплательщиков из 3191, попавших в указанный список, по­гасили задолженность на сумму более 116 млн. руб. В отношении граждан, не уплативших налог, в настоящее время применяются меры по его судебному взы­сканию.

Только за 2009 год в суды направлено исковых заявлений на сумму более 1 млрд. руб. Судебными органами уже вынесены решения о взыскании с должни­ков налога на сумму более 400 млн. руб. Начало процедуры судебного взыскания побуждает многих из них уплатить причитающиеся суммы, не дожидаясь реше­ния суда. Кроме того, 57 налогоплательщиков-должников, имеющих крупные сум­мы задолженности по транспортному налогу, были вызваны в территориальные налоговые органы на комиссии по урегулированию налоговой задолженности с участием представителей прокуратуры и правоохранительных органов.

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

С декабря 2009 года на сайте Управления действует online-сервис «Узнайте вашу задолженность» в рамках реализации программы «Личный кабинет нало­гоплательщика». Данная услуга с первого дня подключения очень востребована пользователями сайта. Ею уже воспользовались более 250 000 жителей Санкт-Петербурга. Среднее количество обращений в день составляет более 4000, а в от­дельные дни — от 20 000 до 25 000. Сумма поступлений в бюджет от пользовате­лей online-сервиса с начала его работы по 1 февраля 2010 года составила более 31 млн. руб.

Планы по расширению информационных услуг в 2010 году

В текущем году Управление планирует расширить перечень услуг по предоставле­нию налогоплательщикам — физическим лицам информации о наличии задол­женности по всем налогам. Такие сведения можно будет получить на мобильный телефон в виде СМС-сообщения. Чтобы узнать о задолженности, налогоплатель­щику нужно только отправить СМС-сообщение, содержащее ИНН, на определенный федеральный номер сотовой связи. В ответ он получит СМС-сообщение о сумме задолженности либо о ее отсутствии.

Главная задача, которую ставят перед собой налоговые органы Санкт-Петер­бурга в 2010 году, — обеспечить своевременную и полную уплату транспортного налога каждым налогоплательщиком, имеющим в собственности транспортные средства. Для этого необходимо иметь достоверную базу данных как о налогопла­тельщиках, так и об исполнении ими налоговых обязательств. Поэтому Управле­ние совместно с Управлением ГАИ ГУВД по г. Санкт-Петербургу и Ленинградской области в январе текущего года провело два совещания по вопросам своевремен­ного предоставления актуальной информации в налоговые органы о владельцах транспортных средств.

Кроме того, важно, чтобы налоговое уведомление было доставлено налогопла­тельщику. С этой целью анализируется возвратная корреспонденция, уточняются адреса доставки на основании сведений, предоставляемых Управлением Федераль­ной миграционной службы по Санкт-Петербургу и Ленинградской области.

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

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

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

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

Основными целями управленческого учета в компании, например, могут быть:

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

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

Информационные технологии и управленческий учет

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

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

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

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

Безусловно, в предлагаемых на рынке программных продуктах, например ERP-система Axapta, имеются инструменты для реализации и того и другого решения[см. Пример бюджетирования в Axapta].

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

Можно отметить, что еще в 2004 году руководство сети дискаунтеров “Дикси” планировало в качестве системы оперативного учета финансово-хозяственной деятельности на уровне холдинга использовать ERP-систему Axapta, а создание системы бюджетирования предполагалось на базе BPM-системы “ Hypirion”.

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

Системы бюджетного управления и контроля

На российском рынке можно отметить следующие системы масштаба предприятия, используемые для автоматизации бизнес-процессов бюджетирования:

Система бюджетного управления PlanDesigner

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

Эти возможности обеспечиваются тем функционалом, который уже реализован в системе PlanDesigner. Ниже приведена сравнительная таблица функционала продуктов класса BPM (по данным компании S-Lab, ©MATRIXGROUP)

где в ценовой нише продукта использованы обозначения

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

Кратко остановимся на основных элементах системы PlanDesigner.

Основные элементы PlanDesigner

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

Кубы и измерения

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

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

В данном примере использованы измерения:

• “Продукты” (состоящее из «атрибутов» “Продукт 1”, “Продукт 2”, “Продукт 3”)
• “Продавцы” (состоящее из «атрибутов» “Менеджер 1”, “Менеджер 2”, “Менеджер 3”)
• “Годы” (состоящее из «атрибутов» “2004 год”, “2005 год”, “2006 год”)

Выделенная фиолетовым цветом ячейка «2004год-Продукт2-Менеджер3» содержит значение 15 000 – данные об объёме продаж продавцом Менеджер3 в 2004 году Продукта2.

В общем случае Куб может содержать любое, но не менее двух, измерений.

Визуализация данных
Для визуализации данных, хранящихся в кубе, используется привычное табличное «представление» (или «срез»)

Для создания нужного представления «вращают куб», меняя измерения местами. Можно «разрезать» куб поперёк одной или несколькими осями, фиксируя на этих осях какой-либо один атрибут. Например:

Двумерный срез куба, разрезанный по продавцу Менеджер 3 и развёрнутый по «годам» и «продуктам».

Если разместить на оси «строк» или оси «столбцов» более двух измерений, то получим двумерную иерархическую таблицу с большим числом развёрнутых измерений, например:

Особенности Измерений

Измерения в PlanDesigner могут включать в себя не только перечень простых атрибутов. Например, в рассматриваемом примере , как правило , интересуют итоги:

• по продуктам,
• по продавцам,
• за период.

Их можно получить, если в измерениях определить атрибуты через формулы, т.е. атрибут «Всего по продавцам» в измерении «Продавцы» равен «Всего по продавцам» = «Менеджер 1» + «Менеджер 2» + «Менеджер 3».

Соответственно, атрибуты :
«Всего по продуктам» = «Продукт 1» + «Продукт 2» + «Продукт 3»
«Всего за период» = «2004 год» + «2005 год» + «2006 год»

На рисунке показан «кубик», c данными атрибутами в измерениях

в системе PlanDesigner срез по фронтальной плоскости этого кубика может выглядеть как:

и суммарный результат, как видно на рисунке, «Всего за период», «Всего по продуктам», «Всего по продавцам» равен 1 368 000.

В измерениях возможно использовать атрибуты, в которых задаются не только простое суммирование. Например, измерение «выручка», которое рассмотрим чуть ниже, содержит атрибуты: «количество», «цена», «стоимость». Причем атрибут «стоимость» рассчитывается как «стоимость» = «количество» *«цена».

Связи

Другим концептуальным понятием в PlanDesigner является понятие “связи”. Связь – это правило преобразования данных, согласно которому данные из ячейки «куба–источника» попадает в ячейку «куба-приемника».

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

Уже есть один куб в котором приведены данные об объемах продаж в количественном выражении. Рассмотрим новый куб “PriceList”, в котором заданы цены товаров. Он состоит из уже рассмотренных выше измерений “Продукты” и “Годы”

Сооветственно в системе "PlanDesigner" он будет выглядеть как обычная двумерная матрица.

Создадим куб “Продажи”, в котором содержаться измерения:

• “Продавцы ”
• “Продукты ”
• “Годы ”
• “Выручка ”

И определим две связи

• “Количество из Объемов продаж”
• “Цена из PriceList”

которые после их создания в PlanDesigner могут выглядеть как представлено на рисунке:

Первая связь передает в куб “Продажи” данные о количестве продаж товаров из куба “Объем продаж”.

После выполнения этой связи в кубе “Продажи” появятся данные:

Вторая связь передает в куб “Продажи” данные о цене товара:

После выполнения этой связи в кубе “Продажи” появятся данные:

И после расчета куба получим полную картину о продажах в количественном и стоимостном выражениях:

Набор кубов и связей между ними позволяют создавать совокупность связанных многомерных бюджетов. Обычно модель системы бюджетного управления и контроля содержит в своем составе не менее нескольких сотен кубиков. Эти кубы собираются в модели (например, модели “Операционный бюджет продаж – план”, “Операционный бюджет продаж – факт” ), в свою очередь модели собираются в группы (например, “Бюджет Холдинга”, “Бюджет Управляющей компании”, “Бюджет Филиала 1”, “Бюджет Филиала 2” и т.д.).

Выводы

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

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

Читайте также:
Планирование закупок в Axapta на примере торговой компании
Пример бюджетирования в Аксапте
Анализ ликвидности в Аксапте

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

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

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

Как правило, в компаниях, не использующих системы MRP класса для планирования закупок, складываются свои, особенные методы расчёта потребностей в материалах и товарах. Более того, во многих из таких компаний планирование закупок автоматизировано, как правило, собственными разработками (нашим специалистам удалось наблюдать довольно широкий спектр программных продуктов для планирования закупок – от простейших формул и макросов в Microsoft Excel до огромных процедур на языке PL/SQL в базе данных Oracle). Терминология и методология таких продуктов обычно формируется эволюционно, в зависимости от знаний и умений пользователей и программистов. В результате, пользователи привыкают к такому «птичьему языку» своих систем и с большой неохотой воспринимают, а то и откровенно саботируют, переход на новую систему. Несмотря на различия реализации планирования закупок в разных системах, большинство систем MRP класса оперируют общими понятиями, определёнными стандартами (методологиями) MRP и MRP II. Поэтому знакомство с модулем мы начнём с определения данных понятий применительно к системе Microsoft Axapta версии 3.0 SP4 FP1.

Основные понятия модуля «Сводное планирование»

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

Потребности

Под потребностями (в англоязычном интерфейсе — Requirements) понимаются планируемые расходы по открытым строкам заказов, CRM предложений, материалов для производственных заказов, планируемые расходы по проектам и складским журналам, а также прогнозируемые продажи и минимальный запас на складе, который необходимо поддерживать. Обычно термин употребляется в более узком смысле: брутто- или нетто-потребности (Gross & Net Requirements).

Покрытие

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

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

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

Например, на приведённом ниже рисунке первая строка является покрытием (значение поля «Требуемое количество» положительно), а вторая потребностью (значение поля «Требуемое количество» отрицательно).

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

Графически потребности обычно обозначаются стрелками вниз, а покрытия — стрелками вверх.

Брутто-потребности

Брутто-потребности (Gross requirements) формируются на основе только планируемых (прогнозируемых) расходов с учётом планируемых приходов товаров (прогнозов продаж и закупок) и не учитывают текущих остатков на складах, открытых закупок, заказов и складских журналов.

Пример результата расчёта брутто-потребностей изображён на рисунке.

В данном примере строки со ссылкой «Прогноз продаж» были получены из прогнозов продаж. А строки со ссылкой «Спланированные закупки» являются результатом расчёта покрытия для брутто-потребностей.

Отдельно расчёт брутто-потребностей осуществляется, как правило, для длительных периодов.

Нетто-потребности

Нетто-потребности (Net requirements) рассчитываются, как правило, на менее длительный период, чем брутто-потребности. Их расчёт наиболее точен, но требует больших вычислительных ресурсов, так как в расчёт включаются все планируемые движения товаров и остатки на складах.

В расчёт нетто-потребностей включаются:

• Брутто-потребности, полученные на основе прогнозов продаж и закупок,
• Остатки на складах,
• Открытые строки заказов,
• Открытые строки закупок,
• Неразнесённые складские журналы,
• Открытые производственные заказы,
• CRM предложения.

Любой из вышеперечисленных источников может быть исключён из расчёта нетто-потребностей настройками сводного плана.

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

Прогнозные модели

Прогнозная модель (Forecast model) представляет собой один из сценариев, по которому будут происходить продажи. Например, можно создать оптимистическую, пессимистическую и наиболее вероятную модели. Аксапта позволяет использовать неограниченное количество прогнозных моделей, но при расчёте потребностей может быть использована только одна из них. Для создания комбинаций разных сценариев можно использовать подмодели. Тогда в расчёт потребностей будут включены все прогнозы текущей прогнозной модели и всех её подмоделей. Например, при включении в расчёт потребностей модели «КОМБИ» будут включены также подмодели «1-ОПТ» и «2-ПЕСС»:

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

Прогнозы

Прогноз (Forecast) представляет собой планируемые продажи (Sales forecast) или закупки (Purchase forecast) какого-либо материала или товара по одной из прогнозной модели. Совокупность прогноза продаж и закупок называется прогнозом запасов и используется для получения брутто-потребностей.

Пользователь может использовать возможности автоматического создания множества строк прогнозов по определённым алгоритмам на основании одной строки, введённой пользователем, при изменении количеств товаров в которой система сама пересчитает данные в автоматически созданных строках. Наиболее простой механизм — «Период». В этом случае система автоматически создаст строки прогноза через равные промежутки времени (день, месяц, год), начиная с даты прогноза до даты, указанной в поле «Завершение». Например, создадим прогноз продаж одной номенклатуры по 20 штук 10 числа каждого месяца в течение первого полугодия:

В данном примере система автоматически создала на основе одной вручную введённой строки (верхняя часть формы) 6 строк прогноза (нижняя часть формы), начиная с 10.01.2006 через каждый месяц по 30.06.2006.

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

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

В данном примере программа автоматически создаст на основе строки в прогнозной модели «ОПТ» новую строку прогноза в прогнозной модели «2-ПЕСС» со сдвигом даты прогноза на 5 дней и уменьшив количество в прогнозе на 20%:

Для групповых операций можно нажать кнопку «Выбор» и указать критерии выборки прогнозов, к которым должна быть применена данная операция. Например, в данном случае выбраны все строки прогнозных моделей «ОПТ» и «2-ПЕСС».

Ключи распределения

С ключами распределения (Period allocation keys, в русском переводе слово Период отсутствует) мы сталкиваемся довольно регулярно. Наиболее показателен пример с оценкой прогноза продаж в разрезе кварталов либо месяцев. В большинстве отраслей объёмы продаж не являются постоянными на протяжении всего года. Есть периоды спада и подъёма, максимума и минимума. Чтобы не определять планы на каждый период (квартал, месяц, неделя, день), а потом их править вручную при изменении прогнозов, используется автоматическое распределение суммы (объём продаж, затраты и т.п.), указываемой за больший промежуток времени, по более мелким периодам. Например, распределение планируемых продаж за год по кварталам или месяцам, распределение планируемых затрат за месяц по дням или неделям.

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

Месяц	Процент
Январь	2%
Февраль	3%
Март	5%
Апрель	10%
Май	10%
Июнь	15%
Июль	15%
Август	15%
Сентябрь	10%
Октябрь	7%
Ноябрь	5%
Декабрь	3%

В Аксапте данное распределение можно оформить в виде ключа распределения из 12 строк - по одной строке для каждого месяца с указанием сдвига для каждой строки: 0 месяцев для первой строки, 1 месяц для второй и так далее до 11 для двенадцатой строки.

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

В итоге получаем распределение по календарному году в разрезе месяцев:

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

Как правило, применяются несколько ключей для разных категорий товаров, имеющих разные сезонные распределения. Кроме того, часто используются ещё ключи, учитывающие распределение продаж по дням недели (см. Пример 2).

Ключи сокращения

Ключи сокращения (Reduction keys) выполняют более «тонкую» настройку прогнозов за счёт учёта влияния на спрос различных внешних или внутренних факторов. Например, в результате воздействия внешних факторов (поздняя весна, правительственный кризис) или внутренних (появление нового аналога товара в ассортименте, скидки на товар-заменитель) в ближайшие месяцы наши продажи данного товара будут ниже планируемых. Для такой цели более удобно использовать ключ сокращения, который скорректирует наши прогнозы с учётом данного фактора. Например, данный ключ сокращения показывает, что в течение всего февраля объём продаж будет меньше на 30% от прогнозированного.

Ключи распределения номенклатуры

Ключ распределения может быть не только по времени, но и номенклатуры (Item allocation keys). Он очень полезен в тех случаях, когда планирование по отдельным позициям требует слишком больших трудозатрат, и требуется запланировать продажи по группам товаров с автоматическим распределением по позициям. В качестве самого простого примера создадим ключ распределения номенклатуры с тремя позициями 50%, 25% и 25% (ключ распределения номенклатуры использован также в Примере 2). При расчёте потребностей с данным ключом распределения номенклатуры система сама распределит количества по конкретным товарным позициям.

Например, запрогнозировав продажи компьютеров в количестве 200 шт., система автоматически разобьёт этот прогноз по отдельным позициям:

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

Прогнозные планы

Прогнозный план (Forecast plan) объединяет прогнозы по выбранной прогнозной модели и созданные на их основе брутто-потребности. Прогнозных планов создаётся, как правило, несколько для разных сценариев.

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

Сводные планы

Сводный план (Master plan) включает в себя запасы в наличии, прогнозный план, планируемые расходы и приходы по открытым строкам заказов и закупок, складских журналов, производственных заказов и CRM предложений (только тех, вероятность которых большей указанной в поле «Вероятность в %») и рассчитанных на их основе покрытий.

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

В Аксапте расчёт брутто-потребностей обязателен для расчёта нетто-потребностей, если в сводном плане должны быть учтены данные прогнозного плана.

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

Коды покрытия

Коды покрытия (Coverage codes) представляют собой варианты алгоритмов, на основе которых формируются планируемые закупки, производственные заказы или складские переносы.

Код покрытия «Потребность»

Код покрытия «Потребность» (Requirement) является наиболее простым. Он формирует планируемые приходы товаров непосредственно перед их расходами, как показано на рисунке:

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

В результате график остатков на складах приобретает такой вид:

Код покрытия «Период»

Код покрытия «Период» (Period) отличается от кода покрытия «Потребность» тем, что формирует закупку не под каждую потребность, а суммарно под все потребности за некоторый временной период (например, в одном из проектов швейного производства интервал составлял одну декаду — 10 дней), как показано на рисунке:

В результате график остатков на складах приобретает вид ступенек:

Код покрытия «Min/Max»

Код покрытия «Min/Max» (Min./Max.) создаёт закупку в тот момент, когда остатки на складах становятся равны или ниже какого-то фиксированного значения «Min», а при формировании планируемой закупки устанавливает количество товара таким, чтобы остатки на складе достигли какого-то фиксированного значения «Max». В вышеприведённом графике превышение остатков товаров при закупке выше значения «Max» может быть связано с условиями поставки - минимальным размером заказа или кратности заказа.

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

Группы покрытия

Чтобы параметры покрытия не настраивать для каждого товара в отдельности, используются группы покрытия (Coverage group). Группа покрытия, указанная в форме параметров модуля, используется по умолчанию для номенклатур, для которых не указана группа покрытия и не настроены параметры покрытия, индивидуальные для номенклатуры.

Временные резервы

Резервы (Margins, в версии Axapta 2.5 данный термин был переведён на русский язык как «Маржа») — временные интервалы в днях, которые необходимо учесть при планировании. Например, время, необходимое для транспортировки товара от склада поставщика на склад покупателя. В системе предусмотрены три вида временных резервов: «Резерв заказа у поставщика» (Reorder margin), «Резерв прихода» (Receipt margin) и «Резерв расхода» (Issue margin).

Кроме временных резервов, в системе предусмотрен ещё один временной параметр — «Время доставки» (Lead time), который может быть разным у каждого поставщика, и указывается в коммерческих соглашениях. Можно даже предусмотреть возможность указания разных цен одного и того же поставщика в зависимости от сроков поставки (плата за срочность). В случае, если для пополнения склада вместо закупки используется перемещение с другого склада (такой склад называется в системе основным), используется временной параметр «Время переноса», указывающий количество дней, необходимых для перемещения товара на склад с основного склада.

Мероприятия

Мероприятие (Action, другой русскоязычный термин — Действие) — один из возможных результатов работы сводного планирования. Суть его — рекомендовать пользователю совершить действия по уменьшению складских остатков или сдвигу, уменьшению или увеличению закупки, переноса или производственного заказа с целью наиболее эффективного использования складских площадей и денежных ресурсов. Стоит отметить, что мероприятие — только рекомендация программы, пользователь может проигнорировать рекомендации. В системе предусмотрен целый ряд параметров, определяющих, каким образом система может создавать мероприятия. Например, можно предусмотреть, что система осуществляет сдвиг закупки максимум на 3 дня, может предложить её уменьшить или увеличить, но те закупки, которые планируются на ближайшую неделю, изменять уже нельзя. Кроме того, система сама может обновить даты закупок, если пользователь сделал соответствующие настройки.

Фьючерсы

Фьючерс (Futures) так же, как и мероприятие, является результатом сводного планирования и рекомендует выполнить пользователю какие-либо действия. Но фьючерсы появляются только в том случае, если по тем или иным причинам невозможно удовлетворить потребности в товарах вовремя и в нужном количестве. Тогда программа сообщает, какой заказ или перенос выполнить в срок невозможно, какой реально срок выполнения заказа и длительность задержки. Пользовать далее сам принимает решение, отменять заказ, информировать клиента о задержке или принять срочные меры для устранения проблемы. Как правило, фьючерсы и мероприятия работают вместе: например, сдвиг заказа клиента, как правило, вызывает сдвиг закупок и наоборот.

Минимальный запас

Минимальный запас (Minimum) используется в качестве минимального уровня запасов, ниже которого нельзя опускаться при любом коде покрытия. Используя специальные Ключи резервного запаса (Minimum/Maximum keys), можно настроить систему таким образом, что она будет поддерживать минимальные остатки на складах с учётом сезонного спроса:

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

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

Положительные и отрицательные дни

Основная цель положительных (Positive days) и отрицательных дней (Negative days) — сократить количество закупок с целью минимизации транспортных затрат.

Предположим, у нас для каждой потребности формируется новое покрытие в виде закупки. Есть потребность, которая попадает в интервал дат между двумя существующими закупками, как показано на рисунке:

Для простоты анализа предположим, что ни для Закупки 1, ни для Закупки 2 потребностей нет. В случае, если параметр положительные дни меньше расстояния от Потребности до Закупки 1, а параметр отрицательные дни меньше, чем расстояние от Закупки 2 до Потребности, система предложит удалить Закупку 1 и Закупку 2 и создать Новую закупку, как изображено на рисунке.

В случае, если положительные дни больше или равны расстоянию от Закупки 1 до нашей потребности, система будет пытаться сдвинуть (отсрочить) и при необходимости изменить объём Закупки 1 вместо создания новой закупки. Закупку 2 система предложит удалить.

А в случае, если отрицательные дни больше или равны расстоянию между Закупкой 2 и нашей потребностью, система будет пытаться увеличить и ускорить (сдвинуть на несколько дней) Закупку 2, а Закупку 1 предложит удалить.

В обоих случаях Новая закупка создаваться не будет, система будет пытаться использовать существующие закупки.

Параметр положительные дни имеет смысл устанавливать не больше срока хранения товара. В противном случае система будет пытаться покрыть потребности из закупок товаров, срок хранения которых уже истёк. Для скоропортящихся продуктов, которые должны поставляться каждый день, данный параметр ставится равным нулю. Слишком низкое значение параметра положительные дни может привести к ошибкам планирования и затовариванию склада (система не учтёт в покрытии те товары, которые пришли давно, и закажет новую партию), слишком высокое — к увеличению размеров закупок, уменьшению оборачиваемости товарных запасов и увеличению интервала между поставками, что особенно опасно в случае товаров с ограниченном сроком годности.

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

Примеры формирования плана закупок

Пример 1. Поставка товаров под заказ (торговля оптом)

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

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

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

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

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

Выбор кода покрытия

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

Формирование сводного плана

Делаем настройку сводного плана. Указываем необходимость учёта остатков на складах, открытых строк закупок и открытых строк заказов, CRM предложений:

Пример результата планирования

На рисунке показан вариант результата сводного планирования закупок по двум заказам клиента:

В случае существования закупки на 1 единицу товара на начало месяца и установки параметра положительные дни больше, чем время от закупки до последней потребности, система создаст мероприятие, предлагая увеличить объём закупки и сдвинуть её на более поздний срок перед первой продажей:

Таким образом, вместо трёх закупок в месяц будет одна перед первой потребностью.

В случае, если поставка не может быть выполнена в срок, система генерит фьючерс. Например, в данном случае система сообщает о том, что наш заказ клиента на 17 марта может быть выполнен только на 4 дня позже, а, именно, 21 марта:

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

Пример 2. Поставка товаров на склад (торговля в розницу, торговля со склада)

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

Так как продажи в течение недели обладают ярко выраженной сезонностью (больше продаж в выходные), используем ключ распределения, учитывающий различия в продажах по дням недели:

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

Выбор кода покрытия

В качестве кода покрытия в данном случае имеет смысл поставить «Период». Длительность периода может быть любой в зависимости от наших продаж и отношений с поставщиком. В качестве примера мы взяли длительность интервала 4 дня, чтобы поставщик привозил товар 1-2 раза в неделю.

Формирование прогнозного плана

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

Формирование сводного плана

Сводный план должен включать в себя остатки на складах, открытые строки закупок (у нас могут быть одновременно открыты 2-3 закупки, которые поставщик должен выполнить в ближайшие 1-2 недели). Никаких CRM предложений нет. Обязательно нужно правильно настроить параметры положительные и отрицательные дни. Положительные дни можно поставить 30 дней (товар длительного хранения), а отрицательные, например, 4 дня. В этом случае при отсутствии одного вида масла система не будет пытаться срочно докупить, а предложить подождать или ускорить закупку. Разумеется, необходимо указать минимальные количества каждого масла для выставления их на витрине магазина, но в нашем примере мы оставим их равными нулю.

При указанных наших данных система автоматически создаст закупку на весь ассортимент масла на ближайшие 4 дня продаж, учитывая при этом необходимость кратного количества в закупке (в ящике 6 бутылок):

Основные проблемы при настройках сводного планирования для розницы — расчёт прогнозов и минимального (резервного) запаса. Готового инструмента для расчёта прогнозов Аксапта не содержит. Наиболее простое решение предлагается на базе другого продукта компании Microsoft — Demand Planner, который полностью интегрируется с Micrisoft Axapta.

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

Пример 3. Поставка запасных частей (сервис)

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

Постановка задачи

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

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

Для примера искусственно создана статистика продаж со склада за три месяца, с декабря 2005 по февраль 2006:

Настройки планирования состоят из двух этапов:

1. Определение минимального (резервного) запаса на основе статистики продаж, времени упреждения и необходимого уровня сервиса (понятие уровень сервиса в данном случае определяет вероятность наличия товара на складе при возникновении запроса у клиента, более подробно данное понятие описано в [2] стр. 78-79).
2. Настройка сводного плана.

Определение минимального (резервного) запаса

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

Система рассчитала средние продажи и среднеквадратическое отклонение:

Теперь можно рассчитать уровень минимального запаса с учётом нашего времени упреждения и требуемого уровня сервиса:

В итоге система определила новый минимум в количестве 4 штук на нашем складе:

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

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

Настройка сводного плана

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

Выводы

Несмотря на очевидные преимущества модуля Сводное планирование, его внедрение далеко не всегда будет восторженно встречено пользователями. В первую очередь это связано с жёсткостью методологии MRP, которая диктует свои правила и ограничения. Кроме того, используемый штатный интерфейс во многих случаях не может состязаться с отточенными в течение многих лет интерфейсами. Но переход на Сводное планирование имеет ряд преимуществ даже при указанных недостатках. Во-первых, использование общепринятой методологии планирования сокращает время подготовки пользователей и их обучение. Во-вторых, использование штатных механизмов гарантирует практически полное отсутствие технических ошибок планирования. В-третьих, штатные механизмы обладает гораздо большей гибкостью, чем написанные под конкретные требования конкретных пользователей системы. В конечном итоге, поддержка штатных систем просто дешевле. В то же время надо отметить, что в ряде случаев для постановки полноценного планирования закупок одной Аксапты будет недостаточно, нужна система анализа продаж и создания прогнозов, например, Microsoft Demand Planner.

Кроме того, внедрение модуля Сводное планирование, как и любой системы, работающей по методологии MRP, требует выполнения ряда условий, необходимых для построения правильной системы планирования на предприятии, а также ряда организационных мероприятий (см. [1], стр. 13).

Литература

1. Д.А. Гаврилов. Управление производством на базе стандарта MRP II. Принципы и практика. Питер. 2002.
2. М.Кристофер. Логистика и управление цепочками поставок. Питер. 2004.

Читайте также:
Пример бюджетирования в Аксапте
Анализ ликвидности в Аксапте