mansi75 commented on code in PR #6106:
URL: https://github.com/apache/fineract/pull/6106#discussion_r3571865428
##########
fineract-accounting/src/main/java/org/apache/fineract/accounting/producttoaccountmapping/service/ProductToGLAccountMappingReadPlatformServiceImpl.java:
##########
@@ -257,21 +259,23 @@ public List<ChargeToGLAccountMapper>
fetchPenaltyToIncomeAccountMappingsForSavin
private List<ChargeToGLAccountMapper>
fetchChargeToIncomeAccountMappings(final PortfolioProductType
portfolioProductType,
final Long loanProductId, final boolean penalty) {
- final List<ProductToGLAccountMapping> mappings = penalty
- ?
productToGLAccountMappingRepository.findAllPenaltyMappings(loanProductId,
portfolioProductType.getValue())
- :
productToGLAccountMappingRepository.findAllFeeMappings(loanProductId,
portfolioProductType.getValue());
-
- List<ChargeToGLAccountMapper> chargeToGLAccountMappers =
mappings.isEmpty() ? null : new ArrayList<>();
- for (final ProductToGLAccountMapping mapping : mappings) {
- final GLAccountData gLAccountData = new
GLAccountData().setId(mapping.getGlAccount().getId())
-
.setName(mapping.getGlAccount().getName()).setGlCode(mapping.getGlAccount().getGlCode());
- final ChargeData chargeData =
ChargeData.builder().id(mapping.getCharge().getId()).name(mapping.getCharge().getName())
- .penalty(mapping.getCharge().isPenalty()).build();
- final ChargeToGLAccountMapper chargeToGLAccountMapper = new
ChargeToGLAccountMapper().setCharge(chargeData)
- .setIncomeAccount(gLAccountData);
- chargeToGLAccountMappers.add(chargeToGLAccountMapper);
- }
- return chargeToGLAccountMappers;
+ // The accounting module is decoupled from the charge domain, so we
cannot navigate a Charge association in
+ // JPQL. We read the charge -> income-account rows via JdbcTemplate
rather than a JPA native query: EclipseLink
+ // does not bind Spring Data ":name" parameters in native queries (it
expects "#name"), which caused the raw
+ // markers to reach the database. JdbcTemplate uses plain JDBC
positional binding and works on all supported
+ // databases. The GL account fields are selected via a join on
acc_gl_account so we avoid a per-row lookup.
+ // Column order: [0] gl_account_id, [1] gl_account_name, [2] gl_code,
[3] charge_id, [4] charge_name.
+ final String sql = "select ga.id, ga.name, ga.gl_code, c.id, c.name "
+ "from acc_product_mapping apm "
Review Comment:
@adamsaghy I agree. The native SQL moves the coupling to the schema rather
than removing it.
'financialAccountType' already distinguishes these on our own row, and the
update path in 'ProductToGLAccountMappingHelper' already uses it so the read
path can too, no charge navigation. Only the charge name needs the charge
module.
I'd propose charge depends on accounting, interface in accounting, impl in
charge (ChargeData is already in core). Is this right to proceed with?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
