Bank Receipt Journals

sriram_venkat

In the bank receipt journals, there is no standard field to capture the information for receiving check number, date and bank. We are forced to enter in the external document number field. These are very basic information which any client would request for. How come NAV / Microsoft ignore these standard features. Sometimes these look very weird and we dont have any answer when client says that NAV does not even carry basic features?

Same case with PO Deletion after the quantity is fully received? Why should it get deleted in first place? We cant be able to take any report in future unless it is archived? Sounds strange...

Does anyone has any answer to it?

David_Singleton

sriram_venkat wrote:

In the bank receipt journals, there is no standard field to capture the information for receiving check number, date and bank. We are forced to enter in the external document number field. These are very basic information which any client would request for. How come NAV / Microsoft ignore these standard features. Sometimes these look very weird and we dont have any answer when client says that NAV does not even carry basic features?

Same case with PO Deletion after the quantity is fully received? Why should it get deleted in first place? We cant be able to take any report in future unless it is archived? Sounds strange...

Does anyone has any answer to it?

The answer is to sit down and learn the basic concept. In your case spend a lot of time playing with the Navigate function in Navision and understand how it works. Then work with one of your Database Experts and have them explain how databases are designed, and how relations work.

I assume you are a sales person form these remarks, and your job should not be to sell these concepts, you need to get a Senior Navision Functional specialist to sit with the client and explain the details of how Navision work and why it does things the way it does.

If in your company you don't have the people that can do this then you should not be selling Navision.

My job is fixing up Navision disasters, and what I see over and over again is code written by companies because they did not understand basic Navision and duplicated exiting functionality.

Jeffrey_Fletcher

Hi, as suggested some features you want already exist such as customer "Branch Bank Number" "Branch Account Number" which will appear on deposit slip when printed plus "Document Date" which can be used for Check Date and will appear on Customer Ledger Entries. The External Document Number field is not on Customer Ledger Entries screen by default. If in doubt of a particular field and its use then use the F1 Key and online help, it is normally OK as far as help goes but occasionally misses the point.

Unlike David I accept at times NAV is lacking in some basic features I personally believe are required however due to its development environment and ease of customisation many solution centres have an internal modified NAV Database they roll out as the standard product which resolves what they see as key missing features. Many features also date back to historical needs and the good old days when NAV sold individual granules of functionality and some of this historical baggage is really no longer required.

Implementation Disasters are normally a contribution of factors including client expectations and ability plus obviously experience of the implementor. To really understand NAV including its strengths and waknesses you have to use it and if it is in a real business even better.

David_Singleton

Jeffrey Fletcher wrote:

Many features also date back to historical needs and the good old days when NAV sold individual granules of functionality and some of this historical baggage is really no longer required.

Could you give some examples please.

Jeffrey_Fletcher

Examples - where do I start.

Sales and Territory code on Customer card can be Advanced Dimensions now although you can sync old fields with new dimension for them but old field is Code = 10 and Dimensions Code = 20 so is a bit inconsistent.

Journals having Gen Bus and Gen Product Posting Grp - as an Ex Chartered Accountant the purpose of this is extremely confusing to all clerical staff I have ever trained as it serves no useful purpose at a General Ledger level.

In regards to missing fetaures
Bulk Email of key business documents as pdf attachments
Workflow on bank reconciliation,cash payments and cash receipts
Support for Direct Credit files and bank Statement importation in different countries
A Service Management Module that actually works
A Job Costing Module that actually works
A Intercompany Module that actually works
etc

Dont get me wrong I do think NAV is a great product and is better than the competitors - they all have their own unique weaknesses, but it lets itself down at times on features and functionality that really are not that hard to fix hence why most successful solution centres already have key enhancements on file ready to go.

David_Singleton

It was a serious question. I am interested to know which

Jeffrey Fletcher wrote:

Many features also date back to historical needs and the good old days when NAV sold individual granules of functionality and some of this historical baggage is really no longer required.

I wanted to know which features from granules functionality are now not required?

sriram_venkat

Hi Jeffrey

What i had mentioned is about the RECEIVING check number, check date and the bank on which my customer gives check (Customer's Bank) and you are mentioning something about the fields on the Bank Card.

Hi David: I understand that i need to know more about NAV. But obviously these fields are not there in the Receipt journals. What i mention here is not my Bank and check details. I mean here about the check that i receive from my customer which i want to log those details

David_Singleton

Fields for Check number and Check Date are there. But not for Customers Bank, but why do you want that, I have never heard that request before, so even though you may have a genuine need for it, I can not believe that EVERYONE needs it, so why should it be in standard?

sriram_venkat

Hi David

Wont you record your Customers check number and Check date in your transaction? What will you print in the Receipt journal which you give him as acknowledgement. How will you track if there are some issues in customer payments? Wont you use the customer check number as reference for tracking?

I presume this is a normal feature which everyone will require.

David_Singleton

David Singleton wrote:

Fields for Check number and Check Date are there.

ssingla

The details of the check no. and check dates is posted to bank account ledger entry in IN version. If needed you can customize it to go to cust. ledger entry also.

David_Singleton

The point is that External Document no. is there for a reason, it travels through the whole system and is then navigable. Customer Check No. = External Document no. Check Date = Document date.

There is no need for any customizations.

ssingla

For reanson best known to the accountants the design of NAV IN is different from W1 version. I don't fully accept the modification in IN database but I have learnt to live with it. IN database have fields "Check No." & "Check Date" and when the fields are available, you feel a urge to use and customize them instead of W1 standard field.
Moreover the IN Finance feature instruction manuals includes these fields.

David_Singleton

ssingla wrote:

For reanson best known to the accountants the design of NAV IN is different from W1 version. I don't fully accept the modification in IN database but I have learnt to live with it. IN database have fields "Check No." & "Check Date" and when the fields are available, you feel a urge to use and customize them instead of W1 standard field.
Moreover the IN Finance feature instruction manuals includes these fields.

It wasn't becasue of "Accountants" or laws, but that is for another discussion off line.