CHIMITDORZHI STUDIO

«Документы из УТ не выгружаются в Бухгалтерию». «В Бухгалтерии два одинаковых контрагента». «Остатки в базах разные, и никто не понимает почему». Так обычно звучит запрос. Бухгалтер закрывает месяц и находит реализации, которых нет. Или находит одну и ту же реализацию дважды. Кто-то начинает править руками, и расхождений становится ещё больше. Ниже расскажу, откуда берутся такие поломки и как я их разбираю. Первая причина — обновление. Одну базу обновили, вторую нет. Или обновили обе, но до разных релизов. Типовой обмен между УТ и Бухгалтерией рассчитан на совместимые версии. Когда версии расходятся, часть документов перестаёт выгружаться или выгружается с ошибкой. Вторая — ручные правки в обеих базах. Бухгалтер поправил документ у себя, а менеджер поправил тот же документ в УТ. При следующем обмене одна правка затрёт другую. Или документ станет недоступен для изменения, и обмен остановится на нём. Третья — дубли справочников. Контрагента завели в УТ и отдельно в Бухгалтерии. Обмен не

В конце месяца бухгалтер или менеджер садится с двумя файлами. Слева выписка, справа счета из учёта. Или остатки со склада и остатки на маркетплейсе. Он ищет каждую строку глазами, ставит галочки, красит ячейки. К вечеру устаёт и пропускает пару расхождений. Я пишу скрипты, которые делают такую сверку за минуты. Расскажу, как это устроено и что нужно, чтобы результат был надёжным. Самая частая задача — оплаты из банка против выставленных счетов. Нужно понять, какие счета оплачены, какие нет и откуда пришли деньги без счёта. Вторая — отгрузки против оплат. Товар уехал, а деньги не пришли. Или пришли, но меньше. Третья — остатки двух систем. Например, склад в 1С и остатки на площадке, где вы продаёте. Четвёртая — два прайса: ваш старый и новый от поставщика, или ваш и конкурента. Во всех случаях задача одна и та же. Есть два списка, их надо сопоставить построчно и показать, где они не сходятся. Чтобы найти пару строке из одного файла, нужен признак, который есть в обоих. Это и есть ключ.

Отдел продаж просит базу: все стоматологии города, все автосервисы области, все оптовые склады в регионе. Менеджер садится и выписывает компании из справочника руками. Через неделю у него пара сотен строк, половина с ошибками. Я собираю такие базы на заказ из открытых источников. Расскажу, откуда берутся данные, где граница допустимого и как сделать так, чтобы база реально работала в CRM. Главные источники — онлайн-карты и отраслевые справочники организаций. Компании сами размещают там карточки, чтобы их находили клиенты. В карточке обычно есть название, рубрика, адрес, телефон, сайт, часы работы. Второй источник — сайты самих компаний. Часто на сайте есть контакты, которых нет в справочнике, например общая почта отдела продаж. Третий — открытые сведения о юридических лицах. По ним можно проверить, что компания действует, и уточнить вид деятельности. Это помогает отсеять закрытые организации, которые ещё висят на картах. Общий смысл про парсинг на заказ и то, как он устроен, я разбирал

Селлер открывает карточки конкурентов по одной и переписывает цены в таблицу. На десяти позициях это терпимо. На сотне это полдня работы, и к вечеру данные уже устарели. Я делаю парсеры цен и остатков с маркетплейсов на заказ. Расскажу, как подготовить задачу, что собирать и чем разовая выгрузка отличается от ежедневной. Парсер не угадывает, кто ваши конкуренты. Ему нужен список. Есть два способа его составить. Список ссылок. Вы берёте свои позиции и к каждой находите несколько карточек конкурентов. Получается таблица: ваш товар, ссылки на похожие. Это самый точный вариант. Вы сравниваете именно то, что считаете аналогом. Список поисковых запросов. Вы задаёте запросы, по которым покупатель ищет товар. Парсер берёт первые позиции выдачи и собирает по ним данные. Так видно, кто стоит рядом с вами в поиске. Но в выдачу попадают и случайные товары, их приходится отсеивать. Собирать всё подряд не нужно. Каждое поле должно отвечать на вопрос, который вы задаёте себе при решении о цене или за

Во многих компаниях главная рабочая система — это таблица. Заявки, остатки, график смен, список клиентов. Люди каждый день делают в ней одно и то же: копируют строки, считают итоги, пишут письма по новой записи, вспоминают про сроки. Большую часть этого таблица может делать сама. Я пишу такие скрипты на заказ для Google-таблиц и для Яндекс-таблиц. Расскажу, что можно поручить таблице, где её предел и о чём договориться заранее. Автозаполнение. Менеджер вписывает номер заказа, а скрипт сам ставит дату, ответственного, статус и подтягивает данные клиента из соседнего листа. Человек заполняет одно поле вместо шести. Сводка из нескольких листов. У каждого филиала или сотрудника свой лист. Скрипт раз в час или по кнопке собирает их в общий свод. Руководитель смотрит один лист и не бегает по вкладкам. Письмо или сообщение по строке. Появилась новая заявка, поменялся статус, клиент отметил оплату. Скрипт отправляет письмо, сообщение в Telegram или уведомление в рабочий чат. Текст собирается и

Компания решила сменить CRM. Новая удобнее, дешевле или лучше подходит под процессы. Но в старой лежат годы работы: клиенты, сделки, договорённости. Страшно потерять базу, и переезд откладывается. Я переношу данные между CRM на заказ. Расскажу, что переносится легко, где подводные камни и как пройти переезд без остановки продаж. Контакты и компании — самая простая часть. Имя, телефон, почта, название, адрес. Почти любая CRM умеет выгрузить их в файл, а новая умеет загрузить. Сложность только в дублях и в том, как связать контакты с компаниями. Сделки сложнее. У сделки есть стадия, ответственный, сумма, связь с клиентом и история движения по воронке. Если воронки в старой и новой CRM разные, каждую стадию надо куда-то отнести. Задачи, заметки и переписка ещё сложнее. Их не всегда можно выгрузить стандартным экспортом. Часто их забирают через API, а потом записывают в новую систему как примечания. Файлы — отдельная работа: их скачивают и прикрепляют заново. Общие ловушки переноса данных

Руководитель хочет раз в неделю видеть простую картину: сколько пришло заявок, сколько сделок закрыто, кто из менеджеров как работает. В CRM это вроде бы есть, но отчёт собран не так, фильтры сбрасываются, а нужного разреза нет. В итоге кто-то в пятницу выгружает файл, чистит его и сводит руками. Я настраиваю автоматическую выгрузку из CRM в таблицу. Расскажу, как это устроено и где обычно ломается. Отчёты в CRM сделаны для всех сразу. Ваш бизнес считает по-своему. Например, выручку по дате оплаты, а не по дате закрытия сделки. Или конверсию только по заявкам с сайта. Или менеджеров вместе с их помощниками. В таблице можно посчитать что угодно формулами. Её легко показать партнёру, не давая доступ в CRM. К ней легко добавить данные из другого места, например расходы на рекламу. И руководителю не нужно учиться отчётам CRM, он работает в привычной таблице. Если в компании CRM связана с учётной системой, в таблицу можно тянуть и оплаты оттуда. Про такую связку я писал в статье amoCRM и 1С

Собственник хочет понять простую вещь: куда уходят деньги. Сколько в месяц съедает аренда, сколько реклама, сколько закупки. Ответ лежит в банковской выписке, но там сотни строк без всякой разметки. Кто-то раз в месяц открывает выписку и руками подписывает каждую строку. Это долго, скучно и каждый раз немного по-разному. Я настраиваю автоматическую разметку выписки по статьям. Расскажу, как это работает и где границы у такого инструмента. Почти любой банк умеет выгружать выписку в стандартном формате обмена с учётными программами или в таблицу. Такой файл удобен: у каждого платежа есть дата, сумма, контрагент, его ИНН и назначение платежа. Скрипт читает этот файл, а не скриншоты и не распечатки. Если счетов в разных банках несколько, выписки можно загружать все вместе. Скрипт сложит их в одну таблицу и пометит, с какого счёта пришла строка. Выгрузку можно делать руками раз в месяц или раз в неделю. Если банк даёт доступ к выписке по API, её можно забирать автоматически. Это зависит от

«Как связать 1С и Битрикс24, чтобы менеджер видел оплату в сделке». «Как не вбивать счёт второй раз». Такие вопросы я слышу постоянно. Продажи идут в Битрикс24, а деньги, склад и документы живут в 1С. Менеджер создаёт сделку, потом просит бухгалтера выставить счёт. Бухгалтер вбивает товары заново. Потом менеджер спрашивает, пришла ли оплата. Каждое такое действие занимает минуты, а за день набегают часы. Разберу, что именно связывают, где какая версия главная и на чём спотыкаются. Контрагенты. Компания из CRM должна совпадать с контрагентом в 1С. Иначе каждый новый счёт создаёт нового клиента, и сверка превращается в хаос. Номенклатура и остатки. Менеджер выбирает товар в сделке из того же списка, что ведётся в 1С. Видит цену и остаток, не звоня на склад. Счета и заказы. Сделка на нужной стадии создаёт в 1С счёт или заказ покупателя. Номер и сумма возвращаются в сделку. Статусы оплат и отгрузок. Когда в 1С пришла оплата или прошла реализация, сделка получает отметку. Менеджер видит это

Типичная картина. Менеджеру нужен договор. Он находит похожий в папке, открывает, меняет название клиента, реквизиты, сумму и сохраняет под новым именем. Иногда в тексте остаётся ИНН прошлого клиента или старая дата. Иногда номер договора повторяется. Ошибку находят, когда документ уже подписан или счёт оплачен не туда. Я делаю генераторы документов на заказ. Расскажу, как они устроены и где без человека не обойтись. В основе шаблон. Это обычный документ, где вместо конкретных данных стоят поля: название клиента, ИНН, адрес, сумма, срок, перечень услуг. Шаблон можно править в привычном редакторе, программировать для этого не нужно. Данные приходят из одного места. Это может быть строка в таблице, карточка сделки в CRM или форма, которую менеджер заполняет за минуту. Реквизиты клиента по ИНН можно подтянуть из открытых источников, чтобы не набирать их вручную. Генератор соединяет шаблон и данные. Он считает итоги, пишет сумму прописью, ставит номер и дату. Если услуг несколько, собирает