Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 Release Wave 2Discover the latest updates and new features to Dynamics 365 planned through March 2021.
Release overview guides and videos Release Plan | Preview 2020 Release Wave 2 TimelineWatch the 2020 Release Wave 1 virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
With Year-end now over, I wanted to share some information around Encumbrance and Year End transfers since many of you are in the process of doing this or will be in June after Fiscal Year end. The Year End Encumbrance Transfer window is used to transfer encumbrance balances on open Purchase orders (POs) from the current year to the next year. The transfer process automatically liquidates encumbered amounts in the current year and updates open purchase orders with the remaining amounts that will be delivered in the next year.
Encumbrance Year End transfer window is located by going to Purchasing > Routines > Year End Encumbrance Transfer.
When running this process, you may encounter the following error: “You can’t transfer encumbrances for XXXX when there are outstanding encumbrance amounts for a prior fiscal year” (XXX representing a specific year). I want to share with you some information about this error, how to troubleshoot this error and what you can do prior to contacting support for help.
There are many reasons for experiencing the error.
There are a few options to try resolve this error. I always recommend that you move a copy of your LIVE data into a TEST company for testing. This blog assumes the user running these steps is familiar with the Encumbrance and Purchase Order data and how the tables should look in the backend. If you are not familiar, you may need to reach out to your partner or create a support case for assistance. In a support case we can assist with one or two problem Purchase Orders and give guidance, but if you have issues with more than a couple Purchase Orders, you may need to create separate cases for each PO as each one may have a different condition that requires separate analysis of data.
OPTION 1: Run the Year End transfer through all the years in the past to ensure there is not a Purchase Order that was entered/encumbered in a previous that needs to be transferred.
Go to Purchasing > Routines > Year End Encumbrance Transfer. Start with the current year, then continue to move backward year by year to find if there is a Purchase Order that needs to be transferred. If there is a PO that is “stuck” and continues to stay on the report even after the transfer, that Purchase Order needs to be dug into by running the ALL PO and Receipt script (link listed later in this blog) to determine what is wrong with the PO. Many times, the ENC10111 is not in the right state which causes the Purchase Order not to not move forward to the next year. If that is the case you may be able to run Option 4 to get the PO to transfer.
OPTION 2: Remove Completed POs and remove history.
Use this option if you have a specific data condition where a Purchase Order on the transfer report just won’t move AND the Purchase Order is in a Closed or Cancelled status. It could be that the PO is damaged and just needs to be deleted from GP. If you are okay with this option do the following steps.
OPTION 3: Data check script
We have a script below you can use to try and identify the culprit PO(s) causing the transfer to error. Many POs can be in the list returned but focus on the 1st one returned that is listed. Not all POs listed are necessarily bad. It just stops after it identifies the 1st corrupt Purchase Order and lists the rest after that. If we fix the 1st corrupt Purchase Order, the hope is the rest of the PO get removed off the list and the transfer goes through without an issue. If not, you will need to repeat the process until the list is cleared.
ACTION of Option 3 overall will be:
Once you know #1 and #2, you now can run the script below to find the problem PO(s). To run the script, you need to run it for a date range that matches your fiscal/calendar years plus 1 extra day.
Use the script below. The key IS entering the correct dates.
If you are calendar, then you would be 1/1/2017 to 1/1/2018. Let's assume you are set up for a Fiscal year starting May1st, instead so that is my example below.
If my first period started on May 1, 2017, and the year ended on April 30th, 2018, my script would look like this:
declare @FROM varchar(10) set @FROM ='05/01/2017'
declare @TO varchar(10) set @TO ='05/01/2018'
declare @FROMDATE DATETIME set @FROMDATE = CONVERT(DATETIME, @FROM, 101)
declare @TODATE DATETIME set @TODATE = CONVERT(DATETIME, @TO, 101)
from ( select ENC10110.PONUMBER, ENC10110.POLNENUM,
(SUM(ENC10111.ENCMBAMT) - ISNULL(
where (GLPOSTDT>=@FROMDATE and GLPOSTDT<@TODATE) AND
ENC10110.PONUMBER = ENC10500.PONUMBER AND
ENC10110.POLNENUM = ENC10500.POLNENUM),0)
) AS REMAMT
inner join ENC10110
ON ENC10111.PONUMBER = ENC10110.PONUMBER AND
ENC10111.POLNENUM = ENC10110.POLNENUM
where (ENC10111.TRXDATE>=@FROMDATE and ENC10111.TRXDATE<@TODATE) AND
GROUP by ENC10110.PONUMBER, ENC10110.POLNENUM,
) AS ENC
The key is to understand what dates you should be running. If you don’t use the correct date restrictions, you could get results that you think are wrong, but actually they are correct and only display because of the way you ran the date restrictions. I always recommend that you start with the year you are trying to transfer, then go back year after year until you receive no results. If you are using the last example set up, you would start with:
declare @FROM varchar(10) set @FROM ='05/01/2017'
declare @TO varchar(10) set @TO ='05/01/2018'
declare @FROM varchar(10) set @FROM ='05/01/2016'
declare @TO varchar(10) set @TO ='05/01/2017'
declare @FROM varchar(10) set @FROM ='05/01/2015'
declare @TO varchar(10) set @TO ='05/01/2016'
And so on, until the results are zero. If I received no results for 2015 to 2016, then I would run the previous script for 2016 to 2017 and that is where I would start troubleshooting. The purpose of the exercise is to find where the problem started.
Again, typically, you would then get the results from the ALL PO and Receipt scripts for the FIRST purchase order in the list and review the data to determine what is wrong. Once you determine the issue and fix the data, you should be able to rerun the Encumbrance Routine Maintenance and then transfer the year.
IT IS IMPERATIVE that all Encumbrance users are on a version of GP equal to or greater than 11.00.1799.
NOTE: Support can help with one or two problem PO(s) and look through the data to give advice on how to fix them, but if you have MANY POs you will need to work with your partner to fix the data or create separate cases to assist analyzing the data issues. Each PO has MANY tables to analyze so one or two Purchase orders in a support case is acceptable to dig through, but after that the case is more consulting and needs your partner’s assistance to work through.
Instructions for gathering the ALL PO and Receipts script.
Script found here:
Run it in text using instructions below.
The goal of this statement is to review ALL data related to a specific Purchase Order. It is only a SELECT statement. It will not update/delete data.
declare @PONUMBER char(20)
select @PONUMBER = 'POXXXX'
OPTION 4: Remove data in the ENC10111 for specific Purchase Orders (or all ENC10111) that are damaged and run reconcile on encumbrance and try the transfer again.
NOTE: If you only have one PO that won’t transfer or clear off the transfer report, you can specify the specific PO to delete.
DELETE ENC10111 WHERE PONUMBER = 'XXX'
The ultimate goal is to have the script in Option 3 run, year by year, and have no data returned which would mean that the year end transfer process can be processed without error.
OPTION 5: Disable and reenable encumbrance
If there is a large amount of corruption found, the best option may be to consider disabling encumbrance, moving all closed/cancelled Purchase Orders to history and then re-enabling encumbrance. Note: To move closed/canceled POs to history, use the Remove Completed Purchase Order routine to move the PO to the history file. Navigate to Purchasing > Routines > Remove Completed Purchase Orders. You DO NOT lose ANY purchase order processing data as long as you are setup to maintain history in POP setup. You only lose some of the old encumbrance detail from historical years for Pos that are in history. You will still be left with current outstanding encumbrances for the current years you have open purchase orders for.
I hope this information is helpful with your Encumbrance Year End transfers and gives you some things to try before contacting support.
Angela Ebensteiner | SR Technical Advisor | Microsoft Dynamics GP
Business Applications communities