R.I.P. РИБ

19.02.21

Интеграция - Файловый обмен (TXT, XML, DBF), FTP

РИБ, спасибо и до свидания.

Я тут попробовал новый для себя жанр писанины – «типовые письма». Это как типовая конфигурация – решение, предназначенное для определенной цели. Может адаптироваться под клиента, если требуется. Но, в целом, содержит в себе всё необходимое, даже чутка избыточно.

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

Пока вроде получается, поэтому решил с вами поделиться каким-нибудь примерчиком. Вдруг формат будет интересен, я тогда ещё чего-нибудь опубликую.

 

Ситуация

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

Ответам на этот вопрос и посвящено приведённое ниже сочинение на тему РИБ. Сразу прошу прощения за неточность, а порой – за недостоверность технических терминов. Это сочинение для клиента, уровень знаний которого мне не известен. Мне сказали, что это «айтишник клиента».

 

Откуда взялся РИБ

Для принятия решения по РИБ нужно понимать его историю, перспективы и особенности.

Первое и главное: РИБ – устаревшая методология. Пишу именно «методология», а не «технология», т.к. технология РИБ ровно такая же, как в современных обменах.

РИБ – это типа «давайте гонять туда-сюда все данные». Несложно догадаться, откуда она взялась – из зеркалирования в SQL (когда рядом с основной БД ставится вторая, и сервер её постоянно пополняет изменениями).

В те времена, когда создали РИБ, просто выхода другого не было. Интернет стоил по 5-10 р. за Мб, всё писалось под локальную сеть и, максимум, флешку. Сейчас смешно, но тогда люди реально ездили с флешкой по магазинам, чтобы собрать данные о продажах за день. С этой же флешкой ездили во франч за обновлениями.

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

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

Собственно, первые годы и РИБа было за глаза. Как говорили самые говорливые из 1С, ИТ-ландшафты предприятий были гомогенными – состояли или из одинаковых, или из схожих систем.

 

Гетерогенный мир

Потом пришла, по их же словам, гетерогенность – системы стали ужасно разнородными. И со всеми надо было как-то интегрироваться. Да и сама 1С осознала ценность доставки контента через интернет, и начала создавать веб-сервисы. Соответственно, в платформе резко и быстро выросла целая плеяда механизмов интеграции с другими системами, поддерживаемых форматов данных, даже количество поддерживаемых СУБД выросло в разы (ха-ха, с 1 до 4, но это ведь в разы). Появилась нормальная клиент-серверная архитектура, тонкий и веб-клиент, новые стандарты разработки – или, точнее, даже новые подходы к разработке.

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

Уже и сама технология обмена поменялась, появился формат, разработанный самой 1С – EnterpriseData. По сути, тот же XML, но избавляющий разработчика от необходимости описывать сущности бизнес-логики – что-то вроде «конфигурированного XML» (по аналогии с обычной конфигурацией, хранящей метаданные).

А РИБ продолжал существовать, по указанным выше причинам. Но в последние лет 10 даже разработчики 1С от него устали – именно от методологии полного обмена данными.

 

Главная гадость РИБа

Эту методологию, будь она неладна, к великому несчастью, надо учитывать при разработке конфигурации. Создавая любой справочник, документ, регистр или обработку, надо думать: так, а чё у нас с РИБом? Как оно там бегать будет? И даже разработчики 1С иногда стали забывать про РИБ во время разработки конфигураций или каких-то механизмов.

Широко известный в узких кругах пример: расширенная аналитика учета затрат в УПП (на тот момент – флагманский продукт 1С). Сделали шикарнейший, до сих пор непревзойдённый (даже в ERP) механизм расчёта себестоимости. Ну прям закачаешься, прелесть, восторг, мечта. Но…

Забыли, блин, про РИБ. Когда делали оптимизацию структур хранения данных (превращали 40 аналитик в 4, 30 регистров в 2), сделали автоматическую генерацию элементов справочников при проведении документов. И сели в лужу – данные создавались независимо в разных узлах РИБ. На всех заводах с РИБ колом встал расчет себестоимости.

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

Технически выкрутились, но РИБ действительно перестал быть РИБом – данные уже не транслировались, «как есть», а пересоздавались в приёмнике. Если называть вещи своими именами, то это не РИБ, а обычный обмен данными между разнородными конфигурациями. Примерно так же обмениваются данными, например, Зарплата и Бухгалтерия – отправляется только сам документ, да и то без части данных, а всё необходимое «доделывается» в приёмнике (например, проводки, которых в ЗУП нет по определению).

Так оно, в УПП, и осталось. Я на заводе работал ИТ-директором, и мне пришлось собственный механизм допроведения писать. И не один раз – когда есть РИБ, тут без вариантов.

В итоге я выкинул РИБ на помойку. Намного проще и дешевле оказалось купить ВПН на 100 Мбит, и подключить пользователей напрямую. Кстати, в толстом клиенте. Недавно, в сентябре, точно так же сделали одному клиенту – он тоже перестал понимать, зачем ему РИБ, настроенный в 2011 году.

 

А как сейчас?

Технически, в современных типовых конфигурациях от 1С тоже есть РИБ. И он тащит за собой те же проблемы, что и старая УПП. Я вот прямо сейчас сходил в код модулей РИБ ERP, и вижу всё ровно то же. Я даже картинку приложу:

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

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

Раньше же РИБ был у каждого второго клиента.

 

А что будет дальше?

Что с РИБ будет дальше – примерно понятно. Он умрёт. Он никому не нужен, дорого обходится в разработке и поддержке, постоянно ломается. Останется, разве что, зеркалирование на уровне СУБД. Да и то не факт.

Современные системы, не 1Сные, давно забили на РИБ. Там используется, по сути, два метода: кеширование данных (хранение части данных на клиенте) и фильтрованная репликация (обмен ограниченными наборами данных). Причём, они давно переплелись между собой, и хрен поймёшь, где кеш, а где результат репликации. Тот же браузер Google Chrome, без вашего ведома, может занять до половины свободного места на жёстком диске своей встроенной СУБД – IndexedDB, а вы об этом даже не узнаете. Это будет кеширование данных сайтов, прилетевших сюда через фильтрованную репликацию.

Так вот, 1С движется в ту же сторону. Кеширование они освоили давно, в т.ч. на сервере (а мы все, дружно, освоили очистку этого кеша). Фильтрованная репликация – в процессе. Это и есть те самые штуки – формат EnterpriseData, механизм синхронизации, публикация для BI-приложений через интерфейс OData и т.д.

РИБа не будет.

 

Адаптация под клиента

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

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

Если конфигурация, которую вы будете использовать, не содержит возможностей РИБ, то при её разработке не учитывались требования РИБ. Грубо говоря, это автомобиль, создатели которого и не думали, что на их детище будут плавать по морю. Наверное, возможно, за очень большие деньги можно приделать к нему парус, днище и шпангоуты, но первый же шторм расставит всё на свои места.

Особенно с учётом того, что конфигурация у вас не очень распространённая, поэтому специалистов по ней не так много. А это, увы, важно, если создавать РИБ – надо знать и понимать, как работают на техническом уровне все механизмы этой конфигурации.

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

Но самое поганое не в этом. Можно сесть, упереться и сделать РИБ, и он даже будет работать. Но: вам ведь обновляться надо будет. Каждое обновление будет напоминать праздник La Tomatina в Испании – весело, но отмываться долго:

 

 

Примерно так же радовались клиенты УПП 15 лет назад, когда обновление обходилось им в 100-500 (!) часов. Потому что нежелание думать, вникать, адаптироваться заменяли тысячами человекочасов программирования. И 1С не отставала, на пару с нашими законотворцами – такие изменения подкидывали, что дым столбом стоял во время обновлений.

Ну и не стоит забывать о развитии платформы. 1С давно работает над механизмом автономных клиентов. Это тоже из веб-разработки пришло – клиент может продолжать работать, даже потеряв связь с сервером. После восстановления связи данные реплицируются. Пока они это сделали только для мобильной платформы, но, не ровен час…

Ну а если серьёзно, то РИБ – не вариант вообще. Если вам необходимо обеспечить высокую доступность сервера на небольшое количество пользователей, то самое простое решение – резервные каналы интернета, в обеих точках (клиент и сервер). Я на заводе, и мои текущие клиенты давно покупают резервные каналы – это не так дорого.

Основной канал работает с ВПН, т.е. он «удобный» - работает даже толстый клиент, если нужно. Резервный канал – для экстренных случаев, там нет никакого ВПН, но есть тонкие клиенты и/или РДП с проброшенными портами устройств, вроде касс ККМ, сканеров штрихкода и принтеров.

Однако, опять же, никакой франч, в т.ч. мы, не будет сильно возражать против разработки РИБ за деньги клиента. Это увлекательно. Примерно, как резьба по дереву – толку мало, но пальцы тренируются. Хоть мышцу прокачаем.

Такое и раньше бывало. Если программисту или клиенту не нравилось, как работает РИБ в типовой конфигурации, он садился и писал весь обслуживающий код самостоятельно. Дима, привет.

См. также

SALE! 10%

Перенос данных 1C Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор

55778 50200 руб.

04.08.2015    167289    340    278    

376

SALE! 15%

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)

Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

26280 руб.

12.06.2017    142258    803    297    

423

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)

Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.237.x) и БП 3.0 (3.0.166.x). Правила подходят для версии ПРОФ и КОРП.

35000 руб.

15.12.2021    24374    172    51    

131

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 10 Россия Управленческий учет Платные (руб)

Перенос данных из 1С:Управление торговлей 10.3 в 1С:Управление торговлей 11.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УТ 10.3 (10.3.88.x) и УТ 11.5 (11.5.20.x).

35000 руб.

23.07.2020    52019    229    72    

187

Перенос данных 1C Программист Бухгалтер Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет НДФЛ ФОМС, ЕФС Платные (руб)

Обработки для быстрого перехода с конфигураций «КАМИН:Расчет заработной платы 3.0», «КАМИН:Зарплата для бизнеса 4.0» и «КАМИН:Зарплата 5.0» на конфигурацию «Зарплата и управление персоналом» версии 3.1.

12000 руб.

25.09.2016    81035    315    250    

268

Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Программист Платформа 1С v8.3 Платформа 1C v8.2 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием Россия Платные (руб)

Регулярный обмен, выгрузка, перенос из КА 1.1, УПП 1.3, УТ 10.3 для обмена с любыми конфигурациями, поддерживающими обмен в формате EnterpriseData (КД3) - БП 3.0, ERP, КА 2, УТ 11, Розница 2, УНФ 1.6 и другими. Правила для старых и доработанных конфигураций не требуют синхронного обновления и совместимы с новыми и будущими конфигурациями. Обмен по расписанию, через папку, FTP, почту.

15300 руб.

18.02.2016    187223    591    513    

529

Внешние источники данных Кадровый учет Файловый обмен (TXT, XML, DBF), FTP Перенос данных 1C Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 10 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

60000 руб.

05.10.2022    10959    13    8    

15

Зарплата Внешние источники данных Бюджетный учет Перенос данных 1C Системный администратор Программист Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и кадры государственного учреждения 3 Государственные, бюджетные структуры Россия Бухгалтерский учет Бюджетный учет Платные (руб)

Обработка позволяет перенести кадровую информацию и данные по заработной плате, фактических удержаниях, НДФЛ, вычетах, страховых взносах из базы Парус 8 учреждений в конфигурацию 1С:Зарплата и кадры государственного учреждения ред. 3 (ЗГУ) и начать с ней работать с любого месяца года.

84000 руб.

19.08.2020    25292    22    1    

25
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Ziggurat 50 19.02.21 10:28 Сейчас в теме
Иван, читал Ваши произведения каждый раз с упоением, даже думал, сохранить всё в файлик, пусть лежит, время нынче такое. Но этот рассказ породил печаль в моем сердце, скорбных моментов всего два, но, тем не менее, они очень заметны. Сам я знаком с РИБ еще с 7.7, и послеживаю за подобными "методологиями", предлагаемыми в других системах. Дьявол кроется в деталях, поэтому опишу всё по пунктам.
1. Вы пишете "РИБ – это типа «давайте гонять туда-сюда все данные»." - при этом Вы понимаете, что гоняются не все данные, а только изменения, однако, у неподготовленного специалиста (не все работают с 1С), знающего примерный объем используемых данных это сразу вызывает непрятие чудеснейшего механизма РИБ. Я понимаю, Вы работаете на барыг, но ведь не следует двигаться к их уровню и использовать прямые манипуляции, разве это выглядит не безобразно?
2. Вы пишете "Потому что в современном мире методология РИБ – ущербна и никому не нужна." это не РИБ ущербна, это современные программисты в подавляющей своей массе стали ущербны.
h00k; pasha_triniti; SP2000; Maximysis; maksa2005; michmich; Pavl0; ragnar40; kMidas; WellMaster; Airin; zavhome@gmail.com; LynxX; Deslime; vv2; LeXXeR; zaic; memb3r; SamMix; bulpi; user904638; Yakud3a; monkbest; Krasnyj; Xershi; +25 4 Ответить
2. 1c-intelligence 12749 19.02.21 10:31 Сейчас в теме
(1) говорю же, формат новый. Потому и написал в статье: "Сразу прошу прощения за неточность, а порой – за недостоверность технических терминов. Это сочинение для клиента, уровень знаний которого мне не известен."
Vasas2007; Torin; +2 Ответить
3. Ziggurat 50 19.02.21 10:34 Сейчас в теме
(2) В этом-то и проблема, что при неизвестном уровне знаний клиента фраза из п.1. откровенно вводит в заблуждение.
GreenDragon; memb3r; +2 Ответить
4. 1c-intelligence 12749 19.02.21 10:37 Сейчас в теме
(3) да, пожалуй вы правы. Это, наверное, уже автоматизм - называть "данными" то, что в обмене ходит. Он и называется "Обмен данными", хотя там почти всегда изменения.
93. GreenDragon 22.02.21 18:29 Сейчас в теме
(4) Всё, что вы зарегистрируете для обмена, то и будет летать. Регистрируется только то, что нужно передать. Пардон, Иван, но вы с каждой статьёй всё больше негатива во мне порождаете. Я нахожу всё больше аналогий между вами и журналистами с канала ТВ-3.
"...сочинение для клиента, уровень знаний которого мне не известен." - категорически противопоказано показывать вот это ваше сочинение как раз такого рода клиентам. Прекратите вредить, в конце концов!
kMidas; zavhome@gmail.com; +2 Ответить
15. RustIG 1752 19.02.21 12:43 Сейчас в теме
(1) да Боже ж ты мой, цепануло слово "все" - попробуйте изменения в конфигуратор внести, попробуйте свертку ЦБ сделать, - Иван о нестандартных ситуациях пишет - в том числе обновления - они перестали быть стандартными процедурами, начиная от простого, что теперь платформу надо обновлять на каждой точке РИБ, заканчивая более сложными поворотами жизни....Во времена когда обслуживаются несколько сетей и клиентов - подобная заминка сдвигает сроки работ и поддержки по всем клиентам - бьет по кошельку и по нервам всех участвующих... а сколько траблов с РИБ, когда какие -то данные не сели - остатки по товарам не бьются, помнится мне - каждый день искал проблемы....
Да, Бог с вами, пусть даже программисты ущербны, пусть я такой же - ну и что с этого? Каждый внедренец ставит то, с чем ему удобно работать.... Если на уровне платформы и конфигурации есть проблемы, то к программисту они не относятся... Программисты наверное все же должны тратить время на разработку своих систем, а не тестирование типовых и тушение пожаров....
ух..
user658002_SvanMoscow; nekit_rdx; pihy; realsevere; AlexandrN; Vasas2007; timurkhann; dnikolaev; Manoshkin; Torin; +10 Ответить
117. Ziggurat 50 24.02.21 19:34 Сейчас в теме
(15)
Во времена когда обслуживаются несколько сетей и клиентов - подобная заминка сдвигает сроки работ и поддержки по всем клиентам - бьет по кошельку и по нервам всех участвующих.

Может быть Вы просто пытаетесь откусить кусок больше, чем можете проглотить? Жадность это вовсе не плохо, просто не нужно использовать её как аргумент. Если трудно обслуживать нескольких возьмите меньше, всё просто.
118. RustIG 1752 24.02.21 22:17 Сейчас в теме
(117) да, все просто, не будем усложнять жизнь.
5. RocKeR_13 1369 19.02.21 11:01 Сейчас в теме
Угу, а есть еще теперь такая прекрасная вещь, как расширение, которые от релиза к релизу бсп/платформы периодически не хотят мигрировать в узлы)) И поскольку РИБ - это почти всегда файловый вариант работы, то сталкиваемся с такими замечательными явлениями, как "Файл базы данных поврежден", что с большой долей вероятности приводит в свою очередь к распространению битых ссылок после восстановления во все узлы... Но до сих пор остаются упоротые упорные клиенты, у которых "а вдруг у нас на сервере интернет/электричество отключат?!". И сидят годами без обновлений на своем РИБе, с древними машинами и с интернетом на "свистках", пока не приходит ЕГАИС/54ФЗ/маркировка и вот тут у них округляются глаза от счетов на оплату по обновлению/переносу справочной информации в чистую базу актуального релиза с последующей повторной настройкой РИБа... Уж лучше VPN, 1С:Линк или свой web-сервер на худой конец....
nekit_rdx; AlexandrN; zqzq; SuhoffGV; LeXXeR; art.prm; rpgshnik; mvxyz; Torin; RustIG; +10 Ответить
10. TODD22 19 19.02.21 11:40 Сейчас в теме
(5)
"а вдруг у нас на сервере интернет/электричество отключат?!". И сидят годами без обновлений на своем РИБе,

Всё хорошо обновляется и в РИБе, кроме "расширений", но на них свет клином не сошёлся.

А вот отключение интернета/электричества это в порядке вещей. У меня был РИБ на 150 узлов, так же была система мониторинга интернета, которая пинговала магазины и отправляла репорт в тех поддержку если с каким то магазином дольше двух часов не было связи.
И нормальная ситуация когда 10-20 магазинов в течении дня теряют связь по разным причинам, от проблем у провайдера и зависших роутеров или вообще выгоревших из за грозы, сварочных работ по соседству и тд (а где то провайдер вообще один) до того что копали яму порвали магистраль и весь город сидит два дня без интернета, а у нас там 4 магазина к этому провайдеру подключено. Один раз рвали кабель питания на территории предприятия. То есть связи с ЦБ не будет у всех 150 магазинов. Интернет для юр лиц стоит не так же как интернет для физиков.

Сутки простоя 150 продуктовых магазинов это очень дорого.
togowest; Ziggurat; vv2; oldcopy; art.prm; Azamatex; bulpi; yaguarrr; +8 Ответить
11. RocKeR_13 1369 19.02.21 11:50 Сейчас в теме
(10) Ну а почему бы не установить фронтовое решение в магазине? Лицензию покупать в любом случае необходимо, обновлять каждую точку - тоже. Если сбоит база в узле - меньше рисков, что последствия сбоя разлетятся по всей сети магазинов. Опять же, если база совсем "померла", то развернуть новую будет не сложнее, чем узел РИБ. Если поставить оффлайн ККМ типа Frontol на кассах, то пересоздать базу еще быстрее можно, чем РИБ или обмен с фронтовым решением от 1С. Очевидный плюс - это существенно более низкие требования к железу в магазине, особенно если в качестве основной базы используется какая-нибудь КА 2.4, да даже УТ 11.4 сейчас имеет крайне неприятный аппетит
u_n_k_n_o_w_n; art.prm; rpgshnik; RustIG; +4 Ответить
12. TODD22 19 19.02.21 12:01 Сейчас в теме
(11)В магазинах КА и УТ не использовали, с начало была самописная конфа с самописным РИБом, РИБ пишется не сложно.
В связи с ЕГАИСами, онлайн кассами и тд решили перейти на "розницу" так как поддерживать все изменения законодательства дороговато, а коробочка от 1с стоит 15К рублей(ну или сколько там стоит типовая розница).
Ну а почему бы не установить фронтовое решение в магазине?

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

С этим никаких проблем не возникало.


Фронтовый софт это хорошо, быстрее и надёжнее чем решения 1С. Но была задача сделать из того что было.

В целом всё получилось.
x13RUS064; rpgshnik; Senator_I; +3 Ответить
42. yaguarrr 72 19.02.21 14:49 Сейчас в теме
(11)
Алексей. Скорее всего от вида конфигурации и колва загрузки фронтофиса зависит: одно дело ккм в розничноммагзаине другое оптовый продавцы.
Для розницы оффлайн ККМ не вариант, поимел большие проблемы на Штрих-М, пока не избавились в пользу Розницы на РИБ
Пример Якутия (территория в 5 раз больше Франции), магазины могут быть удалены на 1000 км друг от друга.
Связь печальная, может пропадать на месяц если где-то кто-то провод оборвал (каждый год и не раз)
Да и в самом городе на выделенном ВПН отпикать 10000 бут то еще удовольствие в центральную базу - проблема в том что все провайдеры декларируют скорость до Х мбит, но никак не от Y мбит, да и канал выделенный как бутылочное горлышко. OpenVPN- тоже сокрости не большие
В городе мобильная то не везде работает - несмотря на заявленную зону покрытия
РАР приходит требуют предъявить УТМ в магазине с ключом - связь подвисла изза аварии (обмена с егаис нет)
резервные каналы - только спутник - не каждый частник пойдет на это, поскольку РИБ дешевле
По опыту: база в РИБ - 98% это сиквел, да и файловые в последнее время редко вижу, даже на ноутбук на встроенный ССД экспресс версию ставят
А так на РИБ на легких конфигурациях - все таки независимо работают от центра.
Что касается тяжелых конфигураций - ЕРП и КА - там да - ВПН+тонкий клиент (вебморду по опыту почти нигде не любят), себестоимость производства на заводе.
Помимо будущих автономных клиентов - сомнительно -тот же егаис. Но встречал однажды - на сиквеле запили обмены и обновления (рекламу приводить не буду) - наверное всетаки - это предпочтительнее там где нет возможности для тяжелой конфы на впн работать
16. Torin 830 19.02.21 12:55 Сейчас в теме
(10)
Всё хорошо обновляется и в РИБе, кроме "расширений", но на них свет клином не сошёлся.

(10)
У меня был РИБ на 150 узлов

вывод! РИБ это дорого и требует надлежащей поддержки!!
P/S а что будет если в центре документы за пару месяцев перепровести? :) Узлы обрадуются?
17. TODD22 19 19.02.21 13:05 Сейчас в теме
(16)
P/S а что будет если в центре документы за пару месяцев перепровести? :) Узлы обрадуются?

Вы же должны понимать к чему приводят ваши действия в ЦБ. Так как:
РИБ это дорого и требует надлежащей поддержки!!


Ну и по поводу "дорого" сложно сказать, можете предложить вариант дешевле коробочного РИБа с небольшими доработками правил регистрации?

Если эти данные нужны в узлах то какие ещё есть варианты? А если не нужны(у нас они не нужны в узлах, из узлов данные о продажах, в узлы НСИ, цены и тд) то правилами регистрации можно рулить что, куда и при каких условиях должно попадать.
togowest; +1 Ответить
19. Torin 830 19.02.21 13:10 Сейчас в теме
(17)
то правилами регистрации можно рулить что, куда и при каких условиях должно попадать.
- вот и ответ! У Заказчика должно быть понимание РИБ его требований , его узких мест! и т.д.! - А если уровень не известен? - то целиться на РИБ это лотерея! А вдруг заказчик вменяемый? А вдруг они знает все тонкости этого инструмента?
20. TODD22 19 19.02.21 13:13 Сейчас в теме
(19)
У Заказчика должно быть понимание РИБ его требований , его узких мест! и т.д.!

Понимание должно быть у того кого наняли эту работу делать.

Поругать РИБ и я могу.

Предложите решение для автоматизации сотен узлов по цене коробки Розницы?
yaguarrr; +1 Ответить
25. Torin 830 19.02.21 13:30 Сейчас в теме
(20)
Предложите решение для автоматизации сотен узлов по цене коробки Розницы?

Frontol :)
27. TODD22 19 19.02.21 13:37 Сейчас в теме
(25)
Frontol :)

Хорошее наверное решение, не работал с ним.
Оно на 1С?
Мы же про обмены в 1С.
yaguarrr; +1 Ответить
30. Torin 830 19.02.21 13:42 Сейчас в теме
(27)Нет не 1С :) Но прекрасно обменивается с 1С информацией :)
Прикрепленные файлы:
31. TODD22 19 19.02.21 13:44 Сейчас в теме
(30)Мы же вроде про механизмы обмена в 1С. А не про выбор софта для кассы в магазине.
32. Torin 830 19.02.21 13:49 Сейчас в теме
(31)
Мы же вроде про механизмы обмена в 1С. А не про выбор софта для кассы в магазине.
- а для какой еще цели нужен РИБ? Ну для какой ? БП в РИБ? - или ЗУП в РИБ? ERP в РИБ? Где еще применяется РИБ если не в торговле в магазине? Ну чтобы был живой пример " Мы используем 100500 РИБ БП" - есть такой? Я за свою практику не встречал! А вы?
33. TODD22 19 19.02.21 13:52 Сейчас в теме
(32)
Ну чтобы был живой пример " Мы используем 100500 РИБ БП" - есть такой? Я за свою практику не встречал! А вы?

Да есть. На текущей моей работе у меня 80 баз БП в РИБе из них 40 баз это работающие производственные предприятия с численностью от 40 до 1000 человек. Через РИБ управляем конфигурацией для всех баз, НСИ и консолидируем некоторые данные в специальных узлах.
34. Torin 830 19.02.21 13:56 Сейчас в теме
(33)
Через РИБ управляем конфигурацией для всех баз, НСИ
- то есть используете РИБ как централизованного поставщика конфигурации? и Справочной информации? - " аля безобразно, но единообразно" ?

p/s присказка - юмор
35. TODD22 19 19.02.21 13:57 Сейчас в теме
(34)
то есть используете РИБ как централизованного поставщика конфигурации? и Справочной информации?

Да. Дополнительно есть несколько узлов которые консолидирует в себе определённые хоз операции по нескольким схожим по функциям компаниям для обмена со сторонним софтом.
49. yaguarrr 72 19.02.21 17:53 Сейчас в теме
(32)

Крупные оптовики либо на сап либо на УПП в риб, у АЛРОСА когдато встречал САП- из него в 1с бух, сейчас вроде полностью на 1с ЕРП перешли, тоже РИБ. "......нерго" ЕРП 2.0 на риб (кажется 12 шт), хотя есть свой спутниковый канал выделенный - но на чрезывачайные ситуации и контроль (Россети ФСК)...
Да много где..
вот обмен разработали https://softpoint.ru/solutions/db-replication/
однажды столкнулся - очень понравилась реализация
54. genayo 19.02.21 19:57 Сейчас в теме
(32) Ну вот, справедливости ради, тут была статья, как вся розница Билайна в одной базе 1С работает. Интересно, конечно, как сейчас у них дела...
criptid; СергейК; +2 Ответить
48. yaguarrr 72 19.02.21 17:33 Сейчас в теме
(30)
Обмены с какой частотой? С минусами методы борьбы?
пришло на две кассы "дирол А" 10 шт и "дирол Б" 10 шт
На первой кассе продавец отбил "Дирол А" 5 шт и на второй кассе продавец отбил вместо 1шт "Дирола А" и 9 шт "Дирола Б" сразу 10 шт "Дирол А" - банальное нес тала считывать Марфуша шк с каждой пачки жев.резинки а считала превую и вбила колво 10 или если стоит флаг считывать каждую позицию то считала шк с первой упаковки дирола А 10 раз
в учетной системе в результате обмена имеем пересорт - а на самом деле банальный минус.
Закрывать как будете? ИМНС еще не отказывала в списаниях по инвентаризации по "технической ошибке" (просто программа так работает)?
47. yaguarrr 72 19.02.21 17:23 Сейчас в теме
(27)
Хорошее, красивое, РМК намного лаконичнее, но борьба с минусами остатков..... Это общая проблема всех оффлайн-касс
РИБ избавил нас от таких проблем
77. hollyfood 21.02.21 15:14 Сейчас в теме
(25) Тех, кто предлагает Frontol сетевым клиентам ( с планами от 20 и выше магазинов) надо бить ссаным веником, могу утверждать это уверенно за 15 лет его эксплуатации еще с его предшественника РМК. Нормальных механизмов обновления большого парка - ноль, Контроля версионности, мониторинга - ноль. Сейчас, с непрерывным госзаказом (егаисы-маркировки) постоянно выходящие обновления Фронтола нужно на каждую кассу сети (у нас их около 300) нужно устанавливать вручную, очередное обновление релиза занимает у всего отдела 2 (две) недели, ближе к концу из-за офигенной тестировки со стороны Атола в этом релизе обнаруживается несовместимый с нормальной работой глюк, разработчики правят, выкладывают новый релиз и 2 недели обновления по новой. И так бесконечно. Плюс к тому же сов в Атоле уже видимо больше чем не сов - вперед никто не смотрит, то кофеварку к Фронтолу приделают, то документы ЕГАИС, которые сейчас сами же и выпиливают. А реально нужных изменений не допросишься. В общем, как сказал один из бывших ПМ Фронтола (уже избавились от него) - Фронтол не предназначен для сетевых клиентов, он для комков.
64. dj_tol 104 20.02.21 03:52 Сейчас в теме
(20)Кристал. Это программы для фронта. У 1С для фронта только Розница нормально работает (не дорого) идля 1 - 5 магазов. Если больше то 1С нужно использовать как БЭК офис а фронт заменить на отказоустойчевые системы.
67. rpgshnik 3800 20.02.21 09:58 Сейчас в теме
(5) да их вроде в целом опасно использовать в РИБ :) они и без РИБ бывают не стабильны. Буквально не давно в РИБ на узле создал расширение (чисто для узла) и словил баги с ролями. Даже после удаления расширения - расширение словно использовалось. Помогло вылечиться только обновление из центра.
6. alk 3 19.02.21 11:01 Сейчас в теме
Эти ваши тонкие клиенты на HTTP через VPN, звучат, конечно, безумно круто. 21-й век, гигабитные скорости и вот это всё. Жаль, что это работает лишь в городах. А вот в Сибири... Да что там, в часе езды от Тулы приличный интернет, кроме мобильного (у которого скорости никогда не соответствуют заявленным), появился менее года назад. И вот там-то РИБ живее всех живых и ещё долго будет актуален
firml; togowest; user1315860; criptid; oldcopy; smit1c; namazi74; rpgshnik; bulpi; yaguarrr; burmsergey; RustIG; +12 Ответить
8. RocKeR_13 1369 19.02.21 11:06 Сейчас в теме
(6) для удаленных магазинов лучше использовать ПО уровня "Фронт": Frontol, 1С:Касса, 1С:Розница и настроить обмен через любой облачный диск с центральной базой. В итоге на кассах можно не ставить производительный ПК и в случае чего проще будет развернуть чистую базу взамен поврежденной, так как вся информация агрегируется и используется для отчетности в бэк-офисе. А то наставят УТ с кривым РМК, настроят РИБ и потом на касса эта УТ еле шевелится спустя пару лет
rpgshnik; yaguarrr; Torin; +3 Ответить
7. Tarlich 116 19.02.21 11:03 Сейчас в теме
Конечно мир не стоит на месте .....
Когда я еще 20 лет назад узнал РИБ - да это был такой прорыв знаний !
Конечно у меня за время использования возникали трудности но не так все плачевно ....
И сейчас использую у множества клиентов .... и БУДУ использовать -))
Senator_I; burmsergey; RustIG; +3 Ответить
21. RustIG 1752 19.02.21 13:22 Сейчас в теме
(7) РИБ на Рознице 2.2 хорошо себя показывает... С чем я столкнулся...
А вы на каких конфигах РИБ используете?
yaguarrr; +1 Ответить
9. genayo 19.02.21 11:37 Сейчас в теме
Иногда РИБ - это исторически сложившаяся данность. Классический пример - розничная сеть, выросшая со 100 до 3000 магазинов за 3 года :)
yaguarrr; alk; +2 Ответить
22. RustIG 1752 19.02.21 13:23 Сейчас в теме
(9)скажите пож-та что за сеть такая
29. genayo 19.02.21 13:39 Сейчас в теме
(22) На алкоголе и табаке специализируется :)
37. RustIG 1752 19.02.21 14:23 Сейчас в теме
(29) россияне пьют....продолжают пить...сеть растет... капец, блин....
39. 1c-intelligence 12749 19.02.21 14:29 Сейчас в теме
40. RustIG 1752 19.02.21 14:40 Сейчас в теме
(39) К&Б перешли с нового года на УТ 11 - был пресс-релиз у фирмы 1С (только не помню с нового 2020го или 2021го)
41. 1c-intelligence 12749 19.02.21 14:44 Сейчас в теме
(40) а в магазе до сих пор 7.7 вроде.
53. genayo 19.02.21 19:55 Сейчас в теме
(40) Это про бэк, наверное. Они же не идиоты УТ 11 на фронт ставить.
55. 1c-intelligence 12749 19.02.21 19:58 Сейчас в теме
(53) сходил, перепроверил: в магазе - 7.7
Senator_I; +1 Ответить
57. genayo 19.02.21 20:00 Сейчас в теме
(55) Ну, значит у них какая-то реализация псевдо-РИБ. Или Кафки с Кроликами какие-нибудь.
131. Ndochp 103 27.02.21 01:11 Сейчас в теме
(57) Почему РИБ то сразу? РИБ это не полный обмен, это прежде всего обмен конфигурацией. А полный обмен это совсем другая просто рядом технология.
В сое время накушавшись "ой, коряво встала конфа, забыли нажать F7, данных никому не дам" оставили в РИБ конфигурацию и все. Рядом пустили полный обмен с предварительной рассылкой правил, стопорящих обмен между разными версиями, только если это нужно. Доступность сильно повысилась, доработка печатной формы убивать обмены перестала.
56. genayo 19.02.21 19:58 Сейчас в теме
(37) Растёт... уже больше 7 тыс. магазинов на настоящий момент, ЕМНИП.
58. genayo 19.02.21 20:03 Сейчас в теме
(56) Ого, перепроверил, в сентябре 2019 года сеть насчитывает 8141 магазин...
13. FesenkoA 59 19.02.21 12:07 Сейчас в теме
все хорошо и красиво пишете если смотреть на мир через очки больших клиентов. Да, когда это 12 магазинов, офис, 2 удаленных склада и отдельно руководство. Но вот смотрим на предприятие с оборотом меньше 100 000$ в год. В нем работает офис и бухгалтер. Офис формирует документы по 1 форме, бухгалтер проверяет правильность и подает отчеты. Стоит 2 бухгалтерии, сервер - это файлопомойка в локальной сети офиса, который выключается в 18:00. Какие есть альтернативы РИБу?
yaguarrr; +1 Ответить
23. RustIG 1752 19.02.21 13:24 Сейчас в теме
(13) РИБ для сдачи отчетности? научили бухгалтера запускать обмен? так может научить копию для себя делать? для отчетов
88. FesenkoA 59 22.02.21 12:33 Сейчас в теме
(23) бухгалтер правит документы 1 формы и офис должен работать уже с новыми данными. Например есть несколько контор, которые работают как одна, делают закупки, продажи. Бухгалтер разбивает суммы, и количества по разным компаниям. Когда один из клеинтов просит счет - бухгалтер формирует его по остаткам организации чтобы не превысить лимит продаж в год. После этого офис печатает и отсылает клиенту. Выгрузка базы это не вариант воообще.

даже если только отчеты. бухгалтер правит ошибки, формирует отчет 2-3 дня. за это время офис может набить десяток новых документов. Кто кого затрет?
43. MazhutkoAV 19.02.21 15:38 Сейчас в теме
(13) Офис и бухгалтер?! Почему не арендовать в облаке? Пусть даже 1000 рублей за подключение в месяц * 12 * 2 = 24 000 / курс = 800 $. Не так дорого.
x13RUS064; +1 Ответить
44. MazhutkoAV 19.02.21 15:40 Сейчас в теме
50. yaguarrr 72 19.02.21 17:58 Сейчас в теме
(43)

Облака хороши для малых компаний без скелетов в шкафу. Бизнеса некторые нужные документы хранит отдельно на съемном помещении, также отдельно сервера с базами.
FesenkoA; +1 Ответить
68. MazhutkoAV 20.02.21 11:04 Сейчас в теме
(50) У нас к одному арендатору УТ, обладателю скелетов, пришли, компьютер забрали, он нашёл другой, к базе подключился и дальше работает. Правда там какие то копеечные дела.
89. FesenkoA 59 22.02.21 12:39 Сейчас в теме
(43) ну вот, РИБ дешевле на 800$ в год))
70. RocKeR_13 1369 20.02.21 16:30 Сейчас в теме
(13) 1С:Линк и бухгалтер хоть в автобусе на планшете пусть доки смотрит)
87. FesenkoA 59 22.02.21 12:29 Сейчас в теме
(70) 1) все таки 7000р в год это больше чем 2000р 1 раз
2) в нашей стране нет Линка
3) старая бухгалтерия на обычных формах
14. comol 5110 19.02.21 12:25 Сейчас в теме
РИБ это имплементация программного шардинга с обнаружением коллизий и гарантированной доставкой. Вцелом хороший механизм для реализации CP систем на платформе 1С. Про ED, кэширование и OData конечно какая то чушь приплетена. РИБ надо не умертвлять а развивать - это же инструмент масштабирования в том числе
user1835472; zqzq; Cерый; yaguarrr; Gorus; RustIG; TODD22; kkv90; kuntashov; alk; +10 Ответить
24. RustIG 1752 19.02.21 13:27 Сейчас в теме
(14) об этом и речь, что разработчики платформы РИБ не развивают, РИБ остался как пережиток прошлого.... Но про него забывают при программировании новых систем.... Выходит плачевно....
u_n_k_n_o_w_n; +1 Ответить
26. comol 5110 19.02.21 13:36 Сейчас в теме
(24) Ну как бы это не "умер" это скорее "не хватает возможностей и гибкости РИБ в современных условиях"...
38. RustIG 1752 19.02.21 14:26 Сейчас в теме
(26)ясно) ладно, развивать некому.... что не развивается, умирает... ладно, эта философия смысла ни к чему не приведет....я к тому написал, чтовы написали "развивать надо....", а я уточнил, что "развивать-то некому...." тренды другие...
18. yyv-911 19.02.21 13:06 Сейчас в теме
перевели всех на 1 сервер из-за проблем с риб. Поимели другие проблемы.
Нет альтернативы рибу при прямых руках. )
Самое важное в риб это отслеживание изменений - это основная суть.
Все остальное (транспорт и т.д.) не так важно.

Но соглашусь - стандартный риб это непонятный сложный механизм.
28. comol 5110 19.02.21 13:38 Сейчас в теме
(18)
Нет альтернативы рибу при прямых руках. )
change tracking, гарантированная доставка, доставка конфигурации - важные и нужные механизмы...Их бы развить.... чтобы распределенная ИБ была именно распределенной а не отдельными связанными ИБ...
36. dsdred 3644 19.02.21 14:02 Сейчас в теме
Блин весело получилось...
Мне тут досталась конфа на РИБах и я последние 2 месяца плююсь.
А тут прям в жилу и в конце
Дима, привет.


Я аж вздрогнул...
sapervodichka; +1 Ответить
45. KapasMordorov 428 19.02.21 16:29 Сейчас в теме
Да уж.
Клиент-сервер - первый серьезный порог входа 1Сника в профессию.
Интеграция - второй.
46. 1c-intelligence 12749 19.02.21 16:38 Сейчас в теме
(45) ещё нулевой есть - ошибка формата потока и нарушение целостности.
pm74; Yimaida; +2 Ответить
51. Cерый 26 19.02.21 19:12 Сейчас в теме
Замечательная статья, резкие выпады, неожиданные заключения. Благодарю Вас, Вы отлично пишете.

О СУБД: почему Вы говорите о зеркалировании, ведь речь идет о синхронизации?
Видите ли Вы общие стороны синхронизации SQL и работой РИБ?
Применим Ваши аргументы отказа от РИБ к отказу от синхронизации SQL и посмотрим на них с точки зрения MicroSoft,
не думаю, что MS считает эту технологию (пусть методологию) устаревшей/неперспективной.
Насчет себестоимости: проведение части документов требует полного объема данных - это вопрос учетной дисциплины;
Ваш пример ERP любопытен, тем не менее - похоже на ситуацию, когда смотрят на огнетушитель и думают - неудачники, горят!
Насчет сложностей разработки: на этом этапе решается вопрос о включении новых объектов в отдельные планы обмена,
насчет остального - мне приходилось писать только ограничения на передачу в коде,
конечно, с дополнительными инструментами регламентных обменов, усечений файловых узлов, альтернатив выгрузок новых узлов (стандарт довольно долгий),
тем не менее, не вижу принципиальных изъянов технологии платформы.
Уверен, Вы представляете, как падает производительность системы с увеличением числа пользователей,
кроме возможных проблем с доступом, отказ от РИБ - это повышение требований к производительности.
yaguarrr; +1 Ответить
52. 1c-intelligence 12749 19.02.21 19:45 Сейчас в теме
(51) в УПП не в дисциплине вопрос - там ключи (справочник) создавались при приведении документов, а состав ключей лежал в регистре сведений.

Проводите два вообще разных документа, но с одним набором аналитик, независимо в разных узлах - получаете два ключа (разных по гвиду) и две одинаковых записи в РС аналитик. А ключ там пишется в ресурс, т.е. в ключ регистра не входит.

После делаете обмен и получаете дубли в РС. Узнаёте о них только при расчете себестоимости - приход по одному ключу, расход по другому.
80. Cерый 26 21.02.21 20:42 Сейчас в теме
(52)
Благодарю за ответ. Насчет УПП спорить не буду - видимо, работал на более ранних версиях, тем не менее - что дальше?
Вы написали в техподдержку, в следующей версии обновились? Так или иначе - речь идет не о багах отдельной конфы, но об общем инструменте системы.
Предполагаю, использование РИБ будет сокращаться с увеличением доступности/надежности InterNet;
с другой стороны, отказ от РИБ - увеличение на порядок подключений к серверу/требований к производительности, более того:
starik-2005 / 12.01.17 / https://forum.infostart.ru/forum34/topic164384/:
Фактически в 1С нет механизмов, позволяющих комфортно работать больше 100 пользователям. Все остальное - это совсем нетиповое оборудование + различные скульные оптимизаторы от известных и неизвестных контор. Даже примитивный шардинг, использующийся везде для оптимизации работы с базами данных, 1С не позволяет делать, превращая высоконагруженные решения в танцы с бубном вокруг оптимизации всего и вся. Не умеет это 1С искаропки. В итоге при 100+ реально активных юзверей контора попадает:
1. На постоянную работу эксперта с целью оптимизации решения.
2. На мощные сервера.
3. На стороннее ПО для оптимизации скульных запросов.
4. На разделение базы на отчетную и оперативную.
59. ltfriend 19.02.21 20:15 Сейчас в теме
Сейчас смешно, но тогда люди реально ездили с флешкой по магазинам, чтобы собрать данные о продажах за день.

Как это знакомо. Я аж прослезился ))
76. Tarlich 116 21.02.21 11:41 Сейчас в теме
(59) у меня одна сеть аптек до сих пор ездит . и по утрам он же чеки в ОФД отправляет -))
60. anosin 29 19.02.21 20:54 Сейчас в теме
Там то что 1с называет "Риб" ниразу не Риб в классическом понимании СУБД.
После отказа от Риб пришлось городить собственный обмен и миграцию данных если между базами организациями и складами есть перемещения и одни и те же мастерданные требуются в разных базах.
Но с другой стороны появилась возможность имеет разные конфиги особенно если территориально находятся в разных часовых поясах
61. bulpi 217 19.02.21 21:21 Сейчас в теме
Риб будет работать нормально, если :
1)прямые руки у программистов
2)конфигурация не монстр типа УПП, а самописная конфетка.
Но я уже давно такого не делал, т.к. интернет и RDP рулит.
62. 1c-intelligence 12749 19.02.21 21:55 Сейчас в теме
(61) самописная конфетка - это та, что 10 лет назад Серёга написал, потом умер, и с тех пор никто не смеет трогать? (да и не хочет никто, особо-то).
63. genayo 19.02.21 22:07 Сейчас в теме
(62) Хороший вопрос, а что не самописка, кроме типовых от 1С?
69. bulpi 217 20.02.21 12:14 Сейчас в теме
(62)
Ну я то пока жив :) Не дождетесь :)
Но даже то, что написал Серега (мир праху его) и то лучше, чем уебищное УПП.
84. u_n_k_n_o_w_n 35 22.02.21 10:15 Сейчас в теме
(62), а может просто помогли, чтобы больше не писал таких конфигураций. :-)
65. rpgshnik 3800 20.02.21 09:49 Сейчас в теме
Но: вам ведь обновляться надо будет. Каждое обновление будет напоминать праздник La Tomatina в Испании – весело, но отмываться долго:


Это реально боль :) Я то же против РИБ.

Есть увы ещё такие точки на карте России, где не то, что резервный, а обычный канал еле еле дышит. И РИБ не умрёт пока там интернет не будет стабильный.
71. RocKeR_13 1369 20.02.21 16:56 Сейчас в теме
(65) Есть у нас клиенты, которые прекрасно работают в связке "Бэк - УТ ПРОФ <--> Фронт - Розницы Базовые". Магазинов под сотню, интернет в большинстве магазинов - мобильный USB-модем, который во многих точках еле дышит. Другие в качестве фронта используют Эвотор, третьи - Frontol. Обновлять РИБ с медленным интернетом - это удовольствие ниже среднего. Это либо ехать на точку с флешкой, либо сидеть и мониторить выгрузки, чтобы после окончания обмена отключить автоматический обмен, чтобы точка смогла в принципе подгрузить к себе файл с обновлением. Куда проще настроить облако/FTP сервер, куда помимо файлов обмена можно закидывать необходимые обновления. Но и как с РИБом может возникнуть проблема после обновления бэк-офиса: может слететь обмен с фронтами. Хотя тут же и получаем преимущество: при обновлении ЦУ РИБ мы обязаны всегда обновлять подчиненные узлы, а вот при обновлении бэк-офиса обмен с фронтами может и продолжит работать; плюс мы можем обмен с фронтами восстановить не обновлением этих фронтов, а только обновлением правил обмена.
79. rpgshnik 3800 21.02.21 18:44 Сейчас в теме
(71) я не про магазины, я про производство. Туда с флэшкой только на вертолете бывает даже 🤣
66. Darklight 33 20.02.21 09:52 Сейчас в теме
Согласен с автором - РИБу R.I.P - и, вероятно, в следующем (ну или через одно) крупное обновление редакции платформы (я намекаю на 8.4, 8.5) его выпилят из самой платформы (но это только вероятность, если вообще будет такое обновление, на минорных релизах точно не выпилят).

Сейчас весь обмен уходит в микросервисы (обычно на основе HTTP-Соединений, в т.ч. REST API), ну и облачные технологии. Кстати, почему-то как альтернатива VPN не были рассмотрены web-клиент и тонкий клиент по HTTP - конечно, это не выделенный канал, но зачастую для очень удалённых узлов - это хорошее решение (где VPN не стабилен, да работать в таких клиентах с нестабильным каналом не ахти как приятно, но куда приятнее чем через удалённый терминал, который постоянно падает, ну и это просто дешевле - что важно для удалённых мелких узлов типа ларьков и иже с ними; при это наличие VPN канала это не отменяет (но и не требует), скорее это альтернатива RDP). Ждём технологию автономных данных для WEB-Клиента и Тонкого клиента. Пока - только на мобильной платформе подымать - но с появлением Мобильного клиента тут всё стало куда проще - в таких ларьках можно рабочее место и на мобильной ОС организовать - да хоть на том же ChromeOS на ноутбуке, или работать с планшета на Android (ждём поддержку клиентов 1С Предприятие на Windows Arm, ну и на новых MacOS Arm за компанию).

Ну а для случаев применения РИБ в зеркалировании есть уже другие решения (идущие от возможностей СУБД + сторонние компоненты). Конечно, хотелось бы и поддержки со стороны платформы 1С Предприятие тут иметь - чтобы прям из неё можно было бы настраивать зеркалирование базы на разные серверы в разных сценариях бизнес-логики (от параллельной работы сразу во всех зеркалах (с общим менеджером управляемых блокировок), для получения резервных баз, до получения баз только на чтение; и чтобы можно было указывать критичные данные - синхронизация которых наиболее важна).

Так же неплохо бы добавить в платформу нативную поддержку подключения разных шин обмена сообщениями - что так же упростило бы настройку обмена данными (в в т.ч. в формате EnterpriseData).
Как вариант - в мелких ларьках можно было бы поставить условно офлайн копию базы (или боле урезанную конфигурацию - не ставить же везде ERP 2) - и формировать из неё в шину данных сообщения по сформированным документам - отправлять их в центральную базу уже асинхронно. И так же асинхронно получать сообщениях актуализации состояния учета. Вести полный учет во всех разделах в таких узлах бессмысленно (да и вообще - вести учет в каком-либо разделе учёта имеет смысл только в одном узле, в других отчасти можно дублировать - но с приоритетом основного узла)
101. comol 5110 23.02.21 11:32 Сейчас в теме
(66)Блин, ещё один.... Ничего не смущает в словах "распределенная" - нет, "микросервисная" - да... Не возникает мысли что что то тут не так? Что система с микросервисной архитектурой должна иметь рачпределенное хранилище... И доставку сообщений, не? :)))))
106. Darklight 33 24.02.21 09:48 Сейчас в теме
(101)Меня ничего не смущает.
Распределённая информационная база - это технология, которая может быть использована в архитектуре построения распределённой бизнес-логики.

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

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

С доставкой сообщений (транспортировка) в 1С всё ещё хуже хотя (с появление Центра Взаимодействий) и тут есть прогресс. Но, всё-таки, лучше бы иметь больше возможностей для интеграции с другими сторонними шинами данных
Но РИБ тут ничего не имел своего
108. comol 5110 24.02.21 12:18 Сейчас в теме
(106)
Платформа 1С пока мало что умеет по части распределения - и да - РИБ тут была вершина этих умений


Хм... оказывается понимание всё таки есть. И даже эту возможность вы решили похоронить?

Так вот.... для микросервисной архитектуры нужно распределенное хранилище, так?
Хм.. притом ведь не только хранилище, а систему распределенного хранения метаданных (cassandra, consul, zookeeper в класике) так?
Да и не только для распределенной, а для любой крупной системы это нужно, так?
Нужно ещё доставку сообщений организовать (kafka, rabbitMQ), так?
Ну и change tracking нужен... (обычно в СУБД).

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

И что же вы стали хоронить единственное что в 1С есть для децентрализованного хранения метаданных, гарантированной доставки и чендж трэкинга... Ладно автор статьи, который и слов то таких не знает, но вы вроде как знаете...
112. Darklight 33 24.02.21 13:56 Сейчас в теме
(108)
Платформа 1С пока мало что умеет по части распределения - и да - РИБ тут была вершина этих умений
Хм... оказывается понимание всё таки есть. И даже эту возможность вы решили похоронить?

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

Так вот.... для микросервисной архитектуры нужно распределенное хранилище, так?

Совсем не обязательно. Часть микросервисов вполне могут быть изолированы по данным друг от друга. Часть - использовать общие общие данные в СУБД, которая может быть вообще внешней для 1С Предприятия. Часть использовать данные одной и той же СУБД-но зеркалируемой на разные сервера (или не зеркалируемой, а синхронизируемой через те же микросервисы, без всякого РИБ). Часть может использовать вспомогательные микросервисы для общего доступа к распаренным данным!

Я не спорю, что 1С не хватает распределённого хранения, в т.ч. распределённого хранения метаданных на уровне платформы. Но обычно, это обходится сторонними решениями. Но да - в эту сторону платформе точно стоит развиваться - и в анонсах 1С Предприятие 8.4 это маршрут был слегка обозначен. Вот только нет больше пока анонсов 1С Предприятие 8.4 - и это печально

Нужно ещё доставку сообщений организовать (kafka, rabbitMQ), так?

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

РИБ вам обеспечивает и 1е и 2е и 3е... При этом не завязан на сторонние технологии.

Сама по себе технология РИБ ничего этого не обеспечивает ВООБЩЕ! РИБ - это достаточно жёсткий протокол сцепки и синхронизации баз данных с условно одинаковыми метаданными! Шаг в лево - шаг в право - расстрел! И Ходьба по прямой - периодические глюки! На РИБ часто смотрят как на на чёрный ящик - не вдаваясь в детали как он работает - от того проблемы множатся! В РИБ нет ни удобных контейнеров передачи данных, ни шины данных, а система событий и диспетчеризация примитивней некуда. А распределённость - весьма условна, ограничивается лишь тупым механизмом полной синхронизации - на уровне зеркалирования!

И что же вы стали хоронить единственное что в 1С есть для децентрализованного хранения метаданных,

Какой в этом смысл? В том как это реализовано в 1С - смысла в современных реалиях почти нет!

А хороню не я - хоронит рынок - просто не используя технологию в новых проектах. И не развивает вендор!

Другие (не 1С) бизнес приложения сейчас строятся без всякого РИБ - и уходят от монструозных конфигураций - каждому узлу - своя система и свои микросервисы, и своя синхронизация. И вот, сделать этот подход удобным в 1С - и есть задача разработчиков будущей редакции платформы 1С Предприятие 8
72. starik-2005 3092 20.02.21 17:01 Сейчас в теме
С интересом прочитал комменты (статью не читал, но согласен полностью). В принципе все мнения хороши: и тех, кто за РИБ, и тех, кто в нем не видит ничего полезного (я вот тоже не вижу).

В принципе не смог себе придумать кейса, где бы нужен был вот прям РИБ. Если это ларек, то он прекрасно работает с многочисленными системами (их просто огромное количество), реализующих тот самый формат offline-кассы (только сегодня это к ЕРП подтыкал на базе того самого фронтола - работает отлично, проблем без какой бы то ни было поддержки не было ни разу, я это еще лет 15 назад использовал в супермаркетах, разбросанных по региону, и уже тогда они работали со всеми видами касс, весов, сканеров ШК, а 1С толком со всем этим делом не работала без пинка).

Если это производственное какое-то подразделение, то там MES-системы рулят и не нужно уда тащить на рабочее место сторожа, открывающего шлагбаум, ЕРП (а ведь до такого доходит!!! при том прога для автоматического открывания шлагбаума по известному номеру стоит копейки).

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

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

1С - это бэкофис, система хранения событий и, может быть, даже НСИ (хотя отдельная MDM тут более уместна, если мы говорим не о ларьке, а о крупной компании распределенной сетью филиалов). Для процессов надо юзать BPM, для взаимоотношений - CRM, для производства - MES, для розницы - ARM кассовое, коих сейчас сотни, и которые могут чеки прям в почту закидывть клиенту - "берегите лес". И, да, РИБ остается только там, где исторически сложившаяся архитектура быоа на нее завязана, а у ИТ-отдела порезали косты или не закинули в бюджет возможностей на переход кассовых узлов на какой-нить оффлайн-АРМ.

Дальше из всего этого коробочного обновляемого и поддерживаемого ПО (ну смысл свой MES писать или BPM, кассовый блок?) данные должны перетекать в бэкофис, ложиться событиями и формировать учетные регистры. Это как раз DevOps для конечного пользователя, к чему все медленно и верно идет.
Darklight; u_n_k_n_o_w_n; user1534961; +3 Ответить
74. genayo 21.02.21 09:03 Сейчас в теме
(72) Только возникает один вопрос - а зачем вообще тут 1С?
Дмитрий74Чел; +1 Ответить
78. starik-2005 3092 21.02.21 16:32 Сейчас в теме
(74) отчетность регулятору сдать.

Не, ну и есть еще те, кто верят в себестоимость в ЕРП. Блажен, кто верует - тепло ему на свете... (с)
82. IvanPoh 25 22.02.21 06:01 Сейчас в теме
(78)
В чем же великая проблема себестоимости в ерп можно узнать?
90. starik-2005 3092 22.02.21 13:20 Сейчас в теме
(82) ну даже банально отразить ее там - весьма непростой процесс.

Вот, допустим, у вас есть поле с травкой. Вы ее скосили, утрамбовали, закрыли пленкой. На выходе когда-то будет силос. Потом вскрали, кормите коровушек которые дают вам за это молока. А тут кабаны пришли, пожрали, потоптали, а потом еще налило воды, сгнили остатки. Да, мы тут раздолбаи, ибо нет у нкс сотни кетайцеф, кто бы это по цене китайского трактора год хранил и берег.

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

Да, если у вас какое-то производство из болта и гайки - ЕРП тут примитивна и проста, но и здесь вы заипетесь спецификации пилить и этапы описывать.

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

Реально в экселе это все считается как два пальца, а в ЕРП тебе нужна армия консультантов и поддержка, чтобы хоть что-то приблизительнле получть.
user1835472; dabu-dabu; zqzq; Gorus; +4