https://forum.mibuso.com/ Wed, 13 May 2026 09:54:12 +0000 en Design Patterns — mibuso.com https://forum.mibuso.com/discussion/77046/in-manhattan-scale-wms-application-where-can-i-find-bulk-storage-to-do-a-replenishment Fri, 27 May 2022 13:55:29 +0000 Design Patterns kingston_surya 77046@/discussions https://forum.mibuso.com/discussion/76812/why-use-the-get-function-with-setup-tables Wed, 02 Feb 2022 09:53:47 +0000 Design Patterns alex6789 76812@/discussions
if not SalesReceivableSetup.get() then
SalesReceivableSetup.insert();

if SalesReceivableSetup."Order Nos." = ' ' then begin
SalesReceivableSetup."Order Nos." := CreateNoSeries();
SalesReceivableSetup.Modify();



]]> https://forum.mibuso.com/discussion/76573/how-to-create-field-that-connect-to-another-field-and-changes-its-value Mon, 27 Sep 2021 14:26:07 +0000 Design Patterns MonZi 76573@/discussions https://forum.mibuso.com/discussion/66793/web-servers-with-https-and-nav-web-services Mon, 13 Jun 2016 12:00:13 +0000 Design Patterns cpittis 66793@/discussions
Where can i find documentation or something which proves that Web Servers with HTTPS can communicate with NAV Web Services?
version: 2009 R2

Thanks]]> https://forum.mibuso.com/discussion/66766/changing-report-text-to-blank-depending-on-user-selection-nav-2013 Thu, 09 Jun 2016 12:19:37 +0000 Design Patterns LewisTioga 66766@/discussions
Any suggestions on how to write this so I can get a blank output. Thanks ]]> https://forum.mibuso.com/discussion/66762/if-statements Thu, 09 Jun 2016 08:21:19 +0000 Design Patterns LewisTioga 66762@/discussions

All feedback is appreciated! ]]> https://forum.mibuso.com/discussion/66547/is-there-something-like-sonar-qube-for-c-al Mon, 09 May 2016 07:30:56 +0000 Design Patterns svensk.tiger 66547@/discussions https://forum.mibuso.com/discussion/65330/pattern-identification-issue Wed, 04 Nov 2015 18:00:33 +0000 Design Patterns Brimstar 65330@/discussions
Quick explanation:
We have a document that is created by our quality department under specific circumstances. It indicates that when we sell part A to customer B we must do X, Y, and Z. X, Y, and Z are defined as processes 1, 2, and 3 in a code list by our quality department.

The bit of data I'm looking at is how we define those codes, called QC codes currently. Considering I'm calling it a document obviously that's a document pattern with the codes being attached as lines. The codes feel like they should be master data, but they must also be maintained as revisions. Entirely possible the code could be updated but historical documents would still reference the older version. What's the best method for this? Is there another pattern I should be considering?

Gut reaction is that do the main characteristics of the QC code that can't change based on versions using the master data pattern and carefully review what can change and place those fields into the rules pattern for the data that has to have a revision maintained since a combination of the master data and this additional data controls what should appear on the main document treating it like the pricing tables.

Overall I'm still new to the idea of designing a whole new section within NAV, having mostly done minor code adjustments in NAV over the last couple years. Just finished reading Mark's book on this subject and this project seems like a good place to start putting this into practice.

]]> https://forum.mibuso.com/discussion/63569/why-did-design-patterns-become-a-popular-topic Wed, 14 Jan 2015 16:17:31 +0000 Design Patterns Miklos_Hollender 63569@/discussions
2) They are strongly add-on focused, not customization focused (too heavy weight, does not worth the effort if you think no more than 2 users will use this feature you just built)

3) Even on an add-on level, they tend towards being heavy-weight, just like the standard is. Here is an example. For the hooks pattern, using a separate object for every hook is a huge overkill. Even in an add-on, one (or one per licencing option, licence granule) suffices.

On the plus side, if you are new to this all, they help understanding the standard better.

I am not saying it is a bad idea or anything. Making add-ons more standard and helping new people understand the standard are useful and okay goals.

I am just bothered that you are not making it clear that these are patterns for large add-ons, where it is worthwhile to invest your time because it will have a hundred users.

So you are not making it clear enough they are not "mandatory" if you are making one button that Katie from Accounting will click once a week.

Look, one issue with the whole ERP or even whole software industry is that everybody is talking about always scaling things _up_.
But in the NAV world I think we all know scaling things _down_ is also a problem, because we often have small clients, who cannot afford large projects and so on. It is often said that this - that small changes could be made lightning-quick - led to the popularity of NAV: once a guy who knows both SAP and NAV explained to me that it takes more time configure the equivalent of General Posting Setup in SAP than extending, via programming, it in NAV by a completely new kind of transaction i.e. column, and posting logic.

Our advantage is that we can be quick, if must be. You have seen customers throwing an 50 item list of small change / trouble requests at you and seen good developers chew through them in less than a week, right?

For this reason, we should not really give people the message that heavy-weight design patterns are to be used all the time, or to put it differently, we should not tell people to do every job as if it was making an add-on.

Since technically they are very similar, we need to separate add-on development and quick customizations "culturally".

I propose to consistently rename terms like Design Patterns to something like Add-On Design Patterns.]]>