Modifying Cust. Ledger Entry and G/L Entry?

Andy_Smith

NAV2013

I have a client that had several weeks of transactions post with bad "Description" fields for Cust. Ledger Entries, which in turn fed to the same field in G/L Entries. Table 36 Posting descriptions were changed to an uninformative and uniform "Entry <Document No.>" instead of the default of the document type and the document no.. We've fixed the table 36 issue, but now want to clean up the existing entries in the CLE and GL.

I'm aware that any modification of G/L Entry is generally frowned upon, and would not attempt to do so for anything other than resetting bad descriptions to the default behavior.

I've created a processing report to scan for Customer ledger entries that have the bogus description and first change the G/L entries associated with it, and then the Customer ledger entry, but when I test it on a single CLE entry, I receive an error: "You do not have the following permissions on TableData G/L Entry: Modify". I do have SUPER role, and I do have full DBO permissions on this database.

Is this a permission that is unavailable due to concerns of modifying the G/L, and if so, what would be the recommended recourse for the client to fix these descriptions? I can modify other tables without issue and wasn't aware of any hard locked tables existing, but wasn't sure if this is a new feature in 2013?

bbrown

"G/L Entry" and several other tables are what are known as "protected tables". They can not be directly written to (insert, modify, delete) with a standard customer license. Only a license with the "Solution Developer" granule can. Or you need to assign the permission to the object doing the update. That also required "Solution Developer".

This is not something new. Been this way for a very long time.

Marije_Brummel

Hey Andy,

Brian is correct, with an end user license you have to give the object extra permissions.

Look at codeunit Cust. Entry-Edit (103) as an example.

I guess programmers never ran into these issues in the past where you would just run the report with your dev-license. Now we have the situation where changing the license on a customers live database is less simple.

Good luck.

Andy_Smith

Thank you Mark and bbrown. Indeed, if I ever have had to change g/l entry before it was likely in a pre-2013 classic environment with the dev license loaded. Thanks for the heads up.