ECi M1

API Integrations There are two M1 APIs: a) The generic “ERP” api which is missing a ton of functions. b) The M1 Public API which is starting to have a lot of the necessary functions. Form Customization Report Customization M1 reports are based on Crystal Reports. You will need to buy at least one license from SAP Crystal Reports in order to edit reports in M1. https://www.sap.com/products/data-cloud … ml#buy-now The best way to handle licensing in my opinion is to limit access to the Cyrstal Reports software by setting file/folder permissions so that only to users in a special LDAP/AD group can access the software. You need to buy licenses for the maximum number of people in the group. If your group has 5 users that can edit Crystal Reports, that means you need 5 licenses. I think it is more realistic to buy something like 2 licenses, meaning 1 main user and 1 ‘on demand’ user. Grid Customization M1 grids are SQL queries converted to spreadsheet (grid). This means one doesn’t need to be limited to just using the “Add Table” button. The “Tables” field is the FROM part of the query. The “Fields” popup is the SELECT part of the query. The “Filter” field is the WHERE part of the query. There is a length limit on the “Tables” field and if I remember correctly you can only nest/include one (mayyyybe two) subquery. How to use ECI M1 Please use this category only for discussions relating to how to use the ECI M1 software and related systems. Specifically, this category is primarily for “use” and not instructions or questions about customization. Database Integrations Directly modifying the MSSQL database very easy and fast but also potentially dangerous. You need to have a good understanding of parent and child tables, column data types, manual and auto-increment indices, and MSSQL statements. Database integrations can also potentially bypass fields that are required in M1 forms but not in the database itself. I recommend using the API integration whenever possible. The API (should) stop bad transactions (i.e. missing critical fields) and also be future-proof (i.e. if an update adds a critical field or a new child table it should prevent bad entries whereas a direct database integration will happily create bad entries).