Re: Thoughts on Voiding Invoices

[..hidden..]

Hello All...

I have been semi-following this list and please parton me for jumping into
a discussion and perhaps going off the tangent.

I remember I once heard "there is a finished thesis and there is a good
thesis" regarding finishing grad school and getting off the $0.99 mac &
cheese diet. You know I am a fifth year SL business user and I have a love
hate relationship with it. SL sometimes just really get me to think about
cheating with commercial accounting software and taking a shot of Cuervo.

So if I must finish SL as a thesis I can think of two things that would
need to be done:-

1) Get more than just one person to architect, develop, and test the
project as two or more brains are better than one.
2) Fix the existing major issues that people are afraid to ask.

This first item I am very glad to have seen it happened and I have nothing
but good wishes for LSMB's future. The reality is I wish I could
contribute to it if could commit the time for sure.

Now for the second item, I am going to pick on SL's COGS issues as that is
such a big issue for business that sells goods. Just imagine if a business
has several million dollars of sales per year (consider by most as a small
business) then it would pretty much render SL usless for that business. I
have had the paid SL manual and I could never find anything in it that
warned me how not to screw up COGS. I have posted questions on the SL list
but I have never gotten a useful response other than your sheet balance
then everything must be good. Further, I also have searched the archived
list and I could just remember seeing the subject "COGS SOB a real pain in
the $&%#@" by Roy Someone (for which I concur). Consequently, I have drawn
the conclusion that it is either no one knows anything about SL's COGS or
everyone on the SL list is afraid to talk about it (I must also state that
we did not repost at the time the COGS problem was discovered).

Taking SL and adding bells and whistles to it will turn heads but
providing solutions to major issues will for sure get LSMB some happy
customers. It worries me to hear about all the new changes like applying
relational database theories to SL's schema and etc. Man, I am still
running 2.4.11 because I am afraid to upgrade to 2.6 and my SL is a
business critical system that has to constantly bill to surive. What if
LSMB has fixed the COGS and FIFO issues with SL am I going to be too
scared to migrate because I know it has done some major schema changes?
Oh, boy!

I fully understand at some point in the future LSMB will no longer
backward support SL but I hope that some point will be at least a year or
ten from now. Lastly, regarding applying referential integrity constraints
to SL's schema and using stored procedure it is probably good to consider
their impacts on its capabilities to cross database platforms and tools (I
know of flat tables financial database app. that supports billion dollor
companies because it served its purpose. I couldn't believe it at first,
and I laughed at it for using unique index and not null constraint to
enforce primary key).

This email has been therapeutic for me after years of using SL...peace!

Tim



>
>> Now, what interface do you propose that these function calls and stored
>> procedures have? This is what I mean by the API needs to come before the
>> data modelling. I guess I'm kind of agreeing with David Tangye that we
>> need to set some scope/requirements _before_ we start hacking and
>> chopping at the schema.
>
> Everything starts with how the data is stored.
>
>
>>  The information that
>> _needs_ to be on an invoice is pretty much specified by law/GAAP; who
>> cares how the system stores that information.
>
> I am sorry but that is a very careless statement.
>
>> What we need to do is
>> specify how we are going represent that information at the point where
>> we separate the business logic and the display. When I say display I
>> mean it in a very general way... It may be the Web interface that's part
>> of the project. It might be an XML/EDI document parser/generator. It
>> might even be a webstore (Interchange/osCommerce) that has chosen to
>> interface directly. Who knows how the API will be used in the future.
>
> Which all starts at the foundation, which is the database, the schema,
> and the data.
>
>>
>> I think SQL Ledger not having that very clear separation is a big part
>> of what has limited its adoption as a business infrastructure module.
>>
>
> Uhh no there was a lot more to it then that.
>
> Joshua D. Drake
>
>
>
> --
>
>    === The PostgreSQL Company: Command Prompt, Inc. ===
> Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
>    Providing the most comprehensive  PostgreSQL solutions since 1997
>              http://www.commandprompt.com/
>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>