This post will be used to track the status of known issues in Adagio Receivables V9.0A and other recent module releases.

Adagio Receivables V9.0A (090511)

There are no known issues with the release of this Service Pack. It also adds the ability to import contacts and ship-to addresses, and improves the customer transaction inquiry by allowing you to use a splitter bar to change the relative screen real estate for header and detail information.

Receivables 9.0A requires Ledger 9.0A (2008.03.07) or higher. If you have an earlier release of Ledger 9.0A you must install the current Ledger 9.0A Service Pack or Hot Fix. The Adagio Ledger Service Pack can be downloaded here.

Adagio Invoices V8.1B (090508)

There are no known issues with the release of this Service Pack.

Thanks to people for bringing earlier items to our attention.

I have read that I need to wait for new modules (bank rec, invoicing) to come out before installing the new Adagio receivable 9.0a. I then read that we are to have all the new modules ready to install before i proceed - does this mean that I should not have installed my invoices 8.1B module yet? I have not posted anything in that module yet...
we do not use the JC module (only bank rec/ap/ar/gl/invoicing)


If we choose not to use this invoicing module until the others are released (use the a/r -old instead to enter invoices) can we leave the upgraded module as is?

Invoices 8.1B is completely fine to install now. It will work with Receivables 8.1A or 9.0A. It is specifically the Receivables 9.0A upgrade that you have to wait for, until you have all the compatible releases.

In your case, BankRec is the only other program. Unless you choose to use the new 'accounting date' in AR90A to set a different GL fiscal period than the invoice/cash dates, in which case you'll need the upcoming Ledger 90B to use this feature.

We print and consolidate our g/l batch in A/R. We are waiting for an official Hot Fix. The last note I saw from you said the end of April. I haven't seen it on your website. Please let us know.

Hi, Jackie,

Sorry, that was a 'best estimate' at the time. The service pack is very close and should be released soo. However, I cannot say exactly which day.

It would be best for you to wait for the official release of the service pack. Are you able to do this?

Contact your dealer - they have access to a replacemnt EXE.

Thanks, we will wait for Service Pack. Not pressed to install upgrade.

As we believe that the release has settled, I will "unstick" this posting. If anything further is uncovered, it will be posted with this thread.

Is there an Order Entry upgrade coming out soon. I went to upgrade Accounts Receivable today and it said I needed order entry 8.0 C. Any idea when that will be coming out?

Thanks

Hello ncc,

Adagio OrderEntry V8.1C is currently undergoing final Quality Assurance testing. We are hoping it will be released before the end of July. We understand the frustration at seeing all these cool new features in Adagio Receivables and not being able to take advantage of them yet.

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

Hi Rick,

The order that the entries exist in the retrieved cash batch are the same order that they appear for me on the cash batch listing report.

If you would like to sort the entries within the cash batch in a different way, you can use the new 'Sort' feature (when editing a batch) and choose to sort the entries based on a number of different fields, such as check number, customer, or date.

Hello,

This may be the case but they are not the order they are being entered into OE. We sort them by entry # because most of our invoices are paid on credit cards and we check them against the printed report before posting the batch. Entry #2-9 from the first day are spread out through the report through the rest of the days in the predictable manner first described and they do not correspond to the order they were entered in OE 8.1B or C. This has happened both weeks they were processed in Receivables 9.

Regards,
Rick McLeod

Hi Rick,

Can you make a backup of your OrderEntry and Receivables data prior to running the dayend and send it to us so that we can try and duplicate the behaviour here?

We'll take a look.

Hi Rick,

Is there a reason you are "retrieving" your batch into AR rather than creating it directly? If not, I think you'll find that the direct method of AR batch creation works the way you expect.

The next Service Pack to Receivables will pass the payment method across in the retrieved batch.

Hi Rick,

Certainly I can duplicate the behaviour. But I believe this might be more of an OE issue creating the file, rather than AR retrieving it. But that is not so important.

For now, perhaps the retrieved batch can be re-sorted until this can be addressed.