This was not meant to replace the Check Distribution report. While I have never compared the two, one difference I know of is that my code will show ALL payments, whereas the GP report will show only checks. Have you tried filtering on the Payment_Type column in my code to include only checks?

That said, I am not sure of the exact logic used by the Check Distribution report, so I am not sure if that is the only difference, if you are finding others and need help tracking them down, please write back with more details.

-Victoria

Thanks again!

PM20100 is a Temporary table, which I try to stay away from when coding reports. PM10200 has the apply information for WORK and OPEN transactions. PM30300 has the apply information for HISTORY transactions. So the combination of PM10200 and PM30300 should be sufficient for the data needed. Are you finding that this view is not giving you correct results?

Out of curiosity, I tested replacing PM10200 with PM20100. In my data set, I get the same number of results with either. However PM20100 has a much larger amount of records than PM10200. So all other things being equal, using a table with less records should make the query faster. I have also seen data issues in the past where records get stuck in PM20100 and need to be cleared out manually for various reasons. Just another reason I would not use this table for reporting if I have other options.

-Victoria

I was just looking at this query and run into a question:
I believe this query lists all payments with documents they applied to.
If you are listing all payments in PM20000, don’t you have to use PM20100 for apply information instead of PM10200, which is for unposted transactions?

Please tell me if I’m going crazy here.
Thank you!

Thank you for responding back so qucikly. My bad, I said I was using your AP_APPLY script and not getting the intended resuilts. I was actually using the Payables_Apply_Detail script whcih was not returning CM’s. I have swithched to your AP_APPLY script and it’s is giving me both CM’s as well as not returning voided transactions.

Thanks for your time and efforts!!

~Tami

I have not tried this myself, but I would think you’d need to add a column for Document Type (to either the payments, or the apply to docs, or both, depending on what you wanted to be able to zoom to) and then use the Payables Transaction Inquiry under Advanced Go Tos.

-Victoria

I am using your AP Apply view in SLB and was wondering if you can or have created a GO To for it. I would like to be able to drill into the original AP Transastion entry winow or zoom.

Thanks!

I think this is what you’re looking for: http://victoriayudin.com/2008/10/22/sql-view-ap-apply-in-gp/.

-Victoria

I’m Noraini. This view is so helpful. Thanks. For your information, one of my customer need to show payments which apply to original document invoice amount and original credit memos amount. How do I get this information?

Regards,
Noraini

The ‘REMIT’ transactions are generated by Dynamics GP during a check run when a remittance needs to be printed, based on rules set up in GP for the payables subledger. Here is one example of when this might happen:
1. You cut a check for vendor A on 1/2/11.
2. You enter a credit memo for vendor A on 1/3/11.
3. You enter an invoice for vendor A on 1/4/11 and apply the credit memo from step 2 to the invoice.
4. On 1/5/11 you do a check run and include all your vendors, or some vendor range that would include vendor A. In the Payables module setup you have the ‘Print Previously Applied Documents on Remittance’ selected. As part of the check run a remittance document for vendor A will be generated by GP showing apply information since the last time you have cut a check to vendor A. It will not use up a check number, but a ‘transaction’ is created for GP to be able to print the remittance.

These remittance transactions will always have an amount of zero and should be fine to ignore, as you suspect.

Hope that helps,
-Victoria

We have been using the query for some time, and from output of the query we are getting:
Payment_Document_Number = ‘REMIT000000000000002′ with Payment_Document_Type = 6 (where 6 is the checks type).
However, all the other Payment_Document_Type = 6 cases are coming always having numeric ids rather then alphanumeric data.

Do you know what type of activity will reproduce this case?

From looking at the data where the $ amount is zero on that row it look like something it may be ok to ignore.
But I want to be able to replicate it to clearly validate we’re doing the right thing.

Thanks much,

Amir

I believe this view will give you what you are looking for.

-Victoria

I need to obtain the voucher number and check information for an invoice that is entered into the Receivings Transaction Entry screen. I know there is information in the PM30300 table, but it doesn’t include the receipt number. Do you have a way to collect this information via the receipt number?

Thanks for all of your posts…they have saved me on a few projects
Jerri

I consider myself to be pretty savvy, but I’m concerned with being directly involved with this issue due to my lack of knowledge of the Purchasing tables. I feel that if I had a little more intimate knowledge I would be able to clear this up if Check Links doesn’t work, but I believe you’re right and we will be calling our GP Partner for assistance with this.

Thanks again!

Thanks for the kind words. I have run into similar situations before. First step is to run check links and reconcile on the purchasing series. Sometimes that will clear up the issue. If that does not help, then you will need to fix this directly in the tables. Since every situation is different, I would advise to get your GP partner or GP Support to help with this, as it can get pretty involved and it’s easy to get undesired results.

-Victoria

I have a question related to Payables Apply. We had a situation where we were applying payments to invoices and received an out of memory error on the database server that is running GP. We were left with a batch that had half applied that we cannot unapply, or recover the batch on.

Now, the batch is no longer available in batch recovery and I cannot find the apply details or distributions in the work, open or historical tables. Is there a way we can unapply this batch so that we can attempt to repost?

Thanks for the update. To my knowledge there is nothing to address this in the latest version (GP 2010). I cannot speak to plans to future versions, as nothing has been released on that.

You can search and vote on existing product suggestions, or suggest your own, at this site: https://connect.microsoft.com/dynamicssuggestions.

-Victoria

Status update and a quick question.

So we’ve gone with option 2 for now for 2 reasons – first to avoid the GP customization needed. Second since we were already comfortable reading that data. We know it’s not perfect, but also believe it would be rare, then we’ll throw in the fact that we’ll be closely monitoring it (send alerts if it happens) + make it simple to manually fix the data – then it’s a non-perfect but pretty practical solution. (in fact all amounts are being read back, even if amounts exactly consume others. Just that when they exactly consume the explicit association to check id is lost. In case one can guarantee a single check per day per seller we could have been deducting the association based on date+seller)

Then another good news is that we are moving to the latest GP code soon.
In which case – since we know this is a missing the option 1 feature in GP – do you have any recommendation or knowledge how to check / where to look up if it’s planned for an upcoming release?
If not yet planned, I would want to file them a feature request for adding it.

Thanks,
Amir