Open Source Code or Free code 
Author Message
 Open Source Code or Free code

I'm trying to find out if there are any open source cobol programs out
there anywhere.  I havne't had much luck in finding
any....Specifically for accounting.  If somebody has some old
accounting source thats pretty uptodate that would be great.  The
reason i want it, is i have a very custom package written, and I was
possibly thinking of intergrating it with an accouting backend.  If I
can not come up with one, i will eiather bite the bullet and begin
writing one (which is like reinventing the wheel when it comes to
accounting -- the testing along), or try to get some intergration with
another package, but i would first like the source to some cobol app.

thanks jeremy



Sun, 17 Oct 2004 11:09:46 GMT  
 Open Source Code or Free code

Quote:
> I'm trying to find out if there are any open source cobol programs out
> there ...Specifically for accounting....   thinking of intergrating it
with an
> accouting backend...

While 'Accounting' is not my strong suit (once I get past the number of
beans I can count on two hands, I'm lost), it seems 'Accounting' is an
awfully broad term and subject to lots of interpretation.

I mean, does 'accounting' include.... Invoicing? Accounts Receivable/Cash
Receipts posting? Fixed Asset Depreciation? Payroll? Job Costing? Accounts
Payable? Cash Flow Forecasting? Inventory Analysis?

My point is, you may have better luck in your search if  either...

A. You can specify what you mean by 'accounting'
  OR
B. You can get people like me beyond the ten beans barrier.

MCM



Sun, 17 Oct 2004 19:59:16 GMT  
 Open Source Code or Free code
I have a similar package, and am in a similar position.  I also have an old
accounting package that works, though it is a mess, and I am about to start
over with it.  I would be interested in *starting* an open source AR system
that would act as a "back end" for custom packages.

Donald


Quote:
> I'm trying to find out if there are any open source cobol programs out
> there anywhere.  I havne't had much luck in finding
> any....Specifically for accounting.  If somebody has some old
> accounting source thats pretty uptodate that would be great.  The
> reason i want it, is i have a very custom package written, and I was
> possibly thinking of intergrating it with an accouting backend.  If I
> can not come up with one, i will eiather bite the bullet and begin
> writing one (which is like reinventing the wheel when it comes to
> accounting -- the testing along), or try to get some intergration with
> another package, but i would first like the source to some cobol app.

> thanks jeremy



Sun, 17 Oct 2004 19:59:18 GMT  
 Open Source Code or Free code

Quote:

> I have a similar package, and am in a similar position.  I also have an old
> accounting package that works, though it is a mess, and I am about to start
> over with it.  I would be interested in *starting* an open source AR system
> that would act as a "back end" for custom packages.

Don,

Is it truly worth it ? Ages ago I had a General Ledger package, (allowed for
different companies, branches and cost accounting). I even tried selling it for
$39 - one taker. It worked very successfully for the one user, no problems.
(It's not the product that sells itself, it requires you to be a bit of a
motor-mouth = salesman).

Considering something like Quickbooks, which I use - it is superb. Other than
specializing/customizing as you did with Inco - seems to me 'general accounting
packages' are a bit of a lost cause for somebody wishing to make some money.

Jimmy



Mon, 18 Oct 2004 02:35:20 GMT  
 Open Source Code or Free code



Quote:


> > I have a similar package, and am in a similar position.  I also have an
old
> > accounting package that works, though it is a mess, and I am about to
start
> > over with it.  I would be interested in *starting* an open source AR
system

> > that would act as a "back end" for custom packages.

> Don,

> Is it truly worth it ? Ages ago I had a General Ledger package, (allowed
for
> different companies, branches and cost accounting). I even tried selling
it for
> $39 - one taker. It worked very successfully for the one user, no
problems.
> (It's not the product that sells itself, it requires you to be a bit of a
> motor-mouth = salesman).

> Considering something like Quickbooks, which I use - it is superb. Other
than
> specializing/customizing as you did with Inco - seems to me 'general
accounting
> packages' are a bit of a lost cause for somebody wishing to make some
money.

> Jimmy

Not as a stand-alone package, for sure.  However, the money to be made is in
generating the transactions.  The real problems with most of the stand-alone
packages are threefold.  They are not big enough for a larger company (say
500,000 invoices a year), they are very difficult to export data into, and
they are impossible to break items down correctly inside them. For example,
I need a ledger not only in dollars, but also in tonnes of ore. Full debits
and credits.  I also have to calculate tax based on a split for each load
... one rate for the material, and a different rate for the shipping.  That
load must appear as one item on the invoice, as shipping rates are
considered trade secrets.  The portion of the amount that is shipping also
has to generate a payable to the trucker, and so forth.  Once an actual
invoice is generated, then a standard package could handle open items,
payments, aging, etc., but getting the invoices cut is very non-standard.

I suspect that a similar situation exists for many industries ... where the
generation of invoices is actually a complete system that does something
like keep timesheets, or manufactures a product ...  I use to computerize
concrete plants.  I produced a bill of lading, and then forwarded it to an
invoicing system.  A computerized concrete plant runs in the $75,000 range.
I could give the accounting away free.

That kind of integration is industry specific, and unless there is open
source, a stadard package is just not going to cut it.

Donald



Mon, 18 Oct 2004 03:10:45 GMT  
 Open Source Code or Free code
Donald,

I completly agree with you on all your points that you have made, and
with everyone else.  I would be interested on an open source package
that you mentioned.  The general accouting like A/R, etc..etc.. is
actually what I am looking for because the invoicing is very custom,
and to be able to send the data to A/R would be great, Its really no
problem to write A/R systems, but carefully planning would be needed
to write a backend accounting system to intergrate to other packages,
but have it open enough to allow for customization by the front end
customzied applicaton.  Also lets rememeber that accouting is
accounting no matter how u look at it.  Also i not sure I understood
you totally correct - you are willing to give the accouting portion
away? If that is so, that would help out a great deal.  I also have
been looking over other posiblites of intergration into other
packages, like quickbooks, and they provide and XML intergration, but
mainly with VB.  There would be ways using existing enhancements from
the COBOL vendors like Acucorp which i use, and Fujitso, which
starting to have some nice offerings.  But I' also am on the same line
as trying to provide a complete solution.  Also at the same time i'm
not in the business to provide accouting software.



Mon, 18 Oct 2004 13:41:37 GMT  
 Open Source Code or Free code
in www.google.com

find TinyCobol

or go to

http://tiny-cobol.sourceforge.net/

carlos lages

Jeremy Miedreich gravada:

Quote:
> I'm trying to find out if there are any open source cobol programs out
> there anywhere.  I havne't had much luck in finding
> any....Specifically for accounting.  If somebody has some old
> accounting source thats pretty uptodate that would be great.  The
> reason i want it, is i have a very custom package written, and I was
> possibly thinking of intergrating it with an accouting backend.  If I
> can not come up with one, i will eiather bite the bullet and begin
> writing one (which is like reinventing the wheel when it comes to
> accounting -- the testing along), or try to get some intergration with
> another package, but i would first like the source to some cobol app.

> thanks jeremy



Wed, 20 Oct 2004 07:13:41 GMT  
 Open Source Code or Free code

Serves me right <G>. Knowing you I should have realized there was already a lot
of deep thinking behind you initial short statement. Problem -  OO or non-OO ? I
guess the other guys are thinking non-OO.

Your reference, presumably to Inco (?), not only is it a self-operating,
stand-alone application, I guess you could now say it's a "fall-alone"
application <G>

Jimmy

Quote:

> Not as a stand-alone package, for sure.  However, the money to be made is in
> generating the transactions.  The real problems with most of the stand-alone
> packages are threefold.  They are not big enough for a larger company (say
> 500,000 invoices a year), they are very difficult to export data into, and
> they are impossible to break items down correctly inside them. For example,
> I need a ledger not only in dollars, but also in tonnes of ore. Full debits
> and credits.  I also have to calculate tax based on a split for each load
> ... one rate for the material, and a different rate for the shipping.  That
> load must appear as one item on the invoice, as shipping rates are
> considered trade secrets.  The portion of the amount that is shipping also
> has to generate a payable to the trucker, and so forth.  Once an actual
> invoice is generated, then a standard package could handle open items,
> payments, aging, etc., but getting the invoices cut is very non-standard.

> I suspect that a similar situation exists for many industries ... where the
> generation of invoices is actually a complete system that does something
> like keep timesheets, or manufactures a product ...  I use to computerize
> concrete plants.  I produced a bill of lading, and then forwarded it to an
> invoicing system.  A computerized concrete plant runs in the $75,000 range.
> I could give the accounting away free.

> That kind of integration is industry specific, and unless there is open
> source, a stadard package is just not going to cut it.

> Donald



Wed, 20 Oct 2004 07:39:48 GMT  
 Open Source Code or Free code
Actually, all mining companies keep tonnes in their general ledger at some
level ... their major asset is always reserves, and without it there is no
value for the comapny.  With gravel pits, "pit run" starts as your main
asset account, while stuff like "washed stone", and "pea stone" look like
inventory accounts.  You debit the pit run, and credit the various piles of
product as you screen and wash. It all has to balance, as you pay resource
tax on the weights.

At the code level, you actually issue invoices and refunds to a customer by
shipping trucks with positive or negative weights.  That ensures that all
taxes are reversed, as well as the inventory being adjusted correctly.

At Inco, I never got involved at the accounting level ... I just ran the
trains and counted/weighted boxcars with the computer.  I am still getting
over the fact that someone gave me a real electric train with a few hundred
miles of track to run with my computer, and even paid me for playing with
it. I really cannot imagine anybody doing that for a Java programmer <G>.

Donald



Quote:


> Serves me right <G>. Knowing you I should have realized there was already
a lot
> of deep thinking behind you initial short statement. Problem -  OO or
non-OO ? I
> guess the other guys are thinking non-OO.

> Your reference, presumably to Inco (?), not only is it a self-operating,
> stand-alone application, I guess you could now say it's a "fall-alone"
> application <G>

> Jimmy

> > Not as a stand-alone package, for sure.  However, the money to be made
is in
> > generating the transactions.  The real problems with most of the
stand-alone
> > packages are threefold.  They are not big enough for a larger company
(say
> > 500,000 invoices a year), they are very difficult to export data into,
and
> > they are impossible to break items down correctly inside them. For
example,
> > I need a ledger not only in dollars, but also in tonnes of ore. Full
debits
> > and credits.  I also have to calculate tax based on a split for each
load
> > ... one rate for the material, and a different rate for the shipping.
That
> > load must appear as one item on the invoice, as shipping rates are
> > considered trade secrets.  The portion of the amount that is shipping
also
> > has to generate a payable to the trucker, and so forth.  Once an actual
> > invoice is generated, then a standard package could handle open items,
> > payments, aging, etc., but getting the invoices cut is very
non-standard.

> > I suspect that a similar situation exists for many industries ... where
the
> > generation of invoices is actually a complete system that does something
> > like keep timesheets, or manufactures a product ...  I use to
computerize
> > concrete plants.  I produced a bill of lading, and then forwarded it to
an
> > invoicing system.  A computerized concrete plant runs in the $75,000
range.
> > I could give the accounting away free.

> > That kind of integration is industry specific, and unless there is open
> > source, a stadard package is just not going to cut it.

> > Donald



Wed, 20 Oct 2004 22:34:13 GMT  
 Open Source Code or Free code
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ The Air Applewood BBS Internet Gateway - +44-1279-792300 v.All
+                                          +44-1279-794008 ISDN
+
+ FidoNet user address: f609.n257.z2 (2:257/609) - FidoNet user name: Vince Coen
+

+ User FidoNet address: 2:257/609
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Hello Jeremy!

Tuesday April 30 2002, Jeremy Miedreich writes to All:

 JM> I'm trying to find out if there are any open source cobol programs out
 JM> there anywhere.  I havne't had much luck in finding
 JM> any....Specifically for accounting.  If somebody has some old
 JM> accounting source thats pretty uptodate that would be great.  The
 JM> reason i want it, is i have a very custom package written, and I was
 JM> possibly thinking of intergrating it with an accouting backend.  If I
 JM> can not come up with one, i will eiather bite the bullet and begin
 JM> writing one (which is like reinventing the wheel when it comes to
 JM> accounting -- the testing along), or try to get some intergration with
 JM> another package, but i would first like the source to some cobol app.

I have a small package that has Sales (& Invoicing), Purchase and Nominal
Ledgers written in Cobol but in a batching environment so would need to be
converted to online updating. I could make that available.

Vince
All context/ content herein is not the responsibility of
Air Applewood BBS nor it's ISP or agents.

No liability will be therefore be so held.



Mon, 18 Oct 2004 19:45:17 GMT  
 Open Source Code or Free code


Quote:
> Actually, all mining companies keep tonnes in their general ledger at some
> level ... their major asset is always reserves, and without it there is no
> value for the comapny.  With gravel pits, "pit run" starts as your main
> asset account, while stuff like "washed stone", and "pea stone" look like
> inventory accounts.  You debit the pit run, and credit the various piles
of
> product as you screen and wash. It all has to balance, as you pay resource
> tax on the weights.

It gets even deeper (pardon the pun). I once had an opportunity to buy into
a 'Sand Pit.' The sand in the ground was, of course, the main company asset
which depreciated as you sold the stuff.

When you sold out of sand, you are left with a hole in the ground.

The sand-selling company converts itself into a land-fill company and
accepts material to bury. The company's main asset, remember, is a hole. The
hole now depreciates as you fill the hole with tree stumps, broken concrete,
Jimmy Hoffas, and the odd car.

When the hole fills up, you cover the area with dirt and sell the land for a
low-cost housing development.

I passed on the opportunity. The accounting was just too weird.



Fri, 22 Oct 2004 01:45:40 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Data Recovery SOURCE CODE ( SOURCE CODES of Professional Data Recovery Software )

2. Converting FORTRAN source code to C source code

3. oPEN sOURCE - debugging Code

4. fast, fast, fast sin, cos, sqrt - OSI open source code

5. Open Source A/R & Accouting Code

6. Open Directory - Fortran Source Code

7. Free Clarion source code editor

8. We have Lots of Free Source Code

9. Free Source Code

10. DELTA Forth now with free source code

11. 200 MB Clipper source codes free

12. More free clipper source code!!!

 

 
Powered by phpBB® Forum Software