Под предлогом, что в CRM сложно с отчётностью - переехали целиком на таблицы?
Не совсем: переехали из чатов в таблицы. CRM как была, так и осталась, просто там больше работают админы, которые назначают уроки и пр. Нужную отчётность в ней не получить без дополнительных разработок.
Они предназначены вытягивать информацию из корп систем
Из систем была только CRM, в которую, к тому же, не все данные можно ввести. То есть, всё равно требовалось ещё где-то недостающие данные вводить, чтобы потом строить отчёт. В этом плане Google Таблицы гибко совмещают как ввод, так и отчётность. С некоторыми компромиссами, конечно.
На скрине не PnL. PnL - отчёт о прибылях и убытках компании.
Там не видно всех столбцов — дальше ещё колонки с расходами и др.
При 400+ менеджерах я бы сказал, что это дело пары месяцев, пока вся эта система ляжет под грузом данных
В таблице УК сейчас данные от менеджеров агрегированы по месяцам и импортируются в 26 колонок. При 400 менеджерах это будет работать примерно 80 лет (два с половиной года уже работает). Плюс, уволившиеся менеджеры не занимают строки в последующих месяцах, так что даже больше.
Или из российских DNS его вдруг удалят, как YouTube. UPD: потом подумал, что написал — это же не важно, .ru или .com... Тут уже не в доменной зоне проблема.
Например, Beget. Раньше они регистрировали через Reg.ru, но 8 лет назад сами стали регистраторами. А Reg.ru тогда попытался не вполне красиво мои домены оставить у себя, пришлось проявить настойчивость. Рефералка, если изволите.
Так проще и для пользователей, и для меня. Не нужно каждый раз залезать в код/базу для добавления менеджера, не нужно пилить интерфейс админа, который не добавляет ценности (и не оплачивается).
Вероятность утечки этого ключа примерно такая же, как вероятность утечки пароля к интерфейсу — я же его точно так же в сообщении отправлю.
Даже если ключ утечёт (вместе со взломом Tg-аккаунта менеджера), то пользы злоумышленнику от него никакой. Разве что насоздаёт ссылок на оплату, пока мы через базу его не забаним. Реквизиты получателя он изменить не может.
Очень давно интересует такой момент: не приводит ли к преждевременному износу покрышек момент касания неподвижных колёс со взлётно-посадочной полосой при посадке? Вроде бы, решение есть элементарное — крыльчатки поставить на них, чтобы от набегающего воздуха раскручивались.
Про сына: напомнило задачу про 3 двери. За одной из них приз, и ведущий знает, за какой. Вы выбрали первую. Ведущий показал, что за второй дверью ничего нет. Поменять свой выбор на третью дверь или остаться на своём?
В чём нюанс
Исходная вероятность угадать: 1/2.
Ведущий может выбрать, какую из дверей открыть. Он выберет случайно между 2 и 3, только если приз за 1 (вероятность 1/3). В других 2 случаях — у него нет выбора. Значит, надо менять свой выбор на 3, вероятность успеха 2/3.
Так же и с сыном: нам предъявляют младшего или старшего ребёнка на свой выбор (в зависимости от того, кто из них сын). Если оба сына, то без разницы, кого предъявить. Получается, 1/3, что оба сына.
Понял свою ошибку: нам предъявляют не конкретного ребёнка (старшего или младшего), а того, который обладает нужным полом. Тогда, действительно, очень похоже на 1/3.
Что если ввести понятия старший/младший (или первый/второй). И может быть два равновероятных случая: в качестве сына упоминался старший либо младший ребёнок.
50%, что предъявили старшего. Тогда из 4 исходных комбинаций подходят 2: мальчик/мальчик, мальчик/девочка.
50%, что предъявили младшего. Тогда из 4 исходных комбинаций так же подходят 2: мальчик/мальчик, девочка/мальчик.
(50%*50%) + (50%*50%) = 50%.
Иначе говоря, если девочка/мальчик и мальчик/девочка считаются по какой-то причине разными случаями, то и мальчик/мальчик должны рассматриваться как два случая. Нам могли как бы упомянуть первого, а могли — второго (младшего).
Но ведь это не так экономично, как ENUM, что критично когда строк много. ENUM значение занимает 4 байта, даже если там длинный текст.
Не совсем: переехали из чатов в таблицы. CRM как была, так и осталась, просто там больше работают админы, которые назначают уроки и пр. Нужную отчётность в ней не получить без дополнительных разработок.
Из систем была только CRM, в которую, к тому же, не все данные можно ввести. То есть, всё равно требовалось ещё где-то недостающие данные вводить, чтобы потом строить отчёт. В этом плане Google Таблицы гибко совмещают как ввод, так и отчётность. С некоторыми компромиссами, конечно.
Там не видно всех столбцов — дальше ещё колонки с расходами и др.
В таблице УК сейчас данные от менеджеров агрегированы по месяцам и импортируются в 26 колонок. При 400 менеджерах это будет работать примерно 80 лет (два с половиной года уже работает). Плюс, уволившиеся менеджеры не занимают строки в последующих месяцах, так что даже больше.
За инструменты спасибо — при случае попробую!
<deleted>
Конечно, примеры:
IMPORTRANGE(),
Apps Script | Условное форматирование
Дальше уже смотря нужно.
Где та грань, какой процент нейрослопа уже недопустим? И судьи кто?
Или из российских DNS его вдруг удалят, как YouTube.
UPD: потом подумал, что написал — это же не важно, .ru или .com... Тут уже не в доменной зоне проблема.
Точно.
Вот тут можно список регистраторов проверить, он там есть: https://cctld.ru/domains/reg/
Вот пример домена, зарегистрированного там: https://who.is/whois/debitoff.ru
Вариант А — от нейронки, Б — мой.
Прошло время, и я пришёл к тому же выводу.
Если интересно, вот тут описал проблемы этого кода и работу над ошибками.
Например, Beget. Раньше они регистрировали через Reg.ru, но 8 лет назад сами стали регистраторами. А Reg.ru тогда попытался не вполне красиво мои домены оставить у себя, пришлось проявить настойчивость.
Рефералка, если изволите.
Не отбивать тире пробелами — это американский стиль. Видимо, нейронки пытаются весь мир к такому стиль приучить.
Так проще и для пользователей, и для меня. Не нужно каждый раз залезать в код/базу для добавления менеджера, не нужно пилить интерфейс админа, который не добавляет ценности (и не оплачивается).
Вероятность утечки этого ключа примерно такая же, как вероятность утечки пароля к интерфейсу — я же его точно так же в сообщении отправлю.
Даже если ключ утечёт (вместе со взломом Tg-аккаунта менеджера), то пользы злоумышленнику от него никакой. Разве что насоздаёт ссылок на оплату, пока мы через базу его не забаним. Реквизиты получателя он изменить не может.
Да, то есть клиент переходит на web-страницу Тинькофф, там оплачивает. Чек тоже от Тинькофф придёт. А бот получает от Тинькофф вебхук об оплате.
Меня тут спросили, во сколько заказчику обошёлся сей бот.
Тайны нет: 30 000 рублей и ещё 9 000 рублей за добавление ежедневных сводок с количеством и суммой оплат.
Очень давно интересует такой момент: не приводит ли к преждевременному износу покрышек момент касания неподвижных колёс со взлётно-посадочной полосой при посадке?
Вроде бы, решение есть элементарное — крыльчатки поставить на них, чтобы от набегающего воздуха раскручивались.
В чём же тогда смысл штрафовать за долговечность лампочек отдельных производителей? Надо было тогда штрафовать за низкую яркость, если она ниже нормы.
Про сына: напомнило задачу про 3 двери. За одной из них приз, и ведущий знает, за какой. Вы выбрали первую. Ведущий показал, что за второй дверью ничего нет. Поменять свой выбор на третью дверь или остаться на своём?
В чём нюанс
Исходная вероятность угадать: 1/2.
Ведущий может выбрать, какую из дверей открыть. Он выберет случайно между 2 и 3, только если приз за 1 (вероятность 1/3). В других 2 случаях — у него нет выбора. Значит, надо менять свой выбор на 3, вероятность успеха 2/3.
Так же и с сыном: нам предъявляют младшего или старшего ребёнка на свой выбор (в зависимости от того, кто из них сын). Если оба сына, то без разницы, кого предъявить. Получается, 1/3, что оба сына.
Понял свою ошибку: нам предъявляют не конкретного ребёнка (старшего или младшего), а того, который обладает нужным полом. Тогда, действительно, очень похоже на 1/3.
Что если ввести понятия старший/младший (или первый/второй). И может быть два равновероятных случая: в качестве сына упоминался старший либо младший ребёнок.
50%, что предъявили старшего. Тогда из 4 исходных комбинаций подходят 2: мальчик/мальчик, мальчик/девочка.
50%, что предъявили младшего. Тогда из 4 исходных комбинаций так же подходят 2: мальчик/мальчик, девочка/мальчик.
(50%*50%) + (50%*50%) = 50%.
Иначе говоря, если девочка/мальчик и мальчик/девочка считаются по какой-то причине разными случаями, то и мальчик/мальчик должны рассматриваться как два случая. Нам могли как бы упомянуть первого, а могли — второго (младшего).