How to Flow a UDF from Sales Order Header to SO History Header Reliably

With identical UDF names in both tables, the original value set into the SO Header UDF via a ColumnPostValidate script from a standard field works to flow the value to SO History Header, but subsequent successful updates directly to that SO Header UDF from within the SO SalesOrder Bus object are not copied to the corresponding history UDF. Just the first. I see no explicit way to set this up because their appears to be no Data Source on which to define a SO History Header UDF from a SO Header.  The first copy must be auto programmed?

Advanced version 2020

Parents
  • 0

    I tried many years ago to script "freight already invoiced" for partially shipped SO, and failed... probably because of the issues you are describing here.

    Alternate idea:

    • Scripted SO UDF, with UDT validation (for the link). 
    • Add a row to the UDT during order entry (SO# as they key, also set in the header UDF after adding it to the UDT), so you have a linked place, outside the SO business objects, to hold extra values. 
    • Then, during the journal posting, open the UDT, and update a column to hold whatever you want. 
    • With the UDT validation link, you should be able to put the other column(s) from the UDT onto SO / SO history panels (display only).

    (Untested, but this is what I thought of to try, if the question ever comes up again).

    Of course, a proper Sage fix is best, but if you need something now, perhaps this idea is worth a try.

  • 0 in reply to Kevin M

    Good idea and I'm glad I'm not alone in this. Since it works to save the residual FreightAmt UDF in the SO_Header, I realized that the client can report on their outstanding freight obligation by using SO_Header. My journal update script has access to both the invoice and the sales order so that I can reduce the sales order FreightAmt residual UDF by the invoice's FreightAmt until the sales order is completely depleted. Which, in that case the residual FreightAmt may be considered zero. Think Left Outer Join. The only downside I see is that if their freight calculation at order time is wrong. Your idea would solve that.

Reply
  • 0 in reply to Kevin M

    Good idea and I'm glad I'm not alone in this. Since it works to save the residual FreightAmt UDF in the SO_Header, I realized that the client can report on their outstanding freight obligation by using SO_Header. My journal update script has access to both the invoice and the sales order so that I can reduce the sales order FreightAmt residual UDF by the invoice's FreightAmt until the sales order is completely depleted. Which, in that case the residual FreightAmt may be considered zero. Think Left Outer Join. The only downside I see is that if their freight calculation at order time is wrong. Your idea would solve that.

Children
No Data