Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Добрый день. Мне вот интересно сколько РАЗНЫХ систем кому приходилось объединять в единое информационное поле с автоматической перекачкой\перекодировкой\преобразовыванием данных? Тоесть если перечислить все программки с данными, что есть в компании между которыми чтото-кудато переливается то сколько получится? (пример: 3 банк клиента, 4 1С-ов в разных отделах+складская программа и все это помножить на 5 филиалов). Одинаковый 1С с едиными справочниками в двух магазинах это одинаковые системы. Одинаковый 1С с разными справочниками в двух магазинах это разные системы, т.к. необходим процесс сопоставления кодов. Причем я не говорю об организации хранилища данных, куда отовсюду сливаются данные, а именно об обмене, чтоб данные ходили в обе стороны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2006, 14:01 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvМне вот интересно сколько РАЗНЫХ систем кому приходилось объединять в единое информационное поле с автоматической перекачкой\перекодировкой\преобразовыванием данных?А с какой точки зрения вопрос? Мы вот, к примеру объединяли ~7-9 географически распределенных систем, но там был упор на следующий уровень обмена: "я тебе запрос, ты мне данные дай или транзакцию сбацай". Все работает, все в он-лайне, но "единого" поля как такового - нет. Каждому свое, в силу специфик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.11.2006, 16:25 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
не приходилось, но видел как было сделано при websphare на в одной компании. там работаю как мин 3 erp системы на разных предприятиях ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 00:49 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Судя по всему, речь идет о применении технологии EAI, которая применяется при необходимости интеграции большого числа разнообразных приложений, данных в различных форматах и т.д. и т.п. В таких случаях вместо десятков интеграционных связей между конкретными приложениями и базами данных используют специальный сервер интеграции. При этом количество связей, требующих перенастройки в случае если где-то что-то изменилось, минимально (вместо паутины связей - "звезда"). А перенастройка осуществляется достаточно легко и только в одном месте - на сервере интеграции. ПО такого класса IBM Websphere или MS BizTalk Server. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 09:30 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Гостььне приходилось, но видел как было сделано при websphare на в одной компании. там работаю как мин 3 erp системы на разных предприятиях А вот здесь можно поподробнее? Что за компании? Какой из продуктов WebSphere использовался (их там мульен и какой что делает нифига не понятно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 10:02 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
asdfghjklА с какой точки зрения вопрос? Да вот бодаюсь тут с зоопарком из 15 систем с частично пересекающимися справочниками. Пытаюсь паутину распутать, чтоб потом можно было одну за другой такие системы прибивать и прочие не почуствовали этого. Интересуют в принципе общие подходы к таким задачам. asdfghjklМы вот, к примеру объединяли ~7-9 географически распределенных систем, но там был упор на следующий уровень обмена: "я тебе запрос, ты мне данные дай или транзакцию сбацай". Все работает, все в он-лайне, но "единого" поля как такового - нет. Каждому свое, в силу специфик. А это при помощи чего реализовывали? По мылу файлами бросались или еще как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 10:17 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv Сложные задачи не решаются простыми методами. 1. Необходимо макс. интегрировать данные в единую БД (это сложно, но эффект большой). 2. При территориальной распределенности применять либо онлайн либо репликацию в зависимости от специфики) Успехов на ниве интеграции. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 10:30 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvДа вот бодаюсь тут с зоопарком из 15 систем с частично пересекающимися справочниками. Если можно дайте побольше входящей информации. "15 систем" это последствия лоскутной автоматизации или географически разделённые предприятия? В первом случае я бы юзал MicroSoft BizTalk. Дешево(по сравнению с IBM) и сердито. Доки на их же сайт... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 10:54 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvМне вот интересно сколько РАЗНЫХ систем кому приходилось объединять в единое информационное поле с автоматической перекачкой\перекодировкой\преобразовыванием данных? 98% проектов таких. А что интересует конткретно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 10:58 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
velfimov IgorTvДа вот бодаюсь тут с зоопарком из 15 систем с частично пересекающимися справочниками. Если можно дайте побольше входящей информации. "15 систем" это последствия лоскутной автоматизации или географически разделённые предприятия? В первом случае я бы юзал MicroSoft BizTalk. Дешево(по сравнению с IBM) и сердито. Доки на их же сайт... Был программист. Писал много и не связанно. Вернее все что нужно посвязывал и уволился. Теперь все смотрят на это и разводят руками - не понятно что с ним делать. Решили менять на новое одно большое, но выключать чтото одно из зоопрака нельзя - много связей. Тут и параллельное развитие нескольких бизнесов, так и география виновата. На BizTalk я смотрел. Презентующие люди сами признались, что продукт сыроват и нам лучше подождать еще с годик а потом чтото на нем рисовать. А по ценам вы не правы. Бизтолк стоит около 20 штук и у IBM тоже есть решение за 20 ( хотя есть и за 120 и за 6 нужно просто внимательно прайслист читать :) ) Еще что мне не понравилось в Бизтолке - так это отсутствие методологии. Вот вам конструктор - решайте свои задачи. У IBM с этим получше - есть методология - и продукт под нее заточен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 11:40 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvДа вот бодаюсь тут с зоопарком из 15 систем с частично пересекающимися справочниками. Пытаюсь паутину распутать, чтоб потом можно было одну за другой такие системы прибивать и прочие не почуствовали этого. Интересуют в принципе общие подходы к таким задачам. Общие подходы - в первую очередь организационные, а тут все очень от конкретного проекта зависит. Универсальных рекомендаций не дашь. А! Одна есть - ввод данных руками должен быть ОДНОКРАТНЫМ! :-) IgorTvА это при помощи чего реализовывали? По мылу файлами бросались или еще как?Вот еще. Никакого файлового обмена, я ж говорю - он-лайн доступ. Были примеры на Oracle BPEL, были свои поделки. Коллеги тут BizTalk и WebSphere упоминают - тож вариант, наверное, мы с ними пока не работали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 11:41 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
iscrafm IgorTvМне вот интересно сколько РАЗНЫХ систем кому приходилось объединять в единое информационное поле с автоматической перекачкой\перекодировкой\преобразовыванием данных? 98% проектов таких. А что интересует конткретно? Конкретно - элементарный вопрос- синхронизация справочников :) Перписывать все системы на единую кодировку нельзя. Как решать вопрос, что товар заводится в одной системе с кодом 10 его нужно создать в другой системе где ей присвоится свой код 123. где и как сохранять эти ссылки что 10=123. Ну тут еще много приколов над которыми стоит поломать голову :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 11:46 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvНа BizTalk я смотрел. Презентующие люди сами признались, что продукт сыроват и нам лучше подождать еще с годик а потом чтото на нем рисовать. А по ценам вы не правы. Бизтолк стоит около 20 штук и у IBM тоже есть решение за 20 ( хотя есть и за 120 и за 6 нужно просто внимательно прайслист читать :) ) Еще что мне не понравилось в Бизтолке - так это отсутствие методологии. Вот вам конструктор - решайте свои задачи. У IBM с этим получше - есть методология - и продукт под нее заточен. Бизтолк стандарт дешевле 20тыс стоит. И методологию можно найти. Стоп, ещё прогонят с форума за рекламу. Мне всё равно что у Вас будет работать ;-) Покупайте то, что функциональней. Желаю удачи ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 11:55 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvКонкретно - элементарный вопрос- синхронизация справочников :) Перписывать все системы на единую кодировку нельзя. Как решать вопрос, что товар заводится в одной системе с кодом 10 его нужно создать в другой системе где ей присвоится свой код 123. где и как сохранять эти ссылки что 10=123. Мы всегда делаем центральное хранилище. Правда все системы на единую кодировку все же переводим. Если кодировка разная (например планы счетов), то используются таблицы трансформации. Они и процедуры их обработки - в центральном хранилище ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 12:29 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvБизтолк стоит около 20 штукStandart Edition по лицензии OLP без скидок на 1 процессор по прайсу Софтлайн чуть менее года назад стоила 7 120,75$. Для интеграции 15 приложений вплоне достаточно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 13:23 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Garya IgorTvБизтолк стоит около 20 штукStandart Edition по лицензии OLP без скидок на 1 процессор по прайсу Софтлайн чуть менее года назад стоила 7 120,75$. Для интеграции 15 приложений вплоне достаточно. Проблема в том, что он сам по себе работать не будет. К нему еще много всякого докупить нужно :( По крайней мере когда нам предложение делали, то общее решение по софту стоило около 20тыщ или даже больше, я уже не помню. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 13:29 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
iscrafm Мы всегда делаем центральное хранилище. Правда все системы на единую кодировку все же переводим. Если кодировка разная (например планы счетов), то используются таблицы трансформации. Они и процедуры их обработки - в центральном хранилище Класно когда есть возможность взять все и переписать нах. А когда справочники разные по струтуре и наполнению, когда создание справочников в разных системах происходит асинхронно а обмен между системами выполнять нужно и таблицы трансформации должны заполняться автоматичесик иначе - бардак. Как такие задачи рашались? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 13:34 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvПроблема в том, что он сам по себе работать не будет. К нему еще много всякого докупить нужно :(MS SQL Server Standart Edition ~6'700$. Больше ничего докупать не нужно. Всё остальное делается руками. Около 20'000$ стоит Enterprise Edition со всеми прибамбасами (вроде специально разработанных адаптеров для SAP, которые, насколько я понимаю, Вам просто не нужны). Для Вас - это как пушка для стрельбы по воробьям. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 14:03 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv iscrafm Мы всегда делаем центральное хранилище. Правда все системы на единую кодировку все же переводим. Если кодировка разная (например планы счетов), то используются таблицы трансформации. Они и процедуры их обработки - в центральном хранилище Класно когда есть возможность взять все и переписать нах. А когда справочники разные по струтуре и наполнению, когда создание справочников в разных системах происходит асинхронно а обмен между системами выполнять нужно и таблицы трансформации должны заполняться автоматичесик иначе - бардак. Как такие задачи рашались? С автоматическим наполнением проблемы, приходится договариваться о кодировках, иначе бардак получается ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 14:06 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv 1. А когда справочники разные по струтуре и наполнению, 2. когда создание справочников в разных системах происходит асинхронно 3. и таблицы трансформации должны заполняться автоматически Как такие задачи рашались? 1 View 2 синхронизировать 3 перекодировать на единую кодировку и см. п.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.11.2006, 15:22 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv Гостььне приходилось, но видел как было сделано при websphare на в одной компании. там работаю как мин 3 erp системы на разных предприятиях А вот здесь можно поподробнее? Что за компании? Какой из продуктов WebSphere использовался (их там мульен и какой что делает нифига не понятно) Честно не знаю, как продукт используется из сферы. тут я полный фуфел. Контора капиталистическая имеет несколько заводов по миру. с разными системами. смотрели как в московском представительстве реализовано. но везде работают разные системы в это 100% уверенность. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 02:12 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Господа ну можно интеграция сделать и на SAP`овских приблудах и на Oracle`левых. Ну правда денег это стоить будет от 200000 евро мин ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 02:16 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
ГостььГоспода ну можно интеграция сделать и на SAP`овских приблудах и на Oracle`левых. Ну правда денег это стоить будет от 200000 евро минНу про SAP спорить не буду, а вот Oracle - гора-а-аздо дешевле, где-то на порядок примерно. А свои приблуды приделать - так вообще копейки. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2006, 04:41 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
asdfghjkl ГостььГоспода ну можно интеграция сделать и на SAP`овских приблудах и на Oracle`левых. Ну правда денег это стоить будет от 200000 евро минНу про SAP спорить не буду, а вот Oracle - гора-а-аздо дешевле, где-то на порядок примерно. А свои приблуды приделать - так вообще копейки. :-) Ну не факт что оракл будет на много дешевле. Возьмём на пример netweaver & Middleware(вот тут могу ошибаться в название продукта) разница в проектах будет с одинаковыми условиями ну мах 5%. + еще возьмем что оба продукта достаточно сыровата. Короче один геморой делать интеграцию. Я думаю что самый на мой взгляд оптимальный способ собирать данные в хранилище и там их уже обрабатывать. Но вот тут как обратно их загонять в системы ..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 01:04 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
ГостььНу не факт что оракл будет на много дешевле. Возьмём на пример netweaver & Middleware(вот тут могу ошибаться в название продукта) разница в проектах будет с одинаковыми условиями ну мах 5%. + еще возьмем что оба продукта достаточно сыровата.Будет, будет. Запуск саповского XI - цифра далеко за 100000. Оракловый BPEL вроде около ~30к$ стоит. Свой самопал - ~3к$. :-) Прачуствуйте разницу. Так шо все - от целей. Лично я деньги клиенту стараюсь экономить. :-) А насчет сырости - ну мы ж с вами, коллега, типа профессионалы и все такое. И на всех этих продуктах вполне можно работать, при всем моем подозрительном отношении к мострам типа XI и творческим поискам от оракла. Гостьь Короче один геморой делать интеграцию. Я думаю что самый на мой взгляд оптимальный способ собирать данные в хранилище и там их уже обрабатывать. Но вот тут как обратно их загонять в системы .....Тут такое дело, вроде как принято запихивать данные в хранилище. А вот выпихивать - не принято. Ни разу. И вообще - "хранилище" и "интеграция" это "два разных человека". Про гемор - отчасти правда, но ведь и задачка непростая. Есть где мысли развернуться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 05:03 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
asdfghjklТут такое дело, вроде как принято запихивать данные в хранилище. А вот выпихивать - не принято. Ни разу. И вообще - "хранилище" и "интеграция" это "два разных человека". Про гемор - отчасти правда, но ведь и задачка непростая. Есть где мысли развернуться. Абсалютно согласен. Так вот собственно вопрос: Кто как решал проблему синхронизации справочников типа в одно системе создали товар в системе А с кодом 10 запихнули в другую систему В этот товар там присвоился код 123 и теперь нужно автоматиечески запомнить что А.10=В.123 и потом, кодга мы будем продажами между системами бросаться, то перекодировать налету. Кто-то решал такие проблемы и как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 10:12 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvТак вот собственно вопрос: Кто как решал проблему синхронизации справочников типа в одно системе создали товар в системе А с кодом 10 запихнули в другую систему В этот товар там присвоился код 123 и теперь нужно автоматиечески запомнить что А.10=В.123 и потом, кодга мы будем продажами между системами бросаться, то перекодировать налету. Кто-то решал такие проблемы и как?Вот например: в системе А выполняется "бизнес-функция" "Создание материала". По факту удачного завершения запускается "интеграционный процесс", инициирующий передачу нужных данных и выполнение "бизнес-функции" "Создание материала" в системе Б. По завершению функция возвращает свои данные. На выходе - в двух системах синхронно создается материал и есть инфа о том, какой номер ему соответствует во второй. Скукота. :-) Сложность реализации зависит только от самих систем, в общем-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 10:43 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvКто как решал проблему синхронизации справочников Не надо их "синхронизировать", надо сделать один справочник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 12:51 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
мод IgorTvКто как решал проблему синхронизации справочников Не надо их "синхронизировать", надо сделать один справочник.Это далеко не всегда можно сделать. Если используетс одновременно несколько разных покупных программных продуктов, решающих разные задачи и в своем составе имеющее жестко "зашитый", например, справочник контрагентов, то не получится его иметь один. Придется именно "синхронизировать". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 12:57 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
asdfghjkl IgorTvТак вот собственно вопрос: Кто как решал проблему синхронизации справочников типа в одно системе создали товар в системе А с кодом 10 запихнули в другую систему В этот товар там присвоился код 123 и теперь нужно автоматиечески запомнить что А.10=В.123 и потом, кодга мы будем продажами между системами бросаться, то перекодировать налету. Кто-то решал такие проблемы и как?Вот например: в системе А выполняется "бизнес-функция" "Создание материала". По факту удачного завершения запускается "интеграционный процесс", инициирующий передачу нужных данных и выполнение "бизнес-функции" "Создание материала" в системе Б. По завершению функция возвращает свои данные. На выходе - в двух системах синхронно создается материал и есть инфа о том, какой номер ему соответствует во второй. Скукота. :-) А если в системе Б операция прошла не успешно то что?Из А тоже удалять товар? А если у меня таких систем 10 то что? Если в одной из них не получилось создать товар? И еще тут ключевое слово - синхронно. А если в системе Б функция "Создание номенклатуры " запускается кнопочкой, которую человек иногда нажимает. И из системы А мы сразуже после создания номенклатуры передаем и продажу, в которой эта номенклатура есть. Так что мне в систему Б передавать если там товар еще не создался? Лично мне не скучно ниразу :) Ну а структура справочников типа в А 1 товар а в Б это несколько товаров вообще отдельная песня. И причем в Б это не будли одного и тогоже, это разные сущьности ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 13:32 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
мод IgorTvКто как решал проблему синхронизации справочников Не надо их "синхронизировать", надо сделать один справочник. Понятно что надо. Но ввести единую кодировку= переписать и одновременно запустить 10 РАЗНЫХ систем учета в компании, где час простоя стоит немерянных денег. Это невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 13:35 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv asdfghjklТут такое дело, вроде как принято запихивать данные в хранилище. А вот выпихивать - не принято. Ни разу. И вообще - "хранилище" и "интеграция" это "два разных человека". Про гемор - отчасти правда, но ведь и задачка непростая. Есть где мысли развернуться. Абсалютно согласен. Так вот собственно вопрос: Кто как решал проблему синхронизации справочников типа в одно системе создали товар в системе А с кодом 10 запихнули в другую систему В этот товар там присвоился код 123 и теперь нужно автоматиечески запомнить что А.10=В.123 и потом, кодга мы будем продажами между системами бросаться, то перекодировать налету. Кто-то решал такие проблемы и как? Решается промежуточными таблицами.Но на первом этапе нужна ручная синхронизация справочников, после чего у каждого филиала товар живет под своим кодом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 13:48 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
sergey888 Решается промежуточными таблицами.Но на первом этапе нужна ручная синхронизация справочников, после чего у каждого филиала товар живет под своим кодом. А добавлять\изменять товары потом как? Снова ручками? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 13:52 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
GaryaЭто далеко не всегда можно сделать. Конечно не всегда, но надо стараться. Если это SQL, то view рулят. Ведь любая программа работает с таблицами своей БД - таблицы можно подменить на view. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 15:27 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv если в системе Б функция "Создание номенклатуры " запускается кнопочкой, которую человек иногда нажимает. И из системы А мы сразуже после создания номенклатуры передаем и продажу, в которой эта номенклатура есть. Так что мне в систему Б передавать если там товар еще не создался?Вы рассматриваете создание новой номенклатуры, как функцию, запускаемую кнопочкой. Но ведь решение нажать эту кнопочку возникает не стихийно? Этому решению предшествует довольно длительная работа. Это лишь один малю-ю-юсенький шажок в процессе, который начинается в момент возникновения потребности в товаре (а иногда и намного раньше). Если рассматривать создание новой номенклатуры как шаг процесса, то можно, используя композитные приложения, организовать одновременное обращение к разным хранилищам, причем не только на "вталкивание", но и на "доставание" данных. Вы можете организовать обращение к разным базам данных в одной экранной форме. Сейчас так много говорят о системах управления бизнес-процессами, но часто присутствуют такие крайние мнения, как: - всего лишь новая рисовалка - еще одна разновидность систем документооборота - подмена BPEL, как интеграционного инструмента - ... Но, говоря языком известного персонажа, "Кавказ - это и здравница, и кузница...". BPM-системы как раз и отличеются от каждого пункта в отдельности тем, что сочетают в себе одновременно все эти пункты. Причем, наличие их является ОБЯЗАТЕЛЬНЫМ УСЛОВИЕМ для принятия продукта в разряд BPMS. И интеграция - это действительный "конек" этого ПО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 15:28 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv Но ввести единую кодировку= переписать и одновременно запустить 10 РАЗНЫХ систем Не понял, а зачем переписывать ? Единомоментная перекодировка вполне возможна даже на работающей системе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 15:30 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv sergey888 Решается промежуточными таблицами.Но на первом этапе нужна ручная синхронизация справочников, после чего у каждого филиала товар живет под своим кодом. А добавлять\изменять товары потом как? Снова ручками? Редактировать товар можете кроме ИД, т.к. с головным справочником товары связаны по ИД. А перед добавлением нового товара надо запускать процедуру поиска аналогичных позиций. Если позиции в головном справочнике нет, то заводите новый товар со своим ИД, затем при репликации товар добавляется в головной справочник и автоматически добавляется запись в промежуточную таблицу, связывая ваш ИД и ИД головного справочника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 16:02 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
мод GaryaЭто далеко не всегда можно сделать. Конечно не всегда, но надо стараться. Если это SQL, то view рулят. Ведь любая программа работает с таблицами своей БД - таблицы можно подменить на view.В одних случаях это надо делать, в других - нет. А что будет с VIEW при попытке наложения новой версии, в которой запускается скрипт ALTER TABLE - той самой TABLE, которую мы ранее заменили на VIEW? Будет большая проблема при попытке обновления версии, вот что будет. Опять же, что делать, если справочник - это не одна таблица, а множество, и в этих таблицах содержится не только содержимое синхронизируемого справочника, но и многих других? В общем, ПМСМ, подходить нужно взвешенно. Когда приложений 2-3-4, может быть, VIEW - это и лучший способ. Когда их 20-30-40, тут уже как ни старайся, можешь себе лишь навредить. При большом количестве приложений необходимо использовать сервер интеграции. Потому что если городить между приложениями прямые связи, то их получится большая и громоздкая паутина, которая будет выходить из строя при смене версии хотя бы одного из нескольких десятков приложений. В таком случае уже важнее нацеленность на безболезненную модификацию, смену версий, форматов и т.п., нежели на возможность работы с едиными источниками информации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 16:19 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
GaryaВ общем, ПМСМ, подходить нужно взвешенно. Когда их 20-30-40, тут уже как ни старайся, можешь себе лишь навредить. Конечно согласен. Правда, если у вас 40 приложений, то пора подумать о том, как сделать из них хотя бы 10 :). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 16:31 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
модесли у вас 40 приложений, то пора подумать о том, как сделать из них хотя бы 10 :).У нас на одном из заводов только 8 РАЗНЫХ систем клиент-банк для связи с РАЗНЫМИ банками. Так что чтобы осталось только десять, остальных приложений должно быть не более двух... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 16:46 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Garya модесли у вас 40 приложений, то пора подумать о том, как сделать из них хотя бы 10 :).У нас на одном из заводов только 8 РАЗНЫХ систем клиент-банк для связи с РАЗНЫМИ банками. Так что чтобы осталось только десять, остальных приложений должно быть не более двух... :):-) Или банков... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 17:11 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
> У нас на одном из заводов только 8 РАЗНЫХ систем клиент-банк > для связи с РАЗНЫМИ банками. Типа по каждому договору заинтересованное лицо получило немножко преференций? А чего только восемь? В стране банков, если память мне не изменяет, порядка полутора тысяч (лень искать точную цифру, извините). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.11.2006, 20:43 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
GaryaУ нас на одном из заводов только 8 РАЗНЫХ систем клиент-банк для связи с РАЗНЫМИ банками. Это периферия, она не в счет. Все равно все 8 связаны с одной центральной бухгалтерией (на 1С ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 09:47 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
После того как объединяешь 2 системы дальше уже все просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 13:18 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
gybsonПосле того как объединяешь 2 системы дальше уже все просто. Вообщем, да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.11.2006, 14:39 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv asdfghjklТут такое дело, вроде как принято запихивать данные в хранилище. А вот выпихивать - не принято. Ни разу. И вообще - "хранилище" и "интеграция" это "два разных человека". Про гемор - отчасти правда, но ведь и задачка непростая. Есть где мысли развернуться. Абсалютно согласен. Так вот собственно вопрос: Кто как решал проблему синхронизации справочников типа в одно системе создали товар в системе А с кодом 10 запихнули в другую систему В этот товар там присвоился код 123 и теперь нужно автоматиечески запомнить что А.10=В.123 и потом, кодга мы будем продажами между системами бросаться, то перекодировать налету. Кто-то решал такие проблемы и как? На самом деле тут вопрос решается в комплексе и для того что бы выполнять задачу по присвоению А.10=В.123 не нужен BMP. Это делается на более низком уровне. Такого рода задача для ESB (Enterprise Service Bus) - это трансформация некого сообщения. А тут WebSphere на ура пойдет (начиная с Express), потому как SIBus в любом сервере присутствует (и дополнительных денег не стоит) - а это то на чем реализуется ESB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 17:34 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
GavrilovD уточню. Для этого даже WebSphere не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 18:37 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
iscrafm GavrilovD уточню. Для этого даже WebSphere не нужен.Угу. Только кто-ж тогда покупать все это будет? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 19:00 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
GavrilovDНа самом деле тут вопрос решается в комплексе и для того что бы выполнять задачу по присвоению А.10=В.123 не нужен BMP. Это делается на более низком уровне. Такого рода задача для ESB (Enterprise Service Bus) - это трансформация некого сообщения. А тут WebSphere на ура пойдет (начиная с Express), потому как SIBus в любом сервере присутствует (и дополнительных денег не стоит) - а это то на чем реализуется ESB. Программить можно где угодно. Среда разработки не важна. Интересует решал кто-то такие задачи или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 19:18 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvПрограммить можно где угодно. Среда разработки не важна. Интересует решал кто-то такие задачи или нет?Ну писали-же выше разные варианты. Понятно, в обобщенном виде, а как еще? Не зная конкретики бОльшего и не посоветуешь. А вникать детально - как правило приличное время и уж всяко деньги. Постановка концепции ведения, скажем, гетерогенного номенклатора материалов - нормальная и серьезная работа. Вы уж определитесь - самим выдумывать или нанять кого. А месяцами чесать репу и ждать готового решения на блюдечке - непродуктивно. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 20:09 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Вставлю. По-моему тут вопрос не в том "чем", а в том, "что и как". т.е. не в инструменте дело, а в том: 1) Справочники. Нужно ли централизованное управление справочниками или достаточно распределенных точек возникновения объектов и их общее хранение с играми видимостью. 2) Документы. Видимость и права. Дальше дело техники, кривизны рук и методов реализации красивых концепций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 18:40 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
asdfghjkl IgorTvПрограммить можно где угодно. Среда разработки не важна. Интересует решал кто-то такие задачи или нет?Ну писали-же выше разные варианты. Понятно, в обобщенном виде, а как еще? Не зная конкретики бОльшего и не посоветуешь. А вникать детально - как правило приличное время и уж всяко деньги. Постановка концепции ведения, скажем, гетерогенного номенклатора материалов - нормальная и серьезная работа. Вы уж определитесь - самим выдумывать или нанять кого. А месяцами чесать репу и ждать готового решения на блюдечке - непродуктивно. :-) +1 поддерживаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 18:41 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Валентин К По-моему тут вопрос не в том "чем", а в том, "что и как". т.е. не в инструменте дело, а в том: 1) Справочники. Нужно ли централизованное управление справочниками или достаточно распределенных точек возникновения объектов и их общее хранение с играми видимостью. Вопрос был: кто как решал задачи автоматического создания таблиц соответствия если единого справочника нет и не может быть в силу разрозненности архитектур систем. Валентин К 2) Документы. Видимость и права. Дальше дело техники, кривизны рук и методов реализации красивых концепций. Собственно про технику, а точнее про технологию решения подобных вопросов и хотелось услышать. Не об инструментарии, а о том как кто это решал, если решал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 18:51 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv Валентин К По-моему тут вопрос не в том "чем", а в том, "что и как". т.е. не в инструменте дело, а в том: 1) Справочники. Нужно ли централизованное управление справочниками или достаточно распределенных точек возникновения объектов и их общее хранение с играми видимостью. Вопрос был: кто как решал задачи автоматического создания таблиц соответствия если единого справочника нет и не может быть в силу разрозненности архитектур систем. При чем тут разрозненность архитектур систем? у вас в системах у контрагента нет кодов ОКПО? или в справочнике товаров нет наименований? "кто как решал задачи автоматического создания таблиц соответствия" это вообще некорректно - ответ на вопрос - SQL-запросами. Второй ответ а зачем их автоматически создавать, это подразумевает их автоматическое уничтожение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 19:00 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTvне может быть в силу разрозненности архитектур систем. Надо строить гетерогенные интегрированные системы, а не наступать каждый раз на одни и те же грабли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2006, 12:08 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Господа, интеграция систем это очень хрупкая штука и каждый ее развивает по своему. У нас это реализовывается следующими методами: учетные системы формируют пакеты и по обычной электронке сбрасывают XML в центр. в центре стоит BizTalk и перемалывает, и в нужном формате отдает потребителю в его систему. качество BizTalk, это отдельная тема, но подтверждаю предыдущие высказывания - сырой еще. по проблеме номенклатурных справочников - это просто самая страшная беда :) Вентилируя данную тему наткнулся на нормальных москвичей (рекламы не будет, Яндекс найдет все. ключевое слово "онтологический классификатор"), которые придумали и разработали методику, и ПО естественно, для ведения системы НСИ (нормативно справочная информация) двумя методами - централизовано и децентрализовано. Кому интересно - они читают семинары на 3 дня где все очень качественно и подробно расказывают и показывают. Суть долго обьяснять, но все сводится к тому, что есть централизованое хранилице НСИ и номенклатура распределяется сверху в учетную систему с необходимым кодом (естественно по ответу от системы можно получить код соответсвия) и тогда передавая данные с одной системы в другую мы всегда имеем точное соответствие и проблем с НСИ нет в принципе. Децентрализованая схема - завели на месте, передали в единый регистратор, и оттуда в другую систему, если необходимо, и опять имеем код соответствия. Паралельно центральное хранилище решает проблемы множественных клиенториентированных класификаций и естественно кодификации номенклатуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2006, 13:28 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Владимир СосницкийУ нас это реализовывается следующими методами: учетные системы формируют пакеты и по обычной электронке сбрасывают XML в центр. в центре стоит BizTalk и перемалывает, и в нужном формате отдает потребителю в его систему. качество BizTalk, это отдельная тема, но подтверждаю предыдущие высказывания - сырой еще. по проблеме номенклатурных справочников - это просто самая страшная беда :) Славутич? Единственное, насколько я знаю, внедрение BizTalk на Украине а может и в СНГ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2006, 12:31 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
guest_20040621> У нас на одном из заводов только 8 РАЗНЫХ систем клиент-банк > для связи с РАЗНЫМИ банками. А чего только восемь?По разным причинам, некоторые из которых я называть не имею права. Но наиболее распространенная причина - "нельзя держать все яйца в одной корзине". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2006, 14:01 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
2 IgorTv Не совсем понятно для чего вы это делаете? Есть ли продолжение интеграции, или создание таблиц соответствий между объектами приложений есть конечная цель? Описанные вами проблемы, очень часто возникают на периферии :( Это и скупость организации, и нежелание программистов разработчиков договариваться между собой и т.д. и т.п. Общий подход применяемый, мной, в таких ситуациях выглядит следующим образом: 1. Анализ существующего функционала, и подбор программных средств, или постановка тех.задания на написание новых, повторяющих уже существующий функционал как минимум. 2. Анализ бизнес-процессов - корректировка БП и тех.задания. (необязательный пункт) 3. На основании п.1 и 2 формируется структура базы данных к которой приводятся все существующие данные. 4. В итоге на руках имеем базу связанных данных для различных приложений. 5. Продолжаем развивать интеграцию, или решаем какие то свои вопросы :) Замечания принимаются :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2006, 17:23 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
babys 2 IgorTv Не совсем понятно для чего вы это делаете? Есть ли продолжение интеграции, или создание таблиц соответствий между объектами приложений есть конечная цель? Описанные вами проблемы, очень часто возникают на периферии :( Это и скупость организации, и нежелание программистов разработчиков договариваться между собой и т.д. и т.п. Допустим есть компания, где есть >3 крупных бизнеса. В каждом бизнесе своя (и не одна) система учета (так исторически сложилось). Системы друг с другом местами повязаны. Справочники местами пересекаются, но единой кодировки нет. Сейчас идет процесс внедрения общей новой системы на всех, но сразу заменить все не получится. Так что нужно как минимум на период, пока старые системы не умрут - придумывать интеграцию чтобы можно было старые одну за другой отключать и все остальные этого не чуствовали. Для этого и нужна перекодировка на лету+автоматическое поддержание таблицы соответствия. Тут не переферия и не скупость. Тут феодальная разрозненность :) И приходится мне программистов между собой договаривать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 10:53 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
babys 2 IgorTv 4. В итоге на руках имеем базу связанных данных для различных приложений. Единоразово это сделать можно - не вопрос. Как ее потом поддерживать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 10:59 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
IgorTv Единоразово это сделать можно - не вопрос. Как ее потом поддерживать? Это уже технические вопросы :) Базы на чем лежат у работающих задач, в смысле какие db? Исходя из этого, и надо решать. При создании структуры связанной базы и надо решить эти вопросы. Здесь же надо решить и вопросы поддержки целостности, включая моменты создания новых, изменения и удаления элементов, решения вопросов безопасности, контроля и т.д. Причем не только самой связанной базы но и приложений работа которых будет с ней связана. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 12:16 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
авторСуть долго обьяснять, но все сводится к тому, что есть централизованое хранилице НСИ и номенклатура распределяется сверху в учетную систему с необходимым кодом (естественно по ответу от системы можно получить код соответсвия) и тогда передавая данные с одной системы в другую мы всегда имеем точное соответствие и проблем с НСИ нет в принципе. Децентрализованая схема - завели на месте, передали в единый регистратор, и оттуда в другую систему, если необходимо, и опять имеем код соответствия. Паралельно центральное хранилище решает проблемы множественных клиенториентированных класификаций и естественно кодификации номенклатуры. Опять изобретен велосипед! Это называется MDM (master data management) и поддерживается несколькими тиражными продуктами, включая SAP. Я тоже пришел к мысли, что интеграция систем через сервер интеграции (BizTalk, например) должна включать MDM-подсистему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 11:45 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
ГликогенОпять изобретен велосипед! Это называется MDM (master data management) и поддерживается несколькими тиражными продуктами, включая SAP. у этого велосипеда много названий, первенство неизвестно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 11:49 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Гликоген Опять изобретен велосипед! Это называется MDM (master data management) и поддерживается несколькими тиражными продуктами, включая SAP. Я тоже пришел к мысли, что интеграция систем через сервер интеграции (BizTalk, например) должна включать MDM-подсистему. А где про это почитать можно чтоб не клыкать миллион ссылок? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 11:59 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Корректно ли поставлен вопрос о синхронизации справочников, вот цитата: "Конкретно - элементарный вопрос- синхронизация справочников :) Перписывать все системы на единую кодировку нельзя. Как решать вопрос, что товар заводится в одной системе с кодом 10 его нужно создать в другой системе где ей присвоится свой код 123. где и как сохранять эти ссылки что 10=123." Создается впечатление, что все справочники имеют однозначное отображение своих записей на записи остальных справочников. Если это так, то проблема в аккуратном создании таблиц перекодировки и создании механизма добавления новых записей во все справочники. Если в одних справочниках есть запись например о материале М12345, а в остальных нет, то их сразу можно создать автоматически. Т.о. решается проблема соответствия на момент Ч. Далее все работает само по себе, создавая везде новые записи и корректируя таблицу соответствия при вводе где-то новой записи. Однако, можно с большой долей вероятности утверждать, что эта схема нежизненна, поскольку однозначного соответствия в нашей жизни не бывает даже между одинаковыми по функциям справочниках. Вот для этого варианта предложить что-то разумное не удается. По-моему к такому выводу уже приходили рассматривая подобную проблему в начале года. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2006, 18:28 |
|
||
|
Интеграция учетных систем.
|
|||
|---|---|---|---|
|
#18+
Задача крайне нетривиальная... :( Например в одной системе адрес заводится прямо в главную запись, а в другой системе адреса лежат в отдельной таблице. И правила (целостность) там можут быть очень даже непростые. И автоматическое создание записей в другой системе "внешним способом" может быть невозможно, т.к. система может генерить какой-нить внут.код с помощью хитрой процедуры и всякие дополнительные строки в другие таблицы (аудит). Достаточно вспомнить генерацию любых номеров в навижине, где есть таблица серий номеров и нехилая процедура по получению очередного номера (зависит от даты, типа документа, серии и т.д.). При этом меняются данные и в самой этой таблице. Грамотно имитировать такое поведение крайне сложно. И всякие БизТолки тут просто Без Толку :) и применимы полько для относительно простых случаев. Наблюдал ситуацию, когда синхронизировали базы 8-10 супермаркетов. В общей сложности почти 0,5млн. строк ! Перед синхронизацией базы маркета её "закрывали" и делали её сведение к эталонной базе. Вручную. Затем в один прекрасный момент процедурой меняли все ИД на новые согласно таблиц сведения и запускали "автоматический репликатор" с Центр.Базой. Потом брали базу другого маркета и т.д. Весь процесс занял неск.месяцев. Но это всего два(!) справочника: Товары и Контрагенты. Да и система простая, потому что самописная и базы совершенно однотипные. У Вас задача раз в 20сложнее. По сабжу: наиболее подх. вариант - организационный. Чётко и жестко регламентировать процесс ввода данных вручную (там где затруднительно делать автоматом). Ввести некий "глобальный код", кот. указывать либо в коментарии либо хоть в самом тексте: ООО "Рога и копыта" [xxх код хxx] Наделать кучу процедур проверки правильности. При переносе в JеDиную :) систему использовать этот глобальный код. Других целесообразных способов нет, ИМХО. Тем более это сравнительно недолго будет работать и усилия по тотальной автоматизации пропадут почти даром. ЗЫ: Игорь, превед кстате. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2006, 16:41 |
|
||
|
|
start [/forum/topic.php?all=1&fid=29&tid=1527798]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
121ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 459ms |
| 0 / 0 |
