Почему нет отечественных программ для бизнеса?

[Aectann]

А про линукс в данной теме никто ниче не говорил.

Название форума и то, что раздел тематический, как бы намекает...

[villager]

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

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

на Windows пространстве этот инструмент есть - 1ц. А в "свободном" мире аналога не нашел. А надо сделать еще проще чем 1ц. тогда народ потянется, и появятся эти самые "программы для автоматизации бизнеса".

а обсуждать маркетинг несуществующих продуктов - ИМХО пустое дело

[trdm]

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

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

на Windows пространстве этот инструмент есть - 1ц. А в "свободном" мире аналога не нашел. А надо сделать еще проще чем 1ц. тогда народ потянется, и появятся эти самые "программы для автоматизации бизнеса".

+500 правильно мыслишь.
НО: сделать просто очень трудно.

[Stasroot1]

А разве нельзя сделать прогу по учету на PHP + MySQL ? И все пропускать через вебсервер? вот тебе и клиенты и сервер удаленый. а клиентов может быть столько сколько надо. Ну в конце концов делать по этой архитектуре локальную версию и по крону например синхронизироваться, или синхронизироваться по запросу, например когда речь идет о покупке товара в офисе фирмы, а склад находиться в десятках км.... ну чтобы конфликтов не возникало с количеством имеющеося на складе и купленного товара в офисах/представительствах фирмы. Это что касаеться учета товаров... зарплата.... наверное проще реализовать чем товары. бухгалтерия... чесно пизнаться уровень мох знаний в бухгалтерии не высок (его нету) но помоему через вебтехнологию можно формировать любой документ. Или заранее формировать щаблон, в него после только через вебмору вписывать даные... и на печать если надо.

Что по этому поводуц скажите? Интересно... Все что выше прочитал досконально. Надо только архитектуру БД продумать как клиетских так и основной... Места хранения. И вовсе не обязательно что будет ОДНА БД. Их может быть НЕСКОЛЬКО... часть баз данных под собственно данные, а часть баз данных под управление данными в других БД. Ну чо то такое.

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

а для дозаточки под конкретное предприятие использовать имеющийся в комплексе набор ПО и возможно привлекать к работе спецов по вебпрограммированию.

[BIgAndy]

Лично я пас. Работа должна стоить денюх....

Хорошо, что нашлось как минимум три человека (один не член форума и даже не линуксоид), которые откликнулись.
Они думают несколько по-другому.
Выгода бывает и отложенной. Ибо тогда бы и не было бы СПО и линукса в том виде, котором он сейчас существует

[Voral]

А разве нельзя сделать прогу по учету на PHP + MySQL ?

Естественно можно. Отчеты можно генерировать для печати в PDF. А остальное какая разница.
Тут единственный минус. Могут (в принципе) возникнуть мелкие неудобства по интерфейсу. Но это не так страшно.
Самое главное, что проще от этого задача для разработки не станет.

А вообще я себе уж давно "домашнюю бухгалтерию" сделал.

Что по этому поводуц скажите? Интересно... Все что выше прочитал досконально. Надо только архитектуру БД продумать как клиетских так и основной... Места хранения. И вовсе не обязательно что будет ОДНА БД. Их может быть НЕСКОЛЬКО... часть баз данных под собственно данные, а часть баз данных под управление данными в других БД. Ну чо то такое.

Репликация.
Это так же не имеет отношения ни к выбору языка ни к выбору СУБД.

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

Не сложнее такой вариант. Трудозатраты одинаковы.
Тут даже (возможно) можно получить некоторый выигрыш путем использования готовой CMS.

[trdm]

Лично я пас. Работа должна стоить денюх....

Выгода бывает и отложенной. Ибо тогда бы и не было бы СПО и линукса в том виде, котором он сейчас существует.

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

[watashiwa_daredeska]

А пока май менталитет: работа должна стоить денюх.

Нормальный «колхозный» менталитет.

[trdm]

А пока май менталитет: работа должна стоить денюх.

Нормальный «колхозный» менталитет.

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

[Voral]

А пока май менталитет: работа должна стоить денюх.

Нормальный «колхозный» менталитет.

А так: "семья должна быть обеспечена"
Последний мой работодатель, как то сказал: "У тебя на первом месте должен быть коллектив, а семья лишь на втором месте"... Догадайтесь, что какая фраза была у меня в голове в ответ...... я просто уволился через пару месяцев....

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

Легко сказать "колхозный" менталитет.

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

Что самое интересное ни кому не приходит в голову (раз уж программа нужна многим) скинуться (с миру по копейке, а разработчик сможет целиком заняться данной разработкой)

[trdm]

Что самое интересное ни кому не приходит в голову (раз уж программа нужна многим) скинуться (с миру по копейке, а разработчик сможет целиком заняться данной разработкой)

И правильно, что не приходит. Пока "Программа" - это абстрактный конь в вакууме. Другими словами: афера.
Иным образом я бы посмотрел на ситуацию, когда сюда бы пришел заказчик со сформированным списком требований, надо то-то, то-то и то-то.
Плачу столько-то, использовать то, то и то.
Это было бы уже пол дела. Но за такой информацией лучше пойти сюда: http://www.flance.ru/

[Voral]

И правильно, что не приходит. Пока "Программа" - это абстрактный конь в вакууме. Другими словами: афера.

Вот и я про то. Сразу открестились.... Может быть это тоже "колхозный" менталитет? Типа "пусть кто-то сделает и может быть он потом дивиденты с этого получит (но опять с кого-то, а не с меня)".... Нравится мне такой подход к опенсорсу. Вы не хотите рискнуть 5ю рублями в месяц, и не понимаете почему человек не хочет "рискнуть" более серьезной суммой?


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


Согласитесь. Каким бы аскетом не был разработчик, как минимум ему надо есть, платить за коммунальные, за интернет. Таким образом любая программа имеет свою себестоимость. Вы предлагаете, что бы все расходы полностью легли на него. А если эти расходы разделить на 10000 человек? Может тогда ему и аскетом не придется быть и те 10000 помогающих совершенно не обеднеют?

[Stasroot1]

А разве нельзя сделать прогу по учету на PHP + MySQL ?

Естественно можно. Отчеты можно генерировать для печати в PDF. А остальное какая разница.
Тут единственный минус. Могут (в принципе) возникнуть мелкие неудобства по интерфейсу. Но это не так страшно.
Самое главное, что проще от этого задача для разработки не станет.

А вообще я себе уж давно "домашнюю бухгалтерию" сделал.

Что по этому поводуц скажите? Интересно... Все что выше прочитал досконально. Надо только архитектуру БД продумать как клиетских так и основной... Места хранения. И вовсе не обязательно что будет ОДНА БД. Их может быть НЕСКОЛЬКО... часть баз данных под собственно данные, а часть баз данных под управление данными в других БД. Ну чо то такое.

Репликация.
Это так же не имеет отношения ни к выбору языка ни к выбору СУБД.

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

Не сложнее такой вариант. Трудозатраты одинаковы.
Тут даже (возможно) можно получить некоторый выигрыш путем использования готовой CMS.

Например CMS DRUPAL. Сложновата для въезда, но потом становиться довольно простой. Может действительно создать сайт для проекта и на этом сайте развивать все что касаеться малог прежде всего бизнеса. Я скажем может быть смогу для проекта хостинг оплачивать. На нем постепенно провести обсуждение необходимых вещей и расставить приоритеты. и далее приступить к написанию ТЗ (плана действий подробного с возможностью корректировки по мере развития проекта, ведь он не статичен.) На все про все пару месяцев. дале писать систему по набору выработанных требований. Для программы надо создавать сообщество пользователей обязательно реальных.

[Voral]

Например CMS DRUPAL. Сложновата для въезда, но потом становиться довольно простой. Может действительно создать сайт для проекта и на этом сайте развивать все что касаеться малог прежде всего бизнеса. Я скажем может быть смогу для проекта хостинг оплачивать. На нем постепенно провести обсуждение необходимых вещей и расставить приоритеты. и далее приступить к написанию ТЗ (плана действий подробного с возможностью корректировки по мере развития проекта, ведь он не статичен.) На все про все пару месяцев. дале писать систему по набору выработанных требований. Для программы надо создавать сообщество пользователей обязательно реальных.

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

Хотя ценовую политику еще и не продумали конкретно.

[BIgAndy]

Не подумай, что я такой уж сухарь, ....
А пока май менталитет: работа должна стоить денюх.

ДА не надо оправдываться! Это нормальное состояние. Потом, может и переменится состояни и появится желание и возможность помочь.
На первых этапах FOSS проекты, если не мейнтейнятся одним человеком, продвигаются сложно и медленно как раз из-за частйо смены людей. Это все как раз понятно. Если будет кусок хлеба, в первую очередь надо его ухватывать.
Поэтому они (проекты) должны строится так, чтобы каждый мог сделать маленький фрагментик работы, но чтобы этот фрагментик был работоспособным на 200% и его моно бюыло использовать в дальнейшем...
Тоесть принцип KISS в действии!!!
[hr]

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

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

Мои приблизительные и самые общие выкладки (нет сил публиковать подробный issue)

Архитектура - клиент-серверная.
Основная логика должна быть реализована на базе RDBMS. Подходящие для меня RDBMS (в порядке убывания юзабилити)- DB2, Postgresql версии 8.4 и старше, Oracle (оракл, скажем так на границе юзабилити, хотя большинство изучает как раз оракл). Ни в коем случаае не MySQL. Это многократно уменьшит количество кода для приложений и станут ненужными куча проверок на consistent состояние записей БД средствами приложения. Уменьшит затрты на проектирование распределнных систем.
Не спрашивайте почему. Анализом занимались года полтора.

Разграничение компетенции (или что еще называют разграничением прав доступа) на уровне RDBMS. Средствами RDBMS можно привязать PAM для аутентификации пользователей RDBMS. Это нужно для того, чтобы одной структурой БД можно было пользоваться с различных рабочих мест где работают люди с разной компетенцией но со схожими полномочиями.
Например, Завскладом должен иметь информацию о Товаре: источник поступления, флаги критических запасов, цену хранения, условия хранения, место хранения. Клоадовщик же должен только знать остаток, место хранения, условия хранения,

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

Струтура приложения должна исключать необходимость привлекать для вода данных специалистов (бухгалтеров или серкретарей, например для работы на складе). Когда мы анализировали возможности различных штатных систем учета (1с, парус, ТурбоБухгалтер и проие), то получалось, что на распределенное предприяти с 25-ю "Синими воротничками" нам прищлось бы содержать дополнительные 3-5 рабчих мест бухгалтеров по первичке. Для приведения првичной документации в удобоваримый для бухпрограмм вид. А также для треккинга документов и постоянной проверки на соответсвие реальным бизнес-процессам.

Составляющие части (программы) оперативного учета
Учет товарно-матеиальных ценностей. (структура учета для денежных средств и товарных средств одинакова, мпоэтому модуль может быть единым. по крайне мере у нас этот модуль обслуживает один и тот же участок БД Resources c одними и теми же алгоритмами.
Учет кадров.
Производственный учет. Это наиболее сложная часть программы. Очень неоднозначная
Учет и управление техничесими стредствами (автомобилями, станками, оборудованием и пр.) Очень важно для автоматического контроля необходимых процессов по обслуживанию данной области бизнеса, отслеживанию соимости владения, амортизации, износа (как бухгалтерского так и чисто технического) и пробега.
Транспортный учет. (учет перевозок своим и сторонним транспотом)
Модуль контроля ( для контроля действий работников при работе с данными)
Модуль оптовых и розничных продаж. Отрадное явление. С мая-июня пользуем для учета розничных продаж ДЕнси:касса. очень довольны.





Приложения должны реализовыать принцип не "Оформил документ, значит ты выполнил свои обязаности, а ты выполнил свои обязанности, если провел все бизнес-правило вплоть до оформления документа.


Вот так вкратце. В первичном ТЗ много чего. почти 140 страниц одног только текста без блок-схем.

[watashiwa_daredeska]

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

А я и не говорю о всеобщем счастье.

Доживете до моих лет, дай бог сообразите.

Не знаю, какие Ваши годы, но сообразил я это очень давно.

[Voral]

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

Вот это уже деловой разговор. Может выделить в отдельную тему - что бы там не было лишнего флуда. Тут надо немного поформулировать сначала.

Как затравку думаю не стоит ориентироваться на php и mysql....

[trdm]

Не подумай, что я такой уж сухарь, ....
А пока май менталитет: работа должна стоить денюх.

ДА не надо оправдываться!

Что значит оправдываться? Кто тут оправдывается?

[villager]

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

Вот это уже деловой разговор. Может выделить в отдельную тему - что бы там не было лишнего флуда. Тут надо немного поформулировать сначала.

Как затравку думаю не стоит ориентироваться на php и mysql....

похоже на конкретный разговор!

мои 5 копеек:
про архитектуру и функциональность говорить рано ИМХО. Ясно, что данные в БД, и ХП будут, и права доступа и все такое... И учет ТМЦ и прочая фигня...
но для начала нужен доступный инструмент для отображения всего этого на экране (интерфейс), и на бумаге - генератор отчетов. Я уже писал чуть выше про конструктор.

я чуть больше года занимаюсь в свободное время этой проблемой. Инструмент - python+Qt. Польза от питона - не надо думать про встроенный язык - это питон (бесшовный доступ ко всем внутренним объектам системы).
на сейчас есть такое:
описание интерфейса пока хранится в 3 таблицах - информация о таблицах, полях, режимах отображения, действиях, там же - куски кода для отработки событий. Из этих же таблиц берется инфа для контроля целостности БД, создания системы меню - все на ходу собирается, простейший результат (справочник ТМЦ) на картинке:

разработка конкретной учетной системы сводится к набору структуры таблиц, задания связей между ними и кодировки отдельных кусков, отвечающих за логику работы системы.
До самих отчетов еще не дошел, но технику генерации PDF/RTF/HTML отчетов на основе БД уже отработал.
Все настроечные таблицы хранятся в отдельной БД, и могут легко переноситься.

сейчас делаю демо-приложение - учет ТМЦ. Медленно. Приходится что-то переписывать, что-то новое прикручивать


Мне интересно - у кого какие мысли на эту "инструментальную" тему?

[BIgAndy]

Мне интересно - у кого какие мысли на эту "инструментальную" тему?

После многих дерганий (с+ qt, fpc+qt (о ужас!), Gambas) остановились на ООBase.
На удивление оказался развитый язык и наудивление получаются стабильные приложения.
Генератор отчетов не самый плохой для *nix...
Некоторые особенности позволят избежть лишнего кодинга. И (трам-тарарам!! Бьембарабан) Поддержиывает транзакции. Одним движением путем установки autocomit=0 (false))
Ессно в качесве бекенда нельзя пока использовать HSQLDB, но Postgres/db2 вполне себе очень ничего.

первый этап - создание что-то-типо БизнесПак

[Voral]

После многих дерганий (с+ qt, fpc+qt (о ужас!), Gambas) остановились на ООBase.

А какую базу он может потянуть по размеру?

первый этап - создание что-то-типо БизнесПак

Полностью поддерживаю такой ход мыслей

[trdm]

После многих дерганий (с+ qt, fpc+qt (о ужас!), Gambas) остановились на ООBase.

что такое "fpc"?
гамбас знаю, сам заглядывался..

первый этап - создание что-то-типо БизнесПак

это конструктор или нечто большее?
ПС. Посмотрел бизнес-пак. Прикольно конечно, но изврат тот еще....

[Stasroot1]

хм... я не берусь что то конкретно утверждать. но пожалуйста объясните почему не php и mysql? Я понимаю что вы можите спросить у меня в свою очередь, а мол какие я вижу плюсы минусы в этом. я пока промолчу наверное. Что касаеться програмистов, я не програмист, в лучшем случае вебкодер (если опятьже можно так выразиться).

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


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

[BIgAndy]

А какую базу он может потянуть по размеру?

Ему пофигу какая база по размеру. ООо - просто фронтенд. наша база содержит одинадцать таблиц, главные операционныек которые содержат до 900000 записей. ООbase прекрасно с ней работает.
Неговоря о некоторых запросах, которые иногдагенерируют union временные запросы по несколько миллионов записей. Благодаря RDBMS до OObase доходят только несколько сотен строк.

Категорически не рекомендую использование идущей прицепом к ООBase HSQLDB. Уж не оворя о том, что RDBMS на java - моветон, она крешится при любом чихе. Так, "на попробовать" можно. например, HSQL DB при union all таблиц всего по 10тыс записей делает этот самый union минут за пять.. (всего получается 10¹⁰ промежуточных записей., что для нормальной RDBMS - пару раз плюнуть, и делает менее чем за две секунды.)

[BIgAndy]

хм... я не берусь что то конкретно утверждать. но пожалуйста объясните почему не php и mysql? Я понимаю что вы можите спросить у меня в свою очередь,

Gочему не php? Потому что больно уж большой паразитный трафик генерит. И уж слишком слабо развиты интерактиные компоненты, бизнес-компоненты (элементы бизнес-логики). Уж лучше (правда лучше) веб-два-нол/ajaks, но он генелит еще более трафика/. (посмотрите на ticket.rzd.ru)

Про MySQL вообще промолчу. Функции и триггеры находятся в зачаточном уровне, если я скажу про тормоза при выполнении совершенно обычных для бизнес приложений запросов, меня наверное закидают здесь плюсометами, но это так и испытано не раз. были попытки у привлеченных разработчиков, но те же DDL применненые в DB2 генерили в разы более компактную БД, не гооря о сложных запросах.
Для веб - это более чем достаточная RDBMS. Но для серьезных приложений, пока "Ой".

а мол какие я вижу плюсы минусы в этом. я пока промолчу наверное.

Да нет.. Очень интерсно. дляэтого и сделал "вброс"..

может тонкоклиентносерверная архитектура? В этом случае нет надобности в "Серьезном железе" для клиентов.

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

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

Все еще хуже. Потребуется коммунити и саппорт и прочие (г)радости.

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

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

[villager]

После многих дерганий (с+ qt, fpc+qt (о ужас!), Gambas) остановились на ООBase.
На удивление оказался развитый язык и наудивление получаются стабильные приложения.
Генератор отчетов не самый плохой для *nix...
Некоторые особенности позволят избежть лишнего кодинга. И (трам-тарарам!! Бьембарабан) Поддержиывает транзакции. Одним движением путем установки autocomit=0 (false))
Ессно в качесве бекенда нельзя пока использовать HSQLDB, но Postgres/db2 вполне себе очень ничего.

первый этап - создание что-то-типо БизнесПак

ООBase - никогда не интересовался - это Access для linux? или поинтересней будет? (на Access никогда бы не стал ничего серьезного делать)
но интерсно взглянуть на скриншоты Ваших программ

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

БизнесПак - это Pvision.ru? внешне не понравился, но это дело вкуса (люблю меню и окна)

[trdm]

хм... я не берусь что то конкретно утверждать. но пожалуйста объясните почему не php и mysql?

да потому что нафиг. Я про php.
Десктопные приложения проще писать, чем для www при сопоставимом функционале.
Отклик больше, контроль лучше, возможностей больше.
WWW - это грубо говоря 1 полотно (если чисто php) и как хочешь, так и крутись. А десктоп - многооконка, уже легче.

....может надо что то подобное ядру системы разработать.....

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

[Stasroot1]

Да нет.. Очень интерсно. дляэтого и сделал "вброс"..

Честно говоря не могу так вот аргументировать за / против и не хочу сильно тут раскачивать это. php/mysql довольно сильно распространена и довольно многое можно сделать на ней. говорим мы тут приимущественно о малом и может о среднем бизнесе, вот статейка из википедии, там есть ссылка на ФЗ о развитии малого предпринимательства что то такое...: ссылка на википедию по статье о малом/среднем бизнесе


Исходя из статьи и моих текущих знаний, возможно немного устаревших, разве 250 человек могут представлять реальную угрозу стабильности работы веббазированного решения? Трафик? Ну в основном он возможно будет локальным, да склад может находиться и за пределами головного офиса, ну может пара другая представительств в других местах... Если же мы беремся за разработку ПО для крупных предприятий то извините тут пожалуй соглашусь... несколько тысячь клиентов одновременно могут что хош порушить. ИМХО.

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

[Stasroot1]

хм... я не берусь что то конкретно утверждать. но пожалуйста объясните почему не php и mysql?

да потому что нафиг. Я про php.
Десктопные приложения проще писать, чем для www при сопоставимом функционале.
Отклик больше, контроль лучше, возможностей больше.
WWW - это грубо говоря 1 полотно (если чисто php) и как хочешь, так и крутись. А десктоп - многооконка, уже легче.

....может надо что то подобное ядру системы разработать.....

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

Учить ни кого не собираюсь у меня слишком ниска наверное для этого квалификация.

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

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


Кто запрещает использовать несколько окон/вкладок браузера? вовсе не обязательно чистый php надо использовать все что доступно в WWW.

[trdm]

После многих дерганий (с+ qt, fpc+qt (о ужас!), Gambas) остановились на ООBase.

Опен-офис у меня на винте занимает: 380 МБ (398 872 576 байт)
Это по вашему нормальный размер для обслуживания программы?
+ при старте ООBase потребовала JRE о_О.
чета мне не нравится ваша задумка...
+ без JRE не дает запустить "Мастер создания таблицы".
фейк короче. зря ты c++/Qt отбросил...