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.

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

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.

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