Jason,
Might I suggest, as a good operating practice, that whoever posts batches make sure they look at the posting period for each batch on the grid on the post transaction screen and uncheck any batch in that grid that appears to have an incorrect posting period so that batches with a faulty posting period do not get posted.
Here are the update queries you will have to run in order to fix up the posting period. xxxxxx is the batch number in question and yyyymm is the correct posting period.
update ardoc set perpost = yyyymm where batnbr = 'xxxxxx'
update artran set perpost = yyyymm where batnbr = 'xxxxxx'
update aradjust set adjperpost = yyyymm where adjgbatnbr = 'xxxxxx'
This, of course, is assuming that the receipt that was posted incorrectly was in its own payment application batch or that all the items in that payment application batch had the incorrect posting period. If this receipt was part of a payment application batch where the other items in that batch belonged to the specified posting period then you can run the above queries because all items in a batch must have the same posting period.
Because the GL side has already been posted, you cannot simply run a similar query against gltran. This is because accthist has already been updated based on the original posting period. So, you only option, for the GL side, is to create two new GL batches. the first one will credit cash and debit receivables for the amount of the payment and will be posted to the original posting period. The second batch with debit cash and credit receivables for the amount of the payment using the correct posting period.
If you do not care about the posting period on the AR side, you could elect to not perform the 3 update queries and just create the 2 GL batches.
Also, running the 3 update queries will leave the batch header record (in the batch table) out of sync (posting period wise) with the AR document and transaction side (because we cannot change the posting period on the batch table since the gltran will still have the original posting period) but this will not cause any issues with any of the reports.
The bottom line is: once a batch is posted, messing around with the posting period is not something you should do without fully understanding the implications of that action. Had the batch not been posted to GL yet, you could have run the 3 update queries, turned on initialize mode, opened the batch on the GL side (initialize mode allows you to change the module to AR so that you can access the batch) and change the posting period.