RD Suite - край на играта

Последните 2-3 години не ми остава много време за RD Suite. Факторите за това са много и по всичко личи ще нещата ще изглеждат по същия начин и през следващите 2-3 години. За съжаление не можах да създам общност около проекта, така че няма кой да го движи, когато аз нямам възможност (разбира се, вината около това е изцяло моя). В тоя ред на мисли, смятам, че след 6 годишно публично съществуване е най-добре официално да сложа край на проекта. Ако някой все пак е решил да го продължи, мога да му прехвърля каквото сметне за необходимо. Хостингът е платен до средата на 2013.

Тези, които ползват в момента софтуера, могат при нужда да ми пишат. Далеч съм от мисълта да ги оставям да се оправят сами. Не изключвам възможността след 3 или 4 години да има remake (макар и под ново име). Разбира се, за да се случи това, проектът трябва да ми е основен източник на доходи, което означава, че и фокусът му ще е по-различен.

RD Suite през 2008-ма

През изминалата година не излезе версия на RD Suite и може би има някаква чудене какво става с проекта. Мога да успокоя всички заинтересувани, че проектът е все още жив. За справка да погледне svn хранилището. Причината да не излезе версия е свързана с фактът, че кодът, който се наблъска през 2008 година е относно нови модули към програмата, а именно неща свързани с бетонопроизводство и заготовка на арматура, които са доста специфични и не са чак толкова свързани с програмата за счетоводство. Доколкото промените в програмата за счетоводство са малки (основни изчистване на бъгове), а feedback-ът от хората, които са разглеждали програмата клони към двете нули, то някак си нямам стимул да компилирам версии, тъй като поне за мен това е времеемък процес. Който иска да гледа промените, да дърпа от хранилището и да компилира.

Положителното за проекта е, че през 2008 целият код се ползва на две места в production вариант, което от своя страна помогна да се изчистят доста дребни грешки. От гледна точка на нови функционалности няма нещо кой знае колко значително, освен много допълнения по справката по сметка, където вече може да се филтрира по нива на аналитичност и се добавиха колоните свързани с количество и цена на нивата на аналитичност към номенклатурата с артикули. Това от своя страна доведе и до написване на нови функции към потребителските справки, макар и за момента да не са закачени към парсера за формули. Именно този парсер ми спъва добавянето на нови функционалности, тъй като е желателно да го пренапиша. За съжаление това ще ми коства поне седмица в плътни занимания, а за момента не мога да я отделя. Зорът в цялата работа е свързан с интерфейса. Примерно в момента лесно може да се направи потребителска справка, в която разни елементи да са свързани с обороти и салда по сметки. Тънкият момент, е че тези справки ще са по-полезни, ако вместо да се гледа движението по цялата сметка, човек се ограничи до някои нива на аналитичност (ако сметките са такива). Принципно в момента формулата позволява да се прави това, но съществения недостатък е, че потребителят трябва да знае кодовете, с които са записани отделните обекти в базата данни. Това разбира се е доста неудобно и поради тази причина трябва интерфейса да го поеме по някакъв начин. В тази ситуация като се пише формулата, програмата трябва да съобрази от контекста, че трябва да се въвежда код и по триков начин да покаже падащ списък с възможности, във формулата да седи избрания текст, но във вътрешното представяне да стои кода. Всичко това не е чак толкова тривиално като решение. Част от нещата са направени, но с други все още имам чуденка как да ги реализирам. Така че, ако някой има опит с такъв тип задачи, ще ми е интересно да сподели.

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

Проектите ми в OpenFMI

В края на февруари регистрирах още един проект с име FreeGIVE в OpenFMI, с което проектите там, в които участвам, станаха три. За момента активността около него ще бъде в svn хранилището (май това е основната причина да го регистрирам), където съм сложил нещата, които до момента съм направил по един иконометричен пакет за R. Принципно цялата идея може да се развие в много посоки (за момента ще ги пазя в тайна), но засега ще се концентрира основно върху този пакет, като се надявам в неговата разработка да се включат и други хора (те си знаят кои са). Може би е уместно да се попита защо няма компилирани пакети за windows или кога този пакет ще се включи към официалните пакети за R. Отговорите са свързани най-вече с появяване на документация по отделните функции, нещо, за което не съм се напънал много. Все пак хората, които искат да го ползват и без документация (не знам какви джедаи трябва да бъдат, за да успеят) могат да го дръпнат от хранилището. Ако са под linux доста лесно ще го добавят към останалите пакети. Ако са под windows ще им трябват неща като perl, latex и още доста глупости.

Интересно е какво става с останалите два проекта? Като че ли този, покрай който има най-много движение е RDsuite, макар и спрямо началната версия да няма кой знае какви видими промени. За следващата версия, която най-вероятно ще излезе есента (да не се заричам много) са планирани три важни и видими нововъведения. Така или иначе, който се интересува от този проект, може да дойде да ме види на априлската конференция на „Линукс за българи” или както се казва вече.

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

Модули в RDsuite

Друго нещо, което ще се появи в коледната версия на RDsuite e възможността за работа с модули. Кодът, който администрира създаването им и раздаването на привилегиите на отделните потребители е вече в svn хранилището. Това като цяло дава възможност да се фокусира разработването на специфични програми, като склад, фактуриране и т.н. Като цяло идеята е следната: добавянето на фирма в системата регистрира схема в базата данни, която общо взето съдържа счетоводна информация за фирмата като номенклатури, сметкоплан, документи, осчетоводявания. Създаването на модул от своя страна създава допълнителна схема, която малко или много е свързана със схемата за счетоводната информация за дадена фирма. Разликата е в това, че в даден модул може да има по специфична информация, обхващаща дейността, за която е предназначен модула. Като цяло още имам няколко чуденки как да бъде реализирана комуникацията между отделните модули. За момента се ориентирам към това публичната информация за даден модул да бъде изнесена по някакъв начин в счетоводната схема и ако някой модул се нуждае от информация генерирана в друг модул, то да я търси в счетоводната схема. Възможно е да се измисли и начин за запитвания към отделен модул идващи от счетоводната схема, както и да се измисли някаква директна комуникация между отделните модули. Но дали ще се наложи да се правят такива сложни работи ще стане ясно, когато броят на отделните модули нарасне.

Като цяло добавянето на нов модул към административната част в системата става като се създадат два xml файла. Единият описва структурата на схемата, а другия съответния template. Към момента обаче регистрирането в системата става, чрез промяна в изходния код. Поради тази причина смятам след нова година да преразгледам db слоя но системата и да изнеса и тази конфигурация във външен файл. Това би дало възможност лесно да се разработват модули, които не е нужно да са базирани на QT4 или C++. Разбира се, при такъв сценарий няма да могат да се ползват готовите widget-и, освен, ако по някакъв начин не може да експортиран rdcorelib към съответните инструменти, които се използват.

Като финал да кажа и кое налага разработването на template-и и модули. Освен нещата, които за момента седят в svn хранилището има още четири програми, които ще бъдат включени в него. Два модула (за управление на арматурен двор, който е завършен доста отдавна и за управление на бетонопроизводство, който е някъде по средата на своето развитие), една програма за управление на xml файловете с дефинициите на отделните схеми (трябва малко да се пипне преди да я импортна в svn-а) и програма за ДДС дневници (сигурно ще бъде завършена след излизането на QT4.4, тъй като ще си спестя доста излишна работа). Така че, ако видите голямо изсипване на файлове в svn, то да не се притеснявате, че съм се преуморил. Просто ще бъдат неща, които залежават повече от година по диска ми.

Template-и в RDsuite

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

От техническа гледна точка template-тът е набор от widget-и, чрез които потребителят въвежда някакви входни стойности. Някои стойности може да са задължителни, а други да се въвеждат при желание. Към всеки widget е закачен набор от sql команди и ако потребителят е решил да въвежда някакви стойности през него, то съответните команди се изпълняват. Принципно командите може да са произволни, но към момента се предполага, че това са select заявки, които връщат резултат един ред с една колона. Това не е кой знае какво ограничение като се има предвид, че записът на данни в базата минава през stored procedures (които в моя случай са функции). От друга страна това ограничение е важно, за да може резултатът от една заявка да се ползва в друга заявка, която не е необходимо да бъде от същия widget. В момента widget-ите, които се поддържат са Label (който ако е пожелателен става CheckBox) и LineEdit. При необходимост този набор ще се увеличи. Иначе цялото описание на template-та се съхранява в xml файл, така че лесно се редактира през текстов редактор. На който му се експериментира да хване последния код от svn хранилището.

От организационна гледна точка имам няколко чуденки. Към момента цялото описание на template-тите се съхранява в отделен файл и не знам дали не е по-добре да ги сложа към файла, който описва структурата на съответната схема. Това от своя страна ще наложи преместване на кода от администраторската част към общата библиотека. Освен това в момента има дублиране на код относно изпълнението на sql команди, което трябва да видя как да разчистя. Нямам още яснота какъв вид ще добият нещата, когато се почне поддържане на няколко различни вида sql сървъра. Ужким това е планирано в проекта, но може да се получат няколко проблематични области. И не на последно място може би трябва да довърша редактора за структурата на отделните схеми, към него и да сложа template-тите и да го commit-на в svn-а. Едно такова упражнение хем ще изчисти всичките въпроси относно как да се организират нещата около достъпа до базата данни, хем ще може по-лесно да се редактират отделните файлове. От гледна точка на крайният потребител на проекта обаче едва ли ще донесе някаква полза.

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

Първи стъпки с Debian

Покрай необходимостта да се направят пакети на RD Suite за Debian и поради липсата на желаещи да направят това, реших да се наема с една такава задача. В резултат на което взех, че след толкова години работа с Linux, най-накрая стигнах и до тази дистрибуция. Тъй като нямам излишна машина, на която да правя такива експерименти, си пуснах едно qemu на което да инсталирам. Въпреки виртуализацията и мрежовата инсталация, всичко стана сравнително бързо. Първите ми впечатления са доста положителни. Харесва ми как са организирани нещата и че не се натрапва мнението на хората поддържащи дистрибуцията как да изглеждат отделните неща (който ползва KDE под Fedora ще ме разбере какво имам предвид).
Надявам се скоро да се появи и така желаният пакет. След диагоналното преглеждане на документацията на пакетната система направих основните файлове, но останаха още няколко неща да се настроят, пък времето все не стига.

Презентация на RDSuite

Покрай упражненията и лекциите, които водя този семестър, като и това, че ми предстои сериозен изпит, не ми остава много време да пиша в блога. Въпреки това нещата покрай проектът RD Suite, макар и не с темпото, което ми се иска, се развиват. Вече има web страница на адрес http://rd-suite.openfmi.net, а тази неделя ще бъде представен на априлската конференция на Линукс за българи. Заповядайте!

Версия 0.2 на RD Suite

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

Една от тях е, че се ползва друг plugin за връзка с PostgreSQL. Това се налага поради факта, че оригиналният такъв, не поддържа кодове за грешки и в самата програма е трудно да се разбере защо е гръмнала дадена заявка. Другата промяна е свързана с това, че повечето SQL команди са изнесени във външен файл. Основната идея е така да се даде основа за по-лесно поддържане на други SQL сървъри освен PostgreSQL. Просто в зависимост от сървъра ще се зарежда различен файл. Трябва да се има предвид, че улеснението не идва само от това, че командите се менят между различните видове сървъри (честно казано в това се съмнявам, защото почти всички команди извикват stored procedures, което става почти навсякъде еднакво), а по-скоро в обработката на грешките. Тъй като част от командите се извикват от библиотеката на RD Suite, то е възможно съобщенията за грешка да се базират на база програмата, която я извиква. Най-общо казано за даден код на грешка има стандартно съобщение, но могат да се дефинират и специфични, които да се визуализират в определени случаи. Разбира се, ако някой код на грешка не е прихванат, то се изплюва съобщение с информация от самия SQL сървър, така че да се позволява по-лесна диагностика.

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

Интересно е какво предстои след тази версия. Насоките са много. Трябва да се направи малко преструктуриране на кода и някои части от него да се изместят от счетоводната програма към библиотеката на системата. Трябва да се дооправят потребителските справки от гледна точка на интерфейс. За момента те поддържат повече възможности от колкото предполага интерфейса. Например могат да се правят обороти и салда по конкретни аналитичности на сметки, но основният проблем е в това, че да се зададат тези аналитичности, трябва да се знаят кодове, под които са записани в базата. Тъй като идеята ми е за справките да се пази начина на работа с електронни таблици, то трябва да измисля някакъв autocomplete механизъм за избиране на аналитичности. Хубаво е да направя възможност за експорт на справките към OpenOffice.org, както и да почна да смятам цени на материалните запаси. По отношение на по-значими функционалности като че ли има две неща – отчитане на ДМА и възможност за дефиниране на документи с повечето им полета, които да се попълват и на тяхна база да се генерират предложения за осчетоводяване.

Интересно ми е от всички тези неща кое е приоритет на хората, които са пробвали програмата?

ДДС неволи

Навремето, когато стана задължително да се подават дневниците по ДДС на магнитен носител, целият счетоводен бизнес се движеше под ДОС и някак си логично от Главна данъчна дирекция предоставиха софтуер, който работеше под ДОС. Първите версии на този софтуер бяха набързо написани и да не бяха много удобни. Тогава се изхитрих да правя дневници по ДДС на Excel. Схемата беше много проста. Въвеждаха се дневниците в електронна таблица (бях направил специален template), експортираха се в csv файл, прекарваха се през една ДОС-овска програма (защо не го направих на Excel-ския Basic не ми е ясно), която бях писал, и накрая се пръкваха файловете готови за данъчните. Който се е занимавал да прави програма за генериране на такива файлове, предполагам знае, че проверките в данъчната служба са малко особени и дори да е генерирал файл по спецификацията, която се публикува в някакво приложение има не малка вероятност генерираните файлове да бъдат върнати. Та последния етап от цялата процедура включваше импортиране на генерираните от мен файлове в програмата на данъчните, и записване на файловете на дискета през нея.

Въпреки, че така описана цялата процедура изглежда доста сложно, всичко ставаше за нула време при добра концентрация. Печелеха се следните неща. Първо дневниците можеха да се печатат на какъвто искаш принтер, а не само на широк матричен и лесно се пропускаха всички празни колони. Второ данните се въвеждаха доста по-бързо, заради автоматичното попълване на имена от страна на Excel-а, както и използването на формули за смятане на разни ставки. А и не на последно място около 40% от фактурите се издаваха от една програма, която ги експортираше в csv.

Тази процедура се използва и досега, нищо че през това време програмата на данъчните е поправена от гледна точка на бързо въвеждане на данни, спря да се използва програмата, която експортваше издадените фактури в csv файл и се появиха доста програми за Windows, които трябва да са по приветливи (като съм гледал програмата на Микроинвест, съм оставал с впечатление, че е правена за счетоводители от 0 до 3 годишна възраст. Толкова е шарена.) Обаче с последните промени на закона за ДДС и коренното променяне на формата на файловете се оказа, че трябва да се правят промени. Негативите от програмата на данъчните си остава необходимостта от матричен принтер. Windows-ки програми не искам да ползвам. От една страна фирмите, които ги разработват изкара версии преди няколко дни, а от друга страна мигрирам всичко под Linux и не ми се разправя с някакви емулации.

Тъй като бях затрил изходния код на програма, която бях писал и се налагаше да почна от чисто, то реших като правя новите неща направо използвайки QT, така че да ги вкарам после лесно в RDSuite. Тъй като не обичам половинчати работи се наложи да направя plugin за кодовата таблица MIK, дето се е ползвала едно време под ДОС. Направих си и всички структури, които съдържат дневниците и генерират в последствие файловете за дискетата. Набързо налях в тях данни от csv файловете, които генерирам през електронната таблица и реших да тествам дали всичко е наред. Критерият беше дали програмата на данъчните ще поеме моите файлове.

Както може да се очаква нещата не минаха гладко. Непрекъснато се сблъсквах с това съобщение.


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


Разбира се, програмата, която писах за целта се мисля да я развия в някакво по-сериозно приложение с интерфейс и прочие, което ще бъде част от RDSuite и да може да си се ползва от всеки под Linux. Въпреки че не знам до колко това има смисъл, като гледам как RDSuite се сваля основно от Windows потребители.

И най-накрая само да отбележа, че DosBox е доста добър емулатор и фирмите, които правят счетоводен и складов софтуер, могат доста лесно да стъпят в Linux сегмента, като извадят от архивите старите си ДОС-овски програми, колкото да видят колко е голям пазара и ако отговаря на очакванията им да почнат на пишат native Linux приложения.

Счетоводство под Линукс

Една от причините да не пиша много в последните месеци е, че исках да доведа един от проектите, които движа до някакъв вид, който става за показване. Днес след като пооправих няколко неща, реших най-накрая да пусна първа версия на програмата RD Suite. Най-общо казано идеята на този проект е да бъде система за управление на фирмата, в чиято основа да седи счетоводна програма и всички модули в системата да си комуникират през счетоводната програма. За сега процеса на разработка е концентриран именно върху самата счетоводна програма, както и върху програмите за администриране на цялата система. Нещата са още в доста ранен етап. Има доста функционалности, въпреки че две от тях съм ги оставил посредата (става въпрос за едни по особени справки). Самата счетоводна програма да бъде напълно функционална се нуждае от още две основни неща. Едното е свързано с дълготрайни материални активи, а другото с поддържане на цени на база няколко принципа за материални запаси. Тъй като искам нещата да бъдат и документно ориентира по някое време трябва да направя частта, която позволява да се дефинират документи като формуляр на база библиотека от widget-и.
От гледна точка програмата да стане по user friendly трябва да почна да пиша нещо като документация. Освен това за момента имам проблем с обработката на SQL грешките. Postgresql връща кодовете на грешките като низ съставен от букви и цифри. За съжаление в QT библиотеката грешките могат да бъдат цели числа и това, което са направили разработчиците е просто да игнорират статуса на грешката при postgresql плъгина. Това е неприятно, защото като се издъни заявка не знам дали е заради синтактична грешка, недостатъчни права или нарушаване на някой първичен ключ. Явно трябва да пренаправям плъгина, което не ме изпълва с много въодушевление.
В този блог съм създал нова категория, която да касае новините около програмата. Не знам колко често ще пиша неща, но поне веднъж месечно ще гледам да споменавам нещо по темата. Като че ли това е засега. Коментари и предложения са добре дошли.