|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
_VVP_ ... Еще один момент - изначально примите решение о разделении бухгалтерского и оперативного учета по разным системам .... Ну все. Приплыли. Боролись боролись за интеграцию, против ИТ-зоопарков. А тут на тебе. Вот так просто. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2009, 12:18 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
astonНу все. Приплыли. Боролись боролись за интеграцию, против ИТ-зоопарков. А тут на тебе. Вот так просто. кто боролся? Я, например, не боролся. А вообще, борьба показала, что монстрообразие в виде ERP совсем не то, за что нужно бороться. Смещение акцентов идет с сторону сервисно-ориентированных архитектур. Наличие двух систем никоим образом не отменяет интегрированное пространство. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2009, 13:27 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
aston, Цена такого решения - существенное удешевление поддержки подсистемы бухгалтерского учета за счет регулярного обновления этой производителем этой подсистемы. Интеграции это не противоречит. Или на каждый чих законодательства лезть и переделывать систему оперативного учета, или тупо обновил БУ, отследил, не изменились ли структуры данных, подправил правила переноса и все... Это и есть интеграция, когда каждая система отвечает за свою область учета. Думаю, тут терминологическая путаница, ибо "зоопарк" и "интеграция" имеют больше общего, чем кажется :) И разница не столько в методологии разбития системы на автономные компоненты, а больше в реализации этого самого разбития. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2009, 13:33 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
iscrafmastonНу все. Приплыли. Боролись боролись за интеграцию, против ИТ-зоопарков. А тут на тебе. Вот так просто. кто боролся? Я, например, не боролся. А вообще, борьба показала, что монстрообразие в виде ERP совсем не то, за что нужно бороться. Смещение акцентов идет с сторону сервисно-ориентированных архитектур. Наличие двух систем никоим образом не отменяет интегрированное пространство. Поддерживаю. "Кесарю - кесарево". У нас на проекте полтора года пытаются прикрутить в оперативной ERP системе с режимом работы 24/365 - "бухгалтерский учет продаж". Попытка сопоставить платежи или сформировать книги покупок продаж вешают всю оперативную работу напрочь. Сервис деск, тупо всех бухов из системы выкидывает, тупо что бы не мешали отгрузку производить. Простой отгрузки - прямые убытки, не отгрузили вовремя и доход потеряли и на штрафы налетели. Так что разделение контуров это в некоторых случаях плюс. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2009, 15:23 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
Тю... Полтора года? Вариант №1. Делим СУБД на два экземпляра: оперативники и БУ. Система (ПО) может оставаться той же. Вариант №2. Не надо бухгалтеру сопоставление платежей за 2 мин. Внесите "управляемость" в процесс сопоставления платежей. Система после получения задания на сопоставления считает сама мелкими этапами с задержками. (Помнится на dbf-ах лет 15 назад на комп "зарплатчице" поставили сетевуху 10МБит/сек, чтобы она расчётом зарплаты не напрягала весь отсальной коллектив бухгалтеров ) варианты ещё есть, заходи если ш о :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2009, 16:13 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
АнатоЛой, это как, разбить на 2 БД не трогая ПО? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2009, 19:18 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
Petro123АнатоЛой, это как, разбить на 2 БД не трогая ПО? Я подразумевал не "не трогая ПО", я хотел сказать, что марка системы может оставаться той же: две 1С, две СФЕРА/5, две ISCRAFramework, две Галактики... То есть если у этой системы функционал позволяет эффективно решать обе задачи. Интегрироваться то придётся в любом случае, а нормальная система между двумя своими экземплярами может (правда, не обязана) делать это более эффективно... ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2009, 19:49 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
АнатоЛой, для этого система сама должна это позволять (масштабироваться). Хотя с другой стороны: "две 1С". Как тогда получать консолидированные данные? Там ведь на XML обмен? ... |
|||
:
Нравится:
Не нравится:
|
|||
24.11.2009, 23:15 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
Бла, бла, бла. Как это знакомо. Пускай наработаются все, кроме программистов. Видите ли, им слишком сложно выполнять обновления и чего-то там отслеживать, а также сделать так, чтобы бухи не вешали продажников. Крылья еще не выросли и нимб над головой не светится? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 05:53 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
astonБла, бла, бла. Как это знакомо. Пускай наработаются все, кроме программистов. Видите ли, им слишком сложно выполнять обновления и чего-то там отслеживать, а также сделать так, чтобы бухи не вешали продажников. Крылья еще не выросли и нимб над головой не светится? Если считать что руководители это голова компании. А программисты ноги . То иногда справедлива пословица "Дурная голова ногам покоя не дает". ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 10:20 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
на вопрос: Petro123АнатоЛой, для этого система сама должна это позволять (масштабироваться). отвечаю: АнатоЛойНормальная система между двумя своими экземплярами может (правда, не обязана) делать это более эффективно... А по поводу Petro123 Хотя с другой стороны: "две 1С". Как тогда получать консолидированные данные? Там ведь на XML обмен? могу добавить: Смотря что в данном случае понимать под "консолидированные". Предлагаю даже рассмотреть самый тяжёлый случай: хотим в одной БД иметь все данные. Имхо, в данном случае "бухгалтерский" экземпляр системы может сам выступать в качестве БД с "консолидированными" данными. Проблема-то как звучала: бухгалтера не дают складу работать. Убираем со складского экземпляра нагрузку бухгалтерии (по изменению и чтению данных бухгалтерией), вместо этого оставляем на складском экземпляре для бухгалтерии только поток чтения с него для бухгалтерского экземпляра. Объём этого потока пусть даже равен всему объёму изменений на складском экземпляре: чтение в объёме записи не должно быть критичной или даже ощутимой нагрузкой для пользователей склада. Обратная репликация может и понадобится, но уже совсем не в полном объёме (чихать складу на упомянутые процессы "сопоставления платежей" или "формирования книги покупок продаж"). Типичный шаблон проектирования архитектуры "разделяй и властвуй", он же " A на то есть с Лой " (я). Думаю, если бы в постановке было сразу две разных системы - практически не задумываясь пришли бы к описанному мною варианту... П.С.: Petro123, я в 1С не дока - достаточного практического опыта пока не имею :(... ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 11:16 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
astonБла, бла, бла. Как это знакомо. Пускай наработаются все, кроме программистов. Видите ли, им слишком сложно выполнять обновления и чего-то там отслеживать, а также сделать так, чтобы бухи не вешали продажников. Крылья еще не выросли и нимб над головой не светится? как раз об этом речь и идет. Строить системы так, чтобы бухи не вешали продажников, чтобы легко выполнялись обновления, чтобы просто было отслеживать... Что хотели сказать? Совершенно не понятно что, к чему относится ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 11:32 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
Не вопрос. Стройте систем У . Главное, чтобы было единое информационное пространство на объекте автоматизации без процессов перекачки, консолидации, сопоставления и сверки между разными систем ами . Ибо это процессы вырожденные и паразитные, придуманные в том числе программистами. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 12:19 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
astonНе вопрос. Стройте систем У . Главное, чтобы было единое информационное пространство на объекте автоматизации без процессов перекачки, консолидации, сопоставления и сверки между разными систем ами . Ибо это процессы вырожденные и паразитные, придуманные в том числе программистами. Единое информационное пространство - это та абстракция, о которой все говорят, но не все понимают, что это такое. Чуть выше было сказано о том, что замена монстрообразным ERP - сервисно-ориентированная архитектура. Создание документа в одной системе, а проведение его в другой, требует такой же сверки, как и в рамках того, что Вы до сих пор считаете "единой системой". Консолидацию придумала жизнь, а не программисты. Вырожденными процессами называются те, которые не подходят для компании. В любой ERP Вы можете найти их массу. В общем, это все банальности. В самом начале века они еще были в диковинку, но сейчас-то... Мне действительно удивительно такое читать. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 12:34 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
astonСтройте систем У . Проходили уже. "Даешь одну большую супер-пупер систему, которая будет делать всё!" (с) САП :) Только гибкость таких систем падает катастрофически, а стоимость поддержки наоборот, катастрофически растет. Не говоря уже о скорости исправления ошибок и жесткой привязке к автору такой системы. ;) astonГлавное, чтобы было единое информационное пространство на объекте автоматизации Его как раз и обеспечивает правильная интеграция. Пользователю абсолютно до лампочки, сколько у него баз данных и как они синхронизируются. Главное - интеграция позволяет объединять в это самое единое информационное пространство наиболее подходящие инструменты для решения узкоспециализированных задач, а не писать эти инструменты самому. ...без процессов перекачки, консолидации, сопоставления и сверки между разными системами. Ибо это процессы вырожденные и паразитные, придуманные в том числе программистами.Зря, выходит, придумали SOA, XML и прочие механизмы упрощения обмена данными. Зря выходит придумали ActiveX\OLE\COM для упрощения взаимодействия разных программ. Да и LinkedServers зря запихали в машину mssql. :) Я так думаю дальнейший спор бесполезен. Иначе перерастет во флейм а-ля "windows vs linux". Когда каждый отстаивает свою точку зрения, не слушая, да и не давая аргументацию :) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 12:40 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
Система не может быть большой или маленькой или монсторообразой. Она может быть достаточной или нет для данного конкретного объекта. Слишком велик SAP, возьмите Галактику. Велика Галактика - возьмите 1С. Или разработайте собственную. Одно радует. Работы по расчистке зоопарков еще хватит надолго. З.Ы. Я дюже удивлен, когда в случае, если бухи вешают продажников при формировании книги покупок, уважаемая публика советует посадить их в разные системы вместо того, чтобы сменить криворукого девелопера. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 12:57 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
полное непонимание того, что называется системой. Одну и туже задачу можно решить различными способами. И как раз большие ( и даже монстрообразные) и маленькие системы - это объективная реальность. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 13:10 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
Полное заточнение в девелоперской среде. SAP для GeneralElectric это не монстр, а козявка. 1С Бухгалтерия для ИП Пупкин - это не козявка, а монстр. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 13:16 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
aston, а чем занимается этот "ИП Козявкин"? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 13:28 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
iscrafmaston, а чем занимается этот "ИП Козявкин"?Флудит на форуме))) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 13:30 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
автор Я дюже удивлен, когда в случае, если бухи вешают продажников при формировании книги покупок нефик делать я насколько понял речь о 7ке... правда это возможно в том случае если запущена скажем процедура автоформирования налоговых... журнал то док-тов один... вот и ждут продажники пока бухгалтерия закончит процесс а ещё есть любители перепроведения оптово-массового для первых событий :) когда такое есть то уже без связки Торг+Бух отдельными физическими БД никуда... да и не нужно как правило в бухгалтерии вся продажная аналитика, достаточно и сводных торговых проводок а всё остальное по деятельности предприятия всё равно по торговле нет смысла гонять так что в разделении учета по участкам физически есть свои преимущества (как и недостатки связанные с синхронизацией) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 13:41 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
astonПолное заточнение в девелоперской среде. Таки флейм начался... :) Aston, приведите хоть одн аргумент, когда "монолитная" система выигрывает перед "интегрированным зоопарком". Как пример - есть три ситем ы , пускай это будут продукты 1С: - "зарплата и кадры" (ЗИК), "Бухгалтерия" (БУ)и "Оперативный учет" (ОУ). "ЗИК" и "БУ" - купленные продукты. Замечу, что у этих продуктов есть встроенная система обмена данными. "УУ" - тоже купленный продукт, но в отличии от остальных - "курочится" в соответствии с изменениями текущих бихнес-процессов собственным ИТ. Первичная документация вся заносится в ОУ. Кадровый учет прозрачно выгружаюися в ЗИК (репликация кадровых документов и справочников ОУ->ЗИК). Бухгалтерские документы выгружается в БУ "одной кнопкой" (регламентный перенос документов ОУ->БУ, после закрытия периода ОУ). Результаты расчета ЗП и налогов (в полном соответствии с законодательством) штатно переносятся в БУ, откуда забираются (с трансформацией аналитики) в систему ОУ. В результате имеем три системы. Поддержка ЗИК и БУ полностью лежит на разработчике этих систем и оплачена лицензией при покупке. Поддержка и доработка ОУ, а также все механизмы синхронизации с ОУ - собственный ИТ. В результате - фирма имеет актуальную "фискальную" систему. И минимальные затраты на поддержку соответствия законодательству. Основные затраты на ИТ сконцентрированы на соответсвии подтемы ОУ текущим бизнес-процессам. И согласованности их с законодательно диктуемыми ЗИК и БУ. Вопросы к Вам, Aston: 1. Как это будет выглядеть в "монолитной" системе? Кто будет отслеживать и реализовывать соответствие законодательству? 2. Сколько ресурсов потребует такая поддержка? 3. И главный вопрос: какие "крылья и нимбы" нужны, чтобы объяснить работодателю, что нужны эти доплнительные ресурсы? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 15:50 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
astonSAP для GeneralElectric это не монстр, а козявка. 1С Бухгалтерия для ИП Пупкин - это не козявка, а монстр. SAP для GeneralElectric точно такой же инструмент учета, как и 1С:Бухгатерия для ИП Пупкина. Если этот инструмент помогает для достижения бизнес-целей - его используют, нет - не используют. С учетом бюджета конкретного предприятия, естественно... ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 15:59 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
Егоров Александр, +1 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 16:16 |
|
Выбор архитектуры . -====1с====--
|
|||
---|---|---|---|
#18+
1С 8.0 вполне справиться. "специфичные части бизнесс логики" - это воровство "потери в производстве" и уход от налогов "налоговая оптимизация"? Если да, то 1С вполне адаптирован под воришек особенности российского бизнеса. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.11.2009, 16:23 |
|
|
start [/forum/topic.php?fid=33&msg=36328831&tid=1548416]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
52ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 303ms |
total: | 451ms |
0 / 0 |