добрый день всем. на ресурсе нашел схему по произвольной иерархии в скд. подогнал под свои нужды, выглядит норм, единственное криво считает суммы.
все это по данным собранным в упп.
есть затраты которые входят по разным заказам в заказы верхних уровней.
артикул родитель и артикул подчиненный, закинул в тз. данные по затратам тоже в тз.
иерархию по сути строит правильно, но если затрата встречается несколько раз по разным уровням в качестве артикула родителя то сумма затрат суммируется.
если строить иерархию по позиции типа 1, 1.1 1.2 и т.д. то теряется вид, который при иерархии артикулов, показывает структуру.
теперь мысли по связи двух наборов данных, как прописать условие сравнения по номеру позиции
все это по данным собранным в упп.
есть затраты которые входят по разным заказам в заказы верхних уровней.
артикул родитель и артикул подчиненный, закинул в тз. данные по затратам тоже в тз.
иерархию по сути строит правильно, но если затрата встречается несколько раз по разным уровням в качестве артикула родителя то сумма затрат суммируется.
если строить иерархию по позиции типа 1, 1.1 1.2 и т.д. то теряется вид, который при иерархии артикулов, показывает структуру.
теперь мысли по связи двух наборов данных, как прописать условие сравнения по номеру позиции
По теме из базы знаний
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Вы хотя бы структуру ТЗ опишите полностью, или схему СКД если на типовых объектах написана. А иначе что тут посоветовать. Работает иерархия и много где работает.
Похоже дело в формуле расчета ресурса. Если там не должна быть сумма подчиненных, нужно писать соответствующее выражение.
Не понятно, что именно имеется ввиду под "встречается несколько раз по разным уровням". Т. е. одна и та же затрата может быть и на 1-м уровне подчиненности, и на 2-м, и т. д.? Если так, то тем более непонятно, что такое "встречается несколько раз по разным уровням в качестве артикула родителя". Родитель-то один у неё, или нет? Опишите внятно проблему.
Не понятно, что именно имеется ввиду под "встречается несколько раз по разным уровням". Т. е. одна и та же затрата может быть и на 1-м уровне подчиненности, и на 2-м, и т. д.? Если так, то тем более непонятно, что такое "встречается несколько раз по разным уровням в качестве артикула родителя". Родитель-то один у неё, или нет? Опишите внятно проблему.
по данным я получаю артикула и суммы, из регистра в плоском виде.
Номер позиции Артикул Артикул затрат Сумма
1 1А
1.1 1А 2Б 10
1.1.1 2Б 11
1.1.2 2Б 12
1.2 1А 3С 10
1.3 1А 4Д 15
1.3.1 4Д 2Б 17
1.3.1.1 2Б 20
иерархия строится на артикуле родителя и артикуле подчиненного. потом собственно группировка по артикулам.
получается при таком виде сложение 1.1+1.3.1=10+17=27
и по иерархии выводит в двух местах по 27.
Номер позиции Артикул Артикул затрат Сумма
1 1А
1.1 1А 2Б 10
1.1.1 2Б 11
1.1.2 2Б 12
1.2 1А 3С 10
1.3 1А 4Д 15
1.3.1 4Д 2Б 17
1.3.1.1 2Б 20
иерархия строится на артикуле родителя и артикуле подчиненного. потом собственно группировка по артикулам.
получается при таком виде сложение 1.1+1.3.1=10+17=27
и по иерархии выводит в двух местах по 27.
Прикрепленные файлы:
Иерархия затрат.erf
(5) При подсчете 1А учитывается 2Б. При подсчете 4Д также учитывается 2Б. А то что 4Д сам, в свою очередь входит в 1А, СКД не учитывает.
Кажется, тут не совсем дерево. Это скорее сеть. У элемента два родителя - это не дерево.
В таком случае, даже без СКД, а просто калькулятором на листочке корректно сумму не посчитаешь.
Кажется, тут не совсем дерево. Это скорее сеть. У элемента два родителя - это не дерево.
В таком случае, даже без СКД, а просто калькулятором на листочке корректно сумму не посчитаешь.
думаю надо менять структуру данных, и делать уникальность для группировки, потому что не понятно как скд должен понять что ему складывать
Пока не могу определить проблему.
ПризнакРаспределения, СтатьяКалькуляции - попробуйте сделать измерениями. Я делал вертикальные группировки, они заработали только когда такие поля были измерениями.
Остальные измерения кажутся лишними. Вроде бы, не должны они тут влиять на что-то.
Кажется понял, в чем проблема. Один и тот же элемент принадлежит сразу двум родителям. СКД всё суммирует.
ПризнакРаспределения, СтатьяКалькуляции - попробуйте сделать измерениями. Я делал вертикальные группировки, они заработали только когда такие поля были измерениями.
Остальные измерения кажутся лишними. Вроде бы, не должны они тут влиять на что-то.
Кажется понял, в чем проблема. Один и тот же элемент принадлежит сразу двум родителям. СКД всё суммирует.
С моей точки зрения проще обработать таблицу предварительно, чем пытаться исправить что-то выражениями СКД. Нужно пробежаться по таблице и проверить, встречается ли артикул среди родителей. Если встречается - значит это не последний уровень и сумму надо очистить.
в этой структуре суммирование идет на уровне иерархии же? артикул подчиненный родителю сам становится родителем и суммирует свои затраты, но по разным родителям. то есть не пойму что даст очищение сумм
не совсем правильно обрисовал свою тз
2Б в 1А = 11+12=23
2Б в 4Д = 20
а получается
2Б в 1А = 11+12+20=43
2Б в 4Д = 20+11+12=43
2Б в 1А = 11+12=23
2Б в 4Д = 20
а получается
2Б в 1А = 11+12+20=43
2Б в 4Д = 20+11+12=43
Прикрепленные файлы:
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот