Checked on release 3.0.74.2 "Accounting for Kazakhstan" (version 3.0).
You submitted form 300.00 for the II quarter of 2026, closed the period, everything matched. And a week later, synchronization with "Trade Management" starts — and a backdated sale appears in the closed June, which the manager corrected after submitting the report. The amounts went off, the VAT payable changed, and the reporting no longer matches the database. To prevent this from happening, 1C has Data Loading Prohibition Dates. You set a date — and no changes prior to this date from other programs will enter the database.
It is important to immediately clarify: this is not a document and not a report with entries. This is a service setting for the data exchange mechanism. It does not post anything to accounts and does not generate electronic invoices (ESF) — it only prohibits loading external changes into the protected period. Therefore, below you will not find a table "Dr/Cr of this object": it does not have one by definition. However, you will find everything that is actually needed for the setup.
1. Purpose
The mechanism prohibits loading into your database, dated earlier than the specified date, when synchronizing with other programs (exchange "Accounting ↔ Trade Management", RIB, exchange between organizations). It serves the same purpose as "Change Prohibition Dates," but works only for receiving data from outside, not for manual editing by the user.
2. Where to find
- Section "Administration" → "Data Synchronization" → "Data Loading Prohibition Dates" (the link becomes active when synchronization is enabled).
- Open directly in 1C: "Service" → "Go to navigation link" and paste:
e1cib/list/Report.DataLoadingProhibitionDates
If the item in the "Administration" section is gray or absent — it means that data synchronization is not yet configured. First, enable it in the "Administration" → "Data Synchronization" section, otherwise there will be nothing to prohibit loading.
2a. How to find out your release
Open "Help" → "About the program" (or the "i" icon in the upper right corner). In the window, you will see two lines: platform version ("1C:Enterprise 8.3.x.xxxx") and configuration release ("Accounting for Kazakhstan, version 3.0, release 3.0.74.2"). Focus on the second line — this instruction is tied to it. The field composition is identical on neighboring releases 3.0.7x.
3. How to fill out
The form is built on one principle: you select the scope (for all data or selectively) and the date itself.
Step 1. Method of specifying the prohibition date (mandatory)
Select one of the modes:
| Mode | What it means | When to take |
|---|---|---|
| For all data | One date for the entire database and all exchange nodes | The most common choice — closed the period, set the date |
| By accounting sections | Separate dates for different sections (for example, bank, warehouse, payroll) | When sections close at different times |
| By sections and objects | Dates for specific organizations / counterparties within the section | Multi-company database, different responsible parties |
If you choose "For all data," and you only needed to close one section — you risk blocking the necessary loading for another section. Start with the simplest mode and complicate only as necessary.
Step 2. Prohibition date (mandatory)
There are two ways to set the date itself:
- Specific date — you enter a specific number, for example
30.06.2026. Loading of everything dated on this date and earlier is prohibited. - Relative date — the date is automatically recalculated with each synchronization: "End of the previous month," "End of the previous quarter," "End of the previous year," etc. Convenient so you don't have to change the setting manually each period.
An error here is costly in both directions. If you set the date later than needed, you will block the loading of current working documents, and managers will complain that "data is not coming." If you set it earlier or forget to shift it — the closed period will remain unprotected, and corrections will leak through.
Step 3. Configuration by synchronization nodes (if necessary)
In the settings link, you can specify different dates for different exchange nodes. Example: you strictly close the exchange with the branch's accounting database at the end of the quarter, while leaving the exchange with the online store open. If there is only one node — skip this step, the general date applies.
Step 4. Save the setting (mandatory)
Click "Save" (or "Set prohibition date"). The setting takes effect immediately and is applied at the next synchronization session. There is no "posting" here — this is a setting, not a document.
4. Analyzed example
Situation. LLP "Astana-Snab" on the general taxation system, VAT payer. Sales accounting is conducted in "Trade Management," accounting — in "Accounting for Kazakhstan," synchronization is set up between the databases. For the II quarter of 2026, form 300.00 was submitted, VAT was accrued at a rate of 16%.
On July 25, the manager backdated a sale in TM from 30.06.2026 for an amount of 1,160,000 ₸, including VAT 16% — 160,000 ₸. If this document is loaded into accounting, it will change the already closed June and create entries:
| Dr | Cr | Amount, ₸ | Description |
|---|---|---|---|
| 1210 | 6010 | 1,000,000 | Revenue from sales (excluding VAT) |
| 1210 | 3130 | 160,000 | VAT payable, 16% |
| 7010 | 1330 | 700,000 | Cost of goods sold |
These entries are what you do not need right now — they will ruin the submitted declaration.
What to do. Open "Data Loading Prohibition Dates," mode "For all data," prohibition date — 30.06.2026. Save it.
Result. At the next synchronization, the document dated 30.06.2026 will not be loaded into the database. In the "Warnings about unexported objects / synchronization collisions" journal, a line appears with this document and the reason: the date fell into the prohibited period. Your closed June remains untouched, and the declaration continues to match the accounting. When you decide to accept this document (for example, in the next period), either remove the prohibition or ask to repost the sale with the current date.
Note: the prohibition date setting did not create any entries. It simply prevented external entries from entering the closed period.
5. Types of operations (modes)
There are no separate "types of operations," like in documents, here. There are modes of scope:
- For all data — a single date for the entire database.
- By accounting sections — its own date for each section.
- By sections and objects — its own date for organizations/counterparties within the section.
- By synchronization nodes — different dates for different source programs.
Plus two ways to set the date: specific and relative (auto-shift).
6. What is generated upon saving
- Dr/Cr entries — are not generated. The object does not affect accounting accounts.
- Electronic documents (ESF, CNT) — are not generated. The setting has no relation to the ESF information system.
- Entries in registers — the record is saved in the service register of the data loading prohibition mechanism (stores date, section, object, node). This register is read by the exchange subsystem before recording each incoming object.
- Effect — during synchronization, each incoming object is checked against the prohibition date; objects "before the date" are rejected and enter the list of warnings/synchronization collisions.
7. Print forms
The setting has no print forms — this is a service mechanism, not a primary document. For control, use not printing, but service lists: "Warnings about data synchronization" and "Results of data synchronization" in the "Administration" → "Data Synchronization" section, where you can see which objects were rejected due to the prohibition date.
8. Common errors
"Modification (recording, posting) of the object ... is prohibited. Data loading prohibition date: 30.06.2026" Appears in the synchronization results: the incoming document is dated earlier than the prohibition. This is not a failure — the mechanism works as intended. Solution: either leave it as is (the protection worked correctly), or repost the document in the source database with the current date, or shift/remove the prohibition date if the correction needs to be accepted.
The item "Data Loading Prohibition Dates" is inactive or absent. Data synchronization is not configured. Enable it in "Administration" → "Data Synchronization," after which the item will become available.
"Data from another program has completely stopped coming." Check if a specific prohibition date is set in the future or "today." In "For all data" mode, such a date blocks current documents as well. Return the correct date (usually the end of the closed period) or switch to the relative "End of the previous month."
Configured the date for one node, expecting an effect for another. In "by nodes" mode, dates are independent. Ensure that the prohibition is set specifically for the exchange node from which unwanted data is coming, or use "For all data."
Forgot that the relative date "shifts." With a relative date, the prohibition automatically shifts each period. If you need to firmly fix a specific day once — switch to "Specific date."
9. FAQ
What is the difference between "Data Loading Prohibition Dates" and "Change Prohibition Dates"? "Change prohibition" does not allow the user to manually edit documents in the closed period. "Loading prohibition" does not allow loading changes from another program during synchronization. These are two independent mechanisms, often configured for the same date.
Will entries appear after setting the prohibition date? No. This is an exchange setting; it does not create movements in either accounting or tax accounts.
Is an ESF or CNT generated? No. This mechanism has no relation to the ESF information system and electronic CNT.
Does the prohibition apply to manual input in the database? No. Manual input and editing are restricted by "Change Prohibition Dates." "Loading prohibition" only concerns receiving data during synchronization.
What happens to a document that did not pass the prohibition date? It remains in the source database, and in the receiver, it enters the list of warnings/synchronization collisions as unexported/unaccepted. The receiver's data does not change.
Can different dates be set for different organizations? Yes, using the "By sections and objects" or "By accounting sections" mode. Convenient in a multi-company database where organizations close periods at different times.
What to choose — a specific or relative date? Relative ("End of the previous month/quarter") — if you want the protection to shift automatically and not require manual adjustment each period. Specific — when you need to fix a specific day (for example, after submitting form 300.00 for the quarter).
Who can change the prohibition date? A user with administrative/data synchronization configuration rights. Typically, regular operators are not given access to this setting.
How to quickly check if the prohibition worked? After synchronization, open "Administration" → "Data Synchronization" → "Data Synchronization Warnings." Rejected objects by date will be in the list with the reason.
Does the loading prohibition affect the export of my data outside? No. Only the reception (loading) of data into your database is restricted. Your changes are still exported to other nodes according to the exchange rules.
10. Related objects
- Data Change Prohibition Dates — a "relative" mechanism for manual editing; configured there as well, in "Administration." Usually set synchronously with the data loading prohibition date.
- Data Synchronization Settings — the basic exchange setting; without it, "Data Loading Prohibition Dates" are unavailable.
- Warnings / Results of Data Synchronization — here you can see which objects were rejected due to the prohibition date.
- Period Closing Assistant / VAT Regulatory Operations — a logical source of the date: as a rule, the prohibition date is set based on the results of closing the period and submitting form 300.00.
How to find out your release: "Help" → "About the program" — there you will find the platform version and configuration release.
This instruction was prepared for "Accounting for Kazakhstan," version 3.0, release 3.0.74.2.