Потрібно якийсь бізнес-пакет з українським інтерфейсом - склад, каса, зарплата.
Простий, зручний в роботі.
Хто що порадить?Captivitas - 11-3-2004 у 12:05
прайс-листи програмного забезпечення від 1С до львівських розробок.Рост - 11-3-2004 у 12:21
прайс-листи - це добре, я б навіть сказав - чудово.
Але де би інформацію взяти, що то за програми, як надійність. Зрештою, демку злити,
подивитись, воно, чи ні?
Та і думка користувачів теж чогось важить...Андрій Пелещишин - 11-3-2004 у 12:46
Фенікс - http://phoenix.ridne.net - моя з колегами розробка. Щиро раджу.
Усе згадане там є, і притому на достойному рівні. Ми туди вклали і багато сил і,
головне, багато ідей. По яких доречи потім 2 дисертації захистили.
Якщо цікавить прошу в u2u або тут. Детальніше можна по пошті або при зустрічіРост - 11-3-2004 у 14:05
Дякую, але без українського інтерфейсу, та ще й під лінукса - нє пойдьоть. Треба з
українським і під вінду Рост - 11-3-2004 у 14:21
Дмитро Тарасов - 11-3-2004 у 16:43
Цитата:
Першим відправив користувач NetGuy
Потрібно якийсь бізнес-пакет з українським інтерфейсом - склад, каса, зарплата.
Простий, зручний в роботі.
Хто що порадить?
Інформаційна система ФЕНІКС
1. Комплексна фінансово-економічна інформаційна система (бізнес-пакет )
2. Український інтерфейс та документація
3. Основні функції :
- склад
- каса
- бухгалтерія
- банк
- торгівля
- виробництво
- зарплата
- основні засоби ...
4. Зручність у роботі:
- економить робочий час різноманітними засобами автоматизації (автоматичні
проводки, надбавки, генерація документів ...)
- використовує стандартний офісний інтерфейс
- гнучка система налаштувань під Ваші потреби
- працює у коп'ютерній мережі
- різноманітні аналітичні звіти ...
5. У використанні достатньо простий.
6. Особливості - потрібен МС Офіс 2000/XP.
7. Відкритий код
8. Ціна - недорого. Є безкоштовна версія http://phoenix.ridne.net/download.htmlДмитро Тарасов - 11-3-2004 у 19:34
З МС Офіса потрібен Access та Excel для роботи клієнтської частини Фенікс (форми для
введення даних, звітність, аналітичні засоби).Олексій Мачехін - 11-3-2004 у 20:15
Я сподіваюсь БД там хоча б не на акцессі?Андрій Пелещишин - 11-3-2004 у 20:51
Система виконана в архітектурі "клієнт-сервер" і в якості сервера може бути і
MS Access для простих випадків. Якщо середовище багатокористувацьке, то можна
використовувати серйозний сервер БД. Ми орієнтувалися на Oracle або Postgress.
Щодо продуктивності систем такого класу, то в будь-якому разі основні проблеми
виникають в наслідок невдалого проекту та коду системи, а не СКБД. Зокрема,
внаслідок того, що розробники не досконало володіють мовою запитів SQL і
опрацювання даних здійснюють за допомою процедурних мов. А це призводить до того,
що всі плюси СКБД зводяться нанівець.rost - 11-3-2004 у 22:20
Цитата:
Першим відправив користувач Андрій Пелещишин
Щодо продуктивності систем такого класу, то в будь-якому разі основні проблеми
виникають в наслідок невдалого проекту та коду системи, а не СКБД. Зокрема,
внаслідок того, що розробники не досконало володіють мовою запитів SQL і
опрацювання даних здійснюють за допомою процедурних мов. А це призводить до того,
що всі плюси СКБД зводяться нанівець.
Важко собі уявити, пане Андрію, людей, що беруться за розробку "систем такого
класу", недосконало володіючи мовою запитів SQL.
Крім того, те що ситема є мульти-платформна, в плані БД, як правило вказує на те, що
там в більшості випадків "опрацювання даних здійснюють за допомою процедурних
мов" бо крім простих SELECT, INSERT та UPDATE діалекти SQL для різних БД суттєво
відрізняються. З іншого боку те що"опрацювання даних здійснюють за допомою
процедурних мов" ще не значить, що ситема є неефективна. Мені доводилося мати
справу з титанами цього ринку такими як SAP, PeopleSoft, Great Plains, які є одноплатформними,
доводилося також мати справу з мульти-платформними системами.
Для прикладу система Agresso (новежсько-голладський продукт ~ 25% європейського
корпоративного ринку) - цілком БД незалежна (Access, правд,а в список не входить). Що
просто вражало -- понад 3 тис. таблиць системи і жодного тригера, не згадуючи вже
про stored procedures(підкажіть, як це буде українською). При тому доля ринку, яку утримує
цей продукт говорить сама за себе.
Те, що, "опрацювання даних здійснюють за допомою процедурних мов" свідчить не
про неефетивність самої системи, чи незнання SQL розробниками, а скоріше про те, що
розробники свідомо вибрали цей, завідомо важчий для них, шлях у випадку, коли
незалежність від вибору БД є важливим фактором маркетингу продукту.Андрій Пелещишин - 11-3-2004 у 23:00
Цитата:
Важко собі уявити, пане Андрію, людей, що беруться за розробку "систем такого
класу", недосконало володіючи мовою запитів SL.
Мені також було важко уявити. Але тепер уже ні. Зустрічався багато з такими.
Правда, то більше халтурщики, але в Україні вони на ринку переважають.
Цитата:
Крім того, те що ситема є мульти-платформна, в плані БД, як правило вказує на те, що
там в більшості випадків "опрацювання даних здійснюють за допомою процедурних
мов" бо крім простих SELECT, INSERT та UPDATE діалекти SQL для різних БД суттєво
відрізняються.
Вірно! Але в принципі саме DML нам і потрібен! А DDL хіба для процедур
встановлення/оновлення. Хоча по великому рахунку він тоже приблизно однаковий. А
відмінності у тонкщах, які не можуть розвязуватися в межах повністю
автоматизованих процедур (наприклад визначення усяких там параметрів типу
PCTFREE).
А я вважаю (хоча не буду розбивати свою голову у суперечці), що DML треба
використовувати стандартний, хоч як би кортіло запустити на повну потужність
можливості конкретної СКБД (типу кляузи CONNECT ... HAVING BY ... в Oracle).
Щодо західних систем - питань нема, це серйозні та потужні рішення. Але занадто
дорогі (особливо у впровадженні) для нас. Колись я чув від чоловіка, який
представляв SAP (я збережу його інкогніто), що заледве не половина підприємств не
може пережити впровадження R3 ( на теренах СНД ). Дуже вже модель бізнесу чи то
відрізняється, чи просто порядок треба наводити. Та й дорого.
Є ще ринок успадкованих систем. Там мови запитів також не використовуються, але то
вже просто тому що вони старі. Деякі наші офшорщики їх тут трохи підправляють,
доробляють, оновлюють. То вони (офшорщики) трохи від них (кодів систем) плюються.
Хоча знову ж переконувати не буду, бо сам глибоко в їхню працю не вникав.Андрій Пелещишин - 11-3-2004 у 23:09
Цитата:
Що просто вражало -- понад 3 тис. таблиць системи і жодного тригера, не згадуючи вже
про stored procedures(підкажіть, як це буде українською)
Говорячи про те, що розробники не використовують SQL у повну силу, я зокрема і мав на
увазі, що цей свій недолік (а також елементарні помилки у проекті БД системи)
розробники компенсують використанням stored procedures & triggers, які звичайно вже
пишуться на процедурних мовах з можливим вкрапленням SQL (типу Oracle PL/SQL).
Тому відсутність трігерів на стороні сервера БД (за винятком певних специфічних
випадків) - це (на мою думку) ознака зрілості системи.rost - 11-3-2004 у 23:19
Цитата:
Першим відправив користувач Андрій Пелещишин
Дуже вже модель бізнесу чи то відрізняється, чи просто порядок треба наводити. Та
й дорого.
Не думаю, що бізнес-моделі відрізняються аж на стільки. В умовах України основним
фактором, думаю, є ціна. Посудіть самі, ліцензія того ж Agresso, в залежності від
кількости блоків функціональності, починається десь з $60,000 і може сягати до $2,000,000
(імплементація в ціну не входить, про імпорт, даних із попередньої системи навіть
мова не йде). І це один з дешевших корпоративних пакетів. Звичайно, за гроші такого
порядку, в Україні можна розробити віддточену під власні потреби систему з нуля,
не кажучи про ринок готових систем.Олексій Мачехін - 11-3-2004 у 23:35
Мені чомусь не дуже віриться в потужну систему на акцесі. Дуже він багато ресурсів
їсть і швидкість обровки.....
але універсальність платформи то в будь-якому випадку великий плюсrost - 11-3-2004 у 23:41
Цитата:
Першим відправив користувач Андрій Пелещишин
Тому відсутність трігерів на стороні сервера БД (за винятком певних специфічних
випадків) - це (на мою думку) ознака зрілості системи.
Ну з цим дуже важко погодитися. Сила stored procedures(як же ж це називається українською?)
& triggers в тому, що вони працють на стороні сервера БД. І в цій частині адекватного
рішення на процедурних мовах буди не може. Так, що їх відсутність в системі не може
говорити про зрілість системи, але в кращому випадку про компроміс, на який пішли
розробники, добиваючись платформної незалежності.Андрій Пелещишин - 11-3-2004 у 23:55
Я не стільки про stored procedures як про triggers. З досвіду знаю - ними часто компенсують
невдалу структуру БД, а саме, коли не було комплексного проекту, а потроху щось
доштуковувалося, схема денормалізувалася, і треба було рятувати цілісність даних
штучними способами.
Хоча є ряд спеціальних випадків, коли обмеження сучасних СКБД роблять
використання тригерів необхідним.
Росте, ПРОЦЕДУРИ (навіть якщо вони сторед) все рівно пишуться на ПРОЦЕДУРних
мовах.Дмитро Тарасов - 12-3-2004 у 15:29
Цитата:
Першим відправив користувач Olexiy
Мені чомусь не дуже віриться в потужну систему на акцесі.
Замовнику вистачає потужності Access - значить ставиться під Access. Система Фенікс
достатньо продумана та ефективна для того щоб працювати з Access. Не вистачає Access -
Фенікс ставиться на сервер БД (СУБД).
Стосовно збережених (серверних, stored) процедур та тригерів - часто доводилось
спілкуватись зі "спеціалістами" які не розуміють особливості реляційних БД
та не використовують на повну силу потенціал SQL та DML.
Замість проектування схеми БД під задачу збереження та опрацювання даних за
допомогою SQL, БД проектується як довісочок до процедур. Тобто БД виглядає як дамп
пам'яті різноманітних процедур.
Функції таких систем реалізуються не за допомогою реляційної алгебри,
реляційного числення, а алгоритмами (інколи занадто складними в силу своєї
штучності у БД).
Взагалі теми фундаментальних та прикладних проблем БД та впроваджень ІС дуже
цікаві. Якщо є бажання поспілкуватись - піднімайте нову тему, і про R/3 і про
кількість таблиць і про тригери поговоримо.rost - 12-3-2004 у 20:52
"Замість проектування схеми БД під задачу збереження та опрацювання даних за
допомогою SQL, БД проектується як довісочок до процедур"
"коли не було комплексного проекту, а потроху щось доштуковувалося, схема
денормалізувалася, і треба було рятувати цілісність даних штучними
способами."
Це дуже дивно чути. Але, це напевне, один з результатів, того, що час програміста
коштує дешево. На Заході таку ситуацію важко уявити, бо рідко хто собі може таке
дозволити, а той хто міг би, то його вже завтра нема.
Я чесно кажучи не навіть не бачу грунту для дискусії. Відмовлятися від чогось
тільки тому, що хтось тим неправильно користувася це все одно, що відмовитися від
вживання кухонного ножа, бо сусід ним колись порізався.Дмитро Тарасов - 12-3-2004 у 23:34
Ніхто не відмовляється від тригерів та процедур. Є ситуації, коли без них не
обійтись. Але і зловживати ними не слід.
На українському ринку ПЗ прикладів таких зловживань багато. У тому числі завдяки "спеціалістам" та рівню оплати праці.Громов Сергій - 7-7-2004 у 09:11
.... а в мене Фенікс не пішов - чи версія офісу
не та, чи ще якась біда !
І взагалі, моя думка, що замут "під офіс" - це не є добре ! Не всяка
фірма(фірмочка) розкошелиться на купівлю вінди, а потім ще й офісу !!!!!
Я от давно, коли 1С сильно розкрутилася, був поставлений перед фактом - зробити
бухгалтерію+склад - все_в_одному замість 1С. Оскільки я працював сам/один, то й мало
що зробив, але де-які фірмочки у Львові таки взяли на озброєння ... От зібрати б
команду, да довести до рівня Фенікса !!!!Андрій Пелещишин - 7-7-2004 у 11:46
Цитата:
.... а в мене Фенікс не пішов - чи версія офісу не та, чи ще якась біда !
Sergo, просто звяжіться з нами.Громов Сергій - 7-7-2004 у 11:52
Ну я ніби послав листа ... ще раніше, ніж написав у форум - на phoenix@ridne.net
У тому числі завдяки "спеціалістам" та рівню оплати праці.