Есть две таблицы (в файле - желтая и синяя), между которыми связь многие ко многим
Общая часть нормальных данных выделена желтым. В синей таблице часть строк - лишние. В примере такая выделена красным. По формальным признакам они от нормальных не отличаются и выбрать их можно только вручную. В желтой таблице - эталонные суммы по категории "Фрукт", с которыми надо сверяться, чтобы понять, какие категории содержат ошибочные строки.
Слева внизу сводная таблица, сделанная через PP из обеих таблиц, в ней видно, что ошибка в категории Яблоко. То есть найти, в каких "Фруктах" содержатся ошибки, можно только сравнивая таблицы через "Суммесли" по столбцу "Фрукт".
В итоге нужно что-то вроде синей таблицы, но с целиком выкинутой категорией Яблоко (то есть состоящую только из точно правильных строк) для дальнейшей обработки и другую таблицу, состоящую только из "Яблок" на ручной разбор, но это должно само собой получиться, если сделать п1.
можно такой логикой пойти:мерой высчитываем разницу сумм продавцов и меню, затем в сводной ставим фильтр по значению - равно "0" или не равно "0" (для второго случая)
Vladimir Chebykin написал: можно такой логикой пойти:мерой высчитываем разницу сумм продавцов и меню, затем в сводной ставим фильтр по значению - равно "0" или не равно "0" (для второго случая)
Нужен не просто список ошибочных категорий.
Нужна как максимум "Синяя" табличка разбитая на 2 таблицы - одна состоящая только из правильных категорий, другая - только из неправильных. То есть одну - содержащую только "яблочные" строки, другую - все остальные.
Ну или как минимум (почему-то мне кажется, что это проще, но не знаю, почему) - какой-то аналог сводной таблицы, которая у меня справа, но созданную только на основе правильных строк.
не знаю, какую таблицу в конечном итоге хотите получить (конечного образца такой таблицы в примере нет), но может такой вариант Вам поможет решить задачу
"Синюю таблицу, разбитую на две", то есть не сгруппированные строки, а исходные, первоначальная идея была получить это все в PQ, но там задачка, по-моему, упирается в возможности компьютера Я делала формулу "Суммесли" по рецепту с этого форума, но запросу целой ночи не хватило, чтобы отработать
Сейчас можно настройками сделать подходящий вид, но обратно в PQ, насколько я понимаю, "загнать" не получится, надо продумать обработку данных перед отправкой в Power Pivot, чтобы не требовалось их после свода еще допилить, но это уже другая история.
Xel написал: "Синюю таблицу, разбитую на две", то есть не сгруппированные строки, а исходные,
во вложенном примере #6 так вроде и сделал - выгрузил исходную таблицу "меню" и для наглядности справа добавил фильтр "правильно" и "неправильно". По поводу PQ: наверное можно сделать такое сравнение быстро и качественно, но я не умею...тут нужны ответы от "мастодонтов" вроде Максима Зеленского, Андрея VG или PooHkrd (и др.)
Xel написал: Я делала формулу "Суммесли" по рецепту с этого форума, но запросу целой ночи не хватило, чтобы отработать
Смотря что вы под Суммесли подразумеваете. В общем случае - это Table.Group. По сути задачи. Выявить по каким фруктам расхождение по суммам - задача простая. Вычленить же какое значение по сумме - ошибочный по сравнению с эталонной суммой по фрукту - задача не тривиальная. По ищите по форуму задачи вида подбор заданной суммы по набору значений
Андрей VG написал: Выявить по каким фруктам расхождение по суммам - задача простая
Андрей VG, я правильно понимаю, что это просто сделать в PQ? ТС именно это просит, сделать сравнение на этапе загрузки данных PQ. я бы хотел увидеть такое решение для саморазвития... если Вас не затруднит.
Xel написал: Оттуда. Как и предсказывал автор - работает страшно медленно
Вот не понимаю, а зачем брать оттуда самый медленный вариант с перебором строк, если третий вариант с Table.Group + Table.Join крайне резкий и понятный? Я им и пяток миллионов строк лопатил - время ожидания было вполне терпимым.
Ну вот, уже "мастодонтом" обозвали, и в один ряд поставили с такими корифеями, как Максим и Андрей. Владимир, спасибо, конечно, но я пока не заслужил. И еще, Андрей, вы в запросе использовали конструкцию
Код
= List.Sum(List.RemoveNulls([Стоимость]))
Это какая-то индейская хитрость? Зачем здесь удалять null?
— Вятская губерния, — сказал Челноков, — отличается своими размерами. Это одна из самых больших губерний России… По своей площади она занимает место, равное… Мексике и штату Виргиния… Мексика одна из самых богатых и плодородных стран Америки, населена мексиканцами, которые ведут стычки и битвы с гверильясами. Последние иногда входят в соглашение с индейскими племенами шавниев гуронов, и горе тому мексиканцу, который…
— Постой, — сказал учитель, выглядывая из-за журнала. — Где ты в Вятской губернии нашел индейцев?
PooHkrd написал: Вот не понимаю, а зачем брать оттуда самый медленный вариант с перебором строк, если третий вариант с Table.Group + Table.Join крайне резкий и понятный? Я им и пяток миллионов строк лопатил - время ожидания было вполне терпимым.
Мы, чайники, такие затейники /смайлик с фейспалмом/ Расширяем сознание о подсказки умных людей. Табл.груп я смотрела до того, как задать тут вопрос, не дошло, что это то самое-нужное. Не помню, почему
У меня после переноса решения в реальные таблицы получился интересный фокус. Это можно вылечить округлением до 2 знаков, насколько я понимаю.
Но у меня вопрос почему так получается - никаких сложных вычислений не делается, обычные формулы Экселя считают цифры равными. Почему PQ считает, что суммы не равны? Большая часть цифр была обработана правильно, все неравные сумму отмечены. Но часть одинаковых тоже отмечена как "ложь". Я сюда я скопировала в "Яблоки" и "Груши" пару примеров, которые неправильно были помечены как не равные. В этом маленьком файле PQ эти суммы бодро отмечает "ложью".
Причина проста - гуглите "excel ieee 754" Округление вам поможет, либо если вы точно знаете сколько максимально будет знаков после запятой в исходных данных (в вашем случае 2) , то можно перед вычислениями все умножить на 100 (в вашем случае), чтобы действия производились с целыми числами. Это снизит погрешность в вычислениях если их много промежуточных.