I was researching a similar issue and thought I would post a follow up.
We had an issue where one Ship-To was getting stuck at 571 and not getting an ASN. When checking the PNID and HLCF in the Shipment Header (F4215) we found that the PNID wasn't populated as expected and the HLCF was blank. The HLCF being blank is what prevented the ASN generation.
I found an Oracle Community posting which summarized how those fields in the F4215 are populated when an order/shipment is created:
At the time of Sales Order Entry - Shipment Creation, the application checks if there is a hierarchical configuration set up for the Ship To address.
If it is found, it will be written to F4215.
F4215.PNID = ShipTo AddressNumber
F4215.HLCF=Hierarchical configuration set up for the ShipTo
If the hierarchical configuration is not found for the ShipTo, then the application checks if there is a hierarchical configuration set up for the Sold To address.
If it is found, it will be written to F4215.
F4215.PNID = SoldTo AddressNumber
F4215.HLCF=Hierarchical configuration set up for the SoldTo
We set up the Hierarchical Configuration on the Sold-To addresses and set the Ship-To's default configuration to None. On the Ship-To's that were getting ASNs, the F4215 was getting the parent address number in the PNID and populating the HLCF from the Parent Address set up in the customer master as expected.
Here is the really odd thing about my specific example. When we looked at the Customer Master screen for a working Ship-To and our broken Ship-To, the screen showed that both had Default Configuration set to None. I finally went and looked at the F03012 data directly in the database and our broken Ship-To had a CFDF value of blank, where all of the working Ship-To's had a value of 0. We had someone go into the customer master and resave the record, the data was fixed and everything worked.
I hope this helps point some future jdelister in the right direction.
