Some results may show up that don't appear to include the search string.
However, you can search for the beginning of the address, e.g., searching for 123 main would include results for customers with an address that starts with this.
MICROSOFT DYNAMICS POS QUERY TOOL ZIP
Combining strings (such as a name and a zip code) will return no results.
In general, it is best to start your search with a longer search string and then shorten it as needed.
Due to the cache needing reloaded, the first searches after the database is restarted may take longer and/or timeout.
Note: Attempting the same search again a few seconds later may return results if the first search attempt completed in the background and the cached data is still in memory.
If the search takes too long and times out, POS may show some errors about the off-line database being inaccessible.
In general, the shorter the search term the more results are returned, and the longer it takes for the search to complete.
Beginning of any currently valid email address.
If the phone number is stored with dashes in AX, the search term must include dashes, and vice versa.
Beginning of any currently valid phone number.
Beginning of any currently valid address linked to the customer.
Note: adding an asterisk to the end of the search term will cause more results to be returned (e.g., Dan Zook will only return customers named Dan Zook, while Dan Zook* will return additional customers, including Daniel Zook).
For example, Daniel Zook will return results, but not Zook Daniel.
First, last, or middle name/initial, or a combination (in order).
For example, if account number is 12345, and the operator searches for 1, 12, 123, 1234, or 12345, it will be found.
If any record is found that meets these criteria, it is included in the search results. The search string is compared to the following customer data. They would be found when searching by name the following day.) (The full-text index is only refreshed at night, so new customers added that day will not be found when searching by name on the same day. Lehman's put in place a full-text index on the DirPartyTable.Name field, which improved the search results performance by an order of magnitude.
Lehman's determined that the GETPARTYBYCUSTOMER function was the bottleneck when searching millions of customers.
These sub-functions return a table of party IDs and CUSTOMERSEARCH unions them together into one result set, which is then used to query the customer, address, and contact tables to create the final results table that is returned to POS, sorted by AccountNum, OrgId, or Name. This function calls three other functions that search customer, address, and contact information. POS calls a function called CUSTOMERSEARCH. These functions are created when the database is created using the database utility.
The POS application uses a set of table-value functions on the retail store database.
If you have questions or need more details about any of the below, please reply in this thread and I'll see what I can do for you.Ībout Customer Search in Retail POS (EPOS) Background As I learned more about how search works in EPOS, I built a document that I thought the AXUG community might find useful if anyone is using EPOS in your brick-and-mortar retail locations. It was taking 30 seconds or more for search results to be returned when searching for customers by name, and this would cause EPOS to time out, effectively making search by name unusable. I was recently asked to improve the performance of the customer search function in EPOS. Our customer records number in the millions, and when we went live with AX a few years ago our entire customer database was synced to the retail store (EPOS) database. Lehman's is a multi-channel retailer using Microsoft Dynamics AX R2.
0 kommentar(er)
