standing purchase orders (or work orders)

[Nik Trevallyn-Jones]

Ok,

So it seems no one has any particular opinion (or interest) in this.

So I will code it as an extension to the Job concept.

I am not sure if it will work best if I create a new type of Job that 
has a "budget", or whether it would be best to just add the ability to 
have a "budget" to any Job.
But I will work that out as I review the GnuCash code.

Cheers!
Nik

On 05/06/2011 02:03 PM, Nik wrote:
> Hi All,
>
> I am using GnuCash to help manage my consulting business, and find a 
> particular issue is currently quite difficult to manage, but could be 
> dramatically simplified if I could automate it using GnuCash.
>
> At least one of my customers gives me a standing PO (purchase order) 
> which 'contains' a total amount of available funds which should cover 
> 6 or 12 months of work.
>
> As I perform work, I invoice against this one standing PO, and the 
> total 'available' funds in the PO is decremented.
> At some point, the PO has so little funds remaining on it that I 
> cannot invoice against it.
>
> So I need to be able to track the decreasing funds in the PO;
> firstly, so that I never present an invoice against a PO which has 
> insufficient funds;
> and secondly so that I can see when the available funds are getting 
> low and remind my customer that we need to top up the existing PO, or 
> generate a new one.
>
> Essentially, I need some entity in GnuCash represents the PO, which I 
> can create and where I store the appropriate value for available 
> funds. Then, as I /post/ invoices, I need the available funds in the 
> PO to be decremented (and incremented again if I unpost).
> In addition, I need to be able to view the details of all such POs:
> - customer;
> - job (optional)
> - creation date
> - expiry date
> - initial funds
> - available funds
>
> As an accountant, I am an excellent computer programmer - which is to 
> say I am pretty lost when it comes to accounting theory, so I have no 
> idea how such a feature should be modelled.
>
> Personally, I would prefer /not/ to represent a standing PO as an 
> account, as the POs tend to come and go over time, and I don't really 
> want a long list of inactive accounts in my system.
> I would prefer them to be either a new entity, or possibly an 
> enhancement to the Job entity.
>
> However, I am posting here to get advice on how best this feature 
> should be modelled, so feel free to disagree :o)
>
> As far as I can tell, regardless of how a standing PO is represented, 
> new code will need to be added to gncInvoicePostToAccount(...) to 
> correctly decrement from the standing PO; and to gncInvoiceUnpost(...) 
> to increment it on unpost.
>
> There should also be code that would warn me as I enter invoice data 
> that the standing PO associated with an invoice has insufficient funds 
> to cover the current total of the invoice. This obviously changes as 
> each change is made to the invoice.
> However, the funds should only actually be decremented from the PO 
> when the invoice is posted.
>
> With guidance on how to model the concept, I am happy to write the 
> actual code and provide it as a patch.
> However, I do need input on the various ways this could and should be 
> modelled.
>
> Thanks in advance for all input.
>
> Cheers!
> Nik