[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Three Possible Bugs in 1.2.X



On Wed, 3 Mar 2010, David Godfrey wrote:

Hi Luke

Luke wrote:
Base situation:

* Service with cost $10.45 and sellprice $11.00 added to sales order.
* Service is taxable, but customer is not.
* Sales order posted.
* Generated purchase order from sales order.
[.]
3.  Bug unless I misunderstand something.

* SO has information in the itemnotes field of the single item moved to
PO.
* Generated PO, for the same item, has a blank itemnotes field.

This would not be a problem for me, except that purchase orders do not
reference the original sales order, and so there is no apparent
relationship.  As such, since I sell a lot of these, I can't determine
which one this particular PO (and its resulting vendor invoice)
represents, and thus can not properly attribute payment information to the
supposed future vendor invoice, which is one of many already handled, but
not entered yet.

I apologize in advance if I have misunderstood your need.

You have not.

As Chris has determined that a "proper" fix is not viable at this time,

He's talking about backporting the 1.3 version of the code, but I don't know the timetable, and my understanding is that he first has to fix the problem in 1.3.

would an interim solution as follows do for bug 3 ?

Add a function that is called when you click on the button to create a
purchase order from a sales order. This function would create a new
entry in a new table containing 2 columns SOnumber and POnumber.

The new record would have the SOnumber set and an empty POnumber.
The SOnumber would be passed as an extra form parameter to the new PO.
When the PO is posted, if the SO form param is set, update the newtable
with the PO number.

Would it be easier to add an ordref column to the oe table? Pass the sonumber to the generated PO, and add code causing it to be saved in to the PO's eo DB entry in the orderref field if it is set.

I could probably figure out how to do these, if I knew where in OE.pl they're being done.

On a vendor invoice, then, it would be necessary to put a "Generated from sales order: " note, which displays the result of: select ordref from oe where ordnumber = $NAME_OF_ORDERNUMBER_INVOICE_FIELD limit 1;

Crude but may be workable for you [.]

Yes, either the original or my varient would be workable.

The difficulty For me at least, is knowing how to write it. IS.pl is one thing, but EO.pl is a different and rather more dense beast. I may be able to write some of it, especially for my simplified version, but short of reading through the file nearly in full, I have no idea where these things would be done.

Luke