As per the subject we think we may have found a small issue with Ledger V9.3B and latest service pack installed(in the Company profile the switch "Require batch print before posting?" is checked).

We discovered this morning that if a user is in a sub ledger module and goes into Ledger from that subledger module and prints the batch the status of the batch stays as "Open". And then obviously when they go to post they get the error.

Yet if that same user logs into Ledger from the desktop and then prints the batch the batch status changes to "Printed" and then no issue on the post.

So in the meantime we will just have them log in from the desktop and not any other sub for now.

Maybe we missed something but thought we would post.

Thanks in advance.

I ran into the same issue at a client today, after installing the latest service pack.

In Company Profile, I ticked off the box "Post invalid entries to an error batch", and that did the trick. The "Require batch print before posting" box was already unticked.

Steve

Hi John/Steve,

Thank you both for posting what you found. Can I confirm with either or both of you the precise steps you take to cause the printed Ledger batch to not have it's status change from Open to Printed, I tried a couple of times to replicate this in sample data and in each case the batch status was correctly changed to Printed. Since two independent sites saw something similar, I wanted to follow the same steps as you to nail down the difference.

My steps:
- Ledger was first set to Require batch print before post and also Post invalid entries to error batch.
- In Payables I posted a batch. Then used the Adagio Toolbar to load Ledger.
- I retrieved the batch in GL but did not post it.
- I printed the batch listing from the Edit Current Batch grid (not the Reports menu) to the AdagioV3PDF driver. The status of this batch was changed to Printed

Something did change in this area for the initial 9.3B 2021.01.15 upgrade, rather than the recent service pack (release note below). I am not sure if this in any way is related to what you found. In each of your cases, is the difference you noted as compared to Ledger 9.3A, or the initial 9.3B upgrade? Nothing should have changed in this area between the 9.3B upgrade and service pack. This is for confirmation, since you indicated that this problem started happening in the service pack.

"In order to ensure that the Company Profile option for Post Invalid Entries to Error Batch correctly prevents posting of any entries without errors, it is now required to enable the option Require Batch Print Before Posting to accommodate this. Previously if the batch was not printed, posting would function as if Post Invalid Entries to Error Batch was enabled."

Thanks Steve. Glad we are not the only ones .

A couple of issues with that though. One, did the print status change when you did that? And two, with that "Require batch print" switch unchecked and they happen to forget to print the batch listing they could go right to post and it won't prompt them to print the batch in the first place.

Just curious.

Hi John,

For your second comment, if they did forget to print the batch listing before posting, they could still print it from the Batch Status Inquiry even after posting. Though of course it is ideal to follow the desired steps in order.

Thanks support. Yes they could. Again not a deal breaker obviously but just wanted to point out.

Thanks again.

Hi Support

My issue was not explicitly related to the print status not updating, but I think it is connected. The client had eight open batches they were trying to post, batches 14 thru 21. Batches 14 thru 17 had a print status of Printed and batches 18 thru 21 had a print status of Open.

As I mentioned above, in Company Profile, both the "Post invalid entries to an error batch", and the "Require batch print before posting" boxes were unchecked.

When they tried to post, they got an error that Batch 18 had to be printed first. Nothing posted. There were no errors in any batches and all fiscal periods were open.

When I checked the box "Post invalid entries to an error batch", and went back to post, it worked.

Now here's a really strong clue in my opinion... In Ledger 9.3A it's possible to have both boxes unchecked, but in Ledger 9.3B if you try to do that, you get an error message:

"When 'Post invalid entries to an error batch' is unchecked 'Require batch print before posting' must be checked". Yet 9.3B doesn't complain if the 9.3A data had both boxes unchecked.

Steve

Steve when we were doing the trial and error on this we ran into the same problem. One or both had to be checked. If neither were checked then the error you mentioned above appeared and you could not save the company profile.

As mentioned earlier to get around the issue the client will log in through Ledger from the desktop and not another module and issue resolved.

Would be nice if a hot fix could be released to fix this but not a big deal.

Hi Steve/John,

Thank you for responding.

As I mentioned in my original post (perhaps not well enough), Ledger did not post batches correctly as specified in some situations where both boxes were unchecked. It was decided to not allow this configuration anymore. Thus the reason for that message in 93B for the, when it did not appear in 93A.

This part is intentional behaviour and I don't expect any hot fixes for this.

I recall going through moving data from 93A to 93B and if both boxes were unchecked, then the Post Invalid Entries box would get checked automatically. If this did not happen for you, then this is an error - something must have undid this behaviour at some point in the R&D cycles.

If batches post correctly for you when Post Invalid Entries is selected in the Company Profile, that is what the intended final solution will be.
----
As for this problem only happening when starting Ledger from within a sub-ledger, can you confirm whether this only happens with both options not selected? Or with some other configuration. If there is something for us to fix (apart from allowing both checkboxes as not enabled), we want to be able to replicate this.

Unless Steve beats me to the punch I will have to confirm and get back to you support on this.