Checked on release 3.0.74.2 "Accounting for Kazakhstan" (version 3.0).
It's Monday morning. You open the database and see: there are no incoming invoices that "Trade" entered yesterday in the accounting. Or vice versa — some documents are duplicated. Synchronization seems to be enabled, the checkboxes are ticked, but the data does not match. Before calling the programmer, open "Data Exchange Sessions". This is a log that records every instance of exchange between your database and another information database (branch, "Trade Management", payroll, RIB node). It shows when the exchange occurred, which way the data went, how many messages were sent and received, and how the session ended. This log is where the investigation of "why it didn't transfer" begins.
1. Purpose
"Data Exchange Sessions" is a service reference of the synchronization subsystem. It stores the history of exchange sessions: each record is one cycle of "sent message / received message" with a specific node. This object does not generate accounting entries, VAT, or electronic documents (ESF, SCT) — it is technical and needed for diagnosing the exchange.
2. Where to find
There is no direct item in the "Sales" or "Purchases" sections for this reference — it opens from the synchronization mechanism.
- Through synchronization:
Administration→Data Synchronization→Data Synchronization Settings→ by clicking theMorebutton / hyperlinks in the node settings form, information about sessions and warnings is available. - Directly from the list — the fastest way. Menu
Service and Settings(☰ icon at the top) →Functions for Technical Specialist→ in the search field, enterData Exchange Sessions. - Through the navigation link. Copy the line below, then in 1C: main menu →
File→Go to Navigation Link(orCtrl+Shift+N), paste it and click "Go":
e1cib/list/Reference.DataExchangeSessions
If the item "Functions for Technical Specialist" is not visible — enable it:
Service and Settings→Settings→Parameters→ check the box "Show the 'All Functions' command".
2a. How to find out your release
Help (or ☰ icon → About the Program). In the opened window — two key lines: platform version (for example, 8.3.24) and configuration version — this is the release (in our case 3.0.74.2). Everything described below relates to release 3.0.74.2; in other releases, the composition of fields may differ slightly.
3. How to fill out
It is important to understand right away: you usually do not fill out this reference manually. Records in it are created by the synchronization mechanism during each exchange. You read it, not maintain it. But you need to know the fields to read the log correctly.
| Field | Purpose and Meaning |
|---|---|
| Name / Code | Technical label of the session. The programmer will match the record with the registration log by the session code if deep diagnostics are needed. |
| Node (mandatory for meaning) | Which database the exchange was with: exchange plan node — "Trade Management", branch, RIB node. If the node is not correct, you are looking at the wrong channel and wasting time searching for your documents. |
| Start Date / End Date | When the session started and ended. The difference shows how long the exchange lasted. An empty "End Date" means the session did not complete (it was interrupted, or a background task hung). |
| Direction | Sending (your data went to the partner) or receiving (data came to you). Confusion in direction is a common reason for the false conclusion "data is missing": they are not missing, but have not yet been accepted by the other party. |
| Messages Sent / Received | Exchange counters. A zero "Received" while you are waiting for documents is a signal that the counterpart database has not yet exported them. |
| Status / Result | Successful, with warnings, or with an error. This is where you should look first during the investigation. |
| Comment / Error Text | Explanation of the problem: version conflict, object collision, rights violation, limit exceeded. This is your main clue. |
If you do create a record manually (very rarely, for service purposes) — only a meaningful Name and a correct Node are mandatory; otherwise, the record is useless for diagnostics.
4. Analyzed Example
You have two databases: "Accounting for Kazakhstan" and "Trade Management". Yesterday, the manager issued a sale of goods for 1,160,000 ₸ (goods 1,000,000 ₸ + VAT 16% = 160,000 ₸). Today, the document is not in the accounting. You open "Data Exchange Sessions" and see the last two records:
| End Date | Node | Direction | Received | Status |
|---|---|---|---|---|
| 07.09.2026 09:15 | TM (Store) | Sending | — | Successful |
| 07.09.2026 09:16 | TM (Store) | Receiving | 0 | Successful |
Conclusion from the log: the session went without errors, but "Received: 0" on receiving. This means your database worked normally — just in "Trade Management" the sale has not yet been processed or the reciprocal exchange has not been initiated. You go to TM, process the document, start synchronization — in the next session, "Received: 1" appears, and the sale comes into accounting.
Already in accounting, this transferred sale document generates standard entries of the RK (they are created by the sale document, not the exchange session):
| Debit | Credit | Amount, ₸ | Description |
|---|---|---|---|
| 1210 | 6010 | 1,160,000 | Reflecting the buyer's debt and income from sales |
| 6010 | 3130 | 160,000 | VAT payable accrued (16%) |
| 7010 | 1330 | 700,000 | Cost of goods written off |
Thus, the session log helped to localize the problem: "it's not in accounting, the document got stuck on the trade side".
5. Types of Operations (What the Object Provides)
There is no separate "Type of Operation" field in the reference, but in essence, sessions can be:
- Data Sending — exporting your exchange message to the receiving node.
- Data Receiving — importing a message received from the node.
- Full Exchange (sending + receiving in one cycle) — a typical synchronization session.
- Initial Export / Primary Filling — during the first synchronization launch or when adding a new node.
- Session with Collisions — the exchange occurred, but conflicts of versions were recorded for some objects (the edit was won by one of the databases).
6. What is Formed Upon Recording
There are no entries — the object is not accounting. During the exchange, the following is created/updated:
- Record in the "Data Exchange Sessions" reference — the very fact of the session with dates, direction, and status.
- Movements in service registers of synchronization — registration of exported/imported objects, marks about conflicts, queue for re-export.
- Records in the registration log — technical protocol (events with synchronization code).
- Synchronization Warnings — if there were unaccepted objects or collisions; visible in the "Warnings" list of the node settings.
Electronic documents (ESF, SCT) are not issued by this object — they are formed from sale/purchase documents and sent to the ESF information system separately.
7. Print Forms
The service reference does not have its own "forms". For analysis, use:
- "Results of Exchange Execution" — report on the last session: how much was sent/received, what was not transferred.
- "Warnings During Data Synchronization" — list of unaccepted objects and collisions with reasons.
- Registration Log (
Functions for Technical Specialist→Registration Log) filtered by exchange events — detailed technical protocol.
8. Common Errors
- "Exceeded the limit of the number of data elements that can be synchronized" — you hit a subscription/license limit on the volume of synchronization. Reduce the export period, break the exchange into parts, or upgrade your subscription. Ensure that filtering by dates is set, not "everything from the beginning of time".
- "Data exchange completed with an error. Exchange plan node not found" — the node was deleted or the synchronization setting was broken. Recreate/restore the synchronization setting for this node.
- "Object version conflict. Changes accepted from database N" — the same document was edited in two databases. Open the warnings, check the winning version, and manually refill if necessary.
- "Exchange message does not match the expected number" — the sequence of messages was violated (the database was deployed from a copy). Matching/resetting message numbering is required — this is a version-specific procedure, clarify the procedure for your release with support before resetting to avoid losing unsent data.
- "Insufficient rights to perform an operation on the object" — the exchange user does not have rights to the uploaded object. Check the roles of the service user for synchronization.
9. FAQ
Q: Can old sessions be deleted so they don't interfere? A: Yes, records in the reference can be marked for deletion and removed using the "Delete Marked Objects" processing. This does not affect already transferred documents — the session history is only needed for diagnostics.
Q: The session is "Successful", but the document did not arrive. Why? A: Check the "Received" counter. If it is 0 — the counterpart database has not yet exported the document. The problem is on the sender's side, not in your database.
Q: Does this reference generate ESF or SCT? A: No. ESF and SCT are issued from sale/purchase documents and sent to the ESF information system. Data exchange sessions are only about synchronization between 1C databases.
Q: How to understand which way the data went? A: By the "Direction" field: "Sending" — your data went out, "Receiving" — came to you. This is the first thing to determine during the investigation.
Q: An empty "End Date" — is that bad? A: This is a sign of an unfinished session: the exchange was interrupted or a background task hung. Restart synchronization and check the scheduled exchange task.
Q: Can a session be created manually to "upload" documents?
A: A correct exchange is not initiated manually like that. Use Synchronize in the node settings — the mechanism will create the session itself. A manual record does not initiate the exchange.
Q: Where to see which specific objects did not transfer? A: In the "Warnings During Data Synchronization" of the node settings and in the report "Results of Exchange Execution" — there is a list of unaccepted objects with reasons.
Q: Does this reference affect tax calculations — VAT 16%, PIT, and WPT? A: No. Taxes are calculated by documents (sales, payroll, etc.). The session only transfers these documents between databases; after the transfer, they themselves generate entries and tax movements.
Q: What to do when receiving a message about exceeding the synchronization limit? A: Narrow the selection period, break the export into several sessions, or expand the subscription. After setting the selection, repeat the exchange — the session should complete without error.
Q: Is it mandatory to fill in the "Node" manually? A: During automatic exchange, it is filled in automatically. If you create a record manually, without the correct "Node", the record is meaningless — you cannot understand which database the exchange was with.
10. Related Documents
- Based on what it appears: records are created by the
Data Synchronizationmechanism during exchange with a configured exchange plan node (TM, payroll, branch, RIB). - What is "entered" through the session: any synchronized objects — sale and purchase documents, directories of counterparties and nomenclature, mutual settlements. The session only transfers them.
- Where to look next:
Data Synchronization Settings, reportResults of Exchange Execution, listWarnings During Synchronization,Registration Log.
How to find out your release: Help → About the Program — there you will find the configuration version and platform version line.
The instruction is prepared for "Accounting for Kazakhstan", version 3.0, release 3.0.74.2. In other releases, the composition of fields and wording of messages may differ.