So, for example, if you ran the AP year-end close process and had not posted all of your 2011 payables transactions yet, the ‘amounts since last close’ will include whatever 2011 transactions were posted after the close, just as the label suggests. The AP and AR subledger year-end close is optional and can be done at any time, and about the only thing it does is update the ‘amounts since last close’, ‘year to date’ and ‘last year to date’ statistics. Take a look at my year end close blog post and the discussions (as well as the comments) there about the AP and AR subledger year-end close. I really wish MS would just take those options out, all they do is confuse people. Unfortunately, ‘Amounts Since Last Close’ are not necessarily going to match the calendar year and that is expected behavior. Also, consider running the ‘historical aged trial balance’ instead, that may have better results. It’s been years since I looked at SBF, I don’t have it installed anywhere or have any customers using it anymore, so I cannot check, but if there is a check links option in there, I would try that to see if it fixes anything (make sure to make a backup first). Again, I would not expect a service pack to fix it, this is more of a data issue. This is definitely not the case in Dynamics GP, there you can select invoices using the invoice numbers.Īs to your other question, there may be data that didn’t get posted properly, difficult to day without looking at it in a lot more detail. I am not sure if anyone is offering customizations for SBF anymore, since it was discontinued a long time ago. And I am not aware of easy way to “change” this. I do not think a service pack will address this. The voucher showing instead of the vendor invoice number is something I remember from one of our SBF customers that we converted to Dynamics GP. Sometimes we just have to support it as best we can. I apologize if this makes little sense as I don’t really use GP nor am I a financial person. Basically we need to know how to either delete the whole thing or force it to apply to the credit card in the initial step. The posted status in PM10200 is 0 and DCStatus in PM00400 is 2. However it does not show up when she goes to pay the credit card. When she trys to apply it to a payable document it tells her that it’s already fully applied. “Go into the Manual Pymt screen.enter pymnt number (I use vendor name and invoice #), pick the checkbook I want to use (credit card) then choose which card from the dropdown, fill in doc # and copy it to comment, fill in amount to apply, click on distribution tab and copy the doc # info into those two lines after verifying code numbers are correct, go back to first page and click on the apply tab, choose open invoice to apply the payment to, go back to first page, verify all information is correct ant click on post.” The details of the transaction are as follows (written by the user as it’ll probably make more sense than if I try to explain it). We have a manual payment in GP 2013 that appears to be hung up. ,datediff(dd, coalesce(ph.DOCDATE, p.DOCDATE) Note that if you are using the POP module this will still return nulls for the dates from invoices posted in POP and not PM. I didn’t see this before replying to the previous message – try this, I changed your code around a bit and my SQL editor makes all the special words lower case. WHERE TRXDATE BETWEEN AND GL105.ACTNUMBR_3 = ‘2000’ LEFT JOIN RV_GP.dbo.PM30200 PM ON GL20000.ORDOCNUM = PM.DOCNUMBR AND GL20000.ORMSTRID = PM.VENDORID When I query from PM30200, I’m getting blank records for invoices that are open/unpaid. Question: Is there a single table that has the Document Date for invoices regardless of whether it has been paid? PM20000 is for open documents and PM30200 is for paid documents.Īsking because I’m trying to measure the $ of invoices that hit our GL each month that are from the prior month. MC020103 – Multicurrency Payables Transactionsħ – Scheduled Payment (thanks to Dennis Sisnarine for this)ġ0 – transaction being entered for the first time before it has been saved by the userģ0 – transaction that is currently posting (realtime)ĥ0 – transaction that has encountered an error during postingĦ0 – transaction that has been saved previously and had a status of 20 and is now being edited by a userħ0 – transaction that has been posted previously in a recurring batch that still contains unposted transactions is now being edited by the userģ – Unposted PM80100 – Batch Headers (includes approval information) PM30600 – GL Distributions for Historical Transactions PM10100 – GL Distributions for Work and Open Transactions PM00204 – 1099 Period Detail (only in GP 10.0 and higher)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |