JoomInvoice - Расширение Joomla

Руководство по JoomInvoice: счета, предложения, PDF, оплаты и клиентский доступ в Joomla

JoomInvoice нужен не как декоративное дополнение к сайту, а как рабочий центр для счетов, коммерческих предложений, оплат, контактов и документов внутри Joomla. В этом руководстве разберём, как подойти к установке, какие настройки проверить первыми, как собрать понятный процесс выставления счёта, как подключать письма, PDF и онлайн-оплату, а также как диагностировать ситуации, когда статус оплаты, письмо или документ ведут себя не так, как ожидалось.

Материал не повторяет краткую карточку продукта. Смысл руководства - показать, как превратить компонент в аккуратный процесс: подготовить Joomla, проверить права и почту, создать контакт, заполнить счёт или quote, настроить шаблоны, проверить PDF, включить напоминания и протестировать платежный путь до того, как отправлять реальные документы клиентам.

У JoomInvoice есть несколько зон, которые легко недооценить: отдельный PDF-шаблон, настройки писем, плагины оплаты, HikaShop-поиск товаров, поведение гостевого доступа, cron-задачи для напоминаний и права доступа в Joomla. Если их не проверить заранее, компонент может формально установиться, но рабочий сценарий сломается на мелочи: письмо уйдёт без вложения, PDF будет выглядеть иначе, чем веб-просмотр, а оплаченный счёт не получит ожидаемый статус.

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

Какую задачу решает компонент и где он уместен

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

По официальной странице продукта компонент поддерживает управление invoices, quotes, contacts, payments, taxes, currencies, products, recurring invoicing, discounts, custom templates, экспорт в CSV, Excel и PDF, а также интеграции с несколькими сторонними расширениями Joomla. Документация отдельно раскрывает Stripe webhook, email notifications, PDF generation и HikaShop integration. Поэтому JoomInvoice стоит воспринимать не только как генератор PDF, а как связку из четырёх рабочих слоёв.

Четыре слоя, которые нужно держать в голове

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

Второй слой - клиентский доступ. Клиент должен увидеть документ в публичной части сайта или по защищённой гостевой ссылке, если такой сценарий включён. В changelog отмечена переработка гостевого платежного опыта с auth code и отдельным видом завершения оплаты, поэтому доступ к документу нельзя считать мелкой деталью.

Третий слой - документы и письма. JoomInvoice может отправлять письма по счетам, предложениям, подтверждениям оплаты и напоминаниям. PDF-часть строится через отдельный PDF layout, потому что движок PDF работает не как обычный браузер. Это важно для шаблонов: красивый HTML-просмотр не гарантирует такой же PDF.

Четвёртый слой - оплата и подтверждение статуса. Если используются Stripe, PayPal или другой платёжный плагин, счёт должен не только показать кнопку оплаты, но и получить корректный статус после события. Для Stripe документация прямо рекомендует webhook, потому что возврат клиента на сайт после оплаты не всегда надёжен.

Кому JoomInvoice подходит

Компонент уместен для небольших агентств, сервисных компаний, B2B-магазинов, учебных проектов, клубов, сайтов услуг и Joomla-магазинов, где нужно выставлять счёт до оплаты или отправлять quote перед утверждением. Он хорошо подходит, когда администратор хочет управлять документами в Joomla и не выносить клиентов в отдельную SaaS-систему.

Отдельно стоит выделить сценарии с ручными заказами. Если клиент пишет по почте, телефону или форме, администратор может создать счёт вручную, добавить позиции, отправить PDF или ссылку, затем отметить оплату или принять её через платежный плагин. Для HikaShop-сайтов полезна интеграция, которая подтягивает название товара, код, описание и цену из каталога через dedicated search plugin.

Кому лучше поискать другой подход

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

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

Что проверить перед установкой и первым запуском

Перед установкой расширения Joomla полезно проверить не только архив компонента, но и рабочую среду. Официальная документация Joomla напоминает, что расширения устанавливаются через системный установщик, а компоненты затем появляются в меню компонентов. Для JoomInvoice это только начало: из-за PDF, платежей и писем среда должна быть готова к нескольким типам операций.

Платформа и совместимость

По официальным источникам и changelog JoomInvoice развивается под современные ветки Joomla, включая Joomla 4, Joomla 5 и Joomla 6. Но перед установкой всё равно проверьте фактическую совместимость вашей сборки: версия Joomla, PHP, база данных, шаблон, включённые плагины, расширения магазина и способ обновления. Если сайт обновлялся с более старой ветки, лучше сначала протестировать компонент на копии.

Практичный минимум перед установкой:

• Сделайте резервную копию файлов и базы данных сайта.
• Проверьте, что установка ZIP-архивов через Joomla работает на тестовом расширении или в staging-копии.
• Убедитесь, что у администратора есть права на установку расширений и настройку компонента.
• Проверьте, что почта Joomla уже отправляет тестовые сообщения через рабочий SMTP или другой настроенный транспорт.
• Если планируются онлайн-оплаты, убедитесь, что сайт доступен по HTTPS и публичный адрес не меняет www/non-www через неожиданную переадресацию.

Без staging-копии не начинайте с живых клиентов. Для счётов, писем и оплат тестовая среда особенно важна: ошибка в шаблоне или webhook может проявиться только после действия клиента.

Права доступа и роли сотрудников

Joomla ACL позволяет ограничивать доступ по группам пользователей на уровне глобальных настроек, компонентов и отдельных объектов. Для JoomInvoice это важно, если счета будут создавать не только суперпользователи. Минимальный рабочий подход - выделить отдельную группу для менеджера счетов и проверить, какие действия ей доступны: просмотр компонента, создание, редактирование, публикация, отправка писем и изменение настроек.

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

Почта, PDF и временные папки

Документация по email notifications указывает, что JoomInvoice может использовать глобальные почтовые настройки Joomla, а также отдельные поля отправителя в своей конфигурации. Там же отмечено, что временные PDF-вложения сохраняются в папку, настроенную для создания временных PDF, и эта папка должна быть доступна веб-серверу для записи. Поэтому до реальной отправки проверьте три вещи: письмо уходит, PDF прикрепляется, временная папка не ломает процесс.

Если письма Joomla уже проходят, но письма JoomInvoice не приходят, причина может быть не в компоненте, а в шаблоне письма, адресе клиента, спам-фильтре, доменной политике отправителя или размере PDF-вложения. Эти проверки лучше выполнить на отдельном тестовом клиенте с понятным email-адресом.

Установка в Joomla и первичная проверка компонента

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

Безопасная последовательность установки

1. Откройте админ-панель Joomla под пользователем с правами установки расширений.
2. Перейдите в системный раздел установки расширений и выберите загрузку ZIP-пакета.
3. Дождитесь сообщения Joomla об успешной установке и прочитайте дополнительные уведомления, если они есть.
4. Откройте меню компонентов и найдите JoomInvoice.
5. Проверьте список установленных плагинов, связанных с JoomInvoice, особенно если вам нужны Stripe, HikaShop или другие интеграции.
6. Откройте конфигурацию компонента и сохраните её без изменений, если интерфейс предлагает базовые значения. Так проще увидеть, что настройки доступны и не возникает ошибок записи.

После установки не включайте все платежи и автоматические письма сразу. Сначала создайте минимальный тестовый документ без оплаты. Это отделит проблемы установки от проблем платёжного шлюза. Если компонент не открывается или показывает ошибку, включать платёжные плагины бессмысленно: нужно сначала проверить установку, зависимости, права и журнал ошибок Joomla.

Первый тестовый счёт

Создайте контакт с безопасными тестовыми данными, затем создайте счёт на одну простую позицию: название услуги, количество, цена, налог или отсутствие налога, срок оплаты. Не используйте реального клиента на этом этапе. Цель - увидеть, что форма сохраняется, счёт получает номер, позиции пересчитываются корректно, preview открывается, PDF скачивается, а email можно отправить тестовому получателю.

Проверка первого счёта должна закрыть цепочку ввод данных - логика компонента - вывод результата - проверка - исправление. Если позиция не сохраняется, ищите проблему в форме, правах или обязательных полях. Если PDF не скачивается, переходите к настройке PDF-шаблона и папки. Если письмо не приходит, проверяйте почту Joomla и шаблон email. Если публичная ссылка не открывается, смотрите права доступа, пункт меню и маршрутизацию.

Что считать успешным первым запуском

Первичный запуск успешен, если администратор может открыть список счетов, создать контакт, сохранить счёт, посмотреть его в админке, скачать PDF и отправить тестовое письмо. Онлайн-оплату пока можно оставить выключенной. Такой результат показывает, что базовый учёт, документы и email-слой работают. Только после этого стоит переходить к Stripe, PayPal, HikaShop, recurring invoices и автоматическим напоминаниям.

Настройка после установки: что включать первым

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

Реквизиты, валюта и налоговая логика

Для счетов особенно важны стабильные базовые данные. Проверьте название компании, адрес, email отправителя, валюту, формат сумм, налоги и скидки. Официальная страница продукта заявляет управление taxes и currencies, а changelog фиксирует исправления, связанные с расчётом налогов и dropdown по tax. Это значит, что налоговые настройки нельзя оставлять наугад: одна неверная ставка может испортить сумму в документе.

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

Номера документов и сроки оплаты

Счёт должен иметь понятный номер и срок оплаты. В changelog отмечалась возможность задавать default due date days для новых счетов. Это полезно, если большинство документов имеет одинаковый срок. Но перед включением проверьте, как компонент рассчитывает дату при дублировании счёта и при recurring invoicing, потому что старые записи changelog также упоминали перерасчёт due date при повторении.

Практический подход: задайте базовый срок, создайте новый счёт, затем продублируйте его и проверьте, не перенеслась ли дата так, как вам не подходит. Если в вашей компании сроки меняются от клиента к клиенту, не полагайтесь только на default value. Сделайте поле срока частью ручной проверки перед отправкой.

Шаблоны счёта, quote и письма

JoomInvoice поддерживает custom invoices and quotes templates. В документации по email уведомлениям описаны темы и тела писем с placeholders, а в changelog отмечалась переработка панели template tokens. Это значит, что шаблоны - не косметика. Они управляют тем, какие данные клиент увидит в письме, PDF и публичном просмотре.

Начинайте с небольших изменений: логотип, название компании, приветствие, короткое объяснение способа оплаты, подпись и контакт для вопросов. Не переписывайте весь шаблон сразу. После каждого изменения скачайте PDF и отправьте письмо на тестовый адрес. Если placeholder не заменился, верните шаблон к последней рабочей версии и проверьте, поддерживается ли этот token именно в нужном типе письма или документа.

Безопасная настройка логотипа в PDF

Документация по PDF generation рекомендует загрузить логотип в media/com_joominvoice/, указать filename в поле Company Logo и использовать в PDF-шаблоне путь вида <img src="/{company_logo}" width="300" />. Размер лучше задавать явно, потому что PDF-движок не всегда ведёт себя как браузер. Если логотип не появляется, проверьте файл, путь, права доступа и то, что редактируется именно PDF layout, а не только веб-шаблон.

Письма и напоминания

Email notifications покрывают отправку счетов, предложений, payment confirmations, quote status notifications и unpaid invoice reminders. Но автоматические напоминания не стоит включать до проверки базовой почты и шаблона. Сначала отправьте один счёт вручную. Потом проверьте письмо quote. После этого можно включить уведомления о принятии или отклонении quote, если такой сценарий используется.

Для unpaid invoice reminders документация указывает cron job URL и параметр количества писем за один запуск. Это важная защита от внезапной массовой рассылки. Для первого запуска поставьте небольшой лимит, проверьте несколько тестовых просроченных счетов и убедитесь, что в письмах есть корректная ссылка на документ и payment link, если он нужен.

PDF и шаблоны: почему документ отличается от веб-просмотра

PDF в JoomInvoice - отдельная зона, потому что компонент использует dompdf для преобразования HTML в PDF. Документация прямо объясняет, что PDF layout отличается от обычного веб-браузера: нет flexbox и grid, JavaScript не выполняется, внешние стили не используются, а базовый табличный layout и inline CSS надёжнее. Это один из самых важных практических моментов руководства.

Как проектировать PDF без лишнего риска

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

Для границ и отступов лучше выбирать простые значения. Документация рекомендует inline styles, явные widths для table cells and images, pt units для borders и тестирование после изменений. Это не значит, что PDF должен выглядеть старомодно. Это значит, что дизайн должен быть устойчивым к ограничениям движка PDF.

Язык документа и спецсимволы

В changelog и документации отмечено, что PDF invoice/quote может использовать язык документа, а не язык сайта или админки. Для сайтов с клиентами из разных стран это полезно: администратор может работать в одном языке, а документ для клиента выводить в другом. Но это нужно проверить на реальном шаблоне: подписи, валютные символы, названия полей и текстовые блоки должны заменяться корректно.

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

Проверка PDF перед отправкой клиенту

После правки шаблона используйте маленький чек-лист:

• Скачайте PDF из админ-панели для тестового счёта.
• Откройте PDF в браузере и отдельной программе просмотра.
• Проверьте логотип, таблицу позиций, итог, налог, скидку и условия оплаты.
• Отправьте письмо с PDF-вложением на тестовый адрес.
• Проверьте, что файл прикрепился, а временная папка не вызывает ошибок записи.

Не оценивайте PDF только по preview в админке. Preview помогает быстро увидеть данные, но финальный клиентский документ - это PDF и письмо. Именно их нужно проверять перед запуском.

Оплаты Stripe, PayPal и подтверждение статуса

Официальная страница JoomInvoice заявляет приём онлайн-оплат через PayPal, Stripe и другие платежные варианты. На практике главная задача не в том, чтобы кнопка появилась на странице счёта, а в том, чтобы компонент получил достоверное подтверждение и обновил статус. Для Stripe документация даёт подробный сценарий с API keys, режимом Test/Live, webhook endpoint и troubleshooting.

Почему Stripe webhook лучше включать до запуска

Без webhook платёж может быть обработан только после возврата клиента на сайт. Документация по Stripe предупреждает: если клиент закрыл браузер до возврата, payment может не записаться как оплаченный. Webhook решает эту проблему, потому что Stripe отправляет событие на URL сайта отдельно от поведения клиента. Поэтому для реальной оплаты webhook - не украшение, а часть надёжности.

Для тестового режима используйте тестовые ключи и тестовые карты Stripe из документации. После успешной оплаты проверьте два места: статус счёта в JoomInvoice и запись платежа в Stripe Dashboard. Если в Stripe платёж есть, а счёт не стал Paid, ищите проблему в webhook URL, signing secret, доступности endpoint, HTTPS или переадресации домена.

Что проверить в настройках плагина оплаты

Логика настройки обычно такая:

1. В Joomla Plugin Manager найдите платежный плагин JoomInvoice, например Stripe.
2. Включите плагин только после базовой проверки компонента.
3. Выберите Test mode для первой проверки.
4. Введите publishable key и secret key из тестового режима.
5. Включите webhook, если платёжный сценарий должен надёжно менять статус.
6. Создайте endpoint с точным URL, который показывает документация, заменив домен на свой.
7. Проверьте совпадение www/non-www, HTTPS и отсутствие лишних параметров.

Не вставляйте secret key в публичные страницы, шаблоны, письма, статьи, тикеты или скриншоты. В руководстве это звучит очевидно, но именно ключи и webhook secrets часто случайно попадают в переписку при отладке. Храните их только в настройках плагина и в панели платёжного сервиса.

Гостевая оплата и доступ к счёту

Changelog JoomInvoice упоминает переработку guest payment experience с auth_code security и standalone payment completion view. Это важный сигнал: если вы даёте клиентам оплату без обычного входа в Joomla, тестируйте гостевой путь отдельно от пути залогиненного пользователя. Ссылка должна открываться только там, где это задумано, а после оплаты клиент должен видеть понятный результат.

Проверка гостевого сценария должна идти в отдельном браузере или приватном окне. Создайте тестовый счёт, отправьте ссылку, откройте её как гость, проверьте preview, payment button, возврат после оплаты и статус. Если ссылка ведёт на ошибку, проверьте пункт меню, маршрутизацию, access level, auth code и настройки компонента.

HikaShop и товарные позиции: когда интеграция экономит время

Интеграция JoomInvoice с HikaShop полезна для сайтов, где часть счетов создаётся вручную, но товары уже заведены в каталоге. Документация JoomBoost объясняет, что dedicated search plugin позволяет искать HikaShop products при создании invoice или quote и подтягивать product name, SKU/product code, description и current price. Это снижает ручной ввод и уменьшает риск ошибок в названии или цене.

Как работает сценарий с каталогом

Смысл интеграции простой: администратор создаёт invoice или quote, начинает искать товар, выбирает позицию из HikaShop, а JoomInvoice подтягивает базовые данные. После этого можно изменить количество, добавить услугу вручную, применить налог или скидку и отправить документ клиенту. Такой процесс подходит для телефонных заказов, B2B-заявок, коммерческих предложений на оптовые партии и случаев, когда покупатель не проходит обычный checkout.

Интеграция не отменяет проверку. Цена в HikaShop может зависеть от скидок, групп, вариантов товара или логики магазина. Документация говорит о current price, но конкретная бизнес-логика вашего каталога всё равно должна быть проверена на тестовом товаре. Особенно внимательно смотрите товары с вариантами, разными налогами, акциями и ручной корректировкой цены.

Настройка search plugin

Документация рекомендует установить JoomInvoice, включить JoomInvoice HikaShop search plugin в Plugin Manager и затем создать новый invoice с поиском товаров. Практически это означает, что после установки компонента нужно проверить не только сам компонент, но и соответствующий плагин. Если поиск товаров не работает, сначала убедитесь, что HikaShop установлен и активен, затем проверьте статус search plugin, права администратора и наличие товаров в каталоге.

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

Когда лучше не использовать интеграцию

Если документы не связаны с каталогом, а состоят из индивидуальных услуг, интеграция с HikaShop может не дать пользы. В таком случае проще завести reusable products в JoomInvoice или вводить позиции вручную. Если же магазин уже является главным источником цен, лучше использовать интеграцию, но сохранить ручную проверку перед отправкой. Счёт клиенту - это финальный документ, а не черновик каталога.

Практический пример: счёт для услуги с PDF, письмом и оплатой

Теперь соберём цельный сценарий. Представим сайт агентства на Joomla, которое продаёт настройку сайта и поддержку. Клиент согласовал работу по почте, а администратору нужно выставить счёт, отправить PDF, дать ссылку на оплату и проверить, что после тестовой оплаты статус стал Paid.

Цель

Получить рабочий процесс: контакт клиента сохранён, счёт создан с одной услугой и одной скидкой, PDF скачивается, письмо отправляется, ссылка открывается в публичной части, тестовая оплата проходит через Stripe Test mode, статус в JoomInvoice обновляется.

Подготовка

• JoomInvoice установлен и открывается в админ-панели Joomla.
• Почта Joomla проходит тестовую отправку.
• Шаблон PDF содержит корректные реквизиты и логотип.
• Stripe plugin включён в Test mode, webhook настроен, сайт доступен по HTTPS.
• Создан тестовый клиент с email, к которому у администратора есть доступ.

Шаги

1. Откройте JoomInvoice в админ-панели и создайте контакт клиента.
2. Создайте новый invoice, выберите контакт и заполните строку услуги, например "Website maintenance package".
3. Добавьте количество, цену, налог или режим без налога, затем проверьте итоговую сумму.
4. Если используется скидка, добавьте её отдельным правилом или полем, которое поддерживает ваша конфигурация.
5. Сохраните invoice и откройте preview.
6. Скачайте PDF и проверьте логотип, таблицу, сумму, срок оплаты и ссылку на оплату, если она есть.
7. Отправьте invoice по email тестовому клиенту.
8. Откройте ссылку из письма в приватном окне и проверьте, что гость видит только нужный документ.
9. Выполните тестовую оплату через Stripe test card.
10. Вернитесь в админ-панель и проверьте статус invoice и запись в payments.

Проверка результата

Результат считается успешным, если клиентское письмо понятно, PDF открывается, публичная ссылка не показывает лишние данные, кнопка оплаты ведёт в тестовый checkout, после оплаты invoice получает ожидаемый статус, а платёж виден в панели Stripe. Если один из этапов не сработал, не исправляйте всё сразу. Разделите проблему на слой: документ, письмо, публичный доступ, платёжный плагин, webhook или права.

Нюанс, который часто пропускают

Если счёт оплачен в Stripe, но JoomInvoice не обновил статус, не создавайте новый счёт и не просите клиента платить повторно. Сначала проверьте webhook delivery, signing secret, точный endpoint, HTTPS и редиректы домена. Если платёж подтверждён в Stripe, финансовая операция уже произошла, а задача администратора - восстановить связь статуса, а не повторять оплату.

Проверка результата после настройки

После настройки компонента нужен не один тест, а небольшая матрица проверок. JoomInvoice затрагивает разные сценарии: invoice, quote, PDF, email, payment, reminder, guest view, logged-in view и интеграции. Если проверить только один счёт в админке, можно пропустить проблему, которая проявится на стороне клиента.

Матрица рабочих проверок

Проверка после обновления

Changelog JoomInvoice показывает, что компонент активно меняет фильтры, гостевую оплату, PDF, Stripe, шаблоны, языковые пакеты и исправления статусов. После обновления не ограничивайтесь открытием админки. Повторите короткий сценарий: создать документ, скачать PDF, отправить письмо, открыть гостевую ссылку, проверить тестовый платёж или хотя бы webhook-логи, если платежи включены.

Особое внимание уделяйте изменениям, связанным с налогами, статусами и payment datetime. Если компонент исправлял сохранение payment datetime/status или duplicate tax calculation, после обновления нужно проверить документы с налогом и уже существующие платежи. Это не признак плохого компонента, а нормальная осторожность для финансового расширения.

Работа со списками, фильтрами и статусами документов

После первых тестов администратор обычно сталкивается не с созданием одного счёта, а с управлением списком: какие документы не отправлены, какие ожидают оплаты, какие оплачены, где просроченные invoices, какие quotes ещё не приняты и какие платежи нужно сверить вручную. В changelog JoomInvoice отдельно отмечалась переработка интерфейса фильтров invoices and payments с offcanvas drawer и chips display. Это полезное направление, потому что финансовый компонент быстро становится неудобным, если список нельзя отфильтровать по рабочему признаку.

Практически это значит, что после настройки стоит продумать не только форму создания документа, но и ежедневный экран менеджера. Человек, который открывает JoomInvoice утром, должен быстро понять, где срочные действия: отправить unsent invoice, проверить unpaid, напомнить по overdue, посмотреть accepted quote, сверить payment и экспортировать данные. Если фильтры настроены хаотично или менеджер не понимает статусы, компонент превращается в набор документов без управляемого процесса.

Какие статусы проверять в первую очередь

Точный набор статусов зависит от конфигурации и типа документа, но логика проверки обычно одинаковая. Для invoice важно различать черновик или неопубликованный документ, отправленный документ, ожидающий оплаты, оплаченный документ и проблемный случай, когда платёж есть, но статус не обновился. Для quote важны состояния отправки, принятия и отклонения. Для payments важны дата, метод, сумма и связь с конкретным invoice.

Если в команде несколько сотрудников, договоритесь о правилах. Например, кто имеет право переводить документ в paid вручную, когда можно отправлять reminder, кто проверяет webhook, кто исправляет ошибку в сумме и кто создаёт новый документ вместо правки старого. Статус в JoomInvoice должен отражать реальное состояние работы, а не быть декоративной меткой.

Фильтры как инструмент контроля, а не только поиска

Фильтры полезны не только для поиска старого счёта. Они помогают строить ежедневные мини-отчёты. Менеджер может отфильтровать неоплаченные счета, отдельно посмотреть recurring invoices, найти документы по клиенту или компании, проверить платежи за период и увидеть, какие quote требуют реакции. Если компонент показывает chips активных фильтров, это снижает риск забыть, что список сейчас ограничен условием.

После первого месяца использования сделайте короткую ревизию: какие фильтры команда использует постоянно, какие документы теряются, какие статусы непонятны, какие клиенты чаще требуют ручной проверки. На основе этого можно уточнить порядок работы: например, отдельный утренний просмотр unpaid invoices, отдельная еженедельная проверка recurring documents и отдельная сверка платежей с платёжным сервисом.

Экспорт данных

Официальная страница указывает export data to CSV, Excel and PDF. Экспорт полезен для сверки, передачи данных бухгалтеру или анализа задолженностей, но его нельзя считать заменой полноценного учёта. Перед регулярным экспортом проверьте, какие поля попадают в файл, как отображаются валюта, налог, скидки, статусы и клиентские данные. Если бухгалтеру нужны другие поля, лучше договориться о формате заранее, чем каждый раз исправлять выгрузку вручную.

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

Recurring invoices и повторяющиеся услуги

Recurring invoicing support на официальной странице JoomInvoice делает компонент полезным для услуг с повторяемой оплатой: поддержка сайта, сопровождение, аренда, ежемесячные пакеты, членские взносы или регулярные B2B-счета. Но повторяемость требует аккуратности. Ошибка в шаблоне, сроке оплаты или налоге будет воспроизводиться снова и снова, поэтому recurring invoices нужно запускать только после проверки обычного счёта.

Когда повторяемые счета действительно нужны

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

Для агентства или сервисной компании recurring invoices хорошо подходят для планов поддержки. Например, клиент оплачивает ежемесячное сопровождение Joomla-сайта. Администратор создаёт базовый invoice, проверяет PDF и письмо, затем настраивает повторение. После первого автоматического создания нужно вручную проверить новый документ: номер, due date, сумма, налог, email и статус публикации.

Автопубликация и сроки

В changelog упоминалась ability to autopublish new generated recurrent invoice и default due date days. Эти функции удобны, но включать их нужно осторожно. Автопубликация хороша, если шаблон полностью проверен и счёт не требует ручной правки перед отправкой. Если же менеджер должен добавлять комментарий, корректировать сумму или сверять услугу, автопубликация может отправить клиенту документ раньше проверки.

Рекомендуемый порядок: сначала создать recurring invoice без автоматической отправки, дождаться генерации следующего документа, проверить его вручную, затем включить более автоматический режим, если результат стабилен. Для due date проверьте, как дата меняется при дублировании и повторении. Если срок оплаты зависит от договора, не ставьте универсальное значение без ручной проверки.

Связь recurring invoices с reminders

Повторяющиеся счета и автоматические напоминания вместе создают сильный, но чувствительный процесс. Если recurring invoice создаётся автоматически, а reminder отправляется автоматически, клиент может получить письмо по документу, который администратор ещё не проверил. Поэтому перед объединением этих функций задайте правило: какие recurring documents публикуются сразу, какие требуют ручной проверки, какие reminders включены и какой лимит писем за cron execution разрешён.

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

Что проверять при ошибке повторения

Если повторяющийся счёт не создан, создан дважды или получил неправильную дату, проверьте исходный invoice, настройки recurring, cron-задачу, статус публикации и журнал ошибок Joomla. Если документ был создан автоматически, но письмо не ушло, проблема может быть не в recurring, а в email notifications. Если письмо ушло, но документ не опубликован, смотрите настройки autopublish. Разделение слоёв экономит время: recurring создаёт документ, email отправляет сообщение, reminder напоминает, payment plugin обновляет статус.

Автоматические напоминания и cron-задачи

Напоминания по неоплаченным счетам полезны только тогда, когда они настроены аккуратно. Документация по email notifications описывает unpaid invoice reminders и указывает, что для автоматического запуска нужен cron job URL из раздела Configuration > Reminders > Cron Job. Там же есть настройка, сколько reminder emails отправлять за один cron execution, чтобы не разослать слишком много писем за раз.

Как включать напоминания без риска

Сначала включите reminders на тестовом наборе. Создайте один просроченный тестовый invoice, настройте тему и тело письма, проверьте placeholders, затем запустите cron вручную или через панель хостинга, если это предусмотрено. После запуска убедитесь, что письмо ушло только нужному контакту, ссылка ведёт к правильному документу, а повторная отправка не происходит чаще, чем вы ожидаете.

Для первого реального запуска поставьте небольшой лимит писем за один cron execution. Это особенно важно, если в системе уже есть старые неоплаченные документы. Иначе компонент может корректно выполнить задачу, но администратор получит лавину отправок, которую клиенты воспримут как ошибку.

Где может сломаться cron

Типичные причины: URL недоступен извне, хостинг блокирует cron-запросы, домен редиректит на другой адрес, сайт требует авторизацию, HTTPS настроен неверно, в письме некорректный placeholder или почтовый сервер отклоняет массовую отправку. При диагностике отделяйте сам cron от email. Если cron запускается, но писем нет, смотрите почтовые настройки и шаблон. Если cron не запускается, смотрите URL, расписание и доступность сайта.

Напоминания должны поддерживать процесс, а не заменять контроль администратора. Раз в некоторое время просматривайте список unpaid invoices вручную, особенно после обновлений, смены SMTP или изменения платёжного плагина.

Частые проблемы и диагностика JoomInvoice

Проблемы в JoomInvoice чаще всего возникают не из-за одной причины, а на стыке компонента, Joomla, шаблона, почты, PDF-движка и платёжного сервиса. Хорошая диагностика начинается с вопроса: на каком слое цепочка оборвалась?

PDF скачивается, но выглядит иначе, чем страница

Симптом. В админке preview выглядит нормально, а PDF ломает сетку, смещает блоки, не показывает логотип или меняет отступы.

Вероятная причина. PDF layout использует возможности dompdf, а не полноценного браузера. Flexbox, grid, JavaScript и внешние CSS могут не работать так, как в веб-странице.

Что проверить. Откройте именно PDF template, проверьте путь логотипа, inline CSS, таблицы, явные widths, размер изображения и доступность файла в media/com_joominvoice/.

Как исправить. Упростите PDF layout: таблицы вместо сложной сетки, inline styles, явные размеры, меньше декоративных блоков. После каждой правки скачайте новый PDF.

Когда откатить. Если после правки PDF стал хуже или placeholder перестал заменяться, верните последнюю рабочую версию шаблона и меняйте по одному блоку.

Письмо отправлено, но клиент его не получил

Симптом. Администратор нажал отправку invoice или quote, но письмо не приходит, вложение отсутствует или тема выглядит неправильно.

Вероятная причина. Глобальные mail settings Joomla, отдельный sender в JoomInvoice, спам-фильтр, неверный email клиента, проблема с PDF attachment folder или ошибка в email template.

Что проверить. Отправьте тестовое письмо из Joomla, затем письмо JoomInvoice на контролируемый адрес. Проверьте From name, From email, subject placeholders, attach PDF setting и права на временную PDF-папку.

Как исправить. Сначала восстановите отправку Joomla, затем настройте sender в JoomInvoice или оставьте глобальные настройки, если они стабильны. Для вложений проверьте папку временных PDF и размер файла.

Когда откатить. Если после кастомизации шаблона письма сообщения перестали уходить, верните стандартный шаблон и добавляйте placeholders постепенно.

Stripe платёж прошёл, а счёт не стал оплаченным

Симптом. В Stripe Dashboard тестовый или реальный платёж есть, но JoomInvoice показывает invoice как unpaid или статус не изменился.

Вероятная причина. Webhook не настроен, endpoint недоступен, есть mismatch между www и non-www, отсутствует HTTPS, signing secret вставлен неверно или клиент закрыл браузер до возврата на сайт при сценарии без webhook.

Что проверить. В Stripe Workbench проверьте delivery errors webhook. Сравните endpoint URL с URL в документации, проверьте canonical URL Joomla, HTTPS, отсутствие trailing slash и лишних параметров.

Как исправить. Обновите webhook secret в плагине, исправьте endpoint, убедитесь, что событие checkout.session.completed отправляется, затем повторите тестовую оплату.

Когда откатить. Если реальная оплата уже прошла, не просите клиента платить повторно. Зафиксируйте платёж вручную по внутреннему регламенту и только затем исправляйте webhook на тестовом счёте.

Гостевая ссылка открывает ошибку или не показывает документ

Симптом. Клиент открывает ссылку из письма, но видит ошибку доступа, пустую страницу, неправильный маршрут или требование входа.

Вероятная причина. Не настроен пункт меню, access level закрывает страницу, auth code не совпадает, кеш отдаёт старый маршрут, либо ссылка сформирована до изменения конфигурации.

Что проверить. Откройте ссылку в приватном окне, проверьте пункт меню, права доступа, guest flow, настройки маршрутизации и кеш. Если используется guest payment, проверьте отдельный вид completion после оплаты.

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

Когда откатить. Если изменение маршрутизации ломает другие страницы сайта, верните прежний пункт меню и тестируйте клиентский доступ на staging-копии.

Товары HikaShop не ищутся в счёте

Симптом. При создании invoice или quote поиск товаров не показывает позиции HikaShop или подтягивает неполные данные.

Вероятная причина. JoomInvoice HikaShop search plugin выключен, HikaShop недоступен, у администратора недостаточно прав, товары скрыты или в каталоге используется сложная логика вариантов.

Что проверить. Статус HikaShop, статус search plugin, наличие простого опубликованного товара, права администратора, поля product name, SKU, description и current price.

Как исправить. Включите search plugin, начните с простого товара, затем проверьте варианты и налоговые правила. Если сложная цена не подтягивается так, как нужно, фиксируйте цену вручную в счёте перед отправкой.

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

Безопасные улучшения без правки ядра компонента

Для JoomInvoice не стоит править файлы ядра компонента или платежных плагинов. Это усложнит обновления и может повредить финансовую логику. Безопаснее работать с настройками, шаблонами, CSS сайта, языковыми переопределениями Joomla и регламентом проверки. Кодовые сниппеты уместны только там, где они не вмешиваются в оплату, расчёт суммы и доступ к документам.

Языковые переопределения

Если подписи в публичной части или письмах звучат не так, как нужно вашему сайту, используйте Joomla language overrides, а не правку файлов расширения. Это безопаснее: переопределения переживают обновления лучше, чем ручная замена строк в компоненте. Перед правкой найдите точный language constant, создайте override для нужного языка и проверьте счёт, quote, письмо и PDF.

CSS для публичного просмотра

Если клиентский просмотр счёта требует небольшого визуального улучшения, добавляйте CSS в шаблон сайта или custom CSS, а не в файлы JoomInvoice. Например, можно аккуратно улучшить читаемость блока счёта в публичной части, если классы известны из инспектора браузера. Не вставляйте CSS в PDF-шаблон без отдельной проверки PDF.

.com-joominvoice .invoice-summary {
  border-radius: 6px;
  padding: 16px;
  background: #f7f9fb;
}

.com-joominvoice .invoice-total {
  font-weight: 700;
}

Этот пример безопасен только как ориентир для публичной страницы, если такие классы действительно есть в вашей разметке. После добавления проверьте desktop и mobile, затем откатите CSS, если он влияет на другие компоненты или ломает PDF. Для PDF используйте отдельный PDF layout и inline styles по правилам документации.

Регламент перед отправкой

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

Когда JoomInvoice будет удачным выбором

JoomInvoice стоит тестировать, если вам нужен Joomla-компонент для управляемых счетов, коммерческих предложений, PDF, email-отправки, клиентского просмотра, онлайн-оплаты и повторяемого процесса внутри сайта. Особенно сильный сценарий - когда администратор вручную создаёт документы, комбинирует услуги и товары, отправляет клиенту ссылку, а затем проверяет статус оплаты в той же админ-панели.

Перед реальным запуском не торопитесь включать всё сразу. Сначала проверьте базовый счёт, PDF, письмо и публичную ссылку. Затем подключите платежный плагин в тестовом режиме, настройте webhook, протестируйте статус и только после этого переносите процесс на реальных клиентов. Такой порядок снижает риск ошибок и делает компонент понятным для команды.

Если после чтения вы понимаете, какой сценарий хотите проверить на своём сайте, переходите к блоку загрузки и скачать последнюю версию JoomInvoice, затем установите его на тестовую копию Joomla и пройдите короткий сценарий из этого руководства. Финальное решение лучше принимать не по списку функций, а по тому, насколько уверенно компонент проходит вашу реальную цепочку: документ, письмо, PDF, доступ клиента, оплата и проверка результата.