// Overall architecture and module depth
Experience & expertise
I take responsibility for the overall architecture and at the same time I am at home in three modules: transport, sales and procurement. That is no coincidence. A process that is meant to run seamlessly does not stop at the module boundary, and that is exactly where most problems arise.
Years of professional experience
Years in SAP projects
Certifications
Academic degrees
// Focus areas
Three core modules and the view beyond them
I look after SD, MM and TM in depth: configuration, enhancements, troubleshooting. Above that sits the overall architecture. Both together are the point, because a process that is meant to run seamlessly does not end at the module boundary.
Overall architecture and perspective
End-to-end process design across module and system boundaries. That includes knowing what happens in the neighbouring areas: warehousing, production, financial integration, master data concepts, interfaces and reporting. I do not have to be able to configure all of them. I do have to know where my process touches them.
Transport Management
Freight demand, freight unit building, planning, carrier selection and settlement. From the delivery through to the credit memo for the carrier, including recharging to the customer by actual cause.
Sales
Order-to-cash from pricing through availability check and shipping to billing, rebate settlement and the returns process.
Procurement
Source-to-pay from source determination through release strategies and goods receipt to invoice verification, including consignment, subcontracting and third-party orders.
// The end-to-end view
Modules are tools. The process is the goal.
Most disruptions do not arise inside a module but between two of them. A condition type in sales helps decide what transport is allowed to cost. A freight cost item belongs in the customer invoice at the end. An inbound delivery from procurement needs planning just as much as an outbound one.
Anyone who only knows one module does not see the break. They only see that the figures do not add up at the end of the month.
// Interplay
Where the modules touch
// SD Sales
Order-to-cash
From the quotation to the incoming payment. The chain in which badly set conditions are the most expensive, because they affect every single invoice.
Typical questions
- Prices are constantly overridden by hand in the order instead of coming from conditions
- Customer hierarchies and discount structures live in Excel rather than in the system
- Delivery notes carry texts that somebody pasted in
- The availability check confirms dates the warehouse cannot keep
- Collective invoices and billing plans are put together manually
- Annual rebates are calculated outside the system and posted afterwards
- Returns run as a credit memo request with no process behind them
- Documents are sent by hand although output determination could do it
// MM Procurement
Source-to-pay
From the requirement to the payment. This is where it is decided whether purchasing conditions, releases and invoice verification fit together or block each other.
Typical questions
- Purchase orders are created without source determination; source lists and quota arrangements lie idle
- Release strategies do not reflect the actual organisation
- Freight costs in the purchase order are posted afterwards instead of planned
- Outline agreements and scheduling agreements exist but are never called off
- Invoice verification blocks too much or too little because tolerances were never adjusted
- Consignment and subcontracting are mapped through workarounds
- Stock transfers between plants run without a delivery and therefore without any transport view
- Evaluated receipt settlement would be possible but is not used
// TM Transport
The transport chain
From the freight demand to the settlement. The area where people most often work in Excel alongside SAP, although all the data is already in the system.
Typical questions
- Transports are planned in Excel although the deliveries are in the system
- Freight units are created by hand; building rules were never defined
- Carrier selection follows habit instead of a ranking list or a tendering process
- Dock time slots are assigned by telephone
- Freight costs only become visible with the incoming invoice, not already during planning
- Recharging to the customer is done as a flat rate instead of by actual cause
- Self-billing has been agreed but fails on the master data
- Status messages from execution end up nowhere in the system
// Standard first
SAP can do more than you may be using
Many systems have been running for years as an expensive typewriter. Documents are entered, prices overridden by hand, texts copied, reports rebuilt in Excel. Yet a large part of this has long been in the standard. It has simply never been switched on.
Pricing
Scales, customer hierarchies, time-dependent conditions, surcharges and discounts, freight shares. What somebody carries around in their head today belongs in the pricing procedure.
Text determination
Order, delivery and invoice texts are pulled from the customer and material master. No copying, no forgotten notes on the delivery note, no translation by hand.
Output determination
Every document goes automatically to the right partner, in the right format, through the right channel. All the way to the electronic invoice and the eDocument.
Rebate settlement
Condition contract settlement calculates annual, scale and supplier rebates in a traceable way, accruals included. Instead of an Excel file everyone dreads once a year.
Partner and account determination
Who is the ship-to party, who is the payer, which revenue account the item posts to. That is a setting, not a daily decision.
Releases and tolerances
Value limits, substitution rules, blocking reasons in invoice verification. Control that happens in the document instead of in an approval email.
// Attitude
The most expensive development is the one that was never needed
Every custom development costs twice: once when it is built and then again with every release change, every test and every bug hunt. In more than eleven years of SAP projects I have seen a lot of custom code and written enough of it myself to recognise when it pays off and when it merely replaces a setting nobody found.
That is not a dogma. Where the standard really is not enough, I build the enhancement, through the SAP Enhancement Framework or through BAdIs. But only after that.
The harder part of this work is rarely the technology. It is the conversation with the business about why the familiar workaround is no longer needed in the new system. I enjoy that conversation, and I have it with examples rather than principles.
// Teaching and training
Passing knowledge on
Teaching forces you to explain something so that a person who has never seen it understands it. I need the same skill in a project, when a department wants to know why a document looks the way it does.
External lecturer at Salzburg University of Applied Sciences
I teach the course Business Standard Software. It runs from business processes through the system landscape to a hands-on part in which the same workflows are built once in SAP S/4HANA and once in Odoo.
Official trainer for SAP courses in SD and MM
Teaching the official SAP course material means knowing the standard down to its edge cases, and knowing it well enough to explain it. What I notice in training I take into projects. And the other way round.
What the course covers
- Business processes: how an order moves through a company, before software is even mentioned
- The system landscape: BI, CRM, MES, WMS, TMS, SCM, HR, ITSM and ERP, and which system you actually need for what
- Standard software or in-house development: the make-or-buy decision and what it costs over the years
- ERP systems: benefits, vendors, modules, configuration, modification and cloud operation
- Architecture: data model, three-tier architecture, three-system landscape, operating models
- Implementation: SAP Activate, project team, best practices, requirements management, and the question of why ERP projects fail
- Core concepts: organisational structures, master data, documents, worklists, material requirements planning, availability check, stock valuation
- Hands-on work on two systems: source-to-pay and order-to-cash in SAP S/4HANA, the same processes in Odoo for comparison
Running the hands-on part on two systems is deliberate. Anyone who has built the same process once in S/4HANA and once in Odoo can tell the difference between a concept and a screen afterwards.
Career path
From dispatcher to ERP solution architect.
Truck dispatcher, transport logistics
Supply chain management, paper industry
Process engineering, pharmaceutical industry
Bachelor of Science, Business Administration
SAP consultant at an SAP partner
SAP Solution Architect, SAP Austria
Technical Specialist, Microsoft Austria
Master of Science, Business Informatics
Founded and managing RONCON IT-Consulting
// Trainings
Certifications
At the centre are the three current S/4HANA certifications for transport, sales and procurement. Every credential is verifiable on Credly.
C_S4TM · 17.01.2025
C_TS462 · 17.10.2025
C_TS452 · 13.04.2025
Further SAP certifications
- SAP Professional Architect19.11.2020
- SAP MM S/4HANA Sourcing & Procurement09.04.2019
- SAP SD S/4HANA Cloud Sales18.04.2019
- SAP SD S/4HANA Sales Upskilling01.03.2019
- SAP ABAP Workbench06.05.2019
- SAP ABAP Advanced
- SAP S/4HANA (TS410)
Microsoft certifications
- Microsoft Azure Fundamentals15.09.2021
- Dynamics 365 ERP Fundamentals28.10.2021
- Dynamics 365 Supply Chain Management21.12.2021
- Power Platform Fundamentals11.01.2022
- Power Platform App Maker25.01.2022
// Credentials
Publicly verifiable
You do not have to take my word for any of it. Both are visible without signing in.
Certifications at the source
Every certification listed above is held as a verified credential on Credly, issued by SAP or Microsoft. You can see the issue date and validity there.
Blog posts and answers
In the SAP Community I write about configuration topics and answer questions from SAP users, mostly on sales, procurement and transportation. If you want to see how I approach a problem, that is where to read it.
SAP, Credly and the FH Salzburg logo are trademarks of their respective owners. See the legal notice.
Project references and CV
I am happy to send you an overview of my project references and my current profile.