Linux за българи: Форуми

Какво ли не опитвах, мъчих се ,бях упорит, не се отказвах, инсталирах всичко нужно, за да успея да пусна някоя от следните програми: biona, warehouseopen и integrator2. Ами какво да кажа, не съм глупав, но не успях да докарам до работещо състояние нито една от тях. Мисълта ми е има ли нужда да се направи един PHP+MySQL проект, който да върши същите неща. Предимствата са ясни: освен че всеки може да си сложи нужните неща без толкова проблеми (има го на почти всяка дистрибуция), дори за windows има специални пакети, работят върху всичко без изисквания за операционна система, само с помощта на браузър, а и може да имате достъп от всяка точка, където има интернет. Нещо подобно на това:
http://www.microinvest.net/warehouseproweb.php
Само че напълно безплатно. В последствие ще се разширява и ще се добави, счетоводство, платежни нареждания и т.н.
Какво мислите, да започвам ли или да направя нещо за себе си само, което ще ми върши работа?

Не само съм на мнение, че е необходимо, но от известно време съм си поставил за задача да подхвана подобен проект.
Т.е. давай и казвай от какво имаш нужда - да видим с какво можем да помогнем!
Аз бях харесал идеята на      
ERPix :: Единна система за управление на корпоративни ресурси, но от края на миналата година там нищо не се случва .

пробвайте да направите нещо в openfmi.net  

аз успях да инсталирам WarehouseOpen версията за линукс

ако имаш нужда от помощ - кажи и ще драсна няколко реда

П.П.с gentoo съм и за инсталацията съм ползвал пакетния му мениджър, а не начина описан на сайта на микроинвест

здравей, аз съм автора на Integrator2 - в момента спрян и свален от WEB. Искам да само да допълня въпроса ти:
Има ли нужда въобще от БЕЗПЛАТЕН такъв софтуер? Опита ми показва (имам вече 3 разработки на тая тема), че това е широкомащабна работа, която не е по силите на един човек, още повече, не е по силите на човек, който се занимава на доброволни начала (разбирай без спонсориране). Та от тази гледна точка такъв софтуер не трябва да е безплатен, не трябва да е дори под GPL, защото в повечето случаи ще съдържа фирмуер (firmware) който едва ли трябва да бъде публичен , и не е проблема с какви инструменти се разработва, проблема е в самата идея на разработката,... и поддръжката.
Още веднъж - кому е нужен такъв софтуер, ако е за една фирма - вж. казаното от мен по горе, ако е просто за любителско занимание в свободното време - ... чиста загуба на време
Със здраве, и не се предавай

въпроса в случая не е дали софтуера да е безплатен, а да е с отворен код.
на разработчика нищо не му пречи (дори е препоръчително) да си събира някакви такси за поддръжка. или ако някой иска допълнителна функционалност, която да се вкара в софтуера.
а отворения код дава възможност за постоянно развиване на софтуера и възможноста всеки с нужните познания да добави нужната му функционалност.

Пък и защо да е без спонсори?
Пък ако доживеем да се инсталира и настройва с два бутона - пак остава възможността да се търси заплащане за поддръжка и за първоначално внедряване, което по принцип е достатъчно стига да знаеш как да подходиш.

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

Или както е казал Радостин Раднев в своето произведение - безплатен обяд има само ако можеш да готвиш!

и аз съм на мнението че има други начини за събиране на пари от GPL софтуер .. примерно ... поддръжка или допълнителни функционалности, които да се доплащат .
       

идеята за php/mysql Складов, Счетоводен, ТРЗ и подобен софтуер не е от вчера, обаче самата идея за php води след себе си проблема за интерфейса, как да се създаде такъв интерфейс, който хем да е удобен, хем да сигурен, какъв вид да се избере: qt/gtk, curses, web/html, изобщо проблеми бол. Самата работа с данни не е толкова сложна, но клиента като вземе да каже: искам да виждам данните така и така, да мога да правя това и това в интерфейса и воловете се отелват Който има нерви да се занимава. Определено има нужда от такива продукти, особено такива, които могат да осигурят поддръжка на клиентите си. Тъй като последните са страшно капризни

Хм. става интересно...
Разбира се че има много начини за изкарване на пари от GPL код, но не това беше (и е!!! проблема, проблема е в самото начинание, както казах по горе, кому е нужно, колко фирми ще се навият - 1, 2 най-много. А в този случай според мен има 2 варианта:
1. вар. Фирмата да ви наеме да разработите такъв софтуер
2. вар. Да имате готов разработен и да го пуснете под GPL

В първия вариант няма нужда от GPL - в 90% фирмата ще иска кода да е затворен, най вече заради т.нар. firmware. Допускам възможността за допълнителни модули - но само човек, работил по темата ще обясни колко са трудностите с това - много по лесно е да вмъкнеш firmware директно в кода, от колкото да правиш модул - говоря от опит. off: (приемам упреци само от хора които имат зад гърба си поне 100000 реда код на такава тема

Във втория вариант проекта като цяло е безполезен - в света на бизнеса (особено в България) на такива системи не се гледа реално за сега. Освен това трите горепосочени проекта са нефункционални, поне не за реална работа, така че ако има желаещи фирми, разработчика ще бъде принуден да се задоволи отново с вариант 1, колкото и благородни да са му идеите... Нека да не сравняваме такъв род системи с нещо от рода на КДЕ/ГНОМ или някоя друга програмка... тука пазара, разбирайте търсенето, е ограничен, броя на потребителите в България няма да надхрърли 50-60, дори и след 5 г.

Разбира се, има успешни такива проекти - Compiere, tinyERP, май за други не се сещам, но колко са фирмите, които ползват tinyERP например - едва ли са повече от 50, а в България знам само за една - и тя (доколкото имам инфо) е модифицирала кода, но няма да го отвори

Отново ще попитам - кому е нужен такъв, след като имаме (имахме) 3 такива проекта, колко реални приложения в реални условия имаме - не знам, може би само biona да имат някъде...прочее, MaX_Ass, подкарай някой от тях, направата на нов проект е загуба на време, определено докато се опитваш да подкараш някой от тия проекти, ще ти хрумне  и идеята как да ги преработиш за по лесна употреба - Вярвай ми - по безболензено е

Въобще не съм на мнение, че няма да се намерят потребители за такъв софтуер.
Аз самия се наемам да намеря 20 магазина (които в момента работят с нещо под Windows) в които да се инсталира и използва първата стабилна версия! И не само, че ще я ползват, но дори ще платят по $100-200 на работно място за инсталация и настройка, а по-големите и повече. Като се има в предвид бюджета на Debian ми се струва, че това не е толкова малко.
След това ще намеря 50-100 човека, които се занимават с предлагане на подобен софтуер, които срещу възможността да не им се отказва поддръжка с удоволствие биха заделяли 10-20% от приходите си от инсталациите за разработчиците.
Трябва само организацията на проекта да гарантира, че няма да се налага да се молиш на програмиста да свърши това дето и без това трябва да го свърши, а това се постига до голяма степен със самия GPL лиценз и достъпа до кода.

Смятам, че е достатъчно да се съберем всички с подобен интерес и всеки да си свърши работата (тази дето така или иначе ни виси, а не тази която се очаква от проекта) и резулатата ще бъде на лице.
По-горе споменах ERPix и наистина се чудя какво се е случило с тях. Някой да познава някого от там?

Познавам човека който пише ерпикса, но и той като интегратора го внедрява в своята фирма и .... работата се закучва.
В тази ситуация (програмисти които си имат друга работа. и разни потребители със слаби познания по програмиране) остава да модифицират нещо като тиниерп-то и да чакат ...

Добре. Поемам инициативата да създам една основа, която лесно ще приема всякакви модули, създадени по един начин, който ще е обяснен подробно. След като е готов, го публикувам и всеки който желае се присъединява със свой модул. Аз например имам готови такива за изчисление на горива на товарни автомобили и един за кухня (със продукти рецепти и т.н.). Само трябва да се попроменят за да работят в новата среда. За склад все още нямам, но не мисля че е проблем Не се наемам със срок, но ако не стане до празниците, до средата на Януари ще го имаме.

п.с. Просто като дойде зима и ми се дописва код  

Мисля, че да правиш безплатен софтуер за продвачи.... не ми се вързва....

Четох с интерес темата.
По мое скромно мнение едва ли с екип от 1-2 човека на доброволни начала ще се прозведе нещо найстина "продаваемо".
за такива срокове от няколко месеца .

Естествено може и да греша ..

Като съвет - прегледай тази ЕРП система, има Live CD и е сравнително лесно да се подкара.
"ERP5": http://erp5.org

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

Тази идея ще роди ли нещо?

Ще роди естествено. В момента пиша, макар и за много малко време на ден. През Януари ще дам за тестове, какво съм направил.

Имам въпрос: Тази складова програма, колко нива потребители трябва да потдържа. Ще има ли такива, които могат да променят и такива, които само ще могат да разглеждат? Или всички да могат да променят?

USER_ROLES = (
    (1, 'Оператор' ),
    (2, 'Търговски агент' ),
    (3, 'Оперативен мениджър' ),
    (4, 'Търговски мениджър' ),
    (5, 'Маркетинг мениджър' ),
    (6, 'Продуктов мениджър' ),
    (7, 'Мениджър доставки' ),
    (8, 'Счетоводител' ),
    (9, 'Финансов мениджър' ),
    (254, 'Собственик' ),

може ли по-подробно защо не е добра идея?

Абе не знам добра идея ли е - ама не е ли добре - ако се прави нещо първо да се започне от спецификация за проекта и чак след това да се пише ?

ако ще се седи и се мисли само спецификация, ще брадясаме

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

MaX_Ass - относно правата за достъп, за елементарна работа е достатъчно да се дефинират поне четири привилегии на потребител:
- може да създава документ (boolean)
- може да изтрива документ (boolean)
- може да разглежда документ (boolean)
- може да пуска справки (boolean)

допълнително
- справките могат да съдържат колони за печалба или други по важни данни - интересни за собствениците (boolean)


това е на ниво "СКЛАД" , за другите модули ще се наложи пак да приемеш нещо по-сложно, като това по горе

Интересно е дали Ви интересува и мнението на един от архитектите на отворена система?
Както и опровергаване на глупостите в тази тема?

Не искам да се заяждам, ама много от нешата тук са празнодумие...

Ами, братко, vixon, кажи ги кои са и защо са такива и спести време на хората да си блъскат главите с идеи без изход?
Какви са тези въпроси?

Донякъде сте прави. Ако имаме дори само 2-ма служителя например един диспечер или оператор и един счетоводител, те не трябва да могат да променят данните на другия. Но пък често малките фирми нямат служители за всяка област от администрацията и затова един човек върши няколко неща. Мисля да подходя по начин, който ще разрешава или забранява промяната на информация за всеки модул. Тоест един потребител ще може да бута произволен брой модули, които администраторът му даде, без значение дали се казва оперативен мениджър или счетоводител.
Във всеки случай си правя всичко предимно удобно за мен. Аз поне ще го ползвам, за останалите това е въпрос на избор.

Явно ще се получи по-дълго писмо. Ето и коментарите:

Опроверженията:
1.   Winman, ти къде забеляза тенденция за изнасяне на данни? Явно си много зле, защото програмата е публикувана с отворен код и преди да кажеш и една дума, да беше погледнал кода и какво точно програмата „изнася”. Защото аз със същата правота мога да кажа, че те видях в стойка „Г” с един много надарен ... гей! Ама и двамата знаем, че това са глупости! Истината е, че никъде, в никой продукт Microinvest не изнасят информация и това лесно може да се провери от сорса.
2.   cvludmiloff – много се чудя дали ти не си човека, на който Microinvest възложи първата версия за създаване на такъв продукт и ти го заряза по средата, дори и без да изпратиш последните сорсове. Тъй като зад този псевдоним не зная кой стои, но пък много от нещата съвпадат, например името Цветослав Людмилов, то ти нямаш никакво основание да пишеш такива твърдения, защото освен, че ти осигурихме всичко необходимо като технология, знания, архитектура и поддръжка, ние и платихме за разработката. На срещата тогава беше Mironcho, не си спомням фамилията на Георги и мисля, че беше поканен и kenedy. Срещата беше през 2002 година, в нашия офис. Така, че твърденията за платена разработка са много двулични!
3.   PHP не е подходящо за такава разработка, спрете да се лутате, няма смисъл, загуба на време е. В следващата част подробно ще обясня защо.
4.   За да тръгне Microinvest Warehouse Open се изискват сравнително добри машини. Това е така, но сега машина на 2.0 GHz струва около 100 Евро! А ако сложиш MySQL на по-стара машина, то какво ще правиш, като базата от данни стане 50-100 MB? Някой пробвал ли е как работи на стара машина такава база? Работи бавно и си представям в супер маркет фразата „Изчакайте малко, системата търси...”. Иначе наистина има какво още да се желае от mono, но скоро това няма да е проблем, компютрите се развиват с невероятна скорост.

Предложенията:
1.   Такъв продукт има реализация в България. Нека да направим анализ на клиентите. Ако системата има за цел да обхване единични клиенти, то езика за програмиране е без значение. Тогава PHP + MySQL стават за решение. Максимален брой на клиентите (фирми, които го използват) – до 20. Тогава разработката ще е скъпа, защото ще се подели между тези 20 фирми и ще е затворено решение. Ако обаче гоним популярен софтуер, нещата не стоят така!
2.   Много фирми биха имали практическа изгода това да стане, просто НЕ МОГАТ да го направят! Липсват специалистите или пък са несериозни и не довеждат нещата до край. Финансовата изгода е голяма и идва от поддръжката на системата. Затова единици се опитват да го направят и дори някои успяха.
3.   Какъв е профила на клиентите? Най-масовите клиенти са малките фирми. Те имат нужда от решение, което да им върши работа. Обаче трябва да съдържа някои елементи – универсалност, гъвкавост и лекота на работа. Това не е реализируемо с PHP, защото не могат да се направят някои ключови неща – например поддръжка на четец за магнитни карти, интерфейс за управление на касов апарат, управление на серийни и клавиатурни бар-код четци, клиентски дисплеи и други.
4.   Работата през браузер или Web интерфейс ограничава много от функциите. Това е още едно твърдение в полза на завършена и автономна система. Затова все още системите в реалните обекти са ориентирани към специфични приложения и тогава трябва да се изгражда собствен интерфейс. Някакси не си представям чрез Web интерфейс да работи склад на едро с всички възможни разфасовки, модели, номенклатури и други.

Стратегия на успеха:
1.   Какви са нуждите? Нуждите са за малките фирми, които имат собствен бизнес.
2.   Кои са потребителите? Потребителите са операторите и собственика на бизнеса, това не е подходящо за големи организации, там има пари, всичко се купува с бюджет и т.н.
3.   Как да се направи? Това е сложен въпрос, но според мен трябва да се избере работещо решение. Ние избрахме готов продукт, който се пренаписа изцяло за Linux. Скоро ще има и първите реални клиенти на системата.

Тук искам да кажа, че нивата на достъп са решение, което всеки може сам да вземе. Защото клиентите се „възпитават” в софтуера и както им се предложи, така се случва. Аз в момента съм доста зает, затова написах само най-важното от това, както трябва да се направи...

Два въпроса:
1. Честно, ама много честно и отговорно, според теб има ли някой, който може да направи драйвер за касов апарат като Java аплет и той да е работоспособен и надежден?
2. Защо досега нито една фирма не е реализирала такъв драйвер?

Точно затова не подвеждайте хората с PHP + MySQL, а ги насочвайте към работещи решения. Аз съм съгласен, че всичко може да се направи на почти всеки език, но с цената на какво и за колко време? Затова, като прагматик, аз съм на друго мнение и го изложих в предишен постинг.

@vixon: аз, като патил човек те разбирам напълно! Обаче по ми харесва да вярвам, че всичко е възможно да се направи.

Между другото като си плащах тока установих, че служителките използват web-система за разпечатване на фактурите!

IE просто беше толкова лесно за забелязване!

Какъв е проблема да се реализира и 1 складова програмка в web па дори и с по-малко екстри. Време, пари и желание, може и да ни липсват понякога, но не и технологии!

Важното е някой да се престраши и да го направи.

Сметките на глобул се плащат на терминали с ИЕ + плъгин за управление на касовия апарат. Мисля че Зерон (финансово-счетоводна система) имаха и WEB интерфейс, ако някой е работил моля да сподели. Аз си хортувам тука с един САП, чийто клиентски софтуер е писан на джава. Много добре премислено, малко тромаво но работещо.

WEB интерфейса е полезен и подходящ за някои неща изключващи преглед на списъци с по 1-2 МБ данни (не, че компютъра няма да може да се справи но се бави осезателно). Функционалността на интерфейса може да се развива независимо от ядрото на системата което е главния му плюс (разни проверки на полетата, навигация с клавиатура и т.н. ). Баркод четците си работят като клавиатура, за тях няма проблем. Подръжка на карти и касови апарати ще има тогава когато някой плати за това.

Така, че и аз не виждам причина да се пробва нещо PHP+MySQL в най-лошия случай няма да се получи и ще има над какво да мисли следващият автор.

п.с. Прагматизмът казва да се ползва монолитна среда VB, Pascal, C  + windows, но когато става въпрос за проекти на любители които го пишат за удоволствие ... прагматизма идва в последствие. Могат да се дадат много примери за успешни проекти (линукс например) но не мисля че трябва да задълбаваме.
чакам новата версия на Микроинвест и на това което ще направи макс ....
п.п.с. и последно да добавя защо е добра тази комбинация (php+mysql).
1. Огромен брой свободни приложения (все по нещо може да се копне)
2. Свободни програмисти и драскачи (като мен)
3. Разделена функционалност

п.п.п.с и малко в страни от темата
Harold Geneen, който към момента на изказването и е бил CEO  (Chief Executive Officer ) на фирмата  ITT:
" Аз мисля, че това е неизменен закон в бизнеса: думите са думи, обясненията са обяснения, обещанията са обещания - но само свършената работа е реалност. Единствено свършената работа е най-добрата мярка за вашата вяра, компетентност и кураж. Само свършената работа Ви дава свободата да израствате сами.
Просто запомнете че: свършената работа е вашата реалност. Забравете всичко друго. Поради това моята дефиниция за менажер е такава: този, който достига до свършване на работата.
Никакво оправдание към другите или към самия себе си няма да промени това. и когато Вие изпълните нещо добре, светът ще го запомни, когато всичко друго ще бъде забравено. И най-важното - вие също ще го запомните."

и един линк да на го забутам

http://www.debet.kiev.ua/index.php?pageid=23

Winman, под моето ниво си, особено с некултурното ти поведение, но сам си отговори на следните въпроси:

1. Черно бял телевизор или цветен?
2. Голям GSM с размер на тухла или малък и модерен?
3. Кола с карбуратор или пълен инжекцион?
4. TFT или CRT?

Когато си отговориш на тези въпроси ще разбереш, че света се движи напред и е много важно дали ще се прицелиш в новото или ще си останеш архаичен. Защото и фабриката, произвеждала най-модерни камшици се е принудила да прави акумулатори, защото дори и да произведе най-добрия камшик - липсват вече желаещите.

****
По отношение на работата IE / Касов апарат, технологията е следната - прави се ActiveX контрол, който управлява на системно ниво касовия апарат и дава възможност за методи, достъпни чрез IE за работа директно с хардуера. За съжаление, тази технология е достъпна само в IE и Firefox, когато използва IE Engine.

По отношение на Microsoft - може би имат трески за дялане, но защо настоящия сайт се посещава от 66% потребители на Windows (според BGCounter)?

Това да наричаш цяло поколение, че са със съмнителни способности е много самонадеяно и безумно. Защото точно тези хора правят всички продукти, с които работиш и ти!

Към karaman:
За да стане един проект, то трябва някой да се нагърби с идеята и да я тика напред. Иначе всички си правят нещо собствено и нещата буксуват.

Вярно е, че един трябва да се хване, но си мисля че не с работата, а с координирането на усилията и тогава нещата ще станат по-... (бързо, добре и т.н.).
В тази връзка си мисля, че началото на ERPix е доста обещаващо, но така и не разбрах защо няма развитие - сгурно някой се е обидил на друг вместо да се концентрират върху съществените неща.

Ще ми е интересно дали този разговор ще доведе до реални резултати или само ще разлайва кучетата.

Аз лично имам скромен опит в програмирането с Pascal и с удоволствие бих писал код, но не и целия проект, а от ERPix не реагират на въпросите ми.
От друга страна тук доста хора заявиха интерес към подобен проект - защо говорим за един програмист?!

Колеги, основите на една складова система са еднакви във всичкия софтуер за складове. Ако ще правим такова нещо, трябва да го направим, така че да могат да се дописват модули лесно, и да направим само основните неща на една складова система. Отвореният модел ще позволи после да се дописват модули и всеки да си го ползва както намери за добре този продукт, ако ще да чупи лешници!

Всеки един проект в тази насока ще го тествам, ще давам идеи независимо от това кой го разработва. ....
така че съм вътре .

200 складови документа на ден е нещо смешно (300 на час е вече нормално)

както и да е

мога да отделя 2-3 часа на денонощие  (PHP)

Напълно ще ви подкрепя!
Кажете какво трябва да се прави и "веднага" започвам. Мился, че мога да отделя по 2-3 часа всеки ден. Сериозно!

Без приказки няма да се размине, но ако започнем с капки може и до езеро да я докараме, т.е. давайте да минем от нахъсване към конструктивни разговори.

Някой който има опит в организирането на подобен проект да каже от къде се почва (sf.net или openfmi.net)!

Конструктивните разговори с какво да се направи са:
База данни: mysql & postgres & firebird
Език за разработка на основата: PHP, C, C++, MONO, Pyton, Perl
Интерфейс: GTK, QT, HTML, AJAX, Flash, XUL, Mono

А какво да се прави е малко по-сложно:
1. функционалност за идентификация и резпределяне на права
  - минимум: администратор, шеф, служител (вързан за склад)
2. функционалност за създаване на складове
  - номер на склад, адрес, наименование
3. функционалност за създаване на артикули
  - артикула трябва да има поне: номер, наименование, мярка, партида, баркод
4. функционалност за въвеждане на приход/разход
  - въвежда се инфо в таблица да движението на стоките. кой, кога, какво, колко на каква цена
5. функционалност за извъвеждане на справки за приход/разход
6. функционалност за извъвеждане на справки за наличност в склада
7. функционалност за опериране в месечни периоди.

ако ви се струва лесно трябва да поясним някои неща. А се задълбочим в тази функционалност то написването на читав, използваем продукт ще отнеме около година минимум.

сега вече може да коментираме по същество

Ето допълнения според моите виждания:

1. Трябва да предвидим възможност за използване на подмерки и дробни количества, примерно за написване на модул (може ние да не го правим, но да има такава възможност)

2. отчитане на стоките да става не само на база цена на партида, но и на база средна претглена цена, като това да се заложи фиксирано, т.е. потребителят решава веднъж завинаги кой метод да ползва

3. хубаво е да има модул контрагенти (купувачи/доставчици) с данни за контакти с фирмите, евентуално ДН/Булстати и т.н.

4. аз бих предпочел за база данни firebird, тъй като поддържа много удобни stored procedures. A и лиценза е готин.

5. Въпрос: Ще има ли Каса?

всичко може. но това е базата. След това трябва да се добави фифо, лифо, средно претеглена, конкретно определена цена за изписване. модул контрагенти, договори ... но това са все добавки. За базата данни би трябвало да ина Database Abstraction Layer но може и без него. Както преценят разработчиците..... варианти много. пребройте се и гласувайте.

по-добре да си е отделно реализирано. някъде може да нямаш контрол върху базата така както искаш....

трябва да са разделени! все пак едните са потребители на програмката, другите на базата и се създават с различни цели!

Коментари:

1. Кой ще се нагърби за да направи архитектура на проекта?
2. Нека разработчиците да се преброят, колко хора са и на какъв език ще се пише?
3. Кой ще определи вида на базата от данни?

@vixon: Викторе, да не искаш да помагаш?!

Мисля си, че ако се направи wiki, като на ERPix, в което да се опише всичко - структура на таблиците с данните, функционалността на отделните модули и т.н., то не само ще подпомогне разработката, а би могло да се ползва и като документация от потребителите и администраторите по-късно.

Между другото и RD Suite изглежда като усилия в посоката в която мислим.

идеята за wiki е много добра, също така предлагам и един IRC канал, кой ще се навие да ги направи, аз ще поема инициативата за попълване на wiki по очертаната от @kennedy схема

Да, аз искам да помагам. Сега ще нахвърлям моите мисли и очаквам коментари за тях. Ще структурирам идеите по точки, за да може отделно да се коментират:

1. Стандартна структура на базата от данни. Според мен трябва структурата на базата от данни да е стандартна и да копира на 100% някой популярен продукт - Microinvest, Mistral, Global или друг. Защо? Ами защото никой не прави например бензин Ж48, а всички използват предварително готовите решения - А95. Защото ако базата е съвместима с готов продукт - ще са ясни предимствата и недостатъците и ще могат да се използват много средстава за импорт/експорт. Също така съм далече от идеята, че някой може да направи ИДЕАЛНАТА база от данни и тя да върши всичката работа на света.

2. Трябва сериозна организация и по 3-4 часа работа от всеки и всеки ден. Иначе нищо няма да стане, защото средно на 6 месеца проектите се забатлачват. Стандартно всеки винаги има по-важна работа и никога няма да откаже една бира, но ако трябва да направи корекция в програмата - не му е сега времето...

3. Трябва лидер, такъв, който отговорно да контролира проекта и да ръководи прогреса, такъв който да се кара и да ръчка заспалите.

4. Пак не разбрах - кои ще са програмистите на системата? Тоест, кой ще пише самия код? Защото тах ги няма, а пък те са най-важните...

Аз се наемам да пиша код на c++ и php, но повече от 2-3 часа на ден не мога да отделя!

Пък и не е ли по-добре да определим първо основните задачи пред нас и тогава да решаваме на какво ще се пишат. От два дена се опитвам да измисля архитектура на проекта, но в главата ми са само баници, баклави, пазаруване, подаръци. Едвам успях да пусна ъпдейти за бинки-то. Тия нощи съм само на кафе!

Айде да се организираме, да се разберем ако трябва в IRC, примерно

днеска, утре, всеки ден: 20:00
bgirc мрежата (не unibg)
http://www.bgirc.net/index.php?option=com_wrapper&Itemid=72
#linux-bg

да се преброим и да решим кой какво ще прави

междувременно да сложим 1 wiki примерно в openfmi.

Няколко идеи ми се насъбираха в главата тия дни.
Ето какво мисля:

1. подкрепям vixon, трябва да видим стандартна база, обаче има едно голямо НО. Тия стандартни бази не винаги са перфектното решение, т.е. съгласен съм да копираме оттам, но да ползваме сляпо не.

2. хубаво е да ползваме някакъв вид MVC, ако ще и да е псевдо такъв.
Примерно

2.1. SQL db backend с драйвери за различни видове бази
2.2. (CORE) основните функции в .DLL или .SO,
2.3. фронтенда вече на каквото дойде: избор богат!

3. Засега предлагам да използваме firebird за вид база. Super сървъра е много удобен, лек е и SQL-а който се поддържа от базата е с богати възможности (VIEWS, TRANSACTIONS, STORED PROC). Освен това е доста бърз.

Предлагам да започнем работа по проекта колкото е възможно по-скоро, така че ако не друго поне да наберем инерция малко!

едит1:
Ако има будни и тази вечер може да съберем да поговорим в чата.

едит2:
часа се променя на 20:00

@karaman: Съжалявам, но не бях гледал "Lord of the rings" и след банята ми изглеждаше като най-доброто решение. Сериозно: точно празничните дни не са най-подходящото време за сериозна работа.

@vixon:
1. Коя да е база има трески за дялане и мисля, че е най-добре да се проведе по-сериозна дискусия, като се постараем да вземем по-доброто от вече направеното и да го дообогатим отколкото да се вземе което и да е нещо и да се съобразяваме с неговите недостатъци;
2. Работата на доброволни начала означава, че всеки вижда в проекта решение на свой проблем и ще се занимава с него докато си реши проблема или докато изглежда, че ще си го реши и не всеки ще може да отдели всеки ден по 2-3 часа, но това не е проблем (според мен), защото това е и творчество, и понякога за няколко часа можеш да свършиш повече отколкото друг път за седмици;
3. Лидер трябва, но той не може "да се кара", защото останалите НЕ СА му подчинени, а трябва да е човек който може да обхване с мисълта си целия проект и да координира работата;
4. Аз на този етап не се наемам да пиша сам код, но ще се постарая да помагам където разбирам.

И аз съм за, да се започне по-скоро работа за да се набере инерция и да се оформи екип.

Според мен базата данни не е решаваща когато се използва DAL . В самата база за версия 1.0 НЕ трябва да има съхранени процедури, тригери и т.н. Всичката логика трябва да е в кода на програмата. Едва след като се стигне до завършен, бавно (относително) работещ стабилен продукт може да се скача на по-горно стъпало. Уроците и изводите направени по пътя с нищо не могат да бъдат заменени ...
Идеята да се ползва структура на Микроинвест не е лоша, както и всяка друга свободна (GPL) програма. Единствено Vixon и Cvludmiloff има голям опит в тези неща, другите ще трябва да го събират тепърва.....

Разбира се точно празничните дни не са за такава сериозна работа, но да не забравяме - тука има и голяма доза творчество, (както каза някой) та такива, дето искат да творят - не трябва да се спират....
сега сериозно:
1. в случай че се събере екип от поне 3-4 човека, аз се навивам да бъда координатор... и програмист...
2. предлагам да не се гледа структурата на ДБ от програми, които не са GPL или имат собственическа тенденция. Много малко ме бърка това че няма да има съвместимост с други комерсиални продукти - наскоро някъде четох нещо скандално точно за тия съвместимости
3. Препоръчвам т.нар agile development с избор на подходяща среда - език и framework - най удобни за целта са Python + Django или Ruby + Rails, макар в краен случай - PHP - в никакъв случай C++
4. Препоръчвам максимално спазване на стандарти и други изисквания към номенклатури и/или логика - независимо дали е за склад или счетоводство или друг модул - само така това което ще направим наистина ще се ползва

нека да се съберем довечера на предложеното от @karaman място и да обсъдим някои неща

едит1: предложения от @kennedy DAL (Database Abstraction Layer) е в основата на Rails и Django - не че няма други, но ....
едит2: и Rails и Django доказано вървят и под Linux и под Windows и имат възможност да ползват доста от по-известните сървъри за бази от данни

1. ОК
2. Ако базата не е съвместима с нищо, то продукта ще остане напълно изолиран и шанса да накарате някой да направи доработка или разширение е нула. Да не говорим за бъдещо счетоводство.
3. На какво се учат младите кадри? Какво преподават в университите? Какви специалисти има най-много? Това е важно...
4. ОК

Аз съм против DAL, но ще се съобразя с мнението на всички.

Чудя се какво ли прави MaX_Ass. Все пак той започна темата.

проектът вече има сайт, вики и svn
за повече информация тук:

http://saplb.devjavu.com/

Следя темата почти от самото начало и ми е интересна. Поне три подобни си спомням на сайта - започващи с ентусиазъм и много приказки за изисквания, бази, нужди на потребители и така нататък (май и аз имам малко принос в тези приказки в една от тях). Това е втората тема завършваща със сайт (ако не ме лъже паметта - едната от подобните идейни теми роди форум и там имаше няколко наистина добри виждания).
Та! Поздрави за сайта! Дано да има много посещения и да има много документация!!!
Засърбяха ме ръцете и реших да видя какво прави и малкото сорс, който има на сайта. Ето тази команда ми свърши работа, за да го изтегля:

svn co http://svn.devjavu.com/saplb/

Не е зле да се драснат два-три реда с правилните адреси за теглене, че горния адрес го налучках от трети опит. Нищо все още не работи и вероятно това е напълно нормално. README е празен така, че пробвах с python xxxx.py, но нито една команда не ми върна никакъв нормален изход, но и аз не съм програмист, така, че може и да бъркам.
Иначе, дано тази инициатива е успешна!
Стискам палци!

Благодарим, братко @alabal за конструктивната забележка, и за пожеланията и подкрепата

Темата заспа или всички сега се подготват за празниците?

Не е заспала
Просто работим по кода (а той има и коментари)
А и се подготвяме за Нова година
Сега повече второто! Аз например се запознах с една готина касиерка (7 пъти ходих до супермаркета за 2 часа!

Весело изкарване на Нова година от целият екип на проекта!
Тържествено обещаваме да не пием повече отколкото трябва!

днеска след 19:30 IRC среща на проекта

Май темата все пак заспа?

В момента не мога да пиша, поради лични причини, но не съм оставил проекта. Все пак да знаете че ще участвам само ако е PHP+MySQL. Имам някои готови неща но те не са свързани със склада или счетоводството. По-скоро си пренаписах нещата които имах за горивата на товарните автомобили, т.е. едва ли на някой ще му вършат работа.

Като гледам посочения сайт вече се работи, но Python + Postgre.

на PHP ще има web-client после! Поне засега мислим за Python.
Аз тия дни празнувах (именни дни, рожденници, ау), но по проекта се работи здраво, особено колегите са най-сериозни, за което шашка им свалям!!! Наздраве от мен!

Разбирам че няма свободно време, но има концептуални грешки и май никой не ги обсъжда. Ще дам 2 примера, които са ключови за успех на проекта:

1. Имате проверка за 13 цифрен бар-код, но масово се използват 12 и 8 цифрови;
2. Използването на броячи за документите елиминира каквато и да е възможност за мрежова работа и синхронизация на документите, защото е възможно за определен момент 2-ма да вземат номер преди инкрементиране на броячите. Особено при активна работа.

1. EAN13 е най-универсалният стандарт, а EAN8 наистина е доста разпространен, но не мисля да е проблем да се добави както той така и UPS-x и т.н.
2. Номерата на документите в базата не е задължително да са водещи при операции с тях (редакция например), а за синхронизация могат да се задават диапазони от номера за различните работни станции.

1. OK, добавате го!
2. Не съм съгласен! Обяснете на счетоводителката, че при 5 работни станции ще имате 5 различни номератора за фактури. То има елементарни решения, няма кой да се консултира.

@vixon: Рече, че искаш да помагаш, но със заяждане не го постигаш! Ако искаш да предложиш нещо - моля, но не се заяждай!

Едит: Пропуснах да спомена, че същата счетоводителка до вчера (а защо не и днес) си работи с кочаните - та се чудя каква е разликата? Или може би когато пишеш фактура се обаждаш на пет места да провериш до кой номер са стигнали?! Да не говорим, че кочана си е отпечатан с номерата в голям % от случаите.

Понеже съм "ангажирана страна" по такива спорове, обикновенно си трая.
НО от гледна точка на практичността - Момчета, уважавам Вашия ентусиазъм (а защо няма включени девойки в проекта

Понеже съм "ангажирана страна" по такива спорове, обикновенно си трая.
НО от гледна точка на практичността - Момчета, уважавам Вашия ентусиазъм (а защо няма включени девойки в проекта?   ), но като виждам пред какви елементарни проблеми се спъвате и потъвате в кофти решения - сигурни ли сте, че е добре да си ангажирате времето с такъв проект?
Колкото и да е експериментален - такъв софтуер има смисъл, ако върши работа!

А ако ще се позовавате на решения от типа "те и сега си работят с кочани.....", съжалявам но не ми изглежда сериозно ....

Помислете, Ваше е решението!

Успех!

P.S. Аз иначе също съм заклет ентусиаст!

Не се хващайте за думата, а вижте смисъла! Не смятам, че "кочаните" са панацея, а просто казвам, че в много случаи добре познатите "прости" решения са добри. Освен това тази забележка беше просто заядлив отговор на примера по-горе, с който (както и с усмивката като мото на мнението ми) исках да подчертая грешния стил на даване на предложения.
Надявам се този път да съм по-ясен!

А иначе много съжалявам, че не съм програмист и не можех бързо да напиша отговор, като този на cvludmiloff, който несъмнено е много по-... от моя. С което искам да кажа, че наистина е добре да се придържаме към сериозния професионелен тон и в предложенията и в коментарите по тях.

Peace!

И като сме отворили дума за кочаните какво пречи да има диапазони (кочани) за всеки потребител; офис; склад и така нататък? Какво пречи да се следят и ръчните кочани, на кого е даден, кога е върнат. Във фирмите си има регистър за тази работа.

Да така е.

Добре е номерацията на ф-рите за всеки обект да почва със сегмент - първите 3 цифри от 10 цифрения номер ако обуславят сегмент това значи, че имаш 1000 такива

само за справка на неверниците  ....
http://www.openpro.com/Reasons.htm

Проекта замря ли?
Бих искал да се включа в частта за XML-RPC клиента. Предлагам да го направя на glade, като формите да се получават динамично през RPC-XML (типично MVC но с rich client). Ако не сте твърдо зад qt разбира се. За съжаление тогава не мога да помогна - доста съм бос там. Видях, че е имало дискусия за типа но не я намерих.
Надявам се, че ще ме приемете.

Qt също ползва XML за описание на формите, резултата в общи линии ще се получи същия като при tinyERP - бавен и тромав интерфейс (поне при мен и според мен). Е, това сигурно си има и някои предимства, и ако можеш да да ги защитиш -
виж това преди всичко http://saplb.devjavu.com/projects/saplb/wiki/SaplbTeam

пс. Интерфейса на клиентската част не е ограничен до Qt, всеки би могъл да си напише клиент с каквато и да е GUI библиотека, и да ползва remote calls към сървъра

Ами тогава ще почакам да направите XML_RPC -то. И ще си напиша клиент.

//bookmark
http://www.debet.kiev.ua/index.php?pageid=23

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

P.S. Не че не се изнервям от четенето на някои специализирани четива на английски, но учителя ми по английски (благодаря Ви г-н Дойчев) беше доста по-упорит от учителката ми по руски до 8-ми клас и сега с английския се справям доста по-добре отколкото с руския.