When doing the conversion, if there are any open batches in the "INVOICE" module that have cash applied to them, the conversion wipes out the payment tab details. Just wanted to give you a heads up - that either there should be no open invoice batches when running the conversion, or, any that had payments applied will need to be re-entered once the conversion is complete.

Karen

Hello Karen,

There must be more to this story. I just retested the conversion. Invoices batches that contained Payments were converted properly.

If you have a backup prior to conversion, please double check the invoice batches and try the conversion again.

I didn't perform the conversion. Our sales support did, and it's complete. I don't understand what could have happened, but I'm not going to have him re-convert as we've already re-entered the payment information to those where it was necessary to do so and posted them. I have the original printed invoices which clearly show that payment was applied - then, after the conversion when we went into the batch, those details were no longer there. Could have been a blip on our end. However, it's fixed at our office so I don't think re-converting would be prudent.

Hi Karen,

If you do have a backup prior to the conversion, would you be willing to send it to us so that we can see whether we can duplicate the problem with your data?

I'm sure we have one - and I'll ask Steve to send it to you.

While we were working this morning, someone in AR (printing an overdue receivables report) received an error that said we had interity errors. We took everyone off the system and ran DataCare. It said:

A/R Cash batch 276 transaction count is 27 stored count is 0
A/R Cash batch 276 last transaction is 27 stored is 0
Checking Cash batch 276 ... 2 errors found.

I opened AR and batch 276 said it had 0 entries. When I edited the batch there were 27 entries inside. I closed the batch and then the batch said 27. Ran another integrity check and it had 0 errors.

All is running well again.

Perhaps someone's workstation failed as they were saving a cash batch? Let us know if the problem recurs, and whether there's any way to make it repeatable.

Thanks

We love all the new features we have found in Receivables 9.0 and OE 8.1C so far. Now we can see the customer's name on the caller ID & search for him by name or phone # and have him up on the screen before we are finished saying hello. Exporting our customer base with the new formatted fields to our Post Office shipping program will keep the data up to date much more easily.

In CR9 (090511) printing the Cash Batch listing imported from OE 8.1C sorted by entry # seems to give us a strange result after the upgrade. Entry #'s 2-9 jump out of order. Entry #2 goes to entry #12, #3 to #23, #4 to #34 etc. Are there other reports of this tiny problem?

I like the idea of storing the Payment Type in Receivables. Is it possible to import that info in the cash batch from OE 8.1C yet? I haven't found an option for it so far.

Hi Rick,

It may be that the entry number was set as 'left-justified' and thus not sorting properly. Is it just the batch listing report that has this for you? Do other cash batches not from OE show this?

I believe the payment type goes from OE to AR if you use the Direct batch method, but not the Retrieve batch method. There is no option to control this behaviour. I believe we are looking to change this in a service pack to allow the Payment type for retrieved batches too.

Hello,

We don't import any other batches so I can't report any similar behavior.

Regards,
Rick McLeod