Една от причините да не пиша много в последните месеци е, че исках да доведа един от проектите, които движа до някакъв вид, който става за показване. Днес след като пооправих няколко неща, реших най-накрая да пусна първа версия на програмата RD Suite. Най-общо казано идеята на този проект е да бъде система за управление на фирмата, в чиято основа да седи счетоводна програма и всички модули в системата да си комуникират през счетоводната програма. За сега процеса на разработка е концентриран именно върху самата счетоводна програма, както и върху програмите за администриране на цялата система. Нещата са още в доста ранен етап. Има доста функционалности, въпреки че две от тях съм ги оставил посредата (става въпрос за едни по особени справки). Самата счетоводна програма да бъде напълно функционална се нуждае от още две основни неща. Едното е свързано с дълготрайни материални активи, а другото с поддържане на цени на база няколко принципа за материални запаси. Тъй като искам нещата да бъдат и документно ориентира по някое време трябва да направя частта, която позволява да се дефинират документи като формуляр на база библиотека от widget-и.
От гледна точка програмата да стане по user friendly трябва да почна да пиша нещо като документация. Освен това за момента имам проблем с обработката на SQL грешките. Postgresql връща кодовете на грешките като низ съставен от букви и цифри. За съжаление в QT библиотеката грешките могат да бъдат цели числа и това, което са направили разработчиците е просто да игнорират статуса на грешката при postgresql плъгина. Това е неприятно, защото като се издъни заявка не знам дали е заради синтактична грешка, недостатъчни права или нарушаване на някой първичен ключ. Явно трябва да пренаправям плъгина, което не ме изпълва с много въодушевление.
В този блог съм създал нова категория, която да касае новините около програмата. Не знам колко често ще пиша неща, но поне веднъж месечно ще гледам да споменавам нещо по темата. Като че ли това е засега. Коментари и предложения са добре дошли.
От гледна точка програмата да стане по user friendly трябва да почна да пиша нещо като документация. Освен това за момента имам проблем с обработката на SQL грешките. Postgresql връща кодовете на грешките като низ съставен от букви и цифри. За съжаление в QT библиотеката грешките могат да бъдат цели числа и това, което са направили разработчиците е просто да игнорират статуса на грешката при postgresql плъгина. Това е неприятно, защото като се издъни заявка не знам дали е заради синтактична грешка, недостатъчни права или нарушаване на някой първичен ключ. Явно трябва да пренаправям плъгина, което не ме изпълва с много въодушевление.
В този блог съм създал нова категория, която да касае новините около програмата. Не знам колко често ще пиша неща, но поне веднъж месечно ще гледам да споменавам нещо по темата. Като че ли това е засега. Коментари и предложения са добре дошли.
4 коментара:
С един приятел планираме проект за счетоводна програма на GTK/PyGTK. Все още обмисляме как да станат нещата, но си мислех дали можем да се обърнем със съвет към теб, ако евентуално имаме някакви проблеми (то ще има със сигурност)?
Няма проблем за съвети. С каквото мога да помогна ще помогна. Общо взето моите концепции се виждат в изходния код на програмата. При мен имаше доста подводни камъни за да: изнеса сигурността на системата към sql сървъра, направя лесна промяната на структурата на базата данни в процеса на развитие на програмата и да подържам различни sql сървъри.
Тъй като сте решили да правите такава програма, с какво се различават вашите концепции от тези на RD Suite.
Благодаря за отговора. За RD Suite разбрах буквално преди минути и все още не съм погледнал изходния код, нито съм я компилирал, за да я разгледам.
Но общо взето ние замисляме счетоводна програма, която да позволява въвеждане на контрагенти, фактуриране, създаване на индивидуален сметкоплан, записване на счетоводни статии, амортизации, извеждане на справки за отделните сметки (главна книга), извеждане на финансов отчет (баланс, отчет за приходите и разходите и т.н.). Мислим да започнем модул по модул, вероятно в този ред. Евентуално по-нататък може да се включат и модули ТРЗ, ДДС дневници, склад...живот и здраве:)
На този етап мислим да ползваме sqlite като субд, но не сме работили с него и не знам как ще се впише в проекта. Другият вариант е postgresql. А за GUI както споменах - GTK+. Все още се двоумим дали да ползваме Python и PyGTK, но май везните накланят натам.
Ще ни трябват и съветите на счетоводител, понеже има доста мъгляви неща около самите счетоводни операции. А и така или иначе трябва да се следят промените в законодателството и новите изисквания.
Иначе си мисля, ако концепциите ни съвпадат... дали да не направим fork на RD Suite като в същото време помагаме по функционалността, където можем да се впишем?
Принципно функционалността на RD Suite е близка до това, което казваш. В момента има доста голяма гъвкавост за дефиниране на сметкоплан. Сметките могат да бъдат с доста нива на аналитичност. Това не става на база йерархия от сметки, а чрез номенклатури. Предимството на този подход е че при справките начина на групиране може да се променя, което йерархичния подход не може да прави. Броят на номенклатурите не е ограничен, а освен това може да се дефинират подчинени номенклатури, чиито стойности да зависят от избрана стойност в друга номенклатура. Дълбочината на тази зависимост също не е ограничена.
Поддържат се счетоводни периоди и може да се работи едновременно с няколко счетоводни периода. Многофирмеността и много потребителността се подразбират, въпреки че още не съм направил заключване на таблици с цел избягване на колизии. По отношение на справките се поддържат справки по сметка, по папка, обортна ведомост и главна книга. Всички други справки или отчети минават през графата потребителски дефинирани справки. Там нещата са още в начален стадий на разработване (най-вече покрай интерфейс), но идеята е следната. Отваря се нещо като електронна таблица с клетки , в които могат да се въвежда текст и формули. Има специални функции искам оборота по тази сметка или началното салдо по другата. По този начин могат да се дефинират отчети за приходи и разходи и така нататък. Липсващи функционалности на този етап са неща свързани с дълготрайнита материални активи и калкулиране на цени на материалите в наличност.
В момента в процес на довършване са разни детайли около извлечението по сметка и потребителските справки. Завършена е обработката на грешки от sql сървъра. И писането на документация е в напреднал етап. Избран е Docbook като формат, направена е структурата за отделните програми и има доста понаписан текст. Всички тези неща ще станат общодостъпни със следващата версия на програмата, която може би ще излезе към края на февруари.
След това планът за развите на програмата предвижда да се фокусира повече върху документооборота и дневниците за ДДС. Искам да се появи нещо като възможност за се дефинират визуално документи и с възможни операции върху тях, с което да се автоматизира процеса на осчетоводяване. Освен това дефинирането на документи ще помогне за интегрирането на счетоводната прогарама с други програми като склад например. Ако това стане д осредата на година ще съм доволен. За по-нататък не съм мислил.
Иначе програмата е писана на C++ и QT4, което дава добра многоплатформеност. По отношение на форка помислете дали има смисъл, тъй като този проект засега е далеч от затихване. Разбира се ако идеята е GUI-то да е GTK, за по-добър изглед под Gnome е обяснимо, но иначе няма смисъл. Освен ако имате идеи, които аз не съм склонен да са имплечентирани в проекта. Иначе по отношение на развитие на функционалнстта ще съм доволен на помощ от хора, които искат да разширят подръжката на програмата върху други sql сървъри.
Тъй като системата е замислена като набор от програми, които си комуникират помежду си и когато проекта почне да се развива от няколко човека си мисля вместо да се блъскат хората помежду си, всеки да маже по някоя от програмите. За сега логически обословени са следните групи. Базова библиотека (там са набутани доста неща около подръжката на базата и общ интерфейс), администрация но системата (три програмки) и счетоводство. Ако имате желание може да стартирате с модул за ТРЗ плюс уведомления до НОИ за осигуровки и НАП за трудови договори, който после да се интегрира в системата. Разбира се, препоръчително е всичките модули да са писани на C++ и да използват QT4.
Ако това представлява интерес, може да ми пишете на пощата да се разберем за детайлите.
Публикуване на коментар