Buyer field in New PO Suggestions

Just starting to experiment with PO Suggestions, and I notice the Buyer field in PO Suggestion Entry always comes up blank. Any way to have it default to the buyer who is launched New PO Suggestions?

We have a Buyer setup for each user, added that user as an authorized buyer, and set that user as the default. Any place else I need to look?

This can be set on the Part or PartClass. I think there may be other places but these two come to mind. @ckrusen

1 Like

That might work for inventoried items. But we’ll be using PO suggestions, mostly for Buy To Order items.

BTO parts automatically have their Part Class set to “BTO Part” during PO Entry. We do this to use that Part Class’s GL Control, to track them different from inventory or expensed items.

We probably messed up by creating a Buyer record for each user that does purchasing. Especially since every user in purchasing is set as an authorized user on every Buyer record.

You can setup a default buyer that all these suggestions will get assigned to.

1 Like

I saw that. But wouldn’t that make this “Buyer” the default on other things (like a new PO), regardless of which user is creating the new PO?

No. The user creating the PO will be the default buyer if their user id is setup as the default authorized user.

1 Like

There is a hierarchy for defining which buyer is used…
In this example to help explain, i have two “Buyer codes” and THREE Authorized users:
Buyer Codes

  • Buyer1 (System Default)
    ** authorized users: Ted, Jane(Default)
  • Buyer2
    ** authorized users: Ted (default), Jane & Alice(Default)

The above setup means that Ted and Jane can both act as either buyer… alice can only buy under Buyer 2. Both Ted and Alice have their default buyer as Buyer2.
Also note that Alice cannot see any suggestions or POs that are assigned to Buyer1.

  1. if you are creating a PO Manually, Jane’s buyer code is Buyer1, Ted & Alice are buyer 2
  2. if MRP/Purchasing Suggestions create the suggestion, it will assign the buyer based on the following rules:
  • PartPlant have a Buyer? Use it - ELSE
  • PartClass have a Buyer? Use it - ELSE
  • Default back to the SYSTEM DEFAULT (Buyer1 above)
  1. if it is a sub-contract operation, then it uses the System Default (Buyer1)

(I think i got all that correct)…


The setup we used was to have a default buyer for all items. When we convert suggestions into PO’s, the buyer is manually changed by the person executing the PO. All of our buyers (or anyone who has to see suggestions) are listed as authorized buyers under the default buyer.

Works pretty well, even though it’s not quite how some other systems work. Gives us a way to see all suggestions at once.



  • Only one Buyer can be the system default.

    • This buyer is selected for some automated things.
    • Other settings (PartPlant & PartClass) can override this
  • Each buyer can have multiple users assigned

    • Multiple users can have the same Buyer as their default
    • Users can only have one Buyer as their default

Dare I ask how PO Limits and Approver hierarchy works?

‘Buyer1’ - with users Adam(d), Barb, & Charlie, a PO limit of $1,000, and Appover ‘Buyer2’
‘Buyer2’ - with users Barb(d) & Charlie , a PO limit of $5,000, and Appover ‘PurchMng’
‘PurchMgr’ - with user Charlie(d) , a PO limit of $0(no limt), and no Appover

(d) - denotes default buyer fro this user

Charlie could create a PO

  • Which defaults to Buyer “PurchMgr”
    • There would be no limit on the PO value, and no approval is required
    • Adam and Barb could not access the PO
  • If Charlie changed the Buyer to “Buyer2”
    • There would be $5,000 limit on the PO value, and he would need approve it himself
    • Adam could not access the PO, but Barb could
  • If Charlie changed the Buyer to “Buyer1”
    • There would be $1,000 limit on the PO value, and he or Barb would need approve it
    • All three could access the PO

Barb could create a PO

  • Which defaults to Buyer “Buyer2”
    • There would be a $5,000 limit on the PO value, and Charlie would need to approve it
    • Adam could not access the PO, Barb and Charlie could
  • If Barb changed the Buyer to “Buyer1”
    • There would be $1,000 limit on the PO value, and she or Charlie would need to approve it
    • All three could access the PO

Adam could create a PO

  • Which defaults to Buyer “Buyer1” (Adam can choose no other buyer)
    • There would be $1,000 limit on the PO value, and she or Charlie would need to approve it
    • All three could access the PO
    • Barb or Charlie could change it to Buyer2, and then Adam could no longer access it
    • Charlie could change it to PurchMgr, and then neither Adam nor Barb could access it

Is this correct?


Unsure of the setup, but in the environment I described previously, the buyer limits do work properly.

Basically, for BTO parts that are NOT in the Part master the PO Suggestion Buyer will either be blank or it will be set to the Buyer marked as the default buyer.
If having one default buyer for all BTO parts wouldn’t work, then what logic does your company use to determine who should purchase each part?
I have setup BPM’s on the POSugg.Generate method (I think that’s the name), to perform calculations and change the buyer or other values, like populate alternate PO Line comments, etc. If you have something to work with you can define the logic in a BPM and get it to work for you.

One mini project I’ve been meaning to work on is adding an additional layer to the hierarchy mentioned earlier. Creating a Buyer called ‘Per Supplier’ then when the hierarchy evaluates to the ‘Per Supplier’ BuyerID or blank then it would set the buyer ID to the Buyer selected on the Supplier via a UD field.

Hello @Rick_Bird,
I am in need of a BMP that copies Requisition Comment to PO Header comment at time of PO generation. Do you have an example of POSugg.Generate code you have used? I don’t seem to have access to PO fields from that method or a way of knowing what PO was generated by what PO suggestion. Thanks for your help

I haven’t don’t this specific thing, but this might help you:

  1. I’m surprised the Requisition comments do not feed into the PO Suggestion.
  2. When the Suggestion is created it records the ReqNum & Line in the suggestion record.
    In a BPM if the ReqNum is not blank then I would use the Setter widget to set the SugPODtl.CommentText to the following Expression(untested):

Db.ReqDetail.FirstOrDefault(r => r.Company == ttSugPODtlRow.Company && r.ReqNum == ttSugPODtlRow.ReqNum && r.ReqLine == ttSugPODtlRow.ReqLine)?.CommentText ?? ""

I see you are in Michigan, perhaps we can meet at the next MI-IN EUG meeting?

Yes, I am in Michigan. When is the next EUG meeting and where?
I did find a solution. I realized Requisition Numbers where copied to the the PO Release. I then created a Data Directive that copied requisition comments using the Req Num link to the PO header whenever a PO was approved. This worked well.

Hi Tim ( and Calvin),
Thanks for framing this out so well!
I have one thing that I need clarified. The hierarchy is from top down in terms of suggestion routing, but is it the case that a Generate Suggestion(s) can be triggered lower in the hierarchy - using the filters in “Generate Suggestions” aka “Generate Purchasing Suggestions” - and does that request triggered by the user there always then begin at that top of the hierarchy and trickle down that if-then-else ladder?

I believe it always uses the same hierarchy to determine the buyer.