Sunday, February 28, 2010
1. Concurrent Manager is related to Concurrent Programs
2. Concurrent manager manages the concurrent(oops I mean parallel) execution of concurrent programs.
3. In oracle apps you have a concurrent program submission screen. You can submit the concurrent program from that screen.
4. There is something known as Concurrent Manager that runs in the background all the time. This background process, called Concurrent Manager ideally will be running 24x7.
As the name suggests, purpose of a concurrent manager is to manage the submitted concurrent programs
5. Concurrent manager will be running in the background waiting for a concurrent program to be submitted. As soon as a concurrent program is submitted, it then gets put in an execution queue by
concurrent manager.
6. At any given point in time a concurrent manager can run no more than say 10 programs concurrently. This figure of 10 is configurable of course. First the manager puts a submitted program into a queue, next the manager checks if there is a slot available (i.e. Less than 10 programs are currently running). If a slot is found available, the concurrent manager then runs the program, or else it keeps the concurrent program in a queue with status Pending.
7. When you define a concurrent program, you can specify if there are any incompatible programs. If incompatible concurrent programs exist, then concurrent manager will wait for the incompatible program to complete.
Sunday, February 28, 2010 by Team search · 1
- All the pl/sql packages will be created in APPS Schema
- All the views will be created in APPS Schema
- For each table in individual schema, there will exist one synonym in APPS schema
- Tables are not created in APPS schema.
- Every implementation has at least 1 custom schema, where custom tables are created. For each custom table created by you, you will need to create a Synonym in APPS schema
- As a developer, you will either connect to APPS Schema or to the custom schema where you will create new tables.
Some notes:-
Custom tables are generally required in Oracle ERP because:-
1. You wish to create a custom screens ( your own screen to capture some info) for a functionality that is not delivered by Oracle
2. Pre-Interface tables ( Interface will certainly be discussed in one of the latter chapters)
3. Temp processing
4. Staging of data for third party extract interfaces….and much more
by Team search · 0
Oracle internally uses a login named GUEST, prior to invoking validation of actual username. Some people regard this as a security threat, but it isn’t. Your DBA’s can change the “guest” password from its default
value after installation.
Oracle uses a DB User account named applsyspub to which it first connects during validation of LOGIN. This user account has very restricted privileges and has access to below objects (primarily for authentication purposes):-
FND_APPLICATION
FND_UNSUCCESSFUL_LOGINS
FND_SESSIONS
FND_PRODUCT_INSTALLATIONS
FND_PRODUCT_GROUPS
FND_MESSAGES
FND_LANGUAGES_TL
FND_APPLICATION_TL
FND_APPLICATION_VL
FND_LANGUAGES_VL
FND_SIGNON
FND_PUB_MESSAGE
FND_WEBFILEPUB
FND_DISCONNECTED
FND_MESSAGE
FND_SECURITY_PKG
FND_LOOKUPS
by Team search · 0
1. Customers
We sell our products/services & bill customers using Order Management & Receivables
2. Suppliers
They sell us their goods(
3. Employees
These can be special customers, or pseudo vendor if they even sue you, as you make them payment.
4. Banks
Banks can be paying us interest, or charging penalties, or selling us products.
5. Insurance Company
This is Interesting. When you buy their policy, you become their customer. However when you make a claim, you become their customer(as you get paid).
6. Students
Even more interesting than 5 above. They are your customers, as you would bill them. They can become your staff latter. Or they can become your vendor if they become independent contractor latter by selling their services to you. Even more, they can become your student again(for post-grad), after resigning as an employee.
by Team search · 0
A receipt can have one of the following statuses:
Approved: This receipt has been approved for automatic receipt creation. This status is only valid for automatic receipts.
Confirmed: The customer has approved the application of this receipt and their account balances have been updated within Receivables. This status is only valid for automatic receipts.
Remitted: This receipt has been remitted. This status is valid for both automatic and manually entered receipts.
Cleared: The payment of this receipt was transferred to your bank account and the bank statement has been reconciled within Receivables. This status is valid for both automatic and manually entered receipts.
Reversed: This receipt has been reversed. You can reverse a receipt when your customer stops payment on a receipt, if a receipt comes from an account with non-sufficient funds or if you want to re-enter and reapply it in Receivables. You can reverse cash receipts and miscellaneous transactions
by Team search · 2
The purpose of Row-Level-Security is to hide certain data[based on some conditions]. RLS does so by appending a where clause to the secured object.
1. MO_GLOBAL.ORG_SECURITY is a function that returns a predicate for the WHERE CLAUSE
2. The where clause will be appended to Table/Synonym/View for which Multi Org Row Level security is enabled
1. MO_GLOBAL.ORG_SECURITY is a function that returns a predicate for the WHERE CLAUSE
2. The where clause will be appended to Table/Synonym/View for which Multi Org Row Level security is enabled
This procedure has two parameters
1. p_access_mode
Pass a value "S" in case you want your current session to work against
Single ORG_ID
Pass a value of "M" in case you want your current session to work
against multiple ORG_ID’s
2. p_org_id
Only applicable if p_access_mode is passed value of "S"
In SQL*Plus, I wish to set my session to work against a specific Org [one single org]. How do I do that in R121. p_access_mode
Pass a value "S" in case you want your current session to work against
Single ORG_ID
Pass a value of "M" in case you want your current session to work
against multiple ORG_ID’s
2. p_org_id
Only applicable if p_access_mode is passed value of "S"
SQL>> exec MO_GLOBAL.SET_POLICY_CONTEXT(’S’,101);
In the above case, ORG_ID 101 will be assigned as current org for your session.
Internally, following code in blue will be executed by Oracle when you set your context to single Org, dbms_session.set_context(’multi_org2’, ’current_org_id’, 101);
If the current database session is initialised for Single Org[as in above step], then Where clause appended to object by Row-Level-Security will be
WHERE org_id = sys_context(’multi_org2’,’current_org_id’)
by Team search · 0
Purpose of mo_global.init :-
It will check if new Multi Org Security Profile is set, to decide if new Security Profile method will be used.
If the new MO security profile is set, then mo_global.init inserts one record, for each Organization in Org Hierarchy, in table mo_glob_org_access_tmp
When & from where is mo_global.init called ?
This package procedure will be called as soon as you login or as soon as you switch responsibility. Just like FND_GLOBAL.INITIALIZE is called. It is safe to assume that Oracle will invoke MO_GLOBAL.INIT after FND_GLOBAL.INITIALIZE
Is mo_glob_org_access_tmp table a global temporary table?
Yes, it is. Hence after Multi Org is initialised for your session, your session will have X number of records in table mo_glob_org_access_tmp. X is the number of organizations assigned to MO Security profile [view org hierarchy or org list in security profile]
It will check if new Multi Org Security Profile is set, to decide if new Security Profile method will be used.
If the new MO security profile is set, then mo_global.init inserts one record, for each Organization in Org Hierarchy, in table mo_glob_org_access_tmp
When & from where is mo_global.init called ?
This package procedure will be called as soon as you login or as soon as you switch responsibility. Just like FND_GLOBAL.INITIALIZE is called. It is safe to assume that Oracle will invoke MO_GLOBAL.INIT after FND_GLOBAL.INITIALIZE
Is mo_glob_org_access_tmp table a global temporary table?
Yes, it is. Hence after Multi Org is initialised for your session, your session will have X number of records in table mo_glob_org_access_tmp. X is the number of organizations assigned to MO Security profile [view org hierarchy or org list in security profile]
by Team search · 0
Lets take an example.
In pre Release 12, you would have had following methodology for PO_HEADERS_ALL
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Create a view PO_HEADERS in APPS schema, as "select * from po_headers_all where org_id=client_info"
But now in R12, following will happen
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Another synonym named PO_HEADERS is created in APPS, referring to PO_HEADERS_ALL
d. A Row Level security is applied to PO_HEADERS, using package function MO_GLOBAL.ORG_SECURITY.
This can be double-checked by running SQL select * from all_policies where object_name=’PO_HEADERS’
e. The effect of this policy is that,whenever you access PO_HEADERS, Oracle RLS will dynamically append WHERE CLAUSE similar to below
SELECT * FROM PO_HEADERS WHERE EXISTS (SELECT 1 FROM mo_glob_org_access_tmp oa WHERE oa.organization_id = org_id)
In pre Release 12, you would have had following methodology for PO_HEADERS_ALL
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Create a view PO_HEADERS in APPS schema, as "select * from po_headers_all where org_id=client_info"
But now in R12, following will happen
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL
c. Another synonym named PO_HEADERS is created in APPS, referring to PO_HEADERS_ALL
d. A Row Level security is applied to PO_HEADERS, using package function MO_GLOBAL.ORG_SECURITY.
This can be double-checked by running SQL select * from all_policies where object_name=’PO_HEADERS’
e. The effect of this policy is that,whenever you access PO_HEADERS, Oracle RLS will dynamically append WHERE CLAUSE similar to below
SELECT * FROM PO_HEADERS WHERE EXISTS (SELECT 1 FROM mo_glob_org_access_tmp oa WHERE oa.organization_id = org_id)
by Team search · 0
Question: What does DFF mean?
Answer: DFF is a mechanism that lets us create new fields in screens that are delivered by Oracle.
Question: Oh good, but can these new fields be added without modifying/customization of the screen?.
Answer: Yes, certainly. Only some setup is needed, but no programmatic change is needed to setup DFF.
Question: Are these DFF’s flexible?
Answer: A little flexible, for example, depending upon the value in a field, we can make either Field1 or Field2 to appear in DFF.
Question: So we create new fields in existing screen, but why the need of doing so?
Answer: Oracle delivers a standard set of fields for each screen, but different customers have different needs, hence Oracle lets us create new fields to the screen.
Question: Are these new fields that get created as a result of DFF free text?
I mean, can end user enter any junk into the new fields that are added via DFF?
Answer: If you attach a value set to the field(at time of setup of dff), then field will no longer be free text. The entered value in the field will be validated, also a list of valid values will be provided in LOV.
Question : Will the values that get entered by the user in dff fields be updated to database?
Answer: Indeed, this happens because for each field that you create using DFF will be mapped to a column in Oracle Applications.
Question: Can I create a DFF on any database column?
Answer: Not really. Oracle delivers a predefined list of columns for each table that are meant for DFF usage. Only those columns can be mapped to DFF segments. These columns are named similar to ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3 ETC. Usually Oracle provides upto 15 columns, but this number can vary.
Question: Can I add hundreds of fields to a given screen?
Answer: This depends on the number of attribute columns in the table that screen uses. Also, those columns must be flagged as DFF enabled in DFF Registration screen. Don’t need to worry much about this because all the ATTRIBUTE columns are by default flagged for their DFF usage.
Question: Hmmm, I can see that DFFs are related to table and columns...
Answer: Yes correct. Each DFF is mapped to one table. And also each segment(or call it field) is mapped to one of the attribute columns in that table.
Question: I want these fields to appear in screen only when certain conditions are met. Is it possible?
Answer: Yes, we have something known as Context Sensitive Descriptive Flexfields
Answer: DFF is a mechanism that lets us create new fields in screens that are delivered by Oracle.
Question: Oh good, but can these new fields be added without modifying/customization of the screen?.
Answer: Yes, certainly. Only some setup is needed, but no programmatic change is needed to setup DFF.
Question: Are these DFF’s flexible?
Answer: A little flexible, for example, depending upon the value in a field, we can make either Field1 or Field2 to appear in DFF.
Question: So we create new fields in existing screen, but why the need of doing so?
Answer: Oracle delivers a standard set of fields for each screen, but different customers have different needs, hence Oracle lets us create new fields to the screen.
Question: Are these new fields that get created as a result of DFF free text?
I mean, can end user enter any junk into the new fields that are added via DFF?
Answer: If you attach a value set to the field(at time of setup of dff), then field will no longer be free text. The entered value in the field will be validated, also a list of valid values will be provided in LOV.
Question : Will the values that get entered by the user in dff fields be updated to database?
Answer: Indeed, this happens because for each field that you create using DFF will be mapped to a column in Oracle Applications.
Question: Can I create a DFF on any database column?
Answer: Not really. Oracle delivers a predefined list of columns for each table that are meant for DFF usage. Only those columns can be mapped to DFF segments. These columns are named similar to ATTRIBUTE1, ATTRIBUTE2, ATTRIBUTE3 ETC. Usually Oracle provides upto 15 columns, but this number can vary.
Question: Can I add hundreds of fields to a given screen?
Answer: This depends on the number of attribute columns in the table that screen uses. Also, those columns must be flagged as DFF enabled in DFF Registration screen. Don’t need to worry much about this because all the ATTRIBUTE columns are by default flagged for their DFF usage.
Question: Hmmm, I can see that DFFs are related to table and columns...
Answer: Yes correct. Each DFF is mapped to one table. And also each segment(or call it field) is mapped to one of the attribute columns in that table.
Question: I want these fields to appear in screen only when certain conditions are met. Is it possible?
Answer: Yes, we have something known as Context Sensitive Descriptive Flexfields
by Team search · 0
if custom table contains data partitioned by ORG_ID. All you need to do in such case is to assign package function MO_GLOBAL.ORG_SECURITY to that table/synonym/view.
Will the Multi Org Row Level security be applied against the table or the synonym or the view?
In theory, RLS can be applied against any of the above objects. However in practice, you will apply RLS against Objects in APPS Schema. This means, you will most probably apply RLS on Synonyms. Basically, the Multi Org Views are now replaced by RLS Secured Synonyms. Hence no code change is required where the pre-R12 Multi-Org secured view was being accessed. The responsibility of securing data as per ORG_ID now lies with RLS [also known as VPD - Virtual Private Database].
I have made changes to my Multi Org Security Profile, by attaching a new Org Hierarchy. Do i need to run any process?
Just like we do in HRMS, it is advised that any changes to Security Profiles must be followed by running "Security List Maintenance"
by Team search · 0
Autoinvoice Line Ordering Rules which enables users to define line ordering rules. Name, Description, Effective Start Date, Effective End Date, Sequence, Transaction Attribute and Type are the fields displayed.
These rules are used by Autoinvoice to determine the order of the transaction lines on a particular invoice. When line ordering rules are not defined, Autoinvoice orders lines randomly on the transaction. A line ordering rule can be assigned to each grouping rule. Active invoice line ordering rules appear as a list of values in the Grouping rules window. Line ordering takes place after grouping.
In the Sequence field, enter the priority of the transaction attribute. Enter a higher number to specify a lower priority for the particular transaction attribute.
In the Transaction Attribute field, enter the transaction attribute by which lines are to be ordered.
In the Type field enter the order in which the transaction attribute must be sorted. Ascending sorts the particular transaction attribute from least to greatest and Descending sorts the particular attribute from greatest to least.
by Team search · 0
Name, Description, Line Ordering Rule, Effective Start Date, Effective End Date, Transaction Class and Optional Grouping Characteristics fields are displayed.
Auto invoice uses grouping rules to group lines to create one transaction. Mandatory grouping attributes cannot be dropped. However, users can add optional grouping attributes.
The grouping rule DEFAULT , is a seeded value, which contains all the mandatory grouping attributes. When an upgrade takes place, from a previous version of Oracle Receivables, this grouping rule becomes the default grouping rule initially. If this rule is used to create transactions, additional grouping rules need not be defined. The grouping rule DEFAULT can be customized, by including additional optional transaction attributes.
Lines which have identical values in the columns for mandatory attributes and the optional attributes, defined in the grouping rule, are grouped into one single transaction.
In the Transaction Class field, enter the class of transaction name, to which this grouping rule should apply. If a particular class of transaction has no grouping rule defined, then, only the mandatory transaction attributes are considered for grouping.
Autoinvoice uses the following hierarchy to determine the grouping rule that is to be used:
1. Transaction batch source
2. Customer site level
3. Customer profile leve
4. System Options Window
1. Transaction batch source
2. Customer site level
3. Customer profile leve
4. System Options Window
If a grouping rule is not specified, either, at the Transaction Source or at the Customer Site level or in the Customer Profile Classes window, Autoinvoice uses the default grouping rule specified in the System Options.
by Team search · 0
Pre-grouping phase: In this phase Auto invoice validates all of the line-level data as well as any other data that is not dependent on successful grouping.
Grouping phase: Auto invoice groups lines based on the grouping rules and validates header-level data that is dependent on how your lines are grouped.
Transfer phase : Autoionvoice validates information that exists in Oracle Receivables tables, such as defaulting tax and Auto Accounting data.
by Team search · 0
General ledger date for Invoices without Rules :
1.Autoinvoice uses the general ledger date in the interface tables, if one exists and it is in an open or future enterable period.
2.If a general ledger date is not populated in the interface tables and Derive Date is set to no, Autoinvoice uses the value of the default date parameter entered for the particular Autoinvoice run.
3.If a general ledger date is not populated in the interface tables and Derive Date is set to yes, Autoinvoice uses the ship date in the interface tables. If the ship date does not exist or is in a closed period Autoinvoice uses the sales order date. If the sales order date does not exist or is in a closed period, Autoinvoice uses the value of the default date parameter entered for the particular Autoinvoice run.
General ledger date for Invoices with Rules
1.Autoinvoice uses the general ledger date in the interface table, if one exists and it is in an open or future enterable period.
2.If the invoice uses Bill in Advance as the invoicing rule, Autoinvoice uses the earliest accounting rule start date as the invoice Gl date.
3.If the invoice uses Bill in Arrears as the invoicing rule, and the invoice line has an accounting rule of type ’Accounting, Fixed Duration,’ and a period of ’Specific Date,’ Autoinvoice computes an ending date using the latest accounting rule date. The latest ending date is the GL date. For all other accounting rules, with Bill in Arrears as the invoicing rule Autoinvoice computes an ending date for each invoice line based on the accounting rule, accounting rule start date, and duration. Once Autoinvoice computes the ending date for each line of your transaction, it takes the latest ending date and uses it as the invoice GL date. Rule Start Date
If the invoice does not use an accounting rule with a type of ’Accounting, Fixed Duration’ and a period of ’Specific Date,’ or if Derive Date is not selected, Autoinvoice uses the default date parameter entered for the particular Autoinvoice run.
If the invoice has an accounting rule with a type of ’Accounting, Fixed Duration’ and a period of ’Specific date,’ Autoinvoice uses the earliest accounting rule date as the rule start date. For example, if the accounting rule dates are 10–JUN–02, 10–JUL–02 and 10–AUG–02,
Autoinvoice uses 10–JUN–02 as the rule start date. If it is elected to derive the date, Autoinvoice first uses the ship date in the interface table. If the ship date does not exist, Autoinvoice uses the sales order date. If the sales order date does not exist, Autoinvoice uses the default date parameter entered for the particular Autoinvoice run.
Transaction date
If a transaction date is not passed for an invoice or debit memo, Autoinvoice uses the general ledger date. If the transaction date is passed specifically, it will be used.
by Team search · 1
Friday, February 26, 2010
Wednesday, February 24, 2010
This API is used to create invoice in batches.
set serveroutput on;
DECLARE
l_return_status varchar2(1);
p_count NUMBER;
l_msg_count number;
l_msg_data varchar2(2000);
l_batch_id number;
l_cnt number := 0;
l_batch_source_rec ar_invoice_api_pub.batch_source_rec_type;
l_trx_header_tbl ar_invoice_api_pub.trx_header_tbl_type;
l_trx_lines_tbl ar_invoice_api_pub.trx_line_tbl_type;
l_trx_dist_tbl ar_invoice_api_pub.trx_dist_tbl_type;
l_trx_salescredits_tbl ar_invoice_api_pub.trx_salescredits_tbl_type;
l_customer_trx_id number;
cnt number;
v_context varchar2(100);
FUNCTION set_context( i_user_name IN VARCHAR2
,i_resp_name IN VARCHAR2
,i_org_id IN NUMBER)
RETURN VARCHAR2
IS
v_user_id NUMBER;
v_resp_id NUMBER;
v_resp_appl_id NUMBER;
v_lang VARCHAR2(100);
v_session_lang VARCHAR2(100):=fnd_global.current_language;
v_return VARCHAR2(10):='T';
v_nls_lang VARCHAR2(100);
v_org_id NUMBER:=i_org_id;
/* Cursor to get the user id information based on the input user name */
CURSOR cur_user
IS
SELECT user_id
FROM fnd_user
WHERE user_name = i_user_name;
/* Cursor to get the responsibility information */
CURSOR cur_resp
IS
SELECT responsibility_id
,application_id
,language
FROM fnd_responsibility_tl
WHERE responsibility_name = i_resp_name;
/* Cursor to get the nls language information for setting the language context */
CURSOR cur_lang(p_lang_code VARCHAR2)
IS
SELECT nls_language
FROM fnd_languages
WHERE language_code = p_lang_code;
BEGIN
/* To get the user id details */
OPEN cur_user;
FETCH cur_user INTO v_user_id;
IF cur_user%NOTFOUND
THEN
v_return:='F';
END IF; --IF cur_user%NOTFOUND
CLOSE cur_user;
/* To get the responsibility and responsibility application id */
OPEN cur_resp;
FETCH cur_resp INTO v_resp_id, v_resp_appl_id,v_lang;
IF cur_resp%NOTFOUND
THEN
v_return:='F';
END IF; --IF cur_resp%NOTFOUND
CLOSE cur_resp;
/* Setting the oracle applications context for the particular session */
fnd_global.apps_initialize ( user_id => v_user_id
,resp_id => v_resp_id
,resp_appl_id => v_resp_appl_id);
/* Setting the org context for the particular session */
mo_global.set_policy_context('S',v_org_id);
/* setting the nls context for the particular session */
IF v_session_lang != v_lang
THEN
OPEN cur_lang(v_lang);
FETCH cur_lang INTO v_nls_lang;
CLOSE cur_lang;
fnd_global.set_nls_context(v_nls_lang);
END IF; --IF v_session_lang != v_lang
RETURN v_return;
EXCEPTION
WHEN OTHERS THEN
RETURN 'F';
END set_context;
BEGIN
DBMS_OUTPUT.PUT_LINE('1');
--1. Set applications context if not already set.
BEGIN
v_context := set_context('&username','&responsiblity_name',&org_id);
IF v_context = 'F'
THEN
DBMS_OUTPUT.PUT_LINE('Error while setting the context');
END IF;
DBMS_OUTPUT.PUT_LINE('2');
exception
when others then
dbms_output.put_line('Error in Crea_cm:'||sqlerrm);
end;
-- Populate header information.
l_trx_header_tbl(1).trx_header_id := 102;
l_trx_header_tbl(1).trx_number := 'Test_inv';
l_trx_header_tbl(1).bill_to_customer_id := 3318;
l_trx_header_tbl(1).cust_trx_type_id := 1069;
l_trx_header_tbl(1).primary_salesrep_id := -3;
-- Populate batch source information.
l_batch_source_rec.batch_source_id := 1021;
-- Populate line 1 information.
l_trx_lines_tbl(1).trx_header_id := 102;
l_trx_lines_tbl(1).trx_line_id := 101;
l_trx_lines_tbl(1).line_number := 1;
l_trx_lines_tbl(1).description := 'Test';
l_trx_lines_tbl(1).quantity_invoiced := 10;
l_trx_lines_tbl(1).unit_selling_price := 120;
l_trx_lines_tbl(1).line_type := 'LINE';
-- Populate Distribution Information
l_trx_dist_tbl(1).trx_dist_id := 1021;
l_trx_dist_tbl(1).trx_header_id := 102;
l_trx_dist_tbl(1).trx_LINE_ID := 101;
l_trx_dist_tbl(1).ACCOUNT_CLASS := 'REV';
l_trx_dist_tbl(1).AMOUNT := 1200;
l_trx_dist_tbl(1).CODE_COMBINATION_ID := 3251;
-- CAll the api
AR_INVOICE_API_PUB.create_single_invoice(
p_api_version => 1.0,
p_batch_source_rec => l_batch_source_rec,
p_trx_header_tbl => l_trx_header_tbl,
p_trx_lines_tbl => l_trx_lines_tbl,
p_trx_dist_tbl => l_trx_dist_tbl,
p_trx_salescredits_tbl => l_trx_salescredits_tbl,
x_customer_trx_id => l_customer_trx_id,
x_return_status => l_return_status,
x_msg_count => l_msg_count,
x_msg_data => l_msg_data);
DBMS_OUTPUT.PUT_LINE('l_return_status : '||l_return_status);
IF l_return_status = 'S' THEN
dbms_output.put_line('unexpected errors found!');
IF l_msg_count = 1 Then
dbms_output.put_line('l_msg_data '||l_msg_data);
ELSIF l_msg_count > 1 Then
p_count := p_count+1;
l_msg_data := FND_MSG_PUB.Get(FND_MSG_PUB.G_NEXT,FND_API.G_FALSE);
IF l_msg_data is NULL Then
EXIT;
END IF;
dbms_output.put_line('Message' || p_count ||'.'||l_msg_data);
END LOOP ;
END IF;
ELSE
dbms_output.put_line(' Got Created Sucessfully : '||l_customer_trx_id);
END IF;
END;
Wednesday, February 24, 2010 by Team search · 5
Monday, February 22, 2010
In Oracle Context External Drop-Shipping means your Oracle Order Management uses purchase orders to outside suppliers that are automatically generated from sales orders for goods supplied directly from the supplier. The “external” supplier ships the goods directly to the 3rd Party customer and confirms the shipment through the use of an Advanced Shipment Notice (ASN). Note: Oracle uses this ASN to record a receiving transaction into inventory followed by an immediate logical shipping transaction. From these transactions, conveyance of title takes place and the customer can be invoiced and the supplier’s invoice can be processed. Whereas “Internal” context Drop-Shipping functions in a similar fashion. The key difference is that no inventory transactions take place on the books of the selling operating unit; transfer of ownership of the goods from shipper to seller to customer with the only physical movement of the goods being out of the shipping organization.
Things not to forget in a Drop Shipment
Things not to forget in a Drop Shipment
ü Release 11i/12 does not support Drop Shipment across operating units.
ü Blanket PO’s will not used with Drop Shipment , the reason the PO must be created when OM notifies PO that a Drop Ship order has been created.
ü You can’t cancel Drop Shipments once Oracle Purchasing obtains the receipt.
ü Standard Items can be used for Drop Shipment.In 11i, PTO’s and ATO’s cannot be drop shipped
Monday, February 22, 2010 by Team search · 2
As mentioned in my previous post, Supplier information is moved to R12 and below are some of the important tables involved
HZ_PARTIES
This is the master table for Suppliers instead of PO_VENDORS. As usual PARTY_ID will be referenced in the other related tables.
HZ_PARTY_USG_ASSIGNMENTS
This table stores the Party Usages, for example, in this case it captures the fact that the given party_id is of type SUPPLIER
HZ_ORGANIZATION_PROFILES
This table captures additional Supplier information, for example, credit scoring details of Supplier or the Number of Employees working in Supplier Organization.
IBY_EXTERNAL_PAYEES_ALL
This table captures Payment related details of the Supplier.
For example:-
1. How should the supplier's remittance advice must be sent?
2. What is the default Payment method Code for this supplier?
3. Who bears the bank charges when lets say SWIFT payment is made?
This information can be setup at either the Supplier level or at Supplier Site level.
For example:-
1. How should the supplier's remittance advice must be sent?
2. What is the default Payment method Code for this supplier?
3. Who bears the bank charges when lets say SWIFT payment is made?
This information can be setup at either the Supplier level or at Supplier Site level.
AP_SUPPLIERS
Alongside HZ_PARTIES, this is another master table that replaces the PO_VENDORS table of 11i.
Instead of expanding the design of HZ_PARTIES, oracle decided to hold the supplier specific attributes in AP_SUPPLIERS
Instead of expanding the design of HZ_PARTIES, oracle decided to hold the supplier specific attributes in AP_SUPPLIERS
POS_SUPPLIER_MAPPINGS
This table holds the mapping between the AP_SUPPLIERS.VENDOR_ID and HZ_PARTIES.PARTY_ID.
This is useful in cases whereby two vendors effectively belong the same HZ_Party Record.
This is useful in cases whereby two vendors effectively belong the same HZ_Party Record.
ZX_PARTY_TAX_PROFILE
The taxation related details like Tax Codes, and Tax Accounts etc have been moved from AP into ZX.
ZX is the name of a new Application "E-Business Tax". Efectively this application is the Tax repository/Taxation Engine for eBusiness Suite starting from R12.
ZX_RATES_B
This table holds all the TAX_RATES. In simple words it is the replacement for the 11i table AP_TAX_CODES_ALL.
ZX_ACCOUNTS
This table also falls under the module ‘E-BUSINEES Tax’ and it holds the details about the Accounting setups for the each TAX_RATE.
by Team search · 0
Ø Supplier becomes as TCA Party.
Ø Suppliers Sites as TCA Party Site for each distinct address.
Ø Contacts for each supplier/address , it means Single supplier address and contact can be leveraged by multiple sites, for each OU
v A single change to an address can be seen instantly by all OUs
v No longer need to manually 'push' updates across OUs.
New AP tables containing supplier unique data been introduced. They have the links to TCA tables:
- AP_SUPPLIERS
- AP_SUPPLIER_SITES_ALL
- AP_SUPPLIER_CONTACTS
I will post the detail information about the tables related to Suppliers soon.
by Team search · 0
Subscribe to:
Posts (Atom)
Disclaimer
The ideas, thoughts and concepts expressed here are my own. They, in no way reflect those of my employer or any other organization/client that I am associated. The articles presented doesn't imply to any particular organization or client and are meant only for knowledge Sharing purpose. The articles can't be reproduced or copied without the Owner's knowledge or permission.