Initially Mercury Support Case#00078434 (Possible bug in Miscellaneous Configuration - Newgistics) was raised assuming there is a bug in the configuration.
The support confirmed that it was because our custom loader (NGLoaderId) was not updated to use the newer feature.
Suggestion was made to switch to standard loader. Loader in QA was switched to Standard loader (CTransportationLoaderid) to test.
Kayvan Shadpour
Jadon Urban
16/11/2022 3:31 p.m.
The loader/parser have now been updated in Prod.
Jadon wrote:
Kayvan,
That is correct. The username will stay the same.
However, Newgistics currently has the EDI 214 set up at two enterprises (Assumingly, both would be updated).
At the Newgistics enterprise, the username is NGLoaderId
At the PB Commerce Services Transportation enterprise, the username is CTransportationLoaderid
(Which is what you were seeing in QA. Both enterprise levels were updated in QA)
I have pasted the current Prod 214 tables below:
Newgistics|IM:EDI214|00|FindCompanyByEDIReceiverId must be true - Do Not Change
Newgistics|IM:EDI214|BaseImportDirectory|\\awsfsprod\CustomerData
ewgistics
Newgistics|IM:EDI214|BaseImportDirectory-TestMode|\\awsfsqa\CustomerData
ewgistics\QA
Newgistics|IM:EDI214|CopyB1001AsShipmentIdIfEmptyOrRegEx|(?)NS
Newgistics|IM:EDI214|FileNameRegEx|214.*
Newgistics|IM:EDI214|Loader|com.mg.importers.Newgistics.TransportStatusLoaderNewgistics
Newgistics|IM:EDI214|Parallelism|10
Newgistics|IM:EDI214|Parser|com.mg.importers.Newgistics.EDI214ParserNewgistics
Newgistics|IM:EDI214|RelativeCompleteDir|Status
Newgistics|IM:EDI214|RelativeLogFile|Log-Import-EDI214-Newgistics.csv
Newgistics|IM:EDI214|Response|com.mg.importers.EDI_214In_997Out_Response
Newgistics|IM:EDI214|TransportMatcherCodeTable|TransportMatcherImport214
Newgistics|IM:EDI214|UseDefaultCompany|true
Newgistics|IM:EDI214|UserId|NGLoaderId
PB Commerce Services Transportation|IM:EDI214|00|FindCompanyByEDIReceiverId must be true - Do Not Change
PB Commerce Services Transportation|IM:EDI214|BaseImportDirectory|\\awsfsprod\CustomerData
ewgistics
PB Commerce Services Transportation|IM:EDI214|BaseImportDirectory-TestMode|\\awsfsqa\CustomerData
ewgistics\QA
PB Commerce Services Transportation|IM:EDI214|CopyB1001AsShipmentIdIfEmptyOrRegEx|(?)NS
PB Commerce Services Transportation|IM:EDI214|FileNameRegEx|(?i)EZV214.*
PB Commerce Services Transportation|IM:EDI214|Loader|com.mg.importers.Newgistics.TransportStatusLoaderNewgistics
PB Commerce Services Transportation|IM:EDI214|Parser|com.mg.importers.Newgistics.EDI214ParserNewgistics
PB Commerce Services Transportation|IM:EDI214|RelativeCompleteDir|Status
PB Commerce Services Transportation|IM:EDI214|RelativeLogFile|Log-Import-EDI214-ezVTransportation.csv
PB Commerce Services Transportation|IM:EDI214|Response|com.mg.importers.EDI_214In_997Out_Response
PB Commerce Services Transportation|IM:EDI214|TransportMatcherCodeTable|TransportMatcherImport214
PB Commerce Services Transportation|IM:EDI214|UserId|CTransportationLoaderid
Prior to requesting QA loader switching to standard, I did a preliminary analysis on the documents provided by MG.
After going through flowcharts and notes provided by MG, I believe the custom loader is having two customized functions:
If the 214 D1 update has Qty and Weight also, it looks up the very first line item (sort) on the load. If Qty and Wt is less than or equals the value received, then it will update only that first item, and then zero out all other sorts (this means it trumps any inputs we get from FastTrak !). Of course there are logic slabs to this, which I have simplified in my review.
Then it adds two references to the load "QtyDelivery" & "WtDelivery" and stores the values received in them respectively.
There are similar logics also for pickup location Qty and Weight.
YTD I see 15 loads with a value in Ref: QtyDelivery (SCACs are: ITSO, SYSH, NOTR)
and 36 loads with a value in Ref: WtDelivery (SCACs are: UNKN, SYSH, LUAC)
So I believe this is a no-brainer to switch to standard loader, as we do not have a real practice of carrier updating qty and weight via 214. Also the additional reference fields are not used and published to Snowflake, due to absence of data.
Confirmed that the Enter invoice activity completed was result of a DRS already in place:
EDI 214 message with 4 updates (AF, X3, X1, D1) was uploaded successfully through UI for load LD131813 in QA.
The load was updated with all 4 tracking updates.
No data validation was done by loader.
New loader ID observed under "Created By"
Load Status updated as expected
Audit history logged the events properly
Most Activities are updated correctly, except "Enter Invoice" which has been marked completed. Not sure if its a result of a DRS (to be investigated)
In QA I used an existing load (LD131813) then manually created an EDI 214 file using https://edination.com/
The EDI file attached purposely has time/dates which do not align, as I also wanted to test if the new loader is more intelligent or validates data.