Question

Custom Fields on reports not being updated

  • 22 March 2024
  • 4 replies
  • 43 views
B
Rank
Userlevel 5
Badge +15

Hello,

 

I have created a handful of custom fields (type read-only) that I have included in operational reports. For example, I have balance due and customer PO fields on the collective invoice form. 

 

There is an issue where, if someone has a customer order that gets invoiced into a collective invoice, but changes their PO, when the collective invoice is first printed off originally, the PO comes up as the updated PO but the balance due is zero, even though the balance due is pulling the open amount. (SELECT OPEN_AMOUNT FROM LEDGER_ITEM_CU_DET_QRY WHERE LEDGER_ITEM_ID= :INVOICE_NO)

 

When we reprint modified the collective invoice form, the PO gets changed to the old PO value and the balance due field becomes the correct, up to date, value.

 

Has anyone encountered this before? Does anyone know what the correct approach is? This seems like some history tracking issue that collective invoices and customer statements of accounts encounter (same error on statements). I’ve checked the custom field’s value via a quick report and it pulls the most up to date information (correct PO and correct balance due)

 

I know this is an odd issue since it encapsulates reporting, custom fields, and invoice/statement history tracking, but any and all advise would be greatly appreciated.

 

Thanks,
Bryan

4 replies

T
Rank
Userlevel 4
Badge +11

Bryan - What method did you take to add your custom fields to the Collective Invoice report?  If your custom fields are in an LU that’s been enabled in the CustomerOrderCollIvc.rdf, then they get added to the report xml when it is run.  It’s possible that the “reprint modified” option is referencing parts of the original xml like the custom fields.  I would trouble-shoot this by examining the xml generated in the report archive.  This may also shed some light on what exactly is getting passed for the balance due on the original print.

B
Rank
Userlevel 5
Badge +15

Hi @Tracy Norwillo

I dug a little deeper into this and realised that the issue was actually opposite that which was reported. The custom values on the invoice are being updated upon time of ordering the invoice via reprint modified. For example, if we have a parent PO placed that creates a customer order, invoice the items on the customer order, and then add new items to the customer order with a new PO (this process is required for one of our customers) then the invoice for the first few items on the customer order, prior to the invoice change, will show the correct (old) PO when clicking reprint original, but when we click reprint-modified, it fetches the current PO of the customer order associated.

We unfortunately have to click reprint modified for other reasons. Is there a way to look back in history and fetch that old value? There has to be some place IFS keeps this archived information. Alternatively, and what I sent for testing now, is that upon an invoice creation, we have a persistent custom field that stores the current PO. When a credit or collective invoice is created, it fetches the originating invoice’s po field and I do an NVL on these two fields. So far testing is going well, but it seems a bit silly since the original PO value for the invoice definitely lives somewhere.

Thanks,
Bryan

T
Rank
Userlevel 4
Badge +11

I’m not a functional expert on the PO to CO to Invoice process, so I’m going to answer with some general solutions that may work.

If the PO number that is appearing in the custom field on the Invoice is pointing to the Customer Order header, then it may work to move it to the line level of the Customer Order.  You said your process is to create the CO with PO1 with some lines, then add lines with PO2. So if the invoice was for the original lines, it would print PO1 and if it was for the additional lines, it would print PO2.  On the CO lines, there are already existing columns for the Demand OrderRef1,2,3, and Customer PO, Customer PO Line.  Perhaps these would work for you?

Re: “it seems a bit silly since the original PO value for the invoice definitely lives somewhere.” 

If you’re basing your assumption that the custom field original value must live somewhere because when you reprint the original, it appears as desired, then I think you’re sort of correct.  The problem is that it lives in the xml that was created when you printed the original invoice.  

Customer Orders and Customer Order Lines both have history tables.  But I do not know which changes to a CO are captured in each.  You’d need to test to see if your changes are captured there.  But parsing through history is sometimes complicated and hard to capture in a single custom field.

There is also archiving functionality that may be turned on to capture certain changes.  But archiving has an overhead you may not want to live with.

 

 

 

B
Rank
Userlevel 5
Badge +15

Hi Tracy,

Thank you for the information, it helps a lot. I’ll have to do more digging into the history table locations since that is what I am looking for. The issue with the lines storing the PO is that if we have this setup via an event action, custom field, and a workflow to populate the data, we will encounter an IFS limitation that tricks itself into thinking the workflow is stuck in a recursive loop, when its actually just processing more than 20 loops (1 for each customer order line). This is a setting that we can increase in IFS Cloud, but the main issue is that we cannot increase it since this will also cause other errors in other locations. 

Juggling between all of these errors and what is feasible and what is not has been the core of working with cloud. I unfortunately think that the current setup I have in testing now is the only solution that will work for our business. If the history tables end up working out well, then that might be a solid replacement too, but as you mentioned, the archiving might be something too big to handle right now.

Thanks,
Bryan

Reply


Terms & ConditionsCookie settings