The way I solved this:

1. Created new accounting code text for the COGS account

2. Added the accounting code text to the product accounting code line

3. Updated all Product accounting codes with the proper COGS account for the new line

4. Copied the PIHI Auto Journal

5. Updated lines 20,22,23,25 by selecting the new accounting code line,(index), for the Purchase type <=1, then I removed the Formula,[F:CAL]ACC(0), from the Account Legal line in the formula areas.  

6. Created specific Invoice type for drop ships and associated the new auto journal to the invoice type. 

This is the cleanest and most effective way I could find especially since the customer wanted to have different COGS accounts per site. 

Looks like a good solution. Strange you had to create a modified custom AJ for this though when standard process does work in the SEED folder provided by Sage. 

Curious how the specific invoice type you've created would cope with sales orders that have multiple source lines. some drop ship, others shipped from your clients site? Is that a consideration you might need to look at?

Please explain how standard functionality meets this need?  The standard PIHI, and PIHI2, will use Line 1 of the accounting code when the purchase type is 'Purchase'; typically this is set to the RNI account, so to use standard functionality I would have update my product accounting codes which would affect all fiduciary entries, if I am wrong here, please let me know so I can learn. 

I did consider that, and verified that they do not have multiple product sources on their PO-direct to customer shipments. 

If you know of a better way, I am so very pleased to be wrong. 

"Please explain how standard functionality meets this need?" - I did, I tested in the SEED folder (which is entirely standard Sage configured) and it correctly debited the COGS account as I mentioned previously when flagged as Back to Back supply. It did not touch the GRNI account, at all! Which is what you wanted to happen.

When the same product and same customer was not flagged as back to back in the sales order, it worked as normal, the GRNI account was affected by the purchase flow and COGS was affected on shipment of the sales order. (2 entirely different flows)

I assume you have access to a SEED folder? I did give you the order number to use to test, the product code and everything else relevant. You can get the accounting codes from the customer/supplier/product from the SEED folder as quickly as I can and trace those through if you like to see how Sage by default configuration handles it.

I'm simply confirming to you that "out of the box" Sage does work correctly for your situation from the tests I did... which makes sense, because the situation you describe is a very very common situation, it sounded unlikely that AJ's would need to be modified/created because as I know we both know, that's normally only required for very "non standard" scenarios.

I'm sorry, but I did extensive testing in SEED prior to posting this question.   For GB Accounting Codes, account 70000 is used on line 1 of the product accounting code.  In GB COA, account 70000 is the COGS account.   You stated that Receive and Ship Sales Order did in fact show the RNI account on the Receipt, would you be able to show me that, because my tests proved otherwise.

Perhaps the Anglo-Saxon accounting parameter is the culprit?? I'm not sure.

But-

My tests are not producing the same result as yours.  All standard PIH auto journals are setup as:

Translation: 

If the purchase type is less than or equal to 1- use line one of the accounting code for the product. 

This is also where the GL account pulls from within the PO. 

So the red area here are the journals created when doing Sales Order > Back to back > Invoice the PO created (ofc no receipt is used here)

The green area is when I took that same PO that was generated via Back to back, copied it and did a purchase receipt on it. so same item, same supplier, same stock site.

I do find it curious that PIHI2 line 100 was used to generate the COGS account line. I don't have any more time to look into this though, so apologies if it contradicts your findings. All I can say is it works ok for me in SEED without any modifications using the data examples provided. You have a solution regardless in your own method so that's excellent. 

Line 100 has a condition for Vat != '"" and the invoice is an EU invoice.  I think the difference here is the fact that I am testing USA legislation and the transactions you are testing are GB.  Apples to Oranges. I wish the American transactions behaved this way.  Thank you again for all your time on this.   I still hope I am wrong and missing something. 

Line 100 has a condition for Vat != '"" and the invoice is an EU invoice.  I think the difference here is the fact that I am testing USA legislation and the transactions you are testing are GB.  Apples to Oranges. I wish the American transactions behaved this way.  Thank you again for all your time on this.   I still hope I am wrong and missing something. 

Yeah it does seem like that's the case. I'm in the UK so instinctively I test only with UK transactions but that does indeed seem to be why it behaves so differently. It actually makes a change that something in the UK by default works better than the US in X3 :)