NotifyReceivable

The purpose of the NotifyReceiveable is to transmit data to create a receivable open item in a receivable application from the billing information generated in an order management application.  The NotifyReceiveable may also update the General Ledger, depending on the specific architecture of the accounting application.

The scope of the NotifyReceiveable is to create a BOD to recognize customer obligation (accounts receivable asset).  Specific transactions include:
1.	Sales Invoice
2.	Credit Memo
3.	Debit Memo
4.	Charge Back

The NotifyReceiveable may also be used for transaction that do not originate from an order management application.

The following two models illustrate that the NotifyReceiveable may, in some cases, be adequate to update the financial applications, i.e., Receivables and General Ledger, and in other cases, will also require the PostJournal Business Object Document (BOD) to assure the General Ledger account balances are updated.

In the model above, the receivable application is a sub-ledger of the general ledger.  Updates to G/L balances occur via the receivables module, therefore the Notify Receivable contains both receivable and general ledger transaction information.

This other model illustrates the environment that sometime exists when General Ledger updates occur directly from the Order Management application.  The reconciliation between the receivable and general ledger is a function within the financial applications and not of the integration space.  This model allows the G/L balances to be updated in either detail or summarized form.

The scope of the role of the receivable application includes functions such as:
·	Allowing Cash Application
·	Dunning
·	Dispute management

Element information

Content

• Sequence [1..1]
  from type BusinessObjectDocumentType
  ApplicationArea [1..1]    Provides the information that an application may need to know in order to communicate in an integration of two or more business applications. The ApplicationArea is used at the applications layer of communication. While the integration frameworks web services and middleware provide the communication layer that OAGIS operates on top of.
  1. DataArea [1..1]    Is where the information that the BOD message carries is provided, in this case NotifyReceivable. The information consists of a Verb and one or more Nouns. The verb (Notify) indicates the action to be performed on the Noun (Receivable).

Attributes

Sample instance

<NotifyReceivable releaseID="normalizedString">
   <ApplicationArea>
      <Sender>
         <LogicalID>normalizedString</LogicalID>
         <ComponentID>normalizedString</ComponentID>
         <TaskID>normalizedString</TaskID>
         <ReferenceID>normalizedString</ReferenceID>
         <ConfirmationCodes>...
         </ConfirmationCodes>
         <AuthorizationID>normalizedString</AuthorizationID>
      </Sender>
      <Receiver>
         <LogicalID>normalizedString</LogicalID>
         <ComponentID>normalizedString</ComponentID>
         <ID/>
      </Receiver>
      <CreationDateTime></CreationDateTime>
      <Signature>
         <!--any element-->
      </Signature>
      <ScenarioID>normalizedString</ScenarioID>
      <CorrelationID>normalizedString</CorrelationID>
      <BODID>normalizedString</BODID>
      <Extension>
         <AnyExtension>
            <!--any element-->
         </AnyExtension>
         <Amount/>
         <Code/>
         <DateTime></DateTime>
         <ID/>
         <Indicator>true</Indicator>
         <Measure/>
         <Name/>
         <Number>1.0</Number>
         <Quantity/>
         <Text/>
         <Time></Time>
         <ValueText>string</ValueText>
      </Extension>
   </ApplicationArea>
   <DataArea>
      <Notify>
         <ActionCriteria>...
         </ActionCriteria>
      </Notify>
      <Receivable>
         <ReceivableHeader>...
         </ReceivableHeader>
         <ReceivableLine>...
         </ReceivableLine>
      </Receivable>
   </DataArea>
</NotifyReceivable>