DogenМашина ездит и приносит вам пользу, а тестовая версия некой системы пользу не приносит (инфу о положительном или отрицательном заключении о пригодности не рассматриваю).Если заказчик так настаивает на проведении тестирования в условиях РЕАЛЬНОЙ РАБОТЫ , то это еще большой вопрос, что его на самом деле интересует - возможность нахаляву "реально поработать", или собственно сам тест.

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

777777777Эта тема появилась из-за удивительно "несерьезной и недоступной" позиции 1с - купите 50 ключиков и все покажем.Судя по всему, вы обратились к мелкой шаражкиной конторе. Которой прежде чем вам установить 50 ключиков, нужно самим у 1С купить 50 ключиков. И поскольку у них не высокие обороты и мало клиентов, они не могут быть уверены, что если результаты теста вас не удовлетворят, то они смогут на эти 50 ключиков найти другого покупателя. Обращайтесь к крупному франчайзи, например в Рарус.

OTiger
>А если операций много? База большая? А если есть сложные алгоритмы расчета статистических данных?

Ну и какие проблемы? Это уже сложности конкретной системы, не способной отработать на триггерах большое кол-во операций. И что, опять будете возводить в ранг особых заслуг системы?OTiger, не всё так просто. Речь идет не о "заслугах", а о том, что для большого числа транзакций невозможно в принципе обеспечить соответствие содержимого ряда отчетов, получение которых связано с работой алгоритмов высокой вычислительной сложности, с картиной по состоянию на 5 миллисекунд назад, когда была закомичена последняя транзакция. Если каждая транзакция начнет заниматься пересчетом (по триггерам) этих алгоритмов, то на порядки упадет время реакции системы для ее пользователей. Если запускать эти алгоритмы тогда, когда понадобились отчеты, отчеты могут формироваться слишком долго. Пока они формируются, опять-таки может сильно притормозить сервер (просто в силу большой нагрузки на процессор), могут заблокироваться данные, из-за чего встанут текущие транзакции (для блокировочников), либо появится эффект "грязного чтения", либо понадобится существенно увеличить и так большое время формирования отчета (для версионника) за счет того, что слишком большие объемы информации подвергнутся копированию. И в любом случае, пока кто-то настроит фокус своих зрачков на отчет, появившийся на экране, его содержимое уже может перестать быть актуальным, потому что за это время прошло еще несколько транзакций.
Если речь идет об OLAP, то различают ROLAP, MOLAP и HOLAP. ROLAP, конечно, наиболее предпочтителен, но на практике он возможен в очень редких случаях. HOLAP может потребовать космических размеров дискового пространства. Как правило, на практике используется кубы MOLAP, которые по большей части синхронизируется с данными в определенные моменты времени, а по жизни содержат информацию по состоянию на некоторое время назад.

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

iscrafmЯ на этом рынке ПО достаточно долго, но про такое правило не слышал. И не считаю зазорным выписать заказчику, с которым собираюсь работать 50 лицензий для того, чтобы погонять систему в условиях максимально приближенным к реальным.Давайте не забывать еще и вендоров. У них имеется такая штука, как "лицензионная политика". Интересно узнать, каким образом вам, к примеру, удастся ОФИЦИАЛЬНО предоставить, ну, например, нам, лицензии Microsoft сроком на 1 месяц, если ни в одном виде лицензирования продуктов Microsoft предоставление программных продуктов сроком на 1 месяц не предусмотрено. Как и у 1С, кстати...

MGR GaryaИ побожитесь в этом договоре, что в случае положительных результатов приобрете программный продукт ( можете даже сразу оговорить, на каких условиях ), а также оговорить штрафные санкции за невыполнение своих обещаний. Не согласен. Предположим предполагаемый клиент закажет такую демонстрацию и договор подпишет, обязуясь потом купить внедрение за 200 000, оговорив модули.
Но цена внедрения может появиться только после предпроекта, который денег стоит и тоже не малых.Ну так я же и говорю о том, что сумму проекта нужно сразу оговорить (см. выделенное).

MGRА то вдруг результаты устроили, а потом оказалось что работы там не на 200 000, а на 100 000 или же наоборот - на 500 000?Чтобы "вдругов" не было, можно сразу приложить к договору ТЗ.

OTigerНу и как поможет защититься история? Вы планируете ВСЮ информацию дублировать? то есть и суммы и курсы? Всё-всё?А мне кажется, что если система позволяет всю информацию дублировать, то это очень хорошая система. В особенности, если до разбора конфликтных ситуаций она позволяет скрыть информацию о журнализации и версиях, и легко ее вывести на экран, если в этом возникла необходимость - любому пользователю (имеющему на это соответствующие права), а не только IT-специалисту, то это вообще шикарная система. Очень жаль, что многие разработчики систем автоматизации этого не понимают и пытаются реализовывать половинчатые решения, к тому же требующие большого объема телодвижений и все равно не предоставляющие стопроцентной гарантии достоверности информации (почему, я уже говорил выше - о возможности править содержимое словарей минуя механизм "сторнирования", а также нерегестрируемое изменение настроек).

iscrafmЕсть такое понятие NFR

http://www.1c.ru/news/info.jsp?id=1866 Версии NFR (не для продажи) программных продуктов системы "1С:Предприятие" предназначены для ВНУТРЕННЕГО использования фирмами 1С:Франчайзи...

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