Design Patterns | 10 Video’s

At the moment of writing this, 10 Design Pattern video’s are published. I recently started working on 5 more.

People at Microsoft have asked me what is the logical order of watching them. This is actually quite a hard question to answer. Some videos are in detail about a specific pattern that is represented by a few fields and some code while other video’s are about larger patterns such as explaining the locial flow of posting routines.

But let’s do a suggestions:

How Do I :

1. Build solutions using design patterns

2. Read and Understand the Posting Routines

3. Work with Master Data and Posting

4. Implement Master Data

5. Implement the Number Series Pattern

6. Use the Journal Template-Batch-Line Pattern

7. Implement the Singleton Table Pattern

8. Use the Select Pattern in a Posting Routine

9. Use Temporary Datasets

10. Use the Transfer Custom Fields Design Pattern

I hope this helps you find your way. The five new titles will be published soon.3. 3.


  1. Peter Elmqvist says:

    Hi Mark

    I have a question regarding video no. 6 “Use the Journal Template-Batch-Line Pattern”. At approx 9:00 you state that the logic in OnValidate is only used when using the UI. I can understand the logic behind this is you are in a posting routine and transfer the fields from SalesLine since these are already validated. However given an example where you import data from a external system and need to populate a item journal. Would you argue that validating the data is ok and considered a automated input, or would you still consider that no validation should take place?

    Alternative 1

    ItemJnlLine.”Posting Date” := TODAY;
    ItemJnlLine.”Document Date” := TODAY;
    ItemJnlLine.”Item No.” := ‘123456’

    Alternativ 2
    ItemJnlLine.VALIDATE(“Posting Date”, TODAY);
    ItemJnlLine.VALIDATE(“Item No.”, ‘123456’);

    My issue with alt 1 is that there is alot of code in OnValidate for “Item No.” that needs to be duplicated instead of letting the standard application handle this in one place. I would really appricate any feedback from you in this matter. Thank you.


    1. markbrummel says:

      Peter, my personal preference is not to use VALIDATE in any situation. This allows better control over the specific transaction. Someone might go into the OnValidate trigger of the Journal and change something that breaks your code.

      Also from a performance perspective it is better to avoid validation since there is in general to much being fired that is unnessesairy when you have full control over the transactionl.


Leave a Comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.