Is there a way to have a field from a Sales Order ...
# general
m
Is there a way to have a field from a Sales Order flow through to the Revenue Element / Revenue Plan? I've figured out how to map to Revenue Arrangement line but that's not close enough for a Revenue Plan saved search.
j
if you find a solution, I would be very interested. Only way to do this that we've found is with custom segments
m
Will let you know if I figure anything out. Did you look into scripting options at all?
We need a free form text field so a custom segment wouldn't work
@Jon Kears I've figured something out that may work for us. Basically a custom Revenue Recognition Plan field to store a link to the transaction, populated by a workflow
j
yeah that would work. I'm assuming your field is on the transaction header?
m
Yes, probably for line level you would need scripting
j
yeah 😢
For header level stuff we just cheat and use odbc
the link isn't pretty but it's ok as long as you limit the revenue recognition postings to just a couple of periods. Anything over 6 and it absolutely crawls
m
The link, you mean ODBC?
j
you need a custom join as there is no direct reference back to the original transaction for some bloody reason
m
We were actually just talking this morning about moving some of our saved searches and reports to ODBC for performance
j
Here's what we have at the minute. It's not great performance-wise and there may be a much simpler way to do it. If sales orders are generating your revenue recognition you'd need to add that context to the last join (our rev rec always originates from invoices or credit notes). We can get back to the originating transaction header (table
ret
) but not the line. We can replicate most of this using Analytics Workbooks, but of course you can't export anything with a decent amount of data
Copy code
FROM 
  "Company".Administrator.transaction_lines d
   INNER JOIN 
  "Company".Administrator.transactions h ON d.transaction_id = h.transaction_id
   INNER JOIN 
  "Company".Administrator.accounting_periods p ON h.accounting_period_id = p.accounting_period_id
   LEFT JOIN
  "Company".Administrator.transaction_links dl ON d.transaction_id = dl.applied_transaction_id AND d.transaction_line_id = dl.applied_transaction_line_id AND dl.link_type='Revenue/Amortizaton Recognition'
   LEFT JOIN
  "Company".Administrator.transaction_lines ld ON dl.original_transaction_id = ld.transaction_id AND dl.original_transaction_line_id = ld.transaction_line_id
   LEFT JOIN
  "Company".Administrator.revenue_elements re ON ld.revenue_element_id = re.revenue_element_id 
   LEFT JOIN
  "Company".Administrator.transactions ret ON TO_NUMBER(SUBSTR(re.reference_ID,10,100)) = ret.transaction_id AND SUBSTR(re.reference_ID,1,8) IN ('CustCred','CustInvc')
m
Nice, thanks! This should hopefully speed things up for me if we go ODBC route
Did you look at the NetSuite2 datasource? Supposedly it's the same schema as Anayaltics so there may be existing joins
j
no we haven't had a look at that. From memory, that last join is the problem. I don't know why they store it as custinvc_123456 instead of just as a bigint transaction ID.
m
Lol that's exactly what I was typing, it's probably the last join that's causing performance issues
j
I bet in the real data source it's pure ID There's some abstraction going on to "help" their customers 😡