Ian,
> That would be great. Problem is that I need help on so many areas of
> OFBiz, it's difficult to know where to start.
Start with your first question. "Where is the door??". Then "ok, doorknob?". It always has to
start somewhere.
The trick is to make sure you give some (reasonable) lead time for the response to come. Ie, don't
go to your tailor 1 hour before closing time to ask for a new suit for the night!
Well, "reasonable" is pretty much tied to "motivation". So if you ask me what I think about
Martians, and all I care about are Mermaids, you'll probably hear from me when the Martians
finally visit us 50 years from now.
But since we're "hot" on cooperating, I'm all ears now. :)
> You sound much too busy at the moment to get into such things, so
> probably best left till the heat is off. I haven't even figured out if
> there is a PM system on this mailing list. How best can we get in touch?
Busy yes. Liability, plenty. But you could be the X-factor I need to take the heat off! Just email
me at my email adress.
> I guess the first thing would have to be the concept and the framework.
> From what I can see, this isn't just another hack job.
No, it isn't. From the entity engine to the front-end widgets and Minilang, you'll see that an
entire ecosystem has been grown just to make it easy to work OFBiz (I know, irony here, hold on
for a bit, I'll help).
Anyway, Java APIs have always been easy to handle. There are lots of solid 3rd-party modules
integrated into OFBiz, and tested. There's now talk of integrating telephony functions into OFBiz.
> There are some pretty obvious, straightforward, superficial
> red-flags that nobody seems too concerned about sorting.
I can't speak for the rest. But I'll tell you that someone here once said he liked OFBiz precisely
because of it's high cost of entry! I don't remember who. It's just human, you know? How would you
like to give arm and leg to help the next newbie understand your competitive advantage? :) That's
my job, by the way, to break vendor-lock.
> As I've said before. The last thing the guys in the workshop want to see
> is a moron standing on the forecourt complaining he can't open the door.
> It's a dirty job, but somebody has to do it :)
I know the veterans here will hate me for saying this, but this is the truth. It's not just
opening the door to the workshop. Speaking from a rather techie point of view, I'd say it's more
like new engineers are asking for access to the "documentation store" (only to find it somewhat
empty after prying it open).
One thing you need to know is that the veterans and community just went through a gruelling
initiation into ASF (apache software foundation). Many are burned out. Many need to get back to
work that piled up.
I believe that the "documentation store" will fill up over time, probably 1-2 years from now,
depending on how charitable the community feels with their spare time.
> I guess what I'd like to see is a team of engineers who are prepared to
> take up that kind of challenge. What does the average driver need to get
> on the road. What can we do to remove the obstacles in his way.
>
> If anybody is interested in working in that direction, that's certainly
> the way I'd like to go.
I don't know, actually. What are the motivations for investing in docs that catapult OFBiz idiots
(newbies) to status of OFBiz users? I'll only comment on this privately. Sorry.
But you're absolutely right. Getting OFBiz to average drivers will mean very easy sells. Tell you
something. My boss was about to give up on OFBiz several times already (yes, the functions have
problems, issues). I begged, oh I begged!
Just to let you know how buggy or polished OFBiz is. OFBiz framework should be considered separate
from the ERP functions that has been built with that framework. So, there's OFBiz framework, and
there's OFBiz ERP. OFBiz framework is marvelous, very tight and robust codes. It's what's built
with it, the "application layer" (not framework layer) so to speak, that's the problem.
It's like I give you a terribly buggy Java application. It can mean 2 things: either Java is
horrible, or I am incompetent. In OFBiz's case, the core framework is tight.
>> That's alright. You can help to testdrive and complain! I love
>> complainers! That's the best way I'll know to fix something.
>
> Great. So how do we begin?
Hmm. We can start with personal emails. Then I could set up a.. er... private Mantis (simple bug
reporter, like JIRA) for you. I'll guide you on how to get started real quick.
What I need from you is user-testing time, that's all. Enter data, test,
thrash, comment, complain.
It's not that I want your inputs for myself only. It's just that there really isn't anywhere we
can put your contributions for now. You already know where this mailing list stands (after
listening for weeks now?).
I'm looking to document OFBiz to a large extent. You can help me in documenting the ERP aspects of
OFBiz; I can work on the core.
>> Oh? I didn't realize that. Yeah, if you need help taking on that piece
>> of pie, we can help each other. But you might have to go through my
>> boss first.
>
> OK. So what do I have to do? Flying out to Singapore is not an option
> for me at the moment. What would your boss need me to do?
I'm working in Singapore (or Malaysia or Asia generally), my boss is in USA. Welcome to internet
connectivity.
To tell you the truth, my boss is one of those who are absolutely too busy with his business to do
a lot of comprehensive user-testing. I want my boss to be successful at what he does, so I
wouldn't want to take him away from his job. That's where you can help me! I'll help you in
return, of course. I mean, how can you do user-testing without a running instance of OFBiz??
Hey wait. Come to think of it, why don't you use one of my many "virtual OFBiz instances" instead?
No setup cost (time or money) for you! Yes, in case you're wondering, it IS possible to run many
virtual instances serving many domains owned by separate people. My boss has 1 virtual instance, I
have 1. Would you like 1 too? :)
> The trick would be to have some kind of filtering process, where easily
> solved dummy problems are dealt with by those with base-level skills,
> and really difficult ones can be referred upwards for the A-team to solve.
Volunteers volunteers volunteers, needed at every stratum. You don't always get enough volunteers
at every stratum. For example, how would you like to be labeled an OFBiz idiot and told to swim in
base-level forums? (Or conversely, you might hate being called "expert".) For example, in Asian
governments, it's not uncommon to see low-level competence in high-level staff. It's a very human
problem. Many people want to be where they cannot be. (I think White House has a room with my name
on it? Ha!)
I think private motivations (profit) generally drive advances even in opensource arena. Even
Mantis has sponsors (but I have a simple critical bug submitted some months ago that isn't fixed!).
I understand your ecosystem of "worldwide users" plus "phenomenal market awareness" fuelling "more
adoption". All that takes preparatory investments, capital/effort outlay. I believe many OFBiz
veterans here are already earning money selling small (compared to your vision), and probably
struggling to garner more support for OFBiz in their spare time.
But sure, we can go it ourselves, serve the average drivers market (which should be many times
more massive than race car driver market!).
Over time, we may have enough docs to form a repository that we can publish somewhere. I'd hope to
put that back to OFBiz community, but as you said, OFBiz veterans seem to have very different
focus than us average drivers.
We might put up a "sister/brother site" dishing out stable releases of OFBiz (just like what
OpenTaps is doing). Someone could manage community-building. We could have a definitive site
containing generous insider-tips, latest and greatest customizations, critical bugfixes that
aren't in OFBiz yet, etc.
Then you'll have contributed to OFBiz in a way you wanted to. And leave the rocket scientists to
enhance the core in peace (since many of my customizations and bugfixes will probably not see the
light of day in OFBiz, due to what?). But at end of day, all that at what costs to yourself?
>> OFBiz's Minilang (coupled with widget XMLs), when properly documented,
>> will be an extremely strong pull factor. If we could somehow breach
>> the divide between developers and users, OFBiz will certainly be
>> wildly successful and widely popularized virtually overnight.
>
> I'm with you 110% there too.
>
> So. How do we get this thing going?
>
> Can reverse-engineering solve that one too? :)
Absolutely. We're not even talking about compiled binaries! The source codes are open for all to
see. It's like having a mountain of blueprints, blueprints that when fed into a factory will
produce the product (so that eliminates problem of discrepancy between blueprint and actual product).
If you're willing to go at it, I can show you how it can be done. Have you done functional
programming and regular expressions? Need that at least to start. Well, ok, to cut to chase, you'd
be looking good if you have experience writing compilers and interpreters.
> This reverse-engineering thing sounds fascinating. Not sure what
> that is exactly. Do you mean looking at the effect and trying to
> figure out the cause?
Hmm. Something like that, for simpler cases.
You know how you can trace through an application's codes (follow code execution path) to figure
out how the application works? That's the brute-force way.
But very often, you can leap from point to point in pseudo-tracing through the application. Simple
detective games. You need to look at the effect, shotgun-assess chunks of codes, rapidly eliminate
false positives, pinpoint a few candidate causes, then work backwards from there to the effect
(that started the journey) to verify each candidate cause.
Pattern recognition. Work backwards.
Jonathon
Ian McNulty wrote:
Jonathon,
Got to say that I like where you're coming from here. Particularly your
attitude to complaints. I'm thinking Toyota production system and the
Honda ads. here - "Hate Something, Change Something, Make Something
Better."
> Can we all help each other? It would be great if we could.
Sure. We'll let each other know where we need help.
That would be great. Problem is that I need help on so many areas of
OFBiz, it's difficult to know where to start.
You sound much too busy at the moment to get into such things, so
probably best left till the heat is off. I haven't even figured out if
there is a PM system on this mailing list. How best can we get in touch?
I'm not exactly a programmer myself, Ian. Do I know all of Java?
Probably just 1% (well, ok, I did know 99% once).
Aha. There you go. I've forgotten most of what I knew too. But I never
knew any Java. So I'm trying to run from a completely cold start.
If I do happen to score well, it's because I worked on
reverse-engineering my memory faculties, not the programming topic at
hand. I went through school studying my learning faculties rather than
the topics at hand.
This reverse-engineering thing sounds fascinating. Not sure what that is
exactly. Do you mean looking at the effect and trying to figure out the
cause?
Yeah, shame on me. But you can say the same of many Singaporeans!
(Dispassionate, robotic, relentless bunch of soulless creatures.)
Yeah. I've heard such things said. But I never believe anything I see on
TV :)
What I'm saying is you, given your prior engineering experience plus
some sense of adventure and clever experimentation, can more than pick
up any concepts or tools you need to work OFBiz. Probably more than I
can. I'm just a simple reverse-engineer (problem-solver in general),
not a real engineer. I'm also one of those "average weekend drivers",
not just someone in overalls. Just focus on "whatever is relevant to
you at the moment", and you'll get started quick. I can try to show
you how if you'd like. Try my methods of picking up OFBiz or anything
in general. Won't hurt (I think). Take Andrew Sykes' advice to Andrew
Ballantine: "take a part of the code that is of interest to you
(you'll need relevance to stay motivated) and then work through
artifact by artifact".
I doubt I could pick it up faster than you. But nice of you to say so
anyway. Words of encouragement are always appreciated :)
That aside, I guess my attitude has always been pretty much as you
describe. The only computer language learned formally - Algol - was out
of date before I'd finished reading the manual. From then on I decided
not to worry about how much I understood. Just grab what I could, hack
it together and knock any bits that didn't fit into shape. Just get the
thing running. By any means necessary.
But there's something different about OFBiz that made me want to try a
completely different tack.
Hard to describe what that is exactly.
I guess the first thing would have to be the concept and the framework.
From what I can see, this isn't just another hack job. It's been so
beautifully designed from the ground up. A real leap forward and a world
beater if I ever saw one. I could be wrong. But I keep thinking that the
potential is just awesome!
The second thing would be how easy it was to get started, but how
difficult to get past first gear. I've never encountered anything like
that before. I manage to pin one problem down to something I think I can
handle, then suddenly another bigger one pops up somewhere else. And yet
none of this shakes my confidence in the original design. Very curious!!!
I guess my conclusion from all this is that the details are all sortable
in one way or another, but the main thing that seems to be missing from
the picture is the long view. OK, so all the bits seem to be roughly in
place. But step back and see what it looks like on the garage
forecourt. There are some pretty obvious, straightforward, superficial
red-flags that nobody seems too concerned about sorting.
How could that be, unless everybody was so busy concentrating on the
details of the trees that nobody had time to step back and look at the
general outline of the forest?
That's all that seems to be missing from this project, and the only real
contribution I thought I might be able to make:
Assume infinite ignorance and unlimited intelligence. Supposing I take
off my overalls and put on my business suit? Approach this thing as
someone who doesn't want to know how to use a spanner, just how to drive
it to work. What obstacles are standing in my way? Stop trying to hop
over obstacles, the way most of us usually do. Adopt a zero tolerance
policy. Don't move on until the problem is isolated, pinned down, boxed
up, and written down in the handbook.
As I've said before. The last thing the guys in the workshop want to see
is a moron standing on the forecourt complaining he can't open the door.
It's a dirty job, but somebody has to do it :)
Having said that, I think this group has been much more patient than any
other I have encountered to date. But I don't want to push it much further.
I guess what I'd like to see is a team of engineers who are prepared to
take up that kind of challenge. What does the average driver need to get
on the road. What can we do to remove the obstacles in his way.
If anybody is interested in working in that direction, that's certainly
the way I'd like to go.
But I do think we need another forum for doing this, so we don't get in
the way of the guys who are working on building an even better mousetrap
than what's already there.
Exactly what that forum could be is something I'm still not clear about.
All ideas greatly appreciated.
I believe that you'll be customizing OFBiz within a day of research,
just like I did. Just like many folks here did, I believe.
Join us! (or *hynotically* "join... us... join... us..."). Heh.
I appreciate your encouragement and think you're probably right.
But I really do believe that somebody has to step back from all this and
play the average driver on the forecourt.
I believe this is the most useful thing I can do at the moment and am
determined to try and keep doing it until somebody chucks a spanner in
my works :)
Well, my boss (and previous bosses) will probably tell you I can be
irritating when I kept trying to make a software engineer out of him.
But I'm seriously telling you that OFBiz is a solid framework you can
easily build on/with. No kidding.
I have absolutely no doubt about that too.
We just need to get the documentation and user manuals in place...
Absolutely my opinion too.
That's alright. You can help to testdrive and complain! I love
complainers! That's the best way I'll know to fix something.
Great. So how do we begin?
> For the past few years I've been installing Open Source e-commerce for
> SMEs. It's a huge and expanding sector. 150,000 members on
osCommerce and Zen
> Cart forums alone! With up to 2,000 online at any one time! But the
problem
> they are all now facing is, now they have a successful website, how
do they
> integrate the back end with in-house accounting and POS? Which is how I
> discovered OFbiz in the first place.
Oh? I didn't realize that. Yeah, if you need help taking on that piece
of pie, we can help each other. But you might have to go through my
boss first.
OK. So what do I have to do? Flying out to Singapore is not an option
for me at the moment. What would your boss need me to do?
> I care deeply about Open Source and want to see it grow. I understand
> why Formula One racers might not see what weekend drivers and
> glove-compartment handbooks have got to do with them. My point is
that a
> wider user base increases the market, the need for all levels of
> mechanics, and the bargaining power of the top class engineers.
We'll need a really solid effort to do all that, multi-tiered forums
and all. Lots of work in forum moderation (but sure, we can recruit
solid volunteers to help in every stratum). And then OFBiz might
become like MySQL. Or sellout eventually like Compiere?
I suspect that once the framework of some kind of open forum was
established, there would be no end of volunteers to moderate it.
The problem with all such forums I've seen is the level of contact with
the core developers.
In Zen Cart for instance, the core team seem to be online all the time
and must be worked half to death trying to keep on top of it all. I
can't believe that one day they aren't just going to give up and walk
away. So this would not be a great way to go.
On the other hand, on Ubuntu, there seems to be no route through to the
developers at all. So big issues are left hanging for months unresolved.
The trick would be to have some kind of filtering process, where easily
solved dummy problems are dealt with by those with base-level skills,
and really difficult ones can be referred upwards for the A-team to solve.
OFBiz's Minilang (coupled with widget XMLs), when properly documented,
will be an extremely strong pull factor. If we could somehow breach
the divide between developers and users, OFBiz will certainly be
wildly successful and widely popularized virtually overnight.
I'm with you 110% there too.
So. How do we get this thing going?
Can reverse-engineering solve that one too? :)
Ian
Argh. Last ounce of energy. 2am. Later.
Jonathon
Ian McNulty wrote:
Jonathon,
Your words of comfort are much appreciated. My instincts tell me
OFbiz rules and I suspect God may too. So Amen from me too!
Can we all help each other? It would be great if we could.
But I think I need to make my position clear at the outset, to avoid
possible disappointment further down the line.
I've been working with computers on and off since the late 60s and
have had to learn to hack various languages, from Algol through to
php. But it was never my major area of expertise. I never got into C,
so OOP and Java is still entirely new territory for me. Java,
Minilang, or Freemarker, I'd have to learn them all from scratch,
will always be miles behind everyone else, and could be in serious
danger of being more of a cost than a benefit. I've just starting
reading Bruce Eckel's Thinking in Java and starting thinking, maybe
there just aren't enough years left to get up to speed on all this?
This could be either a major weakness or a strength, depending on
where I'm standing and what people might be relying on me to do.
From what I've seen on this group over the past few weeks, there is
no shortage of top class engineers who I have no doubt could strip
down the engine and stick it back together again working better than
ever, before I'd finished making the morning tea (or coffee,
depending on what side of the pond you're on. :)
I'm enough of an engineer to know how utterly irritating it is to
have people whittering on about irrelevancies like sticking door
locks when you've been up all night regrinding the cylinder head. But
I've also been down that road enough times to know how crucial it can
be to have someone fresh to take over, to wipe the grease off the
bonnet, polish the chrome work and wheel it out onto the forecourt,
after you've done your bit and just need to go home to bed.
So I guess what I'm saying is that, for the moment at least, I'm
better off leaving the engineering to the experts and focussing on
what the average driver needs to see.
For the past few years I've been installing Open Source e-commerce
for SMEs. It's a huge and expanding sector. 150,000 members on
osCommerce and Zen Cart forums alone! With up to 2,000 online at any
one time! But the problem they are all now facing is, now they have a
successful website, how do they integrate the back end with in-house
accounting and POS? Which is how I discovered OFbiz in the first place.
There are many points that come out of this. Too many to properly
discuss here.
First would be a huge potential market with installation fees of $3K
upwards, and with very little heavy engineering required at all.
Store owners care mainly about the look of their shop windows, the
learning curve for their staff, reducing staff overheads and the
reliability of the whole thing, and are prepared to pay for it. After
a while they start to understand the benefits of tuning the engine,
which is where the heavy engineering work kicks in. But this is
something they will not even contemplate until they are confident
they have a solid vehicle that will take them reliably from A to B.
Second would be how the structure of these forums cultivate many
levels of users, from Formula One engineers all the way through to
those who don't even want to fill up the windscreen washer
themselves. And this is only the tip of the iceberg. For every one
member on these forums there are 9 others who can't even handle the
log in and just want somebody to take care of it all for them.
I care deeply about Open Source and want to see it grow. I understand
why Formula One racers might not see what weekend drivers and
glove-compartment handbooks have got to do with them. My point is
that a wider user base increases the market, the need for all levels
of mechanics, and the bargaining power of the top class engineers.
If anybody thinks this make some kind of sense, please let me know.
Ian
Jonathon -- Improov wrote:
Er, Ian. I forgot to mention this.
The docs for engineers aren't too comprehensive either. Try putting
your best Java developers into picking up OFBiz. Take the screen
widgets and form widgets for example. See how they fare. Like I
said, Java is more documented than OFBiz-specific technologies.
BUT.. but it's entirely possible to use Java only, plus
non-OFBiz-specific technologies like Freemarker for front-end
develo
ent convenience, and to skip Minilang and screen/form
widgets to a large extent. Non-OFBiz-specific technologies are
generally better documented since their developers focus develoment
time solely on those techs, like Freemarker (front-end tool)
developers don't delve into entity engines (backend tools).
As I was telling my boss, it's actually easier to hire Java
programmers than to hire Minilang or screen/form widget programmers.
So, beware of the implications. Say I code customizations for you in
Minilang and screen/form widgets, using almost or entirely zero
Java. Future tech support could be an really hairy issue for you.
BUT... at some point (I can't guarantee when), Minilang and
screen/form widget docs will be complete, audited to be
comprehensive, etc. You'll then probably find that programming in
Minilang is more cost-effective than in Java. (Either that, or I get
paid by someone to completely reverse-engineer and document all of
Minilang and screen/form widget in a reasonable timeframe --- say a
month. Not an impossible task, just a mountain of Java codes, is all).
For now, Java is perhaps your best bet.
To the other folks in overalls, I've been meaning to ask this. Is
there any way at all to insert debug messages inside of Minilang and
screen/form widget codes? I find it easier to debug Java codes for now.
Jonathon
Jonathon -- Improov wrote:
Ian,
Amen! Yeah, God is good. OFBiz is good. Both can be hard to
understand. But I do believe that both are loving, very loving. Amen.
If there's any way we can all help each other (Paul, Ian,
Jonathon), let me know.
Jonathon
Ian McNulty wrote:
Hi Jonathon and Paul,
Could I dive in here and say I'm currently trying to get a working
model up and running that I could demo to small business clients
in the UK.
OFbiz looks so beautifully designed from the ground up, streets
ahead of the competition and adaptable to almost any situation
from running a one-man consultancy to a multinational enterprise.
It looks like the most awesome super-car you've ever seen. I can't
believe everybody won't want one.
As Jonathon says, the community seems entirely focussed on moving
forward rapidly and winning the next Le Mans. Which is how it
should be.
Imo this explains the lack of docs and the small bugs. The mass of
available documentation is actually almost as awesome as the
framework itself. Problem is that it is all aimed at engineers who
need to understand how it works ... not how to work it. Enough
workshop manuals to fill shelves in the garage, but no simple
driver handbooks you can put in the glove compartment.
This is a very fundamental difference. An entirely opposite point
of view.
Try talking to the average driver about the thermodynamics of
combustion and they glaze over in seconds. They neither need nor
want to know. They simply want to drive it. They pay the garage to
take care of all that for them so they can free themselves up to
deal with other things - like where to drive to.
It's the little, superficial things that are most important. How
does the door latch sound? Where is the gear shift and indicator
switch? How often does it break down?
This is true for all levels of users. More so in fact for the
President of a large Corporation to whom image arriving at the
golf club is everything, than to the small businessman in the
street who accepts he may have to get his hands dirty occasionally.
Winning the Le Mans is obviously a huge selling point and an
essential place to start. In those circumstance, a door latch
which needs a knack to open, the absence of a drivers handbook and
the need for team of mechanics to tune it before every race is
absolutely par for the course. And a racing driver who complains
about such things will - quite rightly - be quickly shown the door.
But for the average driver in the street it's exactly the
opposite. One sticking door latch, one miss-start, one breakdown
on the first test drive and they've had their one bite of the
cherry and ain't never coming back for more.
Imo this is the only problem I'd like to see solved.
I started out a few weeks ago trying to point out that this list
is more for users in overalls at the pit stop than drivers in
business suits on their way to the office.
Imo a forum for user-drivers rather than user-engineers would help
focus the view from the other end of the telescope and prevent
discussion of such superficial issues from clogging the inboxes of
the rocket scientists who really need to be concentrating on
getting us to Mars.
I personally would like to contribute towards the development of
some kind of drivers handbook. But if I can't get a working model
going for myself then it's hard to know where to start.
Ian
Jonathon -- Improov wrote:
Hi Paul,
I believe I'm currently doing it for a small business as well.
You'll need to customize. Customization in this case involves
defaulting many values and code execution paths for a more
condensed workflow. That is, you can cut out some unnecessary
steps in the workflow and also auto-populate default values for
some fields (or leave them blank and unused).
I propose that we work together on this? I have yet to hit the
accounting and GL side of things. I have figured out the
ecommerce (PO, SO) and product configuration side of things,
though. And also manufacturing, because my boss does manufacture
stuff.
You'll find that being a novice Java developer is ALL you need to
be, the framework is that easy to use. Well, you also need acute
reverse-engineering skills because the only way you'll find out
how things work is by diving into the framework source codes (see
GenericDelegator.java for entity-related functions). No docs.
Community is too being moving OFBiz forward rapidly.
In fact, you may find it easily initially to use Java instead of
Minilang. Java is a lot more documented than Minilang.
Tell you what. I can offer you very quick answers to "how do I do
this or that". I'm a reverse-engineer by trade; I have small
crack teams that mathematically take apart legacy system codes to
break vendor-lock for my clients. So, figuring out OFBiz, given
that it's opensource no less, is really... an interesting
exercise, not a tedious impractical one.
You can help me with your accounting knowledge. (Yes, help me!! I
beg you!)
How about that?
One warning, though. There are quite a few bugs in OFBiz. They're
small issues if you can dive in to fix them yourself. But if
you're waiting for the community to fix them, you could be
looking at weeks before a patch goes in, especially for
non-trivial fixes that take time to review/audit. I'm currently
holding quite a number of fixes in-house, not yet reviewed by
community and merged back into OFBiz.
I'm deploying a customized system for my boss inside of 1 month.
And he has quite a bit of customizations to do, particularly for
the manufacturing side of things. Oh, the Manufacturing module is
very feature-rich (thanks Jacopo!), just that my boss has special
needs. I'd say we could work together and customize OFBiz for you
inside of 2 weeks?
Jonathon
Paul Gear wrote:
Hi folks,
I'm looking at different accounting/business management packages
for use
in my small business, and i was excited when i found how
comprehensive
and easy to install opentaps was.
However, it is a daunting application for the beginner, and it
leads me
to ask: is it asking for trouble trying to use it as a small
business
accounting package? My requirements are fairly simple: invoicing
(services only, no inventory), general ledger, and GST tracking
for the
Australian tax system.
I'm a novice Java developer, so i can get through most basic
problems
OK, but understanding the framework is a bit more complex an
undertaking. Am i just creating work for myself thinking that i
can use
OFBiz/opentaps for my small business?
Thanks in advance,
Paul
<http://paulgear.webhop.net>
--
Did you know? Using HTML email rather than plain text is less
efficient, taking anywhere from 2 to 20 times longer to
download, and a
corresponding amount more space on disk. Learn more about using
email
efficiently at <http://www.expita.com/nomime.html>.
