Creating a journal temporary before posting it.

NavStudent

Hello, in a lot of integration you have to validate a couple of fields on gen journal before you post it. You are not inserting the genjournal etc. then youc all runwithcheck.

My question is this. You run some validation, which builds this temporary dimemsion using DimMgt codeunit. There is no way for me to get these dimensions. I have to manually create the tempJnlDim and populate it.
So I would like to ask, am I missing something? Most of posting routines, the dimension come from documents, which come from Master tables, and they are not validating any genjournalline fields when they post, which is another story by itself.

So why isn't MS making it clear on how to create a genjournal through code?


I would like to see an example code on how to post a genjournal.

Here is some starting code.

clear(genjournalLine);
genjournaline.validate("Posting Date",workdate);
genjournaline.validate("Document No.",'HAH');
genjournaline.validate("Account Type","Account Type"::"G/L account");
genjournaline.validate("Account No.", 10000);
genjournaline.validate("Amount",100);
genjournaline.Validate("Bal. Account Type","Bal. Account Type"::"G/L account");
genjournaline.Validate("Bal. Account No.",10000);
//how do  you populate TempJnlDim without manually populating it with
//default dim or what not. Shouldn't there be a function on
//genjournaLine called GetTempDimensions????
GenJnlPost.runwithCheck(genjournaline,TempJnlDim);

Same applies to Item Journal, job journal, resource journal, FA journal, warehouse journal, bom journal.

Dave_Cintron

NAV code is definitely a self study topic, and dimensions is not one of the easier studies. You need to go through the functions in codeunit 408, Dimension Management, and see how these are used by codeunits 12, 80 and 90. I don't think there's an easier way.

NavStudent

CU 12, 80, 90 transfer the dimension from documents or from journals. So the dimensions already exists in the table.
For temporary journals, there is no place but to manually create the dimensions.

I'm sure you've written some code that creates a temjournal and posts it.
Would you be kind and post the code on how you create the TempJnlDimension?


Or anybody for that matter.

NavStudent

Can somebody post a code on how they create a temporary journal and how to post it with Dimension?

Anybody?

DaveT

Hi NavStudent,

I can understand the attraction of using a temporary record but I think the sub-tables (such as dimension) will let you down. Unless you create a whole posting routine for the journal it will not "see" your temporary dim tables. What I suggest is to create a batch for this posting and write the line to the batch. You would not have to commit the line so if (when ) the posting routine hits a problem it will roleback the entire posting.

NavStudent

That's wrong way to post journals.
What if somebody inserts other records into the batch.
You then have to deal with SIFT tables being populated which is not needed.


So I'm guessing nobody here ever created a journal line and posted it with dimensions?

Dave_Cintron

As I've said, every posting codeunit does this! Look there and learn.
Example from Codeunit 80:

The dimensions have already been put into TempDocDim, when suddenly:

ResJnlLine.INIT;
ResJnlLine."Posting Date" := "Posting Date";
ResJnlLine.x = y etc., etc.
(notice there is NO insert here)
TempJnlLineDim.DELETEALL;
TempDocDim.RESET;
TempDocDim.SETRANGE("Table ID",DATABASE::"Sales Line");
TempDocDim.SETRANGE("Line No.",SalesLine."Line No.");
DimMgt.CopyDocDimToJnlLineDim(TempDocDim,TempJnlLineDim);
ResJnlPostLine.RunWithCheck(ResJnlLine,TempJnlLineDim);

NavStudent

NavStudent wrote:

CU 12, 80, 90 transfer the dimension from documents or from journals. So the dimensions already exists in the table.
For temporary journals, there is no place but to manually create the dimensions.

I'm sure you've written some code that creates a temjournal and posts it.
Would you be kind and post the code on how you create the TempJnlDimension?


Or anybody for that matter.

And the above quote states the exact thing.
One of main points in Navision is to validate the fields so business logic is run, if you are not doing this, it's as good as writing sql statements and asking thirdparty to insert into the journal table directly, and let Navision post it.

DenSter

So what you need to do is create the journal in the actual table, validate all the right fields and post it from there, that should transfer all the right dimension values aotumatically. Give it a Template/Batch combination that you create and remove on the fly.

NavStudent

NavStudent wrote:

That's wrong way to post journals.
What if somebody inserts other records into the batch.
You then have to deal with SIFT tables being populated which is not needed.

It's also not good for performance reasons, Locking. etc

DenSter

DenSter wrote:

Give it a Template/Batch combination that you create and remove on the fly.

Not real big on reading yourself are you

It's the right way to post journals, because that's how it's done thoughout the system. Journal tables shouldn't have any SIFT. If your really worried about other people entering lines into your batch, you could always restrict certain (types of) batches.

Tell me exactly what is bad for performance about this solution?

DaveT

Hi Navstudent,

If you that worried about other people using the same batch you can filter to just your line no. and post this it that way - just as it works manually.

NavStudent

Even if you temporary insert it, other people will still see it. Navision does dirty read. And SQL will escalate locking the journal line table. A person who is doing payment journal won't be able to do anything.

So you are telling me that everybody here inserts the journal line into the table. The grabs the journal dimension that it creates and posts it with run with check?

I'd rather create the dimension manually than use this solution. If you are posting 20000 lines, you won't have the luxury to insert into a table that you don't need to.

DenSter

There are a million ways to solve problems, and if you don't know all the details you're not always going to suggest a proper solution. If you don't give us all requirements, don't tell us that suggestions are wrong. You can't come in here, ask advice, and then slam everything everyone says, feeding additional details that we didn't know about to tell us why something won't work.

Creating the journal and posting it is the standard accepted way of posting journals programmatically. If you manage the template/batches well, it's not going to be a problem. Now with the transactino volume that you are now talking about, that might become a problem, it might not be, you can't tell ahead of time.

I seriously doubt that creating 20000 records in memory, plus all related dimensions is the right solution either, and you know it isn't either or you wouldn't ask for help. I would probably start thinking more along the lines of storing the journals in the table, locking certain template/batch combinations, and letting a NAS post the journals.

Anyway, this is my last contribution to this thread, good luck in figuring this out.