Each of these forms is a stand-alone template, the Purchase Orders being for use when ordering
goods or services, the Acceptance Forms being for use by a Supplier when confirming a sale of
goods or supply of services.
A worked example showing how the form may be filled in is also included.
Very many businesses have no proper system for ordering goods and services and our form is
intended to remedy the problem so that a proper record is kept of all orders. This can be
useful in a variety of ways, not least to ensure that the key terms are complied with by
your supplier. The order form is prepared with a space for signature by both purchaser
and supplier, so you should, ideally, issue two signed copies, one to be kept by each party.
Similarly, a supplier of goods and services should confirm in writing the key terms of the
order that he is accepting – a clear description of what is to be supplied, the delivery date,
price and payment terms etc. and, again, get the customer to sign, indicating his agreement.
But even if the form is only signed by the company that issues it, it is a useful record.
VALIDATIONS:
.organization validation
.purchase number validation(getting po_header_id from po_headers_all based on po number,organization)
we can do this conversion by directly inserting into base tables or we can do by using api
USING API:
declare
result number := null;
begin
fnd_global.apps_initialize (user_id, responsibility_id_id, application_id);
result :=
po_change_api1_s.record_acceptance
(9310000133, ---po num
null, ---release num
0, ---revision num
'new', ---action
sysdate, ---action date
261, ---buyer id
'y', ---acceptance flag ‘y’ or ‘n’
'abcd', ---acceptance lookup code
'all valid', ---note
'1.0'); ---version number
commit;
end;
USING DIRECT INSERT INTO BASE TABLES:
begin
insert into po.po_acceptances
( acceptance_id
, last_update_date
, last_updated_by
, last_update_login
, creation_date
, created_by
, po_header_id
, action
, action_date
, revision_num
, accepted_flag
, note
, accepting_party
, signature_flag
, attribute1
, attribute2
, attribute3
, attribute4
, attribute5
, attribute6
, attribute7
, attribute8
, attribute9
, attribute10
, attribute11
)
values
(po_acceptances_s.nextval
,sysdate
,fnd_global.user_id
,fnd_global.login_id
,sysdate
,fnd_global.user_id
,rec_process.po_header_id
,rec_process.action
,rec_process.action_date
,rec_process.revision_num
,rec_process.accepted_flag
,rec_process.note
,rec_process.accepting_party
,rec_process.signature_flag
,rec_process.attribute1
,rec_process.attribute2
,rec_process.attribute3
,rec_process.attribute4
,rec_process.attribute5
,rec_process.attribute6
,rec_process.attribute7
,rec_process.attribute8
,rec_process.attribute9
,rec_process.attribute10
,rec_process.attribute11
);
commit;
exception
end;
REQUIRED COLUMNS TO MAP WITH THEIR DESCRIPTION:
po_num :purchase order number.
release_num :required if the purchase order is a release. the pass-in value must be a number.
revision_num :which revision of the purchase order/release is being acted upon.
action :indicates the action to take. the value must be new.
action_date :indicates the date of follow-up action. provide a value in the format
of 'mm/dd/yy' or 'mm-dd-yy', its default value is trunc (sysdate).
employee_id :the fnd_global.user_id of the buyer.
accepted_flag :indicate if purchase is accepted. must be 'y' or 'n'.
acceptance_lookup_code:type of acceptance, its value must be corresponding to the lookup_code
in po_lookup_codes table with lookup_type of acceptance type.
the possible values are- accepted terms, accepted all terms, on schedule,
unacceptablechanges, and rejected
note :any description you want to insert.
version :version of the current api (currently 1.0)
No comments:
Post a Comment