Problem migrating overwritten code from ADempiere to iDempiere

[Emiliano Pereyra]

Good morning, community!

In our company, we have started the migration from ADempiere 361.Final to iDempiere. This process involves migrating the Argentine Localization (LAR) that we have been developing for several years. It includes fiscal printing, complete tax and accounting management for Argentine legislation, and current electronic types of invoicing in our country.

Regarding iDempiere, we have some knowledge of OSGi, we have noticed that the business processes and operations that both developers and users perform in ADempiere are similar in this new ERP (as expected, given the origin of iD). However, despite this, we have some questions that we hope you can help us address to get this migration process started.

## Overriding of classes
We have 99 overridden classes in LAR, and some of these are further overridden in the custom projects of each client.
So far, we have used iDempiere's own extension mechanisms (EventHandlers, ModelFactory, Callouts, and Processes) to migrate the code. However, we have encountered some situations where it's not possible to do it that way.

One of these cases is as follows: we've added code to a method in the MPayment class, and this method is called from a custom class as well as from core classes. What approach do you recommend for handling this type of situation?
Method in the MPayment class:

public BigDecimal getAllocatedAmt ()
    {
        BigDecimal retValue = null;
        // begin @emmie issue #17
        if (getC_Charge_ID() != 0 && !get_ValueAsBoolean("EsRetencionIIBB"))
        // end @emmie
            return getPayAmt();
        // @mzuniga Se agrega COALESCE (Evita Null Pointer Exception cuando
        // no se trabaja en una Cabecera)
        String sql = "SELECT COALESCE(SUM(currencyConvertRate(al.Amount,"
                + "ah.C_Currency_ID, p.C_Currency_ID, al.TasaDeCambio)), 0) "
            + "FROM C_AllocationLine al"
            + " INNER JOIN C_AllocationHdr ah ON (al.C_AllocationHdr_ID=ah.C_AllocationHdr_ID) "
            + " INNER JOIN C_Payment p ON (al.C_Payment_ID=p.C_Payment_ID) "
            +  " LEFT JOIN LAR_PaymentHeader ph ON (p.LAR_PaymentHeader_ID = ph.LAR_PaymentHeader_ID) "
            + "WHERE al.C_Payment_ID=?"
            + " AND ah.IsActive='Y' AND al.IsActive='Y'";
        //  + " AND al.C_Invoice_ID IS NOT NULL";
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try
        {
            pstmt = DB.prepareStatement(sql, get_TrxName());
            pstmt.setInt(1, getC_Payment_ID());
            rs = pstmt.executeQuery();
            if (rs.next())
                retValue = rs.getBigDecimal(1);
        }
        catch (Exception e)
        {
            log.log(Level.SEVERE, "getAllocatedAmt", e);
        }
        finally
        {
            DB.close(rs, pstmt);
            rs = null;
            pstmt = null;
        }
    //  log.fine("getAllocatedAmt - " + retValue);
        //  ? ROUND(NVL(v_AllocatedAmt,0), 2);


        if (retValue != null)
            retValue = retValue.setScale(getC_Currency().getStdPrecision(), RoundingMode.HALF_UP);


        return retValue;
    }  //  getAllocatedAmt

The other case is as follows: we created a custom model by extending MInvoice and its corresponding ModelFactory. The issue occurs when completing a Point of Sale (POS) order because it calls the createInvoice() method, which creates an object of type MInvoice but does not use our custom class, meaning our LAR_MInvoice model is not instantiated.

Thank you in advance.

Best regards,

NB: We plan to publish the plugins that make up the LAR localization once we have minimally stabilized them.

Emiliano Pereyra.

[Carlos Antonio Ruiz Gomez]

Hi Emiliano, it doesn't sound easy, maybe you need to re-formulate your issue in terms of "how my invoice differs from the core" and develop POST event handlers to manage the situation.

Similar with MPayment.getAllocatedAmt - where is it called?  Can you customize all the calling points?

There is an open ticket at IDEMPIERE-2849 where we have discussed the possibility to change core to call custom model classes, it was discussed in the 2015 workshop, and it has been stagnated as it can be a massive change.

Regards,

Carlos Ruiz

Am 06.11.23 um 14:34 schrieb Emiliano Pereyra:

[Heng Sin Low]

For customization to core model that can't be replaced by extension mechanism, you can perhaps try to extract that changes to core - it can be either an enhancement to core or making it configurable in core or making it an replaceable OSGi interface in core.

--
You received this message because you are subscribed to the Google Groups "iDempiere" group.
To unsubscribe from this group and stop receiving emails from it, send an email to idempiere+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/idempiere/5f011252-debe-4c5f-b49b-00375616f54bn%40googlegroups.com.