Pass RefNbr in PrepareInvoice Action

@Shaify , @Naveen B , I do not believe you should customize the invoice preparation logic at all here

There is already the invoice nbr field in a sales order which supplies the Ref Nbr field when specified. See the SOInvoiceEntry.InvoiceOrder method:

if (soOrder.InvoiceNbr != null)
                    {
                        newdoc.RefNbr = soOrder.InvoiceNbr;

This field is enabled and required only for orders of IN and CM behavior (not processing shipments). If the intention is to manually provide invoice nbr for sales orders of SO behavior, you can enable this field and make it required by a simple customization like this:

public class SOOrderEntryCommCust147EnableInvoiceInfoUnderManualNumbering : PXGraphExtension<SOOrderEntry>
    {

        public bool isInvoiceInfoEnabled (SOOrder doc)
        {
            return (doc.ARDocType != ARDocType.Undefined && doc.IsUserInvoiceNumbering == true
                && doc.BillSeparately == true);
        }
        public virtual void SOOrder_RowSelected(PXCache sender, PXRowSelectedEventArgs e, PXRowSelected baseM)
        {
            baseM(sender, e);
            SOOrder doc = (SOOrder)e.Row;
            if (doc!=null)
                PXUIFieldAttribute.SetEnabled<SOOrder.invoiceNbr>(sender, doc, isInvoiceInfoEnabled(doc));
        }

        public virtual void SOOrder_RowPersisting(PXCache sender, PXRowPersistingEventArgs e, PXRowPersisting baseM)
        {
            baseM(sender, e);
            SOOrder doc = (SOOrder)e.Row;
            PXDefaultAttribute.SetPersistingCheck<SOOrder.invoiceNbr>(sender, doc, isInvoiceInfoEnabled(doc)? PXPersistingCheck.NullOrBlank : PXPersistingCheck.Nothing);
        }
    }

Notice that  this code enables the (and necessitates filling of) the Invoice Nbr field only when Bill Separately = true (because only this setting ensures that this order cannot be invoiced along with other orders. which would have created ambiguity in invoice numbers)

 public class SOInvoiceEntry_Extension : PXGraphExtension<SOInvoiceEntry>
    {
        public delegate void PersistDelegate();
        [PXOverride]
        public void Persist(PersistDelegate del)
        {
            if (Base.Document.Cache.GetStatus((object)Base.Document.Current) == PXEntryStatus.Inserted)
            {
                Base.Document.Current.RefNbr = "XXXX";
                Base.Document.Cache.Update(Base.Document.Current);
            }
            del();
        }
    }

@Naveen B : I tried this way but didn’t work.

@Naveen B : Thanks I have understood the @mvolshteyn response.

@Naveen B : I am getting below error after implementing the above approach and also replied on the same.

@Naveen B , thanks for the follow up

@Shaify , sorry for confusion. It turned out that the IsUserInvoiceNumbering field was introduced only in 21R2 version, probably you are working on the earlier version. In this case, you should follow the suggestion of @Naveen B  to replace this DAC field with the Current member of SOOrderType, but only if you do not intend to use the Copy Order function to copy orders to ones with different automation behavior (e.g. QT to SO or SO to CM). When Copy Order function is run, the soordertype.Current might not be synced with the order type of SOOrder by the time of these handlers are run

So, if you intend to use the Copy Order function and run this solution on versions prior to 21R2, you can just mimic the product behavior by adding this field in the SOOrder DaC extension with the following attributes:

public abstract class isUserInvoiceNumbering : Data.BQL.BqlBool.Field<isUserInvoiceNumbering> { }
		[PXBool]
		[PXFormula(typeof(Where<Selector<orderType, SOOrderType.userInvoiceNumbering>, Equal<True>>))]
		public virtual bool? IsUserInvoiceNumbering
		{
			get;
			set;
		}

and accessing this SOOrder extension in the isInvoiceInfoEnabled function.