G/L Acct Dimension Enforcement... can use ranges?

MW59

Greetings All,

I see that on the homepage, Alex finally says what we've all known for years. This IS better than MS support and I appreciate everyone (including Alex) around the world who has helped me in the past.

Anyway... I'm a PM (not developer) trying to help a NAV 5.0 SP1 (NA) user who wants something extra from dimension code enforcement on the G/L Account card.

I know we can enforce the use of any code, a specific code, or even bar the use of a code. But my user wants to declare that certain code ranges are okay while others are not for a single G/L account. Actually, it strikes me as a reasonable request.

Is there some way to achieve this short of throwing 1,000,000 <insert currency of choice> at Programming?

Thanks in advance for the feedback and I bid a good weekend to all.

mw

ssingla

Sorry but not possible without customization though I am curious to know the scenario.

MW59

ssingla wrote:

Sorry but not possible without customization though I am curious to know the scenario.

Thanks for your reply and the scenario is pretty basic. They're using a single Global Dimension and in the case of (for example) G/L expense account 43500, they want to enforce the use of Departments 50, 51, 52, or 53. That is, one of those codes is mandatory. On the other hand, codes 60 & 61 are always the wrong answer. Of course, people use them anyway, so they want the s/w to prohibit that.

DaveT

Hi MW,

This is not a major change - change the table for additional code and the codeunit DimensionManagement (408) function CheckValuePosting.

Would definitely be able to delivery under the "1,000,000" budget

MW59

DaveT wrote:

Would definitely be able to delivery under the "1,000,000" budget

Dave... are you sure you're not in Sales? Anyway, thanks for the tip and I'll inject it into what appears will be a programming issue.

Thanks again! <hoisting a shot of Crown Royal in your direction>

mw

djswim

$500k fixed price bid... PM me for details

That includes two weeks of on-site time as well, can be negotiated to more if you're somewhere sunny or with a large number of microbreweries...

Alex_Chow

1. You'll need to create a new table to store dimension restrictions against G/L accounts.
2. Modify the CheckDimComb function in codeunit 408 so it checks for illegal combinations on the table in step 1
3. if true, then error.

See! Easy! :whistle:

MW59

Thank you very much Alex & DJ.
DJ? I may be in touch after talking with the resident coder on Monday... sunshine abounds, there was a microbrewery (will check if deleted) and tornados always possible for a cool photo op. 8)

kriki

[Can you change the attribute of the topic to <Solved> (or also <Good Posting>) and remove the text from the title?]
Please see Forum Rule(s) #3.9: Forum Rules.

MW59

kriki wrote:

[Can you change the attribute of the topic to <Solved> (or also <Good Posting>) and remove the text from the title?]
Please see Forum Rule(s) #3.9: Forum Rules.

I did show the issue "solved" and removing the topic strikes me as counter-productive for other people searching for answers about the same question. I don't think I'm understanding you.

mw

DaveT

Hi MW,

What Alain is asking is to use the new way of marking a post solved i.e.


as opposed to writting [Solved] in the title.

kriki

DaveT wrote:

Hi MW,

What Alain is asking is to use the new way of marking a post solved i.e.


as opposed to writting [Solved] in the title.

Correct.
But I will have to rephrase my wording, it seems. :-k

MW59

Well... I apologize. I had not previously paid attention to the "Attribute" field and at first, I thought I was being chastised for using "[ ]" instead of "{ }" to surround my "Solved" text. My first inclination was that I was being counseled by someone with way too much free time on their hands and I responded accordingly. :-({|=

I now understand and will use the "Attribute" field accordingly.

Cheers!
mw