Jiwa

https://service.jiwa.com.au/browse/DEV-4416 has some discussion about getting carrier information copied to a new snapshot.

I'd like to do this.

This is a continuation of my (tangentially) related challenge around automatic backorder release on shipment book-in. The release is working, but my generating of an XML for export to our 3PL is failing because there is no carrier information on the newly created snapshot.

Would it be sufficient to populate SO_HistoryCarrier from somewhere in, say, SalesOrder.SaveEnd ? Presumably I need the new snapshot's RecID first?

Hi Ryan

This should be possible in a form plugin as I did a similar thing when adding extra fields to the sales order form that were kept in another table and needed to work in extra controls on the form. These are the steps

Declare a private sales order variable in the form plugin
Assign the forms sales order property to it in setup for the form plugin
The sales order has a copy end event write a handler for this and assign it in setup as well
In this handler the object passed in as sender will be the new sales order
Copy the values for carrier from the forms private sales order variable to the cast object that was passed into as the first parameter to the handler

The signature for the copy end handler is

Code: Select all

public void CopyEnd(Object sender, System.EventArgs e)

This should go in the setup

Code: Select all

salesform = (JiwaFinancials.Jiwa.JiwaSalesUI.SalesOrder.SalesOrderEntryForm)JiwaForm;
salesorder = salesform.SalesOrder;
salesform.SalesOrder.CopyEnd += CopyEnd;

Hope this helps.

Thanks Stuart, but my case is a little more complex than that.

The snapshots are not just being created from the front-end.

We've got a business object plug-in that traps shipment book-ins and automatically runs the backorder release process for parts on that book-in.

That part is working. However, once the backorder is released, we need to send a ship instruction to our 3PL. So I have trapped the various events triggered by JiwaBOProcess.StdFunctions.Process to get the new snapshot so I can export the XML. By some trial-and-error over the weekend, I got down to a combination of ProcessSnapshotCreated (gives me InvoiceID and InvoiceHistoryID) and ProcessComplete or BOProcessComplete.

from there, I can:

Code: Select all

Dim so As SalesOrder = JiwaFactory.CreateBusinessLogic(Of SalesOrder)(Nothing)
so.Setup()
so.Read(InvoiceID)
Dim newSoH As SalesOrderHistory = so.SalesOrderHistorys(InvoiceHistoryID)

and have a valid sales order and history objects. And that history object has carrier details if I'm stepping through with the debugger. But after it leaves my code, they seem to get lost. I'm still trying to work out whether it's before or after JiwaBOProcess.StdFunctions.Process completes, but it goes AWOL by the time I can look at the order in the front-end.

I have some more research to do, but will respond again when I have something more. Possibly even a plugin to demonstrate (although producing something de-cluttered enough for this discussion will have its own challenges)

Hi Ryan

In that case my only other suggestion would be some custom fields and store the values there as the custom fields come across in the copy but that's fairly messy. You could also use the GenericObjectCollection with read end and then copy the values back out after copy ends but I don't know if copy clears this collection.

You could also possibly try writing a sales order history carrier changed event handler (SalesOrderHistoryCarrierChangedEventHandler) and see what is changing things, I can tell you copy instantiates a new carrier but doesn't copy the details across from the old order. SalesOrderHistoryCarrierChangedEventHandler signature is

Code: Select all

public delegate void SalesOrderHistoryCarrierChangedEventHandler(object sender, EventArgs e, short HistoryNo, string FieldName);

pricerc wrote:... and have a valid sales order and history objects. And that history object has carrier details if I'm stepping through with the debugger. But after it leaves my code, they seem to get lost. I'm still trying to work out whether it's before or after JiwaBOProcess.StdFunctions.Process completes, but it goes AWOL by the time I can look at the order in the front-end.

a correction, before I call it a night again (it's closing in on midnight where I am).

I can set the carrier information in my code, and it be there when I save the XML for the 3PL, but the carrier information doesn't make it to the database (with either SOH.Save() or SO.Save(false,false).

I am (with my latest code) populating the carrier with this:

Code: Select all

            Dim priorSoh = soh.SalesOrderHistorys.Item(newSoH.HistoryNo - 1)
            newSoH.Carrier = priorSoh.Carrier
            newSoH.Carrier.SalesOrderHistory = newSoH


(I've also tried just copying the account number and service details)

Hi Ryan,

OK now that I have a better idea of the exact problem I think what is causing the issue is the fact that the necessary conditions to get Jiwa to save the carrier for you are not being met namely that the change flag is true and the recid is not an empty string. You can't call the setter for recid it is internal

Try calling ReadRecord on the Carrier this takes two parameter as follows SeedValue and SeedIsID if the second parameter is true then its expecting the first to be a value in FR_Carriers.RecID if its false its expecting it to be FR_Carriers.CarrierName, when this function is called it will also fill the services collection for you and freight items collection for you that are appropriate for the Freight carrier.

Hope this solves it for you.

So this has been fun. Doing a ReadRecord on the carrier doesn't seem to help.

Along the way, just using the UI, I noticed this:

and this:


(i.e. the carrier details were there after the snapshot is created, but go missing during the save)

then after poking around in the debugger, I saw this:


I found if I manually changed the ChangeFlag, then it saved the carrier information.

So I eventually tried this:

Code: Select all

        Public Sub Setup(ByVal JiwaBusinessLogic As JiwaApplication.IJiwaBusinessLogic, ByVal Plugin As JiwaApplication.Plugin.Plugin) Implements JiwaApplication.IJiwaBusinessLogicPlugin.Setup
            _salesOrder = TryCast(JiwaBusinessLogic, SalesOrder)
            If _salesOrder Is Nothing Then Return ' Panic

            AddHandler _salesOrder.CreatedNewSnapshot, AddressOf salesOrder_CreatedNewSnapshot
        End Sub

        Private Sub salesOrder_CreatedNewSnapshot(sender As Object, e As EventArgs)
            Dim soh As SalesOrderHistory = _salesOrder.SalesOrderHistorys(_salesOrder.SalesOrderHistorys.Count)

            Dim cf As System.Reflection.PropertyInfo = soh.Carrier.GetType().GetProperty("ChangeFlag", System.Reflection.BindingFlags.Instance Or Reflection.BindingFlags.NonPublic Or Reflection.BindingFlags.Public)
            If cf IsNot Nothing Then
                cf.SetValue(soh.Carrier, True)
            End If
        End Sub


I suppose it's naughty, but it seems to at least get a record into the SO_HistoryCarrier table!

So that last post worked for creating a new snapshot from the front-end, but I still had a problem with snapshots created from BO Processing (in my case, via Shipment Book-in, but that's a different story).

The attached plugin will grab a list of new snaphots during the BO Process, and then fix all their carrier data at the end. It uses the Carrier.ReadRecord method Stuart suggested to copy the carrier information from the previous snapshot. It would be trivial to make it pick the first snapshot instead.

This works well for my purpose, although I'm sure there is room for improvement.

Ideas I already had:
1) I did entertain setting the carrier information from with the BOProcess.ProcessSnapshotCreated event, but the code I have is already working, but I think at some point in my testing I upset the process with too many SalesOrder.Save()s, so have opted to leave it as-is.
2) Check to see if the carrier is already valid before setting it, just in case it's been set by some other plugin. But this is probably a good reason to *not* do 1).