Shopify DİA Integration

DİA is a cloud-native ERP and that makes two steps of the integration easier from the start: no server sits in between, and the invoice goes out on its own infrastructure without a third firm in the middle. Against that, this system has a mechanism no other pre-accounting or ERP product has: service calls consume credits. The connection is built with a web-service user, permissions also have to be defined on the desktop client, sync stops when credits run out, and an internet-sale invoice has rules of its own.

Talk to us about setup See the integration

200+ active brands
growing on Shopify with Nodus Works

Shopify DİA integration what is it?

A Shopify DİA integration is the connection that keeps store orders, customers, products, stock and price lined up with DİA. DİA stays at the center: the product leaves DİA with all of its variants and options, the order comes from the store into DİA and the invoice is issued in DİA.

Setup starts by opening a web-service user on the DİA side and giving it permissions. The critical detail here is that permission is not inherited: for every action that will be done through the service, that user also has to hold the same permission on the desktop client. Then matching, price and stock rules are defined. When details such as permission inheritance are missed and the connection does not work, Nodus Works' Shopify integration and custom app development service builds this setup from the start in the right order.

Once the connection is live, daily work runs from one place: the order lands in DİA with a customer account opened, stock and price are written from DİA to the store and the document goes out on DİA's own infrastructure. Because service calls consume credits, watching credits has to become an operational routine.

WHAT SYNCS

What syncs between Shopify and DİA

Once the connection is live, products, stock, price, orders, accounts and invoices become parts of the same flow. The six headings below cover the questions that come up most often in a Shopify DİA integration.

Product and variant transfer

A product entered in DİA comes to the connector with all of its variants and options and is listed in the store. This is one of the few examples among the systems we reviewed where the variant is written clearly in the official text; it makes the work clearly easier on catalogs with a color and size matrix.

Stock and price matching

Quantity and price are written from DİA to the store, so the catalog's truth sits in DİA. Changes are checked regularly and published to the store; which warehouse's stock is opened is defined during setup.

Transfer of Shopify orders into DİA

When the order is created in the store it is written into DİA and the customer's account card can open automatically. This automatic opening is convenient, against that it also brings the risk of the same person being opened as a customer account a second time.

Customer-account and customer matching

The buyer's details turn into an account card; if a card already exists it is matched to that. Which field the match is built on is the critical setup decision, because merging is done by hand later.

e-invoice and e-archive

Because DİA is a special integrator, the document goes out on its own infrastructure without a third firm in the middle. Bulk invoicing is also possible; the number and series come from DİA's document layout and a separate series is required for internet sales.

Cancellation and return flow

A return and a cancellation are not the same action on the DİA side; which one applies depends on the age of the document. Because an official step list for the return flow has not been published, this has to be made clear during setup with a test order.

ACCESS AND PERMISSIONS

How is the DİA connection opened?

Two details on this side set the whole project, and both are written in DİA's own documentation: permission is not inherited, and calls consume credits. Almost every case where the setup runs only halfway comes from the first.

Two cloud systems, no server in between

Because both the store and the ERP run in the cloud, a secure tunnel, a fixed address or on-premise server access is not required. The infrastructure step that eats the first week of a project on installed ERPs does not exist here at all.

The connection is built with a web-service user

A web-service user is opened on the DİA side and an access key is produced for that user. The connector runs with this identity; so what the integration can do is limited to what this user can do.

Permission is not inherited, it is defined separately

For an action to be done through the service, that user also has to hold the same permission on the desktop client. If there is no permission to list customer accounts, the service also returns a permission error; this is the number-one reason a setup runs only halfway.

Calls consume credits

Credits drop for every service call and the credit status is watched on a screen in the desktop client. Among the systems we reviewed this is the only one with such a mechanism; when credits run out, sync stops.

Every record is written into an accounting period

Firm code and period code are required on service calls; so which period every record is written into is clear from the start. After the period closes, no record can be opened in that period and the connector returns an error.

DİA does not build the connector

DİA has not published a Shopify app of its own; the connector comes from the solution-partner ecosystem and DİA introduces a solution partner that lists Shopify by name on its own site. The ownership line has to be clear in the contract.

The practical result of these six items is this: on the DİA side the project is not an infrastructure job, it is a permission and credit-planning job. Giving permissions one by one on the first day of setup and forecasting credit use against your order volume prevents the half-syncs that cannot be explained later.

SETUP

How is the Shopify DİA integration done?

The six steps below cover the full setup, from opening the web-service user through the first test order. Every step runs between the two panels.

Prepare the web-service user and its key

Open a web-service user on the DİA side and produce the access key. Make the setup path and the required modules clear together with the partner you work with through dia.com.tr.

Give permissions one by one on the desktop client

For every action that will be done through the service, the same permission also has to be defined on the desktop client. Check order-write, account-open, stock-read and invoice-issue permissions separately; a missing permission leaves the flow halfway.

Confirm firm and period data

Because firm code and period code are required on calls, confirm that the connection is built to the right firm and an open period. If you track more than one firm, this step decides invoices landing on the right taxpayer.

Define matching and the variant layout

Define which field products match on and how variants will appear in the store. Because DİA carries variants natively, the work gets easier here, but the matching key still has to be confirmed with a test record.

Choose price, warehouse, tax and invoice series

Decide which price will be written to the store, which warehouse's stock will be opened, how tax rates will be read and which series will be used for internet sales. How the shipping charge lands on the invoice is also defined in this step.

Verify the flow and the credits with a test order

Place an order with a single product and see that the order lands in DİA, that the customer account opens correctly, that stock drops in the store and that the document is issued on the right series. In the same test, measure how many credits a few actions consume and plan against your monthly volume.

The table below shows which Shopify records map to which counterparts on the DİA side.

What Shopify has	What it maps to in DİA
Order	Order record and account movement
Customer	Account card, can open automatically
Product	Stock card
Variant	The product's variant and option structure
Price	The price on the stock card or the selected list
Stock	Quantity of the selected warehouse
Tax	The rate on the stock card
Invoice	e-invoice or e-archive, from DİA infrastructure
Return	Return document or cancellation, depends on the window
No Shopify counterpart	Tax ID and legal-title fields; firm and period code; credits

The three items in the last row of the table are this system's own side. Because firm and period code are carried on every record, which period the record is written into is clear from the start; credits are a resource that has no counterpart on the Shopify side and is watched only on the DİA side.

Where are you in the setup?

Tell us about your catalog and current setup, and we will work out how the Shopify DİA integration should be built for your product structure. You do not need to fill in a form, reach us directly by phone, email or WhatsApp.

Get in touch 0850 888 2815 hub@nodusworks.com WhatsApp

CREDITS

What are credits, and how do they affect the integration?

On DİA's web service, credits drop for every call; some special calls such as login sit outside this and the credit status is watched on a screen in the desktop client. Among the seven pre-accounting and ERP systems we reviewed, this is the only one with such a mechanism. This is a topic that directly decides whether the integration is sustainable.

How the mechanism lands on the operation is this: as your order volume grows, the number of calls grows. Stock checks, price updates, writing an order, opening an account and issuing an invoice each produce a separate call. When credits run out, sync stops, and in most setups this stop happens silently; no alert appears on the store side, stock simply freezes and orders do not go into the ERP.

If you sell on more than one channel, consumption multiplies. If marketplace channels also write to the same ERP, each channel's own stock check and order write produce separate calls. So adding a new channel is not only an operational decision, it is a decision that also changes credit planning; this is a cost item we do not see on any other system.

The practical approach has three steps. First, during the test stage of setup, measure how much a few actions consume and scale that to your monthly volume. Second, cut unnecessary calls: prefer a design that only writes what changed, instead of querying every product continuously. Third, set up monitoring that raises an alert when credits run low; because the real risk on this side is not that credits run out, it is that no one notices they have run out.

INVOICES

How is an internet-sale invoice issued in DİA?

Because DİA is a special integrator there is no intermediary on the invoice side; this is a structural advantage that reduces the number of counterparts on the project. Against that, internet sales have their own rules that come from regulation.

The document goes out without a firm in the middle

Because DİA is a GIB special integrator, e-invoice and e-archive are sent from its own infrastructure. The sealing-firm layer seen on the enterprise ERP side is not here; when a problem appears there is a single counterpart.

The internet-sale series has to be separate

The series of invoices for sales made over the internet must be different from your other invoices. So your Shopify orders cannot be written to the same series as store or wholesale sales; this layout is set at the very start.

The invoice has required fields

The paper copy goes with the goods

So the returns section can be filled in, the paper copy of the invoice is expected to go with the shipped goods. This rule changes your packing station: the label and the invoice output have to be taken in the same step.

The cancellation window is short, after that a return invoice

An issued document can only be cancelled inside a set window; after the window the correction is made with a return invoice and the two documents are offset. Sources disagree on the number of days, so we do not give a day count here.

The tax rate and the shipping line are defined separately

The rate is read from the stock card; whether the shipping charge is added to the invoice as a line, and its rate, is defined during setup. You should not go live without confirming this with a test document.

STOCK AND ACCOUNTS

How are a stock collision and a duplicate account prevented?

This system's variant side is comfortable; against that, automatic account opening has a natural side effect: a duplicate card. On the stock side the classic collision of multi-channel setups also applies.

Variants are carried natively

Because the product comes to the connector with all of its variants and options, a separate conversion design is not required on catalogs with a color and size matrix. That means a topic that is unclear on most installed ERPs is clear here.

The matching key is confirmed during setup

Which field the product matches on is not written in an official source, so we do not invent an answer here. The key is defined during setup and confirmed by making a test record with a single product.

The real stock has to sit in one place

Quantity is written from DİA to the store; if two channels sell from the same warehouse, the real quantity has to be held in one place and written from there to every channel. Otherwise the last unit is sold on two channels and a cancellation is unavoidable.

Automatic account opening produces duplicates

Because the connector can open an account card on every order, a second card forms when the same person arrives with a different email or phone. Merging is done by hand; that is why the matching rule has to be defined from the start.

Guest checkout wants a separate rule

The details of a customer who shops without opening an account arrive again on every order. Whether these orders will be written to a single retail account or a separate card will be opened for each one has to be decided during setup.

If a permission is missing the flow runs halfway

When the service user's permission is short, half-results appear such as the order being written but the account not opening. Until permissions are given one by one on the desktop client, this kind of error keeps repeating.

What these items share is this: the real risk on this system is not that data never goes, it is that it goes only in part. A missing permission, credits running out and a period lock all produce a half-result; that is why the setup has to have a screen that makes records that error visible.

MULTICHANNEL

What happens if marketplace channels also write to the same DİA?

This system's strong side is working multi-channel: connectors write dozens of marketplaces into the same ERP. When Shopify is added the risks that appear are the same as on the other systems, and one more is added on top.

The risk of a separate stock card per channel

If the same physical product is recorded with a different code on two channels, two stock cards open in DİA and the stock report shows no channel's truth. Codes have to be lined up before a new channel is added.

The same customer becomes a separate account per channel

Because the contact details the channels give are different, the same person is opened as two accounts. Because merging is done by hand, this job grows as the number of channels grows.

Credit consumption multiplies with the number of channels

Each channel's own stock check and order write produce separate calls. So adding a new channel also changes credit planning; this cost item does not exist on any other system.

The same warehouse's stock is reserved twice

If two channels sell from the same warehouse, the quantity can drop twice or not drop at all. That is why running stock management from a single center is a requirement, not a preference.

The invoice series can be split per channel

The separate-series rule for internet sales applies to every channel. If you want to see which document came from which channel, building the series layout for that makes reporting easier.

The period lock affects every channel

After the accounting period closes, no record can be opened in that period, and because period code is required on calls the connector returns an error. Emptying the queue before the close hour has to be made a rule.

If your Trendyol and Hepsiburada connections already write to DİA, adding Shopify means reviewing both the record layout and your credit plan. You can review Station to watch the order, stock and invoice flow from a single panel.

CHECKLIST

What you need to confirm before setup

Some of the headings below are written in DİA's own documentation, some have not been published anywhere so they have to be measured during setup. Separating the two is the only way to produce a realistic timeline.

Your credit consumption

Measure during the test stage how many credits you consume for how many orders and how many products. A setup that has not been scaled to your monthly volume can stop silently on a busy campaign day.

The service user's permissions

Are order-write, account-open, stock-read and invoice-issue permissions defined separately on the desktop client? Because permission is not inherited, a missing permission leaves the flow halfway.

Firm and period accuracy

Is the connection built to the right firm and an open period? Because both are required on calls, a wrong choice either returns an error or writes documents in the wrong place.

The matching key

Which field products match on has not been published. You have to make a test record with a single product and see how the record opens.

Price and warehouse choice

Which price will be written to the store and which warehouse's stock will be opened is defined during setup. A wrong choice produces either the wrong price or an oversell.

The steps of the return flow

Which document a return and a cancellation produce is not described in an official document. You have to see the flow by returning the test order.

The invoice-series layout

Make it clear how the separate series for internet sales is defined. Because this is a required layout it has to be solved before setup.

Error notification

Will an alert be raised when a record is refused or credits run low? Because the whole risk on this system comes from flows that run halfway, monitoring is part of the setup.

The support line

Because DİA does not build the connector, ownership sits with the solution partner. Which problem belongs to whom has to be written in the contract; otherwise at an outage the two sides point at each other.

SCENARIO

Three common problems and how they were solved

The three setup scenarios below show how we handled Shopify DİA integration problems we solved in stores we connected.

Sync that stopped on campaign day

ProblemOn the busiest campaign day of the year, stock in the store looked frozen and orders stopped going into the ERP. The team first blamed volume, but the flow did not come back in the evening either and oversells piled up.

CauseService calls were consuming credits and how many times campaign traffic would multiply a normal day's calls had never been measured. Credits ran out during the day so sync stopped; because there was also no alert that reported the stop, the problem was noticed hours later.

SolutionCredit consumption was measured and scaled to monthly volume, and a separate buffer was set aside for campaign periods. Unnecessary calls were cut: a design that only writes what changed was built instead of querying every product continuously, and monitoring that raises an alert when credits run low was added.

The order landing but the account not opening

ProblemAfter the connection was built, orders started landing in the ERP but some of them had no customer data. Accounting could not invoice those orders and every day a few records were left waiting to be completed by hand.

CauseThe service user's permission related to the account card was missing. On this system permission is not inherited, it also has to be defined on the desktop client; order-write permission had been given, account-open permission had not.

SolutionPermissions were reviewed one by one on the desktop client and completed, and an error list was built for records where the flow stopped halfway. Waiting orders were completed by opening their account cards, and the same case did not repeat on new orders.

Records refused at month close

ProblemAt month close a gap appeared between the sales report and store revenue. The missing orders were sitting in the store but had no counterpart on the ERP side, and no one had seen an error notification.

CauseBecause period code is required on calls, every record was being written into an accounting period. Orders that landed near the last day of the month sat in the queue while the period closed; because a record cannot be opened in a closed period, those records were refused.

SolutionA checklist that made records that errored in the queue visible was built and added to the end-of-day routine. Emptying the queue before the month-close hour was made a rule, and the missing orders were posted to the right period.

STATION

Shopify DİA integration

Station is the tool we built to watch the order, stock, price and invoice flow from a single panel. If your marketplace channels also write to the same DİA, you see both the duplicate-record risk and the credit consumption here.

See the integration Talk to us about setup

FAQ

Frequently Asked Questions

How is the Shopify DİA integration done?

Setup starts by opening a web-service user on the DİA side and producing an access key. Then that user's permissions are given one by one on the desktop client, and it is confirmed that the connection is built to the right firm and an open period. The next steps are defining matching and the variant layout, choosing price, warehouse, tax and invoice series, and placing a test order with a single product. Measuring credit consumption during the test is also part of this work.

Does DİA have a Shopify app of its own?

There is no Shopify app published under the DİA name. The connector comes from DİA's solution-partner ecosystem; DİA introduces a solution partner that lists Shopify by name among the ecommerce platforms it supports on its own site. The practical result is this: the support and ownership line sits with the solution partner, not with DİA, and this has to be clear in the contract.

Where is a DİA API key taken from?

The connection is built with a web-service user opened on the DİA side and the access key produced for that user. The critical point here is not the key itself but the permissions: for every action that will be done through the service, the same permission also has to be defined on the desktop client. Because permission is not inherited, a missing permission leaves the flow halfway.

What is a DİA web-service credit?

On DİA's web service, credits drop for every call; some special calls such as login sit outside this and the credit status is watched on a screen in the desktop client. Among the seven pre-accounting and ERP systems we reviewed, this is the only one with such a mechanism. When credits run out, sync stops, and in most setups this stop happens silently.

How many credits are consumed?

We do not give a unit-consumption number here because it depends on how many calls your setup produces: stock checks, price updates, writing an order, opening an account and issuing an invoice each produce a separate call. The right approach is to measure the consumption of a few actions during the test stage, scale that to your monthly volume, cut unnecessary calls and set up monitoring that raises an alert when credits run low.

What happens when credits run out?

Sync stops: stock freezes in the store, orders do not go into the ERP and price updates are not published. The riskiest side of this stop is that it is silent; because no alert appears on the store side, the problem is usually noticed when oversells pile up. That is why credit monitoring should be treated as a required part of the setup, not an optional one.

Is a server required for the connection?

It is not. Because both the store and DİA run in the cloud, there is no need to build a secure tunnel, a fixed address or on-premise server access. The infrastructure step that eats the first week of a project on installed ERPs does not exist on this system at all; the weight of the setup sits on permission and credit planning.

Do Shopify orders land in DİA by opening a customer account automatically?

They can: while the order is written into DİA the customer's account card can open automatically. This convenience has a side effect, a duplicate card: when the same person arrives with a different email or phone a second card forms and merging is done by hand. A separate rule also has to be set for customers who shop without opening an account.

How are stock and price transferred from DİA to Shopify?

The catalog's truth sits in DİA; quantity and price are written from DİA to the store and changes are checked regularly and published. Two decisions are made during setup: which price will be written to the store and which warehouse's stock will be opened. If two channels sell from the same warehouse, the real quantity has to be held in one place.

How do Shopify variants match in DİA?

On this side DİA is a comfortable system: the product comes to the connector with all of its variants and options, so the variant is carried natively. On catalogs with a color and size matrix a separate conversion design is not required. Against that, which field the match is built on is not written in an official source; the key has to be confirmed with a test record.

Which field are products matched on?

Product matching is built on the stock card, customer matching on the account card; but whether the match is made on stock code or barcode has not been published. That is why we do not invent an answer here: the key is defined during setup and confirmed by making a test record with a single product.

Is a separate integrator required for DİA e-invoice?

It is not. Because DİA is a GIB special integrator, e-invoice and e-archive are sent from its own infrastructure without a third firm in the middle. That means the sealing-firm layer on the enterprise ERP side is not here; when a problem appears the number of counterparts is small. Bulk invoicing is also possible.

Is a separate series required for internet-sale invoices?

Yes. The series of invoices for sales made over the internet must be different from your other invoices, so your Shopify orders cannot be written to the same series as store or wholesale sales. This layout is set at the very start of the invoice structure; the series of past documents cannot be changed later.

Which fields are required on an internet-sale invoice?

The web address where the sale was made, the payment method, the organization that mediated the payment, the payment date, the tax or identity number of the party that carried the goods, the date the goods were sent, a returns section and a statement that the sale was made over the internet must be present. The paper copy of the invoice is also expected to go with the shipped goods; this directly affects your packing flow.

Is Shopify's own invoice valid?

No. The order summary Shopify produces is not treated as a valid invoice in Turkey; the legal document always comes from your accounting system. The aim of the integration is not to send the customer an output, it is to produce a document in DİA on the right series, at the right rate and with the required fields filled.

How is the invoice of a returned order corrected?

It depends on the age of the document. An issued document can only be cancelled inside a set window; after the window the correction is made with a return invoice, not a cancellation, and the two documents are offset against each other. Sources disagree on the number of days, so we do not give a day count here. Because which document the return flow produces is not described in an official document, it has to be made clear with a test order.

How does the shipping charge land on the invoice?

Whether the shipping charge is added to the document as a separate line is defined during setup. Because the tax rate of the shipping line can differ from the product tax, the rate has to be confirmed with a test document instead of an assumption. On a return the same line is also dropped with its tax.

Why do orders that land at month end not go into DİA?

Because period code is required on service calls, every record is written into an accounting period and after the period closes no record can be opened in that period. If an order that lands near the last day of the month sits in the queue while the period closes, the record is refused. The fix is two-step: raise an alert for records that error, and make emptying the queue before the close hour a routine.

The order lands but the account does not open. What could be the cause?

Almost always permission: the service user's permission related to the account card is missing. On this system permission is not inherited; for every action that will be done through the service, the same permission also has to be defined on the desktop client. When order-write permission is given and account-open permission is not, the flow stops exactly halfway like this.

I have more than one firm. Which one is the connection built to?

Because firm code is required on service calls, the connection is built to a specific firm. If you track more than one firm this has to be confirmed from day one; when the wrong firm is chosen you either get an error or documents are written to the wrong taxpayer. The same confirmation also applies to period code.

Can DİA, Trendyol and Shopify be managed from the same panel?

They can; connectors write dozens of marketplaces into the same ERP and this is also this system's strong side. Three risks have to be watched: the same physical product opening a separate stock card per channel, the same customer becoming a separate account per channel, and credit consumption multiplying with the number of channels. The last item does not appear on any other system.

How does adding a new channel affect cost?

On this system a new channel is not only an operational decision, it is a decision that also changes credit planning: each channel's own stock check and order write produce separate calls. That is why, before you add a channel, you have to measure current consumption and forecast the call load the new channel will bring.

How do marketplace deductions enter DİA?

Because commission and shipping deductions are taken from the marketplace payout, the sales amount written into the ERP and the amount that lands in the bank are not the same. Whether this difference is recorded as an expense or as a sales discount is decided with your accountant; if it is not defined, bank reconciliation is corrected by hand every month.

I sell in a foreign currency. How do the records enter?

Shopify can sell in more than one currency; on the ERP side the record enters after conversion into local currency. If which day's rate is used is not defined during setup, reconciliation breaks every month with small differences. Because there is no published rate policy on this topic, the decision has to be made on the project and written down.

Who owns the integration?

Because DİA does not build the connector, technical ownership sits with the solution partner. This is the topic that produces the most trouble at an outage: if which problem belongs to whom is not written in the contract, the parties point at each other. Topics such as permission, credits and period sit on the DİA side; data conversion and queue management sit on the connector side.