Before writing a single line of code for the Open Mercato financial module, we spent an entire day in front of a wall covered in sticky notes. Developers, members of the platform's core team and an expert with first-hand accounting experience all came together in one room.
The outcome surprised us. It was only when we mapped out the entire process that we realized just how many of its elements were interconnected. This is the second part of our series on the Open Mercato financial module – in the first, we explained why we're starting with the chart of accounts and general ledger.
We had two reasons for bringing everyone together. First, we wanted the entire team to share the same understanding of accounting processes, rather than having several different ideas of how they worked. Second, we wanted to make sure that domain knowledge wasn't concentrated in one person.
The workshop wasn't intended to produce documentation, set a budget or estimate development costs. Before any of that, we needed to understand how financial operations actually work and which dependencies we would need to account for as we developed Open Mercato.
Instead of presentations and architecture diagrams, we had a wall and a lot of sticky notes. We arranged business events in the order in which they actually occur. Alongside them, we recorded the rules defining what must happen before a particular event can take place, as well as questions we couldn't yet answer or disagreed on.
That's what Big Picture Event Storming looks like in practice.
This gave everyone a shared view of the process. At that stage, we weren't trying to fit it into the system's architecture.
Read the first part of the series: We're Building the Open Mercato Financial Module – Starting with the Chart of Accounts and General Ledger.
The workshop took place on September 5, 2026 in Katowice and was facilitated by Mariusz Gil. Our domain expert was Mateusz Duda, a financial controller at incro who previously worked as an accountant and has hands-on experience with closing accounting books.
The technical side was covered by Commerce Weavers developers and the Open Mercato core team.
Having the people who develop the platform in the room meant we could clarify which mechanisms were already available in Open Mercato as questions arose. Whenever we needed to understand what the platform could do, we could get an answer that same day rather than postponing the discussion.
The most important discovery of the workshop was the actual scope of the financial processes.
We started with company data configuration and ended with year-end closing and preparation for the next accounting period. By the end of the day, we had mapped seven interconnected stages on the wall:
Configuration: Company details, fiscal year, chart of accounts and opening balance sheet.
Accounting entries: Assigning accounting entries to documents and recording transactions in the ledger.
Purchasing and accounts payable: Purchasing operations and the resulting liabilities.
Sales and accounts receivable: Sales processes and receivables settlement.
Banking: Bank transactions, bank statement reconciliation and debt collection.
Reporting and month-end closing: Reports, period closing and taxes.
Year-end closing: Closing the fiscal year and filing financial statements with the Polish National Court Register (KRS).
The final stage led straight back to the opening balance sheet for the new year. What we were looking at wasn't a collection of separate features, but a complete cycle of interconnected processes.
We thought we knew how big this module would be. We didn't.
This map is not a list of features already available in Open Mercato, nor does it represent the scope of a single development iteration. It shows the processes and dependencies we explored during the workshop.
The second outcome was a Polish-English glossary of accounting terminology, reviewed and corrected by our domain expert.
A good example of why precise terminology matters is the difference between red storno and black storno, two methods of reversing accounting entries. With red storno, an entry is reversed using negative amounts on the same sides of the accounts. Black storno records the same amounts as positive values, but on the opposite sides (debit instead of credit, and vice versa).
Both methods are valid, but they produce different account turnover figures. If the data model supports only one of them or treats them as interchangeable, the trial balance will no longer match the accountant's expectations. Reconstructing and auditing transactions will also become more difficult.
This is why establishing a shared glossary was more than a formality. It helped us make sure that the people responsible for accounting and those developing Open Mercato were using the same terms with the same meanings.
The third outcome of the workshop was a list of issues that still needed clarification.
In some areas, we were missing information. In others, we had different interpretations of the process. Rather than making assumptions we hadn't verified, we recorded questions for further discussion.
An ambiguity discovered before implementation can be resolved during design. The same uncertainty discovered in a finished solution may require parts of it to be rebuilt.
We didn't need to end the day with every question answered. What mattered was knowing exactly what still needed to be checked.
Before designing a complex part of a system, it's worth looking at the entire process through the eyes of the people who work with it every day, then comparing that knowledge with the platform's technical capabilities.
Event Storming, a technique that originated in the Domain-Driven Design community, is particularly useful here because it forces us to describe a process in terms of events rather than features.
And this isn't limited to accounting in Open Mercato. A similar workshop can be held before developing order management, returns or another complex business process.
Event Storming is a workshop-based method for modeling business processes. Participants arrange events on a wall in the order in which they occur, and record the rules and unanswered questions next to them. In the Big Picture variant, the goal is a shared view of the entire process before the team starts designing the system.
During the workshop, we mapped seven interconnected stages: configuration, accounting entries, purchasing and accounts payable, sales and accounts receivable, banking, reporting with month-end closing, and year-end closing. This is a map of processes, not a list of features already available in Open Mercato.
Symfony is often described as a PHP framework, but at its core are around fifty independent libraries. Each solves a spe...
Read more →
Commerce Weavers is taking responsibility for building the Open Mercato financial module. The first iteration covers the...
Read more →
Choosing a framework may seem like a purely technical decision. In practice, however, it affects much more than how deve...
Read more →
