[GNC-dev] Adding module to make GnuCash more valuable

[Christopher Lam]

Rosi

The core of the issue is the different purposes and needs for your software
vs a general-purpose bookkeeping software.

Your particular requirements have particular terminology that cannot be
solved via GnuCash.

A different example is - we can shoehorn running a full medical practice
into GnuCash database -- after all the system has customers (patients),
vendors (suppliers), employees (staff), basic entries (notes), sending
tests to lab (includes the invoicing), receiving results (reconciliation),
etc but nobody will ever try fit in a full business into this software.
GnuCash *can* be a small part of the solution, but the document management,
tracking, authentication, signatures, etc must be a different tailor made
product.

Good luck in your search!

On Fri, 26 Jul 2019 at 06:07, Rosi Dimova via gnucash-devel <
gnucash-devel at gnucash.org> wrote:

> Hi Derek,
>
>
> > On 25 Jul 2019, at 17:51, Derek Atkins <derek at ihtfp.com> wrote:
> >
> > Rosi,
> >
> > Rosi Dimova via gnucash-devel <gnucash-devel at gnucash.org> writes:
> > ...
> > I think the issue here is that GnuCash could be used to keep track of
> > the value of the B/L, and even record when the transfer happens, but it
> > does not have the capability to actually *transfer* the actual B/L
> > between entities.
>
> GnuCash doesn’t need to keep track on the actual value of the B/L. There
> is no value in terms of accounting. It’s just a supporting document as
> proof of service provided.
> Accountants do not collect any B/L’s. No one should. Only the issuing
> party and the appointed agent on B/L. You either have paper originals, or
> express/telex release. For B/L this is the only way to identify the owner
> all over the world and it is recognised by all involved entities.
>
> A bit off-topic:
> The only values you can see on B/L are the rates of the transport itself
> and they are not always obligatory. It’s “value” is only defined in force
> majeure like General Average by calculating number of packages or gross
> weight with special delivery rights (SDR). That’s all.
>
> > I think the closest you could get would perhaps be the business features
> > in terms of the Invoice operations, but I don't think that applies here,
> > either.  That's an AR operation.  You create the Invoice when to
> > initiate the Receivable, and inform the customer that they owe you
> > money.  However, there is no document that shows when the invoice has
> > been paid, per se (there is the ability to re-print the invoice and show
> > the payments on it).  But I don't think that counts as a B/L.
>
> You are right, it doesn’t. And that explains why it cannot be done. I was
> hoping that an additional template for printing will do and adding document
> number (some ID) from the data base will maintain the tracing of the b/l’s
> issued. Re-printing is forbidden for paper originals - exactly three
> originals, no more, no less. And the existing software still allows it. :)
> I never thought the actual document will be part of the transactions.
>
> > GnuCash does not currently have any support for digital signatures, nor
> > does it have any way to import/sign/export a multi-stage Invoice (or any
> > other document).  And I'm with John (and everyone else) here.  I don't
> > think GnuCash is really the right tool to implement that.
>
> I agree with all of you now.
>
> > I will also note that in my $DAYJOB I am working on building an
> > ownership transfer system sort of like a B/L but more designed for IoT
> > so that the end owner of a device and prove that it's the device's owner
> > (and then provision it) without requiring any UI on the device itself.
> > But again, it's not quite a B/L system, even though it has the ownership
> > provenence piece of a B/L system embedded in it.
> >
> > Good Luck,
>
> Yeah, you all have day jobs, never had any doubt about that. Seems there
> is nothing useful I can share with you. Your system sounds to act exactly
> as B/L, perhaps on at least two layers like MBL & HBL. If anyone is
> interested in this topic, feel free to contact me personally.
>
> Thank you for your patience and good luck to you, too!
>
> Kind regards,
> Rosi
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>