Should website customers be actual customers?

Dakkon
Member Posts: 192
In short I'm working on an implementation for web ordering with 2009 R2 classic Nav and I'm torn between implementing the web customers as actual customer records vs creating a separate custom table to store the records. Certainly making them full customers provides a lot of benefits, but it also means the customer table is going to skyrocket in records. Does anyone know of some really good reasons why making such customers actual customer records in Nav would be a bad idea? I admit I'm a bit adverse to dumping thousands of web customer records into the table, but it's not like the data can't be easily filtered to remove web customer records if a user didn't want to see them. :-k
Thad Ryker
I traded my sanity for a railgun
I traded my sanity for a railgun

0
Comments
-
Honestly I do not see any reason in creating a separate master data, this would mean duplicating for instance all the validation logic.
Maybe think about filters in customer list to be set up for filtering out web customers when opening it, to reduce long waiting time.
I actually work for an e-commerce end user and in the main company we have about 250.000 customers.* Daniele Rebussi * | * Rebu NAV Diary *0 -
Thanks Geordie, that is good to hear. That was my leaning as well given that being actual customer records provides a large number of benefits. I just wasn't sure if there was any reason I couldn't think of as to why inserting a couple hundred thousand records in the customer table would be undesirable.Thad Ryker
I traded my sanity for a railgun0 -
Is there a difference between the two? Like wholesale vs retail?
We keep ours separate. Instead of adding 100,000+ retail accounts we set up one customer account for web orders and use ship-to's for all the web customers names, addresses, phone #, email, etc.. Each code is the phone number for easy referencing.0 -
That is a very interesting idea. These are indeed retail customers so the numbers will grow much faster than core business customers. Unfortunately given the requirements of this particular project I don't think I can use ship-to records to store the customers. I just want to insure I'm not running into any big gotchas if I make them full customer records. I can't think of any reason why it should impact performance as long as good filters and indexes are used.Thad Ryker
I traded my sanity for a railgun0 -
I guess it all depends on your particular project. If these are potentially one time customers (ie. Amazon.com orders). You could potentially just create the one customer and using a dataports just fill in the ship to fields to get the order out. You never actually have hot save everyone as a separate customer. All the customer info will still be saved on the sales invoice header table if ever needed. Without knowing any details I can only speculate.0
-
Unfortunately we have to be able to save multiple ship-to addresses for the customer records as well as potentially store customer credit cards, so storing them grouped under one customer record would be problematic. Our existing credit card add-on only stores cards against customers so anything other than one customer per customer record would require hacks to the add-on. The users also want to be able to run most of their existing reports against these customers just as if they were any other customer as well as look at ledger entries, order histories etc. If we proceed with making them full customers (which is seeming quite likely at this point) my plan is to embed a filter in the core customer card and list so that they filter the e-commerce/retail customers out and give users a separate card and list for these new customers. That should avoid some confusion for many users though obviously they will still need to filter them out of the reports where they do not wish to see them.Thad Ryker
I traded my sanity for a railgun0 -
One addition: we necessarily had to create every single retail account because one of the requirements was to reconcile NAV customer balances with figures provided by payment service provider.
This was not possible (and not accepted by auditors) using a unique account.* Daniele Rebussi * | * Rebu NAV Diary *0 -
If you have to save multiple ship-to's per customer and credit card info then it looks like creating a custmer is the way to go.
We have added an "Internet Customer" boolean field to our customer cards for easy filtering.
Or you can assign a new salesperson code for these to filter also.
Good luck & happy selling!0 -
Ok sounds good, I was planning on adding a similar flag as well as adding different customer group codes to further differentiate customers from different websites.Thad Ryker
I traded my sanity for a railgun0
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