Да хорошо что делают, плохо что не совсем в том направлении. Бухгалтерию вот приделали, а складской учет нет, хотя программа именно складская. в двух словах чего нет:
1. Многоскладовость (достаточно просто делается) и как следствие нет возможности передачи товаров между складами
2. Как я понял операции - вшиты - от тут и негибкость выплывает, в частности в зависимости от операции нельзя форму другую вывести (хотя конечно Open Source позволит переделать)
3. Партионный учет ( в малых фирмах редко нужен, а в больших без него головняк)
Воооооооот.
пойду помучаю GNUe PS. Не подумайте что ругаю, но обидно блин.
Ок. Замечания конструктивные. Там (в дистрибутиве), кстати, есть один такой файлик. Называется todo. Хотелось бы и на его содержание услышать не менее конструктивные замечания.
И вообще, почему бы не взять да и не написать что-нибудь самому.... для пользы дела так сказать? :) Хотя бы ТЗ например... с описанием архитектуры :)
я, например начал бы ТЗ писать с того, что реляционщину нужно отрывать. Именно архитектурно. Т.е. может быть где-то там на уровне реализации таки и окажется что внутри будет PostgreSQL (у mysql уже транзкции живые?), но на middle-level не дножно быть никаких таблиц. Должны быть абстракции, наборы данных. Но никаких таблиц. Таблицы - это сразу ограничение себя. Зачем сразу себя ограничивать архитектурно?
далее, интерефейс, у вас вроде уже отрывается... Это хорошо, это нужно отрывать в первую очередь, и желательно выкидывать как можно дальше.
Продолжать? ;-)
На самом деле, может есть смысл попинать GNUe? А то какое-то распыление ресурсов получается...
В Ананасе не реляционный API сделан главным образом для того, что бы после того как он отмапится на команды скриптового (командного) языка, программист, специализирующийся на бухгалтерских проводках и документах, работал с понятиями близкими/аналогичными документам и проводкам, а не мучался каждый раз тем как операции над документами/проводками перевести в операции над таблицами/записями. То есть - важно понимать цель отрывания/абстрагирования от реляционных операций. Переносимость и возможность подмены в будующем SQL engine, тоже может быть целью. Но в Ананасе - эта цель отходит пока на второй план, так как считается несколько амбициозной при имеющемся резерве ресурсов.
Похоже GNUe движется... Я что-то давно к ним не заглядывал. Кто может в двух словах рассказать как у них дела? Дело в том что Ананас - реально используемая система и сейчас, например, в работе один заказ по доработке Ананаса. Когда GNUe будет реально работоспособной хотябы с ограниченным набором функций?
При компиляции ананаса с qt 3.0.3 выдает ошибку в модуле datavalidator - нет метода QRegExp::find, постмотрел хидеры - действительно нет, зато есть search. Заменил, откомпилилось. Действительно, пора подключать автотулсы.
Небольшое замечание по обработке ошибок - если нет коннекта к базе, в гуи ничего не сообщается, продолжается работа как ни в чем ни бывало (хотя и с нулевым результатом:), сообщения идут только на консоль, что идеологически неверно.
Кажется имеет смысл в будущем перейти с майскл на чистую БДБ. Во-первых, можно будет все документы хранить в одной таблице (дереве) - организовать наследование типов документов, может что-то еще (немаловажно при возможном расширении ананаса до полноценной бугалтерии). Во-вторых, будет значительно проще распостранять (инсталлировать) - будет один бинарник, может быть даже статически слинкованный с БДБ, это для однопользовательской версии, для многопользовательской можно\нужно будет сделать апп сервер поверх сальдолиб, ну и клиентскую прокси либу. Хотя и будет сложнее доступ выписывать (без скл). Да, сейчас, пока сальдолиб апи еще не утрясся, это наверное преждевременно, но вот развивать апи уже нужно с учетом возможного отказа от скл.
Спасибо на добром слове и интересных замечаниях. Я эту станицу пожалуй отправлю в список ananas@linux.ru.net Если еще у кого возникнет желание высказаться по теме так, что бы его слова остались в "истории" прошу делать это через список рассылки ananas@linux.ru.net, На который можно подписаться на сайте http://ananas.linux.ru.net
Привязочка к qt зело крупная ошибка. У меня к примеру никогда и ни на одной
машине qt не ставилась. Да и cpp в такого рода программах не уместен.
Короче хрень на палочке.