Какие доводы можно привести за 1С против навижн ? Планируется внедрение NAVISION, но клиент хочет услышать сильные стороны 1С. Возможно, передумает.
Спасибо.

Планируется писанина практически с нуля. Нужна автоматизация управленческого учета с выгрузкой в БП 8.2

1с тупо дешевле (и в начальных вложениях и в обслуживании и в расширении)

внедрять куда и зачем? цели то какие?

(1) больше быдлокодеров

(3)см. 1

(1) забадаетесь... я так понимаю там кастомизация дорогая. И лапшу с ушей поставщика "мы все сделаем" надо стряхивать

(0) Навижен - окаменелое дерьмо мамонта.

(1) Писать с нуля на  Навижен просто глупо.

мне казалось что Навижен - старье... или нет?

(7)Не. ну там возьмется за базу например ихняя CRM-ка...

(7) +1

там все остановилось на уровне Access 2.0 в плане среды разработки и прочего. Много там накастомизируешь?

В навижн нет цветовой синтаксической разметки кода!!

ЗЫ это я от гения слышал.

Слышал в одной крупной фирме как главбух общалась с фиником на счет перехода с nav на 1С. Главбух сказала, что 1С ставят только мелкие фирмы, у которых нет денег на нормальные программы)

http://www.axforum.info/forums/showthread.php?p=237681#post237681

Здесь Mazzy доказывает, что Navision при разработки с нуля круче 1С 8.2 и даже аксапты!
Со скриншотами

(12) да-да... если бух этот занимается только gaap и прочая может быть. Нашим оно даром не упало... Купить OeBS и строить ОСВ в экселе - это от отсутствия денег?

просто 1С лучше...

(13) маззи там доказывает, потому что когда ему начинают задавать вопросы по существу, а он не может ответить, он просто банит неудобных

я могу доказать что БЭСТ-4 удобнее 8.2. Если хорошо поискать подходящий пример.

(9) Если вы хотите выбросить деньги, то могу номер своего счета дать. Получите тот же результат, но без геморроя длиной в год.

В моей прежней конторе у ИТ-директора была идея-фикс - внедрить "настоящую ERP". Ну не писать же кандидату технических наук в резюме "внедрил 1С". Я тогда писал докладную генеральному на трех листах с описанием, почему это гуано не сможет решить задачи, которые планируется решить. Ессно с заявлением об увольнении, т.к. участвовать в этом процессе я не хотел никоим боком.

Результат - год контора стояла на ушах, потрачено больше 70 тыс. евро впустую, год идут суды в попытке вернуть деньги с "внедрюков" хотя бы частично. ИТ-директор уволен. Его преемник, пытавшийся спасти проект, уволен. Контора продолжает работу на семерочной самописке примерно 1992 года, которую ваш покорный слуга на пару с коллегой написали и внедрили за 8 месяцев. Которая ессно устарели и морально, и физически.

К сожалению текста докладной не осталось за давностью лет. А заново ковыряться нет возможности - я на это месяца два потратил.

(0)В СНГ  даже и не думай внедрять навижин....  засмеют  и будешь белой вороной.......  только 1С....  как в анекдоте "только х-ем  и не в коем случае руками" ибо у нас только красивые дети получаются.. а все остальное сам понимаешь  что...

(0) самый главный, нету исправлений задним числом.

(16) Сможешь аргументировать, что SIFT хуже здесь?

(19) Чего то не совсем ясно откуда в 1992 году взялась семерка, для начинания "самописки" :)

по нему же полная ж.па с проектами... п.э. ушлые внедрюки согласятся "переписывать" что угодно, лишь бы заплатили

используй подход http://www.pcmag.ru/solutions/sub_detail.php?ID=40193&SUB_PAGE=3

(19) что за ерп за 70 тыс евро ?

(23) Тфу, 2002 конечно!
Это я справки о сдаче жилья из КЭЧ как раз перекладываю от 1992 года в папке вот и пишу хрень :)

ну, что вам сказать.. в 2003-м устроился я на крупную фирму, у неё был и навижн, и 1с в трех ипостасях..
через полгода весь отдел навижн был уволен (не в связи с моим приходом, конечно, а потому, что от него, видимо, было мало проку.. одни расходы)

а уж в 2009 году и сама фирма перестала существовать.. капитализм-с..
но до самого конца гендир был приверженцем 1с.. вот был генератор идей!! только позавидовать :)

Процент плохих программистов в любых системах примерно одинаковый, но с учетом общего количества программеров всяких сап и навижн - количество тех, кто сможет создать и внедрить эти системы приближается к нулю. В 1С типа естественный отбор - можно отсеять и найти тех кто запускал и может запустить систему. В сап-навижн новички прикрываются мощностью системы и надеются что как-нибудь да запустят.

(26) Это только закрытые этапы и чуток предоплаты. А лицензии не все сразу стали покупать. До того, как проект зашел в тупик, были превышены все сроки и бюджет. Теперь судятся по закрытым актам. Типа хорошо, что было проведено предпроектное обследование, но оно в рамках договора внедрения, который не выполнен. И самостоятельный результат оного на фиг конторе не нужен. Часть судов решает в пользу конторы, часть утверждает, что акты подписаны, значит работа сделана. Короче юристам развлекуха еще та. Но вроде большую часть отбили.

(29) Вопрос не в плохих программистах. Особенно с учетом того, что в Навижен гораздо меньше программировать нужно.

Вопрос о российском бизнесе и его реалиях, особенностях российского бухучета и т.п. и возможностях учетной системы. А также о применимости данного продукта к конкретному предприятию. Для примера в прежней же конторе на производственном предприятии он бы вполне вписался и заработал. Дискретное двух-трехпередельное производство для него без проблем. Да еще при налаженных процессах. Лепить его в сложную оптово-розничную торговлю с импортом, дистрибьюцией, проектными работами, кучей взаимосвязанных юрлиц, увязанных в один управленческий контур и т.п. было несколько самонадеянно. Ну не его это хлеб.

(1) Писать с нуля на Наве -- верх идиотизма. Ка среда разработки ИС 1С на голову выше. Даже 7-ка (помню, как ацки завидовали навиженцы семерочным отчетам).
Нав может быть ценен только правильной (ну, так говорят) реализацией MRPII, но это только в типовом решении.

+(32) Если быть более точным, Нав -- вообще не среда разработки ИС. Это готовое решение с некоторыми возможностями кастомизации. И, кстати, если я не ошибаюсь, лицензий на доработку конечным пользователям там обычно не дают, только партнерам. Или её просто отдельно покупать надо, не помню. На это, правда все легко кладут с прибором, но всё же ...

А в чем сильные стороны Навижн ? Ну хоть что то лучше чем в 1С должно же быть ???
Итак доводы за 1С:
1. Кастомизация на порядок дешевле.
2. Поддержка дешевле.
3. Простая совместимость с 1С бухгалтерией.
4. Продвинутая среда разработки.
5. Появление новых версий и как следствие новые возможности для конф
6. ?

Какие доводы за Навижн ?

(11) Нет цветовой дифференциации штанов ;-)

У навижн и сап возможно лучшая поддержка СУБД, соответственно скорость, мощность.

(36)В относительных значениях на сколько ?

(36) Native движок этого зверя достаточно шустр. А вот SQL-вариант уже не столько.

В 1С все привязаны к типовой схеме - справочник-документ-регистр-отчет. В сап-навижн теоретически можно создать более гибкие и оптимизированные схемы-объекты.

(36) улыбнул)))

(39) и кто гипотетически это будет делать и за какие деньги?

(34) [Какие доводы за Навижн ]
- функционал дерет 1С как тузик грелку
- релизы не содержат детских ошибок
- скорость работы на порядок выше
- и главное - нет перепроведения

(39) Теоретически да. Практически саперы на проекте, с которым сейчас ковыряюсь, выгрузку данных в xml-формате некой информации и формирование штрихкодов на документах, делали три дня и два раза еще накосячили. В ПУБ, Комплексной и Бухии я потратил на это в среднем по 30 минут. Ибо в их тысячах таблиц и процедур задолбаешься разбираться.

Разработка в Навижине возможна только с лицензией вендора.
Соскочить не реально, т.к. она имеет печальное свойство периодически истекать. :(

ЗЫ Ещё очень много зависит от того, что понимается под управленческим учётом.
ЗЫЫ В навижене грядёт смена платформы. Её бесшовная замена как ранее - не предвидится:( (А это был один из основных аргументов Мази против 1С на этапе появления 8ки).

(13) читал как-то сообщения этого Мази и сложилось впечатление, что он хреново знает 1С.
Например "Даже в последних версиях 1С со связками между таблицами нужно поработать (Кнопка Перейти наверху каждой формы)". В 8.2 нет такой кнопки.

(44)Упр. учет это впринципе очень сильно перепсианная торговля услугами.

(44)
Не понял. можно объяснить:
>>Соскочить не реально, т.к. она имеет печальное свойство периодически истекать. :(

(42)
> - функционал дерет 1С как тузик грелку
Крайне сомнительное утверждение. Применительно к УПП.

>- релизы не содержат детских ошибок
Действительно бывают они настолько редко, что сложно допустить ошибку

> - скорость работы на порядок выше
Это миф.

> - и главное - нет перепроведения
Многие корректировки просто задолбаешься проводить. Без степени доктора в области ядерной физики хрен корректно откатишь. Кроме того многие корректировки очень оригинально потом перекладываются на бухучет. Во многом эта возможность теоретическая. В некой телекоммуникационной конторе был товарищ, имеющий статус незаменимого. Ибо только он мог снизойти до бухгалтера и поправить именно "задним числом", а не корректировками. Если его долго просить. Преимущество сомнительное.

Кроме того какая религия запрещает запретить правки задними числами в том же УПП?

2(45)http://www.screencast.com/users/october.hammer/folders/Jing/media/41b5b717-1b8c-4ba3-acfe-aa0b4cb84bdd

(45) А вы уверены, что прочитанное Вами высказывание было сделано после выхода 8.2 ? ЗЫ Мази давно уже ушёл от разработки в 1С.

(46) Тогда лучше наверное 1С. У неё интерфес подружественнее.
(47) Вы сможете нанять своего программиста по Навижену, но ему нужна будет лицензия (которой с вами может поделиться вендор). Но она кончится (срок 1 год) и Вам снова придётся ДОГОВАРИВАТЬСЯ с вендором.

(50)Ну а получение это лицензии это какое волшебство нужно сделать ?

Скорость работы относительно 1С разниться от участка к участку.
Достигнуть предела производительности весьма реально.

(50) написано 29.11.2010 http://www.axforum.info/forums/showthread.php?p=237676#post237676

2(53) и в8.2 есть эта кнопка... Хотя возможно и не в каждой форме.

(51) ДОГОВОРИТЬСЯ, ТОЕСТЬ ЕЁ НАРУШИТЬ!!! Конечным пользователям она недоступна.

(53) Почитайте внимательно, о чём именно там пишет Мази. В 1С это надо кодить :(.

(56) Что нужно кодить в 1С, поясните?

(56) да что вы все в перейти впились то? это реализовано на уровне платформы и без кода, связанные регистры, справочники по умолчанию появляются, остальные можно через Критерии отбора привязать... Мази - типичный недокодер 1С, неосиливший и ушедший в (как он сам говорит) "игрушечные примеры"

Я вот чего не пойму: а почему все здесь обсуждаю Навик как средство разработки. Пользователю это параллельно. Плюс 1С в наличии набора отраслевых решений. Если Навик продает мечты "как это может быть", то мы возможно предложим решение. Отсюда вопрос к (0)- опиши обьект автоматизации

(57) То, что по ссылке пишет Mazzy тут
http://www.axforum.info/forums/showthread.php?p=237681#post237681

То, что расшифровку в отчете в 1С необходимо кодить.

(42) И самое главное - самый громкий крик!
"Внедрение от сертифицированных партнеров за 1—2 месяца"
http://www.microsoft.com/Rus/dynamics/nav/overview.mspx

"Популярность системы обусловлена скоростью внедрения, низкими эксплуатационными расходами, быстрой адаптацией под требования и особенности бизнеса заказчика."

Правда не видно криков в самом малом - соответствие законодательству РФ.
Или это "соответствие" есть "требования и особенности бизнеса заказчика" и допиливается легко за 1-2 месяца?!

А меня особенно сразил функционал "Управление персоналом"
http://www.microsoft.com/Rus/dynamics/nav/person.mspx#person3
Детским лепетом городо о банальностях...

И еще нажал Расчет стоимости проекта и вижу, что навижн желает меня объегорить, ибо цену не светит. Видать жулье!
"Для того, чтобы мы могли наиболее полно ответить на Ваш запрос, пожалуйста, заполните приведенную ниже анкету."
Детский лепет...

(0) А ви покупаете или продаёте? Таки если ваш доход увеличится пропорционально увеличению количества гемороя тогда ищите доводы "За".

(0) Лезь на сайт навижна, задавай вопросы им.
Именно они и раскажут почему у них апельсин сладкий и за какую цену, а у других - тоже апельсин сладкий, а цена в прайсе.

(60) я не такое видовал, когда семерошники на 8.1 всякими нетривиальными способами пытались реализовать функционал СКД... С группировками по иерархии, раскраской групп и измерений... То, что делается одним запросом, и нажатием 2х кнопок - выполнено программной дрочкой макета, приставлением областей, и кодом в 10к строк

(43) это не плюс и не минус. Просто особенности конфигурации

4 года назад работал с навиженом... не заню насколько сечас изменился функционал... но тогда минусы:
- куча кода - это верно - такое ощущение что , программист кодивший после когото - не исправлял ошибки в уже существующем коде , а дописывал сбоку свой обходя в какомто конкретном случае какуюто конкретную ошибку
- отчеты ваять - геморрой - на отчет ... на который в 1С уходит 30 минут . в навике действитенльно его можно делать 3 дня
плюсы :
- менее требовательно к ползователскому железу
- FlowField поля - это очень сильно и в 1С это вряд ли когда будет
- очень понравилась система бюджетирования
- работает быстрее даже без допиливания - если сравнивать скажем с той же упп при одинаковом количестве и интенсивности пользователей
- дорогая система если сравнивать с 1С

(65) Если они куцый функционал в
http://www.microsoft.com/Rus/dynamics/nav/person.mspx#person3
реализовали, как сказал (43) "тысячах таблиц и процедур", то они действительно профессионалы по написанию кода.
За такое нужно отвалить много бабла.

+66 если очень захотеть - то потратив некоторое количество времени и сил можно сделать доработку(обработку) для навижена по корректировке нужных документов (исправление учтенных) в навижене

(42)
>> - функционал дерет 1С как тузик грелку
В типовом решении для отдельных видов бизнеса. См. (1)

>> - релизы не содержат детских ошибок
Угу, и выходят раз в 5 лет.

>> - скорость работы на порядок выше
Враки. Вполне сопоставимо.

>> - и главное - нет перепроведения
Еще раз смотри (1)

"FlowField поля - это очень сильно и в 1С это вряд ли когда будет " вкраце, что это?

берите Axapta там это реализовано

Вычисляемые поля, как яндекс сказал.

кстати а где и как именно навижен "дерет 1с как тузик грелку" ?

(72) А что, в 1С нет вычисляемых полей?

(72) Это из серии показать колонку остатка на складе в справочнике товаров ?
в 8.2 динамические списки кажут

Эти вычисляемые поля можно добавлять прямо в таблицу. В 1С так нельзя.

У нас работает НАВ в упр. учете, бух и кадры на 1С. НАВ реально быстрее 1С-ки, но сделан, ИМХО, не через то место. Чего стоят только наименования клиентов размерностью в 50 символов, расширять которые забодаешься. Но больше всего вымораживает политика лицензирования. Т.е. лицензия требуется на каждый заблудившийся "ИК", буквально. Про девелоперскую лицензию вообще молчу. Про красивые разноцветные отчеты - забудьте, отчеты с расшифровкой - тем паче.  Механизм аналитических отчетов весьма силен, а вот печатные формы - жуткий ужас, редактировать их невозможно. В принципе, основные минусы НАВа упираются в интерфейс. Сюда же добавлю отсутствие нормального дебаггера.

Добавлю, что обмен данными с НАВ очень просто реализовать SQL-ными запросами напрямую из таблиц. Писать туда теми же запросами не рекомендуется))

(0) вот накопал
http://www.sql.ru/forum/actualthread.aspx?tid=139060
http://www.sql.ru/Forum/actualthread.aspx?bid=53&tid=245289&pg=1

(79)спасибо. буду читать. завтра на ковер :)

(79) А в 1С, кстати Drill-Down одной формулой нельзя сделать, в отличии от Nav - это я к тому "забудьте, отчеты с расшифровкой"!

(75) нет это не из этой серии...

(81) Угу, и получаешь что? Правильно, табличку с исходными данными. В общем, чтобы флейм не раздувать - отчеты в НАВ отвратительно вырвиглазные. ИМХО естественно.

ну и одно из самых основных отличий - в навижене нигде нет вопросов типа сохранить документ или элемент справочника или не сохранить - все что ты ввел и нажал либо ентер или перешел в другое поле - тут же сохраняется в базе, т.е. потери скажем при обрыве связи с базой минимальны - хорошо это или нет - не зна...

(83) Тем, что SIFT - это не только суммирование, но и Drill-Down одной формулой.
Регистры в 1С - это только суммирование, фильтрация. чтобы сделать Drill-Down надо код/запрос писать.

(85) Инфа с ах - форума  (фраза Mazzy)
(84) Для 1С это только в рег. сведений)

(84) При таком подходе не будет тонкого клиента.

В Навижене есть два справочника Поставщики и Покупатели, которые заполняются независимо друг от друга.
В 1С есть один -- Контрагенты.
Соответственно отчет по контрагенту, который является и поставщиком и контрагентом в 1С сделать можно и выявить должны мы или нет.
В Навижене Вы сделаете 2 отчета и в уме (!!!) будете прикидывать кто кому должен.

(79) Читанул...
Дерьмо этот Навижен!!!
Хотя предлагает бесконечный и сочный материал для мазохистов.

Кратко о навижен, кому интересно!
http://soft.mail.ru/article_page.php?id=207

навижен - это РАБОТА, много РАБОТЫ!!!

перекидывал из нава в 1с, например ОС ведутся в разрезе ID которое имеет предствление на форме "Серийный номер" и может редактироватся.

при этом ссылочная целостность НЕ КОНТРОЛИРУЕТСЯ

1 января списали по ID-1 100р
2 января в карточке ОС поменяли ID с 1 на 2,

после этого у нас повисла проводка на 100р, а в ОС с ID-2 отсутствуют движения

(91) Да, совсем забыл))) Изменяемые пользователем идентификаторы записей - это супер.

(91) Да, естественные ключи у объектных сущностей там на каждом шагу, и это мрачно.

(93) это не то что мрачно, это полный ппц...

(94) Не, ну люди живут как-то.

(88) ну вообщето в каждом справочнике есть отдельное поле где можно установить связь между двумя справочниками - и в отчете и вкаждой карточке справочника будет в этом случае выдавать также общий долг...

(88) Да, с этим я тоже гемора огребал, когда загрузку из Нава в 1С делал.

А кто нибудь реально с технологией SIFT работал в Навижен?

тема уже никому не интересна?

100

ты на форуме навижн бы эту тему поднял.. вот было бы интересно.. а так.. большинство кроме 1С только бейсик в школах видели и соответственно какое тут может быть мнение то?

(0)
Какие доводы можно привести за 1С против навижн ?

Наверняка "за 1С" ты и сам знаешь, а вот "против навижн" могу рассказать следующее. Меня приглашали на 2 проекта (одна лизинговая компания, вторая - многопрофильная) как эксперта, чтобы понять, почему внедрение MS NAV застопорилось. Так вот выяснилось, что внедренцы плохо знают как бизнес-логику вообще, так и бухучёт в частности. Например, под курсовые разницы разницы в плане счетов создавались счета такого вида (пишу в нотации 1С):
  91.01 - Положительные курсовые разницы
  91.02 - Отрицательные курсовые разницы
Как говорится, "вопросов больше не имею". (с)

Так что смело можешь приводить такой довод, что уровень внедренцев Навижн ничуть не выше уровня внедренцев 1С, а вот часовой тариф гораздо дороже.
Ну, и второй стандартный довод - более сложная, по сравнению с 1С, адаптации под быстроменяющееся российское законодательство

(34)
>Какие доводы за Навижн ?

Основной - достоверность учета, см. например (21). Поэтому эта система для белых фирм, коих в России абсолютное меньшинство.

(49) это чо к чему???? ваще

Спасибо всем, кто рассказал тут о недостатках Навижн. В качестве платформы выбрали 8.2. Бюджет на следующий год подписан. Слава 1С! Слава Нуралиеву ! Троекратное УРА !!!

"В качестве платформы выбрали 8.2." - почему не навижен? Вроде на него даже цены снижены

(98) Толку от нее никакого. В "файловом" варианте все чудно. В MSSQL вся ее чудность пропадает. Кроме того по сути это технология промежуточного хранения итогов. Почти как в регистрах 1С. С относительно небольшими различиями в способе хранения данных.

(106)
то есть на SQL под каждое SIFT-поле создается свой тайный мини-регистр ?

(93) "Да, естественные ключи у объектных сущностей там на каждом шагу, и это мрачно."

Это не мрачно, это с.уко гордось настоясчих программиздов, а не 1Совцев-неудачников.
Это типа ВОЗМОЖНОСТЬ работать напрямую с таблицами СКЛ (ну когда там в Аксесс надо выгрузить для бабы Нюры). Не то что непонятные таблицы 1С с совсем непонятными человеку идентификаторами...

(107) Не, SIFT это некий индекс таблицы. Но кроме ключа в нем есть поле с агрегатной операцией. Обычно с суммированием.

Например на складе товар "Какая-то хрень":

Приход 10, SIFT-остаток 10
Расход 5, SIFT-остаток 5
Приход 1, SIFT-остаток 6
Расход 3, SIFT-остаток 3

Не напоминает регистр остатков 1С, но с разницей, что тут остаток на каждое движение?

Да, по сравнению с обычными буржуинскими системами, где остаток вычисляется как сумма всех движений, это преподносится как преимущество. Применительно к 1С он не столь очевидное.

(109) АЙТИ директор одной котнторы пережившей внедрение AXaptbI говорил, что там нету банальных печатных форм, а это 2штуки евро тока за одну с-ф, вот и посчитайте обычный набор документов и у вас уже можно у франя услуги заказать на комплексное внедрение ;-)

(105)Долгая и сверх дорогая разработка. Там УРБД планируется. На навижине вообще непонятно как УРБД сделать. Я их напугал.

Приход 10, SIFT-остаток 10
Расход 5, SIFT-остаток 5
Приход 1, SIFT-остаток 6
Расход 3, SIFT-остаток 3

а если добавить в начало
Приход 1,  SIFT-остаток 1

как пересчитается все остальные значения в SIFT?

(112) Это же не 1С :) Там "в начало" ничего не вставить. Работа "задними числами" не ведется.

Вероятно для программеров обходы есть с пересчетами, но я настолько глубоко копал. Чуть выше я писал, что потратил несколько месяцев, но цель была не изучить технические тонкости. И даже не весь функционал. Задачей было определить будут ли достигнуты конкретные цели проекта внедрения. Увы, я оказался прав - ни единого шанса не было ни теоретически, ни практически.

как дела у буржуинов с Неопределено, NULL, пустыми ссылками?

(111)
>Там УРБД планируется. На навижине вообще непонятно как УРБД сделать.

Открою тебе маленький секрет: на Западе уже лет 10 (а то и все 15) никто не использует то, что 1С-ники так гордо называют "УРБД".

(115)а что на западе используют ? открой секрет плиз.
Какая там альтернатива УРБД ?

(115)Как там вообще распределенку делают ?

(116) Нет никакого секрета - тонкий клиент используют

ответил на высказывания, которые понял и которые, на мой взгляд, требуют комментариев

(7) > Навижен - окаменелое дерьмо мамонта.
Нет

(7) > Писать с нуля на  Навижен просто глупо.
Да

(8) > мне казалось что Навижен - старье... или нет?
нет

(11) > В навижн нет цветовой синтаксической разметки кода!!
есть.

(16) > маззи там доказывает, потому что когда ему начинают задавать вопросы по существу, а он не может ответить, он просто банит неудобных
Не бывает неправильных вопросов. Неправильными бывают только ответы
история бана demiurg на аксфоруме http://axforum.info/forums/showthread.php?t=27688

(21) > самый главный, нету исправлений задним числом.
нету. и слава богу.
однако есть ввод новых документов задним числом.
причем ввод новых документов задним числом делается правильно с сохранением истории изменения последующих документов

(29) > Процент плохих программистов в любых системах примерно одинаковый
Да

(29) > но с учетом общего количества программеров всяких сап и навижн - количество тех, кто сможет создать и внедрить эти системы приближается к нулю
нет

(34) > А в чем сильные стороны Навижн ? Ну хоть что то лучше чем в 1С должно же быть ???
> Итак доводы за 1С:
> 1. Кастомизация на порядок дешевле.
да.

(34) > 2. Поддержка дешевле.
нет. потому что дешевая кастомизация приводит к бОльшему количеству кастомного кода. А его нужно поддерживать

(34) > 3. Простая совместимость с 1С бухгалтерией.
:)

(34) > 4. Продвинутая среда разработки.
Нет.

(34) > 5. Появление новых версий и как следствие новые возможности для конф
:) http://www.microsoft.com/Rus/dynamics/nav/overview.mspx#Section2

(38) > Native движок этого зверя достаточно шустр. А вот SQL-вариант уже не столько.
Да. Тянут совместимость.
Со следующей версии останется только SQL-вариант. Его сильно оптимизируют под SQL

(42) > - функционал дерет 1С как тузик грелку
Да

(42) > - релизы не содержат детских ошибок
Ну... Есть конечно. Но не в таком количестве, конечно.

(42) > - скорость работы на порядок выше
Да

(42) > - и главное - нет перепроведения
О, да!

(44) > Разработка в Навижине возможна только с лицензией вендора.
Нет. Такое практикуется, если клиент хочет "сэкономить". Но лицензией это запрещено

(44) > В навижене грядёт смена платформы. Её бесшовная замена как ранее - не предвидится
Да, грядет. Да похоже будут затыки - разработчики решили таки отказаться от некоторых старых функций которые поддерживаются с 80х годов. Через 2-3 года будет полный переход на .net и отказ от native-базы в пользу SQL. О возможных проблемах все заинтересованные стороны предупреждаются в технических документах. Пока все старое поддерживается.

(48) >> - функционал дерет 1С как тузик грелку
> Крайне сомнительное утверждение. Применительно к УПП.
рвет-рвет. именно применительно к УПП.
про многозначность термина "1С" - в курсе. http://axforum.info/forums/showthread.php?p=214328#post214328

(48) >> - релизы не содержат детских ошибок
> Действительно бывают они настолько редко, что сложно допустить ошибку
:) И виноград зелен...

(48) >> - и главное - нет перепроведения
> Многие корректировки просто задолбаешься проводить.
Самое интересное, что 1Сники когда слышат об отсутствии перепроведения тут же говорят о корректировках.
А на самом деле там совершенно другая идеология: ПЕРЕД проведением стоит куча проверок.
Мало того, такие проверки можно и нужно добавлять как настройкой, так и программированием.
Там просто другая идеология.

А "незаменимые", которые вместо добавления проверок в документ повышают свое ЧСВ... да, такие случаи бывают

(48) > Кроме того какая религия запрещает запретить правки задними числами в том же УПП?
В том то и дело, что никто не запрещает.
И правят задним числом в УПП.
только итоги от этого разъезжаются и становится непонятно почему люди действовали так, а не иначе... :)

(50) > А вы уверены, что прочитанное Вами высказывание было сделано после выхода 8.2 ? ЗЫ Мази давно уже ушёл от разработки в 1С.
Ушел. Давно. Высказывание было сделано после выхода 8.2

(56) > Почитайте внимательно, о чём именно там пишет Мази. В 1С это надо кодить
Да, спасибо. Именно это и имел в виду.

(58) > Мази - типичный недокодер 1С, неосиливший и ушедший в (как он сам говорит) "игрушечные примеры"
Спасибо :)

(66) > но тогда минусы: куча кода - это верно - такое ощущение что , программист кодивший после когото - не исправлял ошибки в уже существующем коде , а дописывал сбоку свой обходя в какомто конкретном случае какуюто конкретную ошибку
:)

(66) > - отчеты ваять - геморрой - на отчет ... на который в 1С уходит 30 минут . в навике действитенльно его можно делать 3 дня плюсы :
Дело в том, что в Навике есть отчеты (они только печатаются) и есть статистические/матричные/запросные формы.
А в 1Се есть только отчеты.
Пользователям все равно как будет реализовано - они хотят видеть цифры, выполнять анали.
Но по привычке называют то, что хотят отчетами.
Внедренцы Навика - зачастую бывшие 1Сники - просто юзают объект "Отчет" вместо того, чтобы предоставить пользователям инструмент для анализа данных. В стандартном Навижине инструмент для анализа - в подавляющем числе случаев - запросные формы.

Проблема как всегда в том, что кто-то не читает инструкции и не читает гайды по системе :)

(66) > плюсы:
да, согласен.

(69) > >> - релизы не содержат детских ошибок
> Угу, и выходят раз в 5 лет.
Конечно же нет.
Новые версии и то чаще выходят :)

(70) > "FlowField поля - это очень сильно и в 1С это вряд ли когда будет " вкраце, что это?
http://msdn.microsoft.com/en-us/library/dd338766.aspx
Вкратце: поле, по которому задана формула расчета. промежуточные итоги хранятся в базе.
в результате можно получить итоги по всем значениям или по отфильтрованным значениям.
в качестве абсолютно естественного для всех навижиновцев бонуса - FlowField "объясняет" как образовалось данное значение.
Навижиновцы считают эту фичу настолько естественной и обязательной, что редко говорят об этом.
Но именно возможность автоматического Drill-Down вводит в ступор программистов других систем (включая и Аксапту)
http://axforum.info/forums/showthread.php?p=237681#post237681

(72) > Вычисляемые поля, как яндекс сказал.
:)

(74) > А что, в 1С нет вычисляемых полей?
:D

(75) > в 8.2 динамические списки кажут
:LOL:

(77) > Но больше всего вымораживает политика лицензирования. Т.е. лицензия требуется на каждый заблудившийся "ИК", буквально.
Да. Но сейчас майкрософт двигается в сторону изменения http://www.microsoft.com/Rus/dynamics/nav2009/promo/index.html

(77) > Про девелоперскую лицензию вообще молчу.
:)

(77) > Про красивые разноцветные отчеты - забудьте, отчеты с расшифровкой - тем паче
Потому что в Навижине надо делать красивые отчетные формы.
http://navision.mazzy.ru/screenshots/common/
Особенно матричные формы
http://www.navision.mazzy.ru/lib/nav2009-matrix-form/

(77) > Механизм аналитических отчетов весьма силен, а вот печатные формы - жуткий ужас, редактировать их невозможно.
Да.

(77) > В принципе, основные минусы НАВа упираются в интерфейс. Сюда же добавлю отсутствие нормального дебаггера.
это про старые версии. там - да.
в последних - очень даже симпатишно

(78) > Добавлю, что обмен данными с НАВ очень просто реализовать SQL-ными запросами напрямую из таблиц. Писать туда теми же запросами не рекомендуется))
да. но помните о совместимости и об апгрейдах.
прямые запросы очень мощный инструмент, но и опасный. как прямая правка в реестре виндов.

(83) > общем, чтобы флейм не раздувать - отчеты в НАВ отвратительно вырвиглазные.
:D
Типичное мнение типичного 1Сника, которого пользователи просят сделать "отчеты" в Наве.
В Наве данные для анализа готовятся другими инструментами.
То, что в Навике называется "Отчет" предназначено только для печати :)

(87) > При таком подходе не будет тонкого клиента.
Есть же :)

(88) > В Навижене есть два справочника Поставщики и Покупатели, которые заполняются независимо друг от друга.
Конечно. И заполняются независимо, и параметры по умолчанию у них разные, и права у них можно установить разные (продавец может и не видеть договоры и параметры этого же контрагента, но в ипостаси поставщик). В общем, появляется куча возможностей

(88) > В 1С есть один -- Контрагенты.
О, да. И параметры в этом справочнике - тоже одни. На все случаи жизни :)

(88) > Соответственно отчет по контрагенту, который является и поставщиком и контрагентом в 1С сделать можно и выявить должны мы или нет.
Конечно же нет. у каждого клиента есть ссылка на поставщика. У каждого поставщика есть ссылка на клиента. Эти поля контролируются стандартным функционалом. Но права на эту ссылку выдаются далеко не всем рядовым пользователям.
Есть стандартные отчеты отчеты, которые выводят "и поставщиком, и клиентом".
Вы наверное просто пропустили этот момент :)

(101) > ты на форуме навижн бы эту тему поднял
Да. Было бы неплохо. http://forum.mazzy.ru

(102) > вот "против навижн" могу рассказать следующее. ... Так вот выяснилось, что внедренцы плохо знают как бизнес-логику вообще, так и бухучёт в частности.
:LOL:
:LOL: :LOL:
спасибо. меня очень впечатлила ваша логика :)

(111) > Там УРБД планируется.
Ни в коем случае!
Разработчики считают, что организовать постоянный канал к единой базе данных гораздо дешевле и надежнее, нежели заниматься администрированием конфликтов репликации и вводить двухуровневую фиксацию транзакций

(114) > как дела у буржуинов с Неопределено, NULL, пустыми ссылками?
NULL (в смысле MS SQL) - не используется
есть свой NULL, его и юзают.
Из соображений совместимости это не будут менять даже в течение двух следующих версий (в течение 5-6 лет)
обсуждения вопроса ведутся. Но окончательное решение будет принято только после выхода следующей версии, в которой останется только MS SQL

(115) > Западе уже лет 10 (а то и все 15) никто не использует то, что 1С-ники так гордо называют "УРБД".
агась :)
просто разработчики 1С в своем УРБД замели под коврик вопросы конфликтов репликации :)

(118)А как быть там, где инета нет даже для тонкого клиента ? Там, куда данные можно только на олене отвезти ? И база нужна не вся, а только для этого бизнесс-узла...

(119) чем NULL там отличается от SQL стандарта?

+(120) могу открыть тебе секрет, что в России есть такие места - у меня таких узлов будет 4.

Реальная альтернатива - это то, что в нотации 8.2 называется тонким клиентом на вэб-интерфейсе. И отдельный дата-центр где-нибудь в столице с хорошим таким каналом. По крайней мере в OeBS-е было именно так.

(123) к (116)

... и покеру было всем на возражения типа "интернет упадет и приплыли". делайте надежный канал, дублируйте.

(125) чушь полная

(120) а для таких мест есть датапорты.
датапорты реализуют интерфейсные API и (в некотором смысле) транспортный уровень.
но датапорты не содержат стандартную бизнес-логику по валидации данных, по решению конфликтов репликации.

поэтому использовать датапорты для прямой загрузки/выгрузки бизнес-данных (документов/справочников/проводок(!)) - будет крайне неразумно не создавая бизнес-логику по валидации и решению конфликтов репликации.

(119) на (112) не ответил.
Новый документ в заднем числе ввести в Навижен можно!
Так, что этот SIFT должен переколбасить всю базу?

(121) > чем NULL там отличается от SQL стандарта?
в базе хранится не NULL, а некое значение, которое самим Навижином трактуется как NULL.
соответственно нет ограничений, связанным с появлением субдшного NULL в результатах запросов.

(123) агась.

(129) тоже велосипедостроители

(129) это ж неопределено!

<<<<<<<<<<<
Вкратце: поле, по которому задана формула расчета. промежуточные итоги хранятся в базе.
в результате можно получить итоги по всем значениям или по отфильтрованным значениям.
в качестве абсолютно естественного для всех навижиновцев бонуса - FlowField "объясняет" как образовалось данное значение.
Навижиновцы считают эту фичу настолько естественной и обязательной, что редко говорят об этом.
Но именно возможность автоматического Drill-Down вводит в ступор программистов других систем (включая и Аксапту)
>>>>>>>>>>>

так или иначе в навижен ВРУЧНУЮ забивается формула (пародия на SQL-запрос) по расшифровке "автоматического Drill-Down"!
В 1С7.7 такое уже было в ОСВ, называлась расшифровка.
Да, в СКД нужно писать запрос для расшифровки, причем более сложный, чем формула в навижен для "автоматического Drill-Down" :)

Очень даже странно, что на стороне Навижн только один единственный Робин Гуд, которого отличает от всех остальных недюжинный интеллект и сверхработоспособность.
В общем, этот интеллектуальный крокодил Навижн исключительно для упертых супермозгов...
Умрет mazzy - умрет Навиж в РФ...

(128) > Так, что этот SIFT должен переколбасить всю базу?
я же ссылку на MSDN привел
http://msdn.microsoft.com/en-us/library/dd338766.aspx

краткий ответ:
нет, не будет переколбашивать. SIFT хранит не остатки, а разницу между "соседними" остатками.

полный ответ:
нет, "ВСЮ базу" переколбашивать не будет.
Однако можно найти такие случаи и можно сделать такие настройки, которые приведут к появлению зависимых значений в SIFT-полях. Тогда Нав будут переколбашивать "зависимые".

В этом и состоит умение внедренца - так скомпоновать настройки SIFT-полей, чтобы получить максимум информации при минимуме зависимостей.

Кстати, именно в этом направлении двигается ядро Навижина. Тут были и удачи, и промахи (в этой ветке упоминалось, что Native-база "хорошо", а SQL-база - "плохо". В одной из версий разработчики исходили из явно неверных предположений относительно использования SIFT. Теперь вроде исправились)

нашел книгу
http://book.axforum.info/morphx.pdf

(127)Сколько времени уйдет на написание нормальной репликации данных на навижн ? Скажем обычная торговля. На 1С 8.1 у меня йдет примерно 2-3 дня.

(131) > тоже велосипедостроители
агась. только этот велосипед с 1991 года.
с тех пор тянут совместимость
http://www.microsoft.com/Rus/dynamics/nav/overview.mspx#Section2

(132) не понял. если это важно, раскройте свое утверждение

(133) как скажете :)

(134) спасибо :D
с остальными крокодилами имеет смысл познакомиться в их естественной среде обитания http://forum.mazzy.ru

<<<
SIFT хранит не остатки, а разницу между "соседними" остатками.
>>>

В таком случае (112) все равно при изменении задним числом навижен будет переколбашивать всю базу, п опринципу сортировки методом "Пузырька", та как храниться разница между соседними остатками, и в итоге все они будут не верны.

(126) поясни, коли заикнулся.

(138) Нет, спасибо. Я их к своей мелкой вотчине не подпущу и сам в чужую соваться не буду.
:)))

(119) "Разработчики считают, что организовать постоянный канал к единой базе данных гораздо дешевле и надежнее, нежели заниматься администрированием конфликтов репликации и вводить двухуровневую фиксацию транзакций"

Просто 1С-овская платформа совсем недавно приобрела механизмы, позволяющие строить подобную логику. Количество РИБ-вских баз, со временем конечно, должно постепенно уменьшатся.

(119) +500

(136) это книга по Аксапте, а не по Навижину
о разнице между двумя этими системами см. хрестоматийную статью
http://axapta.mazzy.ru/lib/names/

(137) > Сколько времени уйдет на написание нормальной репликации данных на навижн ? Скажем обычная торговля. На 1С 8.1 у меня йдет примерно 2-3 дня.
ЗАЧЕМ?????!!!!
Упаси бог делать НОРМАЛЬНУЮ репликацию. Очень много и очень долго.

Упаси бог называть вас инструмент обмена данными в 1С - нормальной репликацией. Это даже не репликация. Это всего лишь обмен данными с подтверждениями о приеме (тикетами).

===============
Черт, в очередной раз объясняю разницу между НОРМАЛЬНОЙ РЕПЛИКАЦИЕЙ и обменом из 1С.

Есть ЦБ, Б1, Б2 (центральная база, база 1, база 2)
предположим, что во всех номенклатура и остатки на складах уже синхронизированы.
Предположим, что на Склад1 хранится 10 шт остродефицитного товара.
Предположим, что менеджеры продаж одновременно продают по 6шт этого товара с одного склада (из центральной базы).

Что произойдет в 1С?
1. Будет создан документ продажи в Б1, 6шт (пройдет резервирование, документ будет проведен, счет выписан, клиент1 может даже выполнить оплату)
2. Будет создан документ продажи в Б2, 6шт (пройдет резервирование, документ будет проведен, счет выписан, клиент2 может даже выполнить оплату)
3. происходит обмен данными с ЦБ.
результат обмена - непредсказуем. Один из документов не будет проведен. Какой именно зависит от массы внешних условий. Но клиенты - оплатили! Резервирование было выполнено!!!!

Что произойдет в нормальной системе репликации
1. Будут созданы документы с промежуточным состоянием - резервирование не подтверждено
2. Менеджерам по продажам будет виден статус, что их резервирование под вопросом. Они соответствующим образом могут информировать клиентов и снять массу нареканий просто объяснив клиенту ЗАРАНЕЕ, что происходит
3. один из документов будт отклонен или частично зарезервирован(порядок проведения, порядок отклонения, порядок частичного резервирования управляется бизнес-логикой!!!!)
4. при следующем сеансе обмена менеджеры получат информацию и смогут допровести документы.

Другими словами, в нормальных (!) системах репликации (!) должна быть предусмотрена двухфазная фиксация транзакций
wiki:Транзакция
http://khpi-iip.mipk.kharkiv.edu/library/extent/ii/itci/02.html
http://itday.kg/main/265-dvukhfaznaja-fiksacija.html

Кроме того, в нормальных (!) системах репликации (!) должна быть встроена бизнес-логика, нормально работающая с промежуточными (недофиксированными) транзакциями на ЛОГИЧЕСКОМ уровне.

==============
То, что вы называете "нормальной системой репликации" - это всего лишь транспортный уровень :)
Транспортный уровень в таком же объеме на навике - также вопрос нескольких дней.

Вопрос: ЗАЧЕМ?!

(139) :D
Нет. См. доку

О блин... Интересная дискуссия... В закладки.

вот еще хорошее про "Двухфазную фиксацию транзакций"
http://msdn.microsoft.com/ru-ru/library/ee914374.aspx

(119)
"> Там УРБД планируется.
Ни в коем случае!
Разработчики считают, что организовать постоянный канал к единой базе данных гораздо дешевле и надежнее, нежели заниматься администрированием конфликтов репликации и вводить двухуровневую фиксацию транзакций "

Мда, разработчики плохо представляют себе реалии телекоммуникационного рынка даже относительно ближнего Подмосковья, не говоря уже о России в целом.

(144) О разнице имён прочитал. Но я так понял, что эти две системы по сути дублируют друг друга своим функционалом?

"нет, не будет переколбашивать. SIFT хранит не остатки, а разницу между "соседними" остатками"

Собственно, разница между "соседними" остатками как бы и есть числовой показатель движения. Зачем его еще раз хранить?
И вообще такую дребедень с остатками в движении на Клипере писал в лохматом году.

Вах, хорошо, что в 2001 я не согласился ковырять навижн.

(144)
Ну да, в прикладных конфигурациях 1С нет репликаций.
Но это на уровне бизнес-логики, когда-нибудь напишут.

Только у нас предприятий таких мало, чтобы разработка 1С окупилась.

А остальных устраивает бухгалтерская архитектура конфигураций 1С.

(144) Так с УРБД в 1С обычно никто не работает. Не, платформа, конечно, позволяет и так делать, платформа 1С вообще много вольностей позволяет, но предполагается, что внедрецы всё же еще и мозгом думать будут.

(149) > эти две системы по сути дублируют друг друга своим функционалом?
Да. На самом деле их в во всем мире 4 :)
В россии представлены 2.

Разведение в разные маркетинговые ниши достаточно искусственное (сугу мое личное мнение, возможно отличающееся от точки зрения самого Майкрософта).

Майкрософт делал и делает несколько заходов к объединению этих продуктов в один. Главный вопрос - совместимость.
Чтобы тянуть совместимость эти продукты живут, развиваются вместе и имеют достаточно далекие планы как отдельные продукты.

Но Майкрософт делает ряд совершенно конкретных и очень долгосрочных шагов, чтобы таки беспроблемно объединить эти продукты в один. Если грубо: в этих продуктах доработан функционал до полного неразличения самими клиентами (если раньше можно было сказать, здесь есть то, а здесь другое, то теперь клиентам все равно какую Майкрософтовскую систему выбирать). Теперь Майксрофот очень осторожно и несколькими шагами переводит средства разработки на .net и Visual Studio. При этом ключевой вопрос - вопрос совместимости. Как уже говорилось выше - вопрос исключения нескольких функций (которые тянутся с 90х годов) приобретает вселенский масштаб - партнеры и клиенты специально готовятся к этому, Майкрософт не забывает об этом напомнить каждый раз - готовьтесь, это будет в через уже 2 года.

(мое личное мнение, возможно не совпадающее с Майкрософтовским) мне кажется, что Майкрсофот хочет довести до состояния, когда и программистам все равно какую систему программировать (они все на VS, все на .net, все с OLAP, все единым движком отчетов - Reporting Service). вот тогда и снова поднимется вопрос об объединении систем в одну Microsoft Dynamics (без суффиксов NAV, AX, CRM и т.п.)

(152) а мне нравится эволюция: :D

Было:
(137) Сколько времени уйдет на написание нормальной репликации данных на навижн ? Скажем обычная торговля. На 1С 8.1 у меня йдет примерно 2-3 дня.

Стало:
(152) Так с УРБД в 1С обычно никто не работает. Не, платформа, конечно, позволяет и так делать, платформа 1С вообще много вольностей позволяет, но предполагается, что внедрецы всё же еще и мозгом думать будут.

(144) Так-так-так... И сколько стоит эта твоя супер-пупер репликация?!
Кста, в 1С можно действовать и по-другому.
Хотя и в нарисованной тобой схеме в навижн не исключена драка за товар.

(153) А где можно почитать про различия Navision и Axapta на функциональном уровне? Вот эту ссылку через гугль нашёл http://forum.mazzy.ru/index.php?showtopic=9553
Но там про разницу между торговыми марками. Язык программирования у них один (MorphD или X)?

(154) "УРБД в 1С обычно никто не работает" - зря ты так...

(145) Есть документация на русском?

(154).2 А я, кстати, не имел в виду написание. Проблема описанную в (144) можно решить без строчки кода, настройкой прав и регламента работы.

(155) > И сколько стоит эта твоя супер-пупер репликация?!
Моя? Или таки 1Совская?

в (119) я же писал:
> Разработчики [NAV] считают, что организовать постоянный канал к единой базе данных гораздо дешевле и надежнее, нежели заниматься администрированием конфликтов репликации и вводить двухуровневую фиксацию транзакций

В том то и дело, я считаю - не надо делать такую супер-пупер репликацию. Надо организовать доступ к единой базе.

==============
Старческие воспоминание и брюзжание....
Я видел "супер-пупер репликацию" на Аксапте с попыткой полностью переписать стандартный функционал, с попыткой ввести двухфазную фиксацию транзакций... Начиналась эта попытка в далеком 2001 (удаленный склад был в подмосковье на одной шумящей телефонной линии). Уже в 2005 провели туда даже резервный канал... И филиалы по россии давно работают при помощи тонкого клиента... Но до сих пор пишут - а вдруг связь пропадет?. Такие дела...

+(157) http://yandex.ru/yandsearch?text=Использование+УРБД+в+1С&lr=213
20 тыс...
Это говорит о массовости использования УРБД в 1С?

(160) Это мания такая - единственность базы?!
Я работаю с 200 базами. Если бы не 1С, я бы не справился.

(157)(161) Перечитай еще раз моё высказывание. Внимательно, не пропуская отдельные слова, даже если они очень короткие.

(155) > Хотя и в нарисованной тобой схеме в навижн не исключена драка за товар.
Возможна. Но "драка" будет в рамках одной транзакции и в одной базе.
А это несколько другой случай :)

(158) > Есть документация на русском?
Возможно я неправильно понял вопрос. Это?
http://www.microsoft.com/Rus/dynamics/nav/useful.mspx
http://forum.mazzy.ru/index.php?showtopic=21

(159) > А я, кстати, не имел в виду написание. Проблема описанную в (144) можно решить без строчки кода, настройкой прав и регламента работы.
Как скажете. ;)

Извините.
Разрешите откланятся и поехать к клиенту.
Вечером еще зайду и постараюсь ответить на вопросы, если таковые будут.

забавное здесь автоформатирование ;)

(165) На прощание небольшой камушек в огород? )

(144) Простите, но исходя из моего скромного опыта, описанная Вами ситуация решается очень просто. В 1с в УРБД каждая база установлена для определенного места хранения. Поэтому, прежде чем продавать товар с другого склада любой менеджер должен убедится о его наличии на другом складе. Принципиальная разница Вашей "двухуровневой фиксации транзакций", как я понял предусматривает лишь, что менеджер будет видеть что его товар может уйти а может и не уйти. Но клиенту пофиг как-то на то, как устроен обмен в ИС предприятия - он хочет купить товар.

(144) Нда... Навижнист думает что сделал открытие, а каждый вменяемый одинэсник знает, что его за такой механизм убьют.

Вот и все отличие.

(144). Т.е. у вас менеджер, сидящий во Владивостоке продает товар со склада в Питере, проводя это во Владиковской базе? Оригинально.
УРБД конечно же придумывалась не для таких задач...

(167) +1

(144) обычно это разруливается правами - каждый работает в своей базе СО СВОИМ СКЛАДОМ. В центр стекается информация для анализа этих продаж со всех складов.

(По поводу УРБД)
А теперь представим ситуацию - сидит центральная контора в Москве и куча подразделений в Мухосрансках.
Каждое подразделение торгует со своего оперативного склада, имеет собственные банковские счета и т.д. Перемещение делается из центра, номенклатура создаётся в центре и т.д.
Т.е. коллизий практически не предвидится.

При этом интернет дают 3 раза в день по чайной ложке.

В этом случае УРБД ой как помогает. А какой бы тонкий клиент не был - он будет очень глубоко в Ж.

ИМХО таких контор предостаточно.

<<<
Возможно я неправильно понял вопрос. Это?
http://www.microsoft.com/Rus/dynamics/nav/useful.mspx
http://forum.mazzy.ru/index.php?showtopic=21
>>>

(164)
А про то, как работает SIFT, есть на русском?

(164)
Mazzy, если не сложно скинь документацию по то, как работает SIFT, есть есть на русском?
nav50 гав rambler.ru

(171) правами это разруливается не всегда, и не всегда каждый работает со свом складом , простой пример:
у нас сеть розничных магазинов(быт.техника) - есть центр.база, есть магазин А и магазин Б (все это распределенка) в магазин А пришел клиент и выбрал товар который был в ед числе в магазине, но он например оказался с дефектом, такой же товар - есть магазине Б ,отправлять клиента в магазин Б чтобы он купил товар там - можно, но... клиент может туда недойти..., пока он туда идет товар также могут продать... и еще много но... по которым нужно продавать в одной базе из остатков другого магазина

(175) В таком случае менеджер звонит в магазин Б и уточняет о наличии товара.

(176) В таком случае, менеджер делает перемещение товара на свой опер. склад, делает обмен с центром, в центральной базе его проводят (или не проводят), снова делают обмен, после чего он может этот товар продать. Так правильно ;-)

о чем спор - то ) Как сказал один мой знакомый, торговавший биодобавками - Это нельзя есть, это надо продавать )

(163) Ага!

(176) Нет. Конфликт решается исключительно средствами навижн.
:)))

(177) А смысл, если этот товар уже продали? Сначала позвонил, а потом уже и перемещение и обмен. Клиенту так долго ждать не будет. Что бы получить ответ.
(180) Ага. Клиенту рассказывают о устройстве "двухуровневой фиксации транзакций" и просят покурить пару часиков.

(181) Смысл в том, чтобы одновременно не позвонили и не продали в другом филиале.

(181) Лучше попросить покурить, чем продать двум клиентам один товар.

(182) Ну вообще то для того и звонят - что бы не только узнать есть ли товар в наличии, но и что бы его зарезервировали. Я так ноут покупал - в одном магазине продали, а забирал с другого. Менеджер просто позвонил в другой магазин и там товар зарезервировали. А если бы я ждал пока сделают обмен и прочую лабуду, то мог пойти в магазин напротив за это время и купить товар у конкурентов.

сейчас почти так и работает как в (176) - по звонку откладывают товар ,с одновременным созданием заявки на резерв в магазине А, которая после попадания в магазин Б пытается зарезервировать товар, т.к. вариант с перемещением не прокатил(менеджера может не быть на месте), вариант - чтобы резерв сделали работники магазина Б - тоже работает не всегда , так как с этой продажи они все равно ничего не получат - а зачем в этом случае делать лишнюю работу...
но в любом случае иногда случаются  коллизии с клиентами...

(184), (185) Вы своими звонками всё величие навижн растаптываете в грязь!

(162) > Я работаю с 200 базами. Если бы не 1С, я бы не справился.
на 1С только так и можно справится (особенно на 7ке)

(167) > В 1с в УРБД каждая база установлена для определенного места хранения.
Да, вот такие вот административные ограничения в "нормальной репликации" от 1С :)

(169) > обычно это разруливается правами - каждый работает в своей базе СО СВОИМ СКЛАДОМ
я знаю как разруливаются в УРБД. Я же рассказывал про нормальную репликацию.

я правильно понимаю, что вы согласны, что систему с подобными ограничениями называют "нормальной репликацией"? ;)
Систему в которой нельзя сделать общий дистрибуционный склад.
ну-ну...

==============
я, кстати, только сейчас обратил внимание.
в (137) меня спросили о "нормальной репликации".
в (144) я объяснил что понимаю под нормальной репликацией
в (155) мою нормальную репликацию назвали "супер-пупер" :)
прикольно.
==============

(172) > А теперь представим ситуацию
а теперь вспомните что было пару лет назад и какая ситуация сейчас с каналами.
чем дальше, тем дешевле будет один раз организовать канал :)
впрочем, как скажете

(172) > А про то, как работает SIFT, есть на русском?
А... вот про что... Понятия не имею. Никогда не задавался таким вопросом.
А почему именно на русском?
Поищите.
Например, http://forum.mazzy.ru/index.php?showtopic=10680
http://naviart.ru/sift


а в остальном, прекрасная маркиза, MSDN, MSDN
http://msdn.microsoft.com/en-us/library/dd355344.aspx

Немного не по теме, но что-то близко:
Вакансия в Оренбурге:
Ведущий программист  19000 рублей
Требования: —высшее профильное образование
Обязанности: администрирование и конфигурирование 1 С Предприятие с дальнейшим переходом c 1 C на систему Axsapta

(187) Не-е-е-е... Иди ты сам в мсдн...

А бывают фрилансеры навижиновцы?)

(144) это уже штатно сделано во всех решениях навижн механизмами платформы ?

(0)
Скорость и удобство разработки.
Ключевой момент при внедрении.

Ситуация.
Все сделели согласно ТЗ, обкатали на юзерах. Вроде все ок.

Полномаштабный запуск.  
Начинает лезть всякая мелочь, которую юзеры при постановке задачи проглядели. Ошибки разработчиков - на 1005 все не протестируешь, очень дорого.
И все это щастье мешает оперативной работе.

Каждый час промеделения в реализации критичных хотелок или исправлении ошибок на начальном этапе внедрения - шаг к провалу всего проекта.

А то что у НАВ есть готовый функционал -это хорошо но ни о чем, так как даже при детальном проектировании нет 100 уверенности что учтена вся специфика бизнеса.

Универсальность гибкость илегкость в доработке - это настоящая "серебряная пуля" при внедрении.

Дополнительно.
Ресуры для поддержки и доработки не то что дороги, это как раз таки меньшая проблема. Их просто физически меньше и аналитиков и прогов и консультантов.

Заказчик имеет очень большой шанс не получить свою ложку к обеду ни за какие деньги.

(187)
по ссылке:
>>>
А теперь о главном. Каждый добавляемый вами в Navision ключ с привязанным полем для пересчета – увеличивает базу и замедляет процедуры вставки/измененения/удаления записей. Ведь агрегатные показатели пересчитываются для всех комбинаций полей, входящих в ключ. Я видел таблицы с 20 ключами, на 8 из которых висели сифты… Простая вставка занимала около 10 секунд
<<<

Что пишет Мазуркин Сергей

>>>
краткий ответ:
нет, не будет переколбашивать. SIFT хранит не остатки, а разницу между "соседними" остатками.
<<<

Так, кому верить?
Ничем принципиально этот SIFT не отличается от агрегации данных в оборотных регистрах в 8.2 НИЧЕМ!

Если кто утверждает обратное, пусть приведет пример работы SIFT в примере, когда новый документ вводится в начало базы и всю историю итогов при этом не пересчитывает!

ссылка по SIFT
http://naviart.ru/sift

В последней версии навижена 2009 SIFT реализован с помощью  Indexed View, появившийся, ещё в SQL 2000!

Что вызвало у многих навиженцев WOW-эффект! :)

(190) > А бывают фрилансеры навижиновцы?)
Да, конечно.

(191) > это уже штатно сделано во всех решениях навижн механизмами платформы ?
начинаю сомневаться в адвекватности. прежде всего в своей.
я же писал в (119)

> (111) > Там УРБД планируется.
> Ни в коем случае!
> Разработчики считают, что организовать постоянный канал к единой базе данных гораздо дешевле и надежнее, нежели заниматься администрированием конфликтов репликации и вводить двухуровневую фиксацию транзакций

нет, "это" не сделано. и не будет. потому что!

(192) > А то что у НАВ есть готовый функционал -это хорошо но ни о чем, так как даже при детальном проектировании нет 100 уверенности что учтена вся специфика бизнеса.
Угу, угу. Зелен виноград.
Но сам пример логики - хоть в хрестоматию вставляй.

Я правильно понимаю, что поскольку при детальном проектировании нет 100 уверенности, то готовый функционал вообще не нужен? ;)

(192) > Универсальность гибкость илегкость в доработке - это настоящая "серебряная пуля" при внедрении.
Точно. Прямо про НАВ сказано

(193) > Ничем принципиально этот SIFT не отличается от агрегации данных в оборотных регистрах в 8.2 НИЧЕМ!
Сомнения в адекватности усиливаются.

Я же говорил вот здесь в (119)
> в качестве абсолютно естественного для всех навижиновцев бонуса - FlowField "объясняет" как образовалось данное значение.
> Навижиновцы считают эту фичу настолько естественной и обязательной, что редко говорят об этом.
> Но именно возможность автоматического Drill-Down вводит в ступор программистов других систем (включая и Аксапту)
http://axforum.info/forums/showthread.php?p=237681#post237681

(195) > В последней версии навижена 2009 SIFT реализован с помощью  Indexed View
во-первых, не в последней
во-вторых, WOW эффект вызван не техническим фактом использования инструмента, а тем, что Майкрософт таки отказалась от мультиплатформенности и начала использовать инструменты конкретной реализации SQL. Мало того, оглушительный WOW-эффект в узких кругах вызвало заявление Майкрософта о том, что в следующей версии будет использоваться ТОЛЬКО ms sql.
в-третьих, вы конечно же легко назовете места в любимой 1С, где используются Indexed View, которые появились в далеком SQL 2000 :D

(187) Простите, а это по Вашему нормальная система репликации?:
"то произойдет в нормальной системе репликации
1. Будут созданы документы с промежуточным состоянием - резервирование не подтверждено
2. Менеджерам по продажам будет виден статус, что их резервирование под вопросом. Они соответствующим образом могут информировать клиентов и снять массу нареканий просто объяснив клиенту ЗАРАНЕЕ, что происходит
3. один из документов будт отклонен или частично зарезервирован(порядок проведения, порядок отклонения, порядок частичного резервирования управляется бизнес-логикой!!!!)
4. при следующем сеансе обмена менеджеры получат информацию и смогут допровести документы. "
Вы считаете, что это правильный режим работы для дистрибьюторского склада?

+(198)К слову - описанный Вами вариант легко делается и в 1с. Но он не решает проблемы. Менеджер продает товар здесь и сейчас, а не во время следующего сеанса обмена

(198) Никакая навижн (даже заточенная mazzy) не решает проблему, которую сам mazzy и привел в пример, как решаемую с помощью навижн.

(200)+100500
Я не видел навижн и не могу дискутировать что лучше. Более того, считаю дискуссию подобного рода бессмысленной - любой программный продукт имеет свои преимущества и недостатки.
Просто возмутил подобный довод против урбд.

(197) "Ничем принципиально этот SIFT не отличается от агрегации данных в оборотных регистрах в 8.2 НИЧЕМ! "

кроме

"в качестве абсолютно естественного для всех навижиновцев бонуса - FlowField "объясняет" как образовалось данное значение. "

Я не об этом!
http://naviart.ru/sift
1) Я имел ввиду реализацию SIFT - это просто агрегация!
2) Как ваш ответ по поводу SIFT
>>>
нет, не будет переколбашивать. SIFT хранит не остатки, а разницу между "соседними" остатками.
<<<<

согласуется с этим мнением по ссылке

>>>
А теперь о главном. Каждый добавляемый вами в Navision ключ с привязанным полем для пересчета – увеличивает базу и замедляет процедуры вставки/измененения/удаления записей. Ведь агрегатные показатели пересчитываются для всех комбинаций полей, входящих в ключ. Я видел таблицы с 20 ключами, на 8 из которых висели сифты… Простая вставка занимала около 10 секунд
<<<

Сережа, вы как то проигнорировали саму соль вопроса!

(198) > это по Вашему нормальная система репликации?
Да. Это нормальная система РЕПЛИКАЦИИ.
повторяю ключевое слово для самостоятельного поиска "двухфазная фиксация транзакции"
повторяю ссылку, которую я уже приводил http://msdn.microsoft.com/ru-ru/library/ee914374.aspx

(199) > описанный Вами вариант легко делается и в 1с
Шутку юмора - оценил. Спасибо.

(199) > Менеджер продает товар здесь и сейчас, а не во время следующего сеанса обмена
То, что вы считаете навязанный технологическими ограничениями УРБД режим обмена "раз в сутки" единственно возможным - ваши проблемы :)

Удивляет то, что 1Сники соглашаются с тем, что в УРБД (и в Обмене данными v8) реализована "НОРМАЛЬНАЯ репликация данных".
Когда я работал с 1С мы себе такого не позволяли...
Но времена меняются "и изменились вконец" (С)

=============
Кстати, я бы хотел обратить внимание как честно разработчики 1С изменили название механизма с УРБД (управление распределенными базами данных) в v7 на "Обмен данными" в v8.
http://v8.1c.ru/overview/Term_000000269.htm
И хотя термин "Распределенная информационная база" по-прежнему используют. Но уже оговаривают что под этим понимают
http://v8.1c.ru/overview/Term_000000315.htm
Хотя до сих пор "забывают" рассказать о конфликтах репликации :)
wiki:Репликация_(вычислительная_техника)

"в-третьих, вы конечно же легко назовете места в любимой 1С, где используются Indexed View, которые появились в далеком SQL 2000 :D"

Честно - не знаю! Но может кто знает и напишет!

так внятно кто то ответит про УРБД на вопрос в (191)?

просто ответить что то типа

"да это делается платформой"
или
"да это программный код который уже готов и вставляется во все решения"
или
"это были размышления на тему 'как нужно делать правильно' но где реализовано 100% в соответствии с размышлениями я не знаю"

(203)"описанный Вами вариант легко делается и в 1с
Шутку юмора - оценил. Спасибо. "
Шутка собственно в чем? Вы считаете невозможным в 1с добавить в заказ реквизит статус заявки? И так же после обмена обрабатывать?
"То, что вы считаете навязанный технологическими ограничениями УРБД режим обмена "раз в сутки" единственно возможным - ваши проблемы :) " - никто не говорит о разе в сутки. Но обмен в любой системе - это время. Вы когда нибудь видели как работают менеджеры в дистрибюции? По Вашей схеме Н менеджеров создают заявки на отгрузки покупателю и обмениваются после каждой?

(205) УРБД по ходу у них в принципе нет. Только одна база и тонкий клиент.

(200) ой, блин... ребяты...

я говорил, что аналога урбд НЕ БЫЛО, НЕТ и НЕ БУДЕТ в НАВИЖИН.
меня спросили каковы трудозатраты на создание НОРМАЛЬНОЙ репликации данных в Наве.
я ответил что понимаю под НОРМАЛЬНОЙ репликацией.
и отметил - что организовать постоянный канал связи - дешевле.

Если вы на основании этого утверждаете, что "которую сам mazzy и привел в пример, как решаемую с помощью навижн" - ваши проблемы.

(201) > Просто возмутил подобный довод против урбд.
:LOL: :LOL: :ROFL:
Ок. Как скажете.
Извините, что задел ваши чувства в отношении УРБД.

(202) > Ничем принципиально этот SIFT не отличается от агрегации данных в оборотных регистрах в 8.2 НИЧЕМ!
> Я имел ввиду реализацию SIFT
Стажер, вы логику знаете?
Вы понимаете разницу между общим утверждением (НИЧЕМ) и частным утверждением (имел в виду реализацию)?
Рекомендую почитать http://metasatanism.ru/Logic.html
http://fritzmorgen.livejournal.com/49306.html

Спасибо всем за содержательную дискуссию.

(208) я так и думал..

"ваша машина г.вно ибо я считаю что на ишаке ездить правильно и никогда никогда не сяду за руль"

ну ну...

(208) Цитата из (144)
"Есть ЦБ, Б1, Б2 (центральная база, база 1, база 2)
предположим, что во всех номенклатура и остатки на складах уже синхронизированы.
Предположим, что на Склад1 хранится 10 шт остродефицитного товара.
Предположим, что менеджеры продаж одновременно продают по 6шт этого товара с одного склада (из центральной базы)."
И далее ты говоришь, как с помощью навижн менеджер звонит клиенту и снимает все вопросы...
А я тебе говорю цитирую из (200)
"Никакая навижн (даже заточенная mazzy) не решает проблему, которую сам mazzy и привел в пример, как решаемую с помощью навижн."
Для тебя, уважаемый mazzy, говорию, что навижн, даже заточенная тобой не решает проблему.
Проблему решает менеджер простым и банальным способом, как ты и указал далее в (144) "снять массу нареканий просто объяснив клиенту".
А клиенту абсалютно пофиг ЗАРАНЕЕ ему отлуп дадут или ЗАГОДЯ и какие слова ему скажут.
Вот и вопрос, а где тут навижн?!

(208)mazzy, ты очень любишь козырять достоинствами навижен, и когда тебе впрямую задают вопрос про её недостатки - ты умалчиваешь, а когда тебя приперают прямым вопросом к стенке ты даешь ссылку на сайты типа (208)

(208) меня возмущает не Ваше отношение к УРБД))). Это Ваше мнение и я его уважаю. Но меня глупость примера поразила. Я так понимаю - приведенный Вами же пример для Вас остается нерешаемым. В том числе и средствами навижн.
"Спасибо всем за содержательную дискуссию." - к сожалению дискуссии не получилось. В ответ на вопросы, Вы отвечаете  - ":LOL: :LOL: :ROFL:". Я так понимаю у Вас просто нет аргументов, что бы основать отсутствие УРБД в навижн. Хотя, как показывают другие вопросы, отвечать на вопросы Вы в принципе не хотите или не в состоянии.

(208)
Итак, твой ответ
"нет, не будет переколбашивать. SIFT хранит не остатки, а разницу между "соседними" остатками."

противоречит этому -

"А теперь о главном. Каждый добавляемый вами в Navision ключ с привязанным полем для пересчета – увеличивает базу и замедляет процедуры вставки/измененения/удаления записей. Ведь агрегатные показатели пересчитываются для всех комбинаций полей, входящих в ключ. Я видел таблицы с 20 ключами, на 8 из которых висели сифты… Простая вставка занимала около 10 секунд"


Очень не хочется думать о том, что ты иногда дезинформируешь!
Хотя судя по тому, что ты уже пару раз игнорируешь...

в случае с (201) - можно сделать так: заказ в 1ске делается только в своей базе, в других базах (по складам других баз) делается через веб сервис. нет связи - по телефону, есть связь - конфликта с остатками нет, потому что заказ проводится одновременно и там и здесь. перебросить документ через веб сервис, провести его там и получить результат - я думаю, проблем у нормального программиста не вызовет.

а по поводу стабильности каналов и использования тонких клиентов - у нас много филиалов по россии, интернет далеко не везде безлимитный и работает без сбоев. схема с УРБД прекрасно себя чувствует в таких условиях

чукчи

+(216) в чуме

+(216) ждет

+(216) рассвета!
(208) Маззи, жду твоего ответа :)

ексель хоршооо, одинэс хорошооо, а навижен лууучшеееее )))

(220) Одно плохо, делает тоже самое, что и 1С, но дороже.
Но!
Внедрение медленнее,
изучение проблематично,
учителя падаванов шлют в мсдн,
и главное...
Столько сказок, столько замечательных сказок вокруг бренда!!
А сколько еще будет на мази!!

все, ждем на sql.ru рассказов о тупых одноэсниках...

Ндааа, из (203)
>>То, что вы считаете навязанный технологическими ограничениями УРБД режим обмена "раз в сутки" единственно возможным - ваши проблемы :)

это пять с плюсом!

Маззи как обычно, очередной раз явил миру свою исключительную пунктуальность. Если вопрос задан как бы не ему и как бы не по форме, то не отвечает. Может ответить ртфмом (тьфу, мсдном).

Ну и объяснил также, что навижн лучше. Чем что? Чем обычный порошок.

(224) "как бы не по форме" - а есть утвержденная форма вопроса у программистов навижн? или только у мази?)))

Мази любит конструктивный диалог, а тут диалоги в стиле конфигуратора. Вот он и пошел дальше любоваться на матричные формы.

"Мази любит конструктивный диалог"? Это шутка что ли? ему задают вопросы, а он на них не отвечает. Где конструктив?

У меня бы на форуме не получился такой диалог - много шума.
А вот за кружкой пива ... :)

(211) не вижу прямого вопроса. приведите пожалуйста

(212) > Я так понимаю - приведенный Вами же пример для Вас остается нерешаемым
неправильно понимаете.
но это ваше право.

(212) > Я так понимаю у Вас просто нет аргументов, что бы основать отсутствие УРБД в навижн.
как скажете (где тут смайлик "пожимает плечами")

(213) я не понимаю в чем противоречит

(214) > "можно сделать так"
ребяты... вы снова путаете "можно сделать" с "уже сделано".
я сколько раз об этом говорил несколько лет назад. и здесь, и на территории, и на sql.ru, и на аксфоруме
а сейчас просто лениво повторять эту песню в очередной раз.

еще раз обратите внимание: я ГОВОРИЛ о том, что УЖЕ СДЕЛАНО. о том, ЧТО УЖЕ ЕСТЬ.

(215) > УРБД прекрасно себя чувствует в таких условиях
поздравляю вас.
только я говорил совершенно о другом
цитирую (219):

> (111) > Там УРБД планируется.
> Ни в коем случае!
> Разработчики считают, что организовать постоянный канал к единой базе данных гораздо дешевле и надежнее, нежели заниматься администрированием конфликтов репликации и вводить двухуровневую фиксацию транзакций

(229) О! Не видите прямого вопроса? Хорошо. Тогда прямой вопрос: Вы считаете, что приведенный Вами пример двухуровневой фиксации транзакций не возможно решить средствами 1с?

(230) > Тогда прямой вопрос: Вы считаете, что приведенный Вами пример двухуровневой фиксации транзакций не возможно решить средствами 1с?
считаю, что возможно.
считаю, что переписывать УПП и другие типовые конфы под двухуровневую фиксацию транзакций в подавляющем большинстве случаев будет дороже, нежели организовать постоянный канал связи

пожалуйста, не заводите эту бодягу снова - решаются/не решаются.
можно реализовать/нельзя реализовать

лет 10 назад уже переобсуждали вопрос "решаются/нерешаются"
http://1c.mazzy.ru/articles/generation1c/#040

(197)
"> Универсальность гибкость илегкость в доработке - это настоящая "серебряная пуля" при внедрении.
Точно. Прямо про НАВ сказано
"

То есть скорость доработки отчетов  печатных форм в в НАВ на порядок  выше чем в 1С

- Это бред, если не сказать прямо п..ж

(233) > То есть скорость доработки отчетов  печатных форм в в НАВ на порядок  выше чем в 1С

никогда такого не утверждал.
тем более не утверждал "на порядок".

ссылку на учебник логики я уже приводил. приведу еще раз http://metasatanism.ru/Logic.html

(232) "считаю, что переписывать УПП и другие типовые конфы под двухуровневую фиксацию транзакций в подавляющем большинстве случаев будет дороже, нежели организовать постоянный канал связи" - Вы не поверите, но не всегда есть реальная возможность организовать постоянный канал связи.
Второй прямой вопрос: в чем преимущество описанной Вами двухуровневой фиксации транзакций от УРБД в 1с?

(231) ок, еще прямой вопрос: считаете ли Вы постоянный надежный канал связи и "двухуровневую фиксацию транзакций" (тм) единственными возможными решениями в описанном Вами случае продажи филиальным менеджером товара с центрального склада?

(235) > в чем преимущество описанной Вами двухуровневой фиксации транзакций от УРБД в 1с?
1.
В гарантированности результатов.
УРБД не гарантирует, что проведенные документы останутся проведенными после сеанса синхронизации.

2.
Двухуровневая фиксация транзакций теоретически позволяет вводить бизнес-логику для решения конфликтов репликации.
УРБД точно позволяет решать конфликты на самом примитивном уровне (центральный - побеждает, переферийная - побеждает)
"Обмен данными" в v8 уже позволяет вводить бизнес-логику для решения конфликтов репликации. Но в типовых конфигурациях никакой бизнес-логики нет, есть тот же примитивный уровень.

(236) конечно же я не считаю единственно возможными вариантами.

я говорил, что разработчики Навижина считают, что канал дешевле [в подавляющем большинстве случаев], поэтому они не делали, не делают и не будут делать аналогов УРБД.

лично я согласен с мнением, что канал дешевле в подавляющем большинстве случаев.

+(238) кроме того, каналы будут дешеветь в будущем.

(237)"УРБД не гарантирует, что проведенные документы останутся проведенными после сеанса синхронизации." - заблуждение. Документ будет проведен. Вопрос только в корректности остатков.
Какой результат гарантирует  двухуровневая фиксация транзакций ? В приведенном Вами примере менеджер не будет осведомлен о наличии товара на складе до следующего обмена. В чем гарантированость?

(240) > Вопрос только в корректности остатков.
:LOL:

(240) > В приведенном Вами примере менеджер не будет осведомлен о наличии товара на складе до следующего обмена. В чем гарантированость?

Он будет осведомлен о "неопределенности" статуса.
В УРБД периферийная база бодро отрапортует, что "все ок", "документ проведен". А после сеанса связи может произойти все что угодно.

В приведенном примере если документ проведен после второй фазы, то он действительно проведен, резервирование действительно выполнено.

может стоит прочитать про ACID?
wiki:ACID
wiki:Транзакция

(238) другими словами, Вы взяли один из множества возможных примеров (продажа филиальным менеджером товара с центрального склада), подобрали далеко не единственный и не самый оптимальный вариант решения на 1С и сравниваете этот вариант с отсутствием технологии у Навижн, потому что "каналы будут дешеветь в будущем".

я прав?

(241) Такая же гарантированность будет и в УРБД - товар может уйдет а может и не уйдет))).

Всем добрый день. Коллеги, я являюсь владельцем сайта http://naviart.ru и автором статьи про SIFT'ы - http://naviart.ru/sift.

Хочу всего лишь отметить в этой горячей дискуссии, что статья писалась для навижн 3-й версии, а сейчас работает уже 6-я, т.ч. материал немного устаревший.

Что же касается до содержания самой статьи, то в тех ее пунктах, где она противоречит мнению Сергея - 99%, что прав Сергей, т.к. он лучше меня разбирается в предмете.

Всем спасибо.

Ребяты, вы совсем предыдущие сообщения не читаете?
Цитирую (208):
> меня спросили каковы трудозатраты на создание НОРМАЛЬНОЙ репликации данных в Наве.
> я ответил что понимаю под НОРМАЛЬНОЙ репликацией.
> и отметил - что организовать постоянный канал связи - дешевле.

Если честно, то мне абсолютно наплевать какой вариант решения является оптимальным "на 1С". Я говорил, что я понимаю под НОРМАЛЬНОЙ репликацией.

================
а также в (144) я говорил:
> Упаси бог называть вас инструмент обмена данными в 1С - нормальной репликацией. Это даже не репликация. Это всего лишь обмен данными с подтверждениями о приеме (тикетами).

================
а также в (144) я говорил:
> То, что вы называете "нормальной системой репликации" - это всего лишь транспортный уровень :)
> Транспортный уровень в таком же объеме на навике - также вопрос нескольких дней.
>
> Вопрос: ЗАЧЕМ?!

(245) Кста, ты меня обошел своим интеллектуальным вниманием.
Я понимаю, что ты разбираешься в постоянных каналах связи и в уровнях,но  только не игнорируй (210).
Жду когда меня пошлешь в мсдн.

(144)

Описанная ситуация не корректна.
Здесь мы имеем дело с информацей которая ОБЯЗАТЕЛЬНО должна быть синхронизирована везде где используется после КАЖДОЙ транзакции.

Это же элементарная логика. Нужно запускать обмен измененными объектами после КАЖДОЙ транзакции.
На 1С 8, используя стандартные возможности регистрации изменений и планы обмена это сделать очень легко.

В остальном. Двухуровневая фиксация транзакций - это мягко говоря ни о чем.  

"Что произойдет в нормальной системе репликации
1. Будут созданы документы с промежуточным состоянием - резервирование не подтверждено
2. Менеджерам по продажам будет виден статус, что их резервирование под вопросом. Они соответствующим образом могут информировать клиентов и снять массу нареканий просто объяснив клиенту ЗАРАНЕЕ, что происходит
3. один из документов будт отклонен или частично зарезервирован(порядок проведения, порядок отклонения, порядок частичного резервирования управляется бизнес-логикой!!!!)
4. при следующем сеансе обмена менеджеры получат информацию и смогут допровести документы."

Это все ни о чем, так как не решает главную проблему обязательной синхронизации данных.

(245) Читаем. И даем ответ: канал связи в некоторых случаях НЕВОЗМОЖНО организовать в следствии ряда технических причин. А если и возможно, то по стоимости он себя не окупит.
По поводу нормальной репликации: пока Вы не назвали чем она отличается от 1с - неопределенность отгрузки товара? Так в 1с тот же менеджер выписывает счет и ждет - сделают на его основании накладную или нет. Без доработок и доп.затрат.

(246) не, он не про навижн в (144), я тоже в силу прикладного характера своей работы не сразу понял - он про "сферического коня в вакууме" ака "НОРМАЛЬНАЯ репликация".

навижн никак не решает эту проблему, у неё нет технологии. её разрабы предлагают кинуть до филиальной точки надежный канал и всё.

(144)
Да  и насчет ситуации. Она в корне некорректна, так как очевидно, что в данном случае единственное решение проблемы - это единая база.

(249) просто непонятна мысль - нет в навижн репликации, потому что в 1с плохая. Я понимаю, почему разработчики навижн не заморачиваются  с ней - на западе вряд ли есть удаленные точки, где нет инета. "Но мы в России, а это вносит свои коррективы ")))

Коллеги, официальные разработчики Navision с ней не заморачиваются, однако компании-внедренцы и внутренние технические отделы очень даже заморачиваются, и имеют свои надежные решения. Правда, практически не светят их, в силу наличия на рынке конкуриющих организаций-внедренцев.

Осколки этой информации есть здесь:
http://naviart.ru/nav-sql-replication
http://naviart.ru/replication-1
http://naviart.ru/navision-replication-3

(246) > только не игнорируй (210).
а в чем вопрос то?

(247) > Описанная ситуация не корректна.
:)
Как скажете.

(247) > Здесь мы имеем дело с информацей которая ОБЯЗАТЕЛЬНО должна быть синхронизирована везде где используется после КАЖДОЙ транзакции.
Нет, ПОСЛЕ каждой транзакции - не поможет.
поскольку транзакция будет закомичена на переферийной базе, ПОСЛЕ чего может быть отменена центральной.
а транзакция по определению - либо завершена полностью, либо отменена полностью.

(248) > пока Вы не назвали чем она отличается от 1с - неопределенность отгрузки товара?
ответил в (237).
в 1С менеджер проводит документ и видит, что он проведен.
в большинстве случаев это означает что товар системой успешно зарезервирован и будет отгружен.
но при УРБД бывают случаи, когда успешное проведение документа еще ничего не означает.

(248) > Так в 1с тот же менеджер выписывает счет и ждет...
Если вы считаете это "нормальным"... Если вы считаете это "нормальной репликацией"... Как скажете.
Лично я не считаю такой сценарий работы нормальным.
Лично я не считаю репликацию, которая может работать только по такому сценарию "нормальной репликацией".

(249) да.

(250) > Да  и насчет ситуации. Она в корне некорректна, так как очевидно, что
как скажете. :)

(251) > просто непонятна мысль - нет в навижн репликации, потому что в 1с плохая.
прусь с логики.
учебник здесь http://metasatanism.ru/Logic.html

(252) > однако компании-внедренцы и внутренние...
1.
Ох... (унылым голосом робота Марвина)
я призываю всех говорить о том, что УЖЕ РЕАЛИЗОВАНО.
я призываю всех говорить о том, что уже реализовано В СТАНДАРТНОЙ ВЕРСИИ.

И для 1С очень много партнерских и несовместимых конф
И для Нава также много партнерских приложений (а некоторые даже несовместимы с остальными)

если мы сейчас начнем говорить о решениях третьих сторон, о том что "можно сделать", то внезапно выясним, что "можно сделать все".

2.
и для Нава партнерские решения - это всего лишь обмен данными, а не репликация.
Чтобы сделать нормальную репликацию, Нав тоже полностью переписать нужно.

==============
Кстати, поэтому и слышим "отголоски".
а не потому что есть конкуренция :)

(241) У меня менеджер когда бъет заявку в своей базе у него реализованы статусы
"Новый" - заявка создана, но не отправлена в центральный офис
"В пути" - заявка выгружена в центральную базу, но ей еще не принято
"№002541" - заявка загружена в центральную базу с таким номером.
После того как по заявки товар поставят в резерв и после обмена у менеджера ищменится статус
"В резерве" - заявка поставлена в резерв в центральной базе. Причем у менеджера в его базе будут видны и сколько какого товара поставлено в резерв
"Просрочена" - по заявки небыло никакого ответа более недели, автоматически такая заявка "обнуляется"


Я правильно понимаю что это и есть двухуровневая транзакция? Причем это реализовано на 1С 7.7

Таким образом менеджер может принимать заявку сидя у клиента в подвале, где инета нет, но при этом после обмена он будет знать сколько и какого товара гарантированного привезут этому клиенту.

(255) > У меня менеджер ... в своей базе у него реализованы статусы
Вы о какой типовой конфигурации говорите?

(255) > Я правильно понимаю что это и есть двухуровневая транзакция?
Если это ваша самописка, то понятия не имею.
Я же не знаю деталей вашей реализации.
Ссылки на статьи на эту тему я прикладывал выше.

(255) > Причем это реализовано на 1С 7.7
Поздравляю вас. И что?

(257) Ну просто чтобы понять что вы понимаете под двухуровневой транзакции.

А типовые. Ну возьмите тот же Рарус - Управления Складом, там это реализовано

Спор "ниочем".

(259) + 100
Взяли конфигу для ларька и сравнивают с конфигой для холдинга, и потом рассказывают, что 1С фигня, потому что это там не реализовано.

А то что не реализовано не потому что это нельзя реализовать, а потому что это никому не нужно - скромно умалчивают.

mazzy Если сравнивать 1С:Машиностроение и Навижен, то окажется. что очень многое что есть в типовой 1С нет в Навижен

(258) > там это реализовано
и что?

возвращаемся к исходному вопросу:
(0) > Какие доводы можно привести за 1С против навижн
Значит, раз в доводах "за 1С" можно приводить самописки и партнерские решения, то и "за Навижин" тоже можно?

Уверяю вас - для Навижина их поболее будет. :)

вы бы почитали сначала это предупреждение
http://axforum.info/forums/showthread.php?p=214328#post214328

впрочем, как вам будет угодно.

+(259) Основное отличие это есть УРБД или его нет, остальное технические детали реализации и воспринимать его нужно как он представлен с его плюсами и минусами. Качестве их (плюсов и минусов) будет только субъективное, а примеры можно придумать любые.

(260) > Если сравнивать 1С:Машиностроение и Навижен, то окажется. что очень многое что есть в типовой 1С нет в Навижен

на аксфоруме уже пробовали http://axforum.info/forums/showthread.php?t=31176
http://axforum.info/forums/showthread.php?t=34562

сравнивайте. посмотрим что у вас получится.

(261) Ну так и сравнивай функционал навижен с 1С:Машиностроение. И будет тебе платформа + решения

(261) > Если сравнивать 1С:Машиностроение и Навижен
(264) > Ну так и сравнивай
o_O!!!!

+(263)
сравнения на форуме у mazzy
http://forum.mazzy.ru/index.php?showforum=35

сравнения на аксфоруме
http://axforum.info/forums/forumdisplay.php?f=29

Вообще для корректного сравнения чего-либо нужны объективные показатели и одинаковые условия проведения сравнения в остальных случаях такие сравнения будут выражать только личную точку зрения автора сравнения.

(267) я убежден, что вы помнили о первоначальном вопросе "Какие доводы можно привести за 1С против навижн ?"
:ROFL:

маззи, ты упорно не отвечаешь на вопросы. то, что я написал в (214)(215) делается за два часа максимум не зависимо от конфигурации и универсально - т.е. последующие изменения конфы (включая структуру метаданных) не влияют на работоспособность механизма и не требуют его доработки. сколько тебе потребуется на такое в навижне?

(268) промолчу )))

(269) > маззи, ты упорно не отвечаешь на вопросы. то, что я написал в (214)(215)
o_O!!!
не отвечаю, поскольку не вижу там вопросов. в чем вопрос то?

(269) > делается за два часа максимум не зависимо от конфигурации и универсально
я не согласен с этим утверждением.
я видел как люди подписывались и делали эти "за два часа" годами.

если вопрос формулируется "В какой системе быстрее вести разработку?"
то я уже говорил http://axforum.info/forums/showthread.php?t=35600
что "скорость разработки" зависит не от удобств самой системы, а от количества объектов, которые затрагиваются (прямо или косвенно) данной разработкой.

===============
веб-сервисы в навике есть.
http://www.nav4u.ru/archives/361-vvedenie-v-veb-sluzhby-v-microsoft-dynamics-nav-2009-chast-1/
http://www.nav4u.ru/archives/345-vvedenie-v-veb-sluzhby-v-microsoft-dynamics-nav-2009-chast-2/

(271) >> что "скорость разработки" зависит не от удобств самой системы

Кхммм ... утверждение, как бэ сильно спорное ...

Я бы иначе сказал: сложность разработки зависит от богатства фрейворка и длины объектной модели.

(271) Хочешь сказать что скорость написания обработки в блокноте или в 1С 7-ке с помощью телепата будет одинакова? Или хотя бы сопоставима?

(274) при большом количестве объектов и связей между ними - да.

(сразу отмечу - в УПП не такое уж и большое количество объектов и связей, по сравнению даже с Навиком. :))

(275) Т.е. держать в уме все связи и методы, или воспользоваться контекстной подсказкой - это одно и тоже?

Как раз для больших связей контекстная подсказка на порядок упрощает написание кода.

ОФФ: Гимнаст проходит по канату с одного конца берега до другого. После этого заявляет: "Мост строить не надо. Достаточно крепкого каната" ... Аплодисменты. Однако практика показывает, что без моста не обойтись. Так и с Навиженом. "Замечательная система". Однако количество внедрений на порядок отстает от 1С по соотношению количество/сумма внедрений. Вот и весь ответ. Есть конечно эквилибристы и гимнасты от Навижен, но их немного. Вот и вам и аргумент. ИМХО

вы мне ответьте почему в навижн такие убогие и некрасивые интерфейсы ?

(276) > держать в уме все связи и методы, или воспользоваться контекстной подсказкой
я просто офигеваю с логики. извините.
в этом утверждении нужно использовать не ИЛИ, а И.

чтобы воспользоваться контекстной подсказкой при большом количестве объектов и связей все равно их нужно держать в уме :)

(277) тоже обсуждалось неоднократно
http://axforum.info/forums/showthread.php?t=25751
http://axforum.info/forums/showthread.php?t=32254
вроде подвижки со стороны Майкрософта в направлении ценообразования в Росии есть
http://axforum.info/forums/showthread.php?t=35707
http://forum.mazzy.ru/index.php?showtopic=14873

(278) Гордость навижен. Обратная совместимость

(278) > вы мне ответьте почему в навижн такие убогие и некрасивые интерфейсы ?
легко. после того, как вы ответите мне почему они такие убогие и некрасивые в 1С.

(280) О_О!!!! Интерфейсы?

(279) Нет не нужно. Достаточно написать точку и выбрать нужный метод, а не держать в уме что счётчик через ё пишется.

(281) 8.2 - прекрасен....

+(284) это же прекрасно: http://v8.1c.ru/small.biz/

(284) NAV 2009 - более прекрасен.
8.2 движется как раз в сторону интерфейсов последних Навиков.

(281) и вот опять ты уходишь от ответа на вопрос.. пытаешься перевести стрелки... эх....

(286) скрины давай

(286) Да ну? http://www.navision.mazzy.ru/lib/nav2009-whats-news/SalesOrders.png

(279) Ссылки давать, т.е. посылать, я тоже могу. Но хотелось бы твое мнение на уровне сегодняшнего состояния, а не планов Микрософта.

(288) Не даст, ибо они убогие http://www.navision.mazzy.ru/lib/nav2009-whats-news/

(285) отлично. перешли к ссылкам.
их есть у меня
http://www.youtube.com/results?search_query=microsoft+dynamics+nav+2009&aq=0m
http://www.microsoft.com/Rus/dynamics/nav/video.mspx
http://www.microsoft.com/Rus/dynamics/nav2009/system/index.html
http://forum.mazzy.ru/index.php?showtopic=14900
http://www.axforum.info/forums/showthread.php?p=182358#post182358
http://www.nav4u.ru/archives/168-finansovye-otchety-v-nav-2009/

(292) это гениально:

http://www.nav4u.ru/wp-content/uploads/2009/06/5_columnlayoutnames.png

http://www.nav4u.ru/wp-content/uploads/2009/06/4_accscheduleedit.png

(287) я вам бот что ли?
(286) легко. см (292)
(289) ну да
(288) о, и это тоже :)

у меня у одного половина ссылок не открылось ?

(292)так я не понял. там все по англицки что ли ?

(295) это хитрый ход - давать ссылки на форумы где картинки открываются только под паролем и логином :)

(290)
мое личное мнение: стоимость лицензий 1С сильно занижена. в других странах по такой стоимости продаются локальные вещи для локального рынка.

зарубежные вендоры просто офигевают, что здесь такая развитая платформа стоит так дешево и просто не верят тому, что для успешной конкуренции здесь нужно снижать цены НАСТОЛЬКО.

+(296)как моим бабкам то работать в программе ?

(294) Интерфес на уровне подделки студнетов на делфи 10-ти летней давности. Мы такие на лабораторных рисовали. И в чем он прекрасен?

(300) легко. после ответа на вопрос "И в чем прекрасен интерфейс 8.2?"

(301) легкий, простой, элегантный, инновационный, современный, светлый, чистый, стильный, тонкий, воздушный интерфейс

(301) и вот опять - стрелки.. стрелки...
:)

(300) он прекрасен своей простатой

(301) на счет 8.1 - там интерфейс более компактен, и более разнообразен по возможностям оформления, чем в навижен 2009

8.2 УП интерфейс беден, но он программируется для web и win одинаково, как в этом плане дело в разработке под web и win в навижен 2009 (6.0)

(303) Это старый еврейский прикол. Отвечать вопросом на вопрос. Ну что возьмешь со старого еврея.

(301) А на мой вопрос ты ответил?!
Я вижу стандартный косёж под дурачка.
Я тебя в мздн не пошлю, пошлю выше, все на русском.
Напрягись!
Цитирую...
Это было выше...
"(208) Цитата из (144)
"Есть ЦБ, Б1, Б2 (центральная база, база 1, база 2)
предположим, что во всех номенклатура и остатки на складах уже синхронизированы.
Предположим, что на Склад1 хранится 10 шт остродефицитного товара.
Предположим, что менеджеры продаж одновременно продают по 6шт этого товара с одного склада (из центральной базы)."
И далее ты говоришь, как с помощью навижн менеджер звонит клиенту и снимает все вопросы...
А я тебе говорю цитирую из (200)
"Никакая навижн (даже заточенная mazzy) не решает проблему, которую сам mazzy и привел в пример, как решаемую с помощью навижн."
Для тебя, уважаемый mazzy, говорию, что навижн, даже заточенная тобой не решает проблему.
Проблему решает менеджер простым и банальным способом, как ты и указал далее в (144) "снять массу нареканий просто объяснив клиенту".
А клиенту абсалютно пофиг ЗАРАНЕЕ ему отлуп дадут или ЗАГОДЯ и какие слова ему скажут.
Вот и вопрос, а где тут навижн?!"

Еще разок повторяю, как навижн в придуманной тобой ситуации решает представленную тобой простейщую проблему нехватки товара?!

Один я понял, что в навижн подобной ситуации быть не может по определению? За отсутствием механизма РИБ-овских баз. Либо товар зарезервирован, либо - нет.

А в (144) речь шла именно о примере нормальной репликации данных.

(0) Против Нав только одно: очень мало спецов, да и функционал не особо-то богатый.

(301)(307) Какой принципиальный вопрос.
Начнем с того, что реализация распределенной БД в 1С поделка еще та. В Наве нет, да и правильно говорят, не особо-то оно и надо.

Касательно красивых отчетов, так вроде как есть коннекторы шарика к наву, а там можно сваять что угодно, да еще мониторить из коробкиЮ как часто, и насколько тягомотно эта хрень выполняется. Без всяких бубнов.

Петь про технологический журнал песен не надо. Не будете же вы его на боевых системах держать включенным постоянно.

(310)"Против Нав только одно: очень мало спецов, да и функционал не особо-то богатый. " - спецы очень существенный вопрос. В одну контору товарищ написал программу для кпк. Сейчас товарищ сдымил в столицу. Теперь всякими ухищрениями пытаемся эту прогу править под 7ку.
Еще вопрос в стоимости навижн. Один франчайзи выиграл тендер на крупном предприятии у конторы, внедряющий навижн - цифра была одинакова, только сумма навижн в долларах, 1С в деревяных.  
"Начнем с того, что реализация распределенной БД в 1С поделка еще та. В Наве нет, да и правильно говорят, не особо-то оно и надо. " - на западе может и не надо, но в деревнях родного СНГ для многих фирм это единственный выход.

"В Наве нет, да и правильно говорят, не особо-то оно и надо. " - а это плагиат))). Так мои знакомые внедренцы УПП говорят клиентам - в УПП этого нет и это правильно - нах оно Вам нужно)))

(229) Противоречие в том, что ты утверждаешь что SIFT это такое благо, которое даже аксаптерам не снилось, и что работает все быстро! А люди пишут про задержку аж в 10 секунд из-за SIFT!

"(213) я не понимаю в чем противоречит"
Все ты прекрасно понимаешь, что SIFT - те же регистры 1С с теми же достоинствами и недостатками! Ты подчеркиваешь лишь достоинства SIFT, умалчивая о недостатках (для 1-го SIFT поля заводится 1 таблица) и о тормозах, которые 1С-у не снились!

Если я не прав, распиши, как работает SIFT с таблицами? Ты этого не сделаешь, ибо механизм очень похож на механизм регистров 1С!

(312) Да-а-а-а... Быть тебе посланным в мсдн...

(313) И где он найдет русский хэлп по SIFT?
Сам напишет, если только?

Никто не может написать по-русски, как работает SIFT, потому, что это та же технология хранения итогов, что и в 1С, только более тормозная!

Никто не мешает признавать недостатков системы и гордиться достоинствами.
Но если идет односторонне-избирательное восхваление в стиле рекламы для боссов, то я не доверяют прежде всего специалисту, и на фоне этого негативно отношусь к той системе, где он работает.

И вообще манера в стиле у нас все круто, все пучком, сами такие, читай мсдн - это или незнание своей системы, или банальное вранье, или возрастная неадекватность или все вместе.

так и знал!
SIFT только на словах, что то уникальное!