Vous êtes sur la page 1sur 17

Customer Acceptance in R12 Order Management

In diferent countries a number of companies prefer to accept goods formally before being invoiced by the supplier.
To record and view customer acceptance, Oracle Order Management integrates with Accounts Receivables and
Costing. The customer can accept the goods in any or in combination of the following ways:
Pre-Billing Acceptance (goods are accepted before Invoicing) Implicit or Explicit
Post-Billing Acceptance (goods are accepted after Invoicing) Implicit or Explicit
What is Customer Acceptance?
Customer Acceptance is new functionality with R12 that gives a seller control over the timing of customer
invoicing or revenue recognition and provides the ability to link either of these events with customer satisfaction of a
product or service delivery. Where invoicing used to be automatic based on the standard fulfllment criteria of
shipping a product or service, it can now be delayed until explicit or implicit customer acceptance criteria are
received and logged against a given shipment (sales order line).
There are some initial concepts that must be understood before confguring and using Customer Acceptance,
and they will be reviewed here.
First, there are 2 fundamentally diferent fows for handling acceptance: Pre-Billing Acceptance and Post-
Billing Acceptance. Lets look at each separately and how they ft into the fulfllment fow.
For Pre-Billing Acceptance, as the name implies, acceptance must be recorded before AR invoicing can be
processed. This is accomplished by preventing the Sales Order Line from interfacing to AR until the acceptance
is recorded. Think of it as the Customer saying Do not bill me until I approve the shipment! and having
Oracle comply with that demand.
Post-Billing Acceptance, also as the name implies, afects what occurs after AR invoicing has already been
processed. Revenue recognition will not occur for a given line/AR invoice until an acceptance is recorded. From the
Customers perspective, there is no change with this type of acceptance. They still receive their invoice with
the normal timing relative to a shipment being confrmed. So in that respect, this acceptance type is less customer
focused and more of an internal (sellers) process.
We reviewed the 2 acceptance fows, but within each one there are 2 types or acceptance Explicit and Implicit.
Explicit acceptance is one that requires an actual acceptance to be recorded, so the sales order line workfow
will NOT progress until this is recorded. It requires action either on the part of the customer or customer
service representative in order to open the gate for customer billing (AR invoicing) or revenue recognition.
Implicit acceptance, on the other hand, is one that will automatically be generated when a certain interval of time
has lapsed beyond a specifc event for the order line. This interval and the event it applies to are both confgurable
in AR and will be explained in more detail later.
Note: Even if implicit acceptance is engaged, you have the option to enter explicit acceptance prior to the
number of expire days elapsing.
So based on the above terms,, there are 4 kinds of Customer Acceptance as listed below:
1. Pre-Billing Explicit
2. Pre-Billing Implicit
3. Post-Billing Explicit
4. Post-Billing Implicit
The seller does not have to rely on any one of the above types, but rather has the ability to use any or all of them
in the course of their fulfllment cycle.
Customer Acceptance Setups:
Order Management:
1) System parameter in OM "Enable fulfllment acceptance " to "Yes"
First, and foremost, you must enable the System Parameter in OM. Without it, Customer Acceptance simply will not
work. The reason it is setup as a parameter, with a default of No, is that when enabled there is an AR API that is
engaged for every sales order line. This requires system resources and can result in a performance penalty for the
application, so you dont want to enable this functionality unless you intend to use it.
2) Show feld using the Folder options to show the felds related to customer acceptance.
Use Folder Show Field to add the required mix of acceptance felds, then save as a named folder, and make it
your default with the option of making it public. If Customer Service intends to use this functionality, I would suggest
you setup a public folder so that every CSR sees the same data when responding to customer inquiries.
Sales order lines- Others tab
3)Enable function security within the Menu
Below are 2 OM functions which must be enabled on the menu structure in order to use Customer Acceptance. By
default, they should be enabled on the ONT_SALES_ORDERS menu, but you might need to verify these in System
Administrator if you run into any difculties. By enabling or disabling these functions within a given
responsibility, you can enforce functional security for who can and cannot perform Customer Acceptance.
Sales Orders: Fulfllment Acceptance
Sales Orders: Update Acceptance Attributes
4) User Access to Order Information Portal (required to perform
Manual Explicit Acceptance)
Receivables (Revenue Management):
1) Revenue contingency
A revenue contingency is an AR setup that afects revenue recognition, and ties in with the workfow
associated with Customer Acceptance. Some seeded revenue contingencies are provided in AR, but you can add
new ones as need be
Contingency removal event is one of the required felds in setting up revenue contingency
The removal event determines which Customer Acceptance fow will be engaged in the workfow.
For Pre-Billing Acceptance, set Removal Event to Invoicing
For Post-Billing Acceptance, set Removal Event to Customer Acceptance
4
A revenue contingency is an AR setup that afects revenue recognition, and ties in with the workfow
associated with Customer Acceptance. Some seeded revenue contingencies are provided in AR, but you can add
new ones as outlined below. You can defne new contingencies using the Revenue Management Super User
responsibility.
The example below is a revenue contingency for Pre-Billing Implicit Acceptance, automatically recorded 3 days after
Ship Confrm.
Fig. 4 Revenue Contingency Example (implicit pre-billing acceptance)
The removal event determines which Customer Acceptance fow will be engaged in the workfow.
For Pre-Billing Acceptance, set Removal Event to Invoicing
For Post-Billing Acceptance, set Removal Event to Customer Acceptance
The choices for Removal Event are: Contingency Expiration, Customer Acceptance, Invoicing, Payment, Proof
of Delivery.
If you want Explicit Acceptance, leave Optional Time Attributes blank. You will record the actual acceptance data at
the appropriate time in the Order Information Portal (OIP).
If you want Implicit Acceptance, select an Attribute Event and Days Added to Event Attribute. The acceptance will be
automatically generated by a request set that can be scheduled to run daily in the
application.
Choices for Event Attribute are: Fulfllment Date, Proof of Delivery Date, Ship Confrm Date, or Transaction Date.
Assignment Rules can be confgured to automatically assign the desired revenue contingency to a sales order line.
Choices can be as general as the Operating Unit, or as specifc as a single Item when shipped to a specifc
Customer.You defne the business scenarios that require Customer Acceptance with these rules, or you can
optionally assign the acceptance manually in Order Management before booking the sales order.
--------------------------------------------
Under Generally Accepted Accounting Principles (GAAP), deferred revenue, sometimes called unearned revenue.
Deferred revenue is a liability that is created when monies are received by a company for goods and services not
yet provided.
What is the deferred revenue?
Deferred revenue is a liability that is created when monies are received by a company for goods and services not yet
provided.
evenue will be recogni!ed, and the deferred revenue liability eliminated, when the services are performed.
Deferred revenue stems from the accounting concept of revenue recognition, under which revenues are recogni!ed
only when the earnings process is complete. "f funds are received and no goods or services have yet been provided,
the process is not complete# thus revenue cannot be recogni!ed, and a deferred revenue liability is recorded.
$pecifically, the deferred revenue account is credited, and cash (or otherassets) are debited. Please ta%e a note
deferred revenue is recorded in specific industries under particular circumstances.
Deferred Revenue Example
&i%e many subscription businesses, A internet 'osting company offers a plan to pay upfront for whole year.
$ince deferred revenue represents the value of the services that are left to be delivered at a point in time, if you
purchased the annual plan, ()*++ would be added to both the cash account of the balance sheet and the deferred
revenue line. ,very month ()++.++ would be moved out of deferred revenue and reported as revenue on the income
statement.
Understand why you need to defer revenue.
-hy can.t you /ust record the revenue when you actually receive the cash payment0 1y doing so , this would violate
the principles of accrual2based accounting.
3here are ) principles which provide the foundation for accrual accounting.
1. 3he first is the matching principle. Under the matching principle, revenues and e4penses that correspond to
each other must be recorded in the same accounting period. Using the insurance e4ample above, you cannot
recogni!e all the revenue in 5anuary, because there will be e4penses associated with that insurance coverage
incurred throughout the year. 3hese e4penses must be matched with their corresponding revenues.
2. 3he second is the revenue recognition principle. 3his principle dictates that revenues should only be recorded
when they are both reali!ed (or reali!able) and earned. 6eali!ed6 revenues are those for which a claim to
cash has been received, and 6earned6 revenues are those for which a good or service has been rendered.
3he implication, then, is that you cannot simply record a revenue whenever cash is paid to your company. "f, for
e4ample, a client is prepaying for a continuing service, then you cannot recogni!e that payment as revenue until you
actually render the service. Until then, the payment represents a liability, or an obligation to the client. 3his ma%es
sense to you.
Governing Rule
7or revenue to be recogni!ed (earned), $,8 have $A1 9+9:9+* sets four %ey conditions that must be met;
1. Persuasive evidence of an arrangement e4ists,
2. Delivery has occurred or services have been rendered,
3. 3he seller.s price to the buyer is fi4ed or determinable, and
4. 8ollectability is reasonably assured
Understanding the Deferred Revenue ccounting !rocess
<ou can create and send invoices for products or services that you will deliver in the future or over a range of time.
"nvoice details#
1ill line amount; =+++.++ U$D.
"nvoicing ule > 1ill in Advance
"nvoice Date )2D,829)
G& Date )2D,829)
Accounting ule;3ype; Accounting, 7i4ed Duration
Period ; ?onthly
@umber of Periods ; =
'ere is accounting Posting
$inally
Aeep in mind that deferred revenue generally means that cash has been received by the seller, so the remaining
concern is determining when the cash is recogni!ed as earned revenue. -ithin GAAP, there are multiple methods that
can be used to recogni!e revenue. Depending upon which method is chosen, the financial statements may loo%
drastically different even though economic reality remains the same.
Posted in Bracle eceivable % @o 8omments C
Revenue Recognition: Does Your Company still Have missing link
within ERP?
Posted on pril &'th( &)*+ by ,an-it nand % Print 3his Post % ,mail 3his Post
Are you aware about the top three concerns for finance teams as
1. 7inancial closing and reporting process
2. ,4cessive use of spreadsheets
3. and revenue recognition.
"n %ey finding of survey conducted by www.evenueecognition , it was observed
D)E of public companies rely on manual processes to perform %ey revenue recognition and reporting
functionality (nearly the same percentage is true for private companies).
o =FE of all companies stated their 7inancials:,P systems DB @B3 automate all their revenue
recognition and reporting activities.
o F*E of companies that initially stated 7inancials:,P systems DB automate revenue accounting are
actually using spreadsheets for these activities.
3he finance processes that are most difficult to establish internal controls for are contract management and
revenue recognition.
8ompanies want to spend less time on data aggregation, manipulation, and validation and more time on
business performance analysis.
"ssue with E./E0
Using ,4cel as the 6system of record6 for managing revenue
3he problems were...
,4cessive time and effort to;
o analy!e and arrange an enormous amount of data
o close the boo%s
o create /ournal entries
o ensure accuracy
"ncreased time and effort to manage accounting controls
"nfle4ible reporting and analysis and the volume of data was growing
1issing 0in2
D)E of companies said above, they are using spreadsheets for one or more of the following %ey revenue recognition
and reporting tas%s;
Applying revenue allocation rules
edistributing revenue (e.g. based on $BP DG2), ,"37 ++2)9)
8reating revenue recognition schedules for future periods
eviewing sales orders to identify deferred items
Performing revenue contribution analysis
eporting on future revenue streams
8reating accounting entries
egardless of whether your company is private or public, does your organi!ation recogni!e the importance of
consistent and reliable revenue recognition 0
Revenue Recognition
evenue ecognition is Principle of accrual accounting that determines the period in which revenue is recogni!ed
evenue recognition is an earning process
3here are rules and regulations on how and when you can recogni!e revenue
Under GAAP, there are four basic criteria;
o ,vidence of an arrangement e4ists (governing contract H PB)
o Delivery has occurred (transfer title and ris% of loss)
o 7ee is fi4ed or determinable (normal payment terms)
o 8ollection is probable (customer has ability to pay)
Accounting terminology you may hear I 7A$1 and "7$ guidelines, evidence of an arrangement, delivery, fi4ed fees,
collection, software and non2software rules, multiple element arrangements, fair value (J$B,, 1,$P, 3P,), relative
selling price, revenue allocation, lin%ed arrangements, acceptance, release events, contingencies, future upgrades,
significant discounts, e4tended terms, software is essential to functionality, deferred revenue release, and so onK."n
other words I itLs '"G'&<
Under Generally Accepted Accounting Principles (GAAP), deferred revenue, sometimes called unearned revenue.
Deferred revenue is a liability that is created when monies are received by a company for goods and services not
yet provided.
What is the deferred revenue?
Deferred revenue is a liability that is created when monies are received by a company for goods and services not yet
provided.
evenue will be recogni!ed, and the deferred revenue liability eliminated, when the services are performed.
Deferred revenue stems from the accounting concept of revenue recognition, under which revenues are recogni!ed
only when the earnings process is complete. "f funds are received and no goods or services have yet been provided,
the process is not complete# thus revenue cannot be recogni!ed, and a deferred revenue liability is recorded.
$pecifically, the deferred revenue account is credited, and cash (or otherassets) are debited. Please ta%e a note
deferred revenue is recorded in specific industries under particular circumstances.
Deferred Revenue Example
&i%e many subscription businesses, A internet 'osting company offers a plan to pay upfront for whole year.
$ince deferred revenue represents the value of the services that are left to be delivered at a point in time, if you
purchased the annual plan, ()*++ would be added to both the cash account of the balance sheet and the deferred
revenue line. ,very month ()++.++ would be moved out of deferred revenue and reported as revenue on the income
statement.
Understand why you need to defer revenue.
-hy can.t you /ust record the revenue when you actually receive the cash payment0 1y doing so , this would violate
the principles of accrual2based accounting.
3here are ) principles which provide the foundation for accrual accounting.
1. 3he first is the matching principle. Under the matching principle, revenues and e4penses that correspond to
each other must be recorded in the same accounting period. Using the insurance e4ample above, you cannot
recogni!e all the revenue in 5anuary, because there will be e4penses associated with that insurance coverage
incurred throughout the year. 3hese e4penses must be matched with their corresponding revenues.
2. 3he second is the revenue recognition principle. 3his principle dictates that revenues should only be recorded
when they are both reali!ed (or reali!able) and earned. 6eali!ed6 revenues are those for which a claim to
cash has been received, and 6earned6 revenues are those for which a good or service has been rendered.
3he implication, then, is that you cannot simply record a revenue whenever cash is paid to your company. "f, for
e4ample, a client is prepaying for a continuing service, then you cannot recogni!e that payment as revenue until you
actually render the service. Until then, the payment represents a liability, or an obligation to the client. 3his ma%es
sense to you.
Governing Rule
7or revenue to be recogni!ed (earned), $,8 have $A1 9+9:9+* sets four %ey conditions that must be met;
1. Persuasive evidence of an arrangement e4ists,
2. Delivery has occurred or services have been rendered,
3. 3he seller.s price to the buyer is fi4ed or determinable, and
4. 8ollectability is reasonably assured
Understanding the Deferred Revenue ccounting !rocess
<ou can create and send invoices for products or services that you will deliver in the future or over a range of time.
"nvoice details#
1ill line amount; =+++.++ U$D.
"nvoicing ule > 1ill in Advance
"nvoice Date )2D,829)
G& Date )2D,829)
Accounting ule;3ype; Accounting, 7i4ed Duration
Period ; ?onthly
@umber of Periods ; =
'ere is accounting Posting
$inally
Aeep in mind that deferred revenue generally means that cash has been received by the seller, so the remaining
concern is determining when the cash is recogni!ed as earned revenue. -ithin GAAP, there are multiple methods that
can be used to recogni!e revenue. Depending upon which method is chosen, the financial statements may loo%
drastically different even though economic reality remains the same.
Posted in Bracle eceivable % @o 8omments C
Revenue Recognition: Does Your Company still Have missing link
within ERP?
Posted on pril &'th( &)*+ by ,an-it nand % Print 3his Post % ,mail 3his Post
Are you aware about the top three concerns for finance teams as
1. 7inancial closing and reporting process
2. ,4cessive use of spreadsheets
3. and revenue recognition.
"n %ey finding of survey conducted by www.evenueecognition , it was observed
D)E of public companies rely on manual processes to perform %ey revenue recognition and reporting
functionality (nearly the same percentage is true for private companies).
o =FE of all companies stated their 7inancials:,P systems DB @B3 automate all their revenue
recognition and reporting activities.
o F*E of companies that initially stated 7inancials:,P systems DB automate revenue accounting are
actually using spreadsheets for these activities.
3he finance processes that are most difficult to establish internal controls for are contract management and
revenue recognition.
8ompanies want to spend less time on data aggregation, manipulation, and validation and more time on
business performance analysis.
"ssue with E./E0
Using ,4cel as the 6system of record6 for managing revenue
3he problems were...
,4cessive time and effort to;
o analy!e and arrange an enormous amount of data
o close the boo%s
o create /ournal entries
o ensure accuracy
"ncreased time and effort to manage accounting controls
"nfle4ible reporting and analysis and the volume of data was growing
1issing 0in2
D)E of companies said above, they are using spreadsheets for one or more of the following %ey revenue recognition
and reporting tas%s;
Applying revenue allocation rules
edistributing revenue (e.g. based on $BP DG2), ,"37 ++2)9)
8reating revenue recognition schedules for future periods
eviewing sales orders to identify deferred items
Performing revenue contribution analysis
eporting on future revenue streams
8reating accounting entries
egardless of whether your company is private or public, does your organi!ation recogni!e the importance of
consistent and reliable revenue recognition 0
Revenue Recognition
evenue ecognition is Principle of accrual accounting that determines the period in which revenue is recogni!ed
evenue recognition is an earning process
3here are rules and regulations on how and when you can recogni!e revenue
Under GAAP, there are four basic criteria;
o ,vidence of an arrangement e4ists (governing contract H PB)
o Delivery has occurred (transfer title and ris% of loss)
o 7ee is fi4ed or determinable (normal payment terms)
o 8ollection is probable (customer has ability to pay)
Accounting terminology you may hear I 7A$1 and "7$ guidelines, evidence of an arrangement, delivery, fi4ed fees,
collection, software and non2software rules, multiple element arrangements, fair value (J$B,, 1,$P, 3P,), relative
selling price, revenue allocation, lin%ed arrangements, acceptance, release events, contingencies, future upgrades,
significant discounts, e4tended terms, software is essential to functionality, deferred revenue release, and so onK."n
other words I itLs '"G'&<3,8'@"8A&
Revenue Re3uirements
8hallenge that software companies face results from the volume and comple4ity of the revenue recognition guidance
that e4ists.in such case, software arrangements include both software and services. 3he services could include
installation, training, software design, or customi!ation and modification of the software. "f the services involve
significant customi!ation or modification of the software, then contract accounting under $BP F929 should be used for
the arrangement.therefore , under such senario , evenue eMuirement should mainly focus on .
1. /ompliance
o 8alculate J$B,(Jendor2$pecific Bb/ective ,vidence : ,$P (,stimated $elling Price)
o ?anage J$B,: 3P,(3hird Party ,vidence):,$P
o 3olerances
2. 1E 41ultiple Element rrangements5
o 3rac% ?,A from multiple sources
o 8lassify elements
3. Revenue Recognition
o $tandalone sales
o ?,A
o ev rec carveouts according to J$B,:3P,:,$P
o Deferrals H rev rec timing
o 8BG$s
o G& Posting
4. Reporting
o evenue compliance
o 1illing and revenue reconciliation
o evenue forecasts
5. 6otifications
o J$B, reference during pricing
o ev rec related notifications (approved e4ceptions, renewals, collectability status, etc.)
7ey spects in Revenue Re3uirements
User2defined evenue 8ontingencies
7air Jalue Analysis
Auto Accounting ules
Amorti!ation ?ethods
E8, R*& Revenue 1anagement Enhancements( filling the Gap of 1issing 0in2
Brgani!ations will also find that Bracle 7inancials 9) allows them to manage revenue with greater fle4ibility and
improved accuracy.
Partial Period evenue ecognition enables the generation of revenue recognition associated with contracts
evenue Deferral easons based on events specific to an enterpriseLs business practices
8BG$ and evenue ?atching synchroni!e the recognition of revenue with the associated 8BG$ in compliance
with Generally Accepted Accounting Principles
Customer Acceptance (Oracle Apps Release12 Feature).
Email This BlogThis! Share to Titter Share to Face!oo" Share to #interest
Customer Acceptance is new feature introduced in Oracle
Application
Release 12.Customers in some in$ustries ha%e nee$ to $e&er in%oicing an$'or re%enue recognition &or shippe$ goo$s
until the customer recei%es the shipment an$ &ormall( accepts the material.
)n Oracle R12 Customer acceptance're*ection can !e capture$ &rom customers+ customer ser%ice representati%es+ or &rom
an e,ternal s(stem.
Customers can per&orm the acceptance in &olloing manners.
1. -og into the sel&.ser%ice Or$er )n&ormation portal.
2. )mport customer acceptance're*ection &rom an e,ternal s(stem ith Or$er )mport'#rocess Or$er A#).
3. Recor$ Acceptance 'Re*ection &rom Sales Or$er Form.
Oracle Or$er /anagement supports onl( &ull acceptance or total re*ection &or each out!oun$ or$er line. One can set the
num!er o& $a(s &or implicit acceptance+ a&ter the pro$uct has !een shippe$.
A 0e S(stem parameter 1Enable Fulfillment Acceptance2 has !een intro$uce$ in R12 at Operating 3nit le%el &or this
#urpose. Once this parameter is ena!le$+ the Accounts Recei%a!les A#) is calle$ to in%o"e the rules engine to %ali$ate
customer acceptance on e%er( or$er line.
The !asic !usiness nee$ is to $e&er in%oicing an$'or re%enue recognition &or the shippe$ goo$s till the customer recei%es
the shipment an$ accepts the material.
Customer Acceptance &unctionalit( o&&ers
1. #re Billing an$ #ost Billing Acceptance
2. E,plicit an$ )mplicit Acceptance.
4. )t is either Full Acceptance or &ull re*ection+ as o& no it $oesn5t support #artial Acceptance.
6. )t support AT#'#TO'7)T'Ser%ice 8 Stan$ar$ item. Acceptance $e&ine$ at the parent le%el (/o$el) onl(+ an$ chil$ ill
inherit that &rom parent (e.g. ATO'#TO /o$el).
As o& no Oracle in not support Acceptance in R/A Or$ers.
Setup for Customer Acceptance:
1.Customer acceptance can !e ena!le$ at Operating 3nit le%el through O/ s(stem#arameter9 Ena!le Ful&illment
Acceptance : ;'0.
2.We need to enable &unction securit( &or a gi%en responsi!ilit( &or the &olloing to
Functions9
a. Sales Orders: Ful&illment Acceptance : This ensures that the action attri!ute Ful&illment Acceptance is a%aila!le in the
Actions -O<.
b. Sales Orders: 3p$ate Acceptance Attri!utes : This allos &or up$ating the acceptance attri!utes o& Acceptance 0ame
an$ Acceptance E,pire $a(s.These are attache$ to the sales or$er menu : O0T= Sales=Or$er.
3.efine eferral Reason &or #re : Billing Acceptance
>e&ine ?>e&erral reason? un$er Recei%a!les Re%enue /anagement set up
0a%igation9 Re%enue /anagement Super 3ser .@ Contingenc( Search ' >e&inition .@
it launches an AT/- page.
>e&ine assignment rules to assign the $e&erral reason to customer+ site+ item+ etc.
a. For $e&ining a !re"billin# Acceptance+ use the $e&erral reason remo%al e%ent as
)n%oicing.
!. For $e&ining a !ost"billin# Acceptance+ use the $e&erral reason remo%al e%ent asCustomer Acceptance.
c. For $e&ining an $mplicit Acceptance+ e nee$ to $e&ine the Optional time attri!utes : E%ent Attribute and a&s
added to E%ent attribute.
As shon a!o%e please note that Or$er /anagement supports S'ip Confirm ate as onl( e%ent attri!ute &or the current
release.
The >a(s a$$e$ to E%ent Attri!ute gets $e&aulte$ as Acceptance E,pire $a(s inSales Or$er -ine.
(ote: The $e&erral reason $e&ine$ in AR?s Re%enue /anagement setup page is actuall( use$ as Acceptance 0ame in
Or$er /anagement
Ena!le Fol$er &iel$s &or Customer Acceptance in Sales Or$er Form as ell as Buic" Sales Or$er Form.
The )n%oice )nter&ace Cor"&lo su! process han$les sen$ing inter&ace $ata to Oracle Recei%a!le &or in%oice an$ cre$it
memo creation.)t us (se$ to han$le pre.!illing Customer acceptance. )& an or$er line reDuires pre.!illing Customer
Acceptance+ this su!.process ill pre%ent the or$er line &rom !eing inter&ace$ to Recei%a!les.
!re")illin# Acceptance
Sales Or$er -ine in #en$ing #re.!illing Acceptance.
E Recor$ Acceptance : e,plicit or implicit .
E -ine status mo%es to close$ an$ line gets inter&ace$ to AR.
E )n%oice generation an$ Re%enue Recognition happen su!seDuentl(.
!ost")illin# Acceptance
Sales Or$er -ine in #en$ing #ost.!illing Acceptance .
E )n%oice generation .
E Recor$ Acceptance : e,plicit or implicit.
E -ine status mo%es to close$ .
E Re%enue Recognition happens once acceptance is complete$ .
E*plicit Acceptance:
1. Acceptance through Or$er )n&ormation #ortal+ clic" on Sales Or$er Actions :Ful&illment Acceptance &rom Aea$er or
-ines.
2. Through Or$er )mport.
$mplicit Acceptance:
1. >e&erral reason has to !e $e&ine$ in AR ith e%ent attri!ute as Ship Con&irm $ate an$ e,piration $a(s.
2. An )mplicit Acceptance ReDuest set that recor$s )mplicit Acceptance consists o& the &olloing concurrent programs9
E Fenerate #re.!illing Acceptance #rogram &or #re.!illing+ )mplicit Acceptance
E Re%enue Contingenc( Anal(Ger &or #ost.!illing+ )mplicit Acceptance
!rocess Flow +E*plicit Acceptance,.
1.Enter orders that nee$ to !e accepte$ !( the customer an$ this acceptance is to !e Recor$e$ !( the Customer Sales
Representati%e.
2.-iew.update Acceptance fields on the or$er line. The Others ta! o& the sales or$ers line $ispla(s the &ol$er ena!le$
Acceptance &iel$s.
3.Sales Order Ac/nowled#ment Report prints Acceptance ReDuire$.
0.S'ip Confirm t'e items m%ie the line status ?#en$ing #re.Billing ' #en$ing #ost.Billing Acceptance?.
1.!erform Acceptance.Re2ection.(Belo is E,ample o& #re.Billing E,plicit Acceptance).
3.-iew Acceptance etails in Sales Or$ers line.
!rocess Flow +O(45 Screen s'ort, of $mplicit Acceptance

Vous aimerez peut-être aussi