Run Accounting Embedded Server

Hi carlos,
Have always wanted to be able to do this instead of going through Unposted Documents, zooming to each one and posting it manually (when posting set to every hour for instance)
regards
steven

Hi Carlos,

+1 for me. Our proprietary ERP did like your proposal

regards
bcahya
http://sistematika.web.id

Committed revision 10187.
http://adempiere.svn.sourceforge.net/adempiere/?rev=10187&view=rev

Regards,

Carlos Ruiz

Steven,
I think you could always tell the Accounting Server to "run now" via the Server Monitor webpage!

I remember Jorg once saying that the "post immediate" should only be used in testing as if posted while the accounting processor happen to be running it might cause issues. I wondered too if that is the case what would happen if two people posted at the same time. As I understand this new "embedded server" functionality is also developer/tester orientated... so I guess we need not worry what would happen if two people used it at the same time. Is Jorg's warning about using such functionality is a production environment still relevant? I guess so?

colin

Colin, it's very uncommon to give access to server monitor to the accountant.

Post Immediate must not be used in production - indeed the help message of the flag states that.

I implemented this with a different approach.
Allowing accounting to run on client - this is, avoiding the call to the server, it's just every client has all the Doc_ classes with the business rules to post documents, so, why to call the server?

With this option an accountant can decide to get rid off completely of the accounting processor (disabling all the accounting processors) - and posting directly from every client (immediate or queue) and reviewing and launching the client processor from the accountant terminal.

I think this can be useful even for big companies, it depends a lot on the way of work the accountant prefers.

Regards,

Carlos Ruiz

>>Colin, it's very uncommon to give access to server monitor to the
accountant.
Yeah, I wasn't meaning as a production use - and it was rather as a "reminder" to Steven as I am sure he knows about the Server Monitor.

As for the embedded service. I see the benefits and as you say the client has the code anyway so why not!?
I was never sure why Jorg said the post immediate was for testing/development and not production but supposed there must be some issue - so I was wondering aloud :) if the embedded server might cause the raise similar issues. The queue is after all only a queue for that one client (user), right? If many users were posting documents then instead of one job doing everything in an orderly one document after the next, the clients (users) would be posting at the same time. As I said I have no idea what the downsides might be but it seemed close to what Jorg warned against with the post immediate and so I just raised the point for consideration.

colin

Hi Colin,

> I was never sure why Jorg said the post immediate was for
> testing/development and not production but supposed there must be some
> issue

I have seen locks trying to post when the accounting server is running.
I saw an implementation where implementor enabled the post immediate and they suffered a lot of lockings of accounting server.

> - so I was wondering aloud :) if the embedded server might cause the
> raise similar issues.

There are three different approaches now:
- server accounting
- embedded server accounting
- client accounting

As the three approaches are managing locking of record I think there must not be problem.
One important thing: server accounting is locking records out of trx, maybe that's the cause of the locks.
I did client accounting to lock records in a client transaction.

> The queue is after all only a queue for that one
> client (user), right?

No, I think is more a queue for the accountant, he can run the client accounting processor to process the queue (or if server processor is enabled it will take care of the queue as normal)

> If many users were posting documents then instead
> of one job doing everything in an orderly one document after the next, the
> clients (users) would be posting at the same time.

If you enable client accounting in [I]mmediate mode - the posting will happen at complete time within the same transaction of the complete. I think this is the scenario I'll apply in my implementations from now on. The performance penaly is really little.

Regards,

Carlos Ruiz

re: Why immediate posting was problematic - A. Locking
aha! okat. thx thanks, that good to know.

> No, I think is more a queue for the accountant, he can run the client
accounting processor to process the queue
But if there is more than one accountant would there be, potentially, more than one queue being committed? ... which is how I was understanding the enhancement or at least when the embedded server enabled.

> I think this is the scenario I'll apply in my implementations from now on.
The performance penalty is really little.
Yeah, I would you think you need to have multiple schemas (and calendars too perhaps) of the accounts for the posting to really have a detrimental impact... or a very high volume of the original documents (shipments invoice etc) anyway. But the actual posting looks to be a fairly light affair, with typically much less complexity than those original documents!

colin

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 15 days (the time period specified by
the administrator of this Tracker).

Committed revision 11683
http://adempiere.svn.sourceforge.net/adempiere/?rev=11683&view=rev
To fix a Client Accounting Processor problem found, it was not updating Posted status on posting failure

Regards,

Carlos Ruiz

Merged 11683 to trunk in Revision: 11694
http://adempiere.svn.sourceforge.net/adempiere/?rev=11694&view=rev

Tony

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 15 days (the time period specified by
the administrator of this Tracker).