Re: Three Possible Bugs in 1.2.X

[Chris Travers <..hidden..>]

On Wed, Mar 3, 2010 at 6:57 AM, David Godfrey <..hidden..> wrote:
> Hi Luke

> I apologize in advance if I have misunderstood your need.
>
> As Chris has determined that a "proper" fix is not viable at this time,
> would an interim solution as follows do for bug 3 ?

I guess I should have noted that the pricing bug will be fixed
somehow.,  The rest can't reasonably.

>
> 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.

I think it would be quite possible to add a function to turn a single
sales order into a purchase order.  The only thing to be careful about
are assemblies.

>
> Crude but may be workable for you, obviously a search screen would be
> needed to make use of this information, but it may (depending on number
> of entries) be possible to have it just provide a list of all entries,
> and browser search can be used to find the one you want.
>
> Of course a far more elegant search screen could also be created.
> Alternatively, if you only need to use this reference from one screen
> (eg. receipt, or payment) it may be better to modify that screen to
> automatically provide the required functionality.

Either way, you are basically talking about a rewrite of this entire
workflow portion.

 Best Wishes,
Chris Travers