On Tue, Sep 11, 2012 at 1:25 PM, Chris Bennett
<..hidden..> wrote:
See comments inline:
I had some health issues (mine and family too) that mostly shut me down
for a good while. Accounting became temporarily irrelevant for a time.
What I did have plenty of time for was to do my own programming to get
together what I needed in-house to be able to do right now estimates AND
prepare estimates for future items that are likely.
I have not had much time to dig into LSMB programming and it is changing
rapidly, which is great!
I like what I have quite a bit, but I want to tie it into LSMB.
>From what I read on the mailing list, quite a few people are doing or have
done customized work.
I also see that there are two code bases. 1.3 and 1.4.
1.3 introduces a new framework. 1.4 tidies it up and extends it. I expect that we will move again one more time before 2.0 as we address some important shortcomings with the 1.3 framework, particularly involving cross-language integration. However, that is neither here nor there, and will be a couple major versions out. I will say that if I get my way, I will be writing a generic db interface *first* and put that on CPAN, and *then* move things to it, so there will be time to review and discuss. Once 1.4 gets into beta I will make my proposals for a design. I have a couple other integration-related projects that will be started around that time also.
>From others experiences, how should I integrate into LSMB?
Is a web interface connection (behind the scenes I am guessing) be best?
Ick..... I don't like to recommend that. It's a lot of parsing of HTML and the HTML particularly in the old code has its ideosyncracies.
Should I go directly into the objects?
In Perl that's the best way.
Will I have a big problem with my work when upgrading from 1.3 to 1.4?
The db schema hasn't changed a lot. The object model for a few things has, namely customers and vendors has been greatly cleaned up to the point where if running Moose is ok, I would suggest running the 1.4 modules against your integration scripts. Since these do not rely on schema changes, you should be able to run them side-by-side 1.3 modules against the same db. Also the structure of projects and departments has *radically* changed. The old project/department system has been pulled out and a new business reporting unit system has been put in place. This does a superset of what the project system did, and in addition you get:
1) Nested projects and departments
2) An ability to define new classes of reporting units. This allows funds accounting to be supported by configuring the software (useful for not-for-profits).
3) A more generic interface for reporting.
Now that business is once again going forward, I have less time to
program than before. I need to "get it right" the first time, if
possible.
I don't know how many people might benefit from my system that allows me
to use free time to prepare Materials and Labor estimates before use.
I want to be able to pull these estimates into LSMB when, and not
before, they are needed. Since they are fully prepared beforehand, I
just want to be able to yank them right in, without a lot of manual
fiddling.
In Perl, create a $form and use functions in OE. That's the easy way. If you want to share logic, then create stored procedures for this. There are no significant schema changes here between 1.3 and 1.4.
If anyone is interested in working with me on this, that would be great.
If not, then any useful advice on how best to accomplish this would be
appreciated.
I don't see exactly what the code roadmap is, so that leaves me a little
crippled for planning my efforts properly.
We haven't set goals for 1.5 yet. I would like to get into replacing the financial logic with something more normalized and clear. However, that may take some time. I think we can deal with order entry in 1.6. However propriorities will be set during the 1.4 beta period.
Best Wishes,
Chris Travers