Thanks Rob. I did not consider that the SugNum would eventually repeat so I should definitely use a different user-defined field to key off. I also did not consider that the PO might be created before the suggestion record is deleted. That is certainly worth looking into. I did a Trace Log and expected to see a method for the new PO creation but did not. Thought that was kind of strange since the PO was definitely created. In any case, you have definitely given me some ideas to follow up on.
Since my ultimate goal is for the Planners to know whether the PO was created, I think for now I can use a SQL trigger to indicate that when the suggestion was deleted with Buy=true then a PO was placed. It would be really nice to have the PO Number too, but this is will at least meet my minimum requirements while I test out some of the other ideas.
Thanks for your thoughtful response. I'm glad to at least have some leads now instead of staring st a dead end.
Aimee
Since my ultimate goal is for the Planners to know whether the PO was created, I think for now I can use a SQL trigger to indicate that when the suggestion was deleted with Buy=true then a PO was placed. It would be really nice to have the PO Number too, but this is will at least meet my minimum requirements while I test out some of the other ideas.
Thanks for your thoughtful response. I'm glad to at least have some leads now instead of staring st a dead end.
Aimee
--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...> wrote:
>
> Aimee: Yes, like all PO, order, job number generation systems, there is an
> incremental system process to come up with the next suggestions number (but,
> depending upon your daily suggestions count, that can eventually wrap around and
> begin to reuse SugNum's).
>
> The big issue is that MRP full regens (or generate new PO suggestions) wipes out
> the current suggestions and generates new ones. As a metric enabler (how quickly
> are buyers acting on new PO suggestions & how many do they process daily), we
> capture SugPODtl after each nightly MRP run & archive it in a SQL table. We can
> then look at New PO suggestion history for any given part using an HTML internal
> Part inquiry tool.
>
> You're still stuck with the issue of how to relate a specific suggestion to a PO
> converted from it (or vice-versa if you archive suggestions).
>
>
> I've never traced through the multiple apps that really are Buyers WB, New PO
> suggestions & PO Entry to see if there is some key point where you could trap a
> list of the suggestions to be converted (writing them out to a UD table perhaps)
> & then somehow (later) relate them to a trapped list of the POs created using
> the suggestion data (also writing the related new PO data to the UD table - or
> pulling the suggestion info from the ud table into user defined fields within
> the PO tables).
>
> ...Whether you really need that ud table depends upon when the suggestion record
> is deleted. If it exists after the PO is created (but perhaps SUgPoDtl.buy is
> flipped from yes to no), you can leverage user defined fields in sugpodtl & just
> read them from a view from within PO entry. If they don't saty in existance that
> long, you'll likely need to use a ud table as a tempt table between the apps.
> (Trace it to find out.) ÂÂ
>
> It's a shame it isn't like Jobs (where MRP creates real, but unfirmed, jobs &
> you could leverage a change log on jobhead.jobnum to realte the suggestion to
> the final actual scheduled receipt).
>
> PO Suggestions are just that: Basic data that is less converted into a PO than
> it is used to copy key info into a new PO (somewhat automating entry).
>
> RobÂÂ
>
>
>
>
> ________________________________
> From: aimee.grebe <aimee.grebe@...>
> To: vantage@yahoogroups.com
> Sent: Fri, September 17, 2010 3:27:56 PM
> Subject: [Vantage] Re: Identify PO that was generated from a PO Suggestion
>
> ÂÂ
> I am surprised to hear the suggestion numbers are reused. Since there is a table
> (_SEQT_sugpodtlseg) to store the current value and increment value I assumed
> this number was processed in the same way as a laborhedseq, checkhedseq, etc.
> with no repeating values.
>
> If indeed the SugNum is reused, you are right there is probably not much point
> in continuing on with my idea, but here is what I am ultimately trying to
> accomplish:
>
> In the interest of not being long-winded, let's suffice it to say that for
> several reasons our Planners sometimes need Purchasing to order parts in advance
> of any demand being entered into the system. This is a business rule that cannot
> be overcome. We cannot use Purchase Requisitions because the parts are going
> into Inventory. So to deal with this I have a routine that will take input from
> the Planners, process it through the appropriate logic and generate a PO
> Suggestion for Purchasing to order from. That all works great, but in addition I
> would like once the PO has been generated for the PO Number to flow back to the
> Planners so that they have confirmation their parts have indeed been ordered. If
> I can link the PO to the originating Suggestion, then I can also link it back to
> the Planner input. It is the connection between the Suggestion and PO that I am
> lacking.
>
> As a secondary benefit, we would also like to collect metrics on how long it
> takes Purchasing to process Suggestions into actual POs.
>
>
> I am open to any ideas on another way to handle this. Hopefully there is
> something very easy sitting right in front of my face. :-)
>
> Thank you!
> Aimee
>
> --- In vantage@yahoogroups.com, Robert Brown <robertb_versa@> wrote:
> >
> > Aimee
> >
> > SugPODtl records only 'live' between MRP (or Generate New PO Suggestions) runs
>
> > (so the suggestion numbers are reused). SOMEHOW recording the sugestion
> > numbers in POs converted from suggestions would be of little value (as looking
> >
> > at those suggestion records today would show different info than likely
> >existed
> >
> > when the PO was created - almost assuredly for entirely different part numbers
>
> > in fact).
> >
> > What business need are you actually trying to cover? (There may be another way
>
> > to do it.)
> >
> > Rob
> >
> >
> >
> > ________________________________
> > From: aimee.grebe <aimee.grebe@>
> > To: vantage@yahoogroups.com
> > Sent: Fri, September 17, 2010 2:28:52 PM
> > Subject: [Vantage] Identify PO that was generated from a PO Suggestion
> >
> > ÂÂÂ
> > Does anyone know of a way to flag a PO that has been converted from a PO
> > Suggestion? I'm trying to find a way to link the PO back to the PO Suggestion
> > that prompted Purchasing to buy the parts. I found the POSugg.Generate method
> > but it does not reference any of the tt PO tables, only ttSugPODtl.
> >
> > Thanks in advance,
> > Aimee
> >
> >
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>