Как добавить функции получения прайса, проверки долга, акта сверки и заказа?

База знаний Одина — Одинэсника › Форумы › ODIN — Форум по 1С Предприятию › Как добавить функции получения прайса, проверки долга, акта сверки и заказа?

Просмотр 1 ветки ответов
  • Автор
    Записи
    • #38970
      Фото аватараOdineski
      Участник

        как можно добавить остальные функции, например: получение прайс-листа, проверка задолженности и получение акта сверки, оформление заказа

      • #38971
        bot_avaOdin — Одинэсник
        Участник

          Это уже не просто отправка документов, а полноценный Telegram-бот, связанный с УНФ 3. Оптимальная схема:

          Для начала лучше использовать регламентное задание с методом getUpdates. Такой вариант проще разместить и обслуживать. Webhook быстрее, но потребует публикации HTTP-сервиса 1С через HTTPS.

          ## 1. Какие функции можно реализовать

          В боте можно сделать меню:

          Пример сценариев:

          ### Прайс-лист

          Клиент нажимает:

          Бот:

          1. получает клиента по Telegram chat_id;
          2. определяет доступный ему вид цен;
          3. формирует список товаров;
          4. формирует Excel или PDF;
          5. отправляет файл в Telegram.

          ### Задолженность

          Клиент нажимает:

          Бот возвращает:

          ### Акт сверки

          Клиент выбирает период:

          Затем бот предлагает:

          После выбора периода:

          1. формируется акт сверки;
          2. он сохраняется в PDF;
          3. PDF отправляется клиенту.

          ### Оформление заказа

          Клиент:

          1. открывает каталог;
          2. выбирает товар;
          3. указывает количество;
          4. подтверждает заказ;
          5. в УНФ создается документ Заказ покупателя;
          6. бот возвращает номер заказа.

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

          —

          # 2. Связка Telegram-пользователя с клиентом УНФ

          Это основной элемент безопасности.

          Нельзя определять клиента только по имени пользователя Telegram. Имя можно изменить, а иногда оно вообще отсутствует.

          Нужно хранить таблицу соответствий:

          В расширении создайте регистр сведений, например:

          Измерение:

          Реквизиты:

          Пример записи:

          ## Вариант регистрации клиента

          Самый простой способ:

          1. клиент пишет боту /start;
          2. бот просит указать номер телефона;
          3. номер телефона передается Telegram как контакт;
          4. 1С ищет клиента по номеру телефона;
          5. бот отправляет код подтверждения;
          6. после подтверждения создается связь с партнером.

          Более безопасный способ:

          1. менеджер в УНФ открывает карточку клиента;
          2. нажимает «Подключить Telegram»;
          3. программа создает одноразовый код;
          4. клиент отправляет боту этот код;
          5. бот связывает chat_id с конкретным партнером.

          Пример текста:

          Код нельзя делать постоянным. После успешной регистрации его нужно удалить или пометить использованным.

          —

          # 3. Получение входящих сообщений от Telegram

          Telegram передает сообщения через API getUpdates:

          В регламентном задании 1С нужно:

          1. получить offset;
          2. вызвать getUpdates;
          3. разобрать JSON;
          4. обработать каждое сообщение;
          5. сохранить новый offset.

          Пример вызова:

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

          —

          # 4. Меню Telegram

          Для меню используются inline-кнопки. Пользователь нажимает кнопку, а бот получает callback_query.

          Структура меню:

          Вспомогательная функция:

          При нажатии кнопки Telegram вернет:

          В обработчике:

          —

          # 5. Получение прайс-листа

          Здесь нужно заранее определить бизнес-правила:

          — какой вид цен использовать;
          — показывать ли только доступные товары;
          — показывать ли остатки;
          — учитывать ли характеристики;
          — учитывать ли индивидуальные цены клиента;
          — какой склад использовать;
          — какие товары разрешено продавать клиенту.

          Для клиента лучше использовать именно тот вид цен, который применяется в заказах УНФ.

          ## Запрос списка товаров и цен

          Ниже примерный запрос. Названия регистров цен в конкретной версии УНФ 3 необходимо проверить в конфигураторе. В разных версиях могут отличаться регистр и состав измерений.

          В рабочей разработке этот запрос нужно адаптировать под фактический регистр цен УНФ 3. Нельзя без проверки использовать условное имя регистра, если его нет в вашей конфигурации.

          ## Формирование файла

          Для большого прайс-листа лучше формировать Excel, а не отправлять тысячи сообщений.

          Варианты:

          — Excel;
          — PDF;
          — CSV;
          — текстовый файл;
          — ссылка на веб-каталог.

          Пример формирования табличного документа:

          Сохранение:

          Затем:

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

          —

          # 6. Проверка задолженности

          В УНФ задолженность может быть рассчитана по разным аналитикам:

          — по заказам;
          — по договорам;
          — по накладным;
          — по расчетным документам;
          — по срокам оплаты.

          Поэтому сначала нужно определить, какая аналитика фактически используется в базе.

          Нельзя автоматически считать задолженность простой суммой всех реализаций минус все оплаты, если в УНФ используется сложная детализация взаиморасчетов.

          ## Пример запроса задолженности

          Ниже пример общего подхода через регистр расчетов. Точное имя регистра нужно проверить в вашей базе:

          Это только пример структуры. В УНФ 3 следует использовать тот регистр, на основании которого типовые отчеты программы показывают задолженность. Надежнее всего посмотреть схему компоновки данных типового отчета по задолженности и использовать ее логику.

          ## Формирование ответа

          Рекомендуется добавить расшифровку:

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

          —

          # 7. Получение акта сверки

          Есть два варианта реализации.

          ## Вариант 1. Вызывать типовой механизм акта сверки

          Это предпочтительный вариант. Нужно использовать типовую логику УНФ формирования отчета или печатной формы акта сверки.

          Порядок:

          1. определить партнера;
          2. определить организацию;
          3. определить договор, если учет ведется по договорам;
          4. определить период;
          5. сформировать табличный документ;
          6. сохранить его в PDF;
          7. отправить через Telegram.

          Для документа акта сверки могут потребоваться:

          ## Вариант 2. Сделать собственную форму

          Можно сформировать акт самостоятельно по движениям взаиморасчетов:

          Но этот вариант опаснее, потому что можно не учесть:

          — авансы;
          — возвраты;
          — корректировки;
          — зачеты;
          — комиссионные операции;
          — разные договоры;
          — валютные расчеты;
          — курсовые разницы.

          Поэтому лучше переиспользовать типовой отчет или типовую печатную форму, а не писать расчет с нуля.

          Общий код формирования PDF выглядит так:

          Процедура СформироватьАктСверки() в данном примере условная. Ее нужно связать с конкретным типовым отчетом или макетом вашей версии УНФ 3.

          —

          # 8. Оформление заказа через Telegram

          Есть два уровня сложности.

          ## Простой вариант

          Клиент вводит:

          Бот:

          1. находит товар по артикулу;
          2. проверяет цену;
          3. проверяет возможность продажи;
          4. добавляет товар в корзину;
          5. просит подтвердить заказ;
          6. создает документ Заказ покупателя.

          Пример команды:

          Это проще всего реализовать для первого этапа.

          ## Полноценная корзина

          Бот хранит корзину в регистре сведений:

          Измерения:

          Реквизиты:

          Сценарий:

          ## Поиск товара

          Клиент отправляет:

          1С выполняет поиск:

          Каждый найденный товар отправляется кнопкой:

          В callback_data нужно передавать не само наименование, а ключ:

          Нельзя без необходимости передавать большие строки в callback_data.

          ## Добавление в корзину

          После выбора товара бот спрашивает:

          Следующее сообщение сохраняется как количество товара.

          Затем в корзину записывается строка. Перед записью нужно проверить:

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

          ## Создание документа заказа

          В УНФ документ создается на сервере:

          Но для типовой УНФ этого обычно недостаточно. В заказе могут быть обязательны:

          — соглашение;
          — склад;
          — вид цен;
          — организация;
          — договор;
          — подразделение;
          — операция;
          — график оплаты;
          — способ доставки;
          — статус заказа;
          — ставки НДС.

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

          В готовом решении обязательно нужно выполнять типовые проверки заполнения перед записью:

          После создания документа бот отправляет:

          —

          # 9. Что делать с заказом без непосредственного проведения

          Не рекомендуется сразу проводить заказ, сформированный клиентом через Telegram.

          Лучше:

          1. создать документ;
          2. записать его;
          3. установить статус На согласовании или аналогичный;
          4. уведомить менеджера;
          5. после проверки менеджер проводит или подтверждает заказ.

          Причины:

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

          —

          # 10. Уведомления менеджеру

          После создания заказа нужно отправить сообщение:

          Можно сделать два варианта:

          — отправлять сообщение в Telegram-группу менеджеров;
          — уведомлять конкретного ответственного менеджера;
          — использовать внутренние задачи УНФ;
          — отправлять уведомление одновременно в Telegram и в 1С.

          Для группы менеджеров потребуется отдельный chat_id.

          —

          # 11. Состояния диалога

          Бот должен понимать, на каком шаге находится каждый пользователь.

          Для этого нужен регистр сведений:

          Измерение:

          Реквизиты:

          Примеры состояний:

          Без хранения состояния получится ненадежная система, потому что бот не будет понимать, к какой операции относится очередное сообщение клиента.

          —

          # 12. Рекомендуемый порядок разработки

          Не стоит сразу реализовывать все функции одновременно. Практичный порядок такой:

          ## Этап 1. Основа

          — регистрация клиента;
          — хранение chat_id;
          — главное меню;
          — отправка обычного сообщения;
          — журнал ошибок;
          — очередь сообщений.

          ## Этап 2. Простые функции

          — просмотр задолженности;
          — получение прайс-листа;
          — отправка существующих PDF;
          — просмотр списка заказов.

          ## Этап 3. Акт сверки

          — выбор периода;
          — формирование PDF;
          — отправка клиенту;
          — журнал отправленных актов.

          ## Этап 4. Заказ

          — поиск номенклатуры;
          — корзина;
          — выбор количества;
          — подтверждение;
          — создание заказа;
          — уведомление менеджера.

          ## Этап 5. Контроль

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

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

      Просмотр 1 ветки ответов
      • Для ответа в этой теме необходимо авторизоваться.
      База знаний 1С