Lance brigham
Forum Replies Created
-
::
Hi Larry,
This use case was what Business Alerts was created for (Microsoft Dynamics GP>Tools>Setup>System>Business Alerts). Within Business Alerts, you would add RM00101 (RM Customer MSTR) and RM00103 (Customer Master Summary) joining the 2 tables together with CUSTNMBR and then set the condition to this formula: RM00103_T1.CUSTBLNC > ( 0.8 * RM00101_T2.CRLMTAMT )
I haven’t used Business Alerts in awhile, but looks like this does support email using an O365 modern auth exchange account, but that would need tested. Also not sure how to limit this to just customers who’s credit limit type is set amount (if unlimited credit limit amount would be 0 so this formula would give a false positive). If you don’t have any customers with unlimited credit then this should work in all cases, but again you’d want to test this first.
Another route could be either an SRS report with subscription (benefit here is you could run this manually at any time) or SQL job with email configured in DBMail to send an email that does this comparison. Both of these would be more complicated than Business Alerts, but offer more flexibility.
Hope that helps at least provide a direction. Let me know if any questions.
Thanks,
Lance Brigham
Principal Consultant
Velosio
-
::
Hi Mary,
The screenshot of the login window you provided is not the normal login window for GP. I know I’ve seen that login window before when attempting to run GP, but can’t recall the exact circumstances surrounding when that occurs and is indicative of there being some other issue in place causing that login window to appear instead of the standard window. It might be a misconfigured ODBC configuration that causes that so I’d suggest verifying that first. For reference, I’ve attached what the login should look like as well as what you provided so you can see the difference.
Let me know if any questions.
Thanks,
Lance Brigham
Principal Consultant
Velosio
-
::
Hi Kevin,
I apologize that this is possibly well passed its usefulness, but here are the high level steps involved with rebuilding the data mart:
- Ensure all users are out of Management Reporter
- Open Configuration Console and do the following:
- Highlight the Management Reporter data mart integration under ERP Integrations, and click Remove at top right of this section out of the 5 options in that area it is the one at the top
- Highlight Management Reporter Services and click on Stop for Process Service followed by Stop for Application Service
- Keep Configuration Console open and open SQL Server Management Studio with an account that has permission to drop databases and drop the Management Reporter data mart database. This should be ManagementReporterDM
- Back in Configuration Console do the following
- Click on Start for Application Service followed by Process Service to restart services
- Click on File > Configure in top left menu
- Check checkbox for Add Microsoft Dynamics GP Data Mart and click Next
- Enter server and credentials for GP and the ManagementReporterDM and click Next followed by Configure
- When this is done the Management Reporter data mart should reappear under ERP Integrations, highlight that and click on Reconfigure change tracking, enter credentials (i.e. sa) and click OK (I’ve run into issues enough with change tracking on tables getting removed that I do this each time although should be unnecessary if rebuilding but doesn’t hurt to do and takes just a few seconds)
- Click on Enable Integration – this may take awhile depending upon size of GP databases
I hope that helps. Let me know if any questions.
Lance Brigham
Principal Consultant
Velosio
-
Lance brigham
MemberJuly 27, 2024 at 11:24 am in reply to: MultiEntity Managment Report odd behavior -
::
Hi Precious,
As to how to identify duplicate vendors, I think it’d be helpful to know for your specific environment what would designate a duplicate vendor? Is there some sort of identifier that would be the same like a tax ID or something? If so, can do a SELECT SomeField,COUNT(*) FROM PM00200 GROUP BY SomeField HAVING COUNT(*)>1 in SQL. From there can do some further querying and determine which vendor ID(s) fall in that same query and then determine which vendor ID you want to keep (combine into). If it’s 2 or more vendor records with same address that could potentially be challenging if you have duplicate vendors with the same address, but entered slightly differently (i.e. 123 East Main St versus 123 E Main Street). Could use the default GP SmartList for Vendors and output to Excel and review/analyze in Excel for which are duplicate and then from there once you have your duplicate vendors identified and which vendor ID out of a group of duplicates/triplicates/etc to keep, then can save to a tab delimited csv/tsv and use that as source for vendor combine in GP.
Let me know if any questions.
Lance