Тут у меня зашел спор с одним программистом 1С из Липецка (Александром Ворониным), считающим себя очень опытным.

Из реального опыта эксплуатации
Распределенная БД, десятки торговых точек-магазинов
Проблема с кешем — где то раз в месяц один раз
Проблема с «чекдбфл» — не наблюдаются

Теперь за «транзакции»
Если за наличные, то проблем нет
Если чек не пробился — ну не пробился, отменили и решаем проблему
Если эквайринг, то сложнее, потому как сначала списание, потом чек
Но если чек не пробился, то тут же отменяем оплату, отменяем операцию и решаем проблему

В прямых руках РМК вполне себе надежный инструмент
А вот если технику и ПО настраивают неумёхи-разводилы, как ты, тогда да, будут проблемы

Оставлю его мнение без комментариев, но расскажу о своем опыте использования кассового фронта на 1С, отдельно для РИБ (когда каждый фронт является отдельной базой, обменивающейся данными с центральной базой) и отдельно для облака (когда все фронты работают в центральной базе).

Моё мнение, что РМК на 1С это, конечно, зло. Но конкуренты пока тоже не приближаются к идеалу, поэтому имеют право на жизнь. Но нужно быть готовым, что использование такого фронта будет обходиться в несколько раз дороже, чем могло бы.

РИБ: файловые базы 1С подвержены сбоям целостности

Их необходимо лечить утилитой chkdbfl. По моим наблюдениям на точках без бесперебойных источников питания (ИБП) где-то два случая на каждые 50 точек в месяц.
Автоматизировать процесс нельзя — 1С не предусмотрела запуск утилиты в командной строке.
Серверные базы ставить невыгодно из-за стоимости лицензии.
ИБП стоят от 3.000 и на 50 точек это уже 150.000 плюс оплата работ администраторов на их установку и замену.

РИБ: типовые базы очень тяжелые

В них хранятся драйвера для всех видов торгового оборудования.

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

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

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

РИБ: устаревшие каналы связи

1С использует устаревшие каналы связи для РИБ, которые «валятся», если файл обмена получается большим, например более 1 Гб. А такое случается часто — при обновлениях конфигурации, при длительно отсутствии обмена.

По сути, у 1С реализованы только варианты:

1. Использовать FTP, но без возможности докачки.

2. Яндекс-диск. Но сам Яндекс-диск не очень открыт для бизнеса, это больше хранилище данных для частных лиц.

3. Можно использовать обмен через каталог, развернув VPN, но там опять же нет докачки.

Единственное нормальное решение — это собственная система передачи файлов обновления. Частично ее заменяет ЯД, но он не предназначен для корпоративного сектора, отсюда слабая надежность.

РИБ: устаревшая пакетная идеология обмена

РИБ разрабатывалась, когда интернет был еще слабый. Поэтому была реализована логика отправки пакетов изменений с подтверждениями. Сейчас было бы логичнее передавать изменения порциями в фоне, чтобы не передавать в случае сбоя одни и те же данные. Но на эту тему у 1С нет даже задумок.

РИБ: обновление типовых конфигураций приводит к сбоям

1С часто выливается в сбои на точках, особенно если точек много.

Потому что обновления не особо рассчитаны на РИБ, там может быть большой объем изменений, а большие изменения плохо проходят по реализованным 1С каналам связи.

Часто приходится заниматься ручной синхронизацией для восстановления обмена.

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

РИБ: сбои соответствия конфигурации

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

РИБ: преимущества и недостатки простых конфигураций

на РИБ ситуация получше. Они поменьше объемом, не так масштабно обновляются, особенно если заточены на РИБ, но таких конфигураций мало, мне известна только Магазька. У остальных нужно пытаться использовать минимальные конфигурации, типа 1С:РМК, но тогда получается, что данные из этих конфигураций нужно конвертировать в более мощную учетную систему, теряется преимущество учета в той же самой конфигурации 1С.

РИБ: требуется монопольный доступ для обновления

1С не может принимать изменения в конфигурации, касающиеся изменения данных, если в ней работают пользователи. Иногда это критично, особенно в круглосуточных магазинах.

Оба: проблемы с локальным кэшем 1С

Кэш регулярно приходит в неадекватное состояние, в итоге база не запускается.
Встречается где-то 5 раз в месяц на 50 баз.
Можно автоматизировать, создав пользователю кнопку на рабочем столе или запуск при перезагрузке. Но это лишнее обучение пользователя.

Думаю, автоматизировать проверку корректности кэша несложно, но в 1С не делается.

Оба: транзакционная незавершенность

В обоих случаях транзакционная завершенность не обеспечивается.

Продажа на кассе — это одна длинная транзакция, состоящая из последовательности операций:

1. Сохранение и проведение чека

2. Получение оплаты по эквайрингу, потому что картами расплачиваются очень часто.

3. Сохранение результатов оплаты эквайринга.

4. Пробитие чека.

5. Сохранение результатов пробития.

Сбой такой транзакции может произойти на любом этапе, но РМК 1С не рассчитано на сбои. Все сбои решаются только через поддержку. Нет механизмов автоматической коррекции, повторения и отката транзакции.

В итоге кассир вынужден чаще требуемого обращаться в поддержку.

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

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

1С не работает в плане опроса оборудования о завершенности попытки транзакции.

Облака: база не доступна при отключении интернета

Часто это критично. Но у меня был опыт, когда пытались перейти на РИБ, но столкнувшись с ее недостатками, решили вкладываться в дублирование каналов связи.

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

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