Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#37 (195) Create From on Receipt

closed
nobody
None
5
2006-11-07
2006-10-03
Vincent Harcq
No

The qty of order lines shown should be reduced by the
number of unconfiremed receipt not yet completed.
Sometimes the receipt is created and confirmed weeks
later... yves you should know what I am talking about ;-)

Discussion

  • Vincent Harcq
    Vincent Harcq
    2006-10-03

    patch

     
    Attachments
  • Yves Sandfort
    Yves Sandfort
    2006-10-03

    • assigned_to: nobody --> comdivisionys
     
  • Yves Sandfort
    Yves Sandfort
    2006-10-08

    • assigned_to: comdivisionys --> jjanke
     
  • Yves Sandfort
    Yves Sandfort
    2006-10-08

    Logged In: YES
    user_id=467647

    This is customer specific solution. I will move over to
    Jorg, but I think behaviour is as wanted.

    What you are trying to achieve with this behaviour is that
    you have a better info from the history in the info windows
    on the status of an ongoing shipments from your vendor. From
    an ERP perspective it is not normal to create a receipt when
    the goods are send out by the vendor and simply not confirm
    it. Maybe also a mark in the PO would be an idea, or some
    other extend in the PO.

    Best would be that Jorg will look into it.

     
  • Jorg Janke
    Jorg Janke
    2006-10-30

    Logged In: YES
    user_id=87038

    I think users would find it "surprising" to have just the change.
    I suggest to list unconfirmed qty explicitly in the grid as a column.

     
  • Jorg Janke
    Jorg Janke
    2006-10-30

    • assigned_to: jjanke --> nobody
     
  • Vincent Harcq
    Vincent Harcq
    2006-10-30

    Logged In: YES
    user_id=125677

    That would be a enhancement

    I create an order of 10
    Receipt 10
    Go back and I can still receive 10
    Go back and I can still receive 10
    etc...
    Finally users have tons of "over receipt" orders

    I find this surprising, not what I propose

     
  • Yves Sandfort
    Yves Sandfort
    2006-10-30

    Logged In: YES
    user_id=467647

    Maybe that is a problem based on that you have not yet confirmed the receipt.

     
  • Vincent Harcq
    Vincent Harcq
    2006-11-01

    Logged In: YES
    user_id=125677

    Of course I have not yet confirmed the Receipt.
    This the whole problem.
    I use receipt with Confirmation. And I leave this
    confirmation open for weeks.
    Because I have already receive the product I don't want the
    system to show me that I still have something to receive

     
  • Yves Sandfort
    Yves Sandfort
    2006-11-06

    • status: open --> closed
     
  • Yves Sandfort
    Yves Sandfort
    2006-11-06

    Logged In: YES
    user_id=467647

    Sorry this is a wanted behaviour, discussed this and nearly
    everyone told us procedure is as wanted and a change would
    screw their system.

    So suggestion:

    Describe how your forecast stuff etc. should work in detail,
    deliver a database and function diagram plus a short process
    description. Then we will evaluate this, may provide the
    data infrastructure and we can implemented a real solution,
    not only a workaround which would be your current solution.

     
  • Vincent Harcq
    Vincent Harcq
    2006-11-06

    Logged In: YES
    user_id=125677

    At the company we work together they create PO with several
    lines and they got delivered multiple times because the
    manufacturing site do never provide full order.
    The products are on boat for weeks but the delivery
    (receipt) arrives before the goods.
    We need to be able to follow multiple unconfirmed receipts
    per po line during the time frame the receipt will
    effectively be received.

     
  • Vincent Harcq
    Vincent Harcq
    2006-11-06

    • status: closed --> open
     
  • Yves Sandfort
    Yves Sandfort
    2006-11-06

    • status: open --> closed
     
  • Yves Sandfort
    Yves Sandfort
    2006-11-06

    Logged In: YES
    user_id=467647

    This is neither a process description, nor a database description of the functions you
    would need to handle real product forecast.

    Again what you are doing here is misusing stuff for features not yet available. This is
    not a reusable solution. If you want to build up a good solution you should provide a
    documentation on how you would extend compiere for this functionality. We would then
    check this documentation and decide whether it makes sense in the core or whether it is
    better kept as an external add on.

    We will for sure not screw the product, we would like to extend if there is a general
    demand and a good description of what is needed, why and how it will be solved.

     
  • Vincent Harcq
    Vincent Harcq
    2006-11-07

    • status: closed --> open
     
  • Vincent Harcq
    Vincent Harcq
    2006-11-07

    Logged In: YES
    user_id=125677

    I contribute something that works for all our implementations.
    You don't take it, OK, I note that.
    If some contributions I have submitted have to be work again
    at our side to remove french comments, or some are not
    complete enough, I am humble, I will work to provide new
    contributions to match your requirements.
    When all our contributions will be submitted I will have to
    explain to my customers that Compiere is not ready for their
    daily work for all contributions not accepted.

    The contribution process is a good way to make Compiere
    better for everybody in a quick way.
    It is not a procedure when I am asking for help.

    If you need process, db, function, ... description for such
    a simple case I am a bit frightened to continue the process
    with more complex contributions.
    I hope you will play the game for non trivial contributions
    and accept some of them.

     
  • Yves Sandfort
    Yves Sandfort
    2006-11-07

    • status: open --> closed
     
  • Yves Sandfort
    Yves Sandfort
    2006-11-07

    Logged In: YES
    user_id=467647

    Sorry I think you didn't get it... It makes sense to provide a forecast delivery function
    etc. It doesn't make sense to use a function which was build for a different purpose as a
    workaround for a not yet existing function.

    I also not from your customers, that they would like to have a real forecast and material
    planning function and not this workaround.

    Contribution is not to modify existing behaviours based on the demand of one partner, if
    it is documented in another way, because thius would screw other customers scenarios.

    If you wanna provide a model for a new function which might be integrated we would
    integrate the tabkles in the core and then you could build the functions around it and
    contribute it. We would be happy to accept it.

    But you complained at the beginning, that Jorg in the past changed functions behaviour,
    now you are trying to do the same based on your experience.

    We really would like to find a good solution for everybody, not just a quick workaround.