Is there a way to get a PO-direct to customer to hit the COGS account instead of the RNI?


I must be missing something, or forgetting something, because I am baffled that a Direct to Customer PO invoice would DR the RNI account when there is no receipt.  In fact, the programming won't allow you to create a receipt. 

The account is defaulted by the purchase type, which then looks to the accounting code.  If I change the line of the accounting code to the COGS, then it is true for every situation, which will throw off the RNI in a normal receive and ship transaction.  

I have tried an Action workflow, but I was unable to get it to change the account.  [This is my preferred method.] 

Does it really involve customizing an Auto Journal at invoicing to CR the RNI and DR COGS? 

I really hope that I am missing something obvious, and that someone could point me in the right direction.

Thank you

  • 0


    I Just did this in SEED. Created a customer order for site GB012, sold to GB011. Product code: BMS002 and selected back to back order. (Infact I copied order SONGB0120030 on SEED), so just use that order number (patch 32) copy/amend to back to back and save.

    I then clicked Back-to-back order to generate the PO which created for me under supplier DE053

    Then I invoiced that PO. 

    It credited PL control account and debited 700000: Cost of Sales. Also debit and credited VAT accounts. 

    So seems to work as expected in the SEED folder? the auto journal that was triggered was PIHI2.

    Might be worth you tracing that through to see the setup of those things and why that worked where yours did not.

    I'm going to make a guess that there's some auto journal with criteria based on LINPURTYP that only triggers for these back to backs but I don't have free reference auto journal lines turned on in my demo folder to check which line was called specifically and don't want to go down that mine field at the moment Slight smile

    Hope that helps a little.

  • 0 in reply to STX_AKM

    Thank you for taking the time to work through this.  May I ask what accounting code product BMS002 is using and what is the GL account associated with Line 1? 

    I will try the pihi2 AJ

  • +1
    verified answer

    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. 

  • 0 in reply to Kendall Cyr

    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?

  • 0 in reply to STX_AKM

    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. 

  • 0 in reply to Kendall Cyr

    "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.

  • 0 in reply to STX_AKM

    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.


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


    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. 

  • 0 in reply to Kendall Cyr

    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. 

  • 0 in reply to STX_AKM

    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. 

  • 0 in reply to Kendall Cyr

    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 :)