Hi All,
We are planning our Nav implementation with a Microsoft Partner and will be integrating NAV with our Housing system which has SQL backend. The customer payments will be entered in the Housing system which will be imported into NAV. It was surprising the NAV Partner mentioned that we should not import customer level transactions into NAV. He said the payments will be imported against the property dimension, instead of customer dimension. In the Housing system customer transaction table the payment is against both customer and property.
I asked the MS partner why we should not bring transactions based on customer_id and he said that it will be a lot of data and we should not create a dimension for customers.
I'm confused why we should not create a customer dimension as the transactions will be same whether its customer based or property. Also what in the future finance wants to create customer based reports.
Please advise whats the best approach as I understand NAV is a robust system and can handle a lot of transactions.
Thanks
Jag
*This post is locked for comments
NAV can be integrated with other system either by importing data in .txt,.csv or .xml file
The data can be validated in Navision after import and then only get posted
Now question is how the entries happening in Housing system and how it will get linked with Navision.
1) Are you receiving payment in full against the invoice or is it partially paid ?
2) How the invoices are getting generated from housing system ?
3) What will be the co-relation between NAV and housing system for invoice/payment ?
May be you need to think more scenarios by looking at both the system
It will not get duplicated unless and until user punch manually same entry or coming from any other system apart from housing system.
You need to analyze it more with partner and try to find out where it will get duplicate/stuck/problems.
Yes, the Primary customer account data is held in the Housing System. The payments are also received in the Housing system. We do not intend to type the same data in Nav but import the data into NAV from the housing system. We can write SQL query in Housing System to pull only the desired columns to match the NAV fields.
Regards,
Jag
Hi Jag,
Is data for customer is coming from some other system also ?
Or if user is punching the same data in Navision ?
The only reason the partner provided is that they do not want to duplicate the customer data in NAV.
Regards,
Jag
Hi,
It is time you can talk to partner and brainstorm for data import for other system.
Mutually you will definitely find solution.
I suppose you need to import the data also by a customer itself (not customer "dimension"). Dimensions are analytical breakdowns of the transactions whereas the customer is treated as a separate Master Record as Raokman mentioned, with its own card and related settings.
If you need to process accounts receivables and send invoices to each particular customer from NAV, you would need to have a mapping between Customer IDs in Housing system and NAV system, and then book the payments to certain customer cards in NAV. There is no need to create a "dimension" for customer and fill it with values.
I'm confused about calling a customer a "dimension".
A customer may have dimensions associated with it, but in and of itself it is a Master Record, not a dimension associated with some other Record.
Is there maybe some issue with importing customers that aren't set up already in NAV? Creating Customer Cards on the fly as it were, or creating a routine to synch the customer masters between the two systems?
I think it is high time to have a big talk with your partner before moving forward. Otherwise you will end up in a conflict with the partner.
Completely Agree with Tharanga,
This answer should come from implementation partner.
Partner should give you excel template in which how they want to get data from other system and can program according to format in Navision.
Actually that answer should come from the partner. I think it is best to ask the valid reason from them before moving forward. At the end of the day you will be using the system and you should be 100% happy about the solution implement.
Sohail Ahmed
2
mmv
2
Amol Salvi
2