Рубрика: Автоматизация

Почти каждый, кто продаёт товары за наличные или картой, рано или поздно сталкивается с требованием выдавать фискальный чек. И тут начинается знакомое: одна программа — чтобы пробить чек, другая — чтобы вести учёт продаж и склада. Кассир бьёт чек в кассовом приложении, а потом кто-то вручную переносит ту же продажу в учётную систему. Две программы, двойной ввод и регулярные расхождения между тем, что в кассе, и тем, что в учёте.

Это не обязательно. Фискализацию можно сделать частью обычной продажи — чтобы чек шёл в налоговую прямо из той системы, где вы и так ведёте товары и деньги.

Что такое ПРРО простыми словами

ПРРО — это программный регистратор расчётных операций. Проще говоря, это «касса без железной кассы»: программа, которая регистрирует ваш чек в налоговой и возвращает фискальный номер. Вместо отдельного кассового аппарата вы пользуетесь сервисом фискализации, работающим через интернет.

В Украине два самых распространённых сервиса ПРРО — Вчасно.Касса и Чекбокс. Оба делают одно и то же: принимают данные о продаже, регистрируют чек в Государственной налоговой службе и возвращают фискальный чек, который можно проверить в реестре ГНС.

Если вы продаёте товары конечному покупателю, в большинстве случаев закон требует выдавать именно такой фискальный чек. Вопрос лишь в том, насколько удобно это делать.

Почему касса и учёт по отдельности — это лишняя работа

Классическая схема: продавец пробивает чек в кассовой программе, а вечером кто-то сводит эти продажи с учётом — чтобы списать товар, увидеть выручку, посчитать остатки. Пока операций мало, это терпимо. Когда их десятки в день:

• одна и та же продажа вводится дважды — сначала как чек, потом как движение в учёте;
• кассовое приложение не знает ваших остатков, а учёт не знает, что уже пробили на кассе;
• любая ручная сверка — это место, где рождаются ошибки.

Корень проблемы в том, что чек и учётная продажа — это на самом деле одна операция, которую искусственно разделили на две программы.

Как это работает в ERPJS

В ERPJS фискализация встроена в саму продажу. Вы оформляете продажу как обычно, а система сама отправляет чек в ПРРО — Вчасно.Кассу или Чекбокс на ваш выбор — и регистрирует его в налоговой. Никакого второго приложения и никакого ручного переноса.

Что происходит за один шаг:

• продажа проводится в учёте — товар списывается со склада, выручка попадает в финансы;
• чек автоматически идёт в налоговую через ваш ПРРО;
• система получает обратно фискальный номер и QR-код, по которому покупатель проверяет чек в реестре ГНС.

Подключение делается один раз: добавляете свою кассу, указываете ключ доступа от Вчасно.Кассы или Чекбокса и настраиваете соответствие ставок НДС. Дальше всё работает само.

Бумажный чек в магазине, электронный — для интернет-заказов

Тот же механизм закрывает два сценария. В офлайн-магазине покупатель получает привычный бумажный чек — с фискальным номером и QR-кодом. В интернет-магазине печатать ничего не нужно: чек электронный, покупатель получает ссылку на фискальный чек, так же зарегистрированный в налоговой.

Фискализируются все формы оплаты: наличные, карта через терминал и комбинированная оплата.

Не только чек: вся кассовая смена

• возврат товара — чек коррекции так же регистрируется в налоговой;
• открытие и закрытие смены, формирование Z-отчёта в конце дня;
• служебное внесение и выдача наличных из кассы.

Всё это — в одном окне, вместе с продажами и складом.

Если чек пробили вне системы

Бывает, что часть чеков пробили в другом месте — с мобильной кассы курьера или с телефона. В ERPJS есть импорт чеков из Вчасно.Кассы: система забирает чеки за период и сама создаёт по ним продажи. Ничего не выпадает из картины.

Главное

Когда ПРРО встроен в систему учёта, продажа, склад и фискализация — это одна операция, а не три. Меньше программ, никакого двойного ввода и всегда согласованная картина: что продали, что списали со склада и что зарегистрировали в налоговой.

Обязателен ли ПРРО для моего бизнеса?

В большинстве случаев, если вы продаёте товары конечному покупателю за наличные или картой, закон требует выдавать фискальный чек. Есть отдельные исключения для некоторых категорий предпринимателей, поэтому конкретно ваш случай стоит сверить с действующими требованиями ГНС. Если чек нужен — ERPJS позволяет выдавать его прямо из системы учёта.

Нужен ли кассовый аппарат, если есть ПРРО?

Нет. ПРРО (программный регистратор) заменяет классический кассовый аппарат: чек регистрируется в налоговой через интернет-сервис — Вчасно.Кассу или Чекбокс. Отдельное «железо» покупать не нужно.

Чем Вчасно.Касса отличается от Чекбокса?

Оба — это сервисы ПРРО, которые регистрируют чеки в налоговой. Для работы с ERPJS принципиальной разницы нет: вы выбираете удобный вам сервис и подключаете его. Интеграция работает и с тем, и с другим.

Как покупатель проверит, что чек настоящий?

На фискальном чеке есть QR-код и ссылка на чек в реестре Государственной налоговой службы. По ним любой может открыть чек и убедиться, что он зарегистрирован официально.

Можно ли выдавать электронные чеки для интернет-магазина?

Да. Для онлайн-продаж чек электронный — покупатель получает ссылку на фискальный чек, без печати бумаги. Это полностью соответствует требованиям к фискализации.

Что с возвратами и закрытием смены?

ERPJS регистрирует в ПРРО не только продажи, но и возврат товара, открытие и закрытие смены с Z-отчётом, служебное внесение и выдачу наличных — полный кассовый цикл в одной системе.

Продаёте на Rozetka и Prom, а заказы вручную переписываете в учётную программу? Остатки на маркетплейсе живут отдельно от реального склада, и время от времени вы продаёте то, чего уже нет? Это классический хаос мультиканальных продаж. Коротко: его снимает интеграция ERP с маркетплейсами — заказы сами попадают в учёт, а остатки и цены синхронизируются со складом без ручной работы. Ниже разберём, как это работает и на что обратить внимание.

Почему ручная работа с кабинетами маркетплейсов съедает прибыль?

Потому что каждый заказ проходит через человека дважды: сначала менеджер видит его в кабинете маркетплейса, затем вручную заводит в вашу учётную систему. Параллельно кто-то должен не забыть уменьшить остаток. При 30-50 заказах в день это часы рутины ежедневно плюс постоянный риск ошибки.

Самая дорогая ошибка — продажа «в минус». Пока менеджер не обновил наличие, маркетплейс продолжает принимать заказы на товар, которого уже нет. Дальше — отмена заказа, испорченный рейтинг продавца, а на некоторых площадках ещё и штрафные санкции. Один такой случай обходится дороже, чем месяц ручной синхронизации.

Вторая скрытая потеря — вы не видите реальной картины. Выручка в кабинете Rozetka, выручка в кабинете Prom, выручка в рознице — это три отдельных отчёта. Свести их в единую маржу с учётом комиссий, доставки и себестоимости вручную практически невозможно. Решения об ассортименте и ценах принимаются «на ощущениях», а не на цифрах.

Что такое интеграция ERP с маркетплейсом и как она работает?

Интеграция ERP с маркетплейсом — это прямой обмен данными между вашей учётной системой и площадкой через её API. Вместо ручного копирования данные ходят автоматически: заказы с маркетплейса попадают в учёт, а остатки и цены со склада выгружаются обратно на площадку.

ERPJS поддерживает два ключевых для украинского рынка маркетплейса — Rozetka и Prom.ua. Здесь важно различать два потока данных, потому что они работают по-разному. Заказы и новые покупатели попадают в учёт в реальном времени — менеджер видит их в системе сразу, без ручного ввода. А каталог товаров, остатки и цены синхронизируются по настроенному расписанию: это не мгновенный обмен, но тоже полностью без ручного труда. Ручной работы нет ни в одном из направлений.

Важно понимать границу ответственности. Маркетплейс — это витрина: он показывает товар покупателю и принимает заказы. ERP — это учёт: он хранит реальный склад, себестоимость, финансы и сводит все каналы продаж в одно место. Интеграция — это мост между витриной и учётом.

Как автоматический импорт заказов разгружает менеджера?

Заказ с маркетплейса в реальном времени становится документом в вашей учётной системе, а новый покупатель заводится в базу контактов без участия менеджера. Человек больше не переписывает данные — он сразу работает с заказом: комплектует, выставляет к отправке, формирует накладную.

В ERPJS полный цикл работы с заказами реализован прежде всего для Prom.ua: новые заказы подтягиваются автоматически вместе со статусами, а покупатели, которых ещё нет в вашей базе, создаются сами. Для Rozetka акцент сделан на синхронизации товарной части — каталога, цен и остатков (об этом дальше).

Что это даёт на практике: менеджер вместо «переписчика» становится оператором, который обрабатывает уже готовые заказы. Освобождённое время идёт на то, что действительно приносит деньги — быструю отправку, общение с клиентом, работу с повторными продажами. А когда заказ уже в учёте, его легко передать дальше по цепочке — например, сразу сформировать отправление через интеграцию с Новой Почтой, замкнув полный цикл «заказ → доставка».

Что даёт синхронизация остатков между складом и маркетплейсом?

Главное — один склад становится единым источником правды для всех каналов продаж. Продали товар в розничной точке или на другой площадке — наличие на маркетплейсе обновится при следующей синхронизации. Риск продать «в минус» резко падает, а вместе с ним исчезают отмены, штрафы и провалы в рейтинге.

ERPJS выгружает на маркетплейс не только факт наличия, но и количество, причём логику расчёта можно настроить под ваш процесс. Например, отдавать на маркетплейс весь физический остаток, или остаток минус уже принятые заказы, или остаток минус резервы. Это важно, если вы продаёте с одного склада одновременно в нескольких каналах и хотите держать страховой запас.

Цены синхронизируются так же: вы ведёте прайс в учётной системе, а на маркетплейс выгружается актуальное значение по выбранному прайс-листу. Не нужно править цену в трёх местах — изменили одну в учёте, и она разошлась по каналам. Это особенно ценно во время акций и быстрых переоценок. Если вы только наводите порядок со складом, начать стоит со складского учёта — без точных остатков любая синхронизация будет отдавать на маркетплейс неправильные цифры.

Зачем вести маркетплейсы через ERP, а не во встроенных кабинетах?

Потому что кабинет маркетплейса видит только свой канал, а ERP сводит все каналы вместе со складом и финансами. Кабинет Rozetka не знает о ваших продажах на Prom и в рознице; кабинет Prom не знает о себестоимости и затратах на доставку. Только в учётной системе вы видите реальную маржу по каждому товару с учётом комиссий маркетплейса, логистики и закупочной цены.

Это принципиальная разница в подходе. Встроенные инструменты маркетплейса оптимизированы под продажу на этой конкретной площадке. ERP оптимизирована под ваш бизнес в целом: сколько вы реально зарабатываете, какие товары тянут вас в минус после всех комиссий, где затоваривание, а где дефицит. Маркетплейс отвечает на вопрос «что продаётся», ERP — на вопрос «сколько я с этого имею».

Для розничного бизнеса, который выходит в онлайн, это особенно актуально: физическая точка и маркетплейсы должны жить с одного склада и одной учётной системы. Как понять, что ваш магазин уже дорос до такой автоматизации, мы разбирали в отдельном материале о программе учёта для магазина.

Что стоит учесть перед внедрением интеграции?

Главное — реалистичные ожидания относительно синхронизации остатков. Заказы и клиенты попадают в учёт в реальном времени, а вот каталог, остатки и цены обновляются по расписанию, а не мгновенно: между продажей в одном канале и обновлением наличия на маркетплейсе проходит интервал синхронизации. Для большинства бизнесов это некритично, но если вы торгуете дефицитными позициями с высоким оборотом, интервал стоит продумать отдельно.

Второе — интеграция требует настройки под ваш склад и прайсы. Базовый каркас обмена универсален, но тонкие правила — с какого склада брать остатки, какой прайс-лист выгружать, как именно создавать новых клиентов — настраиваются под ваш процесс. Это не «включил и работает из коробки», это проект по настройке, пусть и небольшой.

Третье — начинайте фазами. Сначала запустите синхронизацию остатков и цен (это снимает самое болезненное — продажу «в минус» и рассинхрон прайсов), затем подключайте автоматический импорт заказов. Так вы быстро получаете результат и не пытаетесь охватить всё сразу. Такой подход мы рекомендуем для любого внедрения ERP — подробнее о выборе системы в материале как выбрать ERP-систему.

Продаёте на Rozetka или Prom и устали от ручной синхронизации? Покажем на демо, как заказы с маркетплейсов будут попадать прямо в учёт, а остатки и цены синхронизироваться со складом автоматически. Оставить заявку на демонстрацию →

Представьте: вы три года пользуетесь ERP-системой. Все процессы настроены, сотрудники обучены, история сделок и документов — всё там. А однажды утром получаете письмо: «Сервис закрывается через 30 дней». Что вы делаете?

Это не теоретический вопрос. SaaS-сервисы для бизнеса закрываются регулярно — от небольших украинских стартапов до крупных международных продуктов. Для одних пользователей это означает 2-3 месяца хаоса и переобучения. Для других — полную остановку работы. В этой статье разберём, как «открытый код» в ERP защищает ваш бизнес от такого сценария — и чем наша модель отличается от классического open-source.

Что обычно означает «open-source ERP»?

Когда вы слышите «ERP с открытым кодом» — обычно имеются в виду крупные публичные проекты: Odoo Community, ERPNext, Dolibarr. У них общая модель:

• Публичный репозиторий на GitHub или GitLab — любой может скачать код
• Лицензия (GPL, AGPL, MIT) — формально разрешает использовать, модифицировать, распространять
• Сообщество — тысячи разработчиков по всему миру
• Самостоятельная установка — вы ставите систему на свой сервер, настраиваете, поддерживаете

Звучит идеально — но есть нюансы. Классический open-source ERP требует сильной IT-команды для внедрения и сопровождения. Для бизнеса на 10-50 человек это часто непосильно: нужен DevOps, БД-администратор, разработчики под вашу отрасль. Или вы нанимаете интегратора — и снова зависите от одного исполнителя.

Поэтому многие украинские компании выбирают SaaS — быстро, без своей IT-команды, с поддержкой «из коробки». Но SaaS возвращает вас к тому же vendor lock-in: ваши данные и процессы у вендора, и если что-то случится — вы снова в ситуации, с которой начинали.

Как работает доступ к коду в ERPJS

В ERPJS две опции работы, и каждая по-своему решает вопрос независимости:

Опция 1: SaaS на erpjs.biz. Вы регистрируетесь, получаете свою компанию в нашем облаке, начинаете работать в течение 15 минут. Код бизнес-логики на наших серверах — у вас к нему прямого доступа нет. Это быстрый старт, но полного контроля над системой у вас нет — вы зависите от нас как от SaaS-вендора.

Опция 2: On-premise установка на ваш сервер. Мы переносим ERPJS на ваш сервер — физический или облачный. И вот здесь начинается главное: код бизнес-логики — документы, процедуры, регистры, отчёты, формы, валидации — автоматически оказывается у вас на диске. Не как «доступ по запросу», не «пришлём архив когда захотите» — а как просто файлы на сервере, к которым у вас прямой доступ.

Бизнес-логика — это полноценный читаемый JavaScript. Не минимизированный, не обфусцированный. Любой JS-разработчик может открыть файлы, прочитать логику, понять что происходит. Системное ядро (фреймворк) при этом поставляется как собранная библиотека — как принято в Node.js-экосистеме. Это не ограничение: всю специфику вашей отрасли и процессы вы можете адаптировать без вмешательства в ядро.

Это не «open-source ERP» в классическом понимании — у нас нет публичного GitHub с тысячами контрибьюторов. Но это — техническая доступность бизнес-логики в ваших руках, что по факту даёт вам тот же уровень контроля над вашими процессами.

Что это даёт вам на практике?

Перейдём от теории к конкретике. Вот 4 следствия того, что код бизнес-логики у вас на сервере:

1. Любой JS-разработчик может работать с бизнес-логикой. Не нужен «сертифицированный ERPJS-консультант». Файлы .js бизнес-логики на вашем сервере — это обычный JavaScript. Нанимаете разработчика-фрилансера, штатного, аутсорсинговую компанию — любой вариант рабочий.

2. Не зависите от нашего roadmap. Нужна специфическая фича под вашу отрасль, а в нашем плане она запланирована на следующий год? Вы можете заказать её реализацию у любого разработчика, который работает с кодом. Не ждёте нас.

3. Имеете план Б на случай любых событий с ERPJS. Сервис закрылся, нас купила другая компания, война — неважно. Ваша система продолжает работать на вашем сервере. Поддержку обеспечивает тот разработчик, который у вас есть сейчас — или новый, которого вы найдёте.

4. Данные + код = полный контроль. Это принципиальная разница от чистого SaaS, где у вас есть только данные, но без кода вы не можете ничего изменить. И от чистого open-source без вендора, где у вас есть код, но вся ответственность на вас.

По такой же логике мы писали о том, когда Excel перестаёт работать — там тоже основной риск в отсутствии контроля. А если вы только выбираете ERP — наш гайд 7 критериев выбора поможет учесть независимость как один из пунктов.

SaaS или on-premise: какой вариант именно для вас?

Это не два этапа одного пути, как часто пишут. Это два разных продукта для разных сегментов — и выбирать нужно на старте.

SaaS подходит вам, если:

• Вы самозанятый, фрилансер, или у вас 1-3 человека в команде
• Одна точка: кофейня, салон, небольшой магазин, сервис
• Простой продуктовый каталог, простые процессы
• Вопрос контроля над кодом для вас не актуален — вам нужен быстрый старт, а не долгосрочная стратегия

На этом уровне vendor lock-in — теоретический риск: процессы у вас стандартные, объём данных ограничен, переключиться на другую систему при необходимости не будет катастрофой. Регистрируйтесь, начинайте за 15 минут, работайте.

On-premise — это правильный стартовый выбор, если:

• У вас производство, дистрибуция, сеть магазинов, СТО, склад
• 10+ сотрудников и несколько юрлиц
• Сложные процессы, специфическая отрасль, возможно — интеграции с другими системами
• Регуляторные требования (фарма, медицина, финансы) или корпоративная политика безопасности
• Вы понимаете, что зависимость от одного SaaS-вендора — это бизнес-риск

Здесь on-premise — это не «следующий уровень когда дозреете», а правильный выбор с самого начала. Чем раньше вы на собственном сервере, тем меньше переделывать при росте. И тем меньше риск, если что-то изменится у нас.

Переход с SaaS на on-premise остаётся технически возможным — например, если начинали небольшой командой на SaaS, а потом бизнес вырос. Данные переносятся с SaaS на on-premise и обратно — это тот же продукт, та же база. Но лучше не доводить до момента, когда «нужно было on-premise с самого начала».

Кто может делать вашу ERP кроме нас?

Вот тут история становится интересной для IT-компаний и разработчиков. Если у клиента on-premise — код у него, значит потенциально его может сопровождать и расширять любая внешняя IT-компания. Это создаёт пространство для сотрудничества. Три формата, которые мы видим реальными:

Формат 1: Реферал. Вы приводите клиента на ERPJS, мы его ведём. Ваша роль — продажа и первичная консультация.

Формат 2: Внедрение и кастомизация. Вы как IT-подрядчик: внедряете ERPJS у клиента, настраиваете под его процессы, дописываете специфические модули. Деньги получаете от клиента напрямую за свою работу. Код бизнес-логики у вас в руках через on-premise установку.

Формат 3: Self-hosted SaaS. Вы берёте код, разворачиваете свой SaaS под своим брендом — например, специализированную ERP для аптек, СТО, или салонов красоты на базе ERPJS. Это white-label вариант.

Конкретные условия сотрудничества для каждого формата — индивидуально, кейс-зависимо. Если вам интересно обсудить — напишите нам, разберёмся, как это может выглядеть в вашей ситуации.

Частые вопросы

Руководитель IT-студии в конце квартала сводит данные по проекту, который «шёл нормально». Выставлено клиенту 800 000 грн. Потрачено на него: зарплата команды 540 000, субподряд дизайнера 120 000, инфраструктура 25 000, переработка двух фич 85 000. Маржа — 30 000 грн, или 3,7%. А планировали 30%.

Проблема не в проекте — проблема в том, что этот расчёт сделан через три месяца после старта. Если бы руководитель видел реальную маржу на 5-й неделе, он бы переоценил скоуп, перенёс субподряд или остановил переработку. Но цифры жили в трёх системах: тайм-трекер для часов, Excel для бюджета, 1С для счетов. Свести их — отдельная работа на 4 часа в конце месяца, которую всегда не успеваешь сделать вовремя.

Учёт проектов в ERPJS решает это по-другому: бюджет, табели времени, расходы и выставление счетов — в одной системе, с рентабельностью в реальном времени. Разбираем, как это работает, что даёт малому бизнесу и где честные ограничения.

Почему без учёта проектов вы узнаёте об убытке только в конце?

У IT-студий, агентств, консалтинга, инженерных бюро есть типичный стек:

• Toggl / Harvest / Clockify — учёт времени команды
• Excel или Google Sheets — смета проекта, бюджет
• 1С / SAP / отдельная бухгалтерия — счета клиентам, ЗП, налоги
• Jira / Asana / Trello — задачи

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

Конкретные проблемы, которые создаёт разрозненность систем:

• Запоздалая диагностика. Маржа посчитана через 3-6 недель после фактических расходов. На этот момент уже невозможно что-то исправить — только зафиксировать.
• «Невидимые» расходы. Закупили субподряд на 50 000 грн — прошло через бухгалтерию, но не попало в смету проекта в Excel. В отчёт по проекту эти деньги не легли.
• Двойной ввод. Менеджер вводит часы в Toggl, потом переносит их в отчёт для клиента, потом бухгалтер создаёт инвойс. Один час — три ввода, ошибки на каждом шаге.
• Время незаметно утекает в «не оплачиваемое». Code review, митинги, переработка — часов много, а в инвойс клиенту они не идут. Без классификации времени невозможно увидеть соотношение продуктивный/непродуктивный.
• Выставление T&M-счёта — отдельный ритуал. Экспорт из Toggl, фильтрация, копирование сумм, ручной инвойс. 30-40 минут на проект в месяц.

Владелец студии с 10 разработчиками и 5 параллельными проектами теряет 8-12 часов в месяц только на сверку этих систем. И всё равно получает запоздалую картину.

Как ERPJS структурирует проект?

Проект в ERPJS — это отдельная карточка с обязательными атрибутами и живой связью со всем учётом компании.

Что хранится в карточке:

• Код и название — для быстрого поиска и привязки документов
• Клиент — ссылка на карточку контрагента; для внутренних проектов поле остаётся пустым
• Тип проекта — настраивается вами (например: разработка, поддержка, маркетинг, исследование)
• Фазы / этапы — отдельный справочник, с которым работает бюджет (об этом дальше)
• Команда — список участников и до пяти менеджеров (руководитель проекта, технический лид, аккаунт-менеджер, главный дизайнер и т.д.)
• Контактное лицо клиента — чтобы не искать в CRM
• Даты — старт, плановый финиш, фактический финиш
• Статус — активный / завершённый
• Иерархия — проект может быть подпроектом другого (для больших программ)

Карточка — это не просто паспорт, а узел: к ней привязываются бюджет, табели времени, закупки, инвойсы и задачи. Всё, что происходит с проектом, видно в одном месте.

Как планировать бюджет проекта с нуля?

Бюджет в ERPJS — это отдельный документ с матрицей работ и материалов. Не таблица в Excel — полноценный учётный документ с историей, версиями и утверждением.

Что идёт в бюджет:

• Услуги / работы (строки с количеством часов и ставкой)
• Товары и материалы (с ценой закупки и продажи)
• Разбивка по фазам — каждая строка привязана к этапу проекта
• Скидки для клиента

Система автоматически считает по бюджету:

• Сумма работ
• Сумма товаров и материалов
• Общая сумма контракта
• Ожидаемая прибыль
• Маржа в процентах
• Наценка

Бюджет поддерживает версии. Это важная деталь: вы делаете план А, потом после переговоров с клиентом — план B с сокращённым скоупом, потом финальный утверждённый вариант. Все версии сохраняются, можно сравнить что изменилось.

Отдельный статус «Утверждено» — пока бюджет не утверждён руководителем, он является черновиком. Утверждённый — становится базой для сравнения план/факт.

Как увидеть какое время реально идёт клиенту, а какое нет?

Этот вопрос задаёт себе каждый владелец IT-студии или агентства. Команда списала 200 часов на проект, инвойс на 200 часов клиенту — а маржа всё равно маленькая. Почему?

Потому что из тех 200 часов:

• Часть — митинги и обсуждения (не всегда оплачиваются клиентом)
• Часть — code review и переработка дефектов (редко оплачиваются)
• Часть — время на задержки, ожидание ответа клиента (накладные расходы)
• Часть — обучение нового разработчика на проекте (инвестиция, не доход)

В ERPJS в табелях времени каждая запись имеет не только проект и часы, но и класс времени — категорию, которую вы определяете сами. Это гибкий механизм: вы заводите такие классы, которые нужны именно вашему бизнесу.

Самые распространённые примеры того, как компании различают время:

• Продаваемое время — часы, которые пойдут в инвойс клиента
• Непродуктивное / не признанное клиентом — переработка, ошибки, время за пределами скоупа, которые клиент не оплатит
• Внутреннее — митинги, обучение, R&D, написание документации, корпоративные мероприятия
• Неиспользованное — простой, ожидание доступов или ответа клиента

Каждый класс можно привязать к отдельной ставке через прайс-лист клиента. Отчёт по табелям автоматически группирует данные по классам — и руководитель одним взглядом видит:

• Сколько часов из тех 200 реально пошли в инвойс
• Сколько «съелось» на переработку — это сигнал переоценить проект или переучить команду
• Сколько времени на внутрянку — это инвестиция, не убыток, но надо знать сколько

Отдельно — внутренние проекты. Для времени, которое не идёт клиенту вообще (R&D, внутренняя автоматизация, ваш собственный продукт) заводится проект без клиента. Время на него списывается теми же табелями, но в клиентскую аналитику не попадает. Так вы точно различаете: работа на клиентов отдельно, инвестиции в компанию — отдельно.

Классификацию определяете вы, а не навязанная структура. Мелкое агентство может иметь 2 класса (оплачиваемый / неоплачиваемый), большая IT-студия — 5-7 (разработка, code review, митинги, обучение, support, пресейл и т.д.). Табели утверждаются руководителем — в отчёты идут только утверждённые часы.

Какие расходы автоматически попадают в проект?

Расходы по проекту собираются из трёх источников и автоматически попадают в отчёт рентабельности:

1. Время команды. Все утверждённые табели умножаются на ставки сотрудников и дают общую стоимость труда на проекте. Если у вас разные классы времени — в расходы идут все (потому что труд — это факт), но в отчёте можно увидеть разбивку.

2. Закупки и подряд. Каждый входящий счёт (от субподрядчика, поставщика материалов, инфраструктуры) имеет поле «Проект». Если закупка создана из строки бюджета — проект подставляется автоматически, ничего выбирать не нужно. Если закупка отдельная (например, дополнительный тестировщик на спринт) — менеджер указывает проект при создании. Это стандартная логика привязки документов к аналитике.

3. Материалы со склада. Если в проекте используются материалы (оборудование для клиента, серверное железо, witnesses kits) — их движение фиксируется через списание со склада с привязкой к проекту.

Всё это собирается автоматически в отчёт «Информация по проекту» — без дополнительных выгрузок, без ручной сверки.

Как выставлять счета клиенту — Fixed Price или Time & Materials?

ERPJS поддерживает обе модели.

Fixed Price (фиксированная стоимость по фазам). Бюджет содержит строки работ, привязанные к фазам. Когда фаза завершена — создаётся инвойс из этих строк. Поле «Выставлено» фиксирует номер инвойса — потом видно, какие строки бюджета уже выставлены, а какие нет. Подходит для проектов с чётко определённым скоупом и поэтапной оплатой.

Time & Materials (по часам). Инвойс формируется из утверждённых табелей за период, умноженных на ставку. Отдельная процедура собирает все часы с классом «продаваемый» за выбранный месяц (или неделю) и создаёт инвойс с расшифровкой по дням. Эту процедуру можно вызвать вручную в конце месяца или поставить на крон — раз в месяц T&M-инвойсы генерируются автоматически из утверждённых табелей, руководителю остаётся только посмотреть перед отправкой клиенту.

Можно смешивать модели в одном проекте — например, fixed price за основные фазы + T&M за отдельный пул часов на поддержку.

Какой отчёт показывает рентабельность проекта в реальном времени?

Отчёт «Информация по проекту» — основной инструмент для руководителя. Он показывает по конкретному проекту или сводно по всем:

• Доход — сумма выставленных и запланированных инвойсов
• Расходы — время команды × ставки + закупки + материалы
• Маржа в деньгах — Доход минус Расходы
• Маржа в % — насколько прибыльный проект

Этот отчёт обновляется в реальном времени. Как только новая закупка проведена или табель утверждён — цифры меняются. Это значит: руководитель может открыть отчёт в любой момент недели и увидеть, как проект себя показывает сегодня, а не за прошлый месяц.

Можно построить отчёт по фазам — и увидеть, что первая фаза в пределах бюджета, а вторая уже превысила план на 20%. Это сигнал действовать сейчас, пока третьи и четвёртые фазы не повторили историю.

Сводный отчёт по всем активным проектам сразу показывает наименее прибыльные. Владелец одним взглядом видит, где команда теряет деньги, и может перепланировать ресурсы.

Как планировать загруженность команды вперёд?

Отдельный инструмент — Менеджер ресурсов, календарный планировщик с тремя режимами:

• Месяц — обзор загруженности команды на 30 дней вперёд
• Неделя — детализация по дням недели
• День — разбивка по часам внутри рабочего дня

Как это работает:

1. Сотрудники заводятся в системе как ресурсы — у каждого свой код, график работы, информация о роли
2. На проектах создаются задачи — с датами начала, дедлайном и списком исполнителей (один или несколько на задачу)
3. Каждая задача имеет тип — разработка, тестирование, митинг, дизайн, code review — типы настраиваются с цветами
4. Менеджер ресурсов автоматически отображает календарную сетку: строки — сотрудники, колонки — даты, цветные блоки в клетках — задачи по типу

Что видно сразу:

• Кто перегружен на следующей неделе (строка забита блоками)
• У кого есть свободное окно (пустые клетки)
• Как распределён тип работы по команде (например, не свалилось ли всё тестирование на одного человека)
• Кто на чём работает именно сегодня

Клик на день в месячном виде — переключает на часовую детализацию. Двойной клик на блок — открывает детали задачи (описание, проект, исполнители, статус).

Дополнительно — рабочий процесс задач: когда задача закрывается с определённым результатом, система автоматически создаёт следующую. Например: задача «разработка» закрылась → автоматически появляется задача «code review» с другим исполнителем. Или задача «тестирование» закрылась с результатом «требует доработки» → снова задача «разработка» оригинальному исполнителю. Это базовая автоматизация workflow без необходимости в отдельном Jira или Asana для малых команд.

Честные ограничения:

• Gantt-диаграммы с зависимостями между задачами «А не начнётся пока не закончится Б» — нет. Зависимости реализуются через автоматические переходы результатов (workflow), не через жёсткую привязку дат
• Поля «оценка трудоёмкости в часах» на отдельной задаче нет — только даты начала и конца. Длительность вычисляется из них. Если нужна точная оценка часов на каждую задачу — это ограничение текущей версии

Для команд до 30 человек с 5-15 параллельными проектами этого обычно достаточно. Если ваш стиль управления требует Gantt с критическим путём — пока ERPJS не этот выбор.

Как ERPJS интегрирует учёт проектов с финансами компании?

Это может быть самое важное отличие от специализированных PM-инструментов типа Jira или Asana. Учёт проектов в ERPJS — не отдельный модуль «сбоку», а часть финансового учёта компании.

Как это работает: каждый документ, привязанный к проекту (инвойс клиенту, закупка, табель времени, списание материалов) автоматически формирует проводки в плане счетов с аналитикой «Проект». Это значит, что:

• P&L по компании можно построить с разбивкой по проектам
• Cash Flow виден как в целом, так и по проектам отдельно
• Дебиторка по проектам — сколько клиентов должны именно за этот проект
• Не нужен параллельный учёт: одна цифра не может жить в системе проектов и не существовать в финансах

Это подход «единая правда» — в отличие от привычной комбинации Toggl + Excel + 1С, где каждая система знает только свою часть, а руководитель сводит их вручную.

Подробнее об основах финансового учёта можно прочитать в нашем посте о финансовом учёте, а об автоматизации управленческих отчётов — в статье об автоматизации управленческого учёта.

С чего начать: 30-минутный план запуска первого проекта

Реалистичный план: за один рабочий день у вас первый проект с табелями и бюджетом. Точнее, за 30 минут — минимальный скелет, дальше команда дозаполнит детали.

Шаг 1 (5 мин): создать проект. Карточка — код, название, клиент, даты, тип. Заполнить обязательные поля, сохранить.

Шаг 2 (5 мин): добавить команду. Выбрать из справочника сотрудников, которые работают над проектом. Назначить одного-двух менеджеров.

Шаг 3 (10 мин): запланировать бюджет. Создать документ бюджета проекта, добавить 5-10 основных строк работ (например, «разработка backend», «дизайн UI», «тестирование», «менеджмент»). Указать часы и ставки. Система посчитает сумму, маржу, наценку.

Шаг 4 (5 мин): настроить классы времени. Если ещё не заведены — создать 3-5 базовых классов («оплачиваемый», «внутренний», «переработка» — названия ваши).

Шаг 5 (5 мин): пригласить команду на ведение табелей. Показать интерфейс табеля времени. Сотрудник списывает часы по дням с указанием проекта, типа работы и класса времени.

Через неделю работы у вас первые утверждённые табели, первые расходы в проекте и первая картина рентабельности. Через месяц — стабильная аналитика по всем активным проектам.

Часто задаваемые вопросы

Менеджер интернет-магазина в 9:30 утра открывает почту: 25 новых заказов за ночь. На каждый нужно подготовить товар, упаковать — и создать экспресс-накладную на сайте Новой Почты. По 5-7 минут на ТТН: логин, форма, копирование адреса из заказа в отдельную вкладку, выбор отделения, описание груза, объявленная стоимость, тип оплаты. К обеду менеджер ещё не начал паковать — он только создал накладные.

Это типичная картина для малого и среднего e-commerce. 25 заказов × 6 минут = 2,5 часа ежедневно, которые можно вернуть себе — если программа учёта интегрирована с Новой Почтой напрямую. Разберём, как это реально выглядит в ERPJS — без обещаний «всё автоматически», а с конкретикой о том, что автоматизировано, а что нет.

Почему создание ТТН вручную убивает маржу малого магазина?

Ручная работа с ТТН на сайте Новой Почты — это не одна задача, а цепочка из пяти шагов. На каждом есть место для ошибки.

Сколько времени уходит на самом деле:

• Логин в кабинет НП — 30 секунд (иногда приходится восстанавливать сессию)
• Перенести данные из заказа в форму НП — 2-3 минуты (адрес, телефон, ФИО, вес, описание груза)
• Найти нужное отделение из 38 000+ — 30-60 секунд
• Рассчитать объявленную стоимость и наложенный платёж — 30 секунд
• Сохранить и распечатать маркировку — 30 секунд

В сумме 5-7 минут на одну ТТН — при условии что ничего не сломалось. Если в кабинете НП вылезла новая капча или медленно загрузилось отделение, можно добавить ещё минуту-две.

Типичные ошибки при ручном вводе:

• Не тот адрес. Менеджер скопировал адрес предыдущего клиента — посылка ушла другому человеку. Переадресация стоит денег и времени.
• Неправильная объявленная стоимость. Менеджер забыл добавить НДС или вписал цену одной единицы вместо всего заказа — клиент получает посылку с некорректной ценой, возникают вопросы при возврате.
• Потерянный номер ТТН. Менеджер создал накладную, но не вставил номер в заказ — через неделю клиент пишет «где моя посылка», и никто не знает, какая это ТТН.
• Дубль ТТН. Два менеджера на один заказ создали две накладные. Одну нужно удалять, деньги возвращать.

Для магазина с 30 ТТН в день это 2,5 часа работы менеджера + 1-3 ошибки в неделю. Ошибки стоят: переадресация — 50-80 грн, дополнительный контакт с клиентом — 10-15 минут менеджера, потерянный клиент — несколько сотен или несколько тысяч гривен упущенного LTV.

Как ERPJS создаёт ТТН из заказа одним кликом?

В ERPJS экспресс-накладная Новой Почты создаётся из заказа или из документа отгрузки. Менеджер открывает заказ → нажимает кнопку «Создать экспресс-накладную (НП)» → система формирует все поля из данных заказа и отправляет запрос в Новую Почту. Через 2-3 секунды ТТН готова, номер записан в заказе.

Ключевое отличие: менеджер не выходит из ERPJS. Не нужна отдельная вкладка браузера, отдельный логин, отдельные копипасты. Всё происходит в одном окне, где уже есть заказ, клиент, товары и цены.

Детали об учёте товаров от приёма до продажи — в нашем отдельном посте. Интеграция с Новой Почтой — это следующий уровень: продажа не только списывается со склада, но и сразу едет к клиенту с трекинговым номером.

Что заполняется автоматически, а что нужно ввести вручную?

Это вопрос, где честный ответ важнее обещания «всё автоматически». Разберём по полям.

Автоматически из данных отправителя:

• Город и отделение отправителя (из настроек вашего юр.лица в системе)
• Контактное лицо, телефон отправителя
• Тип груза (стандартный — «Товары»)
• Кто платит за доставку (из настроек: вы или клиент)

Автоматически из данных заказа:

• Объявленная стоимость = сумма заказа
• Наложенный платёж = сумма заказа (если клиент платит при получении)
• Юридическое лицо клиента — система распознаёт по наличию ЕГРПОУ в карточке контрагента
• Номер заказа привязывается к ТТН — потом видно, какая посылка для какого заказа

Вручную вводит менеджер:

• Город получателя (если это новый клиент, которого нет в базе)
• Отделение или полный адрес (отделение-отделение или адресная доставка)
• ФИО и телефон получателя (если нет в карточке клиента)

Если клиент постоянный и уже есть в базе с адресом и телефоном, менеджеру вообще почти ничего не нужно вводить — нажал кнопку, проверил, подтвердил. Создание ТТН занимает 20-30 секунд вместо 5-7 минут.

Как работают справочники городов и отделений — быстро или с задержкой?

Это важная деталь, которую часто не замечают при выборе системы. У Новой Почты 38 000+ отделений и почтоматов, сотни городов. Если каждый раз при выборе система ходит в API НП — поиск тормозит, особенно при слабом интернете.

В ERPJS всё наоборот: справочники хранятся локально. При настройке интеграции система один раз загружает полный каталог городов, отделений, типов груза, типов оплаты — и кладёт в свою базу данных. Дальнейший поиск мгновенный: менеджер начинает набирать «Льв» — система за долю секунды показывает Львов и все его отделения.

Обновление справочника — либо по нажатию кнопки в административном модуле, либо автоматически по расписанию (раз в неделю-две). Новые отделения появляются в системе без участия менеджера.

Что это даёт на практике:

• Поиск отделения занимает 2-3 секунды вместо 10-30
• Интеграция не зависит от доступности API НП в моменте — даже если у Новой Почты сбой, вы дальше можете готовить заказы, ТТН создастся позже
• Менеджер не отвлекается от основной работы на «загрузку справочника»

Как автоматически обновляются статусы доставки?

Создать ТТН — половина задачи. Вторая половина — знать, где она сейчас. В e-commerce это критично: клиенты спрашивают «где мой заказ», менеджер отвечает, маркетинг сегментирует клиентов по статусам доставки.

ERPJS периодически обращается к Новой Почте и опрашивает статус всех активных ТТН. Интервал настраивается — чаще всего устанавливают раз в 1-2 часа. Статус обновляется в заказе автоматически: «Принято в отправление», «В пути», «Прибыло в отделение», «Получено».

Как это выглядит в рабочем процессе:

• Менеджер открывает заказ — видит актуальный статус доставки без перехода в кабинет НП
• Можно построить отчёт «все посылки, которые доставляются более 5 дней» — и позвонить клиентам, предупредить
• Маркетинг настраивает автоматические письма клиентам — «ваша посылка прибыла в отделение», «вы её получили — оцените, пожалуйста, заказ»
• Бухгалтерия видит, какие заказы с наложенным платежом уже получены — деньги Новая Почта вернёт через 2-4 дня

Финальные статусы (доставлено, возвращено, отменено) система перестаёт опрашивать — нагрузка на API минимальная.

Поддерживается ли печать маркировок для термопринтеров?

Печать маркировки — отдельная история. Маленькие магазины печатают на обычном офисном принтере формата А4 — и это нормально. Магазины с объёмом 50+ посылок в день переходят на термопринтеры Zebra (печатают на самоклеящихся рулонах 100×100 мм), потому что это быстрее и дешевле — не нужен тонер, нет ограничений на распечатывание.

ERPJS поддерживает оба варианта:

• Печать экспресс-накладной (А4) — стандартная печать на обычном принтере. Подходит для офиса, где отправляют 5-20 посылок в день.
• Печать маркировки для термопринтеров (Zebra) — специальный формат для самоклеящихся этикеток. Накладная печатается одним нажатием, ярлык автоматически наклеивается на коробку.

Система фиксирует, что маркировка уже напечатана — можно увидеть, для каких заказов ещё не сделана наклейка, и за день обработать все одним пакетом.

Можно ли подключить несколько магазинов или юр.лиц?

У малого бизнеса часто бывает ситуация: одна ФОП для маркетплейса, другая ТОВ — для B2B-продаж. Каждая — отдельный кабинет в Новой Почте, свой API-ключ.

В ERPJS таких отправителей можно подключить сколько угодно. Каждый — отдельная запись в настройках интеграции со своим API-ключом, типовым городом, отделением, настройками. При создании ТТН менеджер выбирает, от какого юр.лица отправлять посылку — или это автоматически определяется в зависимости от заказа (например, B2C → ФОП, B2B → ТОВ).

Это особенно полезно, если вы масштабируетесь — добавляете новый бренд, новый канал продаж, новое юр.лицо. Не нужно переходить в другой кабинет, пароли разные и так далее — всё живёт в одной системе.

Какие типы доставки поддерживаются?

Поддерживаются все основные режимы Новой Почты:

• Отделение-Отделение — стандартный вариант для большинства заказов
• Отделение-Адрес — курьерская доставка до двери клиента
• Адрес-Отделение — забор курьером от вашего офиса или склада
• Адрес-Адрес — полная курьерская логистика
• Наложенный платёж — клиент платит при получении, вы получаете деньги от НП через 2-4 дня
• Предоплата — посылка идёт уже оплаченной, без блокировки средств
• Возврат товара — отдельный тип документа для рекламаций со стороны клиента

Честно об ограничениях: изменение отделения уже созданной ТТН через API не экспонировано в форме. Если клиент после отправки попросил изменить пункт получения — это нужно сделать через кабинет НП. Это планируется к добавлению в следующих версиях.

Что с бухгалтерским учётом услуг доставки?

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

Почему так: проводки зависят от того, кто платил за доставку (вы или клиент), каким способом (оплата с карты, со счёта), как это отражается в реестре НДС. Универсальной логики нет — у каждой компании своя схема учёта услуг доставки.

Что это означает на практике:

• Менеджер создаёт ТТН — интеграция работает автоматически
• Бухгалтер раз в месяц получает от НП отчёт и вносит итоговую проводку
• Через интеграцию уже видно, на какую сумму услуги НП за период — отчёт помогает сверить со счётом от НП

Это тот же подход, что и у большинства ERP-систем — автоматизировать операционную работу (создание ТТН, статусы) и оставить бухгалтеру полный контроль над тем, что уже попадает в Главную книгу.

С чего начать интеграцию — план на полчаса

Реалистичный план подключения Новой Почты к ERPJS — менее чем за рабочий день:

Шаг 1 (5 минут): получить API-ключ. Зайти в свой кабинет Новой Почты → Настройки → API → создать новый ключ. Скопировать.

Шаг 2 (5 минут): добавить отправителя в ERPJS. В настройках интеграции вставить API-ключ, выбрать город, типовое отделение, контактное лицо. Сохранить.

Шаг 3 (5-10 минут): загрузить справочники. Нажать кнопку «Обновить справочники НП» — система подтянет все города, отделения, типы груза. Делается один раз на установку.

Шаг 4 (10 минут): тестовая ТТН. Создать один заказ, попробовать создать ТТН. Проверить, что номер появился, маркировка печатается.

Шаг 5 (опционально): добавить автоматическое обновление статусов. В административном модуле поставить обновление раз в час-два. Это делается один раз.

После этого интеграция готова к промышленной эксплуатации. Менеджеры продолжают работать в привычных заказах, но кнопка «Создать ТТН» убирает 5-7 минут ручной работы на каждую посылку.

Что это даёт в результате

Через месяц работы с интеграцией Новой Почты владелец магазина получает:

• ✅ Экономия 2-3 часов работы менеджера ежедневно (для магазина с 30 ТТН/день)
• ✅ Меньше ошибок в адресах и данных — всё подтягивается автоматически из карточки клиента
• ✅ Привязка каждой ТТН к конкретному заказу — поиск статуса занимает секунды
• ✅ Автоматические статусы доставки в реальном времени — клиенты получают ответ быстро
• ✅ Печать маркировок пакетом за день — менеджер работает партиями, а не по одной посылке
• ✅ Поддержка нескольких юр.лиц или магазинов в одной системе
• ✅ Отчёты по доставкам для анализа: среднее время, количество возвратов, география

Если у вас больше 10 посылок в день — ручное создание ТТН на сайте НП уже стоит дороже, чем интегрированная система. Для 30+ посылок интеграция окупается за первую же неделю.

Если вы только запускаете магазин или планируете переход — начинайте с учёта товаров и базовой программы учёта магазина, а интеграцию с Новой Почтой добавляйте, когда объём доставок станет критическим для времени команды. POS-касса с онлайн-фискализацией — отдельная история, её мы разбирали в посте об интегрированной POS-кассе.

Часто задаваемые вопросы

Прокат техники без системы живёт в Excel-таблице и блокноте: непонятно, у кого конкретная единица, забыто когда проводить регламентное ТО, а спорные случаи о повреждениях остаются «ваше слово против моего». В ERPJS есть отдельный модуль «Аренда», который закрывает весь цикл — от заявки клиента до плана обслуживания — и связывает все документы между собой.

Почему Excel и блокнот не справляются с прокатом оборудования?

Excel не отличает «10 перфораторов» от «перфоратор Bosch SN-001, SN-002, SN-003». Невозможно вести историю конкретной единицы — кто, когда, с какой наработкой. Блокнот фиксирует бронирования, но не показывает конфликты и не напоминает о ТО.

5 типичных проблем прокатчика с парком в 50 единиц:

• Двойные бронирования — заявка принята на уже забронированную дату
• Спор с клиентом о повреждениях — не задокументировано состояние при выдаче
• Пропущенное регламентное ТО — перфоратор отработал 150 часов без обслуживания, ломается у следующего арендатора
• Ошибки в счетах — аренду на 18 дней выставили как 17, или забыли
• Решение «ремонтировать или списать» вслепую — нет истории единицы и дохода за год

Что должна закрывать система учёта аренды оборудования?

6 функций в одном цикле: каталог единиц, бронирование с валидацией, договор аренды с периодом и ценами, акты выдачи/возврата с фиксацией состояния, план регламентного ТО, автоматические счета по периодам. ERPJS закрывает это в модуле «Аренда».

Как выглядит каталог единиц в ERPJS?

Каждая единица аренды (Rental Object) — отдельная карточка: код + серийный номер, производитель, модель, год, локация, тип счётчика (HOURS / KM / CYCLES / NONE) и стартовое значение. Статусы: AVAILABLE / RESERVED / RENTED / MAINTENANCE / DECOMMISSIONED. Опционально — привязка к Основному средству.

Модуль универсален — используется не только для оборудования. Квартиры, авто, выставочное оборудование, контейнеры, залы — любая долгосрочная аренда. Базовая логика одна. Для почасовой записи (на услуги) — есть отдельный модуль бронирования.

Как увидеть загрузку парка — Менеджер ресурсов

ERPJS не позволяет создать бронирование на период, когда объект уже зарезервирован — это валидация на уровне кода. Поэтому в системе нет «конфликтов бронирования» — их невозможно создать.

Чтобы менеджер быстро находил свободные слоты, есть Менеджер ресурсов — визуальный календарь с режимами месяц / неделя / день. Каждый ресурс — отдельная строка, цветные блоки — забронированные периоды. Менеджер открывает календарь, видит свободные слоты и резервирует там.

Как устроены заявки и договор аренды?

Цикл начинается с Заказа на аренду (статусы DRAFT → CONFIRMED → CONVERTED → CANCELLED) — мягкий документ, фиксирует запрос клиента без резервирования. При подтверждении конвертируется в Договор аренды — основной документ модуля.

Тип договора: OUTGOING (даём клиенту) или INCOMING (берём в аренду от поставщика — модуль двухсторонний). Договор имеет 3 вкладки: Объекты аренды (с ценами и периодом), Обслуживание (план ТО), План оплаты (график счетов).

Статусы: DRAFT → ACTIVE → SUSPENDED / CLOSED / CANCELLED. При подтверждении (OK) система резервирует объекты на даты, договор переходит в ACTIVE. Можно приостанавливать (SUSPENDED — на время внепланового ремонта) и возобновлять. Договор автоматически закрывается (CLOSED) когда все объекты возвращены.

Из меню документа доступны действия: Создать счёт, Рассчитать план оплаты, Создать Акт выдачи/возврата, Приостановить, Отменить.

Как работает регламентное обслуживание — вкладка «Обслуживание»?

Регламентное ТО — критическая фича для прокатчика. Без него техника ломается у клиента в середине аренды.

В Договоре аренды есть отдельная вкладка «Обслуживание» со списком регламентных работ. Для каждой заполняются:

• Тип сервиса — например, «замена щёток», «чистка воздухозаборника»
• Описание работ — детали
• Интервал — в календарных днях ИЛИ по показанию счётчика (например, «каждые 100 мото-часов»)
• Плановая и последняя дата
• Статус: PLANNED → IN_PROGRESS → DONE
• Кто платит: CLIENT (клиент отдельно) или INCLUDED (входит в стоимость аренды)

Интервал по счётчику работает на реальной наработке: при возврате техники новое показание сравнивается со стартом — и когда разница превышает интервал, система сигнализирует «пора ТО».

Выполнение сервисных работ — через отдельный модуль «Сервисное обслуживание».

Как настраивается стоимость и выставляются счета?

Цена задаётся всегда за день — из прейскуранта. Период аренды (день/неделя/месяц + количество) — это не тариф, а частота биллинга: определяет как часто выставлять счёт.

Пример: цена 500 грн/день, период «месяц», аренда на 90 дней → 3 счёта по месяцу. Или: цена 200 грн/день, период «неделя», аренда на 21 день → 3 еженедельных счёта.

Настраивается также момент выставления: в начале периода (предоплата) или в конце (постоплата). Во вкладке «План оплаты» виден график счетов со статусами PLANNED → ISSUED → PAID. Команда «Создать счёт» формирует инвойс из стандартного модуля Sales.

Оплата — через счёт-фактуры и предоплаты. POS и фискальные чеки для аренды не используются — аренда не розничная продажа. Контроль финансов — через управленческий учёт (план/факт поступлений, задолженность клиентов).

Как фиксируется состояние техники при выдаче и возврате?

Акт выдачи (Rental Issue Act): кондиция при выдаче, аксессуары и комплектация, показание счётчика, фото (как attachments документа). Клиент подписывает — юридический документ.

Акт возврата (Rental Return Act): новое показание счётчика (разница = наработка), кондиция при возврате, описание повреждений, отсутствующие части, целевой статус — AVAILABLE (в пул для следующих аренд) или MAINTENANCE (сразу в ремонт без промежуточных операций).

Если менеджер указал повреждения или отсутствующие части, или целевой статус MAINTENANCE — автоматически активируется флаг «Есть замечания». В перечне возвратов сразу видны проблемные позиции.

При любом споре с клиентом — подписанный акт с зафиксированным состоянием. Не «ваше слово против моего».

AI-агент и MCP для прокатчика

ERPJS поддерживает MCP-протокол — AI-агент имеет прямой доступ к системе на чтение и запись. Менеджер проката спрашивает агента в Telegram без перехода в интерфейс:

• «Какие единицы свободны с 15 мая?»
• «Когда ТО для SN-001?»
• «Создай Заказ на аренду перфоратора SN-001 с 15 по 17 мая»

Документы создаются как черновики с подтверждением от пользователя. Реальный кейс — AI-агент создал 3 документа из одного сообщения в Telegram.

Часто задаваемые вопросы

Владельцу магазина часто предлагают два инструмента отдельно: кассовую программу «для пробивания чеков» и программу учёта «для бухгалтерии». Работает, но каждую продажу нужно дважды вводить. В этом посте разберём, почему это больше не работает и как выглядит интегрированная POS-касса с онлайн-фискализацией через Checkbox в системе ERPJS.

Почему отдельная кассовая программа больше не вариант?

Сценарий из жизни: кассир пробил чек на 5 единиц товара. Кассовая программа отправила фискальный чек в налоговую — всё хорошо. Но товар на складе не уменьшился, потому что складская программа — отдельная. Бухгалтер вечером импортирует данные с кассы через Excel, ошибки в SKU, часть чеков потерялась. К концу месяца остаток расходится на 30 единиц.

Отдельная кассовая программа имеет 4 системные проблемы:

• Двойной ввод. Каждую продажу нужно учитывать дважды — в кассе и на складе
• Разрыв во времени. Остаток на складе не обновляется в real-time, только после импорта
• Потерянные чеки. Если что-то не импортировалось — продажа «есть в кассе, нет в учёте»
• Отчёты не сходятся. Бухгалтерские и операционные данные живут в разных системах

Интегрированная POS-касса решает это архитектурно: продажа на кассе — это одновременно чек в налоговую, списание со склада и запись в кассовой книге.

Как работает онлайн-фискализация через Checkbox?

Checkbox — это сервис программных регистраторов расчётных операций (ПРРО), который заменяет классический кассовый аппарат для украинских ФОП и ООО.

Логика работы:

1. Кассир делает продажу в POS-интерфейсе
2. POS формирует данные чека (товары, цены, НДС, способ оплаты) и отправляет в Checkbox API
3. Checkbox регистрирует чек в налоговой (ГНС) и возвращает фискальный номер
4. POS печатает чек с фискальным номером или отправляет клиенту в электронном виде

Всё происходит за 2-3 секунды. Без кассового аппарата, без печатной ленты, без связанных расходов на обслуживание. Чек имеет полную юридическую силу.

РРО vs ПРРО — в чём разница?

Что даёт POS, интегрированная с учётом?

Каждый чек в POS, интегрированной с учётом ERPJS, одновременно делает три вещи:

1. Списывает товар со склада. Остаток обновляется мгновенно. Если у вас 2 точки — система фиксирует, с какого склада списано.

2. Передаёт чек в Checkbox для фискализации. Налоговый номер появляется в системе, чек имеет юридическую силу.

3. Формирует запись в кассовой книге с валютой, способом оплаты, маржей. Бухгалтер вечером видит готовый отчёт продаж за день — без импорта, без обработки.

Подробности про учёт товаров от приёмки до продажи — в отдельном посте. А реальный пример того, как аналитика продаж выявляет аномалии — в нашем кейсе.

Какие функции обязательны на кассе для розницы?

Базовый набор POS-интерфейса для розничного магазина:

• Быстрые кнопки — топ-20 товаров одним нажатием, без поиска
• Сканер штрих-кодов — поиск товара по EAN/UPC, автодобавление в чек
• Поиск по названию — fallback, если штрих-код не считался
• Скидки и акции — % или фиксированная сумма на позицию или весь чек
• Несколько способов оплаты — наличные, карта, Apple/Google Pay, бонусы
• Частичная оплата — половина наличными, половина картой (один чек)
• Возврат товара — отдельный тип чека со ссылкой на оригинал
• Электронный чек на email/SMS — клиент получает копию без бумаги
• Смена продавца — в середине дня (подотчётность)
• Z-отчёт — закрытие смены в одно нажатие

В ERPJS POS-интерфейс работает как на ноутбуке продавца, так и на планшете/смартфоне. Один интерфейс — без разницы на устройстве.

Как настроить POS в ERPJS — за один день

Поэтапный план для магазина, у которого склад в ERPJS и нужно только добавить кассовый слой:

Шаг 1 (30 мин): регистрация в Checkbox. Зайти на checkbox.ua, завести ФОП/ООО, получить API-токен. Документы из налоговой — стандартные.

Шаг 2 (15 мин): подключение Checkbox в ERPJS. В настройках ERP вставить токен, выбрать кассу. Тестовый чек на 1 грн — чтобы проверить фискализацию.

Шаг 3 (1-2 ч): настройка быстрых кнопок. Перетащить топ-20 товаров в POS-интерфейс. Один раз — дальше редактируется по необходимости.

Шаг 4 (30 мин): подключение оборудования. Сканер штрих-кодов через USB или Bluetooth. Если есть фискальный принтер — тоже подключаем.

Шаг 5 (1 ч): тренировка кассира. 5-10 тестовых продаж, возвраты, Z-отчёт. Кассир осваивает интерфейс за 30 минут — он понятен.

Шаг 6: рабочий день. Первый реальный день — наблюдайте за скоростью, адаптируйте кнопки. Через неделю POS работает «невидимо».

Сколько стоит переход на онлайн-фискализацию?

Запуск: 0 грн. Регистрация в Checkbox бесплатна, подключение в ERPJS — стандартная функциональность.

Подписки на месяц:

• Checkbox: бесплатная модель доступна для ФОП на упрощённой. Платные планы — от ~150 грн/мес
• ERPJS: бесплатный тариф для старта, платные — по количеству пользователей и модулей

Оборудование (опционально):

• Сканер штрих-кодов — от 800 грн (USB), 2 000 грн (Bluetooth)
• Принтер чеков — от 2 500 грн (опционально, можно без — электронные чеки)
• Подставка/держатель для планшета — 500-1 500 грн

Магазин, который стартует с нуля, выходит на рабочее состояние за 5-10 тыс. грн оборудования + подписки от 150-500 грн/мес. Для сравнения: классический РРО = 10-15 тыс. грн + ежемесячное обслуживание 500-1 000 грн.

Что это даёт в результате

За три месяца с интегрированной POS-кассой владелец магазина получает:

• ✅ Точный остаток на складе в реальном времени — без еженедельных ревизий «на глаз»
• ✅ Отчёт продаж за любой период — одна кнопка, без Excel
• ✅ Маржинальность по товарам и группам — видно, что приносит прибыль
• ✅ Кассовая книга — без ручного импорта, готова для бухгалтерии
• ✅ Электронные чеки — клиенты получают копию даже если потеряли бумажную
• ✅ Экономия на оборудовании — минус 10-15 тыс. грн по сравнению с РРО

Для полного обзора — наш недавний пост «Программа учёта для магазина: 5 признаков, что пора автоматизировать».

Частые вопросы

«ERP — это для крупных корпораций, нам это не нужно». Это самый распространённый миф среди владельцев малого бизнеса. Реальность другая: современные ERP-системы давно масштабируются под бизнес любого размера — от 3 сотрудников до 500. И часто именно малому бизнесу ERP нужна больше всего, потому что ресурсов на ошибки в учёте у него меньше.

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

Что такое ERP и чем она отличается от обычной программы учёта?

ERP (Enterprise Resource Planning) — это единая система, объединяющая учёт, склад, финансы, продажи, производство и другие бизнес-процессы в одной базе данных. Главное отличие от отдельных программ: все модули работают с одинаковыми данными в реальном времени.

Простое сравнение:

• Отдельные программы: складская программа + бухгалтерия + Excel для продаж + CRM. Данные между ними не синхронизированы, приходится вручную дублировать, отчёты не сходятся.
• ERP-система: продали товар → автоматически списано со склада → автоматически сформирована проводка → клиент видит обновлённый баланс в CRM. Одно событие — все модули обновились.

В ERPJS 16 модулей: учёт товаров, склад, продажи, закупки, финансы, производство, CRM, сервис, POS-касса, бронирование, аренда, проекты, HR, интеграции (Новая Почта, Checkbox), отчёты. Все работают в единой базе.

Нужна ли ERP малому бизнесу сейчас, или это для крупных?

Короткий ответ: если вы узнали себя хотя бы в 2 из 5 признаков ниже — ERP вам уже нужна. Это не про размер компании, а про сложность процессов.

5 признаков, что ERP уже нужна:

1. Больше 100 SKU на складе. Ручной учёт 100+ позиций перестаёт быть надёжным — остатки расходятся, пересортица становится нормой.
2. Команда 5+ человек работает с учётом. Когда один Excel-файл редактирует несколько человек одновременно — версии начинают конфликтовать.
3. Excel-файл с 10+ вкладками. Если ваш главный учёт — это 15 взаимосвязанных листов Excel, это уже не таблица, а шаткая самодельная ERP без контроля целостности.
4. Вы не знаете реальную прибыль за прошлый месяц. Чистая прибыль считается руками неделю после закрытия периода — это признак разорванных данных.
5. Есть несколько каналов продаж. Сайт + маркетплейс + офлайн + звонки = если заказы собираются отдельно, вы теряете контроль над остатками.

Когда Excel перестаёт справляться — мы подробно разобрали в статье «Excel vs ERP: когда таблицы перестают работать».

Сколько стоит ERP для малого бизнеса?

Диапазон рыночных цен для малого бизнеса — от 0 до 200 USD в месяц на всю компанию. Конкретные опции:

В ERPJS есть бесплатный тариф без ограничения времени — это позволяет малому бизнесу начать без затрат и масштабироваться постепенно. Когда бизнес растёт — переходите на платный тариф, но данные и настройки остаются.

С каких модулей начинать внедрение ERP?

Главное правило для малого бизнеса: не внедрять всё сразу. Постепенный подход — от самой болевой точки к полному циклу. Вот проверенная последовательность:

Этап 1 (месяц 1-2): склад + продажи. Заведите каталог товаров, внесите остатки, начните выписывать документы продажи через систему. Это уже даст контроль над остатками и чёткие первичные документы.

Этап 2 (месяц 3-4): закупки + финансы. Добавьте документы поступлений, контрагентов, банковские выписки. Теперь у вас закрытый цикл «закупка → склад → продажа → оплата».

Этап 3 (месяц 5-6): CRM + аналитика. Подключите учёт клиентов, воронку продаж, отчёты. На этом этапе вы начинаете получать реальную картину бизнеса.

Этап 4 (при необходимости): производство, бронирование, POS, HR. Специализированные модули включаются тогда, когда есть соответствующая потребность в бизнесе.

Подробнее о том, с чего начинать диджитализацию бизнеса, мы писали отдельно. А принципы учёта для малого бизнеса — в этой статье.

Чем ERP лучше набора отдельных программ?

Типичный «зоопарк» в малом бизнесе: 1С для бухгалтерии + Excel для склада + amoCRM для продаж + Google Forms для бронирования + Telegram для коммуникации с клиентами. Выглядит рабочим, но имеет 4 системные проблемы:

• Двойной ввод данных. Заказ надо внести в CRM, потом вручную списать со склада в Excel, потом провести в бухгалтерии. 3 входа для одного события — времени тратится втрое больше.
• Нет единой правды. Сколько у нас на складе? Excel говорит 48, склад говорит 45, 1С говорит 50. Кому верить?
• Невозможна реальная аналитика. Чтобы увидеть прибыль по клиенту, нужно свести данные из 4 систем — это работа на полдня вместо кнопки «отчёт».
• Риск потери данных. Google Forms может отключить доступ, сотрудник уволился с правами на Excel — часть данных недоступна.

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

Какие риски внедрения ERP для малого бизнеса?

Честно — риски есть, и о них надо знать заранее. Вот три основных:

Vendor lock-in (привязка к вендору). Классические ERP с закрытым кодом держат ваши данные в проприетарных форматах. Если цена выросла вдвое — вам некуда уйти. В ERPJS бизнес-логика открыта: данные ваши, экспорт возможен в любой момент, партнёр или ваш программист может самостоятельно дорабатывать систему.

Сложность миграции данных. Перенести 500 товаров, 2000 контрагентов и остатки из Excel — это работа на 1-2 недели. Решение: начинать с импорта через Excel-шаблоны (ERPJS их поддерживает) и поэтапного внесения.

Сопротивление команды. Сотрудники привыкли к старым процессам и сопротивляются новому. Решение: внедрение через «агента изменений» (один человек ведёт проект), постепенное подключение модулей, обучение перед стартом.

Все три риска управляемые, если выбрать правильную систему и не пытаться внедрить всё за месяц.

Как выбрать ERP-систему для малого бизнеса?

5 практических критериев для выбора:

1. Постепенное внедрение. Проверьте, можно ли начать с 1-2 модулей и наращивать. Big-bang внедрение для малого бизнеса опасно.
2. Украинская локализация. НДС, Единый налог, Checkbox, Новая Почта — всё должно работать «из коробки», а не через костыли.
3. API для интеграций. Сайт, маркетплейс, платёжный агрегатор — система должна подключаться к вашим каналам.
4. Открытый код или ясные условия лицензирования. Что будет, если вендор поднимет цену вдвое? Ваши данные мигрируются? Можете вы или партнёр доработать систему самостоятельно?
5. Поддержка, понимающая ваш бизнес. Малому бизнесу нужна поддержка, понимающая украинские реалии — не «тикет в Индию на 3 суток».

ERPJS удовлетворяет всем 5 критериям: постепенное внедрение (16 модулей включаются отдельно), полная украинская локализация, открытое API, открытый код бизнес-логики, украинская поддержка и партнёрская сеть.

Частые вопросы

Ваши клиенты записываются через телефон, Viber, Instagram Direct? Вы ведёте расписание в блокноте или Google Calendar? Тогда вы точно знаете эти проблемы: забытые заявки, двойные записи на одно время, сотрудники не знают о новых клиентах. Есть решение — автоматизация записи через сайт.

В этой статье разберём, как онлайн-бронирование работает в ERP-системе и почему это эффективнее отдельных приложений для записи.

Почему мессенджеры и блокноты не работают для записи клиентов?

Когда бизнес маленький — 5 клиентов в день — блокнот справляется. Но при росте начинаются проблемы:

• Клиент написал в Viber, а вы забыли перенести в расписание. Результат — клиент пришёл, а его не ждали.
• Два клиента записаны на одно время. Вы проверяли свободные слоты по памяти, а не по системе.
• Сотрудник не знает о заявке. Клиент записался вчера вечером через мессенджер — а мастер узнал, только когда клиент стоит перед ним.
• Нет истории клиента. Что заказывал в прошлый раз? Какие были пожелания? Кто его обслуживал?
• Финансы отдельно. Запись в одном месте, оплата в другом, материалы в третьем. Невозможно понять рентабельность услуги.

Знакомо? Тогда пора переходить на автоматизированную запись. Как мы рассказывали ранее — Excel и мессенджеры перестают работать при масштабировании.

Как работает онлайн-бронирование в ERPJS?

ERPJS имеет встроенный модуль бронирования, который позволяет клиентам записываться через ваш сайт. Вот как это работает:

Шаг 1: Клиент открывает форму записи на вашем сайте. Видит свободные даты, время, услуги и специалистов. Выбирает удобный слот и оставляет контактные данные.

Шаг 2: Система автоматически распределяет ресурсы. Проверяет занятость выбранного специалиста, учитывает длительность услуги, блокирует слот для других клиентов.

Шаг 3: Сотрудник получает уведомление. Через Telegram, email или внутри системы — в реальном времени. Не нужно проверять расписание вручную.

Шаг 4: Клиент получает подтверждение и напоминание. Автоматическое напоминание за день или за час до визита — меньше «не пришёл».

Посмотрите, как это выглядит на практике, в нашем видео-обзоре модуля бронирования.

Что получает бизнес от автоматизации записи?

Онлайн-бронирование — это не просто удобство для клиента. Это инструмент, который решает конкретные бизнес-задачи:

Чем это лучше отдельных приложений для записи?

На рынке десятки приложений для онлайн-записи: Calendly, Booksy, Altegio. Они хорошо решают одну задачу — запись. Но у них общая проблема: они не связаны с учётом.

В ERPJS бронирование — часть единой системы:

• Запись → Заказ на обслуживание. Из бронирования автоматически создаётся рабочий наряд для сотрудника с перечнем работ.
• Услуга → Материалы. Система списывает расходные материалы (запчасти, краска, средства) со склада. Вы знаете себестоимость каждой услуги.
• Оплата → Финансы. Счёт клиенту создаётся из услуги. Оплата попадает в Главную книгу. Прибыльность — автоматически.
• Клиент → CRM. Вся история взаимодействия в одном месте: звонки, визиты, заказы, счета, оплаты.

Отдельное приложение для записи — это ещё один инструмент, не связанный с остальными. ERP-система — один инструмент для всего.

Для каких бизнесов подходит онлайн-запись?

Модуль бронирования в ERPJS подходит для любого бизнеса, где есть запись на время + сотрудник/ресурс:

• Сервисные центры — запись на ремонт техники, распределение между мастерами. Подробнее о сервисных услугах.
• Салоны красоты и барбершопы — запись к конкретному мастеру, учёт материалов (краска, средства).
• Медицинские клиники — запись к врачу, история пациента, напоминания о визите.
• Спортивные клубы — бронирование занятий, тренеров, залов.
• Автосервисы — запись на ТО, распределение по подъёмникам, учёт запчастей.
• Прокат/аренда — бронирование оборудования на конкретные даты и время.

Как подключить онлайн-запись на свой сайт?

Процесс настройки занимает несколько часов:

1. Создайте каталог услуг. Внесите перечень услуг, длительность каждой, стоимость. Например: «Замена экрана iPhone — 1 час — 2500 грн».

2. Добавьте специалистов. Укажите кто выполняет какие услуги и график работы каждого сотрудника.

3. Настройте ресурсы. Если у вас есть оборудование (подъёмник, кресло, кабинет) — добавьте его как ресурс с расписанием доступности.

4. Вставьте форму на сайт. ERPJS предоставляет виджет или ссылку на форму бронирования, которая встраивается на ваш сайт.

5. Настройте уведомления. Выберите как уведомлять сотрудников (Telegram, email) и клиентов (SMS, email).

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

Частые вопросы