Re: Three Possible Bugs in 1.2.X

[David Godfrey <..hidden..>]

Hi Luke

Luke wrote:
> I am still on 1.2.18--but I don't think I read of these being fixed.
>
> 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.
>
> 1.  Definite bug...
>
> * Purchase order reports: the default report shows prices as $11.29.
> * Totals show correct on PO.
>
> 2.  Bug unless I misunderstand something.
>
> * Department was set on SO; it is unset on PO.
>
> 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.
> Actually that's a lie in this specific, because I obviously found the 
> order in order to confirm number 2 above, but only because it was the only 
> SO with the right characteristics in the right time period.  If this 
> happens tomorrow or later this week, I won't be so lucky.
>
> Purchase orders have a "PO Number" field.  I would expect that to be the 
> sisterfield to the "invoice number" field on invoices--the document ID 
> field.  Instead, the document ID field is "Order Number", which is where I 
> would prefer to see the number of the originating sales order, as a 
> reference field instead of a document ID field.
>
> Of course, that is not something that can change in 1.2, and maybe not in 
> 1.3, but if I don't have a screw loose, is this a reasonable change for 
> 1.4?

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 ?

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.

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.

Regards
David G