There are several things that you could do depending on your SL rights and availability of a SQL tool.
I have to start by asking for some more detail.
a) Did this batch introduce new cash or were you just applying former payments and/or credit memos to invoices? In other words, did this batch have a non-zero control total? It sounds like it did since you said it exists on the GL side.
b) Do you use Cash Manager or Bank Reconciliation?
If the answer to question a is yes the batch introduced new cash and the answer to question b was no you do not use one of these modules then the following applies.
1) Since the batch is not yet posted to the GL, you, or a user with initialize mode rights to the GL journal entry screen, can enable initialize mode, open that screen, change the module to AR and edit the posting period of the batch. While this action will fix the GL side, it will not fix the AR side so the transactions of this batch will still show under the original posting period on any AR reports but the GL side will be correct. If you are OK with this limitation then this is your easiest choice.
2) If you, or someone, have access to the SQL Server Management tool such that a set of update queries can be run against the various tables affected by the batch. Here are the update queries that need to be run where xxxxxx is the batch number and yyymm is the correct posting period and YYYYMM is the incorrect posting period.
update ardoc set perpost = yyyymm where batnbr = 'xxxxxx'
update artran set perpost = yyyymm where batnbr = 'xxxxxx'
update aradjust set adjgperpost = yyyymm where adjbatnbr = 'xxxxxx'
update ardoc set perclosed = yyyymm where perclosed = YYYYMM and custid+doctype+refnbr in (select custid+adjddoctype+adjdrefnbr from aradjust where adjbatnbr = xxxxxx)
update gltran set perpost = yyyymm where batnbr = 'xxxxxx' and module = 'AR'
update batch set perpost = 'yyyymm where batnbr = 'xxxxxx' and module = 'AR'
The above update queries need to be done with caution and accuracy as they can make a mess if you do not enter them correctly. It is suggested that each one of them start with
begin transaction and end with commit transaction where you execute the begin transaction line and the update query but not the end transaction line and see how many records are affected and then execute the commit transaction line if the record count seems reasonable. The ardoc update should have a record count equal to the number of payment documents. The artran update will likely be double that document count. The batch update should only affect 1 document. The gltran update can vary depending on the number of unique GL account/sub-accounts involved in the payment batch. The aradjust count should equal the number of invoices having the payments applied to.
If you are not comfortable with SQL update commands then I suggest you go with option 1 realizing the AR reports will still reflect the wrong posting period. If you use Cash Manager or Bank Reconciliation then let me know and do not attempt option 2 without additional information as those modules are also affected by a payment application batch.
