Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена | Можно выполнить переход с УПП на БП 3 или запускать выгрузку данных за выбранный период времени | Переносятся документы, начальные остатки и вся справочная информация | Есть фильтр по организации и множество других параметров выгрузки | Поддерживается несколько сценариев работы: как первичный полный перенос, так и перенос только новых документов | Перенос данных возможен в "1С: Бухгалтерия 3.0" версии ПРОФ, КОРП или базовую | Переход с "1С: УПП1.3" / "1С:КА 1.1" на "1С:БП3.0" с помощью правил конвертации будет максимально комфортным! | Можно бесплатно проверить перенос на вашем сервере!
Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор
Перенос данных из ERP в БП 3 | из КА 2 в БП 3 | из УТ 11 в БП 3 | из ЕРП в БП 3 | Сэкономьте время - используйте готовое решение для перехода! | Перенос разработан в формате КД 2 (правила конвертации данных) | Переносятся все возможные виды документов, начальных остатков и нормативно-справочная информация| Можно опционально выгружать каждую пару "номенклатура+характеристика" как отдельную номенклатуру | Есть выгрузка настроек счетов учета и зарплатных данных из ERP / КА 2 | Можно проверить на вашем сервере перед покупкой
Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.
Можно проверить до покупки, оставьте заявку! Воспользовались более 268 компаний! Перенос данных из УТ 10.3 в УТ 11 | из УТ 10.3 в КА 2 | из УТ 10.3 в ERP. Решение для перехода с УТ 10.3. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам.
Переносите справочную информацию, остатки и документы из УПП 1.3 в Бухгалтерию 3.0 с помощью готовых правил. Переносится более 50 видов документов. Простой интерфейс и понятные настройки.
Перенос данных из ERP в ЗУП 3 | из КА 2 в ЗУП | Готовые правила конвертации данных (КД 2) для переноса остатков, документов с движениями и справочной информации 3 | Есть перенос начальной задолженности по зарплате и начальной штатной расстановки на выбранную дату | Обороты за прошлые годы (данные для расчета среднего) переносятся свернуто в документ "Перенос данных" | Есть фильтр по организациям | Документы за текущий период переносятся сразу с движениями, поэтому не потребуется делать перерасчеты | Перенос можно проверить перед покупкой, обращайтесь!
Обработка не только формирует начальные остатки по всем счетам на нужную дату (экономя время на свёртке базы БП 3), но и полностью переносит справочные данные и документы за заданный период. Гибкая настройка включает фильтр по организациям и множество параметров выгрузки. Работайте в удобном формате: выполните однократный полный переход или настройте регулярную догрузку только новых документов из БП 3 в БП 3.0. Интеграция правил конвертации в план обмена гарантирует точную выгрузку исключительно зарегистрированных объектов.
(1)Хорошо, давайте без аллегорий.
У вас есть ERP она должна выплюнуть остатки товара одним сообщением. Это сообщение, например в формате JSON.
Оно должно уйти:
1 На кассуX и кассуY, учитываем то, что на кассах стоит frotol, который как мы знаем работает с файлами csv и чаще всего через ftp.
2 В Postgres в определенные таблицы, с postgres сайт забирает данные.
3 Без трансформации сообщения улететь, например в 1с Бухгалтерию. В бухии уже есть код, который читает json.
4 Cохранить данные в RabbitMQ c которым работают мобильные устройства. Мобильные устройства содержат код, которые читают json.
Сможет так кафка без каких-то дополнительных средств это все сделать?
(5) Ну не работаю я с малым бизнесом...
Для мне это не экзотика, а варианты задач.
П.С. Человек попросил привести пример с функционалом 1С:Шины который Кафка не сможет, я его сгенерировал.
Могу еще посложнее сгенерировать, но тут как говорится подумать надо.
(6) Малый бизнес тут не при чем, чтобы получить такой ит ландшафт, надо очень сильно постараться :) И Шина не решит проблемы, она только добавит ещё один уровень проблем. Проверено на практике в сети из 6 тыс. розничных магазинов...
(10) Так оно так.
Как говорится не растет тот кто ничего не делает.
А так как мы часто делаем то чего не делали ранее, хочешь не хочешь, а расти приходится, в хорошем смысле этого слова.
Сможет так кафка без каких-то дополнительных средств это все сделать?
А в шине это одной галочкой включается? Давай говорить правду, в Шине придется все это или кодить, или мышкой накликивать, оно само ничего не заработает.
С таким же успехом поднимаешь микросервис (stateless в контейнере) и делаешь все то же самое: из одного топика читаешь - в другой отправляешь, или из кафки читаешь и в кролик отправляешь. Вот прямо классическая задача для микросервиса.
(33) Само по себе и Шина и Кафка не установится ))
Шина и затевалась как дирижер по управлению интеграциями.
Все инструменты для реализации внутри Шины есть.
(34) Вы отвечаете на какой-то другой вопрос, прямо как настоящий менеджер.
Насчет "все инструменты" это Вы преувеличиваете, ну например клиента к grpc-сервису сможете написать?
(36) У меня задачи такой не стояло. С другой стороны, до 4 версии шины и коннектора к kafke не было.
Продукт новый и он развивается. А все "хотелки" можно писать в 1С.
Люди хотели коннектор к kafke, он появился.
(3) сходу подумал - а что мешает в ERP регламентом создавать этот JSON и CSV одновременно, затем распихивать его по кассам, задуть в Postgre через внешние данные, ну и подложить бухгалтерии, всё это проконтролировать и если кто-то не ответил, то повторять до ус...чки
У меня появилось несколько вопросов, может сможете уточнить.
На сколько я понял - в рамках шины+КД, то шина выступает в качестве брокера?
Взаимодействие с 1С, я так понимаю, самый оптимальный вариант - это создание в 1С REST сервиса, через который и предлагается меняться данными - интерфейс oData видимо подходит для этих целей?
А вот писать трансформации в самой шине, для меня, пока выглядит тяжеловато. И есть ли более менее серьезные реализации обменов без КД с использованием шины?
У меня появилось несколько вопросов, может сможете уточнить.
На сколько я понял - в рамках шины+КД, то шина выступает в качестве брокера?
Да, но выглядит это максимально глупо. Дело в том, что КД имеет Узлы, каждый Узел создан под конкретный приемник. Соответственно, например номенклатура будет собираться на все узлы. И сообщения будут лететь в количестве равных количеству узлов.
Хотя по-хорошему должно быть одно сообщение с несколькими получателями. И инструменты — это реализовать без доработок в 1с есть.
Взаимодействие с 1С, я так понимаю, самый оптимальный вариант - это создание в 1С REST сервиса, через который и предлагается меняться данными - интерфейс oData видимо подходит для этих целей?
Ранее я тоже так считал, сейчас я пересмотрел свой взгляд. На счет oData… Она имеет ряд опасных моментов, например если через нее послать запрос без ограничения в регистр или справочник с кучей элементов, то система «вздрогнет», прям сильно «вздрогнет». Также мы не видим изменения, мы видим лишь текущее состояние запрашиваемых данных.
А вот писать трансформации в самой шине, для меня, пока выглядит тяжеловато.
Скажу честно. Для обмена между 1с-ками я не вижу смысла трансформации данных в шине.
И есть ли более менее серьезные реализации обменов без КД с использованием шины?
Я не знаю на сколько серьезна моя реализация )) Я делаю без КД. Про это я собираюсь рассказывать в следующих статьях ))
1 Для регистрации изменений я использую Историю данных и ее пост обработчик «ИсторияДанных.ВыполнитьОбработкуПослеЗаписиВерсий();». В итоге я имею три состояния. Добавление, изменение и Удаление.
В пост обработчике я использую обработку от Артёма Кузнецова ее пришлось немного подшаманить. Ее результат сохраняю в JSON и формирую сообщения сервисов интеграции указывая получателей.
2 На стороне получателей уже читаю данные. Если какие-то данные не находятся, тогда запрашиваю полную версию в базу источник и сохраняю прочитанное не до конца сообщения. Когда все данные прилетают, считываю сообщение еще раз.
Пока все в полуавтомате, но понемногу улучшаю обмен.
1. Почему глупо, скорее тяжело, может не рационально. К тому, же КД 3 как раз и решают задачу приведения данных к общему бизнес формату (или должны решать), т.е. как раз обновление везде номенклатуры из MDM системы самое то.
2. Думаю, что нормальная практика для обмена данными, между двумя конкретными узлами. А широковещательные сообщения более присуще push сервисам.
Скажу честно. Для обмена между 1с-ками я не вижу смысла трансформации данных в шине.
1. Пока из всего оставшегося 1с:шина выглядит как обычный менеджер сообщений + может вытягивать данные.
2. Еще конечно хороший плюс - это общая структура маршрутизации в одном месте (можно сказать из коробки). Когда обменов много и они разные, то тут без такой штуки тяжело приходится.
3. Если не нужны правила поиска (много ли у кого стоят MDM системы?), преобразование данных, например, из заказа клиента в счет на оплату, то наверное можно обойтись без всего этого. Хотя при обмене между разными конфигурациями, какое-то преобразование все равно понадобится. В случае КД - оно брало на себя эту задачу, не очень удобно, зато в одном месте. То в случае 1С:Шины логично было бы возложить на нее эту обязанность. Как вы и где преобразуете данные? Или нет такой необходимости?
(8)
Шина нужна для единого центра управления потоками информации. У нас свой продукт в роли шины. Вот у него внутри зашито xdto для всех видов данных. Маршруты, условия маршрутизации. Там же выгрузка в csv для внешних систем. В основе лежит Бит.Адаптер. И соответственно есть единство подхода во всех системах. Т.е. вот есть пакет с физлицом, он из зуп выгружается и дальше в этом одинаковом для всех виде летит по кролику в десяток узлов. Транспорт не принципиален, но у кролика есть маршрутизация по заголовкам, что позволяет красиво управлять маршрутами.
По шине пока непонятно как они сделают код, который пишется внутри нее, поддерживаемым, управляемым и прозрачным. Т.е. сколько дней мне надо будет потратить, чтобы поменять какой-то там маршрут или конвертацию, которые кодом регулируются.
А если у меня Apache Proton в стэке, а не кролик и кафка? За каким коннектором AMPQ спрятали?
Если кому хочется оценить зачем нужна шина и чего от нее ждать, то вот отсюда можно начать
Ждёмс продолжения цикла.
И отдельный вопрос на сейчас:
Хотелось бы увидеть изложение конкретного технологического преимущества шины как технологии перед брокерами сообщений. Т.е. что может только шина, но не могут кролик и кафка.
Есть ещё один вопрос.
Вот такой момент - как шина увязывается с бешовной интеграцией 1С (это у них отдельная технология и у неё много преимуществ).
Как принимаете решение гнать объект через шину или через бесшовку, по каким критериям?
(21) Бесшовная объявлена для "любой" конфигурации, для любой пары конфигураций.
Да, с ЕРП часто бесшовку используют. Но она не только для ЕРП работает.
(20)
Это не на мой вопрос ответ. Ответ там про частный случай и функционал технологии.
А я спросил про принципиальные отличия технологии.
То что кафке может что-то понадобиться допилить, так и шине допиливать придётся и приходится.
(22)Шине не надо допилить то что понадобится допилить кафке.
Шина может маршрутизировать, трансвормировать и коннектится к разным приёмником и источникам в том числе и кафке. Соответственно если Шине понадобится функционал кафки она к ней конектится и все.
(26)принаять данеые в xml или json сконвертировать в формат csv подключится по ftp и выкинуть файл могут?
И могут получить данные и выплеснуть в sqlмогут.
Или они все таки получают данные и отдают тем кто у них запрашивает?
В статье есть картинка вся шина концептуально, помоему наглядно.
Еще не так давно я не видел какой-то практической ценности в сервере взаимодействия, но сейчас этот продукт стал значительно функциональнее и многие начинают использовать его из-за своей тесной интеграции с 1С.
Так же будет и с шиной. Сейчас сложно сказать, зачем она нужна, ведь есть конкуренты, но пройдет время, появится много кейсов, расширится и упростится функционал, появится много обучающий материалов (в том числе и от меня). И тогда, из-за тесной и удобной интеграции многие начнут выбирать именно ее.