Perhaps there is a simple way to do this, but I’m trying to figure out which query an base entry form is calling to pull data into a grid.
Specifically, I am trying to find the query for Cash Receipts Entry>A/R Receipt>Invoice Selection grid.
We are trying to solve an issue wherein an invoice is populating in the grid for a customer that this invoice is completely unrelated to. The database shows no relation or corruption for this invoice record. We have only seen this once but it’s a very strange problem. Knowing the query might help to solve why this is showing up.
Have you tried doing a Trace? I imagine it is a BO call and not a straight up query. What’s the method it calls?
Is the account part of a National Account.
The account which is pulling the available invoices to select from IS part of a national account, but the customer on incorrect invoice that is showing in the grid is NOT part of a national account.
I can see no relationship between the two customers either.
Or is the invoice set to BillTo another entity?
BAQ on the Erp.InvcHead table looking for where CustNum <> SoldToCustNum
I think its CashRec BO and CashRecGetInvoices. Good call on the BO call not a query.
The invoice is set to bill to another customer, but the Bill To is a separate customer from the one we are having this issue with.
So looking at the code in the back end the only thing I can think of is, if this Customer is setup as a BillTo or PayTo for another customer? Can you check the Customer Record? (National Account)
The code in the back end will list all invoices for any customer which is set as the PayFor of the given
Looking at the customer, I can see that the customer against which the invoice was generate is not in a national account. The customer that is wrongly pulling this invoice as available to pay against IS is in a national account. When I look at that national account, the first customer is not in the listed.
Which table should I be able to find the PayFor indication in, if you don’t mind sharing?
Not sure if this helps, but try using SQL profiler to see what tables are being hit. A bit of a sledgehammer approach, but it gives you a different angle to look at things from.
A variation on the sql profiler is the sql trace flags. You can turn on in the client, monitor the sql calls being made on behalf on that client. Lights up in PDT as well. Pretty useful tracking down the ‘why is just this client slow’ issues.
We have changed the UI and doc and feature a lot over 10.1.400 to 500 to 600 so mileage varies depending