Skip to main content

I was contemplating how to document the contents of a customization project. I thought about adding a readme document as a File in the project. There are also Wiki options or perhaps a Code file that doesn’t get exported to the Extension library.

This might include a change log so that I can include that with the project in a way that someone else can look at without having to go somewhere else to read what’s new/changed.

How do you document your functionality and changes so that others can understand what the customization project is doing?

For me a readme is usually more than enough, but if I ever needed more I would probably use a wiki with a link in the readme. I don’t generally keep a changelog as the git commits mostly already cover that need.

I find it easiest to keep any documentation as close as possible to whatever source control you are using. 

Hi @ddunn 

You can add notes to a customization project. I know many members of our team uses that to keep track of changes and such. 

This is topical for us as well because we are defining our own best practices for customization packaging, publishing, and backup.  I haven’t decided yet, but I’m leaning towards a readme.md (markdown) file included in the customization package, as well as being stored in our source code repository (Azure DevOps) for that customization.

I don’t believe that notes on a customization project inside Acumatica will be exported into its package, so I wouldn’t recommend using notes for this purpose because of its lack of portability.

Reply


Terms & ConditionsCookie settings
About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2024  Acumatica, Inc. All rights reserved