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