Skip to main content



No record found.

Microsoft Dynamics SL forum

SL Customization - Change Default based on PO Type

Posted on by 180

We need the ability to default Drop Ship PO's to seperate AP Accrual accounts based on the PO Type in order to satisfy a process and reporting requirement for an investor. Since the PO Setup only allows for one set of defaults, I have been attempting to modify the PO Maintenance screen to programatically change the defaults based on the POType/PO Line Type.

Since we don't allow various PO types to be combined on a single PO, looking for POType of "DP" in an event and changing the defaults should be simple right? Not really.

I have been successful in using the field and line "chk" events to handle this when manually entering a Drop Ship PO. The problem comes when I try to set the accounts on an auto-generated Drop Ship PO created from a DS order in the OM module. I've tried several different logics but everything seems to fire to early or not fire at all when the system populates the PO in the PO Maintenance screen.

Has anyone been able to address an issue like this? I've spent several hours testing the different events and none of the events seem to fire on the screen after the detail level is loaded by the system. Here is what I tried so far.

1) Override the "Default" Event and modify. - This works is you stop processing by returning something other than zero in retval. Otherwise, it replaces my default with the system default in POSetup.

2) Override OnLoad/OnDisplay - I've tried modifying the defaults in bPOSetup.APAccrAcct and directly modifying the Detail Level data in here. Neither works and the lines are set to the POSetup default.

3) Override LineChk/Chk - These don't seem to fire when the system loads the data. Only when a user modifies the field/gridcolumn.

4) Override OnUpdate/OnFinish - This would ignore the value in the grid and reset it before it was inserted into the database, very much a "hack" and not something I wanted to try. Unfortunately this did not even work as the postprocessing subscreen appears to be called before the override is invoked.

Have I missed something? It's always possible in my haste that I tested one of these event improperly but I think I was pretty thorough. Does anyone have another suggestion?



Jason Irvan

  • Jason Irvan Profile Picture
    Jason Irvan 180 on at
    Re: SL Customization - Change Default based on PO Type

    Using the OnUpdate events works. Unfortunately, I ran into another problem during the Sales Journal process that doesn't look like it can be addressed. Drop Ship PO's post to the AP Clearing account by default (since they do not affect Inventory). Changing the account on the DS PO Line does change which account that is debited, however, the Sales Journal process generates the cooresponding credit in the default AP Clearing account instead of the account I specified during PO generation so our accounting gets 9 kinds of messed up if I do this....

    Thank you for your feedback though. I'm sure it will be useful with other items we are working on.

  • Jason Irvan Profile Picture
    Jason Irvan 180 on at
    Re: SL Customization - Change Default based on PO Type

    It's actually a DIalog Box asking if you want to Print then it starts ROI if you say yes. I think I may have been mistaken last night when I tested that approach. I'm going to work with OnUpdate a little more thoroughly this weekend as you suggested.

    Thanks for the note on the Grid. I've ran into that before. Not looking forward to that again as I had the problems you mentioned last time I did this in a screen.

  • Barry Flynn Profile Picture
    Barry Flynn 3,090 on at
    Re: SL Customization - Change Default based on PO Type

    I'm not sure what you mean by "the post processing" screen.

    Can you give me a screen number?


  • Barry Flynn Profile Picture
    Barry Flynn 3,090 on at
    Re: SL Customization - Change Default based on PO Type


    I should have added a further comment.

    I'm not sure whether you are wanting to modify data at the Document or Grid level.

    Be aware that if iy is at the Grid level, then at the time the Update/OnUpdate event fires, you will (pesunably) need to navigate the grid, so that you can modify each grid line one by one.

    That can sometimes get a little tricky.

    Code that works in one screen may make another "unstable" - .It seems to vary screen-by-screen.

    You sometimes need to "fiddle around a bit" to get it to work.


  • Jason Irvan Profile Picture
    Jason Irvan 180 on at
    Re: SL Customization - Change Default based on PO Type

    Thanks for the feedback Barry. I did try to OnUpdate but it seemed to fire after the PO post-processing screen had been called. I'll test it more throughly however as it was late last night when I tried that approach. Thanks for the feedback


  • Verified answer
    Barry Flynn Profile Picture
    Barry Flynn 3,090 on at
    Re: SL Customization - Change Default based on PO Type


    I'm not too familiar with the PO Maintenance screen - not a good start!

    However, if the lines you want to modify are inserted "automatically" then all the work is done by code in the host screen, and most events will not fire.

    In particular, Default events don't fire - they fire when the control is being defaulted.

    If program code is creating & piopulating a new record by directly populating the "buffer", then, the Control is "not involved in that process", and its Default event does not fire.

    You referred to the Update/Finish event.

    This event is not connected to the Finish Button.

    The Finish Event fires as you navigate off a document.

    So it fires as you Navigate, or hit New, or Close the screen.

    It DOES fire from the Finish Buttonm - in a round-about way.

    The Finish button is just a "shortcut" - it just does a Update followed by a NEW.

    And NEW causes the Finish Event to fire. But too late for your purpose.

    Have you considered the Update/OnUpdate event?

    That fires prior to the data being Saved. So it gives you a chance to modify it immediately prior to the host screen performing the Save.

    Be aware that (like all the "update" familly of events) it fires multiple times - once per Level being saved, plus possibly one or two extra firings (before the job starts, after it has finished. I forget the exact rules offhand.)

    Hope those ramblings are some use.


Helpful resources

Quick Links

Replay now available! Dynamics 365 Community Call (CRM Edition)

Catch up on the first D365 Community Call held on 7/10

Community Spotlight of the Month

Kudos to Saurav Dhyani!

Congratulations to the June Top 10 community leaders!

These stars go above and beyond . . .


André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 287,986 Super User

Martin Dráb Profile Picture

Martin Dráb 225,588 Super User

nmaenpaa Profile Picture

nmaenpaa 101,148


Featured topics

Product updates

Dynamics 365 release plans