Hi @EnzoFerrari ,

I can confirm you that this is the standard behavior of APP10. I am not sure whether Customs Value field has been there in APP75. But in APP10, for the Unit Value to have a number, Customs Value should be defined in the line. 

Help text of Custom Value confirms this too.

Additionally I also found out that this has been reported to RnD recently and they have advised users to define the Customs Value in lines. 

On one hand, when we think of the Shipment Proforma Invoice, I feel the Customs Value should be defined, but on the other hand as you said, it might be not convenient for users to manually define it where the value shall not be fetched from somewhere else.

Thank you.

Let me mention @Yeshan Aluthgama here, since he is handling a case with RnD regarding a similar issue at the moment. Yeshan, hope this will help in any ongoing discussion :)

Sure, thanks for the update @Vimukthi Mahakumbura. If you or someone can let me know how it was fetched in App75 it will be good to convince my colleagues here. I am pretty sure we didn’t have to fill the Customs Value on the CO line back then. Is this the same question @Yeshan Aluthgama has reported to IFS RnD possibly as a standard software fault? :)

Hi @EnzoFerrari ,

I tested this in APP75. It behaves same like APP10. Means, when Custom Value is empty, no Unit Value in Shipment Proforma Invoice. 

Also, according to internal IFS knowledge (sol 226401, 221748 ), this has been the same since 99 version. Hence, it is a very thin possibility for Yeshan to report this as a Standard Software Fault and qualify. 

Maybe you can tell your users that.

Thank you.  

The reason behind, why price information cannot be used (according to RnD),

“ The Pro Forma Invoice printed for a Delivery Note is a delivery based Pro Forma Invoice, which is based on the value entered as Customs Value on the CO line. This invoice was introduced through bug 82611, after requirements had existed for so many years to have a Pro Forma Invoice that would reflect what is actually delivered, and which also needs to support that the goods it not sent to the buying customer, so the value cannot be taken from the price information stated on the CO line and instead it has to be deliberately set as the Customs Value.”

Thanks Vimukthi, that helps. Hopefully Yeshan has anything additional to add

@Vimukthi Mahakumbura, can you please recheck this? I just logged into our old App75 version and checked Shipment Proforma Invoices in the Report Archive. COs dont have the Customs Value filled. Shipment line, I cant find a column called Customs Value. But the report has the Unit Value filled. How come this difference between what you and me checked? 

Why not change the report to show the Price/Curr if the Customs Value field is empty? That way if there is a need to have a different value, it would still work.

Hi,

I can confirm what I stated previously. 

Can you try a new flow in APP75 track? What is your fininding when you create a new report with no value for Customs Value. 

And yes, in APP75, Customs Value is not seen in Shipment lines. 

THanks. 

Yes Steve, I think that’s the solution we should look at - thanks for the suggestion :)

Hi @EnzoFerrari ,

Hope you tested in APP75 again in a new flow. 

Since there was a disparity, I also spoke with one of  experienced RnD experts on this and it is reconfirmed that Customs Value needs to be defined. 

To add more, we discussed further, We want to make sure that the user deliberately sets a correct value, Since this impacts the procedure with the customs at the recipient. Even if the CO is entered and sold to customer A, they may request that the delivery is done to their customer and this is entered as a Single Occurrence Address. Then the Customs Value must reflect what customer A sells the parts for to customer B, and not the price we sell to customer A.

But as Steve suggested you can do an easy modification here, considering above impact.

Thanks.