Valuation Miscellaneous Receipt with Last Recepipt cost

SUGGESTED

Hello,

We have a problem with Miscellaneous Recepipts. We want to valuate them with "Last Recepipt cost".

The valuation rule details are:

- Receipt source: Order cost

- Receipt alternate: Last cost  (i dont know whye the possible values are differents than the previous picklist).

- Exception: Miscellaneous Receipt; Valuation source = Last cost.

Example: in product-site "Last receipt cost" = 22. I create a miscellaneous receipt, qty=1, value=23. Therefore the product-site "last receipt cost" change to 23. I would like to maintain 22.

Top Replies

  • 0

    Hi  

    I think you should use the Last purchase cost to obtain the result you are looking for:

    Please be sure to run the proper test in a test environement prior to changing your Live environment.

  • 0 in reply to Julien Patureau

    Actually I run some test in 2023R1 and I failed to replicate the scenario you mentioned above:
    See before misc. receipt:

    Both Last receipt cost and Last purchase price remain identical after the misc. receipt created at a different order price:

    Can you share the detail of the valuation method setup (screenshots)?

  • 0 in reply to Julien Patureau

    Thanks  ,

    We need use "last receipt cost" and not "Lats purchase cost" because we have additional invoices that increase the "last receipt cost" that must be the true cost (purchase cost is less than "last receipt cost" ).

    Here some screenshots with our problem (sorry by the language, i translate):

    Valuation method:

     Example with Product 000145:

    Last Journal receipt:

    Related transaction:

    Thanks!

  • 0 in reply to Jonathan.gonzalez

    Hi  

    I have reproduce the described behavior (2023R1).

    By design Last cost is updated with the latest stock receipt (misc. receipt included).

    I create a miscellaneous receipt, qty=1, value=23. Therefore the product-site "last receipt cost" change to 23. I would like to maintain 22.

    If this is really the expected behavior, then I can suggest a simple development to ensure to have the order cost entered at Last price, but of course this would affect the secondary valuation method as well.

    But before you move forward on this direction, I'd like to draw your attention on your unusual configuration:  using order cost for receipt but Last cost for issue is inconsistent in my opinion.

    Imagine, the following scenario:
    • Supplier Receipt 1: 1 unit at 2€
    • Supplier Receipt 2: 1 unit at 3€

    At this stage stock value is 5€ in your GL and last cost is 3€
    So if you empty your stock, you will get :
    • Customer delivery: 2 units at 3€ (so total value 6€)

    And now in your GL you have a negative value (5-6=-1) for your stock value. I suspect, the valuation method maybe not set to do what your are looking for.

    In the above scenario, after creating the receipts 1 & 2, what is the expected value for the 1st unit you will issue? Then what is the expected value for the 2nd unit you will issue?

  • 0 in reply to Julien Patureau

    Hi  ,

    I understand the design behaviour, but in stock journal the "Value price" (0.4476) is the last cost befote the misc. receipt. I don't understand why Sage x3 use the "order value" (0.5050) to update last cost and not "Value price", as "Receipt valuation exceptions" said. The development is our B-plan (maybe easy, because these misc. receipts come from a existing development).

    About the configuration: Issue with last cost (is ok); Receipt with order cost (sage x3 doesn't allow use "last cost" in "Receipt Source" but yes in "Receipt Alternate" in Valuation method).

       

    We work always with last cost. The problem comes when the misc receipts update the last cost with an erroneous value (because the correct is purchase cost + aditional costs).

    All issues must be valued to the last cost receipt.

    In your example, after Receipt 2, all issues must be 3€. 

    If GL = General Ledger, in Spain is not mandatory register the stock movements in GL. 

    Thanks  

  • 0 in reply to Jonathan.gonzalez

    Hi  

    So I think you have not choice but to go for plan B: development.

    I don't understand why Sage x3 use the "order value" (0.5050) to update last cost and not "Value price", as "Receipt valuation exceptions" said.

    Last price, Average cost, Lot Average cost and FIFO are always calculated in Sage X3 disregarding the valuation method setup (based on VARORD and not VARVAL). Indeed, if you are using standard cost, following your proposition, the system should fed the above costs with the value matching the standard cost.

    The benefit of the current behavior is to be able to compare your stock value with other methods (using the valuation report) and to be able to change of valuation method at some point.

    If GL = General Ledger, in Spain is not mandatory register the stock movements in GL. 

    Yes GL stands for General Ledger. 

  • By design Last cost is updated with the latest stock receipt (misc. receipt included).

    Hi  , therefore you previous example, is opposite to the afirmation? (maybe is my english)

    "See before misc. receipt:

    Both Last receipt cost and Last purchase price remain identical after the misc. receipt created at a different order price:

      "

    About the standard cost, i can not understand "Indeed, if you are using standard cost, following your proposition, the system should fed the above costs with the value matching the standard cost."

    ast price, Average cost, Lot Average cost and FIFO are always calculated in Sage X3 disregarding the valuation method setup (based on VARORD and not VARVAL). Indeed, if you are using standard cost, following your proposition, the system should fed the above costs with the value matching the standard cost.
  • 0 in reply to Jonathan.gonzalez
    SUGGESTED

    Hi  
    Indeed my initial test was showing no change after the misc. receipt, there is an inconsistency and I have reported the question to the support. But the on-line is very clear: misc. receipt should update the last receipt cost (based on the order price).
    So this will not help you here.

    "Indeed, if you are using standard cost, following your proposition, the system should fed the above costs with the value matching the standard cost."

    You are expecting the last cost to remain identical after a misc. receipt because the valuation method is set with last cost. This is not the product logic, we are not using the valuation amount (VARVAL) but the order price (VARORD) to update the last cost (and other costs such as AVC). 
    I tried to explain why using the valuation amount (VARVAL) is not a good idea to update the last cost by setting an example with standard cost. If you use standard cost to value your misc. receipt (VARVAL = standard cost), then the last cost would be, accordingly to your suggested logic, equal to the standard cost.  This will forbid any possible stock valuation simulation / comparison between last cost and standard cost. Moreover, if you decide to transition to a valuation method using standard cost to last cost, the initial value would be incorrect.

    I hope I am clearer in this new post.

  • 0 in reply to Julien Patureau

    Thanks Julien for the new post.

    We will try the development in misc receips and adjust the order price.

  • Hi again  ,

    I have other question, because with the same valuation method, when a Misc. Receipt with 0 in Order price, Sage X3 create a stock movement valued at article last cost. ¿why and why not when the misc. Receipt has value?

  • 0 in reply to Jonathan.gonzalez

    Hi  

    This is an interesting question: when having no order price upon receipt should the system put zero in the order price (impacting the last cost calculation) or use the valuation price as a default vale for the order price (hence for the last cost) which is the current behavior?

    I just found that this was discussed internally in September and the final answer I can see is the current behavior is confirmed working as designed. -> It seems this would deserve your need!

    Note: I wasn't able to reproduce in 2023R2 the anomaly identified earlier (from my 2nd post where the misc. receipt didn't update the last cost), so no anomaly was log at the end.

  • 0 in reply to Julien Patureau

    Thanks  , i finally learn that it isdifficult to know the behaviour of the system with que documentation before doing some tests.