Оплаты из своей программы в 1С: клиника, салон, самописная система. Схема загрузки через расширение

Во многих компаниях основная работа идёт не в 1С. В клинике — медицинская информационная система, в салоне — программа онлайн-записи, в сервисной компании — самописная система заявок, которую когда-то сделал знакомый программист. Там записывают клиентов, оказывают услуги и принимают оплату. А бухгалтерия и управленческий учёт — в 1С.

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

Ниже — как я раскладываю такую загрузку на стороне 1С: что забирать, в какие документы, как не задвоить и не потерять возвраты, и где проходят границы, о которых лучше договориться до разработки. Примеры кода упрощены и написаны для статьи; имена документов и реквизитов зависят от конфигурации (БП, УНФ, УТ, КА).

Что вообще нужно 1С из чужой программы

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

• оказанные услуги — что, когда, на какую сумму, по какому подразделению;
• оплаты — сколько, когда, каким способом (наличные, карта, онлайн, сертификат, депозит клиента);
• возвраты и отмены;
• иногда — расход материалов на услугу, если его ведут в источнике.

Для клиник отдельно: персональные и тем более медицинские данные в 1С без необходимости не тянем. Часто для учёта достаточно агрегата по дню или по чеку и обезличенного «розничного покупателя». Если по договору нужен конкретный контрагент (юрлицо, страховая, корпоративный клиент) — тогда да, контрагент с ИНН. Решение фиксируем вместе с ответственным за персональные данные у заказчика, а не по умолчанию.

Первая развилка: кто пробил чек

Это вопрос, который нужно задать в первый день, иначе можно сломать фискальный учёт.

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

На практике почти всегда первый вариант: касса живёт там, где работает администратор.

Вторая развилка: каждый платёж или итоги дня

Решение принимает бухгалтер. Механизм загрузки должен уметь оба режима, потому что через полгода режим могут поменять.

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

Условное соответствие (уточняется под конфигурацию и учётную политику заказчика):

Отдельные случаи, которые надо обсудить заранее: сертификаты (оплата сертификатом — не выручка в момент продажи сертификата, а при оказании услуги), депозиты и абонементы (аванс клиента), рассрочка и оплата страховой. Каждый из них — отдельное правило, и лучше их выписать до первой строки кода.

Как забирать данные

У отраслевых программ бывает API (REST, иногда с вебхуками), у самописных — что угодно: от API до доступа к таблице в базе данных или выгрузки файла в папку. Схема на стороне 1С при этом одна:

Своя программа ^72;^72; API / вебхук / файл ^72;^72;`58; Расширение 1С
                                             ^74; сохранить сырое
                                             `60;
                                   Регистр «Входящие операции»
                                             ^74; разбор
                                             `60;
                          Сопоставление: услуги, способы оплаты, кассы, подразделения
                                             ^74;
                          ^84;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;_24;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^88;
                          `60;                                    `60;
                    Документы 1С                       «Требует внимания»

Если источник отдаёт операции по API, самый надёжный способ опроса — курсор по времени изменения и идентификатору, а не «за сегодня»:

Процедура ЗабратьОперации(Источник) Экспорт

    Курсор = ПолучитьКурсор(Источник); // Структура: МоментИзменения, ПоследнийИд
    // Запас назад — на случай операций, изменённых задним числом
    С = Курсор.МоментИзменения - ЗапасСекунд(Источник);

    Пока Истина Цикл
        Порция = КлиентAPI.ОперацииИзмененныеПосле(Источник, С, Курсор.ПоследнийИд, 200);
        Если Порция.Количество() = 0 Тогда
            Прервать;
        КонецЕсли;
        Для Каждого Операция Из Порция Цикл
            СохранитьВходящую(Источник, Операция); // идемпотентно по внешнему ID + версии
        КонецЦикла;
        Последняя = Порция[Порция.ВГраница()];
        Курсор.МоментИзменения = Последняя.ИзмененВ;
        Курсор.ПоследнийИд     = Последняя.Ид;
        СохранитьКурсор(Источник, Курсор);
    КонецЦикла;

КонецПроцедуры

Почему не «за сегодня»: администратор вполне может отменить оплату за вчера или исправить способ оплаты задним числом. Опрос по дате операции этого не увидит, опрос по времени изменения — увидит.

Идемпотентность и версии

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

Функция ДействиеПоОперации(Ключ, ХешСодержимого)

    Сохраненное = РегистрыСведений.Обмен_СоответствиеОпераций.Получить(
        Новый Структура("Ключ", Ключ));

    Если Не ЗначениеЗаполнено(Сохраненное.Документ) Тогда
        Возврат "Создать";
    ИначеЕсли Сохраненное.Хеш = ХешСодержимого Тогда
        Возврат "Пропустить"; // повтор той же версии
    ИначеЕсли ПериодОткрыт(Сохраненное.Документ) Тогда
        Возврат "Обновить";
    Иначе
        Возврат "НаРазбор"; // изменение в закрытом периоде — решает бухгалтер
    КонецЕсли;

КонецФункции

Для режима «итоги дня» логика та же, но ключом становится «источник + касса + дата + способ оплаты», а хешем — хеш всех операций, вошедших в итог. Изменилась любая операция за день — пересчитываем итог, если период открыт; если закрыт — в очередь разбора.

Сопоставление: справочники источника и 1С

Типовые пары, которые нужно сопоставить один раз и хранить в регистре соответствий:

• услуги источника → номенклатура (услуги) в 1С. В клиниках и салонах прайс часто подробнее, чем нужно бухгалтерии: десятки вариантов процедуры в источнике могут сводиться к нескольким позициям в 1С. Это нормально, соответствие «многие к одному» — допустимый вариант;
• способы оплаты → касса / эквайринговый договор / вид оплаты;
• филиалы, кабинеты → подразделения и склады;
• сотрудники — только если нужна аналитика по исполнителю в 1С (например, для расчёта процента мастера). Если не нужна — не тянем.

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

Сверка: главный аргумент для бухгалтера

Бухгалтер поверит загрузке, только если может её проверить. Поэтому в расширении стоит сразу сделать простой отчёт сверки за период:

• сумма оплат по способам оплаты в источнике (из сохранённых сырых данных);
• сумма по тем же способам в документах 1С;
• разница и список операций, которые её дают (в очереди разбора, отменены, в закрытом периоде).

Если сырые данные сохраняются, отчёт строится без повторного обращения к источнику и показывает ровно то, что было получено.

Всё в расширении

Как и любая подобная интеграция, загрузка делается расширением: свой HTTP-сервис или регламентное задание опроса, свои регистры входящих и соответствий, свои обработки разбора и мониторинга. Типовые документы создаются программно, без правки их модулей и форм. Типовая конфигурация остаётся на поддержке; правила сопоставления и режимы настраиваются в режиме предприятия.

О чём договориться до начала

Короткий чек-лист для первой встречи с заказчиком:

1. Кто пробивает чеки: своя программа или 1С?
2. Каждый платёж или итоги дня? Для кого — исключения?
3. Какие способы оплаты бывают, включая сертификаты, депозиты, страховые, рассрочку?
4. Как в источнике выглядят возвраты и отмены и можно ли их отличить от правки?
5. Есть ли у источника API, и отдаёт ли оно операции по времени изменения?
6. Какие персональные данные реально нужны в 1С — и можно ли обойтись без них?
7. Кто разбирает очередь «требует внимания» и кому слать оповещения?

Ответы на эти вопросы определяют объём работы сильнее, чем сам источник.

Вместо выводов

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

Если у вас клиника, салон или своя система, из которой выручку пока переносят в 1С руками, — опишите в комментариях, какая программа и как устроены оплаты. Разберу типовые ловушки для конкретного случая.