Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Мне кажется, что для описания общей схемы нужно также добавить синхронизацию данных.
Т.е. когда процесс перехода сильно растянут во времени может получиться ситуация, что часть данных заносятся в исторических источниках, а часть уже в новых. Точнее для средних и крупных систем так обязательно получится. В таком случае необходимо осуществлять синхронизацию данных для обеспечения беспрерывной работы системы.
(1) Именно. На мало-мальски серьезном проекте обмен необходим в обе стороны. Кто будет останавливать работающий бизнес ради какого-то там перехода?
(1)(2)
Коллеги, спасибо за комментарии
Да, в некоторых случаях после внедрения новой системы есть период, когда учет ведут и в старой системе и в новой. В таком случае обеспечивается синхронизация данных. И это, по сути, уже обычная интеграционная работа — регулярный автоматический или полуавтоматический обмен между системами.
Другое дело, что если миграция происходит с целого ряда систем на новую — то обеспечение такой невольной интеграции уже тянет на отдельный проект.
(3) Если есть ряд систем в начале не синхронизируемых между собой, то переход делается посистемно, сначала одну систему, потом вторую и опять же с синхронизацией. Временно (до окончательного перевода всех процессов) отключаем (или не включаем) в 1С контроль зависимостей одних данных от других.
Да: долго, дорого, муторно, жаба душит, но: дешевле простоя, а тем более риска из организованного хаоса создать неорганизованный бардак, в ходе которого многие активы компаний имеют свойство умножаться на ноль.
(4) да, согласны — такой вариант самый, пожалуй, надежный и сохраняет нервы крепче
добавлю, на мой личной практике была такая миграция, когда старая система так и осталась в строю, но для ограниченного круга лиц и уже, понятно, не для оперативной работы, а как архив прежде всего. Плюс, как некая тестовая база для отработки каких-то технических решений по соседним еще рабочим системам на аналогичной платформе.
По поводу простоя — если брать именно наши проекты, простоя никто из Заказчиков, конечно, не хочет. Да и возможности такой нет. Соответственно, стараемся провести по максимуму тестовых миграций, главных тестовых миграций, сверхглавных тестовых миграций и т.п. Также, стараемся подготовить и автоматизировать процесс так, чтобы финальная миграция ужалась до времени массовой автоматизированной заливки данных по нажатию на одну кнопку, грубо говоря. Поэтому, если всё готово заранее, сама заливка+тест занимают пару-тройку дней и сводится до рутинных нажатий на несколько кнопок.
В целом, вопрос параллельной работы в старых системах, всё же, решается Заказчиком, прежде всего. Если они готовы, IT-отделы старых систем готовы, бизнес готов, это у них стандартная практика — то почему бы и нет. Но нам, как исполнителям потенциально нужно быть готовым к единовременному переносу данных сразу — вот вам новогодние праздники, местные специалисты, дерзайте.
Не описан любимый процесс миграционщиков — проВэПээРить
(6) имеется ввиду функция ВПР в экселе?
Мы в данном случае эксель используем просто как таблицы некой промежуточной БД.
всю обработку и необходимую аналитику данных в этих таблицах выполняем запросами — там вполне себе полноценный SQL, и insert есть, и нормальное преобразование типов и т.п.
В принципе, можно сразу все эксели переливать в СУБД как есть и работать уже там. Такой ETL будет…. Чем мне не нравится такой вариант — эксель универсален и стоит у всех пользователей и все умеют с ним работать. Это крайне удобно и практично.
Фигня какая-то. Почему xls удобен? Не понятно. Если миграция из 1С в 1С, то удобнее всего конвертация данных, а значит xml. Если миграция из/в другие системы, то смотри, что за системы. Часто удобно бывает сделать промежуточную SQL базу, которая обеспечивает целостность данных.
Мне ни разу не приходилось мигрировать xls файлами. Потому что эксэль считает себя самым умным и иногда искажает данные.
(8) Трактор, полностью согласен — но в большинстве случаев не хватает квалификации у людей ваять SQl промежуточные базы, да и конвертации как огня боятся — потому и изгаляются выгрузками в файл: XLS, DBF, Txt
(8) xls удобен некой общей универсальностью — и как инструмент, и как транспорт данных
В экселе ведется мэппинг полей — прорабатываются и согласуются алгоритмы сопоставления. Этой работой занимаются специалисты Заказчика от бизнеса + аналитики Исполнителя. В экселе тут же ведутся всякие реестры и отчеты. То есть тут — рабочий инструмент.
Ну, и эксель достаточно удобен как средство хранения информации для обработки. Его можно открыть с любой машины, просмотреть. Специалист Заказчика может сам что-то проверить.
По поводу промежуточных SQL-баз — вариант хороший, не спорю. Такие примеры миграции также у нас в практике есть.
Но, в большой конторе для того, чтобы просто поднять чистую sql-базу может потребоваться писать служебки с кучей согласований, в том числе и служб ИБ.
Далее, остро встанет вопрос по поводу квалификации людей, которым нужно работать с этими данными.
Далее, встаёт вопрос _выгрузить_ из старых систем данные в эту новую sql-базу. Систем может быть десяток, на разных платформах — и MS SQL и Oracle, и те же эксели.
Зачастую, владельцы старых систем никак не заинтересованы в таких работах. Выгрузить 10 файлов эксель «как есть» — это просто. А вот работать для переливки в sql-базу…
С xml — примерно те же проблемы. Софт, квалификация, оперативность работы, доступность для работы
(9) абсолютно верно
ситуация 1 — миграцию делает 1-2 разработчика 1С. Тут можно хоть прямыми запросами из системы А в систему Б делать. Всё ограничивается только уровнем 1С-ников
ситуация 2 — систем два десятка. Только аналитика и мэппинг полей занимают полгода смежной командой Заказчик+Исполнитель — это и бухгалтеры, и экономисты, и прочие. Тестовых миграций и выверок еще на несколько месяцев. Общая длительность работ — больше года.
Понятно, что тут нужно что-то простое, понятное, всем доступное в любой момент. Чтобы Бухгалтер А мог четко и быстро отработать по телефону по файлу с Экономистом Б.
Добавлю, что, конечно, если Заказчик — серьёзное предприятие с бесконечно развитым IT-блоком, то там начинают использоваться уже промышленные ETL-системы
Например, по такой схеме
Но, понятно, что бюджеты подобных работ равно как и стоимость соответствующего софта очень нескромные.
Суть статьи правильная, на собственном опыте подтвержденная.
Но есть некоторые придирки к тексту. Хочется спросить автора, чем в его трактовке отличается «мэппинг» от «трансформации»?
> На основании согласованных реестров «мэппинга» полей специалисты Исполнителя разрабатывают правила трансформации данных.
ИМХО вы «запутались» в терминах.
Насколько я понимаю, Ваше «мэппинг» это и есть «правила отображения и трансформации» прикладных данных исторической системы в новую. А «специалисты исполнителя», в вашей цитате, реализовывают эти правила трансформации в программные (или иные) «механизмы трансформации».
Например, у нас в Крыму, при переходе из украинского учета в российский учет, бухгалтера выполняли «трансформацию» украинского БУ в российский, но «мэппинг» они не делали… :-))
Не стоит использовать американизмы там, где есть нормальные русские термины.
(13) спасибо за комментарий
мэппинг — это такой устоявшийся термин, но корнями не совсем из мира 1С, да..
смотрите ссылку на ETL в (12) или , к примеру
то есть это процесс сопоставления полей системы А и системы Б — обычно в виде каких правил, алгоритмов, возможно, кусков кода и т.п. Это аналитическая работа специалиста буквально ручками в экселе или в какой-то специальной программе.
а трансформация, конвертация — это просто процесс автоматизированного преобразования данных как раз по этим правилам
Плюсую за расширенную консоль.
Складывается ощущение, что такая схема синхронизации категорически не подходит для достаточно больших компаний, или для компаний, объем данных в исторических системах которых довольно большой.
Я боюсь себе даже представить сколько будет открываться excel с миллионами строк насыщенной колонками таблицы.
Ведь Вы выбрали excel именно потому что в нем удобно будет работать заказчику?
Страшно подумать, во что станет потом заказчику этот excel проверять/сводить/редактировать перед загрузкой в целевую систему.
На мой взгляд сильно проще описать достаточное количество внешних источников данных. И работать с ними в единообразной 1С-ной манере.
Чувствую, что в 97,5% случаев этого будет достаточно.
Исключением будут являться какие-нибудь поросшие мхом источники данных, подключиться к которым просто так нельзя.
(15)
Я боюсь себе даже представить сколько будет открываться excel с миллионами строк насыщенной колонками таблицы.
я думаю, да, в этом случае — уже next-level, переход на другой технологический уровень и использование других инструментов. Но общий принцип, в целом, такой же.
В целом, открывать миллионные эксели особой необходимости нет — активная работа с таким файлом ведётся на тестовом примере. Например, 100-1000 строк произвольных строк более-менее отражающих срез данных. Повторюсь, работа именно аналитическая, когда, скажем, бухгалтеры Заказчика сопоставляют поля этих экселей и поля таблиц новой системы- это вот как раз работа по мэппингу данных.
Составлен мэппинг, программист по этому мэппингу написал код трансформации — всё, можно конвертировать исходный файл. И только тут первый раз на сцену выходит миллионный файл.
Ну и потом, нужно смотреть, что за предметная область. Откуда миллион строк в таблицах. Если это проводки — то, возможно, достаточно будет ввода остатков и всё. Ну, а НСИ в таких размерах.. ))
Люди любят изобретать велосипеды и не любят изучать стандартные механизмы конвертации
(15)
Чувствую, что в 97,5% случаев этого будет достаточно.
Исключением будут являться какие-нибудь поросшие мхом источники данных, подключиться к которым просто так нельзя.
если есть возможность, да, конечно, можно поступить и так
но ситуация может складываться так что:
а) просто так никто к другой базе подключиться не даст. Только через служебки, согласования, пробросы портов, разрешения ИБ и прочее. Для каждой базы по отдельности. Плюс, если это рабочая база — то к ней в принципе могут не дать доступ никак. Только к какой-либо тестовой копии, которую чтобы поднять… см. выше
б) даже если доступ получен — мы можем увидеть оригинальные таблицы СУБД, которые, как и в 1С, могут слабо отражать бизнес-смысл. Соответственно, нужна дополнительная приличная аналитика по этим базам… Это время, ресурсы, бюджеты
Иными словами, нужен промежуточный формат такого плана, чтобы без проблем можно было в него выгрузить из старых баз данные (примеры данных) и без больших трудозатрат посадить бухгалтерш и 1С-консультантов разрабатывать алгоритмы переконвертации этих данных.
плюс, ещё бы консольку приложить…
(8) Трактор,
У меня был опыт миграции xls файлами со СБиСа (точнее csv, суть одна). XLS ничем не лучше и не хуже других форматов. Вопрос насколько специалистам, осуществляющим миграцию, проще работать с тем или иным форматах при переносе. Если, например, у вас уйдет 50 часов на написание правил для выгрузки/загрузки в XML и 10 часов на те же правила, но с использованием csv вы наверняка выберете csv.
(8) Трактор,
Потому что база-источник может быть построена на таких платформах/технологиях, что специалистам c «той» стороны дешевле, проще, удобнее выгрузить исходные данные в формат «который уже поддерживает наша система». Я участвовал в проекте, в котором максимум что могли дать с «той» стороны, это много-много файлов в формате *.txt. С учетом среднего объема файла в 1 Гб.
Как раз таки, если рассматривать только формат xls как источник данных, то вам не обязательно его открывать экселем. Читайте тем средством, которое вам доступно/нравится. Никаких «авто» преобразований в этом случае не будет. Более того, сам формат полей, также можно настроить. Но конечно, стоит на задачу смотреть контекстно. Например, если размер файла с данными начинает превышать гигабайтный размер, в случае с тем же txt, стандартный драйвер чтения такого файла, скорее всего просто завалится. В этом случае, как вариант, файл действительно есть смысл как-то загрузить в какую-то субд. Я в таких случаях использовал MS SQL, делал человеческие вьюшки к ним, и уже через ВИД, цеплялся к ним. В этом случае, никакие продвинутые консоли не нужны, достаточно обычной стандартной итс’овской, или вообще любой. Опять же почему я пришел к понимаю именно такой архитектуры. Смотрите, как правило, данные мигрируют из одной системы в другую. В источнике — там же не табличка, там база. И удобно именно через 1С по быстрому настроить все необходимые для работы связи между таблицами, настроить типы полей, чтобы из 1С это все работало в типах данных 1С и был доступен механизм «по ссылке». Таким образом у вас и интерфейс человеческий к источнику, и запросы со всеми плюшками разименования по ссылке на языке запросов 1С, опять к анализу можно подключить СКД, и отдать этот функционал человеку, «ни 1с’нику». При этом вы как бы в мире 1С, но в качестве источника у вас совершенно сторонняя система.
Надеюсь, дискуссия от моих 5 копеек не испортится 🙂
(21)
да, абсолютно аналогичная мысль пришла и нам — на стороне принимающей 1С-системы необходимо организовать такое рабочее место, чтобы источники уже были как-либо проинициализированы в «1С-нотацию», с переводом ключевых полей в ссылки и прочее. Технологически это могут быть и через ВИД, и прямые запросы к промежуточной СУБД, прямые запросы к xls и что-то другое.
Такое рабочее место позволяет оооочень быстро и эффективно буквально на лету изменять алгоритмы трансформации данных под новые обстоятельства.
Сколько умных слов, задействованных людей и написанных обработок. Все делается при помощи КД 2.0. От заказчика требуется только описание структуры базы.
Если между 1С 8.X, «На коленке», большие объемы, «Я не люблю КД»:
Источник: Запрос -> Таблица значений -> ЗначениеВФайл()
Приемник: ЗначениеИзФайла() -> Таблица значений.
А далее вариации:
1. Грузим «кодом» из таблицы значений
2. (Большой объем): «Кладем» таблицу значений и объект приемник в запрос, сравниваем их, на выходе получаем «Дельту, обновляем элементы объекта.
(11) видел в живую попытку ребят из Диалог ИТ через экселя провернуть перенос данных из овер 10 баз 7.7 в 1 на 8.х — и не увидел никаких преимуществ технологии.
Все равно лично вкорячил реквизиты синхронизации в нужные справочники, написал отчетов, которые проверяли заполнение этих реквизитов и сравнение справочников в разных базах через COM — потому что данных столько, что если человекам поручить в экселе все проверять — то так и на год подготовительных работ выйти можно))) Считаю предлагаемую технологию ущербной хотя бы в силу большей сложности написания автоматизированных проверок синхронизации данных во множестве «исторических систем» перед выгрузкой во внедряемую.