Source Type / Source No. in G/L Entry table.

MarkKeener
Member Posts: 17
I have a client that has a report that they run against table 17 that shows what they've spent for each G/L account with each of their vendors. They do this using the Source Type and Source No. fields that are populated automatically when using either the purchase journal or a purchase invoice.
However, sometimes the wrong G/L account is entered and they want to reclassify the expense to another G/L account. This is done using a regular G/L Journal Entry. But, when doing that, the source type and source number fields are not populated in the journal and so the report is no longer accurate.
I already know that I can expose the Source Type and Source No. fields on the G/L Journal Entry form and they will populate. Is there any reason that I SHOULDN'T do this? Are these fields used for any other reason than to provide a reference back to the vendor (or customer, bank acct, etc.) when entries are made from subsidiary ledgers?
I know this sounds like a dumb question. I can't think of any reason why I shouldn't use these fields in a journal entry, I just want to make sure I'm not overlooking something.
THANKS!!
However, sometimes the wrong G/L account is entered and they want to reclassify the expense to another G/L account. This is done using a regular G/L Journal Entry. But, when doing that, the source type and source number fields are not populated in the journal and so the report is no longer accurate.
I already know that I can expose the Source Type and Source No. fields on the G/L Journal Entry form and they will populate. Is there any reason that I SHOULDN'T do this? Are these fields used for any other reason than to provide a reference back to the vendor (or customer, bank acct, etc.) when entries are made from subsidiary ledgers?
I know this sounds like a dumb question. I can't think of any reason why I shouldn't use these fields in a journal entry, I just want to make sure I'm not overlooking something.
THANKS!!
0
Comments
-
The idea is that if a user should not be able to edit a field, then the table will be non editable (Through license) or the field will be non editable (through properties) or there will be code to give an error message (on validate), always at the table level.
So if you can with an end user license, go to table designer an modify a field then you have to assume that the developer that created that field wants to allow you to change it.
So yes you should be able to expose these fields without problems.David Singleton0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions