Oberon space
General Category => Общий раздел => Тема начата: ilovb от Апрель 11, 2012, 09:47:14 am
-
У одынесников есть профессиональная забава под названием "разузлование".
На производственном предприятии рано или поздно возникает задача анализа затрат.
Т.е. нужен отчет, который показывает из чего сложилась себестоимость продукции в виде дерева.
Затраты обычно накапливаются в одной, или нескольких таблицах вида:
| Дата | Номенклатура | Затрата | Сумма |
Тут номенклатура выступает в качестве родителя.
В 1С конечно все несколько сложнее. Там эти данные хранятся в регистре РАУЗ.
Но специфика 1С тут мало интересна и я не буду ее освещать.
Суть задачи в следующем:
Нужно максимально эффективно по времени выполнить разузлование.
Ограничения:
Ваш код на клиенте.
СУБД находится на сервере в локальной сети 100мбит.
К СУБД можно обращаться только SQL оператором SELECT.
Рекурсивные запросы СУБД не поддерживает.
Пользователь может формировать отчет за любой период с наложением любых отборов на данные.
Отчет должен формироваться за приемлемое время на огромных объемах данных.
Можно рассмотреть вариант, когда исходные данные предварительно подготавливаются каким либо образом (время подготовки не ограничено, но это не должно в разы увеличить размер базы).
Как бы вы решали такую задачу?
p.s. Задавайте вопросы. Буду уточнять...
-
Уточнение:
На сервере СУБД можно формировать временные таблицы и индексировать их.
-
Из постановки задачи мне не понятно - где тут дерево?
-
Вечером сделаю пример с исходными данными и деревом которое нужно получить.
-
Еще хотелось бы узнать что значит "огромные объёмы".
Допустим мы (Дата | Номенклатура | Затрата | Сумма) занумеровали целыми числами (UInt64 | UInt64 | UInt64 | UInt64).
Это 32 байта на строчку.
В одном гигабайте уберётся 33.5 миллионов таких записей.
В восьми гигабайтах -- 268 миллионов записей. Это много или мало?
-
Ну в 1С в этой таблице примерно 100 байт на строчку.
В таблице за год накапливается примерно 10 гигов (+/- 1).
p.s. Еще может разнообразная дополнительная информация тащиться из других таблиц. В результате на строчку максимум 200 байт наверно.
p.p.s Тут не очень важны конкретные циферы. Важно лишь понимать, что на клиента это все закачивать нет возможности, т.к. элементарно не хватит памяти. Т.е. выгребсти всю таблицу одним запросом и обойти ее рекурсией не прокатит... Получать запросом подчиненные записи на каждый элемент дерева очень дорого. Плюс если в таблице зацикливание, нам его нужно как-то обойти.
-
Интересны также общие соображения. Например клиент формирует отчет по всей продукции за год, но такой отчет в оперативе не поместится.... Как быть? Покрутить пальцем у виска или предложить альтернативу?
Клиенту по сути нужна комфортная работа. Чтобы, изменив период или отбор какой, не приходилось ждать по 6 часов. :)
Сразу все мы не можем закачать на клиента, значит нужно динамически подтягивать по мере необходимости.... но делать это эффективно.
Тут коренные проблемы две:
1. Нам неизвестна глубина формируемого дерева
2. В дереве могут быть циклы
-
Ну в 1С в этой таблице примерно 100 байт на строчку.
Чегой это я? Народ в заблуждение ввожу :)
100 байт это только внешние ключи конечно. Т.е. например наименование номенклатуры в другой таблице находится...
-
Так записей-то в таблице сколько?
-
Примерно 10 000 000 за год
-
Вот свежие реальные данные: Формируем по 15 позициям продукции за месяц. Элементов самого нижнего уровня в дереве примерно 1 миллион
-
Интересны также общие соображения. Например клиент формирует отчет по всей продукции за год, но такой отчет в оперативе не поместится.... Как быть? Покрутить пальцем у виска или предложить альтернативу?
Крутить у виска - не доблесть, значит нужна альтернатива...
(если по-хорошему, то начать следовало бы, наверное, с проектирования БД под предметную область)
Клиенту по сути нужна комфортная работа. Чтобы, изменив период или отбор какой, не приходилось ждать по 6 часов. :)
... и клиент прав...
Сразу все мы не можем закачать на клиента, значит нужно динамически подтягивать по мере необходимости.... но делать это эффективно.
Можно подкачивать, можно сформировать [временную] таблицу и потом читать из неё.
Тут коренные проблемы две:
1. Нам неизвестна глубина формируемого дерева
2. В дереве могут быть циклы
1. Глубина не слишком важна, если данные для отчёта формируются во временной таблице, да, и при подкачке данных на клиента... тоже не слишком проблематично. Хотя не очень понятен тезис о произвольной глубине иерархии. Неужели структура себестоимости продукции/затрат произвольна?.. Может быть поговорить с экономистами?..
2. Циклов в "дереве" быть не может, иначе это не "дерево", а циклический граф. Возможно, имелось ввиду, что на одну вложенную ветку ссылаются две других ветки-владельцы?.. Тогда это не "дерево", а сеть, орграф.
В любом случае, Вам надо составить "дерево" (иерархию) запросов. Результаты этих запросов будут либо закачиваться на клиента, либо помещаться во временную таблицу (возможно потребуется более одной таблицы). Если используется вариант со временными таблицами, то создавать "дерево" лучше не с помощью ссылок на родительский узел, а с помощью диапазонов. При этом нежелательны произвольная глубина и циклы, поскольку решение будет более трудоёмким, хотя и возможным.
Какая СУБД используется?
-
...Неужели структура себестоимости продукции/затрат произвольна?.. Может быть поговорить с экономистами?...
Затраты только примерно планировать можно.
Вот сломался станок например. Мастер чинит этот станок.
Работа мастера в данном случае затрата, которая имеет свою стоимость. Эта стоимость должна войти в себестоимость полуфабриката, обрабатываемого на этом станке.
Т.е. затраты это не спецификация. Нету предопределенного состава затрат. Их можно только анализировать, и влиять на их состав управленческими рычагами. Таким образом регулируют себестоимость продукции и соответственно маржинальный доход.
Для того отчет и нужен. :)
На остальное по порядку вечером отвечу.
-
Примерно 10 000 000 за год
Тогда это ерунда. Перенумеруйте все используемые объекты в целые числа. В 64 разрядных целых числах таблица по 4 числа в строке из 10М записей займёт всего 300 Мб. Закачай эти 300 Мб в оперативную память клиента и со скоростью света сделай над ней любые расчёты. При выводе отчёта на лету преобразовывай обратно из целых чисел в исходные объекты.
-
Во первых: Как их нумеровать? Нам только SELECT доступен.
Во вторых: Как их обратно в объекты преобразовать? Объекты то в СУБД хранятся... Сделать к базе 10м запросов? На это месяц уйдет.
-
Хотя можно только отобранный массив на сервер отослать и там преобразовать в объекты.
Понял вашу мысль. Согласен.
Но как нумеровать объекты мне все равно не понятно.
-
...Неужели структура себестоимости продукции/затрат произвольна?.. Может быть поговорить с экономистами?...
Затраты только примерно планировать можно.
Затраты (себестоимость) можно и нужно планировать. Да, могут быть внеплановые затраты, но планирования это не отменяет, а, наоборот, позволяет увидеть проблемные места, а значит открывает простор для поиска решений (хотя простор очень мизерный, на самом деле).
Вот сломался станок например. Мастер чинит этот станок.
Работа мастера в данном случае затрата, которая имеет свою стоимость. Эта стоимость должна войти в себестоимость полуфабриката, обрабатываемого на этом станке.
Т.е. затраты это не спецификация. Нету предопределенного состава затрат. Их можно только анализировать, и влиять на их состав управленческими рычагами. Таким образом регулируют себестоимость продукции и соответственно маржинальный доход.
Для того отчет и нужен. :)
Как учил прадедушка... К. Маркс производство включает в себя предмет труда, средства труда и живой труд. Предмет труда - это то из чего получается конечный продукт (если на промежуточной операции, то полуфабрикат), то есть, в понятие предмета труда входят сырье, комплектующие и пр. материалы. Средства труда - это оборудование (станки, в том числе), оснастка и инструменты. Живой труд - это труд рабочих/инженеров/программистов и пр. Все три ипостаси делятся на две категории: основные и вспомогательные (основные/вспомогательные материалы; оборудование; рабочие). Затраты на основные - списываются прямо на себестоимость продукции. Вспомогательные списываются на цеховые (иногда на заводские) расходы, позже они распределяются на всю выпущенную продукцию, например, пропорционально объёму (материалоёмкости), трудозатратам, стоимости или как-то ещё (не суть). Труд ремонтных рабочих - это вспомогательный труд. Ремонтные работы могут проводится по план-графику (система ППР - планово-предупредительных ремонтов) или по ситуации (поломки, аварии и т.п.). Они могут списываться на цеховые расходы, если ремонтники входят в состав цеха или ремонтные работы проводятся силами основных рабочих, или на заводские, если завод имеет централизованную службу ремонта. Расходы на восстановление оборудования после аварии являются внеплановыми и служат для оценки эффективности системы ППР (если таковая имеется на предприятии) или для оценки потерь, связанных с отсутствием системы ППР.
Как видите данный фактор (ремонт станка) должен, наряду с прочими, учитываться в структуре себестоимости.
-
Хотя можно только отобранный массив на сервер отослать и там преобразовать в объекты.
Можно иначе. Когда клиент будет смотреть отчёт, то одномоментно на одной странице он увидит порядка 100 записей, вот только для них имена и закачать. Когда он перейдёт к просмотру другой страницы подкачать имена для других 100 записей, а для предыдущих забыть.
Но как нумеровать объекты мне все равно не понятно.
В БД создать и заполнить таблицы:
Словарь номенклатур (по сути массив)
индекс: UInt64 (автоинкремент)
номенклатура: Номенклатура (уникальный)
Словарь затрат (по сути массив)
индекс: UInt64 (автоинкремент)
затрата: Затрата (уникальный)
Дату в UInt64 и наоборот преобразовывать по функции.
Сумма наверное и так UInt64?
Далее таблицу (Дата | Номенклатура | Затрата | Сумма ) переделать в таблицу (датаКакЧислоUInt64 | индекс_номенклатуры | индекс_затраты | суммаКакЧислоUInt64).
-
Затраты (себестоимость) можно и нужно планировать.
Я и не отрицаю. Наш отчет в частности и в планировании нужен.
Но для решения нашей задачи это ничего не дает.
Как учил прадедушка...
О теории управленческого учета можно долго говорить.
Вывод то какой?
Как видите данный фактор (ремонт станка) должен, наряду с прочими, учитываться в структуре себестоимости.
Отчет нам это и должен показать.
-
Как видите данный фактор (ремонт станка) должен, наряду с прочими, учитываться в структуре себестоимости.
Отчет нам это и должен показать.
Показатели себестоимости образуют иерархию. Под каждый показатель - свой запрос, результаты запросов обрабатываются на клиенте или формируют [временную] таблицу на сервере.
-
Можно иначе...
В общем понятно. Правда для 1С такой метод не подойдет. (много причин) А вот если напрямую с СУБД работать, то вполне.
Правда остается вопрос: А если данных еще больше? Если там уже не 10м а 500м?
И разузлование в оперативе тоже интересно обсудить. ;)
-
Показатели себестоимости образуют иерархию. Под каждый показатель - свой запрос, результаты запросов обрабатываются на клиенте или формируют [временную] таблицу на сервере.
Я не очень понимаю.... Что такое показатель? Как это храниться должно?
Можно подробнее?
Вот я формирую отчет по затратам на производство паровоза. Как ваш метод будет работать по шагам?
-
p.p.s Тут не очень важны конкретные циферы. Важно лишь понимать, что на клиента это все закачивать нет возможности, т.к. элементарно не хватит памяти. Т.е. выгребсти всю таблицу одним запросом и обойти ее рекурсией не прокатит... Получать запросом подчиненные записи на каждый элемент дерева очень дорого. Плюс если в таблице зацикливание, нам его нужно как-то обойти.
Выделенное жирным непонятно -почему?. Задача частотная - классический подход создание drill-down (разворачивающихся по требованию) отчетов - количество уточнений ( а следовательно запросов на их получение) невелико - на сетку нагрузка минимальная.. Насчет "зацикливания" вам сказал AlexUs.
Помочь быстро получать временные данные - помогают вспомогательные поля введенные в структуру базовых таблиц -их конкретный тип и количество определяется структурой БД и требуемой отчетностью. Заполняются эти поля обычно во время некритичных по времени операциях ( триггерами на уровне БД, или средствами пост - пред обработки 1С). Можно также, делать это отдельной последовательностью действий (преподготовка) - но только если нет зависимостей (значение этих полей не используется в других отчетах).
-
(если по-хорошему, то начать следовало бы, наверное, с проектирования БД под предметную область)
На структуру исходной таблицы мы мало можем влиять. Она такая какая есть, и оптимизирована для других задач. Мы можем только дополнительные таблицы делать.
Можно подкачивать, можно сформировать [временную] таблицу и потом читать из неё.
А как ее сформировать? Что в ней должно быть? Это и интересно :)
2. Циклов в "дереве" быть не может, иначе это не "дерево", а циклический граф. Возможно, имелось ввиду, что на одну вложенную ветку ссылаются две других ветки-владельцы?.. Тогда это не "дерево", а сеть, орграф.
Да. Не может.
Но есть два момента:
1. Пользователь мог допустить ошибку при вводе данных, и случайно получился цикл.
2. Полуфабрикат может пойти на затраты сам на себя (и это не редкость)
Отчет должен конечно корректно эти ситуации обработать. И кроме того нужно бы и пользователю показать где циклы образуются.
При обнаружении цикла конечно дальнейшее разузлование в данной ветке дерева уже не имеет смысла.
В любом случае, Вам надо составить "дерево" (иерархию) запросов. Результаты этих запросов будут либо закачиваться на клиента, либо помещаться во временную таблицу (возможно потребуется более одной таблицы). Если используется вариант со временными таблицами, то создавать "дерево" лучше не с помощью ссылок на родительский узел, а с помощью диапазонов. При этом нежелательны произвольная глубина и циклы, поскольку решение будет более трудоёмким, хотя и возможным.
Какая СУБД используется?
Что значит дерево запросов?
Про глубину и циклы уже говорил.
СУБД - MS SQL Server
-
А я все еще хочу пример исходных данных чтобы таки пощупать оное дерево за… узлы :-)
-
1. Пользователь мог допустить ошибку при вводе данных, и случайно получился цикл.
2. Полуфабрикат может пойти на затраты сам на себя (и это не редкость)
1. В нормально настроенной системе такого быть не должно ( каждое изменение в наборе данных должно быть синхронизировано по логике с зависимыми данными - (иначе нарушение логики в штатном режиме) - то есть операция если она прошла - должна быть корректной.
2. Если это ДОПУСТИМО логикой - то структура не является деревом , по определению.
-
Выделенное жирным непонятно -почему?. Задача частотная - классический подход создание drill-down (разворачивающихся по требованию) отчетов - количество уточнений ( а следовательно запросов на их получение) невелико - на сетку нагрузка минимальная.. Насчет "зацикливания" вам сказал AlexUs.
Структура затрат может быть очень большой. Пользователь сразу должен развернутое дерево увидеть. У него палец отвалится по крысе клацать :)
Да и запросы будут отнимать на вскидку секунд 15-20.... (это в простейшем случае)
Клацнул. Ждешь... Клацнул. Ждешь... У пользователя на 150 клике глаз начнет дергаться
-
2. Если это ДОПУСТИМО логикой - то структура не является деревом , по определению.
Да, допустимо. Но вывести нужно дерево. Циклы просто не разворачивать, и показывать на каком элементе образуется цикл. В таких ситуациях пользователь сам разберется. (ошибка это, или так и надо)
-
Вот тут очень хороший способ (Ctrl+F Маршрут обхода):
http://www.osp.ru/pcworld/2007/03/4199032/ (http://www.osp.ru/pcworld/2007/03/4199032/)
Данные можно будет вытаскивать динамически и максимально быстро.
Но есть пара минусов:
1. Данные придется продублировать. Т.е. добавится еще одна таблица на 10 гигов
2. Эту таблицу нужно будет периодически заполнять.(раз в месяц) И это будет довольно долго выполняться.
-
Выделенное жирным непонятно -почему?. Задача частотная - классический подход создание drill-down (разворачивающихся по требованию) отчетов - количество уточнений ( а следовательно запросов на их получение) невелико - на сетку нагрузка минимальная.. Насчет "зацикливания" вам сказал AlexUs.
Структура затрат может быть очень большой. Пользователь сразу должен развернутое дерево увидеть. У него палец отвалится по крысе клацать :)
Да и запросы будут отнимать на вскидку секунд 15-20.... (это в простейшем случае)
Клацнул. Ждешь... Клацнул. Ждешь... У пользователя на 150 клике глаз начнет дергаться
1. Структура может быть сложной , а количество данных большим...- но если ситуацию анализирует человек -то смысла анализировать рулон бумаги с 500 наименованиями , каждое из которых содержит с полсотни зависимых позиций -нет. Классическое решение вопроса срезка данных по входным параметрам -но полагаю, что вы это знаете- не очень понятно почему это (у вас) не работает.
2. Странно... Профилируйте запрос (сколько времени из этих 15- 20 секунд приходится на создание выборки datamining) - если окажется , что 80% то использованная методика получения данных неоптимизирована (выбран неудачный вид запроса (запросов) , выборка ведется не по проиндексированным полям), структура таблиц неоптимальна для данного вида запросов. Правда есть еще вид отчетности... сверочный - где требуется честно пересчитать данные и проверить зависимости и найти возможные нестыковки...(возможно вам стоит рассмотреть применения такого рода отчетов- но они не для новичков -для их создания необходимо четкое понимание механизмов взаимодействия подсистем предприятия
- т.е их тяжело создавать а еще тяжелее поддерживать в актуальном состоянии).
-
1. Структура может быть сложной , а количество данных большим...- но если ситуацию анализирует человек -то смысла анализировать рулон бумаги с 500 наименованиями , каждое из которых содержит с полсотни зависимых позиций -нет. Классическое решение вопроса срезка данных по входным параметрам -но полагаю, что вы это знаете- не очень понятно почему это (у вас) не работает.
А что удобнее?
Сразу сформировать дерево и просто крутить его крысой или 500 раз кликнуть (с задрежкой) чтобы увидеть что там внутри?
Если бы человек не анализировал ситуацию, то отчет вообще бы смысла не имел. А о таком отчете почти каждое производственное предприятие мечтает.
Запросы реально долгие. Я же вам про реальную ситуацию говорю. Я вам могу настоящие запросы по этой таблице показать... (1к строк текста SQL обычное дело, а ведь сервак еще транслировать этот запрос должен, потом оптимальный план выбрать и т.д. и т.п.)
2. Странно... Профилируйте запрос (сколько времени из этих 15- 20 секунд приходится на создание выборки datamining) - если окажется , что 80% то использованная методика получения данных неоптимизирована
Нормально там все. Одынэсники обычно оптимальные запросы пишут, т.к. занимаются этим день и ночь ;)
-
DIzer, и кстати можете посчитать сколько времени на одну только пересылку данных тратится в локалке 100мбит...
-
Вот поля реальной таблицы
-
1. Структура может быть сложной , а количество данных большим...- но если ситуацию анализирует человек -то смысла анализировать рулон бумаги с 500 наименованиями , каждое из которых содержит с полсотни зависимых позиций -нет. Классическое решение вопроса срезка данных по входным параметрам -но полагаю, что вы это знаете- не очень понятно почему это (у вас) не работает.
А что удобнее?
Сразу сформировать дерево и просто крутить его крысой или 500 раз кликнуть (с задрежкой) чтобы увидеть что там внутри?
Если бы человек не анализировал ситуацию, то отчет вообще бы смысла не имел. А о таком отчете почти каждое производственное предприятие мечтает.
Запросы реально долгие. Я же вам про реальную ситуацию говорю. Я вам могу настоящие запросы по этой таблице показать... (1к строк текста SQL обычное дело, а ведь сервак еще транслировать этот запрос должен, потом оптимальный план выбрать и т.д. и т.п.)
2. Странно... Профилируйте запрос (сколько времени из этих 15- 20 секунд приходится на создание выборки datamining) - если окажется , что 80% то использованная методика получения данных неоптимизирована
Нормально там все. Одынэсники обычно оптимальные запросы пишут, т.к. занимаются этим день и ночь ;)
1.Вопрос не в том , что лучше - а в том что в большинстве случаев это не имеет смысла.
2. А каким образом он анализирует ? чаще всего - поиск его основывается на знании потенциально более вероятных источников проблемы и "подозрительных" цифр и зависимостей ... в явном и неявном виде - вся эта деятельность алгоритмизируется.
3. Многие мечтают - ;) но есть люди которые их ДЕЛАЮТ (я, например, такие делал -и цена таких отчетов была соответствующая).
4. Если это так, то самое паршивое - существующая структура таблиц и данных неоптимальна для подобных выборок - лечится в лучшем случае добавлением полей в базовые таблицы, созданием дополнительных таблиц (или отображений (views они часто бывают лучше), ну и крайняк - это сверочные отчеты по предприятию (где от Анализа ВСЕХ зависимостей не убежишь ) - комбинация вышеперечисленного возможно с созданием временных структур и соответствующих наборов данных вне БД.
-
2. А каким образом он анализирует ?
А кто его знает? ;D
Сам он вам не расскажет даже под угрозой расстрела. Просто потому, что не умеет облекать в слава свой опыт.
И вам всю предметку изучить тоже не вариант.
Так что вам придется под его дудю плясать, если вы вообще намерены эту задачу выполнить и получить за нее деньги. ;)
Экспертная оценка будет стоить баснословных денег. И мало какое предприятие будет за это платить (даже просто потому что руководство "не шарит")
3. Многие мечтают - ;) но есть люди которые их ДЕЛАЮТ (я, например, такие делал -и цена таких отчетов была соответствующая).
Мы в общем то тоже сделали. ;)
-
Вот поля реальной таблицы
Да.... Погорячился я со 100 байтами :)
-
DIzer, и кстати можете посчитать сколько времени на одну только пересылку данных тратится в локалке 100мбит...
Нафига мне это считать (время пересылки ВСЕХ данных) - НУЖНО считать время пересылки РЕАЛЬНО НЕОБХОДИМОГО набора данных - для этого у меня нет достаточно информации
-
2. А каким образом он анализирует ?
А кто его знает? ;D
Сам он вам не расскажет даже под угрозой расстрела. Просто потому, что не умеет облекать в слава свой опыт.
И вам всю предметку изучить тоже не вариант.
Так что вам придется под его дудю плясать, если вы вообще намерены эту задачу выполнить и получить за нее деньги. ;)
Экспертная оценка будет стоить баснословных денег. И мало какое предприятие будет за это платить (даже просто потому что руководство "не шарит")
3. Многие мечтают - ;) но есть люди которые их ДЕЛАЮТ (я, например, такие делал -и цена таких отчетов была соответствующая).
Мы в общем то тоже сделали. ;)
1. А более вариантов кроме предложенных нема (если он обычный "прошаренный мэнагер").
2. Поэтому - разумно ему предлагать возможные альтернативы (вместо генерации всего набора данных) -такие люди ценятся больше чем тупые исполнители (к ним больше доверия и получают они больше заказов- как интересных, так "халявных").
3. Да приходится - если заказчик оплачивает часы (я так понимаю что вы сидите на "отсосе" - то есть предприятие оплачивает почасовку (закрывает часы)).
4. Поздравляю -одна проблема все ваши построения могут рухнуть как карточный домик - в том случае, если вы восстанавливали алгоритм обработки опираясь только на существующие структуры и зависимости.
-
Я тут не советник, но, по-моему, нужно смотреть в сторону технологии OLAP, online analytical processing.
-
Поэтому - разумно ему предлагать возможные альтернативы (вместо генерации всего набора данных)
Мы так и поступили
... вы сидите на "отсосе" ...
;D ;D ;D У нас это называется - проэкт ;)
4. ... все ваши построения могут рухнуть как карточный домик ...
Мы остановились на максимально простых построениях.
-
Я тут не советник, но, по-моему, нужно смотреть в сторону технологии OLAP, online analytical processing.
Это немного другое.
-
Я тут не советник, но, по-моему, нужно смотреть в сторону технологии OLAP, online analytical processing.
А любая современная система содержит ее поддержку ... но она основана на формировании предварительного набора данных из таблиц исходной БД и отображении срезов по ним - те формируется гипер куб данных , а визуально отображается некоторое его сечение (можно рассматривать как источник целого набора отчетов)- т.е ничего нового не дает.
-
Вот тут можно посмотреть на картинки и прикинуть масштаб реальной задачи :)
http://www.ec-network.ru/index.php?option=com_content&task=view&id=94&Itemid=94 (http://www.ec-network.ru/index.php?option=com_content&task=view&id=94&Itemid=94)
-
Показатели себестоимости образуют иерархию. Под каждый показатель - свой запрос, результаты запросов обрабатываются на клиенте или формируют [временную] таблицу на сервере.
Я не очень понимаю.... Что такое показатель? Как это храниться должно?
Можно подробнее?
Показатель - это то, что выводите в каждой строке отчёта. Поскольку мы говорим о затратах, то каждый вид затрат - это и есть показатель. Чтобы получить данные для расчёта показателя необходимо составить запрос к БД. Сами показатели составляют иерархию. Для рассмотренного ранее примера:
Структура цеховых затрат:
.... 1. Фонд оплаты труда:
.... 1.1. Оплата управленческого персонала;
.... 1.2. Оплата ремонтной службы;
.... 1.3. Оплата уборщиц и подметальщиц;
.... 2. Приобретение оборудования
.... 2.1. Основное технологическое оборудование;
.... 2.2. Вспомогательное оборудование;
.... 2.3. Офисное оборудование и принадлежности;
.... 2.4. Оборудование для пищеблока;
.... 3. Затраты на вспомогательные материалы;
.... 3.1. Затраты на спец. одежду и средства индивидуальной защиты;
.... 3.2. Затраты на протирочные материалы;
.... 3.3. Затраты на смазочные материалы;
.... 3.4. Затраты на ремонтные материалы;
.... 3.4.1. Крепежные изделия;
.... 3.4.2. Подшипники;
.... 3. 4.3. ....
....................
Вот я формирую отчет по затратам на производство паровоза. Как ваш метод будет работать по шагам?
Под каждый из приведённых выше (и прочих) показателей формируется свой запрос. Обходим иерархию показателей, отправляем запросы к БД, формируем строки в таблице или отчёте... Иерархия показателей и есть ничто иное, как структура затрат/себестоимости. По её поводу я Вам настоятельно рекомендую поговорить с экономистами (не с бухгалтерами!). Сами запросы можно хранить в БД, в отдельной таблице, это позволит корректировать запросы при необходимости, без переделки приложений и использовать эти запросы из разных приложений...
-
(если по-хорошему, то начать следовало бы, наверное, с проектирования БД под предметную область)
На структуру исходной таблицы мы мало можем влиять. Она такая какая есть, и оптимизирована для других задач. Мы можем только дополнительные таблицы делать.
... именно поэтому я и сказал про проектирование... То, что у Вас там десятки гигабайт хранятся - косвенное свидетельство того, что БД... спроектирована... не очень корректно. По мере сопровождения такой БД её структура будет пухнуть, пока разработчики не перестанут понимать, что и где хранится.
Можно подкачивать, можно сформировать [временную] таблицу и потом читать из неё.
А как ее сформировать? Что в ней должно быть? Это и интересно :)
Как обычно: пишем на SQL:
CREATE TABLE NEW_TABLE (...);
В ней должны быть значения показателей для каждого вида затрат. Поскольку диапазон дат для каждой записи будет один и тот же, то хранить этот диапазон в каждой записи... нет необходимости. Поэтому в таблице будет два поля: название вида затрат и сумма затрат в данном периоде времени.
2. Циклов в "дереве" быть не может, иначе это не "дерево", а циклический граф. Возможно, имелось ввиду, что на одну вложенную ветку ссылаются две других ветки-владельцы?.. Тогда это не "дерево", а сеть, орграф.
Да. Не может.
Но есть два момента:
1. Пользователь мог допустить ошибку при вводе данных, и случайно получился цикл.
Сделайте проверку на клиенте, но лучше на сервере!.. Не пропускайте такие данные для хранения.
2. Полуфабрикат может пойти на затраты сам на себя (и это не редкость)
Это как?.. Из болта сделали тот же болт?..
Отчет должен конечно корректно эти ситуации обработать. И кроме того нужно бы и пользователю показать где циклы образуются.
Данные в БД должны быть максимально корректные, никакой отчёт не должен править/обрабатывать некорректные данные.
При обнаружении цикла конечно дальнейшее разузлование в данной ветке дерева уже не имеет смысла.
Так и не надо позволять делать циклы при вставке и изменении данных.
Какая СУБД используется?
Что значит дерево запросов?
см. выше.
СУБД - MS SQL Server
Ну, так есть же в ней триггеры... Кривовато сделано, но всё же есть. И хранимые процедуры тоже есть... Кстати, MS SQL неоптимально хранит данные, это тоже одна из причин большого объёма БД.
-
Давайте посчитаем. Вот у меня сейчас перед глазами отчет по одной позиции продукции. В дереве 1342 элемента.
Пусть запрос выполняется 1 секунду.
Имеем 1342 / 60 = 22 минуты
Или я неправильно понял?
-
А я все еще хочу пример исходных данных чтобы таки пощупать оное дерево за… узлы :-)
Да, там как обычно 1С-овцы... наваяли таблиц... "не от большого ума, но от чистого сердца" (с). Они же на всё смотрят через призму бух.учёта. Чисто бухгалтерский подход...
-
:o В этой задаче от бух учета даже запаха нет.
-
Вот тут очень хороший способ (Ctrl+F Маршрут обхода):
http://www.osp.ru/pcworld/2007/03/4199032/ (http://www.osp.ru/pcworld/2007/03/4199032/)
Вы поаккуратнее с Тарасовым, заносит его регулярно... Вон уже и Джо Селко... переплюнуть пробует... :)
-
Давайте посчитаем. Вот у меня сейчас перед глазами отчет по одной позиции продукции. В дереве 1342 элемента.
Пусть запрос выполняется 1 секунду.
Имеем 1342 / 60 = 22 минуты
Или я неправильно понял?
У Вас 1342 вида затрат?.. Если для каждого вида затрат нужно выдернуть свои данные, то... каждый вид затрат будет формировать свой запрос. Получите 1342 вида запросов. Или Вы одним запросом выдерните данные и по зарплате уборщицы и по покупкам подшипников?..
-
:o В этой задаче от бух учета даже запаха нет.
Дело не в задаче, а в структуре БД... (это совсем разные вещи).
-
Давайте посчитаем. Вот у меня сейчас перед глазами отчет по одной позиции продукции. В дереве 1342 элемента.
Пусть запрос выполняется 1 секунду.
Имеем 1342 / 60 = 22 минуты
Или я неправильно понял?
то есть вы хотите сказать, что одна элементарная позиция (болт) - имеет 1342 видов затрат ;) - в тех базах с которыми я имел дело о каждому обьекту требующему учета затрат ставились в соответствие записи из некоторой таблицы , которая ссылалась на справочник организованный приблизительно так же как предложил AlexUs
-
Это затраты на производство вакцины
-
Это затраты на производство вакцины
Да, какая разница... вакцина или подъёмный кран... Поверьте, что суть себестоимости, равно, как и производства (как вида деятельности) не меняется от смены предмета труда.
-
... соответственно агрегация по правильно проиндексированной таблице такого рода дело долей секунды ( даже при 1300 записях на позицию
учета)/
-
другое дело что в некоторых моделях учета для определенных обьектов прежде чем сделать агрегацию необходимо рассчитать эти затраты...
-
DIzer посмотрите личное сообщение :)
alexus, вам тоже пытаюсь послать.
-
Как более наглядно объяснить я не знаю ;)
Но я пример исходных данных конечно подготовлю, чтобы можно было алгоритмы погонять. Пока думаю как это сделать...
И в каком формате...
Есть предложения?
-
Посмотрел, что это -сгруппированный набор данных из исходной таблицы или отчет?
-
Это отчет который требуется получить.
-
Сформирован отчет этим:
http://infostart.ru/public/93020/ (http://infostart.ru/public/93020/)
-
Это отчет который требуется получить.
И вы хотите сказать, что пользователь может визуально проанализировать все эти записи за раз ;)...
...по виду типичный drilldown... причем некоторые статьи затрат формируются в результате анализа операционных документов (не фиксированы)
вопрос - существует ли таблица затрат отдельно?
-
Дело не в задаче, а в структуре БД... (это совсем разные вещи).
А что со структурой не так?
-
И вы хотите сказать, что пользователь может визуально проанализировать все эти записи за раз ;)...
...по виду типичный drilldown... причем некоторые статьи затрат формируются в результате анализа операционных документов (не фиксированы)
вопрос - существует ли таблица затрат отдельно?
Анализирует.... Иначе этот отчет и не нужен был бы.
Там вообще ничего фиксированного нет.
Все данные в одной таблице
-
Сформирован отчет этим:
http://infostart.ru/public/93020/ (http://infostart.ru/public/93020/)
я так понял, что это сторонний инструмент, который делает отчеты из "общих соображений"- т.е . корректно выдающий результаты лишь при правильно настроенной аналитики?
-
И вы хотите сказать, что пользователь может визуально проанализировать все эти записи за раз ;)...
...по виду типичный drilldown... причем некоторые статьи затрат формируются в результате анализа операционных документов (не фиксированы)
вопрос - существует ли таблица затрат отдельно?
Анализирует.... Иначе этот отчет и не нужен был бы.
Там вообще ничего фиксированного нет.
Все данные в одной таблице
Эта таблица формируется отчетом или существует и поддерживается в актуальном состоянии средствами системы(1С)
-
Да нет... Он всегда корректно результаты выдает. (если ошибок в нем нет конечно)
В нем просто куча настроек детализации.
Я его дописывал/оптимизировал для себя и не помню там грубых косяков.
Там довольно деревянно все внутри. С большими объемами он не справляется (память на клиенте кончается)
-
Дело не в ошибках генератора отчетов, наиболее частые косяки возникают при неправильной (либо нестандартной) настройки аналитики..
-
Эта таблица формируется отчетом или существует и поддерживается в актуальном состоянии средствами системы(1С)
Если вы про исходную таблицу, то она накапливает данные в течение месяца. Плюс в конце месяца выполняется расчет себестоимости который формирует в ней кучу записей распределения затрат.
-
Эта таблица формируется отчетом или существует и поддерживается в актуальном состоянии средствами системы(1С)
Если вы про исходную таблицу, то она накапливает данные в течение месяца. Плюс в конце месяца выполняется расчет себестоимости который формирует в ней кучу записей распределения затрат.
Про нее... если я правильно вас понял -то можно считать что время на ее формирования не входит затраты на получение отчета но мне непонятно почему мелкие выборки в правильно проиндексированной супертаблице занимают так много времени?
-
Дело не в ошибках генератора отчетов, наиболее частые косяки возникают при неправильной (либо нестандартной) настройки аналитики..
Не понял.
Вы про какие ошибки? В программе выводящей отчет или в исходных данных?
Какая бы аналитика не была этот отчет выводит ровно то, что содержится в таблице.
-
Но судя по задаче - как ни странно прав Romiras - она допускает следующее решение
взять весь набор данных с сервера - в клиентский (индексируемый) дата сет - а приложение пусть аккуратно разбирается с ним -аналог работы с гиперкубом (OLAP- анализ)
-
Дело не в ошибках генератора отчетов, наиболее частые косяки возникают при неправильной (либо нестандартной) настройки аналитики..
Не понял.
Вы про какие ошибки? В программе выводящей отчет или в исходных данных?
Какая бы аналитика не была этот отчет выводит ровно то, что содержится в таблице.
я про то, что данные в ЭТУ таблицу могут заносится некорректно , например, не полностью в следствии некорректного учета первичных документов (из которых рассчитываются затраты)
-
Про нее... если я правильно вас понял -то можно считать что время на ее формирования не входит затраты на получение отчета но мне непонятно почему мелкие выборки в правильно проиндексированной супертаблице занимают так много времени?
Конечно не входит. Вам таблица уже дана.
Но она в плоском виде на сервере СУБД.
Если в этой таблице выделить самую суть то будет три колонки
[на что затрачено][что затрачено][сумма]
А вам это нужно на клиенте в виде дерева вывести. Чтобы это сделать нужно эту таблицу рекурсивно обойти.
А чтобы ее рекурсивно обойти вам нужно закачать ее на клиента. А на клиенте она в оперативу вся не влезет.
Это трабл.
Но нам нужна ведь не вся таблица. А только то что входит в наше дерево. Мы например сделали отбор по одному виду продукции. Т.е. из 10м строк в разузловании будут учавствовать только 500 например.
Но вы не можете получить одним запросом эти 500 строк, т.к. вам не известна глубина дерева!!!
Это трабл.
Можно запросом получать затраты по каждому полученному элементу дерева. Но запросы тяжелые, и отчет будет формироваться очень долго.
Это трабл.
-
я про то, что данные в ЭТУ таблицу могут заносится некорректно , например, не полностью в следствии некорректного учета первичных документов (из которых рассчитываются затраты)
Так вот отчет для того и нужен в частности. Чтобы выявлять ошибки.
-
Но нам нужна ведь не вся таблица. А только то что входит в наше дерево. Мы например сделали отбор по одному виду продукции. Т.е. из 10м строк в разузловании будут учавствовать только 500 например.
Но вы не можете получить одним запросом эти 500 строк, т.к. вам не известна глубина дерева!!!
Почему- разве в таблице не хранится идентификатор обьекта учета? если нет, то нужно вставлять... и делать по нему индекс
-
я про то, что данные в ЭТУ таблицу могут заносится некорректно , например, не полностью в следствии некорректного учета первичных документов (из которых рассчитываются затраты)
Так вот отчет для того и нужен в частности. Чтобы выявлять ошибки.
а каким образом вы по нему сможете выявить ошибку такого рода?
-
Вот пример исходных данных, и дерева из них построенного.
-
Почему- разве в таблице не хранится идентификатор обьекта учета? если нет, то нужно вставлять... и делать по нему индекс
Более того, индекс должен быть по любому категорийному полю - в идеале набор данных импортируемый из БД должет состоять из таблицы видов затрат, таблицы наименований обьектов учета - они должны быть маленькими - и супер таблицы с данными...
-
Блин у стола лак забыл разузловать.
Но я думаю суть понятна. :)
-
... в этом случае вы сможете делать очень эффективные срезы данных , а на них в свою очередь делать деревья (точнее представлять данные содержащиеся в срезах в виде древовидной структуры) или дополнительную фильтрацию
...
... да я понял
-
Блин у стола лак забыл разузловать.
Но я думаю суть понятна. :)
Да, понятно. Результирующая структура данных сильно смахивает на кучу.
-
DIzer посмотрите личное сообщение :)
alexus, вам тоже пытаюсь послать.
Посмотрел. Обычный "бухгалтерский отчёт" по затратам. К задачам управления предприятием он имеет оооочень косвенное отношение. Такие отчёты обычно создаются, когда нет нормального учёта и хоть какую-то информацию, хоть каким-то способом... пытаются вытянуть из бухгалтерии. Для этого в бухгалтерию начинают сливать огромное количество самой разной информации, например данный из КД (конструкторской документации). По всей видимости, это Ваш случай... термин "разузлование", которым Вы пользуйтесь, - взят именно оттуда... из КД.
Не подумайте, что я критикую данное решение (хотя, конечно, приветствовать я его не могу), но... нелепый отчёт порождает нелепые требования... к ресурсам. Всё нормально.
Почему это "бухгалтерский" отчёт?.. Поясню примером... Вот конструктор начертил стол. У стола четыре ножки. Очевидно столько ножек и попадёт в данный отчёт. Но технолог скажет, что это не так, на стол расходуется 4,12 ножки... и он будет прав, потому что на каждые 100 столов будет израсходовано 412 ножек (12 штук - это бракованные ножки, которые должны быть списаны, но они тоже входят в затраты на приобретение/изготовление). Но и это ещё не всё. Ножки покупались по цене 3 р. 23 коп., но в производство они идут по цене 4 р. 56 коп. Поскольку вторая цена (она называется ценой заготовления или "внутренней" ценой) включает в себя затраты на транспортировку, погрузочно-разгрузочные работы, стоимость хранения и пр. Но в накладной от поставщика, есть только первая цена (3 р. 23 коп.). Работаем себе в убыток?.. Или всю эту информацию (и множество другой) сваливаем в бухгалтерию, а потом включаем в отчёт?.. И кому будет нужен отчёт длинной... в несколько километров?.. Проще заново сосчитать/прикинуть какой-то показатель, чем найти его в этом отчёте.
-
Дело не в задаче, а в структуре БД... (это совсем разные вещи).
А что со структурой не так?
Эта структура отражает представление бухгалтера о производстве. Но представления бухгалтера о производстве и реальное производство - "две большие разницы"... (при этом информационная модель любого производства существенно проще и полнее, чем представления бухгалтера).
Афоризм Козьмы Пруткова № 66: " Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий".
-
Анализирует.... Иначе этот отчет и не нужен был бы.
Там вообще ничего фиксированного нет.
Все данные в одной таблице
Так об этом же и спрашивали... сведены уже (до начала формирования отчёта) данные в одну таблицу или нет... Я Вас понял так, что данные не сведены... поэтому и говорил об иерархии показателей/запросов. Если данные уже сведены, значит и структура показателей уже определена (иначе было бы непонятно, какие данные в таблице). Но если данные уже сведены в таблицу, то... что мешает вывести их в виде отчёта?..
-
Эта таблица формируется отчетом или существует и поддерживается в актуальном состоянии средствами системы(1С)
Если вы про исходную таблицу, то она накапливает данные в течение месяца. Плюс в конце месяца выполняется расчет себестоимости который формирует в ней кучу записей распределения затрат.
"Распределение затрат" делается до формирования отчёта?
-
Но судя по задаче - как ни странно прав Romiras - она допускает следующее решение
взять весь набор данных с сервера - в клиентский (индексируемый) дата сет - а приложение пусть аккуратно разбирается с ним -аналог работы с гиперкубом (OLAP- анализ)
Да не нужен здесь OLAP поскольку... нет никакого анализа... а минус - дорогое это решение (и по деньгам, и по времени), да и поддерживать куб в согласованном состоянии, тоже не всегда элементарно.
-
Про нее... если я правильно вас понял -то можно считать что время на ее формирования не входит затраты на получение отчета но мне непонятно почему мелкие выборки в правильно проиндексированной супертаблице занимают так много времени?
Конечно не входит. Вам таблица уже дана.
Но она в плоском виде на сервере СУБД.
Если в этой таблице выделить самую суть то будет три колонки
[на что затрачено][что затрачено][сумма]
А вам это нужно на клиенте в виде дерева вывести. Чтобы это сделать нужно эту таблицу рекурсивно обойти.
А чтобы ее рекурсивно обойти вам нужно закачать ее на клиента. А на клиенте она в оперативу вся не влезет.
Это трабл.
Но нам нужна ведь не вся таблица. А только то что входит в наше дерево. Мы например сделали отбор по одному виду продукции. Т.е. из 10м строк в разузловании будут учавствовать только 500 например.
Но вы не можете получить одним запросом эти 500 строк, т.к. вам не известна глубина дерева!!!
Это трабл.
Можно запросом получать затраты по каждому полученному элементу дерева. Но запросы тяжелые, и отчет будет формироваться очень долго.
Это трабл.
Ничего непонятно...
Предположим, что таблица имеет примерно такую структуру:
1. Показатель; (первичный ключ)
2. Ссылка на показатель верхнего уровня; (внешний ключ, может быть null для корневых узлов)
3. Единицы измерения;
4. Значение показателя в натуральном выражении (объём/количество);
5. Значение показателя в денежном выражении.
Примечание, если одна подветка иерархии входит в несколько веток, то есть, записи таблицы ссылаются на другие записи той
-
Предыдущее сообщение было отправлено неоконченным, простите.
Про нее... если я правильно вас понял -то можно считать что время на ее формирования не входит затраты на получение отчета но мне непонятно почему мелкие выборки в правильно проиндексированной супертаблице занимают так много времени?
Конечно не входит. Вам таблица уже дана.
Но она в плоском виде на сервере СУБД.
Если в этой таблице выделить самую суть то будет три колонки
[на что затрачено][что затрачено][сумма]
А вам это нужно на клиенте в виде дерева вывести. Чтобы это сделать нужно эту таблицу рекурсивно обойти.
А чтобы ее рекурсивно обойти вам нужно закачать ее на клиента. А на клиенте она в оперативу вся не влезет.
Это трабл.
Но нам нужна ведь не вся таблица. А только то что входит в наше дерево. Мы например сделали отбор по одному виду продукции. Т.е. из 10м строк в разузловании будут учавствовать только 500 например.
Но вы не можете получить одним запросом эти 500 строк, т.к. вам не известна глубина дерева!!!
Это трабл.
Можно запросом получать затраты по каждому полученному элементу дерева. Но запросы тяжелые, и отчет будет формироваться очень долго.
Это трабл.
Ничего непонятно...
Предположим, что таблица имеет примерно такую структуру:
1. Показатель; (первичный ключ) [INDICATOR];
2. Ссылка на показатель верхнего уровня (внешний ключ, может быть null для корневых узлов) [OWNER_INDICATOR];
3. Единицы измерения [UNIT];
4. Значение показателя в натуральном выражении (объём/количество) [VAL_NATURAL];
5. Значение показателя в денежном выражении [VAL_CURRENCY].
Примечания:
А) если одна ветка иерархии входит в несколько веток, то есть, записи таблицы ссылаются на другие записи той же таблицы в отношении многие-ко-многим, то нужна ещё таблица для ссылок;
Б) более оптимальное (правильное) решение состоит в том, что структура показателей хранится отдельно от значений показателей.
При данной структуре таблицы надо иметь всего один параметризуемый запрос, чтобы вывести нужный показатель:
SELECT "INDICATOR", "UNIT", "VAL_NATURAL", "VAL_CURRENCY" FROM "MY_TABLE" WHERE "OWNER_INDICATOR" = :OIND;Когда пользователь "щёлкает" на каком-то показателе, подставляем его идентификатор в запрос, получаем данные и выводим на экран. Происходит это очень быстро (как правило, миллисекунды для тысяч записей), поскольку по внешнему ключу [по умолчанию] создаётся индекс.
-
я про то, что данные в ЭТУ таблицу могут заносится некорректно , например, не полностью в следствии некорректного учета первичных документов (из которых рассчитываются затраты)
Так вот отчет для того и нужен в частности. Чтобы выявлять ошибки.
Хм?.. Неожиданно... А не дорого обходится такое решение? Например, если ошибку не выявили, а результаты утвердили (списали в затраты, например, на порядок больше, чем есть на самом деле). Мне кажется, что мухи (баги) должны быть отдельно от котлет (отчётов)... хотя "на вкус и цвет"...
-
Вот пример исходных данных, и дерева из них построенного.
Хе...хе... в машиностроении/судостроении/самолётостроении... особенно интересно посмотреть на разузлование. И попытку построить такого рода отчёты... Тогда сразу приходит понимание того, что делать надо, а что нет... Возможно и фармацевты к этому придут когда-нибудь... например, внедрив очередные "нано-технологии". :)
-
Но судя по задаче - как ни странно прав Romiras - она допускает следующее решение
взять весь набор данных с сервера - в клиентский (индексируемый) дата сет - а приложение пусть аккуратно разбирается с ним -аналог работы с гиперкубом (OLAP- анализ)
Да не нужен здесь OLAP поскольку... нет никакого анализа... а минус - дорогое это решение (и по деньгам, и по времени), да и поддерживать куб в согласованном состоянии, тоже не всегда элементарно.
Я сказал, что ДОПУСКАЕТ = именно по тому, что работа ведется после того , как внешней процедурой процедурой по первичке будет произведен перерасчет себестоимости.. а из этого следует, что работа такого рода отчетами периодическая - и производится в конце определенного интервала времени (иначе себестоимость будет иметь выбросы), а значит требование к актуализации данных минимальны - допустимо, например , раз в месяц тратить 20 минут на получение данных, чтобы работать с ними за доли секунды
-
Хм?.. Неожиданно... А не дорого обходится такое решение? Например, если ошибку не выявили, а результаты утвердили (списали в затраты, например, на порядок больше, чем есть на самом деле). Мне кажется, что мухи (баги) должны быть отдельно от котлет (отчётов)... хотя "на вкус и цвет"...
Повторяюсь ,проблема в том, что по данным отчета этого отчета ошибку не выявишь - ибо она входит в данные таблицы -для ее выявления нужно ЧЕСТНО пересчитать себестоимость по первичке и сравнить с этой таблицей
-
Да не нужен здесь OLAP поскольку... нет никакого анализа... а минус - дорогое это решение (и по деньгам, и по времени), да и поддерживать куб в согласованном состоянии, тоже не всегда элементарно.
Я сказал, что ДОПУСКАЕТ = именно по тому, что работа ведется после того , как внешней процедурой процедурой по первичке будет произведен перерасчет себестоимости.. а из этого следует, что работа такого рода отчетами периодическая - и производится в конце определенного интервала времени (иначе себестоимость будет иметь выбросы), а значит требование к актуализации данных минимальны - допустимо, например , раз в месяц тратить 20 минут на получение данных, чтобы работать с ними за доли секунды
Допускает... конечно. Только в жизни не всё так бывает. Получат отчёт, а потом начинают задним числом править. В кубе автоматически эти правки не отражаются... то есть, исходные данные поменяли, а результат всё тот же... Начинают искать виноватого...
С другой стороны, решение всё равно не очень удачное... Эту "кашу" куском дорогого масла хуже не сделать... :)
-
А по смыслу - этот отчет , обычный Олап гиперкуб. А медленно он делается - потому, что исходные данные денормализованы + неудачный первичный ключ -это приводит к неоправданно большим затратам при транспортировки данных по сетке и трудности в эффективном построении сечения гиперкуба (разумеется если нет грубейших ошибок , вроде Select * from...) .
-
Хм?.. Неожиданно... А не дорого обходится такое решение? Например, если ошибку не выявили, а результаты утвердили (списали в затраты, например, на порядок больше, чем есть на самом деле). Мне кажется, что мухи (баги) должны быть отдельно от котлет (отчётов)... хотя "на вкус и цвет"...
Повторяюсь ,проблема в том, что по данным отчета этого отчета ошибку не выявишь - ибо она входит в данные таблицы -для ее выявления нужно ЧЕСТНО пересчитать себестоимость по первичке и сравнить с этой таблицей
Вы не внимательно прочитали... Я же не Вам отвечал... Да, и ошибки они разные бывают, бывают ошибки в первичных документах, бывают в запросах, бывают в расчётах... а бывают и в постановке задачи.
-
Допускает... конечно. Только в жизни не всё так бывает. Получат отчёт, а потом начинают задним числом править. В кубе автоматически эти правки не отражаются... то есть, исходные данные поменяли, а результат всё тот же... Начинают искать виноватого...
С другой стороны, решение всё равно не очень удачное... Эту "кашу" куском дорогого масла хуже не сделать... :)
Повторяюсь, для СВЕРОЧНЫХ целей этот отчет бессмыслен -но вообще говоря сверка НЕОБХОДИМА именно потому что в жизни все так хорошо не бывает...
-
А по смыслу - этот отчет , обычный Олап гиперкуб. А медленно он делается - потому, что исходные данные денормализованы + неудачный первичный ключ -это приводит к неоправданно большим затратам при транспортировки данных по сетке и трудности в эффективном построении сечения гиперкуба (разумеется если нет грубейших ошибок , вроде Select * from...) .
Так я ещё в самом первом своём сообщении намекнул на проблемы в проектировании...
И если копнуть глубже, то OLAP... это следствие неправильного способа изоляций транзакций В СУБД (при условии правильного проектирования). Почему возникла потребность в OLAP? Потому что аналитические транзакции:
1. Работают медленно (перелопачивают большой объём информации);
2. Требуют высоких уровней изолированности, чтобы анализируемые данные не менялись во время работы транзакции (как минимум repeatable read).
Как следствие, блокировочные СУБД просто "встают колом" и никто не может достучаться до БД. Чтобы этого не происходило, данные сливают в OLAP и там анализируют. Если СУБД поддерживает версионность, то потребность в OLAP значительно снижается. Хотя нормальных версионных серверов просто нет.
-
Допускает... конечно. Только в жизни не всё так бывает. Получат отчёт, а потом начинают задним числом править. В кубе автоматически эти правки не отражаются... то есть, исходные данные поменяли, а результат всё тот же... Начинают искать виноватого...
С другой стороны, решение всё равно не очень удачное... Эту "кашу" куском дорогого масла хуже не сделать... :)
Повторяюсь, для СВЕРОЧНЫХ целей
Раньше речь шла просто об ошибках... которые бывают разные...
-
Да не нужен здесь OLAP поскольку... нет никакого анализа... а минус - дорогое это решение (и по деньгам, и по времени), да и поддерживать куб в согласованном состоянии, тоже не всегда элементарно.
Я сказал, что ДОПУСКАЕТ = именно по тому, что работа ведется после того , как внешней процедурой процедурой по первичке будет произведен перерасчет себестоимости.. а из этого следует, что работа такого рода отчетами периодическая - и производится в конце определенного интервала времени (иначе себестоимость будет иметь выбросы), а значит требование к актуализации данных минимальны - допустимо, например , раз в месяц тратить 20 минут на получение данных, чтобы работать с ними за доли секунды
И если копнуть глубже, то OLAP... это следствие неправильного способа изоляций транзакций В СУБД (при условии правильного проектирования). Почему возникла потребность в OLAP? Потому что аналитические транзакции:
1. Работают медленно (перелопачивают большой объём информации);
2. Требуют высоких уровней изолированности, чтобы анализируемые данные не менялись во время работы транзакции (как минимум repeatable read).
Как следствие, блокировочные СУБД просто "встают колом" и никто не может достучаться до БД. Чтобы этого не происходило, данные сливают в OLAP и там анализируют. Если СУБД поддерживает версионность, то потребность в OLAP значительно снижается. Хотя нормальных версионных серверов просто нет.
1. На деле оказалось - что они ничего не проектируют - просто в тупую работают с неудачно сформированными (не ими !!!) данными.
2. Олап это прежде всего следствие отсутствия релевантных моделей анализа - и цель его - помощь в формирования оных.
3. А я еще не видел универсальные решения спроектированный без bottlenecks - в условиях когда меняются модели анализа.
4. Лично я работал в основном с версионниками.. но там есть свои заморочки.. база пухнет как на дрожжах, дополнительные усилия на логгирование (если есть необходимость в многоуровневых откатах)...
-
Предположим, что таблица имеет примерно такую структуру:
1. Показатель; (первичный ключ) [INDICATOR];
2. Ссылка на показатель верхнего уровня (внешний ключ, может быть null для корневых узлов) [OWNER_INDICATOR];
3. Единицы измерения [UNIT];
4. Значение показателя в натуральном выражении (объём/количество) [VAL_NATURAL];
5. Значение показателя в денежном выражении [VAL_CURRENCY].
Примечания:
А) если одна ветка иерархии входит в несколько веток, то есть, записи таблицы ссылаются на другие записи той же таблицы в отношении многие-ко-многим, то нужна ещё таблица для ссылок;
Б) более оптимальное (правильное) решение состоит в том, что структура показателей хранится отдельно от значений показателей.
При данной структуре таблицы надо иметь всего один параметризуемый запрос, чтобы вывести нужный показатель:
SELECT "INDICATOR", "UNIT", "VAL_NATURAL", "VAL_CURRENCY" FROM "MY_TABLE" WHERE "OWNER_INDICATOR" = :OIND;Когда пользователь "щёлкает" на каком-то показателе, подставляем его идентификатор в запрос, получаем данные и выводим на экран. Происходит это очень быстро (как правило, миллисекунды для тысяч записей), поскольку по внешнему ключу [по умолчанию] создаётся индекс.
Можно более подробно про отдельную структуру показателей? Какая у нее таблица? Я так понимаю, можно выполнить до формирования отчета преобразование вышеописанной таблицы в 2 другие. Но не понял, как можно будет связать таблицу структуры и таблицу показателей?
-
1. На деле оказалось - что они ничего не проектируют - просто в тупую работают с неудачно сформированными (не ими !!!) данными.
Я уже говорил: Эта таблица для других целей оптимизирована. (и вполне удачно для своих целей) Структуру ее мы менять не можем, т.к. на нее завязано много тысяч строк кода.
Таблица такая какая есть, и точка. Нужно очень много времени, чтобы объяснить почему у нее такая структура.
Какой смысл рассуждать о ее структуре?
-
Можно более подробно про отдельную структуру показателей?
Ага. Я вот тоже секрет alexus'а понять не могу. :)
-
1. На деле оказалось - что они ничего не проектируют - просто в тупую работают с неудачно сформированными (не ими !!!) данными.
Об этом и речь...
2. Олап это прежде всего следствие отсутствия релевантных моделей анализа - и цель его - помощь в формирования оных.
То есть, всё тот же недостаток проектирования, неверно сформированы модели предметной области.
3. А я еще не видел универсальные решения спроектированный без bottlenecks - в условиях когда меняются модели анализа.
А с чего им меняться?.. Аналитических плоскостей не так уж много...
4. Лично я работал в основном с версионниками.. но там есть свои заморочки.. база пухнет как на дрожжах, дополнительные усилия на логгирование (если есть необходимость в многоуровневых откатах)...
Речь видимо про Firebird или Interbase... С чего бы у версионных СУБД база "пухла"?.. Старые версии не хранятся дольше, чем к ним есть интерес. Отсутствие журнала - это не проблема версионных СУБД, а конкретной реализации (всё тот же Firebird). Для откатов (многоуровневых, в том числе) можно использовать save points, но, конечно, в рамках текущей транзакции. Если выходить за пределы транзакции, то нужна поддержка журнала, разработчикам Firebird об этом говорят лет 20... может быть и больше (я про то, что за время моей работы с этой СУБД знаю).
-
1. На деле оказалось - что они ничего не проектируют - просто в тупую работают с неудачно сформированными (не ими !!!) данными.
Я уже говорил: Эта таблица для других целей оптимизирована. (и вполне удачно для своих целей) Структуру ее мы менять не можем, т.к. на нее завязано много тысяч строк кода.
Таблица такая какая есть, и точка. Нужно очень много времени, чтобы объяснить почему у нее такая структура.
Какой смысл рассуждать о ее структуре?
Вы посмотрите на свои начальные сообщения - неочевидно даже существование подобной структуры.... и тем более не понятно нафиг она нужна в денормализованном виде.
Но в одном вы правы - необходимо разбираться с тем, что есть...
-
Предположим, что таблица имеет примерно такую структуру:
1. Показатель; (первичный ключ) [INDICATOR];
2. Ссылка на показатель верхнего уровня (внешний ключ, может быть null для корневых узлов) [OWNER_INDICATOR];
3. Единицы измерения [UNIT];
4. Значение показателя в натуральном выражении (объём/количество) [VAL_NATURAL];
5. Значение показателя в денежном выражении [VAL_CURRENCY].
Примечания:
А) если одна ветка иерархии входит в несколько веток, то есть, записи таблицы ссылаются на другие записи той же таблицы в отношении многие-ко-многим, то нужна ещё таблица для ссылок;
Б) более оптимальное (правильное) решение состоит в том, что структура показателей хранится отдельно от значений показателей.
При данной структуре таблицы надо иметь всего один параметризуемый запрос, чтобы вывести нужный показатель:
SELECT "INDICATOR", "UNIT", "VAL_NATURAL", "VAL_CURRENCY" FROM "MY_TABLE" WHERE "OWNER_INDICATOR" = :OIND;Когда пользователь "щёлкает" на каком-то показателе, подставляем его идентификатор в запрос, получаем данные и выводим на экран. Происходит это очень быстро (как правило, миллисекунды для тысяч записей), поскольку по внешнему ключу [по умолчанию] создаётся индекс.
Можно более подробно про отдельную структуру показателей? Какая у нее таблица? Я так понимаю, можно выполнить до формирования отчета преобразование вышеописанной таблицы в 2 другие. Но не понял, как можно будет связать таблицу структуры и таблицу показателей?
Структура показателей статична, меняется (как правило, расширяется) очень редко (если, конечно, её разрабатывали толковые экономисты). Структура этой таблицы очевидна из предыдущего сообщения:
1. Показатель; (первичный ключ) [INDICATOR];
2. Ссылка на показатель верхнего уровня (внешний ключ, может быть null для корневых узлов) [OWNER_INDICATOR];
3. Единицы измерения [UNIT];
Таблица значений тоже очевидна:
1. Показатель; (первичный ключ, ссылка на таблицу структуры показателей) [INDICATOR];
2. Значение показателя в натуральном выражении (объём/количество) [VAL_NATURAL];
3. Цена за единицу [PRICE];
4. Значение показателя в денежном выражении [VAL_CURRENCY] (вычисляемое/необязательное поле).
Примечание:
А) связь между таблицами один-к-одному, но можно расширить первичный ключ таблицы значений, например, идентификатором отчёта, тогда в ней можно хранить разные (например, по времени) отчёты;
Б) структуру показателей тоже можно расширить, добавив в первичный ключ поле "тип отчёта", тогда в этой таблице можно хранить разные отчёты, с разными показателями;
В) чтобы показатели выводились в определённом порядке можно добавить поле "вес показателя" в таблице показателей;
Г) чтобы была возможность отключать показатели (не удаляя их, можно предусмотреть логическое поле "активный" в таблице показателей;
Д) можно добавить поддержку версий отчётов;
Е) можно хранить запросы для показателей...
и т.д. и т.п.
-
1. На деле оказалось - что они ничего не проектируют - просто в тупую работают с неудачно сформированными (не ими !!!) данными.
Об этом и речь...
2. Олап это прежде всего следствие отсутствия релевантных моделей анализа - и цель его - помощь в формирования оных.
То есть, всё тот же недостаток проектирования, неверно сформированы модели предметной области.
3. А я еще не видел универсальные решения спроектированный без bottlenecks - в условиях когда меняются модели анализа.
А с чего им меняться?.. Аналитических плоскостей не так уж много...
4. Лично я работал в основном с версионниками.. но там есть свои заморочки.. база пухнет как на дрожжах, дополнительные усилия на логгирование (если есть необходимость в многоуровневых откатах)...
Речь видимо про Firebird или Interbase... С чего бы у версионных СУБД база "пухла"?.. Старые версии не хранятся дольше, чем к ним есть интерес. Отсутствие журнала - это не проблема версионных СУБД, а конкретной реализации (всё тот же Firebird). Для откатов (многоуровневых, в том числе) можно использовать save points, но, конечно, в рамках текущей транзакции. Если выходить за пределы транзакции, то нужна поддержка журнала, разработчикам Firebird об этом говорят лет 20... может быть и больше (я про то, что за время моей работы с этой СУБД знаю).
1. См. выше
2. В реале обычно базу не проектируют с нуля . а насаживают на некоторую базовую модель... и это в краткосрочной перспективе дешевле, однозначно - требует меньших затрат на проектирование, обучение персонала.. и т.д. и т.п.
3. Плоскостей (входных переменных) действительно не очень много - так же как и рассчитываемых по ним параметров индикаторов- но алгоритмов их учета наколбасить можно предостаточно)..
4. Да , на практике вариантов не было - с 4 пунктом согласен полностью
-
1. На деле оказалось - что они ничего не проектируют - просто в тупую работают с неудачно сформированными (не ими !!!) данными.
Я уже говорил: Эта таблица для других целей оптимизирована. (и вполне удачно для своих целей) Структуру ее мы менять не можем, т.к. на нее завязано много тысяч строк кода.
Таблица такая какая есть, и точка. Нужно очень много времени, чтобы объяснить почему у нее такая структура.
Какой смысл рассуждать о ее структуре?
Хм?.. Может быть и нет смысла... но не поэтому ли возникли у Вас вопросы? Менять таблицу никто не призывает, но можно
1. поучиться на этом примере, как делать не надо;
2. более основательно подойти к созданию новых таблиц...
То есть, добавлять таблицы не на потребу, а исходя из сути... предметной области (хотя докапываться до сути... любителей мало...).
-
Структура показателей статична, меняется (как правило, расширяется) очень редко (если, конечно, её разрабатывали толковые экономисты).
alexus, вы какую-то свою задачу решаете.
Нету в реальности никакой статичной структуры показателей.
-
3. Плоскостей (входных переменных) действительно не очень много - так же как и рассчитываемых по ним параметров индикаторов- но алгоритмов их учета наколбасить можно предостаточно)..
Нет... Повторю, аналитических плоскостей, равно как и показателей, равно как и возможных решений... совсем немного. Это в бухгалтерии аналитика восходит к традиционному: "А давайте ещё так попробуем...". "Сон разума, рождает чудовищ" (с) (испанская пословица)...
-
Структура показателей статична, меняется (как правило, расширяется) очень редко (если, конечно, её разрабатывали толковые экономисты).
alexus, вы какую-то свою задачу решаете.
Нету в реальности никакой статичной структуры показателей.
Примерно также сказала лиса из басни Эзопа... не сумев достать виноград. Хотя я понимаю, что в 1С, возможно, так и есть.
-
В 1С вот так:
http://www.ec-network.ru/index.php?option=com_content&task=category§ionid=4&id=32&Itemid=94 (http://www.ec-network.ru/index.php?option=com_content&task=category§ionid=4&id=32&Itemid=94)
Цитата:
"Если бы все было так просто, уже давно появилась бы литература, исчерпывающим образом раскрывающая все вопросы данной темы. Так что, придется немного потерпеть."
-
Зря я заговорил о затратах.
Надо было просто дать абстрактную таблицу:
[родитель][подчиненный]
Вместо обсуждения задачи получилось обсуждение системы 1С >:(
-
3. Плоскостей (входных переменных) действительно не очень много - так же как и рассчитываемых по ним параметров индикаторов- но алгоритмов их учета наколбасить можно предостаточно)..
Нет... Повторю, аналитических плоскостей, равно как и показателей, равно как и возможных решений... совсем немного. Это в бухгалтерии аналитика восходит к традиционному: "А давайте ещё так попробуем...". "Сон разума, рождает чудовищ" (с) (испанская пословица)...
:) :) Как скажете - в конце концов, всегда есть вероятность, что мы говорим о различных вещах... с другой стороны - с этой сферой деятельности я завязал лет 7 назад -так что вполне могу быть не в курсе последних веяний- да и та же 1с ка развивается... а еще до в 6.6 это было непотребство рассчитанное лишь на учет в конторах однодневках бешеных 90-х
-
Обсуждать что-то кроме самой задачи больше не буду. Надоело.
-
В 1С вот так:
http://www.ec-network.ru/index.php?option=com_content&task=category§ionid=4&id=32&Itemid=94 (http://www.ec-network.ru/index.php?option=com_content&task=category§ionid=4&id=32&Itemid=94)
Цитата:
"Если бы все было так просто, уже давно появилась бы литература, исчерпывающим образом раскрывающая все вопросы данной темы. Так что, придется немного потерпеть."
Это "немного" растянется... на всю жизнь. Литература тут даром не нужна, можно обойтись собственным "серым веществом".
Суть в том, что для Вас показатели - это буковки и цифирьки... А Вы попробуйте поставить себя на место руководителя... посмотреть на свою задачу его глазами...
- Брак 18%... Это хорошо или плохо? Сколько было брака в прошлом квартале?
- А в прошлом квартале мы это показатель не считали...
- Тьфу... А какие причины брака?
- А этих показателей у нас нет, только общий итог?
- Тьфу... А какой износ основного оборудования?
- Три года назад был 64%.
- А сейчас?
- А сейчас мы это показатель не считаем...
- Тьфу... А у конкурентов, какой брак?
- В нашей системе этой информации нет...
- Так что же есть в вашем ... отчёте! На кой ляд он мне сдался!.. Проще самому пройти по производству... разгильдяи...
(разбавьте этот диалог матом, получите кальку типичного разговора в кабинете директора с... адептами 1С-идеологии)
-
Литература тут даром не нужна, можно обойтись собственным "серым веществом".
Неужели? На западе в течении 100 лет теорию управления затратами развивали...
-
Зря я заговорил о затратах.
Надо было просто дать абстрактную таблицу:
[родитель][подчиненный]
Вместо обсуждения задачи получилось обсуждение системы 1С >:(
Давайте считать... для эффективных манипуляций
супер таблица ДОЛЖНА иметь как минимум три целочисленных поля (по которым клиентом строится сечение гиперкуба)
id _P1 ,id_P2, id _obj - первые два- ссылки на справочники категорий (они образуют дерево), последняя на название обьекта остальные поля - специфика отчета... например ,стоимость позиции в рублях
к этой таблице должен прилагаться выход на справочник категорий id _P1 ,id_P2, Name_P и обьектов учета id_obj, name_obj
- вопрос ? где приводить ее к стандартному виду - на стороне сервера, или на стороне клиента
-
точнее не на стороне клиента - а при пересылки данных клиенту
-
3. Плоскостей (входных переменных) действительно не очень много - так же как и рассчитываемых по ним параметров индикаторов- но алгоритмов их учета наколбасить можно предостаточно)..
Нет... Повторю, аналитических плоскостей, равно как и показателей, равно как и возможных решений... совсем немного. Это в бухгалтерии аналитика восходит к традиционному: "А давайте ещё так попробуем...". "Сон разума, рождает чудовищ" (с) (испанская пословица)...
:) :) Как скажете - в конце концов, всегда есть вероятность, что мы говорим о различных вещах... с другой стороны - с этой сферой деятельности я завязал лет 7 назад -так что вполне могу быть не в курсе последних веяний- да и та же 1с ка развивается... а еще до в 6.6 это было непотребство рассчитанное лишь на учет в конторах однодневках бешеных 90-х
Ну, для примера... Любое/ая подразделение/подсистема предприятия основана на 3-х ключевых элементах. Возьму для примера сбыт (можно и производство, но писать больше... а лень).
Треугольник сбыта:
вершины: товар/продукция, клиенты, деньги;
ребра: товар-деньги (прейскуранты), деньги-клиенты (оплаты), товар-клиенты (заявки, рекламации);
В центре треугольника точка, которая смыкается с тремя вершинами, - это основные документы проходящие через сбыт:
1. Заказ (клиент, товар, цена);
2. Счет (клиент, товар, цена);
3. Накладная и счёт фактура (клиент, товар, цена);
4. Товарная накладная (клиент, товар, цена);
5. Возврат товара (клиент, товар, цена);
6. Любые другие документы...
Можно расширять любые из элементов (клиент, товар, деньги), вводить категории и группы, фиксировать те или иные контакты... сути сбыта это не изменит, и аналитические плоскости будут всегда определяться этими ключевыми элементами... То есть, всегда работу сбыта будут анализировать
1. по клиентам (какие клиенты или группы клиентов сколько товаров закупают, сумма товаров, по каким товарам);
2. по продукции (какая продукция наиболее ликвидна, какая продукция наиболее доходна/рентабельна);
3. по деньгам (какие формы оплаты предпочитают те или иные клиенты/группы клиентов [для промышленных предприятий не очень актуально... пока денег в стране хватает], какие отсрочки платежей наиболее эффективны для тех или иных групп клиентов, для тех или иных категорий товаров).
Ну, и что ещё принципиально иного можно добавить к этому?..
-
2 DIzer
А можете наполнить вашу таблицу данными для примера?
Не очень понятно о чем речь :)
-
Зря я заговорил о затратах.
Надо было просто дать абстрактную таблицу:
[родитель][подчиненный]
Вместо обсуждения задачи получилось обсуждение системы 1С >:(
НЕТ не зря.
-
Обсуждать что-то кроме самой задачи больше не буду. Надоело.
Аналогично - выцерапывать по крохам информацию необходимую для решения задачи - на фиг, я за это деньги не получаю..
-
2 DIzer
Разговор, который тут идет, пока к задаче вообще отношения не имеет.
Задача - это первое сообщение.
По существу задачу только Сергей Губанов решал
-
2 DIzer
Разговор, который тут идет, пока к задаче вообще отношения не имеет.
Задача - это первое сообщение.
По существу задачу только Сергей Губанов решал
Жаль, что я сразу не сообразил, что решение сводилось к подсчёту байтиков... Простите, что влез со своими рассуждениями...
-
2 DIzer
Разговор, который тут идет, пока к задаче вообще отношения не имеет.
Задача - это первое сообщение.
По существу задачу только Сергей Губанов решал
Жаль, что я сразу не сообразил, что решение сводилось к подсчёту байтиков... Простите, что влез со своими рассуждениями...
;) А кто бы сообразил..мдь "разузловка"..."распальцовка"..
-
Сергей предложил минимизировать таблицу так, чтобы она целиком поместилась в оперативную память. Т.е. снял первое ограничение из озвученных мной. И тем самым решил поставленную задачу.
-
.."распальцовка"..
Это в мой огород камень? :)
-
p.p.s Тут не очень важны конкретные циферы. Важно лишь понимать, что на клиента это все закачивать нет возможности, т.к. элементарно не хватит памяти. Т.е. выгребсти всю таблицу одним запросом и обойти ее рекурсией не прокатит... Получать запросом подчиненные записи на каждый элемент дерева очень дорого. Плюс если в таблице зацикливание, нам его нужно как-то обойти.
-
.."распальцовка"..
Это в мой огород камень? :)
Конечно нет - вместо того чтобы сразу сказать что речь идет о различных представлениях данных из ОДНОЙ таблицы и дать ее структуру - вести речь о затратах... разузловке.. разхреновке.. -виноват исключительно я ;D что не понял этого сразу(види те ли стал интересоваться -а почему токва херово мелкие запросы выполняются) ... экий я недалекий чел...
-
Сарказм? ;D (с) Шелдон Купер
Да не важно почему они медленные. Какая разница?
Сеть медленная/нагруженная.... Объекты тяжелые.... Сервак в Африке находится....
Тем более, что в реальной задаче нагруженная сеть 100мбит и старенький слабый сервак...
Представьте, что вы на олимпиаде по программированию.
В условиях задачи написано:
"Запросы дорогие"
Т.е. нужно выполнить минимальное число запросов. Это кстати основное правило при работе с СУБД.
На сертификации 1С сразу ставят неуд, если в вашем коде есть запрос в цикле (за исключением очень редких случаев)
-
Я даже по другому скажу:
Не запросы дорогие, а клиент-серверное взаимодействие...
Так проще понять.
-
Вот один из вариантов решения этой задачи:
http://nashe1c.ru/materials-view.jsp?id=357 (http://nashe1c.ru/materials-view.jsp?id=357)
-
Вот один из вариантов решения этой задачи:
http://nashe1c.ru/materials-view.jsp?id=357 (http://nashe1c.ru/materials-view.jsp?id=357)
Нда ... решение... нормальное решение -сформировать таблицу из 4 полей
id_parent, id_zat -ключи таблицы затрат
id_obj (ключь строки названия обьекта учета)
id _str - индекс строки в вашей супер таблице - то есть 4 записи по 4 байта - если у вас супер таблица имеет 10000000 строк то это всего 160 мб причем срезы по ней практически мгновенные (обычно такие таблицы в простейших случаях делаются с помощью views более общий подход хранимые процедуры).., для построения дерева использовать хранимые процедуры либо делать их на клиенте (для мелких срезов) остальные данные - из тех которые не меняются - названия обьектов учета, названия категорий затрат - запихивать на локаль и модифицировать только в случае необходимости, -те которые меняются прокачивать по срезу он же range.- это первичные соображения- остальные, только в том случае если вышеперечисленное не работает.
-
Вместе со ссылкой на родителя можно ещё хранить путь до корня. В дополнительном поле. В формате:
<rootid>-<subtreeid>-<subtreeid>-...-<parentid>
А в дополнительной таблице - листья дерева.
Искать циклы будет просто.
-
Да еще лично я бы сделал гиперкуб на локале - один фиг исходная таблица создается редко и данные в ней НЕ ИЗМЕНЯЮТСЯ -ну подождал бы менагер минут десять (в наихудшем) случае (пока идет прокачка данных с сервера и построение индексов на клиенте)-покурил сигаретку - зато, комфортная работа - до тех пор пока не понадобится перестроить супер таблицу (а это случается обычно в конце отчетного периода)
-
Не 4 записи по 4 байта -а 4 поля по 4 байта , сорри.
-
А если вы делаете приложение (не пользуетесь штатными средствами 1с ) - то предложить заказчику выбор между двумя режимами
-
И вдогонку (а вдруг это откровение ;) ) - все что можно вычислить - вычислять на локале при отображении в грид
-
сформировать таблицу из 4 полей
Сергей Губанов примерно так и предлагал поступить.
-
А если вы делаете приложение (не пользуетесь штатными средствами 1с )
Что значит пользоваться штатными средствами 1С?
-
сформировать таблицу из 4 полей
Сергей Губанов примерно так и предлагал поступить.
Нет он предлагал хреначить все это на сервере (не БД, но на серверной машине) - куда доступ скромному 1с нику на отсосе в нормальной конторе путь заказан - и для ГРАМОТНЫХ действий по ЕГО плану требуется высокая квалификация 1с ника как программиста- системщика -которой обладают 1 из 50 рядовых 1сников. НО САМОЕ ГЛАВНОЕ - на том этапе было неизвестно, что набор данных УЖЕ рассчитан.
-
А если вы делаете приложение (не пользуетесь штатными средствами 1с )
Что значит пользоваться штатными средствами 1С?
по сути дела - генератором отчетов встроенным в в систему (его возможности велики - но все же он не очень БЫЛ гибок для подобных задач (мои данные 7-9 летней давности) ),
возможно за это время в 1с появились другие средства.. я , же говорил, что завязал с этой деятельностью
-
Просто по вашему высказыванию показалось:
разработка в 1С <> использование штатных средств 1С
-
Для генератора отчетов вам как минимум SQL запрос нужно написать.
-
Для генератора отчетов вам как минимум SQL запрос нужно написать.
ОООх разве ? ;D да , я забыл сказать - что (по подобным задачам) всегда считал что об этом стыдно напоминать
-
Для генератора отчетов вам как минимум SQL запрос нужно написать.
Вот... где засада-то... :o
-
А в чем юмор?
Расскажите я тоже посмеюсь :)
-
Вот... где засада-то... :o
Вы о чем?
-
А в чем юмор?
Расскажите я тоже посмеюсь :)
В том, чтобы набрать это сообщение на клавиатуре, надо было, как минимум, на кнопки нажимать... ;)
-
В том, чтобы набрать это сообщение на клавиатуре, надо было, как минимум, на кнопки нажимать... ;)
А что написание SQL запросов легкое занятие?
-
А в чем юмор?
Расскажите я тоже посмеюсь :)
Но особый прикол читать "Для генератора отчетов вам как минимум SQL запрос нужно написать."
после "Нормально там все. Одынэсники обычно оптимальные запросы пишут, т.к. занимаются этим день и ночь "
-
Напомню контекст:
Просто по вашему высказыванию показалось:
разработка в 1С <> использование штатных средств 1С
-
Ну, для примера... Любое/ая подразделение/подсистема предприятия основана на 3-х ключевых элементах. Возьму для примера сбыт (можно и производство, но писать больше... а лень).
Треугольник сбыта:
вершины: товар/продукция, клиенты, деньги;
ребра: товар-деньги (прейскуранты), деньги-клиенты (оплаты), товар-клиенты (заявки, рекламации);
В центре треугольника точка, которая смыкается с тремя вершинами, - это основные документы проходящие через сбыт:
1. Заказ (клиент, товар, цена);
2. Счет (клиент, товар, цена);
3. Накладная и счёт фактура (клиент, товар, цена);
4. Товарная накладная (клиент, товар, цена);
5. Возврат товара (клиент, товар, цена);
6. Любые другие документы...
Можно расширять любые из элементов (клиент, товар, деньги), вводить категории и группы, фиксировать те или иные контакты... сути сбыта это не изменит, и аналитические плоскости будут всегда определяться этими ключевыми элементами... То есть, всегда работу сбыта будут анализировать
1. по клиентам (какие клиенты или группы клиентов сколько товаров закупают, сумма товаров, по каким товарам);
2. по продукции (какая продукция наиболее ликвидна, какая продукция наиболее доходна/рентабельна);
3. по деньгам (какие формы оплаты предпочитают те или иные клиенты/группы клиентов [для промышленных предприятий не очень актуально... пока денег в стране хватает], какие отсрочки платежей наиболее эффективны для тех или иных групп клиентов, для тех или иных категорий товаров).
Ну, и что ещё принципиально иного можно добавить к этому?..
:) Это сообщение я пропустил, но в связи с открывшимися обстоятельствами давайте не будем это обсуждать в этой ветке (я понял что вы хотите сказать), но говорил про другое - а именно про модели (алгоритмы) расчета себестоимости (в соответствии с топиком и в связи с тем, что были непонятны причины медленной работы... горе от "ума", как говорится :( - но все таки жизнь веселая штука ;) ) .
-
Напомню контекст:
Просто по вашему высказыванию показалось:
разработка в 1С <> использование штатных средств 1С
я, слава богу, нехристь -ибо если после каждого раза когда мне что-то показалось крестился...рука бы наверное отсохла...
-
по -этому - предлагаю относится проще к таким вещам :)
-
Да я и не напрягался ;)
Я тогда просто хотел уточнить смысл вашего сообщения, т.к. не понял его совсем.
Правда понимания у меня так и не прибавилось :)
-
И вдогонку (а вдруг это откровение ;) ) - все что можно вычислить - вычислять на локале при отображении в грид
И это сообщение тоже совсем не понял. :)
У вас весьма необычная манера изъясняться. Ваши сообщения нужно вдумчиво читать... А мне лень :)
Чесна чесна :)
-
грид - это контрол такой?
-
Да я и не напрягался ;)
Я тогда просто хотел уточнить смысл вашего сообщения, т.к. не понял его совсем.
Правда понимания у меня так и не прибавилось :)
Дело вот в чем, об 1с ке я сужу по данным 7-9 летней давности -серьезно не копал..но конкурентов нужно знать в "лицо" в те времена действия, которые не вписывались в "общую" схему 1с ки - а это практически все нестандартные задачи делались с помощью достаточно мощного генератора отчетов - который позволял даже создавать стандартного вида окна со стандартными элементами управления а с точки зрения БД - работать с клиентскими наборами данных... на этом "штатные" возможности заканчивались. С другой стороны, вы начинаете тему про 1с, но - то говорите о применении предложения С. Губанова (реализация которого ВЫХОДИТ за рамки "штатных" средств), то ссылаетесь на программу (которая генерирует отчеты - к созданию которой приложили руку). А если учесть, что (как оказалось) задача сформулирована вами КРАЙНЕ не прозрачно... То один бог ведает, какие средства в действительности допустимо использовать вам для решения этой задачи - а как известно наличие (отсутствие) средств во многом определяет как алгоритм, так и качество решения....Вот и выдал вам соображения с учетом ВОЗМОЖНЫХ обстоятельств.
-
грид - это контрол такой?
да, quantum grid от devexpress - классический пример
-
И вдогонку (а вдруг это откровение ;) ) - все что можно вычислить - вычислять на локале при отображении в грид
И это сообщение тоже совсем не понял. :)
У вас весьма необычная манера изъясняться. Ваши сообщения нужно вдумчиво читать... А мне лень :)
Чесна чесна :)
Тогда делайте на ББ - там все просто, настолько, что народ применяет и не думает - лафа, однако... :D
-
а с другой стороны - фигли думать ЧЕРНЫЙ ЯЩИК - по определению устройство загадочное... ;D
-
Дело вот в чем...
Теперь понятно :)
Я не говорил, что метод Сергея выходит за рамки штатных средств (или условий задачи). Я говорил, что для 1С это не подходит по ряду причин (просто не подходит, а не невозможно)
Насчет 1С.... Я не работал с версиями младше 7.7 Наверно потому не могу представить что вы описываете.
В современной 1С нет ничего необычного.... Представьте себе такой сильно упрощенный .NET, под который пишут на VB переведенном на русский язык - это и будет 1С ;D ;D ;D
Насчет формулировки задачи. Да я весьма туманно описал задачу. Признаю. Но чтобы ТЗ написать нужно мозг включать. А мне опять же лень :)
Я в начале потому и сказал: "Задавайте вопросы. Буду уточнять"
-
А смысел в
2 DIzer
Разговор, который тут идет, пока к задаче вообще отношения не имеет.
Задача - это первое сообщение.
По существу задачу только Сергей Губанов решал
тогда какой ? - ОХХХ так это я должнен "обижаться" ;) должен вас разочаровать - мне лень...
-
Речь не о вас была, а вообще.
Пошло обсуждение себестоимости, плохой структуры одынэсных таблиц, что циклов быть не может, что одынэсники тупые, что пользователю такой отчет не нужен и т.д. и т.п.
Что из этого списка имеет отношение к задаче?
И я оффтопил тоже как мог ;)
Я никого не осуждаю. Просто обсуждения задачи не получилось...
-
Правда остается вопрос: А если данных еще больше?
Тогда придётся делать это на жёстких дисках. Допустим данных 1 террабайт. Они размещены на одном террабайтном диске. Ответ надо записать на другой террабайтный диск. Для промежуточных расчётов (если они нужны) использовать третий террабайтный диск. :) :) :)
-
Правда остается вопрос: А если данных еще больше?
Тогда придётся делать это на жёстких дисках. Допустим данных 1 террабайт. Они размещены на одном террабайтном диске. Ответ надо записать на другой террабайтный диск. Для промежуточных расчётов (если они нужны) использовать третий террабайтный диск. :) :) :)
Лучше сразу купить пару-тройку твердотельных дисков под PCI-E... Похоже на чисто американский взгляд: не бывает плохих алгоритмов, бывает мало памяти, производительности процессоров, пропускной способности каналов и пр. Но нам-то всегда было свойственно подумать... "растечься мыслью по древу"... выучить SQL... так, чтобы написание запросов не вызывало проблем. Ваши посты (алгоритмов) пример непохожести на американцев... ;)
-
твердотельных дисков
Мне начальство пообещало купить для ноута в ближайшее время. Жду с нетерпением :)
-
Речь не о вас была, а вообще.
Пошло обсуждение себестоимости, плохой структуры одынэсных таблиц, что циклов быть не может, что одынэсники тупые, что пользователю такой отчет не нужен и т.д. и т.п.
Что из этого списка имеет отношение к задаче?
И я оффтопил тоже как мог ;)
Я никого не осуждаю. Просто обсуждения задачи не получилось...
Плохо, :(
Так и есть -"одынэсник" под авататаром не есть выражение иронии. Вы клише об "1сниках" проецируете на себя - замечу, что как минимум это приводит к неадекватной оценке
ситуации :
1. Речь как раз шла об отчете - для того, чтобы предложить эффективное решение необходимо понимание задачи - вы ее четко не сформулировали, но захотели эффективное решение, без понимания -его нет. Насчет нужности отчета пользователю (я до сих пор в ней сомневаюсь) - это достаточно больная тема - одна из проблем в том, что ОЧЕНЬ часто сам пользователь не знает что хочет. Конечно, можно сказать так - пусть заплатит и после этого хоть потоп...но -боюсь после этого он к вам с заказом не обратится.
Так что к задаче имело отношение ВСЕ из вашего списка (кроме -одынэсники тупые - это Ваш выбор)
2. Вы не оффтопили - вы пытались разьяснить на своем уровне понимания задачи (в такой ситуации очень легко повернуть не туда куда нужно), так что нечего на себя наговаривать..
3. Еще раз ошибаетесь- очень даже получилось (по выше перечисленным причинам), и вам было предложено решение с вариациями
ЗЫ Не очень понимаю чем начинающий Скалист лучше начинающего 1Сника... ,а насчет "одынэсники тупые" -как вы лодку назовете, так она и поплывет..
Знаю одно -хороший специалист по автоматизации,оптимизации процессов управления ,учета - по интеллекту равен хорошему администратору - и в чем то лучше него
ибо приходится работать с различными моделями учета, с людьми и за ОГРАНИЧЕННОЕ время принимать решения с учетом большего числа факторов . Среднаяя оценка IQ для администратора -180 баллов, интеллект среднего научного работника 160 баллов, для того что бы успешно заниматься системным программированием, к которому чувствую вы относитесь с пиитетом вполне хватает120-140 баллов... Так что смотрите сами... ;)
-
"одынэсник" под аватаром появилось раньше этой темы ;)
В общем согласен. Хочу лишь заметить, что у меня цель была абстрактную задачу рассмотреть. Т.е. алгоритмическая задача в ограничениях с привлечением SQL(только SELECT). Почему ограничения именно такие объяснять очень муторно, да и решить задачу это не поможет.
Интересна общая стратегия. Ну вот как у сортировки во внешней памяти своя стратегия против сортировки в оперативе, по причине дорогого доступа, так и тут.
Да... придется мне все таки потратить калории на формализацию задачи :)
Да и таблички тоже нужно подготовить. И от предметки абстрагироваться...
Но не сегодня. Сил нет.
Насчет тупых одынэсников... Мне пофик в общем. Но все равно было неприятно читать этот боян:
Да, там как обычно 1С-овцы... наваяли таблиц... "не от большого ума, но от чистого сердца" (с)
Ведь человек знает что я одинэсник, и все равно пишет... Т.е. взял и косвенно меня умом обделил.
-
"одынэсник" под аватаром появилось раньше этой темы ;)
В общем согласен. Хочу лишь заметить, что у меня цель была абстрактную задачу рассмотреть. Т.е. алгоритмическая задача в ограничениях с привлечением SQL(только SELECT). Почему ограничения именно такие объяснять очень муторно, да и решить задачу это не поможет.
Интересна общая стратегия. Ну вот как у сортировки во внешней памяти своя стратегия против сортировки в оперативе, по причине дорогого доступа, так и тут.
Да... придется мне все таки потратить калории на формализацию задачи :)
Да и таблички тоже нужно подготовить. И от предметки абстрагироваться...
Но не сегодня. Сил нет.
Насчет тупых одынэсников... Мне пофик в общем. Но все равно было неприятно читать этот боян:
Да, там как обычно 1С-овцы... наваяли таблиц... "не от большого ума, но от чистого сердца" (с)
Ведь человек знает что я одинэсник, и все равно пишет... Т.е. взял и косвенно меня умом обделил.
1 ИМЕННО по этому я сделал вывод что это не есть самоирония
2.НЕТ вы САМИ сказали что временные наборы данных создавать МОЖНО (лень искать ваши слова)
3. Вот стратегию решения которая вам "интересна" вы и получили с краткими пояснениями почему это так.
Во общем хватит, надоело - не хотите - не думайте.
-
Насчет тупых одынэсников... Мне пофик в общем. Но все равно было неприятно читать этот боян:
Да, там как обычно 1С-овцы... наваяли таблиц... "не от большого ума, но от чистого сердца" (с)
Ведь человек знает что я одинэсник, и все равно пишет... Т.е. взял и косвенно меня умом обделил.
Приношу извинения, на подпись я вообще не смотрел... но виноват, конечно. У меня сложилось впечатление, что БД не Ваша, Вы только её сопровождаете/развиваете.
Что же касается ума... то моё мнение об 1С-никах лучше не стало (без кивков в Вашу сторону). Просто одни делают криво, другие ограничивают себя этой кривизной, не желая понять той предметной области, которой занимаются. Мне такой подход претит, но это выбор каждого...
Ещё раз простите, говоря про 1С-ников Вас я ввиду не имел.
-
2.НЕТ вы САМИ сказали что временные наборы данных создавать МОЖНО (лень искать ваши слова)
Я запрещал SELECT INTO?
3. Вот стратегию решения которая вам "интересна" вы и получили с краткими пояснениями почему это так.
Во общем хватит, надоело - не хотите - не думайте.
Если вас не затруднит напомните какой это пост был пожалуйста.
-
alexus, нормально все. Я не обидчивый :)
-
2.НЕТ вы САМИ сказали что временные наборы данных создавать МОЖНО (лень искать ваши слова)
Я запрещал SELECT INTO?
3. Вот стратегию решения которая вам "интересна" вы и получили с краткими пояснениями почему это так.
Во общем хватит, надоело - не хотите - не думайте.
Если вас не затруднит напомните какой это пост был пожалуйста.
1. Прежде чем копировать данные куда-то, нужно это куда то создать....
2. #133 и далее.. http://oberspace.dyndns.org/index.php/topic,217.msg4852.html#msg4852 (http://oberspace.dyndns.org/index.php/topic,217.msg4852.html#msg4852)
Все хватит - это последнее на что я вам отвечаю
-
У меня сложилось впечатление, что БД не Ваша, Вы только её сопровождаете/развиваете.
Так и есть. Это УПП. Но разрабатывали то ее такие же одинэсники как я. Я потому и сказал, что косвенно... ;)
-
1. Прежде чем копировать данные куда-то, нужно это куда то создать....
Я опять ничего не понял. ::) Что создать?
Ну да ладно. Тема затянулась.
Извините за отнятое время :)
-
Тут вроде уже писали, что расчет себестоимости это оффтоп, но к alexus:
Вы приводили мнение что система 1С заточена под бухучет. У меня вопрос, насколько хорошо она заточена под бухучет, и есть ли решения лучше (ну и в чем их отличия).
Если можно, то также хотел бы услышать про партионный учет. Так ли он нужен для расчета себестоимости (в 1С кроме него появилось сравнительно недавно понятие РАУЗ - расширенная аналитика учета затрат). Я особо не вникал в суть РАУЗ. Может быть по этому поводу тоже есть более эффективные решения?
-
Тут вроде уже писали, что расчет себестоимости это оффтоп, но к alexus:
Вы приводили мнение что система 1С заточена под бухучет. У меня вопрос, насколько хорошо она заточена под бухучет, и есть ли решения лучше (ну и в чем их отличия).
Насколько мне известно... не существует предприятий, которые бы только вели бух. учёт. Козьма Прутков утверждал, что "специалист подобен флюсу"... но не бывает флюса без человека. Поэтому невозможно хорошо "заточить" систему под бух.учёт, игнорируя при этом другие задачи. Сам бух. учёт - это следствие, а не причина деятельности предприятия. Чтобы хорошо "заточить", надо массу задач "втянуть" в бухгалтерскую систему и... получить "флюс во всё лицо", то есть, 1С.
Нужна нормальная система, где бух. учёт занимает свою совершенно конкретную нишу. Тогда и бух. учёт становится предельно простым, и... система в целом.
Если можно, то также хотел бы услышать про партионный учет. Так ли он нужен для расчета себестоимости (в 1С кроме него появилось сравнительно недавно понятие РАУЗ - расширенная аналитика учета затрат). Я особо не вникал в суть РАУЗ. Может быть по этому поводу тоже есть более эффективные решения?
Партионный учёт он бывает разный... настолько разный, что вопрос выглядит некорректным.
Есть партии поставок/закупок, а есть партии поставщика - это разные вещи. Мы можем в разных партиях закупок получить материалы из одной партии поставщика, а можем в одной партии закупок получить материалы из разных партий поставщика, обладающих несколько разными характеристиками, которые могут быть важными для нас. Есть партии продаж и есть производственные партии. Все эти партии могут явно или косвенно влиять на себестоимость.
Но расчёт себестоимости, как таковой, и партионность - не являются элементами бух.учёта. Информация о партиях относится к экономистам, плановикам и технологам (если речь идёт о производственных партиях). Для примера, посмотрите в литературе расчёты оптимального размера производственной партии. Оптимальный размер партии можно рассчитывать разными способами, например он может определяться соотношением времени рабочего хода (временем обработки) и временем перенастройки оборудования. Но тех.операций может быть много, а оборудования ещё больше... Чтобы правильно выполнить расчёт необходимо определить "узкие места" и выбрать критерии для расчёта. Зачем всё это нужно в бухгалтерии?.. Ей нужно списать в производство материалы и получить из производства продукцию/товары. И то и другое делается по накладным без какой-либо партионной привязки.
Поэтому самое эффективное решение для бухгалтерии - не связываться с партионным учётом... не мешаться под ногами экономистов и технологов.
-
хотел бы услышать про партионный учет
Чаще всего под партионным учетом подразумевается списание запасов в определенном порядке (FIFO, LIFO). Каждый поступивший товар имеет свою партию (в простейшем случае номер и дата партии). Соответственно при продаже товара нужно списывать либо из последней поступившей партии, либо из первой.
-
:) ;D типичная точка зрения бухгалтера....
-
Не понял вашего юмора.
-
Не понял вашего юмора.
Хоть там и стоят смайлики, но это не юмор...
"Я тебе один умный вещь скажу, только ты не обижайся" (к/ф "Мимино")
Можно поставить вопрос так: "Что такое современная бухгалтерия?"... На этот вопрос можно получить разные ответы, но правильным будет такой: "Современная бухгалтерия - это специфический вид... налога на предприятие, где нижняя граница составляет 1 МРОТ, а верхняя определяется произведением МРОТ на два коэффициента. Ко - коэффициент количества документов, поступающих в бухгалтерию, Кт - коэффициент тупости налогоплательщика. Оба коэффициента варьируются в очень широких пределах. Но если Ко имеет физические пределы, то Кт никаких пределов по верхней границе не имеет.".
Суть в том, что бухгалтерия для управления предприятием не нужна (ниже поясню почему), а нужна она государству и отчасти акционерам. Но и (грамотные) акционеры сегодня предпочитают не данные внутренней бухгалтерии, а данные независимого аудита... то есть, им тоже бухгалтерия... непотребна. Почему бухгалтерия нужна государству... пояснять или уже понятно?..
Бухгалтерия не нужна для управления предприятием по той простой причине, что бухгалтерия живёт "вчерашним днём", она фиксирует то, что произошло. А управление состоит в том, чтобы вырабатывать цели, строить планы, находить механизмы реализации планов, и решать текущие задачи. Другими словами, управление нацелено в будущее, а бухгалтерия - в прошлое. Да, управлению порой необходима "обратная связь", нужно не только ставить задачи и формировать планы, но и контролировать их выполнение. Но вот беда... бухгалтерия ничего про планы не знает, а, следовательно, и контролировать их выполнение она не может. Для этого есть управленческий учёт (при условии, что он правильно выстроен).
-
У вас весьма смутные представления о бухгалтерии
-
У вас весьма смутные представления о бухгалтерии
Угу... Примерно такие же, как и о журнале транзакций...
Если есть, что возразить, то... возрази, а кидаться словами... ума не надо.
-
У вас весьма смутные представления о бухгалтерии
Согласен с alexus, даже в учебниках по бухучету пишут, что он нацелен на фиксацию фактов хозяйственной деятельности постфактум (т.е. нацелен на прошлое). А для управления обязательно должен быть выстроен упр. учет.
И мне в текущий момент очень не нравится в нашем государстве, что есть: бух. учет и налоговый учет, которые приходится вести отдельно, это точно косвенный налог на предприятие. Ну может быть чтобы создавались дополнительные рабочие места это и полезно, но обычно бухгалтера день и ночь торчат на работе, особенно в период отчетности.
К alexus, но в бухгалтерии на текущий момент надо знать номенклатуру, стоимость и даты партий, иначе как можно определить себестоимость? Если себестоимость не считать, налоги ого-го какие будут :( . Какие у Вас мысли по поводу расчета себестоимости, особенно если упр. учет на предприятии не поставлен (лучше на простейшем случае - торговом предприятии)?
-
Бух.учет - это аналитика, баланс, учет долгов, расчет прибыли/убытков, учет НДС.
Вам всю теорию рассказать? Читайте Луку Пачоли.
-
И мне в текущий момент очень не нравится в нашем государстве, что есть: бух. учет и налоговый учет, которые приходится вести отдельно, это точно косвенный налог на предприятие. Ну может быть чтобы создавались дополнительные рабочие места это и полезно, но обычно бухгалтера день и ночь торчат на работе, особенно в период отчетности.
Создавать надо те рабочие места, которые дают полезный продукт. Вон Т. Рузвельт во время великой депрессии... дороги строил, мосты возводил... А плодить бухгалтеров хуже, чем безработных... у них "пособие" выше...
К alexus, но в бухгалтерии на текущий момент надо знать номенклатуру, стоимость и даты партий, иначе как можно определить себестоимость? Если себестоимость не считать, налоги ого-го какие будут :( . Какие у Вас мысли по поводу расчета себестоимости, особенно если упр. учет на предприятии не поставлен (лучше на простейшем случае - торговом предприятии)?
Нет нужды считать себестоимость в бухгалтерии, есть приходы, есть расходы... вычитаем из первого второе, получаем прибыль. От прибыли считаем налогооблагаемую базу. Да, и не всегда, в принципе, можно определить себестоимость... продукции.
-
Бух.учет - это аналитика, баланс, учет долгов, расчет прибыли/убытков, учет НДС.
Вам всю теорию рассказать? Читайте Луку Пачоли.
Пожалуйста, не забрасывайте меня ссылка, я если что, бухгалтер по образованию. Тому что высказали alexus и я это не противоречит, правда не понял, какую аналитику Вы имеете в виду. Если субконто, то да, если что-то другое, то не знаю. Вся эта информация собирается по фактически свершившимся фактам (операциям) хозяйственной деятельности, и никак иначе. Нет факта, нет отражения в бух. учете. Баланс это обобщенная информация и т.д.
-
Мой комментарий вот к этому относился.
"Современная бухгалтерия - это специфический вид... налога на предприятие, где нижняя граница составляет 1 МРОТ, а верхняя определяется произведением МРОТ на два коэффициента. Ко - коэффициент количества документов, поступающих в бухгалтерию, Кт - коэффициент тупости налогоплательщика. Оба коэффициента варьируются в очень широких пределах. Но если Ко имеет физические пределы, то Кт никаких пределов по верхней границе не имеет.".
А то, что по факту.... Так это известно любому, кто хоть чуть чуть данным вопросом интересовался.
Счет - это тоже аналитика.
-
Нет нужды считать себестоимость в бухгалтерии, есть приходы, есть расходы... вычитаем из первого второе, получаем прибыль. От прибыли считаем налогооблагаемую базу. Да, и не всегда, в принципе, можно определить себестоимость... продукции.
Это примерно как сейчас НДС начисляется? Пришел документ поступления, отразили в расходах, реализацию - в доходах? Не разбирался с МСФО, там тоже так?
Вполне обычна ситуация, что приходит в одном периоде, а расходуется в другом. Ну и другие нюансы могут быть (переход с одной системы налогообложения на другую и т.д.). Ну ладно, Ваша позиция примерно понятна, я тоже согласен, что бухучет должен быть упрощен, но т.к. не являюсь практиком по бухучету, не знаю, во всех ли случаях пригодно Ваше предложение.
-
Нет нужды считать себестоимость в бухгалтерии, есть приходы, есть расходы... вычитаем из первого второе, получаем прибыль. От прибыли считаем налогооблагаемую базу. Да, и не всегда, в принципе, можно определить себестоимость... продукции.
Это примерно как сейчас НДС начисляется? Пришел документ поступления, отразили в расходах, реализацию - в доходах? Не разбирался с МСФО, там тоже так?
Так, вроде, с 2005 г. отчётность на российских предприятиях готовится по нормам МСФО...
В одной из систем мы встраивали поддержку US GAAP, принципиальных отличий нет, хотя там свои статьи и проводки, по некоторым документам могли быть двойные проводки. Но сейчас и штаты переходят на МСФО, начиная с транснациональных корпораций (ТНК). Так, что "всё едино, и аппатиты, и навоз" ((с) В.С. Высоцкий).
Вполне обычна ситуация, что приходит в одном периоде, а расходуется в другом. Ну и другие нюансы могут быть (переход с одной системы налогообложения на другую и т.д.). Ну ладно, Ваша позиция примерно понятна, я тоже согласен, что бухучет должен быть упрощен, но т.к. не являюсь практиком по бухучету, не знаю, во всех ли случаях пригодно Ваше предложение.
То, что приходит в одном периоде, в этом периоде и фиксируется, то, что уходит в другом периоде - в другом периоде и фиксируется. Это у финансистов есть разные бюджеты... БДДС (бюджет движения денежных средств), БДиР (бюджет доходов и расходов), РС (расчётный баланс), операционные бюджеты, вспомогательные бюджеты... А бюджеты напрямую связаны с планированием и исполнением планов... но это уже далеко не бухгалтерия.
-
Не понял вашего юмора.
Хоть там и стоят смайлики, но это не юмор...
Не совсем так:
Первый смайл -улыбка по поводу того как легко из правильной фразы "Чаще всего под партионным учетом бухгалтером подразумевается списание запасов в определенном порядке (FIFO, LIFO)." - в то хмм.. что выдали Вы :)
Второй навеян случаем из практики ... лет 10 назад я был свидетелем разговора одной дамы (выпускницы одного вуза по спец. бух учет с отличием работающей настройщиком одной системы (не 1с) операционного учета) с директором одной конторы...Тот пытался ее дать задание организовать "взвешенное" списание запасов (разумеется в рамках той программы настройщиком которой она была) это была трагикомедия в 2 частях. В первой части : дама утверждала - что такое невозможно, а если возможно то это будет неправильно, активно споря с директором....Во второй части представления (после того как директор с ошалевшим видом сходил в уборную успокоиться).. была демонстрация... т.е. директор подобрав с десяток соответствующих бумажных документов показывал, что нужно сделать "натуральным" образом (перекладывая документы и делая нехитрые вычисления). Под конец спросил... ну понятно? - дама ответила - понятно (ошалевшая от такого напора). Тот - вот и чудненько, а то вот мне (непонятно) - почему то что я могу делать в ручную - не может сделать программа в которую я уже вложил 2000$. И что - будем делать? -ответ.... Ничего -это все неправильно...
-
Второй навеян случаем из практики ... лет 10 назад я был свидетелем разговора одной дамы (выпускницы одного вуза по спец. бух учет с отличием работающей настройщиком одной системы (не 1с) операционного учета) с директором одной конторы...Тот пытался ее дать задание организовать "взвешенное" списание запасов (разумеется в рамках той программы настройщиком которой она была) это была трагикомедия в 2 частях. В первой части : дама утверждала - что такое невозможно, а если возможно то это будет неправильно, активно споря с директором....Во второй части представления (после того как директор с ошалевшим видом сходил в уборную успокоиться).. была демонстрация... т.е. директор подобрав с десяток соответствующих бумажных документов показывал, что нужно сделать "натуральным" образом (перекладывая документы и делая нехитрые вычисления). Под конец спросил... ну понятно? - дама ответила - понятно (ошалевшая от такого напора). Тот - вот и чудненько, а то вот мне (непонятно) - почему то что я могу делать в ручную - не может сделать программа в которую я уже вложил 2000$. И что - будем делать? -ответ.... Ничего -это все неправильно...
Да, знакомая ситуация. Был и такой случай... лет 5-7 назад. На форуме delhikingdom... 1С-ники в очередной раз с пеной у рта доказывали, что никто, кроме них бухгалтерии не знает... а 1С - это лучшее, что есть на сегодня для асу-чивания предприятий. Один из них (благо тоже из Ё-бурга) решил приехать в гости, чтобы, так сказать, личным примером... убедить в своей правоте. Приехал, посмотрел на софт, потом на модели предприятия, снова на софт, потом попросил прояснить возникшие вопросы... Часа два мы с ним сидели... Наконец, он перешёл, собственно, к бухгалтерии... А что бухгалтерия... пять основных таблиц и десяток справочников... плюс некоторые средства автоматизации проводок... если нужно. Нарисовал я ему бухгалтерию. Он себя по лбу хлопнул, попросил забрать почеркушки... больше я его не видел... даже на форуме... :)
-
А этот 1С-ник... он аналитик или кодер? И какие сертификаты у него?
Дураков везде полно.
-
А может тему создать "One Ass"? Раз уж так много претензий к сему продукту и его адептам. И высказать там конкретно и по существу где в 1С байты кривые, а у 1с-ников гены... :D
-
А может тему создать "One Ass"? Раз уж так много претензий к сему продукту и его адептам. И высказать там конкретно и по существу где в 1С байты кривые, а у 1с-ников гены... :D
Я вот тоже 1сник (других языков, практически не знаю, т.к. не использую, и не учился на них, оберон чисто академический интерес, и все). Я не системный архитектор, но почему-то считаю, что 1с можно и нужно улучшить. Как, что и почему, не знаю, т.к. пока не уложилось все по полочкам. Но надо же искать, а не принимать как данное, что "1С это наше фсЁ", и лучше быть не может. И не надо принимать всё на свой счет, но с другой стороны, если что-то Вам указывают, имеет смысл задуматься, в вдруг это правда (токо без обид :) )
-
Дык я и предлагаю обсудить :) У меня тоже есть претензии к этому продукту. ;)
-
А может тему создать "One Ass"? Раз уж так много претензий к сему продукту и его адептам. И высказать там конкретно и по существу где в 1С байты кривые, а у 1с-ников гены... :D
Ну, 1Сников может утешать то, что бывает и хуже - SAP :-)
Специфика ниши такова, что собственно сам язык и архитектурные решения там вторичны, а первично, с точки зрения распространения и применимости, совсем другое. Ну и развитие/распределение усилий соответствующее.
-
Да. И SAP ругают и Axapta.
Язык и архитектурные решения 1С в определенном плане тоже интересны. (Тем более что о них мало знают люди извне) :)
Создавать тему?
-
Да. И SAP ругают и Axapta.
Язык и архитектурные решения 1С в определенном плане тоже интересны. (Тем более что о них мало знают люди извне) :)
Создавать тему?
Конечно создавай. А нужна она или нет - покажет число постов в ней :-)
-
Создал:
http://oberspace.dyndns.org/index.php/topic,225.0.html (http://oberspace.dyndns.org/index.php/topic,225.0.html)
-
Специфика ниши такова, что собственно сам язык и архитектурные решения там вторичны, а первично, с точки зрения распространения и применимости, совсем другое. Ну и развитие/распределение усилий соответствующее.
Надо бы сказать... что язык и архитектурные решения там пока вторичны... Так будет точнее. Просто систем такого уровня, взаимодействующих не с "железом", а с людьми, больше нет. Отсюда, я думаю и издержки. Придёт время красивых и стройных архитектур, мультиязычности... понимания системологии. 20 лет маловато... видимо.