Как работает 1С размером 13 ТБ в условиях непрерывной разработки

27.03.20

Интеграция - Перенос данных 1C

Обеспечение быстрого непрерывного обмена данными между высоконагруженными системами 1С, покрывающими всю территорию России, требует ответственного подхода к архитектуре и инструментам, используемым для обмена. Как правильно построить такую инфраструктуру и научиться ее оперативно мониторить, в своем докладе на конференции Infostart Event 2019 Inception рассказал разработчик компании «ДНС Ритейл» Максим Старков.

Меня зовут Максим Старков, я работаю в команде управления системами 1С компании «ДНС Ритейл». Наша команда занимается вопросами, связанными с эксплуатацией систем, реализованных на платформе «1С:Предприятие».

Я хочу рассказать о том, как работает 1С размером в 13 ТБ в условиях непрерывной разработки, а также поделиться опытом эксплуатации таких систем.

 

Задачи команды эксплуатации

 

 

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

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

Итак, давайте я по каждой задаче поделюсь некоторым опытом.

 

Архитектура системы базового обмена данными

 

 

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

  • Оценить объем данных в компании ДНС достаточно сложно. Он зависит от многих факторов. Но в среднем можно сказать, что за одну итерацию обмена между двумя узлами уходит около 50 Мб данных.
  • Обмен выполняется каждые 15 минут. В итоге за один день между двумя узлами проходят миллионы объектов.
  • Из всех систем можно выделить основную – мы называем ее центральной или управленческой базой данных. Она состоит из головного узла и 9 подчиненных территориально распределенных узлов. Это классический вариант распределенной базы данных. На данный момент размер основного узла центральной базы составляет 13Тб. Региональные узлы имеют размеры от 1 до 2 Тб данных.
  • Кроме этого, у нас также есть и другие системы. Это – склад, сайт, система продаж и бухгалтерия. Со всеми этими системами нам нужно обмениваться.

 

 

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

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

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

Чтобы увеличить параллельность работы при выгрузке и формировании пакетов, мы используем прямые запросы в базу данных:

  • первое, что мы делаем, – это устанавливаем с помощью прямого запроса номера сообщений для пакетов (я думаю, все знакомы с квитированием обычных обменов);
  • и также прямым запросом очищаем таблицы изменений – но в основном это делаем только с нашим регистром сведений.

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

 

 

Далее – формируем пакет обмена:

  • При записи информации в пакет обмена мы используем свои XML-узлы и атрибуты XML-узлов. Они понадобятся нам в дальнейшем, когда мы эти данные будем считывать.
  • Чтение данных в базах-приемниках мы выполняем в параллельном режиме.
  • Специальные XML-узлы и атрибуты предназначены для того, чтобы наши алгоритмы параллельного чтения распределяли порции из пакетов и загружали их параллельно. На рисунке можно увидеть, что у нас в каждом XML-узле есть атрибут Order, и при считывании в базе-источнике все данные, которые в нем находятся, распределяются между пулом потоков, который реализован на основе фоновых заданий. Здесь тоже ничего удивительного нет.

Таким образом, мы умеем быстро выгружать и загружать данные, поддерживая продолжительность цикла обмена не более 15 минут. На самом деле, получается значительно быстрее.

 

Apache Kafka для обмена данными по изменениям цен

 

 

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

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

Было принято решение вынести этот контур обмена в отдельную систему, и в качестве транспорта для этой системы мы решили использовать брокер сообщений Apache Kafka.

 

 

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

  • у нас есть три кластера Apache Kafka, распределенных по разным регионам всей России;
  • в каждом кластере – по три брокера;
  • в каждом брокере есть три темы;
  • и в каждой теме – по 10 разделов (партиций);
  • данные в кластере синхронизируются по брокерам с помощью внутренних механизмов Apache Kafka (обычно это репликация, а у нас – тройная репликация).
  • Также мы синхронизируем данные между кластерами. Из коробки Kafka этого делать не умеет. Но есть прекрасная утилита MirrorMaker, с помощью которой у нас, по сути, три наших кластера хранят в себе одни и те же данные, и географически распределены по всей России.

 

 

Что мы делаем дальше?

  • Когда происходит изменение цен, мы записываем эти данные в соответствующую тему. Кроме этого, мы формируем хэш для записи. То есть указываем ключ, который определяется по наборам характеристик номенклатуры. Таким образом, каждая номенклатура с определенным набором характеристик всегда попадает в одну и ту же партицию (или в раздел). Я уже говорил, у нас их 10, и это – жесткая настройка. Если мы изменим количество разделов, у нас, конечно, все «уедет». Или придется как-то останавливать обмен, и все это приводить в порядок.
  • Для чего нам нужно соблюдать соответствие номенклатурных позиций определенным партициям? Это нужно, потому что Kafka не гарантирует порядок записи сообщений в одной теме. Гарантия записи сообщений есть только в том случае, когда мы пишем в один и тот же раздел. Таким образом, мы храним в Kafka историю цен. Там есть небольшой промежуток времени, за который хранится вся история цен.
  • Дальше, для работы с Apache Kafka и 1С мы решили использовать Rest Proxy интерфейс от разработчиков Kafka (фирмы Confluent). Он бесплатен, любой может его поднять. И в принципе можно работать с Apache Kafka из 1С без внешних компонент, используя стандартное HTTP-соединение. Возможно, это работает не так быстро, как компоненты от известных на Инфостарте людей, но очень хорошо работает.

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

 

 

Каждый кластер хранит в себе данные цен всех других регионов. Поэтому чтение цен других регионов выполняется очень быстро:

  • с помощью Apache Kafka мы получили некое централизованное хранилище цен, отдельную систему;
  • данные по ценам больше не нагружают основной обмен – он работает, как и раньше;
  • значительно сократилось общее время от момента изменения цены до синхронизации этих данных между всеми системами. Также получили большой плюс, что к нашему хранилищу цен на Kafka могут подключаться и другие системы – это система продаж, сайт и вообще, кто угодно.

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

 

Автоматизация обновления конфигураций

 

 

Следующая задача нашей группы эксплуатации – это автоматизация обновления конфигураций.

  • У нас много программистов, они выполняют очень много помещений (коммитов) в хранилище – порядка 30 в день, иногда даже значительно больше.
  • И бизнес говорит нам, что мы должны обновлять конфигурацию баз данных каждый будний день.
  • Но с этим есть одна проблема – время для обновления (допустимое технологическое окно) – с 6 до 7 утра по времени Владивостока.

 

 

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

Архитектурно, система автоматического обновления имеет:

  • служебную конфигурацию на платформе 1С:Предприятие
  • и специальное приложение, написанное на C#, которое установлено в качестве службы на всех рабочих серверах кластеров 1С, которые у нас есть.

 

 

На скриншотах вы можете видеть функциональность служебной конфигурации.

 

 

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

В принципе, это можно сделать с помощью технологического журнала и его определенных настроек, которые есть на партнерском форуме. У кого нет доступа к партнерскому форуму, эти настройки можно найти на Инфостарте.

 

 

В технологическом журнале мы получаем событие System, в котором выводится вся нужная информация – какие объекты метаданных будут реструктуризированы, какая это будет реструктуризация – полная или не полная. Кроме этого, у нас есть накопленная статистика по времени реструктуризации тех или иных таблиц баз данных.

 

 

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

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

 

 

Вернусь к автоматизации обновления. Все довольно просто. Мы не используем современные технологии, в том числе другие движки, которые умеют читать язык 1С. Так повелось исторически, но мы довольны.

У нас запуск автоматического обновления происходит, когда в пакете обмена есть данные конфигурации.

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

  • она закрывает соединения с базой данных;
  • в случае необходимости удаляет сеансы, которые «зависли»;
  • при необходимости может даже рестартануть службу (бывает такое, что сеансы могут остаться – например, в случае какого-нибудь длительного отката транзакции, когда сеанса уже нет, соединение с базой данных будет держаться, и соединение в кластере тоже будет жить).

Такой механизм позволяет в течение часа (в период технологического окна) обновить нашу конфигурацию во всех узлах – центральный узел и все 9 узлов, от Дальнего Востока до Калининграда.

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

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

 

Мониторинг систем

 

 

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

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

  • во-первых, это сбор логов работы приложений;
  • второе – это сбор показателей производительности оборудования и серверов;
  • и третье – это сбор собственных метрик.

 

Сбор логов приложений 1С

 

 

Мониторинг работы приложений у нас реализован следующим образом:

  • Наш основной рабочий инструмент – это, конечно, технологический журнал платформы 1С. Мы его очень активно применяем.
  • На каждом рабочем сервере у нас настроен вывод всех важных событий технологического журнала, а также собираются все события длительностью более 1 секунды. Наш технологический журнал получается довольно массивным, но мы не храним большой период, нам важно оперативно решать проблемы и иметь небольшую историю – хотя бы месяц.
  • Для обработки данных технологического журнала мы используем стек технологий EBK (Elasticsearch, Beats и Kibana).
  • Большая часть анализа выполняется автоматически. У нас есть список определенных запросов в Elasticsearch, результаты которых говорят нам о том, что что-то пошло не так: либо появились какие-то управляемые блокировки, либо runtime-ошибки, либо непонятные перезапуски рабочих процессов и т.д.

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

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

 

 

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

В том числе мы добавляем свои поля – log_type, log_timezone (так как у нас распределенная система, нам обязательно нужно указывать временную зону, иначе у нас появляется неразбериха).

 

 

Обработкой поступающих данных занимается сам Elastic. В нем есть прекрасная возможность Ingest Node – она по умолчанию уже задействована и работает. Если Elastic состоит из нескольких служб, то Ingest Node можно назначить на любой из серверов, из которых состоит кластер. С помощью настроенного Pipeline Ingest Node умеет парсить данные техжурнала.

 

 

С помощью pipeline мы разбираем запись лога технологического журнала на определенные фрагменты – выявляем оттуда:

  • длительность;
  • имя события;
  • номер сеанса;
  • контекст;
  • description в Exception и много других параметров.

В принципе вы можете найти такой pipeline в интернете, чтобы ничего не изобретать – он там есть. Там только одна хитрость – Filebeat и Elasticsearch будут по умолчанию записывать данные в техжурнал с тем временем, с которым Filebeat их отправил. Но нам нужно точное время из записи самого техжурнала, а для этого нужно поработать над этим pipeline, чтобы вырезать данные, склеить их и записать настоящее время.

 

 

В итоге все это выглядит вот так – мы анализируем информацию с помощью Kibana (визуализатор для Elasticsearch). У нас в Kibana настроено много каких-то своих отборов, агрегаций. В том числе есть различные дашборды.

 

 

Кроме этого, иногда возникает необходимость собрать более подробные данные технологического журнала. Например, мы исследуем проблемы с производительностью какого-то механизма, какого-то фонового задания, или какой-то пользователь вдруг начал жаловаться на производительность. В этом случае мы формируем в файле настроек технологического журнала отдельный узел, где указываем отдельное местонахождение для вывода файлов технологического журнала в отдельный каталог. И Filebeat, когда производит чтение из этого каталога, шлет эти данные уже не в основные индексы технологического журнала, а в специальный индекс трассировки. Это сделано для того, чтобы мы не загрязняли в Elasticsearch данные нашего технологического журнала данными наших трассировок. Потому что вероятно, что-то может задублироваться или показать какие-то лишние срабатывания.

Мы можем вывести техжурнал в отдельный каталог, настроить отбор (по номеру сеанса, по номеру соединения, по пользователю – как угодно в целом) – это позволяет нам расследовать проблему производительности. Мы эти данные соберем в отдельном индексе, проанализируем, решим, найдем, устраним проблему. И потом мы этот индекс спокойно удаляем – это чисто служебные данные.

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

Анализируется действительно море информации. У нас в постоянном режиме происходит оповещение мессенджера – что сейчас происходит с базой данных, есть ли блокировки, какие-то Runtime-ошибки.

Кроме этого, Runtime-ошибки мы выводим напрямую в отдельный чат для разработчиков. К сожалению, в 1С не статическая типизация, и возникает очень много Runtime-ошибок, которые просто невозможно предусмотреть (всевозможные «Поле объекта не обнаружено» и т.д.). Эти ошибки моментально выявляются с помощью технологического журнала.

 

Мониторинг состояния обменов данными

 

 

Кроме технологического журнала нам нужно мониторить еще и состояние обменов данными. Для этого у нас есть несколько инструментов, но самый основной и наглядный из них – карта. По сути, это изображение географической карты, на которой отображены все узлы обмена и потоки данных между ними. Как мы видим, карта насыщена узлами обмена, и они, местами, как мы видим, не в очень хорошем состоянии.

На карте каждый узел имеет определенный цвет.

  • Если он зеленый, значит, итерация обмена этого узла занимает менее 15 минут времени.
  • Если он красный и мигает, то итерация обмена превышает 30 минут, и нам нужно на это как-то реагировать.
  • Желтый цвет означает, что мы находимся между 15 и 30 минутами.

Карта интерактивна, она также выводится на большом мониторе, также на вторых мониторах наших коллег. Карта реализована на HTML и JS, а бэкэндом является служебная конфигурация на 1С.

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

Если мы видим, что с обменами что-то не так, то с помощью этого инструмента уже более подробно видим, что именно пошло не так. Может быть, просто объем данных увеличился. А может быть, действительно, получили какую-то ошибку, и приходится что-то делать.

И, наконец, если какой-то узел задерживается с обменом на более чем 15 минут, мы получаем уведомления в наши чаты и мессенджеры.

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

 

Мониторинг СУБД

 

 

Дальше – мы также мониторим ситуацию на СУБД.

  • Единственное, что мы можем мониторить – это блокировки и длительные запросы.
  • У нас есть несколько инструментов, но основной из них – это десктопное приложение, написанное на C#, которое получает данные о сеансах со всех наших серверов СУБД, и в случае появления конфликтов блокировок или длительных запросов выводит необходимое уведомление на рабочий стол.
  • Однако этот инструмент ничего не знает об управляемых блокировках, которые в текущем времени можно мониторить только с помощью технологического журнала или периодически опрашивать консоль серверов. Но так как информация из технологического журнала у нас собирается в режиме реального времени, то все сообщения о проблемах мы получаем моментально. В том числе видим пространство блокировок в случае возникновения ошибок, и какой сеанс кому мешает. Эти оповещения, конечно, происходят не при возникновении какого-то одного конфликта блокировок (это для наших объемов допустимо), но есть определенный уровень, выше которого мы считаем, что уже есть проблемы.

 

Сбор показателей производительности

 

 

Мониторинг работы оборудования и показателей производительности.

  • Для сбора показателей производительности работы серверов и оборудования мы используем обычные инструменты, но данные храним в базе данных InfluxDB.
  • Для анализа и оперативного оповещения используем Grafana.

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

 

Сбор собственных метрик

 

 

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

  • Мы сразу отказались от очередного регистра сведений или, тем более, журнала регистрации. И решили отправлять произвольные метрики из кода посредством протокола UDP. Это, конечно, спорная тема, но UDP гораздо быстрее, чем TCP. Но 1С не умеет работать с UDP напрямую, поэтому мы реализовали внешнюю компоненту и некий небольшой интерфейс, написанный на 1С, который каждый разработчик может вставлять в свой код и отправлять через UDP определенные данные.
  • Метрики мы храним в ClickHouse. Это отличная база данных, но она, к сожалению, тоже не умеет читать протокол UDP.
  • Поэтому для чтения UDP мы используем промежуточное звено – это logstash. Он из коробки умеет слушать UDP-порт и принимать на него данные. Также есть плагин, который позволяет выливать данные из logstash в ClickHouse. Его нужно немного покрутить, но он стартует довольно быстро. В итоге мы умеем слать в ClickHouse произвольные метрики прямо из кода, и при этом не создавать почти никакую нагрузку на основную базу данных.
  • Единственное, UDP предполагает, что возможны потери пакетов. Но наше нагрузочное тестирование показало, что потери пакетов начинаются только при сверхвысокой нагрузке. Но такая нагрузка – это, видимо, уже совсем другой уровень.

Кроме событий открытия форм, таким образом, мы собираем и замеры времени.

Кстати, ClickHouse очень хорошо умеет агрегировать данные. Мы отсылаем сначала первое событие, а потом, например, после окончания проведения – второе. У них есть одинаковый GUID, и ClickHouse умеет это все клеить, соединять между собой и находить дельту по времени.

Таким образом, мы в текущем времени мониторим, например, время проведения всех документов.

На слайде вы видите хитрый график, выведенный через Grafana. Здесь разноцветными точками представлены различные типы документов. Это – распределение, показывающее, с каким временем происходит проведение этих документов.

 

Заключение

 

 

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

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

В заключение могу сказать, что эксплуатировать такую огромную распределенную систему на платформе 1С:Предприятие – это реально.

 

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.

 

10 - 12 октября 2024 года состоится конференция INFOSTART EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Администрирование серверов 1С и СУБД. HighLoad оптимизация
  • Инструментарий разработчика. Приемы и методы разработки 
  • Интеграция и обмен данными 
  • Мобильная разработка и чат-боты 
  • Управление проектом и продуктом 
  • Управление командой 
  • Управление ИТ 
  • Мотивация, лидерство и личная эффективность 
  • Идеи и тренды в разработке

INFOSTART EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

SALE! 15%

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

Перенос данных 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. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.

25080 руб.

12.06.2017    137259    747    292    

399

Перенос данных из УПП 1.3 в ERP 2 / УТ 11 / КА 2. Переносятся документы, справочная информация и остатки

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

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

45650 руб.

04.08.2015    161828    365    272    

357

Перенос данных из ERP 2 / КА 2 / УТ 11 в БП 3.0. Переносятся документы, начальные остатки и справочники

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

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

34650 руб.

15.04.2019    69740    172    143    

113

Перенос данных из УТ 10.3 в УТ 11.5. Переносятся документы (обороты за период), справочная информация и остатки

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

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

28000 руб.

23.07.2020    47855    207    64    

169

[ED2] Обмен УПП 1.3, КА 1.1, УТ 10.3 с EnterpriseData (универсальный формат обмена), обработка

Перенос данных 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, почту.

14580 руб.

18.02.2016    184001    570    509    

513

Перенос данных из БП 3.0 в УТ 11 / КА 2 / ERP 2. Переносятся начальные остатки, документы и справочники

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

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

45650 руб.

31.10.2014    233513    91    329    

299

Переход и перенос данных из УПП 1.3 в ERP 2.5, КА 2.5. Переносятся документы (обороты за период), справочная информация и остатки

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

Переход и перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:ERP Управление предприятием 2.5 и 1С:Комплексную автоматизацию 2.5 с помощью правил обмена. Переносятся остатки, документы (обороты за период), справочная информация. Правила проверены на конфигурациях УПП 1.3 (1.3.227.x), ERP 2.5 (2.5.16.x), КА 2.5 (2.5.16.x) .

28000 руб.

24.06.2020    61929    47    27    

78

Перенос данных из ERP 2 / КА 2 в ЗУП 3. Переносятся остатки, документы и справочники

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

Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Воспользовались более 79 предприятий! | Готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | В продаже с 2020г. | Оперативно обновляем правила до актуальных релизов 1С | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!

43450 руб.

03.12.2020    34970    84    59    

82
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. ogre2007 299 27.03.20 16:59 Сейчас в теме
В ДНС магазинах раньше были 1С, а сейчас у них веб клиенты, без признаков 1С.
6. max_st 310 27.03.20 21:57 Сейчас в теме
(1)Система продаж, которая используется в магазинах работает не на 1С. Это свой внутренний продукт на C#. В докладе об этом не стал уточнять. На 1С работает своя ERP система для бэк-офиса.
2. RustIG 1670 27.03.20 18:59 Сейчас в теме
3. Xershi 1496 27.03.20 19:19 Сейчас в теме
Так 13 ТБ это рабочая база или все узлы?
И как данные размазаны?
Про КОРП платформу ничего не сказано или материал написан, до дня Х?)
4. Torin 765 27.03.20 20:02 Сейчас в теме
(3)
На данный момент размер основного узла центральной базы составляет 13Тб. Региональные узлы имеют размеры от 1 до 2 Тб данных.
user1315860; BairamovTM; max_st; +3 Ответить
5. Torin 765 27.03.20 20:13 Сейчас в теме
(0) Очень интересно кто!! и как часто анализируется информация? и сколько человеко/часов используется для этого
7. max_st 310 27.03.20 22:00 Сейчас в теме
(5)У нас есть отдел, который занимается мониторингом и эксплуатацией всей системы. Часть информации анализируется автоматически. Расклад по затратам трудовых ресурсов раскрывать не стану, но скажу, что в отделе менее 10 человек.
8. Torin 765 27.03.20 22:04 Сейчас в теме
(7) Коллега.я о другом..такой большой объем информации анализировать..в любом случае нужно визуально... Очень интересная тема. Не в онлайн режиме же они мониторят..как баг листы ведут..как документируют.
10. max_st 310 27.03.20 22:13 Сейчас в теме
(8)Ответил в корень ветки, ошибся)
9. max_st 310 27.03.20 22:12 Сейчас в теме
Объем информации действительно большой, но 2/3 информации поступает от внутренних систем автоматизации мониторинга, т.е. информация уже агрегирована и мы можем понять по её поступлению, что нам нужно делать далее.
В рабочее время можем следить за информацией в режиме он-лайн.
Документация по инцидентам и сам факт их появления учитывается во внутренней системе учета задач.
Конечно же, еженедельно просматриваем логи и метрики вручную, чтобы выявить что-то особенное.
В планах, начать использовать систему для автоматического выявления аномалий в метриках и логах. Работаем над этим.
teflon; acanta; Torin; +3 Ответить
11. muskul 28.03.20 05:21 Сейчас в теме
Не сразу понял что 13 ТЕРА байт и по 2 ТЕРА байта каждый узел. впечатляет.
12. baracuda 2 28.03.20 10:02 Сейчас в теме
молодцы, что тут сказать) я думал что 1Гб это большая база, а тут такое)
13. neuromancer_aza 49 28.03.20 14:11 Сейчас в теме
(12) 1 Гб это пустая база УНФ уже. Кажется пора начинать привыкать к большим цифрам.
14. dexxxqqq 28.03.20 14:19 Сейчас в теме
(13) 640 килобайт хватит всем
товарищ Ын; +1 Ответить
15. acanta 28.03.20 15:09 Сейчас в теме
Подскажите пожалуйста, правильно ли я поняла, что на перифериях и в центре конфигурации одинаковые и разница только в данных? Клиент никак не связан с центральной базой 1с в режиме онлайн?
21. RustIG 1670 28.03.20 23:08 Сейчас в теме
(15) я сначала подумал, что так - по крайней мере начинали они наверное именно так, что ЦБ и периферия были схожими конфигурациями. Потом штат разработчиков рос, задачи усложнялись, конфигурации ЦБ и периферии стали отличаться... Для этого они сами формируют xml-пакеты обмена, сами их распознают при загрузке, сами переопределили алгоритм задания номеров сообщений... Я думаю, что клиент не связан с ЦБ в онлайн-режиме.
16. hamsar 16 28.03.20 15:32 Сейчас в теме
Непонятно как вы поступаете, когда в регистре на млрд записей все таки надо добавить измерение
20. RustIG 1670 28.03.20 23:02 Сейчас в теме
(16) не знаю как они, а я бы сразу создал новый регистр с новой логикой. Если для старых сведений измерение не нужно было использовать, значит и в старый регистр не надо его вставлять. Создаем новый регистр с новой логикой, в котором сведений еще не млрд записей.
33. alex_art 14 30.03.20 00:31 Сейчас в теме
(20)
а потом джойним\подзапросим все вновь созданные РСы с самым первым РСом для получения достоверных сведений за весь период существования этой бизнес логики. При этом не забываем, что связанных РСов столько, сколько раз было необходимо добавить новое измерение :))))))))))))
34. RustIG 1670 30.03.20 09:09 Сейчас в теме
(33) вам новый регистр в таком случае, конечно, не поможет... мое предложение не для вашего случая, к сожалению. А для тех, когда это допустимо при прочих условиях.
50. Vortigaunt 96 21.04.20 23:51 Сейчас в теме
(33) Ну мы так делаем. Не вижу ничего плохого в таком подходе. Я конечно не имею ввиду базу таких размеров. С такими объемами и близко не сталкивался. В таком случае новый регистр и сам по себе часто оказывается логичным и к месту. Вот вам пример. Есть у нас конфигурация где в регистр сведений записываются все продажи, каждая позиция. За длительное время этот регистр разрастается очень сильно. Встала задача прикрутить оплату банковской картой. Надо где-то хранить информацию об оплатах картой чеков. Для этого заводим новый РС: Оплаты картой. И связываем со старым РС по полям: Касса, Номер чека и т.п. Бонусом имеем возможность хранить более 1 транзакции оплаты на 1 чек. А также имеем в отдельном месте историю всех транзакций.
51. alex_art 14 22.04.20 09:29 Сейчас в теме
(50)
Есть у нас конфигурация где в регистр сведений записываются все продажи, каждая позиция. За длительное время этот регистр разрастается очень сильно. Встала задача прикрутить оплату банковской картой. Надо где-то хранить информацию об оплатах картой чеков. Для этого заводим новый РС: Оплаты картой. И связываем со старым РС по полям: Касса, Номер чека и т.п. Бонусом имеем возможность хранить более 1 транзакции оплаты на 1 чек. А также имеем в отдельном месте историю всех транзакций.

Это все ужасно :)))) я думал только у меня архитектурный коллапс.
23. user612295_death4321 29.03.20 09:04 Сейчас в теме
(16) Вроде были ответы на вопросы, где Максим отвечал, что они используют подмену таблиц (подсовывается пустышка без данных, которую 1С воспринимает как родную таблицу).

Вот примерно по такому же принципу https://infostart.ru/public/199018/ .
35. max_st 310 30.03.20 09:12 Сейчас в теме
(23)Да, именно так и поступаем.Исследуем возможности умной реструктуризации в новых версиях платформы. Пока результаты положительные, планируем переход.
Zhilyakovdr; nekit_rdx; acanta; hamsar; +4 Ответить
38. hamsar 16 30.03.20 09:24 Сейчас в теме
(35)
(23)Да, именно так и поступаем.Исследуем возможности умной реструктуризации в новых версиях платформы. Пока результаты положительные, планируем переход.


Спасибо за ответ!
52. tormozit 7176 02.05.20 08:15 Сейчас в теме
(35) Перешли на новую штатную реструктуризацию? Вот это будет супер интересно - узнать опыт ее эксплуатации на таких объемах данных. Механизм до сих пор в статусе Бета видимо потому, что мало обкатки.
53. rinat_alp2 61 04.05.20 12:07 Сейчас в теме
(52) Еще не перешли, тестируем новую реструктуризацию с точки зрения больших объемов, например:
1) При добавлении в регистр накопления реквизита новый механизм использует alt er table add column и это быстро, но при добавлении измерения или ресурса происходит пересчет таблиц итогов (создание новых и удаление старых).
Если таблицы итогов небольшие, то это не страшно, но они могут быть и большие.
2) Если таблица регистра накопления была создана давно (поле _Period с типом datetime) и добавить хотя бы реквизит, то это вызовет конвертацию типа поля _Period в datetime2(0).
Что на больших объемах не успеет в технологическое окно: переливка значения через update, создание новых индексов и перестроение кластерного индекса, пересчет таблиц итогов.
Сейчас конвертируем понемногу datetime на datetime2(0).
17. insurgut 207 28.03.20 18:06 Сейчас в теме
Или я пропустил, или осталась нераскрыта тема конфигурации сервера под базу в 13ТБ. Интересно было бы конфигурацию узнать (о:
ansh15; zabaluev; +2 Ответить
39. max_st 310 30.03.20 09:37 Сейчас в теме
(17)Давайте кратко расскажу:

Процессор Intel® Xeon® Platinum 8160M CPU @ 2.10GHz, 2095 МГц, ядер: 24, логических процессоров: 48 - две штуки
Диски Micron 9200 SSDs (with NVMe) - много :)
Intel® Optane™ SSD 900P/905P Series - для tempdb и логов транзакций.
Память - 1,5 ТБ.

Это конфигурация основного сервера с центральным узлом.
На регионах конфигурации попроще, но справляются.
firma_unix; insurgut; +2 Ответить
48. spbsichkar 02.04.20 12:35 Сейчас в теме
(39) для tempdm рекомендую использовать RAM, если конечно объем памяти позволяет взять хороший запас на рост базы.
http://winramtech.atwebpages.com/RAMDriv/main/try_buy_on.htm

рекомендую и стоит 11$ и работает на серверах до 2016

Мы используем уже давно, более 1,5 лет. Без сбоев.
(39)
55. buganov 203 30.11.20 18:32 Сейчас в теме
(48)очень плохой совет. Вы уверены, что получите прибавку в производительности произвольной системы только выводом tempdb в RAM? А как же анализ, как же исследование на предмет ускорения КОНКРЕТНОЙ базы под РАБОЧЕЙ нагрузкой?
Почему не советуете всю базу выгрузить в оперативную память? Ну быстрее же по идее?
18. CheBurator 3125 28.03.20 21:48 Сейчас в теме
"Если с планами обмена все понятно, то зачем нам понадобился дополнительный регистр сведений? Он нам нужен для того, чтобы в нем регистрировать изменения тех объектов, которые при выгрузке и загрузке должны с собой забирать связанные данные, чтобы в момент загрузки в единой транзакции загрузить не только сами данные, но и все, что с ними связано. Таким образом, мы обеспечиваем целостность загружаемых данных в базах источниках."

- то есть следует читать так - использование штатных возможностей планов обмена не позволяет обеспечить целостность данных?
или я что-то принципиальное не понял?
19. RustIG 1670 28.03.20 23:00 Сейчас в теме
(18) штатные не позволяют. вообще нет такого понятия "штатные" возможности. План обмена - это объект метаданных, дальше логику его использования надо программировать самим. Пример - аналогия с любым другим объектом метаданных: справочники или документы, регистры расчета, регистры бухгалтерии ...
36. max_st 310 30.03.20 09:16 Сейчас в теме
(18)Да, именно так. В файле обмена все такие данные собраны в одном xml-узле, обработка которого происходит в единой транзакции. Самый простой пример - документ и его движения.
zhichkin; +1 Ответить
56. CheBurator 3125 08.02.24 16:47 Сейчас в теме
(36) "Он нам нужен для того, чтобы в нем регистрировать изменения тех объектов, которые при выгрузке и загрузке должны с собой забирать связанные данные," - ну так если связанные данные участвуют в обмене то они или в этом сеансе обмена были зарегистрированы к обмену или раньше. Зачем их регистрировать дополнительно?
22. acanta 28.03.20 23:53 Сейчас в теме
Если в РИБ регистрация обмена очищается в момент получения ответа, то в случае с произвольным планом обмена ( кроме разнесения связанных данных по различным объектам архитектуры) очистка регистрации выполняется в момент выгрузки и для повторной передачи утерянного пакета необходимо повторно зарегистрировать изменения?
А ответ получателя на регистрацию изменений не оказывает никакого влияния.
Возможно, в БСП есть механизм, дополняющий функционал планов обмена контролем ответов (в виде регистра сведений).
24. acanta 29.03.20 09:32 Сейчас в теме
Я пришла к выводу, что в 1с8 предъявляются особые требования к связи между периферией и центром отправителем и получателем -"не уверен, что получатель поймет правильно загрузит пакет - не выгружай", отсюда сравнительно небольшая известность конвертацией и высокая популярность "единой базы", т.е комплексной, ЕРП и т.д. которая лично мне совершенно была непонятна.
Но в случае с большими данными, когда все упирается в физические ограничения это особенно интересно в плане широковещания, когда кд3 ставит задачу просто выгружать по формату.
Но почему при таких мощных возможностях рлс так низка популярность РИБ (логично же ли эти рлс использовать как ограничитель данных при обмене с привязкой к узлу РИБ - или оно так не работает?).
25. kamisov 210 29.03.20 12:42 Сейчас в теме
А была бы правильная архитектура - незачем было бы и подвиги совершать.
27. roman72 382 29.03.20 13:52 Сейчас в теме
(25) Похоже на критику ради критики, без предложений. Какая архитектура была бы "правильной" в описанном случае?
lunjio; spbsichkar; Fox-trot; +3 Ответить
28. kamisov 210 29.03.20 15:39 Сейчас в теме
(27) а это же было на самом инфостарте в сентябре. После доклада были вопросы к Максиму и команде, где Максим согласился с тем, что если бы изначально данные лежали не в регистре бухгалтерии (который и занимает почти все 13ТБ), то и не было бы никаких 13ТБ. Собственно, под архитектурой я понимаю иной способ расположения данных, использование нескольких регистров вместо одного, например. Поэтому это пример вынужденного геройства, команда решила проблему большого костыля. Безусловно они молодцы, что справились с такой трудной задачей. Но будь выбрана другая архитектура, повторюсь, было бы все проще.
starik-2005; acanta; zhichkin; +3 Ответить
30. roman72 382 29.03.20 19:43 Сейчас в теме
(28) Ааа, спасибо за ответ. Мимо моего внимания проскользнуло, что 13ТБ засажено именно в регистр бухгалтерии. Кстати упустил и то, что непонятно на какой же конфигурации 1С строит свою архитектуру в DNS автор статьи, если опорой избран регистр бухгалтерии. ERP? Но там регистр бухгалтерии не является держателем всей информации. БП3?
31. kamisov 210 29.03.20 20:26 Сейчас в теме
(30) вроде УПП была, но точно не помню.
32. roman72 382 29.03.20 23:53 Сейчас в теме
(31) УПП уже к 1ТБ кошмар для производительности..... Короче, Станиславский, не верю, не УПП у них ))) Может автор объявится и уточнит?
37. max_st 310 30.03.20 09:20 Сейчас в теме
(32)Конфигурация у нас самодельная. Типовые конфигурации только для бухгалтерии и расчета заработной платы.
В регистре бухгалтерии у нас примерно 60% данных из всего объема. И это в основном индексы на таблицах итогов и движений.
Такая архитектура сложилась "исторически", мы делаем все возможное, чтобы сохранять технический долг в рамках разумного. Но все равно - приходится работать с тем, что есть сейчас.
42. roman72 382 30.03.20 13:10 Сейчас в теме
(37) Спасибо за ответ. А эта самописная конфигурация работает с расширениями? И потом, если она самописная, то архитектуру её вы сами можете преобразовывать без оглядки на 1С.
44. max_st 310 30.03.20 14:16 Сейчас в теме
(42)Конфигурация на обычных формах, поэтому пока не можем в полной мере использовать расширения.
Считаем, что пока справляемся с действующей архитектурой, но что можно быстро поменять - меняем.
Вопрос архитектуры конечно же важный, но очень много того, что сложилось "исторически".
Чуть ниже Димтрий Жичкин хорошо прокомментировал вопрос относительно архитектуры)
41. zhichkin 1464 30.03.20 11:20 Сейчас в теме
(25) Правильной архитектуры не бывает - это миф. Оптимальной архитектура может быть только в отдельно взятый момент времени. Архитектура должна быть адаптивной, меняясь вместе с организацией, процессами и т.д. Это особый вид искусства.
Отличная книга по этому поводу: Complex Enterprise Architecture: A New Adaptive Systems Approach
46. starik-2005 3051 30.03.20 15:18 Сейчас в теме
(41)
Правильной архитектуры не бывает - это миф.
Все зависит от точки зрения. ИТ-архитектура конкретного решения должна отвечать требованиям к решению. Исходя из подхода CMMi, например, очевидно, что правильная архитектура - это совокупность лучших практик (на сейчас) в части доступа к данным, их предоставления пользователю, ... поддерживаемость, расширяемость, минимальная избыточность...

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

Часто архитектурные проблемы - это проблемы заимствования типовых систем. Там все в куче, а реально используется из этого 5% функционала даже в очень больших системах, т.к. в у владельцев таких систем свое понимание бизнес-процессов, которое очень сильно отличается от понимания разработчиков типовых. И все ключевые элементы переработаны и дополнены основательно.
nekit_rdx; genayo; Il; acanta; zhichkin; +5 Ответить
26. пользователь 29.03.20 13:52
Сообщение было скрыто модератором.
...
29. suggestive 282 29.03.20 16:52 Сейчас в теме
Спасибо за кейс, интересный опыт! А вариант вести учет в одной базе рассматривали? Что за конфигурация, типовая или самописная?
40. max_st 310 30.03.20 09:41 Сейчас в теме
(29)По конфигурации ответил выше.
Вести учет в одной базе для нас уже не имеет особого смысла, текущая система работает.
Это дает нам возможности масштабирования - филиалы могут почти полноценно работать в своих базах.
Жесткие зависимости от центрального узла выявляем и пытаемся исправлять, но некоторые операции пока сильно завязаны на центральный узел.
43. roman72 382 30.03.20 13:11 Сейчас в теме
(40) Если несложно, можете озвучить список операций, сильно завязанных на центральный узел?
45. max_st 310 30.03.20 14:17 Сейчас в теме
(43)Не могу раскрыть эту информацию.
47. starik-2005 3051 30.03.20 18:12 Сейчас в теме
(43)
писок операций, сильно завязанных на центральный узел
То, что не может быть обработано обособленно. Система лояльности, заказы поставщикам, итоговая себестоимость, консолидированная отчетность. Те же ОСы, коих в таких компаниях миллионы. Заявки внутренние на АХО. Планирование затрат - аренда та же...
IlyaSR; genayo; +2 Ответить
49. _alex1974 15.04.20 13:51 Сейчас в теме
В свое время (15 лет назад) один из клиентов отказался от РИБ в пользу терминальной фермы (500+ пользователей УПП) и ему в принципе не пришлось решать озвученных здесь героических задач...
С масштабированием проблем еще меньше - подключение к терминалам из любого филиала (50-60 филиалов по РФ) не требует вообще ничего, кроме интернета, который сейчас есть в принципе везде. Плюс экономия на железе и обслуживании (два админа на всё)
Alexandr73Rus; handscenter; starik-2005; +3 Ответить
54. handscenter 60 06.10.20 12:46 Сейчас в теме
(49) это решение однозначно лучше РИБ, но и оно не идеально.
Оставьте свое сообщение