Post several different documents

skalp

Hi all,

I need to post several different documents at once, for example Sales Invoice, Purchase Receipt, Invoice, Payment Journal etc.
I can do this by calling different codeunits for posting according to the document, but I want to be sure that all the documents are posted successfully.
How can I do this? What is best practice for posting several documents at once?

Thank you,

thankesh

I need to post several different documents at once, for example Sales Invoice, Purchase Receipt, Invoice, Payment Journal etc.
I can do this by calling different codeunits for posting according to the document, but I want to be sure that all the documents are posted successfully.
How can I do this? What is best practice for posting several documents at once?

Yup! You can do posting at once by calling the relevant code units functions. But, I want to know why do you want to do it? It is not an advisable one.

skalp

You see, I’m doing some "temporary posting" from different documents, and doing some processing.
After I finish processing, I must Post those documents, this time for real.

Yes, I know that is not advisable thing to do, but I cannot let customer post one by one document.

I want to hear from you, maybe someone has done something like this, maybe it is really crazy, and every opinion is valuable to me.

thankesh

I can do this by calling different codeunits for posting according to the document, but I want to be sure that all the documents are posted successfully.
How can I do this? What is best practice for posting several documents at once?

By assuming :roll: that your code units which posts all the values have been hit into the relevant tables, We can check the posted documents through lots of ways. We can do it by

1. History -> Posted documents -> Navigate

2. Finance -> History -> Registers

& so on

skalp

thankesh wrote:

By assuming :roll: that your code units which posts all the values have been hit into the relevant tables, We can check the posted documents through lots of ways. We can do it by

1. History -> Posted documents -> Navigate

2. Finance -> History -> Registers

& so on

Yes, yes thankesh i know all of this, thank you.

The point is how best to post all the different documents, or if some fails to post, not to post any of the documents, you know. Because when you run codeunits for posting, if some document posts well, and after that second document doesn't post, even you receive error, first document is posted, and in history, which is not good.
rollback is what i'm concerned of.

thank you again.

FDickschat

You would have to change all posting CUs and add some kind of testpost function. Take a look into the French DB. They have such a functionality in the G/L Area.
You will need to look at all COMMITs in the database to see whether they might be touched by the posting function somehow (a standard 6.01 DE has 540 commits) and add an "If not TestPost" to them.

But even if you do all this then during the real post some user might come in and do something unexpected and your posting job is stopped with an "another user..." error and again you have some docs posted and some that aren't although the test post was successful.

Additionally you will create veerrryyyyy long running processes which will block other users from their work.

If you ask me: Don't do it. Instead create a processing log so that you know exactly per document what the posting status is, which docs have been posted correct, which have created errors (and what the error was - GETLASTERROR) and which have not been posted at all. Set up a Jobqueue and have a NAS process these jobs.

skalp

Thank you FDickschat,

I agree with you totally.

The thing is that I need posting results for processing again. See, I’m doing test post, then segregate the results of test post, then real posting, segregate again the results, this time real G/L Entry, real VAT Entry, real posting documents etc.

But I will definitely propose some different approach, semi-automated.

Also, the Batch posting of Sales Documents for example, is giving us the same, how many documents are posted / total documents, so I guess that’s the way the NAV is working and the way that you propose.
Logging actions/posted documents are something that I will need for sure.

Thank you very much again.

Regards,

kine

Question is - what you want to solve with this? That users are not doing their job correctly? Are there often some problems? etc etc.... Try to define the main reason for that, do not solve only the effect....

Savatage

I agree with Kine.
If a request sounds Bizarre (& this one kind of does) there is probably a better way to accomplish this task.
What problem do you have & what is this solving?

skalp

Savatage wrote:

I agree with Kine.
If a request sounds Bizarre (& this one kind of does) there is probably a better way to accomplish this task.
What problem do you have & what is this solving?

Ok, this is what customer need:

1. Not to post Sales, Purchase Documents, Journals, etc. directly. Instead of posting, just give me the G/L Entries that posting will produce. I have done this, in posting routines after all the processing I’m forcing ERROR and in the temporary table I keep the G/L epilog.
2. Some processing is done with this “temporary” G/L Entries, and afterword if everything is ok proceed with real posting, but this time do it automatically, customer doesn’t want to go document by document, journal by journal and click post. So this time post for real. But, if there are some errors they want to correct the errors (wrong posting date, dimension, amounts, etc.), do a temporary post again, and then continue with real posting.
3. The situation is more complicated when they want to group all the postings into one custom document (basically I keep several g/l entry no. in this document)

This is the desired scenario, but if it’s not applicable, we must change something, but at the end, result should be the same.

They need this only because they keep that customs documents and because reversal in NAV is too complicated for them (creating Return Order, Credit Memo, etc.).

So, what we are trying to do is put this strange scenario into NAV logic, that’s it.

Thank you all for participating and sharing your ideas.

Savatage

skalp wrote:

Some processing is done with this “temporary” G/L Entries, and afterword if everything is ok proceed with real posting,

They need this only because they keep that customs documents and because reversal in NAV is too complicated for them (creating Return Order, Credit Memo, etc.).

1.so the potential g/l entries are being altered. why? what's wrong with them.
2.sounds like some training on how the system works solves this problem instead of altering the system and how it works.

skalp

Savatage wrote:

1.so the potential g/l entries are being altered. why? what's wrong with them.
2.sounds like some training on how the system works solves this problem instead of altering the system and how it works.

1. if they see some wrong amount, or wrong posting date, or something, they will change it in the document, do a temporary post, see again the results, and if everything is ok then post for real. you see, we are trying to make easier reverse procedure.
2. i agree with this, but they need simple reverse procedure, that's it.

thank you Savatage

kine

I think that there is no problem the "pre-accounting" part when they see the potentially resulting entries (I did it too for our customers, but mainly for journal postings). The problem is "posting different documents as one (together)". This is the biggest problem and I recommend to find different solution like training or other tools.

Savatage

skalp wrote:

1. if they see some wrong amount, or wrong posting date, or something, they will change it in the document, do a temporary post, see again the results, and if everything is ok then post for real. you see, we are trying to make easier reverse procedure.

The thing I can't get passed is that why can't they see the error the first time before "temp" posting it.
Why not use a "test report" like many journals already have? The report can point out possible errors.
What make you think they will catch every mistake the 2nd time if they didn't see it in the first place?

and if by error, they post the 2nd time & then realize "oops" I made a mistake then they will have to go thru the reversal steps anyway. So they will have to learn them. So if they have to learn them anyway incase they make a mistake (and it will happen eventually) then this mod doesn't make sence to me, but that's my opinion. But good luck with it

skalp

Yes Savatage, I agreed with you completely, that’s the way NAV works, that’s the way customers should work.
But, at the end, what customer needs is an easy reversal process. For example, if they put wrong Posting Date, NAV will not give an error, because it is not an error, you can put whatever Posting Date you like.
And now for just one wrong Posting Date they should make at least 2-3 documents just for putting right Posting Date. This is an example; they may spot wrong Dimension, wrong Vendor Invoice No., etc.
With this “temporary posting” we are trying to reduce possible errors (from business perspective, not NAV errors).
They see NAV very unpleasant to work with for this type of changes and that’s why we are trying to do something about it.

Thank you,

Savatage

skalp wrote:

NAV will not give an error, because it is not an error, you can put whatever Posting Date you like.

If the posting date is always today then you can do
OnAfterGetCurrRecord-trigger of the Sales Order form: (for example)
IF "Posting Date" <> TODAY THEN
"Posting Date" := TODAY;

you can also set the allowable posting dates from & to
in the g/l setup
from 06/01/2010
to 06/30/2010

and this will only allow posting within this range or whatever range you define.

this wil stop most wrong postings or at minimum keep it in a desirable range.
we change it the first of every month