I am new to Navision and trying to enter a simple allocation. I am following an example to the letter. However, when I set up the allocation and then go to Financial Mgmt > General Ledger > Periodic Activities > Allocation Processing → enter the proper information - I end up with the following error message: ‘The G/L Entry table does not have an active key that starts with the following field(s): Transaction Type,G/L Account No., Fund No.,Global Dimension 1 Code, Posting Date.’ Any ideas on what that means or how I can fix it? Thanks - Kevin
It means that table 17:“G/L Entry” doesn’t have an active key with these fields in it. Go into design of the table, open the indexes and see if an index has those fields and hit the toggle to enable it. If there is no such index, you can create it. In this case make an index. "G/L Account No.,Transaction Type,Fund No.,Global Dimension 1 Code, Posting Date. With the fields in this order, the index will more performant. After this save the table. This can take some time because Navision has to create the table.
I am sorry that it took so long to reply. Alain - thanks for the above response. I may not be looking at this correctly. But - when I go Tools > Object Designer > Table 17 (G/L Entry) - the table has all of these options checked. Am I looking in the wrong place? I apologize if this is a silly question, but Navision is brand new to me and my company. Thanks for your help.
Yep, you are missing on important step to get the the keys… > View, >Keys - that’s the list of keys that is defined for the G/L Entry table. The process you mention is a customization, at least neither the W1 (international) nor the NA (northamerica) release have this process, and also a couple of fields you mention do not exist in the standard version. It’s very probable that the key has not been created in the mentioned table. Saludos Nils
Thank you Nils. I will continue to work on this tomorrow. I will let you know how it works. Thanks for your help - Kevin
I wanted to also post this for others future reference. To improve posting performance, key groups have been implemented for Grants, Investment, BudgetPkg, Closing, RevenueMgt, Allocation, and Reimburse (for Reimbursements). Note always check the readme.doc that comes with the release to be sure all necessary Key Groups are setup. To enable or disable: i. File, Database, Information, Tables button, and then Key Groups button. ii. Type in the name of the Key Group. iii. Click the Enable or Disable button. This should solve the problem. Thanks for everyones help.
I would definitely like a response to this if anyone has an opinion or comment. To solve the problem I went: Object Designer>chose the correct table>Design Button then View>Keys and I added a new line at the bottom. In the SumIndexFields I added Amount, Debit Amount and Credit Amount. This seems to have completely solved the problem. Does anyone know if I missed anything or may have messed up anyother areas??? Thanks - Kevin
Your solution is 100% correct - adding a key doesn’t mess up anything, deleting or modifying of course can do so… you’ll just need some more db space for the new key. I am not sure if you really need to add the 3 fields to the the SumIndexFields, this is only necessary if there is a flowfield that is based on this key to calculate these amounts, though it’s just a matter of some db space, it doesn’t have any further implication adding these fields. Saludos Nils
Once again - thank you very much. Thanks also for clarifying the SumIndexField. I have had this question sent to support for over a week with no solution and you were able to solve it in a day. Thanks for the good work and for being willing to share your knowledge.
Thanks a lot for you feedback and appreciation, this is exactly the type of replies that motivates one to share knowledge! Glad I was able to help. Saludos Nils
Just when I thought I was all fixed up I ran into the same type of error message for a client. However, this time there is another catch. After using the same fix as documented above - I received the following message: ‘There are only 40 Keys allowed per table…’ Is there a Key that is safe to delete to make room for the new Key or is it possible to have more than 40 Keys in a table? Thanks for the help - Kevin
Kevin, unfortunately navision has a restriction on keys of 40 per table, nothing to be done there… what key to disable without causing a problem at another point cannot be determined exactly - it depends a lot on what functionality you are using, what new keys have been setup for new reports, which of those new reports you actually use, etc. Are we still talking about table 17, or another one, as you mention customers? What Navision version are you using? This might give a first idea on what key can be disabled… Saludos Nils
The client is moving from 2.6 to 4.0 and it is in table 21 - ‘Cust. Ledger Entry’. The exact error message is - ‘The Cust. Ledger Entry table does not have an active key that starts with the following field(s): Document Type, Document No., Customer No…’ When we try the above fix - then we get the error message about already having 40 Keys. Thanks again and again. If for some reason you are ever are any near Boise Idaho - I will buy you many many drinks.
Kevin, I can suggest 2 choices 1) modify the process/report you are running to use the following key: Document No.,Document Type,Customer No. 2) Disable the key: Transaction No. (I haven’t seen any report or process using that key… please correct me if I might be wrong here) By the way, thanks for the invitation - not sure if I can make around there, but I appreciate it [;)] Saludos Nils
Nils - Thanks again. I will talk this over with the client and see which one they prefer. As far as the invitation goes - it can’t be more than about a 14 hour plane ride. Maybe it would be easier to meet in Costa Rica or somewhere in the middle. Thanks again.
2) Disable the key: Transaction No. (I haven’t seen any report or process using that key… please correct me if I might be wrong here)
The key is used in 2 places: Table 179:“Reversal Entry” and C367:“CheckManagement”. So I am not sure if this is save. I would try to first suggestion of nilsm You should really be thinking about re-structuring the indexes of the table. 40 keys in 1 table is a lot. Probably posting something in the table is quite slow. Probably a lot of keys are just used in 1 or 2 reports (or not at all). If you restructure the reports to use another key, you can delete the key, gain place for other keys in case you really need a new key, and gain performance.