Verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4).
You closed the period. Reporting has been submitted, VAT and taxes calculated, ESF issued. And a week later a manager in the source database "retroactively corrected" a shipment from last month — forgot a line. During the next synchronization, this change arrives in your database and silently changes the figures in the already closed period. The balance "shifts," and you don't even see it. To prevent this from happening, the receiver database has a data upload prohibition date enabled. And the "Upload prohibition dates" report shows which date is currently in effect and which organizations/nodes it applies to.
Important right away: this is a service object of the data synchronization mechanism, not a sales document. It doesn't create accounting entries, doesn't issue ESF and SNT, and has no regulated printed forms. Its job is to protect closed periods from changes coming via exchange. Below is how it works and how to configure it without mistakes.
1. Purpose
The "Upload prohibition dates" mechanism blocks the reception (upload) of synchronization data for periods before the specified date. The report Report.UploadProhibitionDates shows the current settings: which date, for which organizations (sections), and nodes it is set. This protects a closed period from "retroactive edits" coming from another database.
2. Where to find it
- Setting: section "Master data and administration" → "Data synchronization" → "Data upload prohibition dates". This setting is available when data synchronization itself is enabled.
- Report with current values: it's more convenient to open it directly. Menu "Functions for a technical specialist" (or "Tools") → "Report" → "Upload prohibition dates".
- 1C navigation link (the fastest way): copy the line below, then Main menu → "File" → "Go to navigation link" (or Ctrl+F11) and paste it:
e1cib/list/Отчет.ДатыЗапретаЗагрузки
The report will open directly in your database with the current settings.
2a. How to find your release
"Help" → "About the program" (or the ℹ️ icon on the panel). In the window that opens, you'll see the platform version (e.g., 8.3.24.x) and the configuration release — a line like "Trade Management for Kazakhstan, edition 3.4 (3.4.5.21)". The instructions describe the behavior of release 3.4.5.21 specifically; in other releases, menu command names may differ slightly.
3. How to configure — field by field
Open the "Data upload prohibition dates" form. Let's go through it in order.
| Field / element | What it's for | What happens if set incorrectly |
|---|---|---|
| "Data upload prohibition dates" checkbox (must be enabled) | The main switch for the mechanism. As long as it's off, no dates are in effect. | Off — no protection, data is loaded for any period, even a closed one. |
| Method for specifying the prohibition date (required) | Determines the level of detail: "Common date" — one for everything; "By section" — its own date for each organization/node; "By section and object" — also by object type. | You choose "Common" but need it per organization — you'll block too much or, conversely, not enough. |
| Prohibition date (required) | The boundary: data with a date on or before this date is not loaded. Usually set to the last day of the closed month/quarter. | Set the date later than the closed period — a "hole": edits to the closed month will go through. Set it too early — the protection effectively doesn't work. |
| Method (relative date) | Instead of a fixed date, you can choose a calculated one: "end of last month", "end of last quarter", "end of last year". It shifts automatically when the period changes. | Won't work if you close periods irregularly — the relative date may "run" ahead and block a needed upload. |
| Section (organization / synchronization node) | With the "By section" method — for whom exactly the date applies. Allows you to close one organization while leaving others open. | Forget to add an organization — the prohibition date won't apply to it at all. |
| Users / role (in databases with detail by responsible person) | In some configurations you can set exceptions — who is allowed to load data even into a closed period. | Grant the right too broadly — the point of the prohibition is lost. |
After configuring, click "Write and close". The values will take effect starting from the next synchronization session.
4. Worked example
Scenario. You have two databases: "TM for Kazakhstan" (source) and "Accounting" (receiver), synchronization is configured. Organization — LLP "Astra". August 2026 is closed: VAT at 16% is calculated, the return has been submitted.
What you do. In the receiver database, open "Data upload prohibition dates":
- mechanism checkbox — enabled;
- method — "By section";
- section — LLP "Astra";
- prohibition date — 31.08.2026.
Saved. You open the report via the link e1cib/list/Отчет.ДатыЗапретаЗагрузки — you see the line: LLP "Astra" — 31.08.2026.
Real-life check. In the source database, a manager edits a sale from 20.08.2026 (added an item for 232,000 ₸ including VAT). Synchronization is run.
Result:
- the modified sale from 20.08.2026 is not loaded into the receiver — its date (20.08.2026) falls into the prohibited interval (≤ 31.08.2026);
- the synchronization log shows a warning that the object was skipped due to the upload prohibition date;
- the figures for the closed August period in the receiver do not change: revenue 6010, VAT payable 3130, cost of goods 7010 remain as they were at the time of closing.
About accounting entries, honestly. The "Upload prohibition dates" mechanism itself does not generate accounting entries — it only skips or blocks the upload of other documents. The accounting entries (for example, Dt 1210 Kt 6010 for revenue, Dt 3130 for 16% VAT, Dt 7010 Kt 1330 for cost of goods) are made by that same sale — and it's precisely its August change that your prohibition kept out of the closed period. If the date hadn't been set, the receiver would have rewritten August and "broken" the already submitted reporting.
5. Operation types (configuration options)
There are no separate "operation types" here as with a document. There are methods for specifying the prohibition date:
- Common date — one date for the entire database and all organizations. Simple, suitable for small implementations.
- By section — its own date for each organization or synchronization node. Needed when organizations close periods at different times.
- By section and object — plus detail by object type (e.g., separately for documents and for balances). Fine-tuning for complex exchanges.
Additionally, the date can be set as fixed or relative (calculated from the current date).
6. What is generated
- No accounting entries — the object doesn't create accounting movements.
- ESF, SNT, and other electronic documents are not issued — this is not a sales/receipt document.
- Register movements: the setting is stored in a service information register of the upload prohibition mechanism (used by the data synchronization subsystem).
- Effect during synchronization: at each upload session, the system checks the date of the incoming object against the prohibition date and skips objects for the closed period, logging this in the synchronization log (warnings).
The Report.UploadProhibitionDates report is a "mirror" of the settings: it doesn't change anything, it only shows the current dates by section and node.
7. Printed forms
The object has no regulated printed forms — it's not a primary document. The report generates a tabular result on screen (organization/node → current prohibition date), which can be:
- printed using the standard tabular document print command;
- saved to a file (Excel, PDF, mxl) via "More → Save".
This is enough to attach a snapshot of the current dates to an internal period-closing regulation.
8. Common mistakes
"Loading data for a period before <date> is prohibited. Object skipped." This is not an error but a standard warning in the synchronization log: the mechanism worked and did not allow a change into the closed period. If the object really needs to be loaded — temporarily move the prohibition date back, run synchronization, then move the date back to its original value.
Data still got loaded into the closed month. Three causes: (1) the main checkbox of the mechanism is off; (2) the prohibition date is set later than the document's period; (3) with the "By section" method, the needed organization was not added to the list. Check all three via the report.
"Setting unavailable / menu item missing". Data synchronization is not enabled, or the user doesn't have administrator rights. Upload prohibition dates are configured by a user with full rights.
A relative date has "run off" and blocks a needed upload. You chose "end of last month," but the period hasn't been closed yet — the boundary shifted and cuts off fresh data. For irregular closing, use a fixed date.
Confused with "modification prohibition date". These are different mechanisms. The modification prohibition blocks manual editing by users in this database; the upload prohibition only blocks the reception of data via exchange. They need to be configured separately.
9. FAQ
1. How does "upload prohibition date" differ from "modification prohibition date"? The modification prohibition doesn't let users manually edit documents in this database. The upload prohibition doesn't let synchronization data overwrite a closed period. These are two independent mechanisms, often enabled together.
2. Does the prohibition date cancel data already loaded earlier? No. It only affects future upload sessions. Anything that was already in the database before the date was set remains as is.
3. What happens to a document that wasn't loaded? It remains in the source database unchanged. It doesn't reach the receiver, and the fact that it was skipped is logged in the synchronization log warnings.
4. Can different dates be set for different organizations? Yes. Choose the "By section" method and specify its own date for each organization (or node).
5. Who is allowed to change the upload prohibition date? A user with administrator rights (full rights). Regular users typically don't have access to this setting.
6. Does the upload prohibition date affect manual entry of documents "here and now"? No. It doesn't affect manual entry and editing — that's the job of the modification prohibition date. The upload prohibition works exclusively on incoming exchange data.
7. What does "relative prohibition date" mean? This is a date calculated from the current one: "end of last month/quarter/year". It shifts automatically when the period changes, so you don't have to change the setting every month.
8. How can I quickly find out which date is currently in effect?
Open the report via the link e1cib/list/Отчет.ДатыЗапретаЗагрузки — it will show the current dates for all sections and nodes.
9. Do I need to configure the upload prohibition date in both databases? It's configured in the database being protected — the receiver. If the exchange is two-way and both databases close periods, the date is set in each of them.
10. Why does synchronization seem to "hang" on prohibition warnings? This is not a failure: the system is listing the skipped objects. Synchronization completes successfully — some data for the closed period simply isn't loaded, as intended.
10. Related objects
- Data synchronization (section "Master data and administration") — the basic mechanism; without synchronization enabled, upload prohibition dates don't work.
- Data modification prohibition dates — a "neighboring" mechanism: blocks manual editing in this database. They are usually configured together.
- Data synchronization settings (exchange nodes) — nodes act as "sections" in the "By section" method.
- Documents arriving via exchange (sales, receipts, payments, etc.) — these are the objects whose loading into a closed period is restricted by the prohibition date.
How to find your release
"Help" → "About the program": this shows the platform version (8.3.x) and the configuration release. This guide was compiled and verified on release 3.4.5.21 "Trade Management for Kazakhstan" (edition 3.4). In newer releases, some menu command names may differ, but the logic of the upload prohibition mechanism remains the same.
This guide is current for "Trade Management for Kazakhstan," release 3.4.5.21 (edition 3.4).