Tracker is not a good tool to try to troubleshoot this. It simply shows you successfully invoked process period end and then encountered an unhandled error with your next action that may point to a database problem. If AP period end is working in other companies and at other clients, the problem would point to  inconsistency in the data. How was the data established if this is the first time you've closed a period in this company and how long have you been using the company? Have you purged data? Can you run period end in other modules or AP period end in other companies? Have you tried an administrative login?

If you copied the data from another company, an inconsistency could have been introduced, it might be a missing configuration option, or it could be sourced in one of your customizations to the data or code. Sometimes developers don't know how to work with the SQL permissions requirements in 500, so the problem could be based on security as well. It could be something simple but a detailed SQL trace will usually reveal the source with this type of issue if you can't narrow it down further.

We will look at all your suggestions, thanks.  The database trace showed nothing, though, and we've had 500 forever, so likely not permissions.  Company P is less than a year old and perhaps it is a setup issue.  Appreciate the help.

A detailed trace will ALWAYS indicate something with a two-tier client server application like 500. You may not be including the correct events or filters or you may not be interpreting or testing the results correctly.

For example, if you select just the Close Period option, a trace indicates a stored procedure execution of dbo.spapClosePeriod, then dbo.spGLUnlockFuturePeriods. You should see a successful completion of both, but if you never see the call to the first proc then you need to dig deeper and determine why. A trace of the form load and determination of the data required would be the first step in that scenario, including errors and warnings. If the process fails to complete execution of the second proc you should be able to determine where it stops and the problem might be sourced in module options or the GL fiscal calendar, etc.

Ran the trace today and did in fact see spapClosePeriod.  Ran it against our test Sage system and the error code is 7 from spglGetFiscalYearPeriod which according to the comments means   7 - Could not Create/Calculate Future.  Not sure if the most expeditious solution is to open a Case or if this information is sufficient for someone more familiar with the logic here to give me a direction.  Appreciate the help.

I would check your fiscal year calendar and make sure you have the next year defined. If you are using the Inventory Module, check that calendar as well.

Set Up Fiscal Calendar in GL as Darrick suggested. That proc is an old piece of code and may not have been updated with the module locking changes added a number of versions back (not sure if you have them in 2017). One scenario that might create a problem is if you are trying to close a period that is already closed in GL, or that proc isn't properly creating a new fiscal year because of the changes. Either way, it points to a problem with the next fiscal year or period in the sequence.

We had 2015, 2016 and 2017 set up.  Worked w/ Sage Support to instead set up 2015, 2022 and 2023 in a manner which gets us to our goal (to process our new company).

Sincerely appreciate everyone who helped with suggestions.