Velgrina Türkiye runs on Magento with a Hyvä storefront. My work on the platform included a collection of custom modules covering local operational needs, including Trendyol integration and UBL e-invoicing. The storefront was only one part of the system that the business needed to operate.
A marketplace, a store and an invoicing service can all refer to the same commercial activity while representing it differently. The engineering work is in making those representations agree where they must, and keeping their differences visible where they matter.
Give every external identity a place
An internal product identifier, a SKU and a marketplace listing identifier serve different purposes. The same is true for a store order, an external order reference and an invoice number. Treating those values as interchangeable creates ambiguity when someone has to investigate a mismatch.
For integrations of this kind, I want the mapping to be explicit. Support should be able to start with the reference a customer or marketplace supplies and find the corresponding store record. A developer should also be able to determine which external operation produced the current local state.
This is a design and diagnostic principle, not an argument for copying every external field into the commerce model. The application needs enough context to explain the relationship and recover work safely.
Integration state is separate from order state
An order can exist successfully in the store while a downstream synchronization is pending or has failed. Combining those situations into one generic order status makes recovery difficult. It can also confuse an operator who needs to know whether the sale itself is valid.
I review the business outcome and the integration outcome separately. Has the order been accepted? Has the external system received the necessary information? Does an operator need to correct data before retrying? Each question has a different answer and a different next action.
A concrete example is an invoice-related request rejected because a required field is missing. Repeating the same request without changing the input does not solve the problem. The operator needs the rejected field and the relevant record, expressed in terms they can act on.
Standard formats still need business validation
UBL provides a structured document format, but producing structured data is only part of an invoicing integration. The application also has to supply the right business information and handle the receiving service’s response. A document that can be parsed is not automatically an accepted or correct invoice.
The useful engineering boundary is to distinguish preparation, submission and acknowledgement. For a review, I trace the identifiers and outcomes across those stages. If a request times out, an operator should have a way to determine whether the destination accepted it before initiating another submission.
Specific invoicing requirements depend on the integration and its current rules. This project note describes the software boundary; it does not substitute for the accounting or regulatory decisions behind the document.
Custom modules need clear ownership
A Magento codebase with many extensions benefits from knowing which module owns each responsibility. Catalog mapping, marketplace communication and invoicing should have understandable boundaries. Otherwise a change intended for one channel can have an unexpected effect on another.
My review checklist includes module configuration, disabled integrations, malformed external data and failures that occur after a local operation has succeeded. I also ask whether an operator can see what happened without reading application code.
Velgrina Türkiye brought commerce development and local integration work together in a live platform. The important lesson is that automation has to include the moments when systems disagree. A maintainable integration preserves identity, makes progress visible and gives people a clear way to recover the unfinished part of the job.
Updated 26 September 2026.