powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Учетная система для ритейла
25 сообщений из 112, страница 3 из 5
Учетная система для ритейла
    #38391185
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
instantна этом форуме сейчас 6000 посетителей. Спросите у админа насколько вменяемые требования.
какая связь между требованиями к железу для 6000 пользователей форума и 1000 пользователей ERP?
это раз
"все познается в сравнении"
это два
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38391244
instant
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovinstantна этом форуме сейчас 6000 посетителей. Спросите у админа насколько вменяемые требования.
какая связь между требованиями к железу для 6000 пользователей форума и 1000 пользователей ERP?
это раз
"все познается в сравнении"
это два

instants_ustinovпропущено...

какая связь между требованиями к железу для 6000 пользователей форума и 1000 пользователей ERP?
это раз
"все познается в сравнении"
это два
а что делают 6000 пользователей ERP в отличии от 6000 пользователей форума? Точно также запрашивают и постят информацию
что более подробно объяснить? Или вы просто пропустили ответ?
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38391248
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
instant, это я по ошибке второй раз отправил.
а указывать дополнительно, что речь идет о сап и 1с - смысл? речь ведь шла именно об этих системах.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38407352
Уважаемый DrBeer,

в другой ветке http://www.sql.ru/forum/1041127/razrabotchik-sprut-ukraina?hl=
вы ищете разработчика Спрута, а здесь вы ищете ответ на вопрос "а на что заменить Спрут?".

Как одно с другим вяжется?

Оно бы вязалось, если бы Вимас отдавал исходники своим заказчикам.
Тогда было бы понятно: CIO компании ищет внутреннего программиста, садит за Delphi, и тот "ваяет" новый функционал.

Но разве они отдают свои исходники клиентам?
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38407553
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь Бобак,

Вы обратите внимание, что ту тему закрыли, когда открыли эту
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38407625
Nitro_Junkie,

я это понял. Я просто не понимаю где на самом деле господин DrBeer работает.
По той теме я думал, что он работает в компании Вимас (потому что искали разработчика).
Но в профиле написано CIO, значит на самом деле работает в компании-ритейлере.

Отсюда закономерный вопрос: зачем человеку, который есть заказчиком, искать девелопера системы, которую делает Вимас?
Значит он либо в тот момент времени работал на Вимас, либо же Вимас отдает свои исходники.

Мне просто любопытно узнать что из двух есть true.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38407674
Фотография peter64
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
там есть возможность подключать внешние модуля + можно написать свой софт поверх базы (если знаешь ее структуру).
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38407677
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь БобакНо разве они отдают свои исходники клиентам?Для некоторых дописок сорцы не нужны.
Что мешает добавить в систему пару тройку доп. таблиц и юзать их например в репортах или совершенно отдельных самописных модулях (например к-л кадровые/производственные/WMS/маркетинговые расширения) ?

Что-то мне подсказывает, что ТС-у в "Спруте" не хватает возможности для осуществления кастомных хотелок, коих реально много.
Вимас не видит смысла, а ТСу это надо, но оперативнее и за меньшую стоимость.

Кстати похоже он охладел к топику. Хотя обещал выложить требования еще 3 недели назад.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38407736
LSV,

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

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

Вопрос в том, насколько продукт позволяет его кастомизировать без написания кода. Чем больше - тем выше качество продукта.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408165
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь БобакLSV,

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

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

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

Ну или делать как SAP, Axapta, 1C и т.п. Предоставлять платформу с исходниками и правь под свои нужды. Конечно общее развитие продукта обходит тогда тебя стороной, но для многих кастомизация важнее.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408207
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игорь Бобакзаказчики часто хотят много всего такого, что если это сделать в продукте - то продукт будет заточен только под этого заказчика, а остальным эта фича будет не нужна - это раз.

А второе - это то, что потом эта фича начинает служить якорем: невозможно нормально разрабатывать другие фичи, потому что всегда приходится думать о поддержке этого якоря.
вместо этого можно подумать об архитектуре и делать якорей. Все же уже давно придумано. По ключу SOA поищите.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408213
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieНу или делать как SAP, Axapta, 1C и т.п. Предоставлять платформу с исходниками и правь под свои нужды. Конечно общее развитие продукта обходит тогда тебя стороной, но для многих кастомизация важнее.
как раз так можно делать, если ничего другого не остается. Но лучше, конечно, действительно потратить в самом начале время и усилия на проектирование архитектуры продукта, чтобы потом так как вы предлагаете не делать
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408256
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmNitro_JunkieНу или делать как SAP, Axapta, 1C и т.п. Предоставлять платформу с исходниками и правь под свои нужды. Конечно общее развитие продукта обходит тогда тебя стороной, но для многих кастомизация важнее.
как раз так можно делать, если ничего другого не остается. Но лучше, конечно, действительно потратить в самом начале время и усилия на проектирование архитектуры продукта, чтобы потом так как вы предлагаете не делать

Давайте так, не существует идеальной архитектуры для всех случаев. Даже для отраслей нет. Максимум какой-то очень узкой ниши. "Точки" входа очень сильно ограничивают разработчика.

Недавний пример. Если вы например когда-нить плагин к IDE писали, то там все на этих "точек" входа (уверяю вас вы такого их количества в жизни не видели) сделано. И все равно идеологически там изменения предполагается идут одновременно для нескольких файлов (и в 95 процентов случаев это так), а если нужно сделать асинхронное изменения многих файлов, из-за особенностей архитектуры есть лаги, от которых никуда не уйдешь. А люди реально старались сделать чтобы к их IDE можно было прицепить все что угодно, но все варианты в принципе не учтешь.

Ну и с нормальной платформой и открытыми исходниками все же гораздо проще, чем выискивать нужные точки входа.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408263
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkieiscrafmпропущено...

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

Давайте так, не существует идеальной архитектуры для всех случаев. Даже для отраслей нет. Максимум какой-то очень узкой ниши. "Точки" входа очень сильно ограничивают разработчика.

Недавний пример. Если вы например когда-нить плагин к IDE писали, то там все на этих "точек" входа (уверяю вас вы такого их количества в жизни не видели) сделано. И все равно идеологически там изменения предполагается идут одновременно для нескольких файлов (и в 95 процентов случаев это так), а если нужно сделать асинхронное изменения многих файлов, из-за особенностей архитектуры есть лаги, от которых никуда не уйдешь. А люди реально старались сделать чтобы к их IDE можно было прицепить все что угодно, но все варианты в принципе не учтешь.

Ну и с нормальной платформой и открытыми исходниками все же гораздо проще, чем выискивать нужные точки входа.
это иллюзия, но она дает работу кодировщикам программного кода, что в принципе не плохо. Но это заход с другой стороны. И откуда вы знаете что я видел, а что нет. И о какой еще IDE вы говорите? Посмотрите шире, за рамки той IDE, которой пользуетесь.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408278
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieНу и с нормальной платформой и открытыми исходниками все же гораздо проще, чем выискивать нужные точки входа.
отдельно выделил...
С нормальной платформой действительно проще построить приложение так, чтобы эти самые "точки входа", как вы их называете, а на самом деле интерфейсы сервисов, были как на ладони, чтобы их не выискивать. Но в отличии от переработки "лапшекода", как его называют, в такой архитектуре просто все делается другими способами
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408307
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmNitro_JunkieНу и с нормальной платформой и открытыми исходниками все же гораздо проще, чем выискивать нужные точки входа.
отдельно выделил...
С нормальной платформой действительно проще построить приложение так, чтобы эти самые "точки входа", как вы их называете, а на самом деле интерфейсы сервисов, были как на ладони, чтобы их не выискивать. Но в отличии от переработки "лапшекода", как его называют, в такой архитектуре просто все делается другими способами

SOA в общем случае предполагает слабо связанную архитектуру, что в случае если вы хотите скажем чтобы у вас расчеты были интегрированы с кассой, управлением заказами и т.п. (утрировано например на кассе видеть остатки по соседнем магазине, когда следующий заказ, есть ли задолженность по выплате кредита и т.п.) невозможно сделать. То есть важно понимать что SOA - это ограничение. То есть мы жертвуем функционалом (связанным с интеграцией) ради модульности, в то время как большинство тех же ERP платформ стараются этого не делать (жертвуя модульностью). Но для заказчика модульность это нечто абстрактное, а функционал - то с чем он сталкивается каждый день.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408315
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieSOA в общем случае предполагает слабо связанную архитектуру, что в случае если вы хотите скажем чтобы у вас расчеты были интегрированы с кассой, управлением заказами и т.п. (утрировано например на кассе видеть остатки по соседнем магазине, когда следующий заказ, есть ли задолженность по выплате кредита и т.п.) невозможно сделать. То есть важно понимать что SOA - это ограничение. То есть мы жертвуем функционалом (связанным с интеграцией) ради модульности, в то время как большинство тех же ERP платформ стараются этого не делать (жертвуя модульностью). Но для заказчика модульность это нечто абстрактное, а функционал - то с чем он сталкивается каждый день
какие-то открытия для меня, удивили. Каким функционалом вы жертвуете в SOA? Может за столько лет я действительно что-то упустил, все возможно
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408338
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmNitro_JunkieSOA в общем случае предполагает слабо связанную архитектуру, что в случае если вы хотите скажем чтобы у вас расчеты были интегрированы с кассой, управлением заказами и т.п. (утрировано например на кассе видеть остатки по соседнем магазине, когда следующий заказ, есть ли задолженность по выплате кредита и т.п.) невозможно сделать. То есть важно понимать что SOA - это ограничение. То есть мы жертвуем функционалом (связанным с интеграцией) ради модульности, в то время как большинство тех же ERP платформ стараются этого не делать (жертвуя модульностью). Но для заказчика модульность это нечто абстрактное, а функционал - то с чем он сталкивается каждый день
какие-то открытия для меня, удивили. Каким функционалом вы жертвуете в SOA? Может за столько лет я действительно что-то упустил, все возможно

SOA предполагает выделение четко определенных, условно "примитивных", интерфейсов взаимодействия. Причем во всех современных реализациях - императивных (то есть нужно делать интерфейсы одиночные и множественные, если скажем не хотите угрохать SQL сервер, запросами в FOR). Соответственно эти интерфейсы, становятся public все внутри остается private и не предполагает использование извне. Последнее и есть ограничение.

Если вы начнете все эти private'ы делать public'ами, тогда смысл SOA теряется. То есть его смысл что public'ов мало, а private'ов много, и все остальное следует из этого. Или вы считаете что SOA это логически(!) нечто другое? Если это чисто техническое понятие, то не понимаю какое это отношение имеет к архитектуре? То есть неважно вы общаетесь через веб-сервисы, RPC или хрен знает что, с проблемами кастомизации это абсолютно перпендикулярно.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408340
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkie,

вы кстати как-то не так понимаете что такое "слабая связанность". Говоря программерским языком это возможность замены одной функции на другую, без необходимости переделки для этого всего проекта. Это совершенно никак не коррелирует с тем, что все расчеты не могут быть интегрированы с кассой, несмотря на все на отсутствие всякого смысла в этом. Это и есть то, что называется "лапшекод", который через несколько итераций легче выкинуть и написать заново, чем поддерживать. Но так как это было абстрактным примером, то упустим.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408349
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_Junkieiscrafmпропущено...

какие-то открытия для меня, удивили. Каким функционалом вы жертвуете в SOA? Может за столько лет я действительно что-то упустил, все возможно

SOA предполагает выделение четко определенных, условно "примитивных", интерфейсов взаимодействия. Причем во всех современных реализациях - императивных (то есть нужно делать интерфейсы одиночные и множественные, если скажем не хотите угрохать SQL сервер, запросами в FOR). Соответственно эти интерфейсы, становятся public все внутри остается private и не предполагает использование извне. Последнее и есть ограничение.

Если вы начнете все эти private'ы делать public'ами, тогда смысл SOA теряется. То есть его смысл что public'ов мало, а private'ов много, и все остальное следует из этого. Или вы считаете что SOA это логически(!) нечто другое? Если это чисто техническое понятие, то не понимаю какое это отношение имеет к архитектуре? То есть неважно вы общаетесь через веб-сервисы, RPC или хрен знает что, с проблемами кастомизации это абсолютно перпендикулярно.
вы о чем вообще? SOA с ООП перепутали похоже. Или пытаетсь скрестить, как говорится "ужа с ежом". Какие паблики, какие приваты... Такого вообще в SOA нет
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408425
Nitro_Junkie
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmNitro_Junkie,

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

Вы не поверите, но отделение объявления от реализации, это концепция, которая называется процедура \ функция, появилась еще в первых структурных языках (читай FORTRAN). То есть вы пишете f(a,b), пишете ее реализацию и можете менять ее реализацию не переделывая весь проект.

А SOA это архитектурная штука в стиле давайте сделаем много больших блоков, свяжем их стандартизированными public интерфейс'ами, а внутри они могут изменяться как хотят. То есть по сути это идея это ОЧЕНЬ БОЛЬШИХ функций не более чем. И ограничение что эти большие функции не могут обращаться к внутренностям друг друга. Это и есть ограничение.

В любом случае готов услышать ваше определение SOA. Только не в стиле "облака белокрылые лошадки", а более предметное.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408498
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieВы не поверите, но отделение объявления от реализации, это концепция, которая называется процедура \ функция, появилась еще в первых структурных языках (читай FORTRAN). То есть вы пишете f(a,b), пишете ее реализацию и можете менять ее реализацию не переделывая весь проект.
почему не поверю? В юности на фортране сделал "а-ля Norton Comander" для VAX/VMS, так что поверю. Так работает любой функциональный язык.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408504
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieА SOA это архитектурная штука в стиле давайте сделаем много больших блоков, свяжем их стандартизированными public интерфейс'ами, а внутри они могут изменяться как хотят. То есть по сути это идея это ОЧЕНЬ БОЛЬШИХ функций не более чем. И ограничение что эти большие функции не могут обращаться к внутренностям друг друга. Это и есть ограничение.
какие еще паблик-интерфейсы? Вы явно пытаетесь скрестить ужа с ежом, уже говорил. А вымышленное вами ограничение не более чем вымысел. Где вы сталкивались с ограничениями, можете пример привести? Может что-то не так сделали...
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38408509
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nitro_JunkieВ любом случае готов услышать ваше определение SOA. Только не в стиле "облака белокрылые лошадки", а более предметное.
оно ничем не отличается от общепринятого, никаких лошадок. Тем более оно много лет работает в самых разных сферах. Я же не скрываю . Но в определении нет именно "моего", мое - в реализации.
...
Рейтинг: 0 / 0
Учетная система для ритейла
    #38409123
Коллеги,

вы все сейчас говорите очень абстрактными терминами.

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

И выходит, что каждый прав, но почему-то все спорят.

Я не хочу уводить эту ветку в сторону и привлекать к себе внимание. Но скажу конкретную вещь. Есть у нас своя собственная BI система, которая (естественно) качает данные из любой ERP (в том числе из Спрута - есть два внедрения).

Система состоит из двух частей:
1) клиентская часть (клиент + сервер приложений) - наш закрытый код
2) сервер "данных" - это ОЛАП сервер Microsoft Analysis Services, в котором "код ОЛАП-кубов" открыт (если так можно выразится - говорю так чтобы все поняли).

Соответственно, хотелки пользователей делятся на две категории:
а) те, где они хотят поменять что-то в формулах отчетов или в виде отчетов или в методах рассылки отчетов или в доступах - это все делается с кубами (где код открыт) средствами MS Visual Studio и не требует переписывание клиентской части вообще.
б) те хотелки, где пользователи начинают хотеть переделать что-то в софте.

Со вторыми сложнее. Например, захотели сделать запись статистики действий в базу - денег даже заплатили. Мы сделали. А теперь везде при развитии нового функционала (добавление новых действий) нам надо думать о том, чтобы туда запихнуть запись статистики... Якорь?

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

Вот вам конкретный пример. А вы тут высшими материями - SOA, и пр.
Слишком абстрактно мыслите. Можете привести свои примеры - с радостью прочитаю.
...
Рейтинг: 0 / 0
25 сообщений из 112, страница 3 из 5
Форумы / ERP и учетные системы [игнор отключен] [закрыт для гостей] / Учетная система для ритейла
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]