The workshop at the 2025 conference started without a fixed agenda. This page is used for a transcript of what we did there.

JIRA tickets

You can find all JIRA tickets we created or touched here:

https://idempiere.atlassian.net/issues/?jql=labels%20%3D%20%22Budapest2025%22

first day

ZK EE license

Eduardo asked the zk project how this can work. The outcome is: It can't. We can not use the EE version in the iDempiere open source project. zk charges 2.500 $ per developer per year. But it is possible for an implementor to use zk EE and pay for it. It should be possible to replace our version of zk with the EE version.

Norbert had the idea to ask the zk people to cooperate in some way.

change the workshop name

Someone did not like the name "developer workshop". What we do is more like a brainstorming, a panel, a roadmap discussion or a "product conference".

Edit after conference -> at the end we said this is a problem for next conference, asked ChatGPT for ideas and these are the results:

Forge, Conflux, Coreweek, DeepSync, Stackmeet, Strata, Foundry, Nexus, Kernel, Blueprint

mobile interfaces

Carlos says that a lot of people are replacing small parts of the iDempiere UI with nicer looking UIs using the REST interface. That is important not only to solve spcialized (mobile) problems but also to attract new users and be more modern and to attract new developers.

Lin uses Flutter and has an implementation that he is willing to contribute.

We want to have good libraries.

The options are already used

Flutter (Lin, Murilo-native, Eduardo Gil, Marco Longo)
Angular (Deepak, Norbert Bede)
React (Diego Ruiz, TrekGlobal, Evan Sutherland/Ross Thein, Crispian Blackbourn, Murilo-web)

What do we need for a library

REST -> Login/Auth/Role
config

We talked about to have a list of apps that we already build and have working. But it is hard to do that because most mobile apps are to solve very specific problems. There is not really an app that can solve a lot of problems in a fast and flexible way (zero code/low code).

Carlos asked: With the given REST interface we can not replace ZK. What is missing to do that? If we solve this missing parts we can do a flexible app that can be configured through the ad as we are used to in the ZK interface. Carlos opinion is that only Callouts are missing.

Doing Callouts in REST context is not so easy because REST is stateless. An idea is to do callouts in javascript in a restricted way that can work through REST.

That will allow us to create zero-code mobile frontends.

Eduardo says that we are not thinking like a user but thinking like a developer when we only think about how to improve our given framework.

Carlos says that Compiere solves the need to fill other fields not with Callouts in a programming language but in the application dictionary.

Deepak says that webhooks are not possible without code.

BI

additional dimensions

Lin and Thomas asked to have more dimensions. As more dimension we can use as more powerful the BI is.

The "BI group" may think about which additional dimensions we need and how we define them. Business Intelligence

Layda, Carlos, Lin and Thomas like to work on that and invite others to join the "BI group".

BI Cubes

We want a view as a starting point. Implementors can extend this for their own needs.

We have already a cube for financials. Fact_account_Summary is created from Fact_acct. In general it summarizes dimensions.

Cubes that we may need:

Sales Cube (BI_Fact_Sales)
Purchase
Materials
Costing
human resources

There was some discussion how to implement it. As a view or a materialized view or a copied table or on a specialized BI database. We agreed that this is a problem to be solved by an implementor. The role of this issue here is to define a view as a stating point for implementations that belong to the customer needs.

things to show

We want examples with internal charts and also to superset.

Norbert Bede showed in the conference his solution to have BI dashboards based on the internal charts.

superset

We want example vies in superset for different cases.

Can superset views be integrated in idempiere? For example in the quickinfo area or as a field? What about authentication?

QuickInfo

QuickInfo is also a good way to show BI information to the user. Diego has the idea to create a place to upload and share these things.

LibreOffice Examples

We can do examples how to get useful data out of iDempiere in LibreOffice through the Base.

create a BI Plugin

We can do a BI plugin as a base that includes everything we want to add.

new dimensions (or better have them in core from the beginning?)
view definition
example charts
columns in some records that show charts
quickinfo that works on our view

Demo server

We want to show that in garden world.

For this we also need additional demo data to show.

webhooks

Example usecases:

An employee arrives at our building. There is a device to take the fingerprint. This devices uses an HTML webhook uri to notify our server about this event. In iDempiere we need code to deal with that.
biometrics
update something
trigger a process

Murilo already has an implementation and uses that e.g. to communicate with banks.

Authentication is an issue to think about. (basic, token, certification)

The payload can be encrypted and in different formats and has to define an endpoint. In some cases third party providers define the format and payload. It can be possible that someone implements e.g. an implementation to connect from shopify and share it.

It seems that it always needs coding to implement new webhooks. Is it possible to do it in a generic way?

Shall we implement this in the REST plugin or not? That means it can use the authentication framework of REST. But it does not really belong to REST).

Carlos likes to open a jira ticket to create a table to define the common data we need and have some code that may be extented by plugins for special needs.

product versus project

Diego talked about his research about Marketing of an Open Source Project. He talked about the roles of the stakeholders like developers, implementors/consultants/end-users.

We do good marketing for developers and DX. We need a strong focus on implementors because they are growing the project. We do not really have to care about end-users because implementors should do that.

Eduardo added that there are also "functional implementors". These use him as a master dealer and he is a communication channel to developers. He provides coding services and certifies plugins and the like to his partner network.

A question is how can we help implementors.

We talked about how to improve the documentation:

basic documentation
basic how-to
context documentation
onboarding
walkthrough
Implementor documentation / onboarding

The product/project issue is about verticals/regions/cultures.

Naomi is also a quite new member of the iDempiere community but also has experience in ERP. Norbert asked her to explain her view to these things. Her points were:

easy access to system capabilities.
find your way in the wiki pages
better overview of plugins (Carlos had the idea of a moderated explanation of the most used plugins)
she did not know that Mattermost exists until being on the conference

We talked a lot about documentation and how we can improve it and make it more available and of use for new users and implementors.

second day

UI improvements / business model as a project

Reka Bede did an insightful brainstorming about her (and our) ideas. We filled a "lean business model canvas" to collect an overview. (Link here...)

Then the discussion moved to the implications that has for the ui. What are the problems we have and what do we want to solve.

We could identify a lot of interesting points and identified some problems but had not the time to come to solutions. Reka proposed to continue this exercise in the community. Diego proposed to call for help in the community and do an online gathering and continuing as a ui/ux meeting.

iDempiere as a framework

When we do that we want to have a different name for the framework. Like "The Killer Framework" or "AD Nexus".

challenges:

db dump
keep database aligned
multiple repositories
we can do plugins of the erp parts like sales, plugins, accounting, etc.
Carlos says that it is a big work to separate the "erp plugin"
all model classes are in a single plugin - we have to split package for model classes
Eduardo started a discussion about if can have one single erp plugin or several plugins
the contribution process gets harder
the framework includes not only AD_ but also some of the C_ tables
we might have issues with foreign keys
idea: use migration scripts instead of dumps
another idea: separate dumps

There can be an interest group with interested developers: Carlos, Hengsin, Deepak, Murilo, Marcelinho and more people from Murilos company (they already did a proof of concept).

single sign on multi tenant

That is already done and thought about from Carlos and Deepak. They are very close to find an solution and will develop it. There is no need to discuss that any further.

btw: sso (single sign on) is already working well. This issue is about multi tenant, multi provider, multi account.

perpetual accounting

Deepak asked who is using perpetual accounting. We discussed some ways how to use periodic or perpetual accounting. Both ways are easily possible in iDempiere. At the end it is just a matter of which numbers you take from the database.

Deepak wants to add a way of accounting that inventory changes are not accounted as cogs (cost and goods sold) during the year and do manual correcting postings at the end of year. Norbert has a solution for that. Deepak will have a look into it and may open a ticket for it.

AI

The question is: How can AI be used in iDempiere? As AI is still a moving target we are not sure how to use it or trust it.

print format customization
test coverage
natural language query
identify duplicate records
interpret incoming PDF invoices (Peter Shepetko did that on a video: https://youtu.be/TZ6-rFWETMY?si=CchGvItk2a3CuH-_ - See other videos of peter's channel about AI)
voice instructed natural language document creation
AI model provider
chat ai
mattermost public chats, google groups, etc.
data mining, forecasting

plugin standardization

Murilo wants to have a better way to create new plugins. He now uses the scaffold. It often has too much things to delete because he does not need anything. His idea is to have a plugin standard to use. It may be good to have templates or the like.

Our idea is to create a tool that asks questions what exactly the developer wants to do and creates exactly the template that we need. The question can be answered from a property file.

Some people (Murilo, Carlos, Eduardo, Saul (creator of scaffold)) like to think to create a tool for that or improve the scaffold repository. Perhaps AI can help.

first impression

It will help us to inject more test data into GardenWorld. There is a plugin to create random data (done by Igor/Norbert). Carlos thinks how this can be started in the installation process. It may be started as a process (how?) or as an app or we create a migration scripts with that data.

process for analysis, design and development

The process to do that in idempiere is not standard. It is not easy and not useful to force that. But we have some best practices. The most important way is to go to mattermost or forums and open a topic.

Can we improve that? Is there a better way?

We can define standard ways to define tables and windows as a documentation document.

All discussion of push request should be in the jira tickets. That is a problem because git pull requests have their own discussions.

Eduardo say there is a jira plugin to help with that (Diego found a plugin called "exalate"). But it is better to define rules that the git discussion is only used for code issues and not functional issues. That might work because only core developers have to agree on that.

Carlos explained a case where he thinks that people should be notified on some topics on mattermost or the like. We discuss how to do a kind of notification or subscription. Diegos idea was to use hashtags. But we did not agree how it can be done at best. Atlassian has a tool to talk on ideas that are not (yet) tickets.

documentation

Norbert want to speed up documentation efforts. His plan is to work with Murilo to generate content for a better documentation. Carlos and Thomas wanted him to write his content into the given Docusaurus installation. Carlos invites them to join the documentation team.

Murilo uses Java code to create documentations from the application dictionary and another too to get screenshots from iDempiere using selenium.

The Meetings of the documentation interest group have been every friday. Carlos offers to do it asynchronously if people have not the time to join on time or are in another timezone.

IDempiere workshop 2025

Contents