Skip to content
Sunny Calculator Add-On

ADR-013 - External APIs

Statusaccepted
Date2025-04-14
Decision MakersDardan Bujupaj (AX), Marc Gähwiler (AX), Markus Brenner (Griesser)

Context

The Sunny Calculator AddOn needs to get information for creating sales offers – things like product details, customer-specific discounts, and maybe even production info. It also needs to handle mark-ups/downs and generate the final offer document. We have a few existing systems: Sunny Konfigurator, CRM, Microsoft Dynamics 365 (ERP), a Pricing API (within Sunny Konfigurator), and Betterna (part of FS&SCM) for complex discounts. The CRM is the main place for customer info and acts as a central point for connecting to other systems. The plan is for the AddOn to only talk to the CRM, and the CRM will handle the rest.

Decision

The Sunny Calculator AddOn will only interact with the CRM for all its external data and functions. The CRM will be responsible for getting or delegating calls to these other systems as needed:

  • CRM: The Griesser CRM is the central hub for managing customer information, including tailored discounts, the status of sales offerings, and efficient coordination with other systems.
  • Sunny Konfigurator: For product configuration details needed to build offers in the AddOn (product options, customizations, maybe base pricing).
  • Microsoft Dynamics 365 (ERP): If we need production lead times or material availability info for the sales process within the AddOn (e.g., delivery estimates), the CRM will get this from the ERP.
  • Pricing API (Sunny Konfigurator): The CRM will use this to calculate initial discounts based on project details before considering customer-specific or complex discounts.
  • Betterna (via FS&SCM): For the final, more complex discounts based on the customer and product specifics, the CRM will talk to Betterna (likely through FS&SCM).
  • Document Generation API (within CRM): To create the final offer document with all the details configured in the AddOn (base prices, discounts, mark-ups/downs, final prices), the AddOn will trigger a process in the CRM.

Consequences

Here’s what this means:

  • Positive:

    • Simpler for the AddOn team – they only need to integrate with one system (the CRM).
    • All the work of talking to other systems is in one place (the CRM), making it easier to manage.
    • Better chance of consistent data since everything goes through the CRM.
    • Clear who’s responsible for what – the CRM is the integration hub.

  • Negative:

    • The CRM might get more complex having to talk to all these other systems.
    • The CRM could become a bottleneck if it has to make lots of calls for each AddOn request. We’ll need to make sure it’s efficient.
    • The AddOn’s features will depend on what the CRM can do and how well it talks to the other systems. If the CRM has issues, the AddOn might too.
    • The CRM might need to do some translating of data between the AddOn and the other systems, which adds to its workload.

Alternatives

We thought about these other ways:

  • AddOn talks to everyone directly: The AddOn could directly connect to the Sunny Konfigurator, Betterna, and maybe even the ERP.

    • Pros: Could be faster to get specific data, less load on the CRM.
    • Cons: Makes the AddOn much more complex, harder to maintain, potential for inconsistent data, more security risks with more connections. We decided against this to keep the AddOn simpler.

  • A special helper service for the AddOn: We could build a new service just for the AddOn to handle all the external API stuff. The AddOn would only talk to this helper.

    • Pros: Keeps the AddOn clean from dealing with lots of different systems, allows for custom data handling for the AddOn.
    • Cons: Means building and managing another service, which costs time and resources. We figured the CRM could handle this role for now.

  • Putting business rules in the AddOn: Instead of always relying on the other systems, we could put some of the business logic (like some discount calculations or checks) directly into the AddOn.

    • Pros: Might make things quicker for the teams managing the other systems. Could speed up some AddOn features if the other systems are slow to implement things.
    • Cons: Big risk of having the same rules in multiple places, leading to different prices and calculations. We could lose control over important business processes if an external company (who might build the AddOn) puts this logic in. This could make future updates and keeping things consistent really difficult and expensive. We really don’t want to go down this road because of the risk of inconsistent data and losing control.