Our company recently moved locations and we made sure to update our address in Moqui to the new one, however, when trying to create labels for incoming shipments, the old address is still being used. I have updated and validated the new address on the warehouse facility, organization and anywhere in Moqui I can find the old address. I have also updated it in Shippo to no avail.
Is there somewhere specific in Moqui that label addresses are kept?
The old address is showing up on new orders even though the address has been updated on the facility, organization, etc.
To look into something like this we’d need to know more about which part of which screen or template/document the address is showing up on in order to be able to look at the exact code to explain the behavior, and possibly some of the data involved as well in order to figure out the data pattern if it isn’t apparent from a general description plus code read. The particular code might not be using the Mantle USL services for getting contact info or doing something that it shouldn’t with the From and Thru dates on the PartyContactMech records.
Here’s an example with a new outgoing order. The order part shows the incorrect address even though it looks to be pulling that address from the warehouse facility. When I go to the facility referenced on the order, the correct address is displayed. I would assume the order part would pull the address from the facility.
I have included screenshots of the order part and facility.
It looks like the Address there isn’t for an Organization (Ridge Crest Herbals), but a Facility (RidgeCrest Warehouse).
Changing the address of the Facility might change the address as you specified earlier.
Michael, if you look at the screenshots I attached you can see that the address is updated for the facility. I have updated the address everywhere in Moqui that I can find.
From looking at the code, ie what the OrderDetail and EditFacility screens do with the facility postal address, the problem may be that the facility has both Primary and Shipping Destination addresses in the database. The EditFacility screen currently only looks at and allows editing of the Primary address for the facility, but the database model and various services support other address purposes so if one was added you would see this behavior. To view all addresses associated with the facility the easiest way is probably the auto screens, just look up the Facility and then you can navigate from there to the ContactMechs for the Facility.
Hi David, as you know I’m the Dev working with Ridgecrest.
I think the issue has come from the mantle.facility.ContactServices.get#FacilityDefaultShipDest service.
From what I saw, the facility did not have a PostalShippingDest contactMech associated (instead it has a PostalPrimary), that was working since the service looks for that purpose Id if no records were found with the former.
Here you can see that in the “main” PostalPrimary record, the thru date was implemented when Tara made the address change, and by that logic the date filter should recognize that’s not the correct address and use the new one associated to the facility. However, there are more than 50k records of PostalPrimary contact mechs associated with the warehouse (from those, all I checked were associated to the old postal address) which did not get a thru date on the address change, most likely causing the service to return one of those ContactMechs.
From that adding a PostalShippingDest ContactMech for our warehouse should solve the issue for us. But I still wanted to ask if you were aware of how those FacilityContactMechs might have been created and if they serve any particular purpose.
That could be your problem, there is a bunch of address data associated with the Facility and some have the same From Date (and are PostalPrimary)… these timestamps are truncated but if the fromDate is the same then the sort by From Date will be unreliable, sometimes the DB will return them in one order and sometimes in another… a possibility anyway.
Whatever the case, if you are interested in solving this quickly, the first thing I’d do is get rid of the unused data there, preferably down to where you have only one FacilityContactMech record for that Facility and Purpose. Some of those were changed recently… perhaps as part of an attempt to fix something, or perhaps they are what caused it, either way, cleaner (and less) data is easier to verify and correct.
