1С Предприятие 7.7. Документация

    63cafd45   

Контур Оперативного управления


Базовые модули

Под оперативным управлением предприятием разработчики системы ГАЛАКТИКА понимают просто ввод фактических документов в модулях СБЫТ, СКЛАД и СНАБЖЕНИЕ, включая расчеты с поставщиками и покупателями. Модуль сбыт достаточно хорошо структурирован, имеет стандартную схему обработки Заказ - Отгрузка. При отгрузке можно проверить состояние расчетов с данным контрагентом. Модуль имеет развитую систему задания прайс -листов с различными скидками и т.д., однако привязка их к клиенту или Продавцу не жесткая. Система резервирования на складе и распределение резервирования по различным складам в соответствии с приоритетами отсутствует.

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

Связь с модулем склад осуществляется методом формирования (вручную) документа на основании отгрузки. При этом кладовщик может ввести другое количество. Счета-фактуры ведутся тут же. Фактически это документ на отгрузку.

Основным недостатком модуля, является то, что ПРОДАВЕЦ не может определить дату когда он может удовлетворить Заказчика, т.е. дату на которую он может принять заказ. Это связано с тем, что в системе вообще отсутствуют понятия ожидаемые приходы или ожидаемый спрос и связанное с этим понятие ожидаемое состояние склада.

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

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

Модуль Снабжение просто примитивен. Можно ввести Заказ и поступление по нему. Нет никаких Заявок, проверок Бюджета и, соответственно, резервирования фондов под эти Заявки. Таких понятий, как ожидаемая дата поступления и ее использования в системе нет. Все заказы однотипные. Нет ни постоянных контрактов, ни плановых заказов. Поставщики не группируются по приоритетам (например, с которыми имеется постоянный контракт). Коды материальных ценностей поставщика и список возможных замен не поддерживаются.

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

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




В системе ГАЛАКТИКА вообще отсутствуют любые функции корпоративного снабжения/сбыта. Невозможно реализовать функции централизованного снабжения (заявки поступают из нескольких организаций, а одна занимается обеспечением снабжения по ним) и связанной с этой функцией “drop shipment”, т.е. прямая отгрузка заказчику от централизованной снабженческой организации. Не существуют специальных операций внутри корпоративных заказов и отгрузок, которые крайне необходимы для обеспечения внутри корпоративных расчетов.

Дополнительные модули

К дополнительным модулям контура оперативного управления относятся: управление консигнационными товарами, давальческое сырье, учет материальных ценностей в производстве. Первые два модуля являются откликом на весьма специфические Российские запросы, хотя в ORACLE APPLICATION имеется возможность реализовать консигнационный склад (наличие учитывается, а проводки не делаются).

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

Выводы по “контуру”

Просмотрев функциональность данного “контура” опять возникает резонный вопрос: ”А где же управление?”. Все управление заключается в том, что кто-то просматривает (глазами) какие-то отчеты или таблицы данных и принимает ВОЛЕВОЕ решение.

Система не поддерживает ГЛАВНУЮ ИДЕОЛОГИЮ БИЗНЕСА - максимальное удовлетворение заказчика с минимальными затратами. Т.е. система АВТОМАТИЧЕСКИ не решает следующих вопросов:


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

    что, сколько, у кого и по какой цене, а главное когда закупать для удовлетворения введенного спроса (Заказов).

    Вопросы неликвидов и дефицита на складе решаются классическим способом выдачи отчета о материальных ценностях не имеющих движения (наконец-то управляющий узнал, что у него есть неликвиды!!!!). В то время как система должна автоматически обеспечивать положение (как это делает ORACLE APPLICATION) при котором эти неликвиды и дефициты не возникают вообще. Модулю снабжение явно не хватает функциональности, а рекомендации по “гибкой” работе с заказчиком путем оперативной корректировке прайс - листов вызывают умиление. Безусловно, данная методика очень гибка, только нужна ли такая гибкость руководству предприятия?


    Содержание раздела