conneqt / module-sap-my-account

2.4.3 2026-08-26 11:18 UTC

Requires

• php: >=8.1
• conneqt/m2-module-sap-base: ^1.2.6
• dompdf/dompdf: *
• magento/framework: *
• picqer/php-barcode-generator: *

proprietary

Published on Packagist.org on 2026-08-26 12:29 UTC

README

What this module does

Conneqt_SapMyAccount adds SAP-driven pages to the Magento 2 customer account area.

Instead of showing only Magento-native account data, this module can expose customer information that lives in SAP, such as:

• account details
• addresses
• contact / management users
• order history
• invoice history
• quotations
• deliveries
• return requests
• backorders
• equipment card related pages

The module does this by adding customer account routes under my-account/*, fetching data from SAP through the conneqt/module-sap-base integration, and rendering the results with Magento blocks, templates, and controllers.

Release history is in CHANGELOG.md. Note the versioning is not strict semver — see the Versioning section there before assuming an upgrade is safe.

In short: how it works

At a high level the flow is:

1. A customer opens a page in the account area.
2. The module decides, based on configuration, whether Magento should use the SAP page or the default Magento page.
3. A controller loads a Magento page result.
4. A block requests data from SAP through one of the API helper classes.
5. Shared base blocks format, filter, paginate, and map the SAP data for the frontend.
6. URL translation logic can expose friendly or translated storefront paths while still resolving to the internal my-account/* routes.

Most list/detail pages in this module follow that same pattern.

Main concepts

1. Feature switches in configuration

Almost every feature can be enabled or disabled separately through store configuration.

Examples:

• dashboard
• address book
• management contacts
• orders
• invoices
• returns
• quotations
• deliveries
• backorders
• equipment cards

These values are read centrally by Helper/ScopeConfigHelper.php.

2. Customer to SAP mapping

SAP data is loaded for the currently logged-in Magento customer.

The key customer attribute is card_code (CardCode in the admin UI / customer data). This value must match the SAP business partner code for the customer. Some queries can also use internal contact-person filtering when the customer has the related custom attributes available.

Important note:

• the SAP base module must be configured with working credentials first
• the customer must have the correct CardCode
• the dashboard/account data assumes the Magento customer can be matched to SAP customer data

3. Shared list and detail rendering

The module has reusable base blocks for SAP-backed pages:

• Block/Base/Lister.php builds list filters, sorting, pagination, and API select fields
• Block/Base/Details.php loads one SAP document and prepares detail data
• Block/Base/MyAccountData.php formats values, dates, prices, and configured field mappings
• Block/Base/MyAccountBase.php handles common URL building and error handling

Because of these base classes, feature-specific pages such as orders, invoices, quotations, and deliveries usually only need small child classes plus layout/templates.

4. URL translation and custom routing

The module front name is my-account, but it can also translate storefront URLs using configuration.

• Controller/Router.php translates friendly storefront paths back to the internal module route
• Helper/UrlTranslationHelper.php converts between internal and translated URLs
• Block/Navigation/UrlNavigation.php uses that translation logic when rendering account navigation links

This makes it possible to keep internal routes stable while showing custom storefront paths.

5. Checkout address restrictions

When SAP account/address functionality is enabled, the module also adjusts the checkout address UI.

Block/Checkout/LayoutProcessor.php replaces parts of the checkout JS layout so billing and shipping address lists can be filtered by SAP address type, and so the frontend can respect whether creating new addresses is allowed.

Important files and what they do

Configuration

• etc/config.xml
  Provides default configuration values for all feature areas, list columns, detail columns, mappings, status options, and URL settings.

• etc/adminhtml/system.xml
  Defines the admin configuration fields shown in Magento.

• Helper/ScopeConfigHelper.php
  Main read-access layer for this module's configuration. Most controllers and blocks use this helper instead of reading raw config paths directly.

Routing and navigation

• etc/frontend/routes.xml
  Registers the module under the my-account front name.

• etc/frontend/di.xml
  Registers the custom router and checkout layout processor, and configures the custom frontend error message renderer for RMA errors.

• Controller/Router.php
  Rewrites translated storefront URLs back to the original internal route so Magento can dispatch them.

• Plugin/DashboardRedirect.php
  Redirects the standard Magento customer dashboard to the SAP dashboard when that feature is enabled.

• view/frontend/layout/customer_account.xml
  Replaces or adds customer account navigation links so account menu items point to SAP pages when enabled.

• Block/Navigation/UrlNavigation.php
  Renders navigation links that respect config switches and translated URLs.

SAP API layer

• Helper/Api/ApiBase.php
  Shared SAP API base class. It resolves the current customer and exposes helpers such as getCardCode().

• Helper/Api/ApiData.php
  Shared document-query layer for SAP lists and details. It builds OData filters, sorting, pagination, and date limits.

• Helper/Api/ApiAccount.php
  Loads and updates SAP business partner account data.

• Helper/Api/ApiOrder.php
  Small feature-specific API class for order data; child API classes for invoices, returns, deliveries, and quotations follow the same pattern.

Shared storefront blocks

• Block/Base/MyAccountBase.php
  Shared error handling and translated URL generation.

• Block/Base/MyAccountData.php
  Shared value formatting and mapping layer.

• Block/Base/Lister.php
  Shared grid/list behavior for SAP history pages.

• Block/Base/Details.php
  Shared detail-page behavior for SAP documents.

• Block/Base/Filter.php
  Builds the filter UI for list pages using configuration-defined fields.

Representative controllers

• Controller/Order/History.php
  Example of a feature controller that checks config, loads a Magento page, and renders a SAP-backed history page.

• Controller/Management/Save.php
  Updates or creates SAP contact employees for account management users.

• Controller/Rma/GuestCreate.php
  Creates a guest return request and redirects to the guest return details page.

• Controller/Download/Pdf.php
  Downloads document attachments from SAP-backed records.

Returns and guest return creation

• Helper/RmaCreateData.php
  Builds the payload sent to SAP when creating a return request. It validates request data, selects return lines, and recalculates totals.

  The submitted quantities pass through parseQuantity() first, which does two things.

  It rejects non-numeric input. The storefront quantity fields are free-text inputs, so a cleared or client-side mangled field can post '' or 'NaN'. PHP 8 compares a non-numeric string to 0 as a string, so 'NaN' > 0 is true: the value passes the loose quantity check and then throws a TypeError on the total calculations, which the controller reports as the generic "contact support" error. Anything non-numeric therefore counts as nothing to return.

  It also caps each line at the Quantity the order actually contains. The form's max attribute was the only limit before, so a crafted post could return more than was ordered — SAP would accept the payload and the totals would be recalculated from the inflated quantity. An over-max quantity is clamped silently rather than rejected, matching what the frontend already does on change. Note the cap is against the ordered quantity only: it does not account for quantities returned earlier on the same order.

• Block/Order/ReturnRequest.php
  Trait holding the return-request availability rules: the return_request feature switch, the create_days_limit window checked against the document's DocDate, and the request URL. It is used by both Block/Order/Lister.php (the "Request Return" action per order row) and Block/Order/Details.php (the same button on the order detail page), which descend from different base classes.

  Block/Base/Details.php declares canRequestReturn() returning false so the shared base/details/header-buttons.phtml template can be used unchanged by the invoice, delivery and quotation detail pages; the trait overrides it for orders. Order detail blocks add DocDate to their select fields because the window check needs it — a document without a DocDate is treated as no longer returnable rather than raising.

• Block/Rma/* and Controller/Rma/*
  Handle the return overview, detail pages, request form, guest search flow, and downloads.

Repair requests / equipment-related storage

• etc/db_schema.xml
  Creates the conneqt_repair_requests table used for stored repair request data.

• Model/RepairRequest.php and ResourceModel/*
  Provide the Magento model/resource layer for that table.

Supported feature areas

This module is structured around separate feature families. Depending on configuration, a shop can enable only the parts it needs.

• Dashboard: SAP-backed account overview and profile editing
• Address: SAP-backed customer address overview, create, and edit
• Management: manage contact employees / account contacts
• Orders: SAP order history and detail pages
• Invoices: SAP invoice history and detail pages
• Returns: return overview, request flow, guest search, and PDF/download support
• Quotations: SAP quotation history and details
• Deliveries: SAP delivery history and details
• Backorders: custom SAP query based backorder overview
• Equipment Cards / Repairs: equipment pages and repair request functionality

Setup notes

Required dependency

This module depends on conneqt/module-sap-base.

Before using this module, make sure the SAP base module is configured with valid API credentials in Magento admin.

Customer requirements

For a customer to see SAP data:

• the customer must be able to authenticate normally in Magento
• the customer record must contain the correct CardCode
• that CardCode must match the SAP business partner code

Admin configuration behavior

The most important configuration switches behave roughly as follows:

• Use SAP account: redirects account/dashboard navigation to the SAP dashboard pages
• Use SAP address: redirects the address book to SAP-backed pages and also affects SAP dashboard address output
• Allow creating new addresses: enables the create-address option in the SAP address area and checkout integration
• Use SAP order history: sends order history navigation to the SAP order pages
• Use SAP return request: adds the SAP return pages to the account navigation
• Use SAP invoice: adds invoice history to the account navigation

Backorders setup

Backorders are not loaded from a standard SAP endpoint in this module. A custom SQL query must exist in SAP.

Example request:

• Type: POST
• URL: {{base_url}}SQLQueries
• Body:

{
  "SqlCode": "GetBackorders",
  "SqlName": "GetOrderInfoForCustomer",
  "SqlText": "SELECT ORDR.DocNum, ORDR.DocEntry, ORDR.DocDate,ORDR.DocDueDate,RDR1.ItemCode,RDR1.Dscription as Description,RDR1.Price, RDR1.OpenQty, RDR1.Quantity FROM ORDR ORDR inner join RDR1 RDR1 on ORDR.DocEntry = RDR1.DocEntry inner join OCRD OCRD on ORDR.CardCode = OCRD.CardCode WHERE ORDR.DocStatus <> 'C' and RDR1.LineStatus <> 'C' and RDR1.OpenQty <> 0 and ORDR.CardCode = :CardCode"
}

Quick mental model for developers

If you are new to this module, the easiest way to understand it is:

1. Start with view/frontend/layout/customer_account.xml to see which account links are replaced or added.
2. Check etc/frontend/routes.xml and Controller/Router.php to understand request routing.
3. Open a feature controller such as Controller/Order/History.php.
4. Follow the feature block into Block/Base/Lister.php or Block/Base/Details.php.
5. Follow the API call into Helper/Api/ApiData.php and the feature-specific Helper/Api/* class.
6. Use Helper/ScopeConfigHelper.php to find the related configuration.

That path gives a good picture of how nearly all storefront features in this module are built.