ShippingAddressID on OrderDetail object

[Former Member]

hey All,

If I set the ShippingAddressID in the order detail object will this information synch over to Business One?

I am trying to create a customization that will allow a user to assign a different shipping address to each line detail and have that synch over to B1. I don't want to have to create a custom synch plugin if I don't have to.

I am writing a control that can update this field for each line level item and then I was hoping I could take advantage of the synch to move the address information into the sales order line items if possible.

[Former Member · Accepted solution]

Hi Curtis,

No luck. We don't set ship to code on the SBO order or RDR1.

All we set is the shipping address text on the order (ORDR.Address2).

[Former Member · Accepted solution]

So what is the shipping address ID used for in the order detail object? What happens if I manually change this field to some other address?

where does the information in the shipping address text come from?

[Former Member · Accepted solution]

ShippingAddressID was originally intended to do what you are thinking, but no functionality has yet been built in to allow the customer to set each line individually.

When the web customer selects a shipper, this value is set on all of the orderdetail. It is also reset when checkout.aspx is hit.

The synch does a select top 1 shippingaddressid from orderdetail to get the shipping address text to put on the B1 order. If you want to use the field you should be safe, so long as you set your values after checkout.

[Former Member · Accepted solution]

Let me pose a question here that could explain some problems we have seen with the SynchEngine synching over shipping addresses incorrectly on sales orders:

What happens when a customer places an order through the e-commerce engine using a shipping address they have stored on the system. Then, they immediately place another order that is shipped to a different address (than the first order) before the synchronization kicks in. The customer did not create a new address id. They used the existing one from the first order, and changed the address information for the second order. Would the first order reflect the shipping address of the second order since no new address was created?

I am seeing some symptoms of this in my system, but can only theorize as to the cause of it.

Any help would greatly be appreciated.

Message was edited by:

Joel Barber

[Former Member · Accepted solution]

That sounds right. I would say your theory is probably accurate.

I can log that as a bug.

If this looks like a big enough problem that you want to address it prior to a patch, you could do so by creating a synch plugin.

The OrderMaster.ShippingAddress field will be an accurate shipping address. I believe the problem could be resolved by synching OrderMaster.ShippingAddress to ORDR.Address2.

[Former Member · Accepted solution]

Thanks for the quick insight.

I would probably go ahead and log this as a bug. Many of our customers drop ship products around the country, so it is not unusual for them to wait until the end of the day to enter in a bunch of single orders.

I'll write a quick fix in the plugin. However, I have a question...:-)

Is there a way in one synchronization process to get the orders that synch'ed? In other words, I only want to do this for the orders that just synched across in the current process, but have no way of identifying them.

Any thoughts would be greatly appreciated.

[Former Member · Accepted solution]

An order is tagged for the synchronization when OrderMaster.CartType = 'O' and OrderMaster.SynchDate is null.

Unfortunately, once the data has been synchronized, the synchdate is updated, so you have no way of knowing by the time the synch plugin runs.

In Webtools 2007, we have added a TransactionQueue to the Webtools database. It works, more or less, like the PRX_Transaction_Queue in B1. The 2007 plugins will have access to the same queue the Webtools uses.

You could implement your own queue if you wanted. Put an update trigger on the ordermaster table and check for CartType = 'O' and SynchDate is null. Then populate your queue table with the orderid and use this to table to determine what need to be updated in the synch plugin. Make sure you delete the data from your queue when you finish.

I'm sure there are other ways to do this. I can not think of any that look particularly attractive.