Результаты опроса: Нужно ли поддерживать Windows 2000?
Да 9 30.00%
Нет 11 36.67%
Все равно 10 33.33%
Голосовавшие: 30. Вы ещё не голосовали в этом опросе

[ОТВЕТИТЬ]
20.03.2009 10:10
Mtirt
 
1. У разных клиентов разные запросы. Ты не соберешь общее видение продукта.
2. Зачем тебе все? Что мешает лично тебе написать СВОЁ видение необходимых доработок? Напиши его в тех.поддержку, с копие менеджеру. Почему ты так уверен, что результата не получишь?
20.03.2009 10:13
7zEro
 
а тогда мы и получаем стандартное предложение от С+ и не чего тогда кричать что нет нас это не устраивает а вы работает не так )))) сидим и дальше лузгаем семки....
20.03.2009 10:33
Mtirt
 
Цитата:
7zEro а тогда мы и получаем стандартное предложение от С+ и не чего тогда кричать что нет нас это не устраивает а вы работает не так )))) сидим и дальше лузгаем семки....
Хорошо, я поставлю вопрос иначе. Что именно ты сам или твое предприятие сделало для развития СМ2000? Какие предложения не были приняты С+? По каким причинам?
20.03.2009 10:59
7zEro
 
не смогли реализовать связку работы см+ с ОПТОМ хотя говорили что возможности есть или на край будут развивать в данном направлении... только продвижении я не наблюдаю...
20.03.2009 11:05
Mtirt
 
Ты написал ТЗ по этому поводу? Или С+ написал ТЗ и согласовал его с вами? Или вы с менеджером за чаем поговорили?
20.03.2009 11:07
7zEro
 
ладно не будем устраивать дебаты... давай те просто обсудим тихо и мирно новую версию линейки с+
20.03.2009 11:07
АсП
 
Цитата:
7zEro не смогли реализовать связку работы см+ с ОПТОМ хотя говорили что возможности есть или на край будут развивать в данном направлении... только продвижении я не наблюдаю...
Связка с оптом - очень обще.
Были ли изложены связано и понятно требования к связке? Даны ответы на уточняющие вопросы аналитиков? Было ли единство мнений по поводу связки внутри вашей организации?
Была ли оплачена доработка, если это было нужно вашей уважаемой организации?
20.03.2009 11:11
7zEro
 
на пред проекте сказали что все реализовано и т.д. а потом выяснилось что есть xml и пишите все сами )) вот и пришлось трудиться... была составлена схема работы предприятия где все прописано и нарисовано... только все это пришлось переделывать потому что не получилась работать так как предложил в данном пред проекте бизнес аналитик... дальше продолжать...
20.03.2009 11:15
7zEro
 
по пред проекту мы должны вести все справочники в СМ2000 а затем выгружать в доверительные базы для полной синхронизации за не имением значимого числа справочников и данные которые просто не обходимые в работе любой ОПТОВОЙ фирмы приходится вести в стороннем софте... предположим справочник водители самые простой какие раком они его в С+ прикрутят и куда? и это только начало а специфика ОПТА она своеобразна и с розницей есть большие отличия... а продвижении как не было так нет и я думаю что не будет... ладно че то я опять не про то =)
20.03.2009 11:17
Mtirt
 
Водители в См2000 используются в документах? расходные накладные, накладные на перемещение? Заведи метку "Водители". Укажи строгий список. И используй на здоровье.
20.03.2009 11:20
7zEro
 
для СМ2000 они мне не нужны они нужны для ОПТОВЫХ складов а вот заводить их по пред проекту должны в см2000 от куда они автоматом должны выливаться в доверительную базу...
20.03.2009 11:46
Mtirt
 
Цитата:
АсП Олег, поясню. Никто не заставляет текущих пользователей переходить на "рискованную" с твоей т.з. модель работы с одной БД. Мы будем поддерживать и одно, и другое решение. У каждого из них есть и будут свои плюсы и минусы. Но имхо монстральности бояться не стоит - все системы двигаются в этом направлении. :)
А это можно понимать, так: клиентское рабочее место Супермага может работать как через сервер приложений, так и напрямую общаясь с базой данных?
А вот почтовый, кассовый, Web- сервера - только через сервер приложений?
Или я неправильно понимаю?
20.03.2009 12:01
OlegON
 
Цитата:
АсП Олег, поясню. Никто не заставляет текущих пользователей переходить на "рискованную" с твоей т.з. модель работы с одной БД. Мы будем поддерживать и одно, и другое решение.
Замечательно, я же стремлюсь к тому, чтобы не было "одно плохо, а другое еще хуже", а к тому, чтобы они (решения) имели право на существование не только потому, что единственные.
20.03.2009 14:10
baggio
 
Так короче...
Давайте завязывать с личностями... скотилось не туда, не так, и не о том...
Нам дали возможность поучаствовать... а не...
Все таки уважаемые сотруники С+ для реального принятия решения, даже на подумать не хватает информации...
в первую очередь:
1. Конкретно какую схему позволит реализовать подобная "перекомпиляция" - мне как внедренцу это очень интересно, т.е. наверняка сейчас есть клиент под которго это пищется и будет обкатыватся ... хотелось бы увидеть описание работы и предпологаемые решения...
2. Все таки как будет выглядить сросшийщя модуль и начем будет написан... чем больше инфу тем лучше...
3. Какие изменения это повлечет за собой в плане лицензирования (что одно подключение к Оракле через сросшийся модуль и все?)

И (простите за глупость)(простите за глупость)(простите за глупость)(простите за глупость) ко всем... к нам пришли с мячом... а не мечом... так что давайте харакири не делать друг другу... а?
20.03.2009 14:50
bob
 
Цитата:
baggio Так короче...
Давайте завязывать с личностями... скотилось не туда, не так, и не о том...
Нам дали возможность поучаствовать... а не...
Все таки уважаемые сотруники С+ для реального принятия решения, даже на подумать не хватает информации...
в первую очередь:
1. Конкретно какую схему позволит реализовать подобная "перекомпиляция" - мне как внедренцу это очень интересно, т.е. наверняка сейчас есть клиент под которго это пищется и будет обкатыватся ... хотелось бы увидеть описание работы и предпологаемые решения...
2. Все таки как будет выглядить сросшийщя модуль и начем будет написан... чем больше инфу тем лучше...
3. Какие изменения это повлечет за собой в плане лицензирования (что одно подключение к Оракле через сросшийся модуль и все?)

И (простите за глупость)(простите за глупость)(простите за глупость)(простите за глупость) ко всем... к нам пришли с мячом... а не мечом... так что давайте харакири не делать друг другу... а?
Ну на первый вопрос Андрей Евглевский уже ответил по сути. Это сети мелких магазинчиков с единой центральной базой, что позволит (я по крайней мере так думаю) удешевить конечный проект. В принципе мысль достаточно разумная.
20.03.2009 15:08
OlegON
 
Все обсуждения по самому Сервис плюсу перенесены в Книгу жалоб
20.03.2009 15:37
baggio
 
Цитата:
bob Ну на первый вопрос Андрей Евглевский уже ответил по сути. Это сети мелких магазинчиков с единой центральной базой, что позволит (я по крайней мере так думаю) удешевить конечный проект. В принципе мысль достаточно разумная.
меня интересует скорость канала... поскольку с базой при скорости меньше 1 мегабита работать тяжело... я не говорю про обрывы связи... Просто одним из + Супепурмага... как раз возможность автономной работы магазина при магистральных авариях... а то получится FIT какойнить... вот что меня волнует...
23.03.2009 10:51
Офигевший
 
Цитата:
АсП Татьяна, я отвечу Вам и остальным коллегам. Через сервер приложений мы планируем работать со всеми бывшими сервисами(кассовым, например). Рефакторингу подвергнется кассовый сервер. Цель - дать возможность нашим сетевым заказчикам не использовать схему с распределенными БД, а всем магазинам работать в одной БД. Итог - нам надо "уметь" удаленно грузить данные на кассы, в чем нам поможет сервер приложений.
Андрей Евглевский
Т.к. по другому видимо мидл-офис работать не умеет.
Обмен должен быть файловый...
Т.к. если будет как в УКМ4.0, транзакционный то будет полная жопа, у кого нестабильные каналы связи...

BI - это как в известном фильме:
- Ты суслика видишь?
- Нет
- А он есть (с)
23.03.2009 16:43
АсП
 
Цитата:
Mtirt А это можно понимать, так: клиентское рабочее место Супермага может работать как через сервер приложений, так и напрямую общаясь с базой данных?
А вот почтовый, кассовый, Web- сервера - только через сервер приложений?
Или я неправильно понимаю?
Я поправлю, будет возможно 2 варианта физического построения сети: 1. Распределенные базы данных. При таком построении сети сервер приложений находится в каждой локальной сети с каждой базой данных. Через него работает локальный сервер лицензий (в нашей ситуации -
это и есть сервер приложений), почтовый и кассовый сервера. 2. Единая БД. При таком построении сети - сервер приложений 1 для всей сети и через него работают общие вышеперечисленные сервисы.

Таким образом по вашему вопросу - в части проверки лицензии(т.е. как сейчас с сервером супермага) рабочее место всегда будет обращаться к серверу приложений, т.к. на него ложится функция сервера лицензий. Тоже самое - через него будут работать перечисленные сервисы. Либо через локальный сервер лицензий, либо через общий.
23.03.2009 16:45
АсП
 
Цитата:
baggio меня интересует скорость канала... поскольку с базой при скорости меньше 1 мегабита работать тяжело... я не говорю про обрывы связи... Просто одним из + Супепурмага... как раз возможность автономной работы магазина при магистральных авариях... а то получится FIT какойнить... вот что меня волнует...
Да, скорость для комфортной работы, ~512.
Как я уже писал выше - вы можете работать и по старой схеме с распределенными БД и каким либо из существующих транспортов между ними.
23.03.2009 17:05
baggio
 
Цитата:
АсП Да, скорость для комфортной работы, ~512.
Как я уже писал выше - вы можете работать и по старой схеме с распределенными БД и каким либо из существующих транспортов между ними.
Меня подобная возможность полностью устраивает... я даже скажу "За"
попутно есть вопрос\просьба
Поскольку подобные схемы мы и так реализовывам через RDP то...
РДП позволяет сохранять резульнат работы и (это основное преимущество) при обрывах связи... Правильно ли я понимаю что сервер приложений будет вертеть все в себе и результаты работы при обрыве будет сохранятся при повторном подключении?
Я думаю это должно быть основноетребование к разработчику - ИМХО...
23.03.2009 17:13
OlegON
 
Прочитал внимательно, к сожалению, не пойму, в чем преимущества этого сервера приложений по сравнению с удаленной выгрузкой и работой в терминале? Т.е. если хотим сэкономить на количестве серверов - ставим в центре сервер терминалов, додумываем, как пересечь каталоги выгрузки с удаленными (это в случае неустойчивой связи) и работаем... Что этому может противопоставить сервер приложений, учитывая, что терминальная сессия не пропадает при разрыве связи?

P.S Долго писал :) Уже задали вопрос, но стирать не буду
23.03.2009 17:15
Mtirt
 
Подозреваю, что стоимостью...
Один модуль одиночного магазина и куча доп.рабочих мест.
23.03.2009 17:55
mighty
 
Предложить можно? Хочется увидеть в 1027:
1) Авторасчет себестоимости
2) Чтобы авторасчет не собирал статистику по FF таблицам, для этого в принципе есть задания
3) при заполении спецификации черер терминал хотелось бы чтобы интерфейс грида отключался - пусть индикатор показывает сколько товаров добавляется. Это жутко тормозит работу процедуры загрузки

навскидку вспомнил, будут еще предложения высскажу..
23.03.2009 18:18
АсП
 
Цитата:
OlegON Прочитал внимательно, к сожалению, не пойму, в чем преимущества этого сервера приложений по сравнению с удаленной выгрузкой и работой в терминале? Т.е. если хотим сэкономить на количестве серверов - ставим в центре сервер терминалов, додумываем, как пересечь каталоги выгрузки с удаленными (это в случае неустойчивой связи) и работаем... Что этому может противопоставить сервер приложений, учитывая, что терминальная сессия не пропадает при разрыве связи?
Плюсом, хотя и неочевидным, является встроенный в приложение механизм. Т.е. приложение отвечает за доставку к удаленному клиенту(кассе), а не сторонняя программа. Хотя может казаться, что в случае с посторонней тиражируемой программой - оно будет надежней.
24.03.2009 16:50
baggio
 
Вот мы сейчас со Student`ом посовешались и пришли к вопросу:
А не является ли подобная схема средством для предоставления сторонним разработчикам возможноти дорабатывать\изменять функционал и интерфейс программы? Подобные задумки есть?
да\нет?
24.03.2009 16:56
isi
 
ветка в сторону ушла от вопроса...


Опции темы


Часовой пояс GMT +3, время: 12:34.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.