Will eConnect import transactions into a batch that is in Batch Recovery?
The short answer is: Yes!
A client asked me this question today and I didn't have an answer, as it is something that I haven't considered or tested before.
The client uses a third party requisition system that is constantly importing batches into Dynamics GP--I believe they are purchase receipt batches. The requisition system can import transactions into GP using two different batch IDs--either the username plus the date, such as "JSMITH20140502", or a single common batch ID, like "IMPORTRCTS".
Since the client has many users of the requisition system, he was hoping to avoid having dozens of different batch IDs to post in GP. But he wondered if he used a single batch, and there was an error in the batch causing it to go to batch recovery, what would happen when the requisition system tried to import more transactions into that same batch?
I didn't know, so I performed a test. Using my Dynamics GP Batch Load Test application, I imported 10 payables invoices into a batch called TEST.
I then modified the distributions in one of the invoices so that they were invalid.
I then posted the batch, forcing it to go to batch recovery.
When a batch is in recovery, GP will not allow you to open or edit the batch.
If I would have recovered the batch at this point, it would only contain one transaction--the invoice with the invalid distributions. The other 9 transactions posted successfully and would no longer be in the batch.
I then used the Batch Load Test application to import more transactions into the TEST batch. I received no errors, and the import completed successfully.
I then recovered the TEST batch.
When the batch was recovered, it contained 11 transactions. The 1 transaction with the error, and the 10 new transactions that I imported.
So, this demonstrates that eConnect, unlike the GP application, will allow you to add new transactions to a batch that is in recovery.
Is this a bad thing? Or a good thing? I don't know that it is either bad or good, but it means that you should design your workflow accordingly.
This particular client wanted to automatically post his batches using Post Master Enterprise. But if he uses a single batch and it goes to recovery, transactions will pile up in that batch until someone uses the Batch Recovery window to recover the batch--since eConnect will import transactions into a batch that is in recovery.
Anyway, this is one of those things where you don't know the answer for sure until you test it and confirm how GP or eConnect behaves. This particular behavior is consistent with other eConnect "differences", such as:
Will eConnect import transactions into a batch that is being edited in GP? Yes!
Will eConnect import transactions into a batch that is being actively posted in GP? Yes!