Еще один быстрый и нелетучий вариант параметризации диапазона:
Вариант с ИНДЕКС почему-то на больших размерах умной таблицы начинает работать непропорционально медленнее при удалении строки. Вариант со СМЕЩ такой болезнью не страдает при той же скорости.

Была схожая проблема: поле «Отправитель» выгружаемого файла содержало текстовое значение и пару сотен пробелов.
Решением было добавление одной строчки в код запроса Power Query:

#"Удаление хвостовых пробелов Отправитель" = Table.TransformColumns(#"Повышенные заголовки",{{"Отправитель", Text.TrimEnd}}),

Чувствую себя дебилом Ж)))

Оу, спасибо!!! Я не подумал, что можно в принципе «спрятать» формулу за ДВССЫЛ )))

В умной таблице два столбца: «Значение» и «Максимум». Столбец «Максимум» содержит формулу, выбирающую максимальное значение от начала таблицы до текущей ячейки. (см. пример во вложении).

При добавлении новой строки или строк формула в последней неизмененной строке самопроизвольно меняется на формулу в последней строке умной таблицы.
Что такое происходит? Как с этим бороться?

Расскажу про свой опыт и решение

Встретил аналогичную проблему: умная таблица не хотела автоматически расширяться вниз при добавлении новых строк.
Решил проблему тем, что выделил пространство под умной таблицей и сделал ему Главная → Редактирование → Очистить все
После этого проблема исчезла. Видимо что-то было там под таблицей, что мешало ей расширяться автоматически.

Да, и правда что.
Если спросить, текст это или нет, то различаются )))

Спасибо!

Пасиба. )

Коварство пустой строки и пустой ячейки, помимо прочего, состоит еще в том, что при проверке формулой они обе равны пустой строке ("")

Благодарю за исчерпывающее объяснение. Действительно, таблица пополняется разными людьми из разных источников. Скорее всего пустые строки попадают из 1С.

Пардон за нубский вопрос, а где и как можно посмотреть содержимое ячеек/массива?  

В чем разница между ячейками А1 и А2?
Как видите, вычисления с ними дают разный результат.

Подходит. Спасибо, друзья!

Позволяет ли синтаксис Excel адресоваться в умных таблицах по имени столбца и номеру строки?
К примеру, если я хочу выбрать значение третьей строки столбца «Сотрудник»

О, да. Это один из признаков профессионализма разработчика. Точнее архитектора.

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

Кстати, да, про объем это я зря не упомянул. До 20 записей в день. Имеется в виду добавление/финализация клиентов.

И я знаю про все преимущества специализированных решений и нанятых специалистов. Тем не менее, не всегда имеет смысл сразу строить самолет, иногда достаточно велосипеда.

Обсуждаемая задача (учет и работа с потенциальными клиентами) для нас не имеет стратегического характера. Скорее это оперативный инструмент. И он уже в стадии обкатки, благодаря коллективным советам и помощи форумчан.

А про небольшие бесплатные CRM я уже говорил: без заточки под наши процессы ни одна из десятка просмотреных мною систем не подходит нам настолько, чтобы выигрыш был больше, чем затраты на переход на новые рельсы. В будущем, когда ресурсы позволят, возможно реализуем какой-то вариант.

Сейчас пока на коленке автоматизирую, потом нормальную CRM запилим )

Я уже написал все, что меня интересовало. И услышал много полезного. На данный момент вопросов нет.

Ну да, мы и пляшем от реального процесса. Я просто не стал его расписывать, чтобы не усложнять без нужды.

Ну вот для этого и существует общение, чтобы то, что понятно одному стало понятно другому )))

Спасибо за хороший пример. Взял за основу.

Не, щас вроде бы вырисовалась оптимальная схема: форма ввода и VBA-код, который растаскивает данные по таблицам. И т.д.Это вариант. Сейчас делаю нечто подобное. Разумеется, своя форма и своя логика, но суть примерно такая же.

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

Потому что если перед тем, как создать запись-контакт, надо сначала внести запись в список клиентов, а потом уже из этого списка «выбирать», скажем, выпадающим списком, то с точки зрения программиста — это все очень логично: вот справочник, вот журнал. А на практике это жутко неудобно и люди по факту используют плейн текст. Да неструктурировано, но проще всего. Поэтому я ищу альтернативу, которая будет сопоставима по удобству ввода: либо последовательное заполнение полей таблицы, либо заполнение формы (что предпочтельнее).

В настоящее время картина более-менее вырисовалась. Хотел обойтись чистым экселем, но, видимо, все равно придется подтягивать тяжелое вооружение в лице VBA.

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

Да, разумеется, это решение на коленке.

Да, что-то типа этого я сейчас делаю )))

Золотые слова! )))
Но заморочиться с табличкой — это одно. А заморочиться с программированием на VBA или СУБД это совершенно другое. Глупо требовать от Экселя функционала Аксесса. Но поискать компромиссное решение никто не запрещает )) Собственно именно это я и сделал.

Я уже говорил, что проблема, так скажем, не в реализации, а в архитектуре. Смысл моего поиска как раз в том и состоит, чтобы понять ЧТО именно реализовать. Сейчас мне это уже более-менее понятно.
Да, решение (общее) есть. Но если вы внедряли CRM вы наверняка знаете, что ни одна CRM не бывает сколь-нибудь удовлетворительно заточена под нужды и процессы компании. Именно поэтому их так много. При выборе CRM почти всегда натягиваешь либо имеющийся функционал на свои процессы, либо свои процессы на имеющийся функционал, и не всегда то или другое выходит удачно.

Почему нам сейчас не подходит CRM я могу сказать кратко — очень много процессов УЖЕ опирается на эксель (который появился, как быстрая и простая альтернатива бумажечкам). Да, я могу сесть и написать CRM, идеально заточенную под нужды нашей организации, но это дорогое решение: месяц моей работы уйдет на создание прототипа, и еще полгода на допиливание и докручивание. Поэтому сейчас мы идем по пути самых простых решений.

Именно! Это разные задачи. Поэтому и возникает противоречие. Потому что в данном случае нам нужны свойства СУБД, а эксель — не СУБД. Если таблица одна, и запись хранит данные об одном клиенте — это концептуально самая простая модель. Она понятна и доступна для мало-мальски знакомых с экселем. Удобно заносить данные: ткнул в пустую строку и вводишь последовательно в поля имя, телефон, и все остальное. Визуально удобно выявлять строки-клиенты, которые предстоит обработать. Удобнее выполнять поиск и перенос обработанного клиента.

А если одной записи (строке) таблицы сопоставляется попытка контакта с клиентом — то да, без сомнения эта структура способна адекватно отразить хоть 1000 таких попыток. Но работать с ней реально неудобно: чтобы обновить статус, придется дублировать всю запись — лишние действия и, как следствие, возможные ошибки. Как отобрать клиентов по последнему выставленному статусу? В принципе можно, но надо заморочиться и делать отдельное представление (таблицу), которое будет анализировать поле статуса и дату-время каждой записи. Значит появляется еще одна сущность. Удалять/переносить зафиналенных клиентов — тоже нетривиальная задача. Этот вариант — шаг в сторону, когда хранение данных отдельно, интерфейс отдельно. Т.е. это шаг в сторону СУБД.

О нет-нет-нет-нет-нет!!! Никакого копирования! Наши талантливые девы такого накопируют — фиг найдешь концы! Плавали, знаем )))
Только выбор поля ввода (табличного или пользовательской формы) и только ввод (ну, или корректировка значения). Может это излишняя паранойя, но практика показывает, что любое действие, где потенциально можно совершить ошибку рано или поздно к этому приведет. Поэтому я стараюсь минимизировать это настолько, насколько разумно возможно.

Для ввода самое то. Для работы со списком — отдельное представление данных.

Тяжелое — имеется в виду, затратное по ресурсам и времени разработки. Эксель + БД разумеется тяжелее, чем просто эксель )))
А ромашки из бумажек мы проходили. И отказались от них в том числе благодаря Экселю.

Я благодарю всех, кто высказал свои мысли и идеи. Склоняюсь к решению на основе пользовательских форм ввода.

 

Благодарю за мнение, но я привык сначала проектировать, а потом строить. А не наоборот.

Из того что прозвучало в этом топике для меня выводы в сухом остатке:
1. Удобный для заполнения табличный вид не подходит для хранения. Преодолеть это средствами Экселя пока не получается.
2. Удобный для представления данных вид (один контакт — одна строка) не подходит из-за сложности ручного внесения данных. Но возможно удастся допилить этот формат с помощью VBA и пользовательских форм ввода.
3. Можно использовать эксель как интерфейс, а данные хранить в БД. Это решение еще более тяжелое, и к нему я прибегну, когда исчерпаю возможности предыдущих вариантов.

Я не говорю, что мне мало )))
Я спрашиваю совета у тех, кому есть что сказать. И, судя по тому, что я привел выше, вроде бы совсем не зря. Теперь я почти уверен, что стандартными средствами Эксель вряд ли удастся разрешить противоречие между интуитивным и понятным способом ввода, и хранением данных о произвольном количестве попыток контактов.
На данный момент для меня это самый полезный и продуктивный вывод из всего топика. За что я очень благодарен всем, кто поделился идеями.

Так я же ответил по этому поводу.

Если этот формат использовать для хранения, то не вопрос. А для ввода данных и для их изменения — это надо обладать иезуитской программистской логикой. Это же, фактически, сырые данные. Юные девы запутаются моментально )

Я не против хранить данные в таком виде. Тогда возникает закономерный вопрос: а как вводить данные? VBA и формы ввода? Возможно стоит изучить вопрос. Возможно у кого-то будут еще дополнения или варианты.

МВТ написал:Ну, меня больше всего смущает, что я не могу заранее знать, сколько попыток контакта может состояться с клиентом, прежде чем он будет зафинален. Если предположить, что это будет не более 10, значит мне придется резервировать 10 групп полей под каждую попытку работы с клиентом. Громоздко... но если ничего не придумаю, то терпимо.

И такое решение ситуативно. В рамках плоской таблицы с правилом одна запись — один клиент, его нельзя масштабировать на хранение произвольной истории взаимоотношений с клиентом (не только в контексте воронки, а вообще). Но это уже не проблема Экселя. Я понимаю, что это задача для СУБД.

Главная мысль моего поста в том, что, как мне кажется, в рамках Экселя удовлетворительного решения не найти. Но, возможно я чего-то не знаю, и, поэтому прошу совета. Возможно другие люди думают иначе. Возможно есть какие-то механизмы, которые позволяют вводить данные в какую-то форму, а затем эти данные сами растаскиваются по сложной системе связанных таблиц, способных как БД хранить все, что угодно и выводить в каком угодно виде. А девочки-операционистки в таком случае в сами данные не лезут (иначе у них мозг порвется), точнее вводят и изменяют их в какой-то относительно простой форме.

Это я так фантазирую... )))

Да рассматривал такой вариант. Нашел неудачным из-за того, что вносить данные крайне неудобно: для того, чтобы отразить действие с клиентом (сменить статус, добавить комментарий), надо дублировать всю строку. А с точки зрения представления данных — да, идеальный вариант. Для БД.

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

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

Э-э-э... ну да, что-то подобное я и хочу. Вопрос, как? И главный вопрос, как хранить данные о контактах?