The LedgerLink scripts are organized following Modular FileMaker principles. That is, if you're starting at the bottom of the script list, each step toward the top further increases the specificity of the script to the solution. Therefore, scripts at the very bottom no nothing about your solution.
For LedgerLink, the module at the very bottom is HTTP. All it knows is how to send and get requests and responses. It does not know your data model, how to set fields or how to gather data to send. It can be copied to any other solution and it would just work!
The top module, File Module, is very specific to this File. What happens when it opens? closes? resets?
In between these modules are degrees of specificity to the solution. It helps to understand the script structure because once you do, you'll easily find the script you need. Let's say your looking for the script that sets QBO data into Customer fields. Well, that script would certainly need to know about your data model. So, we know it's in the LedgerLink module. A user might want to modify this script, so it's a "config" script. And finally, we know that Customers are a "Name List" type in QBO. Knowing that, we quickly go to the correct folder and find the Customer :: Field Map :: Set script.
We break down the folder structure design by module in these other articles:
- LedgerLinksSync API
- LedgerLink API