Comments

  • Sameh Soliman

    hi steve

    i seen this scenario alot with US employees that are expatriates in canada.

    there are two options implemented for different clients

    1- expatriates are charged to a new company (e.g. global mobility).

    2- or expatriates are charged to US as balance segment value and canada as intercompany segment value.

     

    either option will help you extract trial balance and load it to the canadian ledger or cross charge the net through global intercompany.

     

    hope this helps

  • Sameh Soliman

    thank you for sharing

  • Sameh Soliman

    hi jain

    do you mind to share the BIP report and explain how you are passing the invoice ID so that the BIP report display information for the respective invoice

  • Sameh Soliman

    are you defaulting any accounting period on the filter?

  • Sameh Soliman

    i do not know , the documentation on this topic is terrible we are left to find out by trial and error.

     

    please let me know if the suggestion worked for you

  • Sameh Soliman

    replace your reversalflag rule with Invoice Distribution.Already Reversed

  • Sameh Soliman

    Hi Subhash Valiveti,

     

    were you able to find a solution for your query?

     

    we would like to use the job level in the IF part too.

    please share your research.

     

    Regards

    Sameh

  • Sameh Soliman

    Hi alexey

     

    Are you able to provide any insight ?

     

  • Sameh Soliman

    Hi alexey 

     

    thank tou tor the interaction and attention to read my business case

    the requirement is to go up the chain and not jump B to C even if B does not have the required limits However it is worth to mention that the business are willing to compromise on this requirement and accept routing the approval directly to the final approval of this will reduce the number of ties to configure in BPM.

     

    we have a rule that if the requestor has the signing limit still approval must be routed to the supervisor in that case. We tried the skip creator for approval list but it doesn’t work in our case because the requestor is captured in routing attribute 2 and BPM doesn’t consider it as the task creator even those routing attribute 2 is the starting participant. If that makes sense?

     

    i have asked Sri to share example of using dummy position hierarchy as it might be a viable option too

  • Sameh Soliman

    Hi srikanth 

     

    could tou you please share an example of how to use position based on org hierarchy?

    would be great to give an example on how you envisage to work or you have use case from previous project?

     

    much appreciated

  • Sameh Soliman

    As of aging for AP is available in R13

    if you on lower releases you can create a BI report using the below query

    let me know if that helps

     
    select 
    PV.VENDOR_NAME,PVS.VENDOR_SITE_CODE 
    ,API.INVOICE_NUM 
    ,DUE_DAYS 
    ,case when INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date) <=DUE_DAYS then 
    (decode(api.INVOICE_CURRENCY_CODE,'INR',nvl(api.exchange_rate,1),api.exchange_rate)*ps.AMOUNT_REMAINING) 
    else 0 end in_terms 
    ,case when INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date) >DUE_DAYS then 
    (decode(api.INVOICE_CURRENCY_CODE,'INR',nvl(api.exchange_rate,1),api.exchange_rate)*ps.AMOUNT_REMAINING) 
    else 0 end out_terms 
    ,case when (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date) <=:P_bucket_day 
    and (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date)>due_days))then 
    (decode(api.INVOICE_CURRENCY_CODE,'INR',nvl(api.exchange_rate,1),api.exchange_rate)*ps.AMOUNT_REMAINING) 
    else 0 end bucket1 
    ,case when (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date) between 
    1*:P_bucket_day+1 and 2*:P_bucket_day 
    and (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date)>due_days)) then 
    (decode(api.INVOICE_CURRENCY_CODE,'INR',nvl(api.exchange_rate,1),api.exchange_rate)*ps.AMOUNT_REMAINING) 
    else 0 end bucket2 
    ,case when (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date) between 
    2*:P_bucket_day+1 and 3*:P_bucket_day 
    and (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date)>due_days))then 
    (decode(api.INVOICE_CURRENCY_CODE,'INR',nvl(api.exchange_rate,1),api.exchange_rate)*ps.AMOUNT_REMAINING) 
    else 0 end bucket3 
    ,case when (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date) between 
    3*:P_bucket_day+1 and 4*:P_bucket_day 
    and (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date)>due_days))then 
    (decode(api.INVOICE_CURRENCY_CODE,'INR',nvl(api.exchange_rate,1),api.exchange_rate)*ps.AMOUNT_REMAINING) 
    else 0 end bucket4 
    ,case when (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date) >4*:P_bucket_day 
    and (INVOICE_TYPE_LOOKUP_CODE!='PREPAYMENT' and 
    to_date(:P_ason,'dd-mon-yy')-to_date(api.invoice_date)>due_days))then 
    (decode(api.INVOICE_CURRENCY_CODE,'INR',nvl(api.exchange_rate,1),api.exchange_rate)*ps.AMOUNT_REMAINING) 
    else 0 end bucket5 
    ,round(decode(api.INVOICE_TYPE_LOOKUP_CODE,'PREPAYMENT',AP_PREPAY_UTILS_PKG.get_prepay_amount_remaining(api.invoice_id),0)*nvl(api.exchange_rate,1),2) 
    unapp 
    ,(select trunc(c.RECEIPT_DATE) from RCV_VRC_TXS_V a,AP_INVOICE_LINES_all b 
    ,RCV_VRC_HDS_V c where 
    a.SHIPMENT_LINE_ID=b.RCV_SHIPMENT_LINE_ID 
    and a.SHIPMENT_HEADER_ID=c.SHIPMENT_HEADER_ID 
    and b.INVOICE_ID=api.invoice_id 
    and rownum=1) recptdt 
    FROM 
    ap_payment_schedules_all ps 
    ,ap_invoices_V api 
    ,po_vendors pv 
    ,po_vendor_sites_all pvs 
    --,AP_TERMS_LINES ATL 
    ,(select distinct TERM_ID,max(DUE_DAYS) DUE_DAYS from AP_TERMS_LINES group 
    by TERM_ID ) ATL 
    where ps.invoice_id=api.invoice_id 
    --and trunc(api.invoice_date)<=to_date(:P_ASON) 
    and trunc(api.gl_date)<=to_date(:P_ASON) 
    AND api.cancelled_date IS NULL 
    and api.ORG_ID=:P_ORGID 
    and 
    decode(api.INVOICE_TYPE_LOOKUP_CODE,'PREPAYMENT',AP_PREPAY_UTILS_PKG.get_prepay_amount_remaining(api.invoice_id),(NVL(api.invoice_amount,0) 
    - NVL(api.amount_paid,0)))*nvl(api.exchange_rate,1) <> 0 
    --AND nvl(api.payment_status_flag,'N') in ('N','P') 
    --AND ps.amount_remaining!= 0 
    and api.VENDOR_ID=pv.VENDOR_ID 
    and api.VENDOR_ID=nvl(:P_vendorid,api.VENDOR_ID) 
    and api.VENDOR_SITE_ID=pvs.VENDOR_SITE_ID 
    AND API.TERMS_ID=ATL.TERM_ID 
    and api.APPROVAL_STATUS_LOOKUP_CODE<>'NEVER APPROVED' 
    order by VENDOR_NAME

     

  • Sameh Soliman

    Hi Alexey 

     

    thank you for getting back

    Just to confirm the business case:

     

    In example 1:
    scenario 3: if the invoice requestor is A and invoice amount is 15K then approver should be to C i guess (so we should skip B here)

                      No Approver should be to A through C so B will be included ( requester and supervisor hierarchy up to the approver with limit)

    scenario 4: if the invoice requestor is B and invoice amount is 5K the approver should be A?

                        No should be B because B has enough signing limits.
    scenario 5: if the invoice requestor is C and invoice amount is 5K the approver should be A? 

                      No should be C because C has enough signing limits.

  • Sameh Soliman

    unfortunately we have identified 106 job names that will have different limits

  • Sameh Soliman

    Hi Becky,

     

     Thank you for your response.

    it is one of the options we are considering however this might be not a feasible option as we have 120 cost centers and each cost center will have owners with different limits.

    we are trying to avoid rule Proliferation   especially the BPM does not allow using data uploader not rule search 

  • Sameh Soliman

    Hi Alexey,

     

    Could you please provide more insight on the BPM modify part and what is the breakdown of the syntax?

    it is a great workaround you are using to leverage the job roles based on routing attribute2 which i used is populated based on OCR's subject line.

    we have a complicated case posted in the below link I am sure you could share some insights

    https://cloudcustomerconnect.oracle.com/posts/aede3d1d64