|
Хочу поделиться опытом переноса большого объема данных из конфигураций на базе 1С:7.7, и дать пару советов, которые помогут в разработке переноса. Для переноса между системами 1С почти всегда выбираю механизм конвертации данных (КД). Для меня он имеет ряд преимуществ перед другими технологиями:
Другому программисту легче понять, как работает перенос. В КД плохо структурировать элементы переноса. Тогда как в самописном переносе часто читаемость кода очень низкая, поскольку пишется на один раз. |
||
|
В последнем моем переносе была задача по получению данных партионного учета. Архитектура системы не позволяла получить остатки партий, и требовалось собирать эти данные, анализируя несколько регистров и документов. В случае использования типовых средств 1С 7.7 для этого потребовалось бы получение нескольких коллекций данных, их перебор и преобразование. На большом объеме такие алгоритмы работают очень медленно. За неимением альтернатив я вынужден был использовать внешнюю компоненту 1С++ (http://www.script-coding.com/1cpp.html). Она существенно расширяет язык 7.7, а для переноса добавляет возможность писать сложные запросы, что очень важно в данном случае. Фактически запросы пишутся на TSQL, а компонента позволяет оперировать именами метаданных, а не таблиц базы данных. С появлением TSQL запросов получение остатка партионного учета было выполнено одним запросом, занимающим 5 минут. За неимением альтернатив могу посоветовать использовать компоненту 1С++. |
||
|
В больших системах, таких как ERP, методы учета могут быть разнообразными, поэтому для клиента проводят моделирование его процессов, чтобы определить, как вести учет. Частью модели являются различные преднастроенные справочники, регистры, константы. Примеры таких настроек:
|
||
| Перенос данных может существенно поменяться с изменением модели учета, и, в идеале, разработка переноса должна начинаться после окончания этапа моделирования. Но на практике часто бывает, что приходится делать параллельно. Раньше я решал эту проблему эталонным начальным образом базы, в которую необходимо переносить данные. Но модели меняются, приходится не забывать о постоянной смене образа, при этом выгрузки базы с образами копятся, иногда забываешь развернуть образ или разворачиваешь не тот… В итоге решил все данные модели создавать программно, код по их созданию сделать частью переноса. То есть при загрузке данных в новую базу первым делом проверяется ее соответствие модели, и в новой базе создаются необходимые данные модели, для которых писался перенос. Может показаться, что это усложняет разработку, но судя по моей практике, получается легче. Раньше, когда меня просили срочно протестировать промежуточный этап переноса, я в спешке переносил данные, и через час обнаруживал, что забыл заполнить какой-нибудь классификатор перед загрузкой, и его значение не проставилось в номенклатуре. Теперь я уверен, что данные перенесутся корректно в пустую базу. Создавать все нужные элементы непосредственно в переносе – второй совет при разработке. | ||
|
Используя эти подходы за 2,5 месяца, параллельно с разработкой модели учета, был создан перенос данных для компании ООО «Эскорт-Центр» (http://www.escort-center.ru, крупная монтажная организация интегрированных систем безопасности крупных объектов: московское метро, военные и ядерные объекты). Была перенесена вся необходимая нормативно-справочная информация и остатки по следующим разделам учета:
Учет взаиморасчетов (в новой базе изменился разрез учета: был по договорам, стал детальнее – по заказам) |
||
| Есть вопросы – обращайтесь! | ||
|
Михаил Чернышев,
консультант-аналитик компании ООО “Кодерлайн” |
||
