Oracle GL Interface API General LedgerPlease find an API for creating Journals in Oracle General Ledger ( GL ) .I had developed this API in year 2002, and I have used this for three of my clients. The idea behind this API is that you do not need to program for:- 1. Inserts to GL Interface ( GL_INTERFACE ) 2. The validations required for Oracle GL Import 3. Submission of GL Import Features of this Oracle GL Interface API are:- 1. It will ensure that the credit equals debit 2. It will submit GL Import when parameter p_submit_gl_interface is Y For the source code for these API's click on the links below:- GL Import API Package Header GL Import API Package Body Usage of this API DECLARE BEGIN xx_import_xfer_gl_iface_api.transfer_to_gl (p_sob_id => --Set of Books Id ,p_batch_header_id => --header id of your feed ,p_trx_header_id => --sub header id of your feed --or leave this to be the same as above ,p_trx_line_id => --line id of your feed ,p_date => --effective date of the journal ,p_currency_code => --currency code of the journal ,p_amount => --journal line amount ,p_dr_account => --GL CCID of account to be credited ,p_cr_account => --GL CCID of account to be debited ,p_journal_name => --Journal Name to be created ,p_header_description => --Journal Description to be created ,p_line_description => --Journal Line descriptionn ,p_success_flag => b_success_flag--boolean returned to show if errored ,p_first_record_in_batch => v_first_record_in_batch --pass Y for First Record in batch ,p_submit_gl_interface => v_is_last_trx_line --Pass Y submit for last line of batch --when Y it will submit the GL Import ,p_gl_user_je_source_name => --user_je_source_name ,p_gl_user_je_category_name => --user_je_category_name ,p_trx_number => --trx_number ); END; For any suggestions or questions, please post a comment |
posted by Anil Passi at 6:08 AM
Comments on ""
-
Anil Passi said ... (4:36 PM) :
-
Anil Passi said ... (8:50 PM) :
-
Anonymous said ... (5:09 AM) :
-
Anonymous said ... (6:42 PM) :
-
Anil Passi said ... (9:07 PM) :
-
Anonymous said ... (11:38 PM) :
-
Anil Passi said ... (6:08 AM) :
-
Anonymous said ... (12:50 PM) :
-
Anonymous said ... (3:08 AM) :
-
Anil Passi said ... (4:35 PM) :
-
Anonymous said ... (1:32 PM) :
-
Anonymous said ... (1:33 PM) :
-
Anonymous said ... (2:54 AM) :
-
Anonymous said ... (1:41 AM) :
post a commentHi Vikas,
Good you asked this question. All that this API does is to provide a wrapper around the GL_INTERFACE table. APIs are useful when you wish to code your business validation just once, whether called from Pro*C, or Concurrent Program or from Oracle Form or a Self Service Framework screen.
Using an API's you can centrally implement the Business Validations for all your GL Interface feeds.
For example, one of my previous Financial Services client had approx 20 odd feeds into GL_INTERFACE. It wasn't a good idea to program the validation & insert logic 20times. Hence I implemented this approach, i.e. do it once, and use it as many times. If business validations change for your client, you will simply need to amend the API, rather than amending all your feeds.
Hope this answers your question.
Thanks,
Anil Passi
Hi Vikas,
You are spot on there, for both your points.
a) The example of custom validations could be their Descriptive Flexfield Values. Although one can argue that GL Import can be run with DFF Validation mode, however if your GL Flexfields have a value set with Where/Order By clause referencing a block.field bind variable, then GL Import will error with "APP-00812 Cannot read value from field lines.accounting_flexfield". Hence, in such cases, you have no choice but to run the GL Import without the DFF Validation mode, and hence the need for custom validations.
b.) Yes, the GL Validation information is reported in the concurrent log of the GL Import. This isn't always very user friendly. For example, for one of the financial services clients, we developed a Receipt Handling Functionality that was a bespoke process and would redirect the receipts either to AR or to Treasury or in exception queue, kind of a Triage. Although the business users may not initially be aware the transaction against which such receipt needs to be reconciled, yet they wanted the "control account entry" for Receipt to be transfered to GL straight from the Receipt Handling process. This GL control account entry was then reversed by actual account when the receipt transaction was eventually reconciled. The idea behind doing so was to make receipt visible straight in GL( i.e. for cash flow balances...). In this scenario, there was a need to send the Receipt straight to GL from the click of a button. TO make this user friendly, this API was developed so that users knew the problem upfront.
Although, in circumstances where million plus journals are to be imported within couple of hours, the common sense should prevail for not doing validations twice (once by our API and next by GL Import ). But in most other cases of low volume interfaces, I will prefer using the API based approach.
Thanks,
Anil Passi
Thats a great code very help full
Thanks you so much
Hi Anil
I would like to utilize the code you have kindly shared to create entries into the GL. I am new to Oracle Apps. I was hopeful that you could give me some guidance. I need to post GL entries from one set of books to another when AP checks are written. I am going to tie this to the AP check RDF. I am looking at the procedure call to create the inital GL entry and am at a bit of a loss on where to find some of the data to populate the call. For example: p_batch_header_id => --header id of your feed
,p_trx_header_id => --sub header id of your feed
Any help would be greatly appreciated.
Hi Susan
Those ID's are in the context for which I developed my code.
However, in your case, you can pass
batch_hdr_id=>CHECKRUN_ID and trx_hdr_id=>CHECK_ID
Thanks,
Anil Passi
Thanks for the input. I am very new to this and appreciate the help. I have been a pl/sql developer for some time but am new Apps. My context will be to execute this in the after report trigger for an AP check batch or a single AP check. So if I am running this in a batch, will I call this interface in a loop to perform a call for each check in the batch passing a Y for p_first_record_in_batch for the first check in the batch and a Y for p_submit_gl_interface for the last check in the batch? What would the call look like if this was a single check?
Yes, you are right, if there is just one record in the batch, then you will pass Y for p_first_record_in_batch and also Y for p_submit_gl_interface
Hence before entering the loop you will need to wok out the count of records in your batch, so that you know when to pass Y for p_submit_gl_interface
Thanks
Anil Passi
Great, I have one more question.(We have a consolidated AP account that all of our companies write checks against for their expenses, then at the end of the month each company reimburses that company for the checks written against their account). So here is the accounting I want to perform. I will write a batch of checks that I want to generate a receivable for each check to the GL, I want the balancing entry to be one transaction reducing cash by the total of check written in the batch. What would be the best way to structure this using the GL API code?
Thanks so much for your insight on this.
Sue
What should I pass in to the call for p_trx_number? Is it required? Can it be the same as p_trx_line_id?
Hi Susan
Please pass to TRX_NUMBER the same value as that for TRX_HEADER_ID
Regarding your other query, on accounting, I must admit I haven't worked out your requirement fully.
It appears you want one journal per batch, per Org Bank Account. Correct ?
Thanks,
Anil Passi
PS:- You may email me a requirement document on anilpassi @ gmail
dot com, so that I fully understand your requirement on accounting front.
I wish to know if there is any way by which we can control the output of GL IMPORT prog. I am transfering transaction from one SOB (Source SOB) to another(Target SOB). I wish the Transaction from Source SOB to come to Target SOB with respect to DOC_SEQ_VALUE i.e in sequence. ( Order by DOC_SEQ_VALUE ). Right now the IMPORT puts the transaction in random manner.
Regards
Robin
I wish to know if there is any way by which we can control the output of GL IMPORT prog. I am transfering transaction from one SOB (Source SOB) to another(Target SOB). I wish the Transaction from Source SOB to come to Target SOB with respect to DOC_SEQ_VALUE i.e in sequence. ( Order by DOC_SEQ_VALUE ). Right now the IMPORT puts the transaction in random manner.
Good article. Thank you.
http://buy-cigarette-online.biz/
Good article. Thank you.
http://asacols.info/