Клиентский портал в ERPNext: заказчик сам видит статус, счета и документы

Клиентский портал ERPNext показывает заказчику его проекты, счета, заказы, коммерческие предложения и отгрузки после входа под своей учётной записью. Доступ выдаётся через Customer и Contact, а чужие данные закрывает привязка пользователя к клиенту. Ниже настройка, границы и проверки.

Что клиент видит на портале ERPNext из коробки

Заказчик проектной организации задаёт три вопроса, и все они одинаковы: на каком мы этапе, где счёт и что нам прислали. Каждый такой вопрос это звонок менеджеру. Клиентский портал в ERPNext закрывает часть этих звонков: заказчик входит в веб-кабинет под своей учётной записью и видит свои данные, взятые из тех же документов, что и у менеджеров. Мы показываем этот сценарий как часть решения ERPNext под ключ, но подчёркиваю заранее: портал в коробке скромный, и ниже я разбираю его по исходному коду версии 15, чтобы не обещать лишнего.

Меню портала для роли Customer задаётся в ядре списком. Заказчик видит разделы: Projects (проекты), Quotations (коммерческие предложения), Orders (заказы покупателя), Invoices (счета), Shipments (отгрузки, это Delivery Note), Issues (обращения), Addresses (адреса), Timesheets (табели) и Material Request (заявки на материалы). Для роли Supplier есть другой набор: запросы цен, предложения поставщика, заказы и счета поставщика. Одну и ту же систему можно открыть и клиентам, и поставщикам, каждому своё меню.

Что я заметил в коде и о чём предупреждаю заказчика. Первое: в списках портала показываются только проведённые документы (docstatus = 1); черновики клиент не увидит. Второе: документа «акт выполненных работ» в портале нет: акты в российских компаниях обычно оформляют в учётной системе вроде 1С, а в портале клиент увидит счета и отгрузки. Если вам нужно показывать акты, их прикрепляют к проекту как файлы или выкладывают иным путём. Третье: у счёта на странице есть кнопка печати, а кнопка оплаты «Pay» появляется только при установленном приложении payments и включённом флаге «Show Pay Button in Purchase Order Portal» (show_pay_button) в Buying Settings: несмотря на название, в версии 15 страница документа на портале (order.py) проверяет именно этот флаг и для счетов покупателю.

Как выдать доступ заказчику и кто такой Portal User

Выдать доступ можно за несколько шагов, и порядок важен. Сначала в системе должны существовать клиент (Customer) и контакт (Contact) с адресом электронной почты. Затем в карточке контакта есть кнопка «Invite as User»: она создаёт пользователя с типом «Website User» и отправляет ему приветственное письмо с ссылкой для установки пароля. Тип «Website User» это принципиально: у такого пользователя нет доступа к рабочему интерфейсу ERPNext, только к порталу.

Дальше ключевой шаг, который часто пропускают: пользователя нужно привязать к клиенту. В карточке Customer есть вкладка «Portal Users», в таблицу добавляют созданного пользователя. При сохранении система назначает ему роль Customer и связывает с контактами. Именно эта таблица, а не адрес в контакте, определяет, чьи документы видит пользователь: код портала ищет клиентов, на которых ссылается этот пользователь в таблице Portal User. Если запись в таблице не создана, пользователь входит, но видит пустые списки.

Для страницы проекта нужен ещё один шаг. Портал показывает проекты, у которых в поле Customer указан клиент пользователя. Кроме этого, в карточке проекта есть таблица Users: пользователи оттуда получают доступ к проекту, а в строке можно выбрать «View attachments» (видеть вложения) и «Hide timesheets» (скрыть табели). Проверка привязки для консоли bench, чтобы убедиться, что таблица заполнена:

bench --site site1.example.com console

frappe.get_all(
    "Portal User",
    filters={"parenttype": "Customer", "parent": "Клиент 1"},
    fields=["user"],
)

Название клиента подставьте своё. Такая проверка занимает минуту и снимает половину вопросов вида «клиент зашёл, но ничего не видит».

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

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

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

Разбивка для проектной организации на условных данных: | Показывать | Показывать по запросу | Не показывать | |---|---|---| | счета и отгрузки | протоколы совещаний | себестоимость и маржа | | статус этапа и задачи | фотоотчёты | внутренние комментарии | | график платежей | исполнительная документация | данные других клиентов | | КП на согласование | вложения проекта выборочно | табели с ставками сотрудников |

Две настройки на уровне проекта, которые закрывают самое чувствительное. «Hide timesheets» в строке пользователя в таблице Users скрывает табели: на странице проекта портал показывает табели, если флаг не отмечен, а там часы сотрудников. «View attachments» разрешает видеть вложения проекта, и его нужно включать только для тех, кому это действительно нужно. Лучше выкладывать клиенту только выбранные файлы, а не всю папку проекта: прикреплять документы к проекту так, чтобы внутренние черновики туда не попадали.

И ещё одна ловушка: адреса. В меню портала есть раздел Addresses; он показывает адреса клиента, и если в базе завели лишние, клиент их увидит. Перед запуском проверьте, нет ли там внутренних или чужих адресов. Изменения шаблонов портала и кастомизацию страниц делает администратор или разработчик, не пользователь: Server Script по умолчанию отключены с v15, а HTML в Print Format и подобных местах исполняется, поэтому правку допускают только доверенные роли.

Как закрыть чужие данные: роли, User Permissions и маскирование

Это раздел, из-за которого портал нельзя запускать без проверки. Во многих инструкциях пишут, что доступ заказчика ограничивают через User Permission на Customer или Project. Разбор кода версии 15 показывает более тонкую картину, и официальная документация по Customer Portal её подтверждает, и её надо знать. Для внешнего пользователя (Website User) списки в портале фильтруются по клиенту, найденному в таблице Portal User: в запрос добавляется условие «customer in (клиенты пользователя)», а сами записи выбираются с правами системы. Это значит, что изоляция между клиентами обеспечивается привязкой пользователя к клиенту, и ошибка в этой привязке показывает чужие документы.

User Permission остаётся основным механизмом для внутренних пользователей: у роли без User Permission есть доступ ко всем записям типа, и этого одной ролью не исправить. Прорабу или менеджеру проектов создают User Permission на его проекты, и он видит документы только по ним во всех связанных типах. Для руководителей флаг «Apply User Permissions» снимают, чтобы они видели всё. Правильная проверка делается под тестовыми учётными записями: два клиента, два пользователя, и каждый должен видеть только своё.

Про скрытие отдельных полей. В версии 16 появился механизм маскирования данных (Data Masking): у поля включается флаг Mask, а в правах роли появляется отдельное право Mask; пользователь без этого права видит маскированное значение. Механизм поддерживает 14 типов полей, включая Data, Currency, Phone, Date и Link, и в документации он помечен экспериментальным. Как он ведёт себя именно на страницах портала, я не проверял и не могу утверждать, поэтому на стенде это надо проверить отдельно. В версии 15 поля скрывают уровнями доступа (Permission Level) для внутренних пользователей, а для портала проще не выводить поле в шаблон.

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

Разбор случая: проектная организация «Чертёж Центр» на 27 рабочих мест

Условный пример. Проектная организация «Чертёж Центр», 27 рабочих мест: архитекторы, конструкторы, инженеры, два ГИПа, руководитель, бухгалтерия и отдел договоров. Одновременно около двадцати проектов у восьми заказчиков, и главная нагрузка на менеджеров: звонки «где чертежи» и «выставьте счёт ещё раз». Они хотели портал, где заказчик видит этап, счёт и график платежей.

Настроили пилот на трёх заказчиках. В каждом создали контакты, пригласили пользователей, привязали в Portal Users, проверили таблицу консольной командой. В проектах заполнили Customer и добавили пользователей заказчика в таблицу Users, для двух заказчиков отметили «Hide timesheets», для одного разрешили «View attachments». Графики платежей и счета вели в штатных документах, и клиент увидел их в разделе Invoices после проведения.

Что показала проверка на тестовых клиентах. Заказчик не видел свой счёт: счёт оказался выставлен на дочернюю компанию, а в Portal Users пользователь был привязан к головной. После переноса привязки счёт появился. Второй случай: клиент видел табели с часами инженеров, пока не отметили «Hide timesheets». Третий: в адресах клиента висел внутренний адрес склада, его убрали до запуска. Ни одна из этих проблем не требовала разработки, но каждая обнаружилась только тестом под двумя клиентами. После пилота портал открыли остальным пяти заказчикам.

Что осталось за границей. Акты и закрывающие документы заказчик по-прежнему получает по электронной почте и через ЭДО, из портала он видит счета и отгрузки. Согласование коммерческого предложения прямо на портале мы не обещали и не включали: стандартной кнопки принятия на страницах портала я в коде не нашёл. Показать, как выглядит кабинет, можно на демостенде erp-demo.itfresh.ru по запросу, на вымышленных данных.

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

Честный список ограничений перед запуском. Портал ERPNext не заменяет полноценный личный кабинет с чатом, электронным документооборотом и подписанием. Нет документа «акт» для просмотра клиентом. Кнопка оплаты требует приложения payments и платёжного шлюза. Согласование КП клиентом онлайн в стандартных страницах портала я не обнаружил: в обзорах встречается утверждение, что портал «позволяет согласовывать КП», но ни код страниц v15, ни официальная страница Customer Portal этого не подтверждают, поэтому считайте такой сценарий доработкой или проверяйте в своей версии. Опции корзины и «Save Quotation as Draft» относятся к сценарию веб-магазина, а не к согласованию проектных КП.

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

Если на стенде что-то не сходится с этим текстом, это нормальный итог проверки, а не ошибка: версии отличаются, и поведение портала зависит от установленных приложений. Лицензии ERPNext стоят 0 ₽, пользователей портала отдельно не покупают: затраты уходят на настройку, сервер и сопровождение, условия внедрения описаны на странице продукта. И последнее практическое замечание: когда запускаете портал, дайте заказчику короткую памятку из пяти строк, где что искать, иначе звонки не уйдут.

• Два клиента, два пользователя: каждый видит только свои документы.
• Пользователь без записи в Portal Users видит пустые списки.
• Черновики не видны, проведённые документы видны.
• Табели и вложения проекта скрыты или открыты ровно так, как задумано.
• Страницы читаются на телефоне, приветственное письмо доходит.

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