Отчет по "мертвым петлям" в производстве по данным регламентированного учета для РАУЗ
Отчет позволяет найти "мертвые петли" выпуска продукции за интересующий период. Мертвая петля - это явление, при котором продукция в отчетном периоде выпущена сама из себя, причем не важно, через сколько колен. Наличие мертвых петель существенным образом замедляет расчет себестоимости выпуска при использовании РАУЗ.
Характеристики и серии не поддерживаются, но кому это нужно - несложно будет "допилить напильником".
Скачать файлы
| Наименование | Файл | Версия | Размер | |||
|---|---|---|---|---|---|---|
|
ОтчетПоМертвымПетлям.erf
.erf 11,58Kb
29.07.11
195
|
.erf | 11,58Kb | 195 | Скачать |
См. также
"Мертвые петли" или по-другому орконтуры (ориентированные контуры - в теории графов) это совершенно нормальное явление в Графе затрат. Не очень понятно, зачем "кромсать" модель предприятия в угоду конкретному численному методу решения СЛАУ, тем более что обсуждаемый метод достаточно примитивен. На данный момент существует много быстрых методов решения СЛАУ, ориентированных на работу с сильно разреженными матрицами большой размерности. Примеры орконтуров можно посмотреть в статье:
-
x1 + x2 = 3
x1 + 2*x2 = 4
Сравним методы Гаусса и Якоби (который в РАУЗ)
По Гауссу
x1 + x2 = 3
x2 = 1
x = {2,1}
В РАУЗ мы получим итерации:
x(0) = {3,2}, x(1) = {1,0.5}, x(2) = {2.5,1.5}, x(3) = {1.5,0.75}, x(4) = {2.25,1.25}, x(5) = {1.75,0.875)...
Все согласно теории. Сходится как геометрическая прогрессия. Толку то...
Метод, который заложен в 1с позволяет юзеру самостоятельно управлять соотношением точности/времени расчета. С перебором это не получилось бы.
Конечно, бред.
Но в целом ты неправ, пихая свой опыт применения метода Гаусса , зато прав автор :
(только вместо "перебора" нужно читать "прямой метод")
Итерационный , а не прямой , метод нахождения медленнее, но надежнее прямого.
(9) Наличие петель отнюдь не означает вырожденности матрицы СЛУ - рисунок из это показывает. Так что еще неизвестно, надо ли убирать петли: ситуация, когда продукция (частично) выпускается сама из себя вполне реальна.
Теперь насчет вырожденных матриц. Метод Гаусса (это не метод последовательного исключения переменных, а приведение матрицы к верхнетреугольному виду!) даст ступенчатую матрицу, и при ненулевых свободных членах в "лишних" уравнениях мы сразу увидим несовместимость системы, т.е. ошибку в исходных данных в нашем приложении. Если же система останется совместимой - мы увидим, какие переменные можно выбрать произвольно, например, подставив в качестве расчетной себестоимости ожидаемую (плановую), сокращая размер матрицы.
Итерационный метод даст в этом втором случае медленную сходимость и в конечном итоге, необоснованную коррекцию той, ни на что не влияющей себестоимости на копейку-другую.
Сравнение методов имеет смысл только на соместимых, но плохо обусловленных СЛУ. Оба в "чистом виде" неприемлемы. Метод простых итераций - из-за плохой сходимости (приемлемая точность достигается за неприемлемое время). Метод Гаусса - из-за ошибок округления. Реальный выход в своей "РАУЗ" 2001 года я предложил такой. СЛУ составляется не для себестоимостей, а для отклонений себестоимостей от плановых. В сочетании с сортировкой (элементы диагонали матрицы по модулю убывают)это дает возможность по мере достижения переменными необходимой точности исключать их из дальнейших вычислений, снижая ранг матрицы и увеличивая ее норму. То есть итерации-то должны быть, только не простые.
Ну и еще раз: петли имеют право быть. Это не ошибка!
Прекрасно. Представим себе предприятие, которое решило для расчета затрат применить подход Арчибальда.
Предприятие покупает программу и ... "Арчибальда" как вспомогательное приложение.
Действительно , ведь после получения "треугольной матрицы" нужно еще кому -то принять правильное решение о совместности системы с учетом ошибок округления, далее нужно кому-то "подставить в качестве расчетной себестоимости ожидаемую (плановую)".
1с пошла по другому пути и продает клиентам программу "без Арчибальда".
В каких -то частных случаях их решение проигрывает программе "с Арчибальдом", но думаю , их товар более востребован на рынке.
Я, прошу прощения, не математик, я всего лишь любитель. Могу ошибаться, но мне показалось, что если петля есть, то СЛУ должна оказаться вырожденной, т.е. в ней неизвестных должно быть больше, чем уравнений. Т.е. если применять метод последовательного исключения неизвестных, то получим СЛУ меньшего размера: 1хN, где N - это разность от числа неизвестных и числа уравнений, в смысле - одно линейное уравнение с N неизвестными, т.е. область. Такое уравнение можно решить только полуэмпирическим путём - взяв цифирьки из жизни (например - какую-либо фиксированную стоимость или что-нибудь в этом роде). Я ошибаюсь?
Позволю себе не согласиться. "Мертвые петли" - абсолютно ненормальное явление в графе ПРЯМЫХ затрат. По моему мнению и опыту, если это наблюдается, значит в чем-то "модель предприятия" ущербна! Т.е. имеет место либо неверная организация учета, либо подмена/путаница в понятиях прямых и косвенных затрат (20/23 путаем с 25). В косвенных расходах это может происходить сколько угодно. На примере картинки Арчибальда просто надо от кружочка П к Э отражать выпуска как Дт23-Кт23, а обратно как Дт25-Кт23 и все будет красиво, петли не будет. Так и во всех других случаях. Прямые затраты - это то что в том примере обозвано "Первичные" - только те что могут быть напрямую пронормированы на единицу продукции. Все другие - косвенные. Почти никогда на продукцию нельзя пронормировать освещение/отопление помещений, текущие мелкосрочные ремонты и т.п. Имеет смысл выискать петли по производственным материальным затратам, т.к. в этом смысле всегда должно действовать правило, что изделие само из себя выпущено быть не может, иначе нарушается закон сохранения и превращения материи :) Т.е. если отражена такая хоз. операция, которая формирует петлю то значит кто-то лжет.
everybody lies ((с) House M.D.)
А затраты на единицу продукции как раз в моем примере нормируются легко (кроме общепроизводственных, конечно). Просто проводки 20-20 делаются (при необходимости) статья в статью. Конечно, при этом СЛУ, конечно, надо решать тоже постатейно. Это и есть реальный РАУЗ, когда в стоимость, к примеру, воды, включена часть зарплаты начальника электростанции.
На мой взгляд, совершенно не важно о каких потоках затрат идет речь - о прямых или косвенных. Здесь важна топология модели. Если есть контур (петля - это когда начало и конец дуги принадлежат одному центру затрат) между двумя центрами затрат и нет других потоков затрат, то, в случае отсутствия незавершенки - такая модель действительно некорректна, определитель такой матрицы равен 0-лю. Если есть исходящий поток затрат еще на какой-либо центр затрат - то модель работает. Кстати, там можно наблюдать интересные эффекты по многократному увеличению стоимости потоков затрат. Для примера можно посмотреть статью:
-
или прочитать в книге:
-
Легко. Если гора не идет к Магомету, то он идет к горе. Экономическое ПО призвано решать реальные экономические задачи, а не абстрактные математические ребусы. Если пример, который вы привели возможен в реальной жизни (я в этом сомневаюсь, т.к. выглядет очень хрупко), то с точки зрения управления, технологии и экономики все три подразделения нужно объединить в одно "Энергоузел" и посадить там одного начальника вместо троих! По отдельности они существовать не могут, исходя из нарисованной схемы. Все. Петли нет.
А если кто говорит, что нельзя ломать "модель предприятия" в угоду ПО, то это ограниченный взгляд на вещи. ПО обычно внедряют, чтоб навести порядок, а значит двигаться надо с обоих концов. По своему опыту скажу, что ломать закостенелые стереотипы поведения менеджеров предприятия приходится гораздо чаще, чем идеи, заложенные в качественном тиражном ПО. И это всегда дает наилучший эффект на выходе в оценке держателей предприятий.
А так, по Вашей логике, "с точки зрения управления, технологии и экономики", а главное, чтобы в УПП себестоимость (неизвестно чего) быстро считалась, на каждом предприятии должен быть один цех, один склад, один начальник. Ломать стереотипы, так ломать. Производство - ничто, УПП - наше знамя.
[quote]на каждом предприятии должен быть один цех, один склад, один начальник[/quote]
Не стоит возводить частное понятие оптимизации учета и управления в абсолютную степень. Думаю, это не самый уместный риторический приём.
В любом случае задача петли никогда, ни с Вашим, ни с Моим подходом не может быть решена неэмпирическим методом. Во всех случаях нужно "волевое" вмешательство в решающее правило, вне зависимости от того какой метод применяется: использовать в качестве базы планово-учетные цены, которые выдуманы из головы, либо просто какие-то коэффициенты на узлах петли, тоже из головы или что-то подобное. Тогда зачем усложнять жизнь себе, работникам предприятия и программе? Может ради самоутверждения? Сомнительная причина. Проще надо смотреть на вещи - народ к Вам потянется :)
1. Петли объективно существуют. Пример я привел. Кстати, у Маркса тоже примеры есть.
2. Наличие/отсутствие петель в графе не имеет отношения к существованию решения СЛУ. Любой математик это знает.
3. Если решение СЛУ существует, оно всегда может быть получено неэмпирическим путем.
4. Решение СЛУ, составляемых из графа затрат предприятия существует всегда, ибо всегда существует себестоимость.
5. Правильность моего подхода и алгоритмов проверена на практике бухгалтерии реального завода. И бухгалтеры оценили полученное упрощение своей работы.
Засим откланиваюсь.
Эге.. ты так и не понял , что анализ на вырожденность - есть главная слабость твоего подхода.
Хотя на самом-то деле , это не твоя , а общая слабость применения метода Гаусса для почти вырожденных матриц.
Ведь в результате твоего анализа ты должен однозначно ответить на вопрос :
Матрица вырождена ? Да или Нет.
В зависимости от ответа ты получишь разные решения , одно из которых - явный "бред".
Теперь представь себе , что для почти вырожденной матрицы такой вопрос вообще не имеет смысла, потому что из-за ошибок вычислений
определить её вырожденность невозможно.
Сетования на то , что на практике такие матрицы при расчете себестоимости редко встречаются (1 из 100) - это разговоры в пользу бедных.
Другими словами , возможность получения "бредового" решения - расплата за сверхскорость ("несколько секунд !").
Вот почему в типовом решении (УПП) применен итерационный метод решения. Тупой , медленный и надежный.
Здесь мы не отвечаем на фатальный вопрос Да или НЕТ, а "потихоньку" приближаемся к истинному Х и критерием окончания процесса может служить малость изменения евклидовой нормы наденных решений Х(п) и Х(п+1) .
Появилось время подробно разобраться в Вашем примере. Прошу прощения за необоснованные нападки, т.к. с самого начала не уловил к чему Вы клоните. С точки зрения математики - правда Ваша: петля с любым количеством звеньев действительно имеет однозначное решение.
С точки зрения реальной жизни, тем не менее, остаюсь на позиции, что явление петли в графе затрат редко бывает обосновано к.л. производственной необходимостью. Чаще всего это плод человеческой ошибки. А по сему анализировать граф на петли надо, т.к., следуя Вашему же примеру, цены мы получим искаженные, если петля возникла там, где ее быть не должно. В этом заключается полезность моего отчета.
(25)
Еще больший бред применять "иной" подход к задаче в программе, где эта задача решена. Не дороговато? Может быть тогда сразу надо было выбирать другую программу?
ab_initio 05.08.11 11:45 URL ↓Цитата ↓Ответить
(19) Легко. Если гора не идет к Магомету, то он идет к горе. Экономическое ПО призвано решать реальные экономические задачи, а не абстрактные математические ребусы. Если пример, который вы привели возможен в реальной жизни (я в этом сомневаюсь, т.к. выглядет очень хрупко), то с точки зрения управления, технологии и экономики все три подразделения нужно объединить в одно "Энергоузел" и посадить там одного начальника вместо троих! По отдельности они существовать не могут, исходя из нарисованной схемы. Все. Петли нет. А если кто говорит, что нельзя ломать "модель предприятия" в угоду ПО, то это ограниченный взгляд на вещи. ПО обычно внедряют, чтоб навести порядок, а значит двигаться надо с обоих концов. По своему опыту скажу, что ломать закостенелые стереотипы поведения менеджеров предприятия приходится гораздо чаще, чем идеи, заложенные в качественном тиражном ПО. И это всегда дает наилучший эффект на выходе в оценке держателей предприятий.
С обоих концов, это да, но вот бывает, что надо, так как есть, а вот тогда приходится голову ломать
По поводу характеристик - все зависит не от отчета, а от Ваших данных, т.е. от того как у Вас в базе настроен РАУЗ (Сервис -> Настройка учета -> Настройка параметров учета -> Режим учета затрат -> Детализация учета).
Отчет работает только с ключами аналитик РАУЗ, если у Вас используются характеристики в настройках РАУЗ, то он их учтет, т.к. они в этом случае будут в составе ключей. Если нет - то нет.
Просмотры 5965
Загрузки 26
Комментарии 35
Создание 29.07.11 08:00
Обновление
№ Публикации 87976
Рубрики
Бухгалтерские,
Анализ учета
Тип файла Внешний отчет (ert,erf)
Платформа Платформа 1С v8.x (все механизмы)
Конфигурация 1С:Управление производственным предприятием
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета
Бухгалтерский учет ,
Управленческий учет
Раздел учета Производство готовой продукции (работ, услуг)
Доступ к файлу Абонемент ($m)
Код открыт Не указано
