Print (Ctrl+P)
Handler Before Recording Received Data
Procedure PKO_<ИмяПКО>_Before Recording the Received Data in the general module Exchange Manager Through Universal Format contains the handler text Before Recording the Received Data for a specific PKO. The handler text may be empty. However, in practice it is always used when loading data to implement additional logic that must be performed before writing an object to the infobase. For example, should changes be loaded into existing information security data or should they be loaded as new data.
The handler contains the following parameters;
- InformationB data– Type – DirectoryObject, DocumentObject. An infobase data element corresponding to the received data. If no matching data is found, then this parameter has the value Undefined .
- ReceivedData– Type – DirectoryObject or DocumentObject. A data element generated by converting XDTO data. Recorded if this data is new for the infobase (the IB Data parameter contains the value Undefined ). Otherwise ReceivedData replace InformationB data(all properties from ReceivedData transferred to InformationB data). If standard replacement of information security data with received data is not required, you should write your own transfer logic, and then install ReceivedData meaning Undefined
- ConvertingProperties. Type - Table of values. Contains rules for converting properties of the current object, initialized as part of the exchange session.
- ComponentsExchange. A structure that contains exchange components: exchange rules and exchange parameters. The procedure for initializing exchange components is located in the module Data ExchangeXDTOServer
Let's look at some practical examples that I solved in an advanced configuration, so as not to change the basic configuration of typical 1C application solutions.
Do not replace found objects when loading
In the rules for converting objects of edition 3.0, unlike edition 2.0, there is no property “Do not replace found objects when loading”, thanks to which the found objects in the receiver infobase will not be changed by the value of the synchronizing fields.
In the object conversion rules of edition 3.0, the parameter InformationB data has the value undefined if the object is not found. In addition, if the parameter ReceivedData has significance undefined then when exiting the handler, m will not be replaced.
The employer asked me to change the conversion rules between the standard configurations of UT 11 and BP 3.0 so that the data from the directory of organizations and warehouses in the accounting department would not be sold when exchanging with UT. They especially sold the additional details of these directories to the accounting department, every time when elements of these directories were registered in UT for sending to the accounting department.
I performed this task in the accounting configuration extension so as not to change the main configuration. The solution is shown in Fig. 1 . If the directory element exists (found in the source), then the parameter InformationB data is defined and that all properties from ReceivedData NOT transferred to InformationB data should be installed ReceivedData meaning Undefined
Fig 3 Program code fragment in the configuration extension
If the directory object is not found, then the parameter InformationB data has the meaning Uncertain and then I call the procedure ContinueCall to continue calling the event handler from the extensible configuration
Do not reflect documents in regulated accounting
I was asked to make it possible not to reflect in accounting 3.0 some shipping documents that are created in trade management 11. For this purpose, I introduced an additional detail of the implementation document “Do not reflect documents in regulated accounting.” If the flag is set, then this document must be marked for deletion in the receiver database (BP 3.0). The complexity of this task lies in the fact that in the accounting department of the enterprise the documents do not have additional details. I decided to use the comment field. When sending on the source side (UT 11), I fill in the comments attribute with the appropriate inscription, and on the receiver (BP), in the handler, before recording the received data, I set a mark for deletion as shown in Fig. 2
The purpose of this exchange rule is to transfer balances on mutual settlements from BP 2 to UT11.
Step-by-step creation of an exchange rule using the "Data Conversion" configuration (metadata must be loaded):
1) Create a rule for uploading an object; for this, go to the “Rules for uploading data” tab, click add. In the window that appears, select the sample object; this will be a self-accounting register. We change the sampling method to an arbitrary algorithm.
2) Let’s move on to writing the code itself because There is no self-accounting register in the UT, so we must convert it. First, we need a query that, according to our parameters, will return balances for mutual settlements. In the "Before processing" event handler we write the following request:
QueryText = "SELECT
| Self-supporting Balances.Account,
| Self-supportingRemains.Subconto1 AS Subconto1,
| ISNULL(SUM(Self-AccountingRemaining.AmountRemainingDt),0) AS AmountRemainingDt,
| ISNULL(SUM(Self-accountingRemains.AmountRemainingCt),0) AS AmountRemainingCt,
| MAXIMUM(Cost Accounting Balances.Subaccount2.Date) AS Date of SettlementDocument,
| MAXIMUM(Self-Accounting Balances.Subaccount2.Number) AS Accounting Document Number
|FROM
| Accounting Register. Self-supporting. Balances (&OnDate, Account = &account,) AS Self-supporting Balances
|WHERE
<>&group and
| Self-supporting Balances. Sub-account 1. Parent<>&group1
|GROUP BY
| Self-supporting Balances.Account,
| Self-supporting Balances. Sub-account 1,
| Self-supportingRemains.Subconto2
|ORDER BY
| Subconto1
|AUTO ORDER";
My task was to limit the groups of counterparties for which mutual settlements are uploaded.
We determine the values of the variables that will be used in the future.
OnDate = date("20130101");
TD = CurrentDate();
group = Directories.Counterparties.FindByName("Buyers");
group1 = Directories. Counterparties. Find By Name("Returns from INDIVIDUALS");
We create a table that we will later pass to the value conversion rule.
TZ = New ValueTable();
TK.Columns.Add("Counterparty");
TK.Columns.Add("Amount");
TK.Columns.Add("AmountREGLE");
TK.Columns.Add("CalculationDocument");
TK.Columns.Add("Settlement Document Date");
TK.Columns.Add("Settlement Document Number");
TK.Columns.Add("Partner");
TK.Columns.Add("Currency of Mutual Settlement");
TK.Columns.Add("Payment Date");
We set the parameters, call the request, fill out the table and call the conversion rule.
request = new Request(RequestText);
request.SetParameter("group", group); request.SetParameter("group1",group1);
request.SetParameter("OnDate",OnDate);
request.SetParameter("Account", Charts of Accounts. Self-accounting. Calculations with Other Suppliers and Contractors);//76.05
Fetch = request.Run().Select();
TK.clear();
While Select.Next() Loop
if Sample.SumRemainingCT = 0 or Sample.SumRemainingCT = "" then
continue;
endif;
if Sample.AmountRemainderCT< 0тогда
report(""+Sample.Subconto1+" negative value "+Sample.SumRemainingCT);
endif;
LineTZ = TZ.Add();
Line TK.Counterparty = Selection.Subconto1;
LineTZ.sum = Selection.SumRemainingCT;//Selection.SumRemainingCT;
LineTZ.sumRegl = Sampling.SumRemainingCT;//Sampling.SumRemainingCT;
Line TK.Calculation Document Date = Selection.Calculation Document Date;
Line TK.Calculation Document Number = Selection.Calculation Document Number;
LineTZ.PaymentDate = TD;
EndCycle;
OutData = New Structure;
OutgoingData.Insert("Date", CurrentDate());
OutgoingData.Insert("CalculationsWithPartners", TK);
OutgoingData.Insert("Operation Type", "Balances of Debt to Suppliers");
OutgoingData.Insert("Comment", "Generated on account credit 76.05");
report("76.05 CREDIT start");
UploadByRule(, OutgoingData, "Input of Balances for Mutual Settlement_7605Credit");
We similarly perform the same operation for the remaining necessary accounts (their description, as well as the ready-made rule, is in the attachment).
3) Let’s move on to creating object conversion rules; to do this, open the “Object Conversion Rules” tab. Let's add a new rule there with the name "Input Balances By Mutual Settlement_7605Credit", leave the source object empty, set the receiver object to the document "Enter Balances", and on the settings tab remove the flag "Search the receiver object by the internal identifier of the source object".
In the "Before loading" event handler we will write the following code:
Generate NewNumberOrCodeIfNotSpecified = true;
In the "After loading" event handler we will write:
execute(algorithms.AfterLoadInputRemainings);
it will execute an algorithm with the following content:
currency = Constants.RegulatedAccountingCurrency.Get();
object.Owner = SessionParameters.CurrentUser;
object.organization=parameters.organization;
for each page from object.calculationspartners loop
Page.SettlementDocument = Directories.Counterparty Agreements.empty link();
PageCurrencySettlements = currency;
if ValueFilled(page.counterparty.partner) then
p.partner = p.counterparty.partner;
otherwise
partners = Directories.Partners.FindByName(page.counterparty.Name);
if the desk<>Undefined and desks<>Directories.Partners.emptylink() then
p.partner = desk;
object2.Partner = desk;
object2.Write();
otherwise
execute(algorithms.AddPartner);
endif;
endif;
end of cycle;
This algorithm will be executed on the receiver side (BP). In addition to transferring balances for mutual settlements, there is the task of transferring counterparties, but the UT uses partners, so after generating the document, we check whether all counterparties and partners are in the receiver database; if for some reason they are not there, then we add them.
Adding contractors will implement the conversion rule for the “Counterparties” directory; you can create it in the same way as the previous rule, but allow the system to compare the necessary fields.
An algorithm was created for partners that is executed on the receiver side.
In order to execute the algorithm on the receiver side, you need to check the “Used when loading” flag in the upper right corner of the algorithm window (when editing it).
Below is the code for the "Add Partner" algorithm:
nPartner = Directories.Partners.CreateItem();
nPartner.Name = page.counterparty.name;
nPartner.Comment = "Created when loading from BP";
nPartner.NameFull = page.counterparty.NameFull;
nPartner.Supplier = ?(find(page.counterparty.AdditionalInformation,"Supplier")>0,true,false);
nPartner.Client = ?(find(page.counterparty.AdditionalInformation,"Client")>0,true,false);
OtherRelations = ?(find(page.counterparty.AdditionalInformation,"Other")>0,true,false);
npartner.Write();
p.partner = npartner.link;
counterparty = Directories.Counterparties.FindByName(page.counterparty.Name);
object2 = counterparty.GetObject();
object2.Partner = npartner.link;
object2.Write();
Let's go back to the object conversion rule. Now we need to establish correspondence between the source and destination fields; this could have been done immediately before writing the code. In order to compare fields, in the lower tabular part there is a button for calling the “Properties Synchronization” wizard. In this wizard, we can either map the fields or leave them both without a source and without a destination. In our case, we leave all fields and PMs without a source.
After the required fields have been selected in the lower TC, for each field we set a flag in the “Get from incoming data” column. This flag indicates that the system will look for this field in the incoming data. It is important that the field name matches the name in the incoming data, otherwise a message will be displayed stating that the field was not found.
The text does not describe all the nuances of the process.
It is known that 1C programs are a convenient and multifunctional tool for accounting automation, suitable for enterprises in a wide variety of industries and areas of activity. However, this tool is complex and, unfortunately, various types of errors often arise when working with it. In this article, we will show you how to find and resolve an error that occurred when migrating data using rules created by Data conversion technologies 2.0. What should I do if the upload fails or it is impossible to load data into the receiving database? Our article aims to answer these questions.
So, if you have purchased data conversion rules, opened processing for transfer, set all the settings, but the upload is interrupted and an error message appears in service messages, here are a few techniques that can help you find and eliminate the error.
First of all, check the release versions of your program with those specified in the rules. With a slight discrepancy between versions source no problems arise, but if your release is significantly behind the latest versions, the rules will not work. Configuration version receiver must be identical to that specified in the rules.
How can I see which releases the rules are for? Just open the rules file with any editor (by default it can be Internet Explorer or Notepad) and look at the first lines - they contain the versions of the source and destination.
Fig.1. View rules
What to do? If you have such an opportunity, update the source program to the release specified in the conversion rules. If you cannot update the program, then you will not be able to work with these rules.
But perhaps you have already done all this, and the upload still occurs with errors? Then try to find the problematic element that prevents the program from loading correctly.
We will demonstrate the algorithm of actions when searching for errors using the example of transferring data from KA 1.1 to BP 3.0.
Proceed as follows: disable all transfer rules and unload individual groups of rules one by one. Those. first try to unload only Accounting policy, then only Incoming balances, only Directories etc. (Fig. 2). Most often, problems arise when unloading documents, while other types of objects are unloaded normally, so let’s use their example to consider further actions. Now you need to repeat the process with alternate uploading with each document conversion rule. Those. in turn, upload only advance reports, only the transferred letter of credit, etc. according to the list, as shown in Fig. 3.
Fig.2. Sequential unloading of groups of objects
Fig.3. Unloading object types one by one
So, let's assume that the upload is interrupted when all upload rules are selected Documentation. You uploaded all types of documents one by one, went through all the positions one by one and calculated that the error occurs only when uploading, for example, documents Operation (accounting and tax accounting). Next, you should gradually narrow the upload period in order to find the problematic document. First, upload by quarter, month, week until you find the day on which the upload fails.
What to do? If you manage to find the specific document causing the error and you can see what the problem most likely is, great. Fix the document if possible, or simply don't migrate it - it's much easier to repair one document than to do the entire migration manually. To perform a transfer excluding only one document, use the selection in the adjacent window. In the "Comparison type" column, set "Not equal", in "Value" select the problematic document, and continue uploading as usual.
Fig.4. Selecting a document when uploading
Okay, but what if the upload is completed correctly, but the data cannot be loaded into another database? First, take your time and check again whether you did everything correctly and whether the program versions match. Unlike the source, the release version of the receiver must strictly match the one specified in the rules, otherwise you will always get an error.
What to do? Errors at the loading stage can most often be corrected only at the unloading stage, so the procedure for finding the problem will be the same as described above, with only one exception - after each unloading it will be necessary to repeat the loading in order to find the element that is in the receiving database is not downloading. Follow the same sequence - first migrate a group of object views, then specific views by specific dates, and finally eliminate the problematic item that is preventing successful loading.
When standard processing cannot perform the upload correctly and the process stops, an error message always appears in the service messages. In some cases, it is really only possible to find the location and cause of this error by unloading different types of objects one by one. However, this is not the only way. Often the cause of the error is already disclosed in the service message; you just need to read it correctly.
Let's look at the example of unloading from KA 1.1. The user unloads from the source database Incoming balances at the beginning of 2018. The unloading process is interrupted and the program displays several service messages, including the following:
Error in the event handler BeforeProcessingUploadRules
PVD = Remaining_Materials
Handler = BeforeProcessingDataUpload
DescriptionErrors = Error getting object property value (by source property name)
PKO = Nomenclature (Directory: Nomenclature)
PKS = 15 (Article --> Article)
Object = Welding machine inverter VDI 160R (Fixed assets)
ReceiverProperty = Article(String)
DescriptionErrors = Object field not found (Article)
ModulePosition = Processing.UniversalXMLDataExchange.ObjectModule(8283)
MessageCode = 13
ModulePosition = Processing.UniversalXMLDataExchange.ObjectModule(1694)
MessageCode = 31
One could go the hard way and unload different types of balances one by one (remains of fixed assets, balances of intangible assets, etc.) and find that the error occurs when unloading according to the rule Remaining_Materials. Or you can immediately see the name of the rule in the error message. Look, the very first line in the error transcript in the message says exactly this. DVP - data upload rule. The data upload rule is equal to Remaining_Materials. We don’t need to look for anything, the program itself tells you where the error occurred.
Rice. 5.1. Service error message
We can just as easily find the reason. In line DescriptionErrors written Not a very clear message for the user. However, we can understand that the error lies in some property of the object. What object? The one indicated in the line An object in this message. In this case, this object is Welding machine inverter VDI 160R (Fixed assets). Already at this moment you can notice a discrepancy. Data upload rule called Leftover Materials, in line Object Conversion Rule (OCR) written Nomenclature, why is the object type written as Fixed assets? Let's look into the source database and check if we really found the correct object.
In the balances of account 10.09 “Inventory and household supplies” we find our problematic object - subconto Welding machine inverter VDI 160R(see Fig. 5.2)
Rice. 5.2. Balance sheet for account 10.09 for 2018
If you open this subconto, you can immediately see that Welding machine inverter VDI 160R is indeed a basic tool, not a nomenclature (see Fig. 5.3). What's left over Welding machine inverter VDI 160R turned out to be a completely obvious error on account 10.09 that needs to be corrected.
Rice. 5.3. Fixed asset card Welding machine inverter VDI 160R
The unloading error in this case occurs due to an incorrect object type. According to the rule for unloading leftover materials, it should be unloaded Nomenclature- materials, fuel, inventory, etc. Such objects have a certain set of properties, which are transferred to another database according to the conversion rule. For objects with type The main thing the set of properties will be completely different. There is no way to unload such an object according to the rule for unloading materials. The program identifies the object as Nomenclature but does not find the necessary properties in it and, accordingly, cannot convert it for writing to a file. This is what the message said Error getting object property value (by source property name).
In this example, the problem can be solved quite easily - in our rules there is a parameter Do not unload balance if quantity is zero. When it is installed, balances with a zero quantity will simply not be unloaded. As you can see in the balance sheet presented in Figure 5.2, the balances of this subconto have no quantity, i.e. this problematic residue can be easily eliminated using the specified parameter.
In other cases, when there is no way to exclude an object using a filter or parameter, the user would have to correct the error in the source database before migrating the data.
An example of an error.
Let's look at an example of another error discovered during data transfer.
When first trying to upload documents, the user saw the following text in system messages. An error message allows us to skip the mechanism of finding when an error occurred and move on to fixing it. Such messages do not always appear, and sometimes you still have to look for an error using the one-by-one unloading method. We have already discussed how to read such a message above.
Fig.6.1. Error message
So, the program itself tells us the problematic document - this is Invoice to the buyer IPBP-000008, which means we immediately go to the document and try to find out what the error is.
As you can see in Figure 6.2, in this document in the tabular section “Goods and Services” in one of the rows the item group is set, and not the item itself, which in itself is an error. Of course, the conversion rules for this document do not specify how to convert an object from this tabular part nomenclature group, this is an element of a completely different type than itself nomenclature, and the program has no information about how to move an element other than what is specified in the rules. Therefore, the conversion process does not recognize it, cannot convert it and throws an error.
Fig.6.2. Document with an error
How and why this was established does not interest us at the moment. We decide not to migrate the document, which means we exclude it from the list of migrated objects. Finding the document upload rule Invoice for payment to the buyer, select it, go to selection, set Field - Link, Comparison Type - Not Equal, Value - our problem document. Thus, we will exclude this document from the list of transferred objects and the upload should proceed normally.
Fig.6.3. Setting preferences for document exclusion
After this, you can continue uploading in a way convenient for you - transfer all documents at once, or transfer only Invoices for payment, with the exception of the found document, and then transfer the rest - the order of data transfer can be any.
It should be noted here that the possibility of selecting objects exists in processing GenericXML Data Exchange not in all typical configurations. More precisely, such functionality is absent in managed application mode. In particular, in a standard configuration Integrated automation rev.1.1 you can work both in regular application mode and in managed application mode, or, as they also say, in managed forms mode. In the first case, selections in standard processing are possible (see Fig. 4), in the second - not. Then you need to use the modified versions of processing (see Fig. 6.3). If the configuration is used in platform compatibility mode 8.2 (this is in particular KA 1.1 And UPP 1.3), then processing is necessary GenericXML Data Exchange versions 2.1.7 . If compatibility mode is not used, such as in the configuration Enterprise Accounting edition 3.0, then you need to work with version processing 2.1.8 . These treatments also have additional capabilities for filling out selections from the log book (more details), so they are not included in all delivery options, but they can always be purchased either as part of packages marked as with selection according to life history, or separately.
This is how, in general, the process of finding and eliminating an error that occurred during the transfer of 1C data looks like.
You can find other useful materials in the Articles section or our main website.
© Anna Balyasnikova, last changes April 2018
Good day, dear blog readers. An article about conversion was previously published on this site
, this article showed
how you can set up an exchange using constructors that create exchange rules.
This method can be used when converting databases from 1C version 7.7 to 8.2.
Now we will talk about how to transfer data between 1C 8.2 configurations, which are slightly different from each other.
The main focus of this article will be on converting the tabular part of the document, which means that
we will work with property group conversion rules - PKGS.
Preparing to set up PKGS - rules for converting a group of properties
We will transfer the “Receipt of Goods and Services” document, which has differences in the VAT Rate attribute of the “Goods” tabular section.
in the source and receiver database. In the source database, this attribute has the type “DirectoryLink.VAT Rates”,
and in the receiver database - the type “TransferLink.VAT Rates”.
By the way, for convenience, you can define
In addition, in the receiver database we need to fill in the “Account BU” detail, which is also located
in the tabular section “Goods” of the document “Receipt of Goods and Services”. We will take the data to fill out from the “Account Accounting” details.
reference book “Nomenclature” of the receiver base.
The situation is complicated by the fact that we will be working with the tabular part, so we need to configure
property group conversion rules - PKGS. We will need to access the current row of the tabular part.
Creating conversion rules for a group of 1C properties
We have already developed conversion rules for the “Receipt of Goods and Services” document.
But for the “Products” tabular part there is no property conversion rules"VAT rates".
You need to add a new property conversion rule by clicking on the “Synchronize properties...” button.
The dialog “Setting up property conversion rules (Receipt of Goods and Services)” will appear.
You need to repeat what was done in the image and click the “OK” button.
Although we have created conversion rule for a property group, but it's not ready yet.
Remember that the details of the tabular section “VAT Rates” differ in the types of values.
In the source database, this attribute has the type “DirectoryLink.VAT Rates”,
and in the receiver database - the type “TransferLink.VAT Rates”. We're missing a rule here
Converting from a directory to an enumeration.
Event handlers for property group conversion rules
To configure property conversion correctly, you need to create a new object conversion rule.
In the dialog that appears, we indicate that the “VAT Rates” directory is converted into a transfer with the same name.
There will be no property conversion rules for this rule.
Therefore, when saving this rule, select “No” in the dialog that appears.
In the dialogue with the question “Create data upload rules?” Let’s also select “No”.
By double-clicking, we will open a dialog with setting up the object conversion rule (PKO) “VAT Rates”.
Here, on the “Event Handlers” tab, select the “On unloading” event and define the “Source” and
“Link Node”, that is, what will be transferred.
LinkNode = "Bid0" ;
ElseIf Source. Bet = 12 Then
NodeLinks = "Bet12" ;
ElseIf Source. Name = “excluding VAT” Then
NodeLinks = "Without VAT" ;
EndIf ;
After writing the handler, click the “OK” button.
In information on handlers:
Source - Custom - uploaded source object (link or custom data).
Link Node - initialized xml link node. Can be used
for example, to initialize properties of other objects.
Now we will explicitly indicate the use of this object conversion rule when unloading the “VAT Rate” attribute.
Go to the “Properties Conversion (*)” tab of the “Receipt of Goods and Services” document and open the conversion
property group “Products”, double-click on the “VAT Rates” property and in the dialog that opens, in the “Rule” field
select the conversion rule for the “VAT Rate” object.
Click the “OK” button.
Now we just need to set up accounting accounts in accordance with the values that are defined for the item.
Let’s go to the “Object Conversion Rules” tab, find the “Receipt of Goods and Services” object and
Double-clicking on it will open the object conversion rules (OCR) dialog.
Let’s go to the “Event Handlers” tab for the “After loading” event and write the following:
LineTC. AccountAccountBU = LineTC. Nomenclature. AccountAccountBU;
EndCycle ;
Now let's load these rules at the source using the external processing "Universal Data Interchange in XML Format" - "V8Exchan82.epf".
Let's upload the data to an xml file. Then, open the same processing in the receiver database and select the upload xml file and load the data.
By the way, the “Universal Data Interchange in XML Format” processing can be opened through the menu item
"Service" | "Other Data Exchanges" | "Universal Data Interchange in XML Format". A little was written about this in a note about.
Textbook on 1C Data Conversion (edition 2) Rules for converting objects
As we already know, object conversion rules are used to match objects in the source and destination configurations. Naturally, the rule specifies the data source object (that is, where to get the data from) and the data receiver object (that is, where to transfer or write the data).
In addition to them, there are a number of properties whose meaning we will try to reveal.
Search for the destination object by the internal identifier of the source object- flag defining the search for objects in the receiver for the V8 platform version. If this flag is checked, then the search for an object for modification in the receiver database is carried out using the internal (unique) identifier of the object. This identifier is not visible to the user, and the program maintains the uniqueness of identifiers in the infobase, so that no two infobase objects have the same identifiers.
Continue searching through search fields if the receiver object is not found by identifier- the flag determines to continue searching for an object in the receiver information base if the search by unique identifier does not lead to a positive result.
Do not replace existing objects in the receiver when loading, but only create new ones and fill them *- the flag determines whether it is necessary to change the object details in the receiver infobase if the object was successfully found by a unique identifier or by search fields.
Don't create a new object in the receiver if it is NOT found *- the flag determines whether a new object needs to be created in the receiver infobase if it was not found by a unique identifier or by search fields.
When transferring an object by reference, DO NOT create a new object, but only transfer the reference- the flag determines whether a new object needs to be created in the receiver infobase if it was not found by a unique identifier or by search fields if the object is transferred by reference. If the object is not found and it is searched by a unique identifier, then only the link to the object will be transferred (without search fields - one link). If the object is unloaded directly (that is, not only the link to the object is unloaded, but also all its details), then the flag does not affect anything.
Do not unload source property objects via links- the flag determines whether it is necessary to unload all objects to which the source object has links or whether it is enough to unload only information about links to these objects. Let's say you are uploading a product reference book. If the corresponding PKO does not have this checkbox selected, then in addition to the item, all objects to which it refers will be unloaded. If the flag is cocked, then the objects to which the nomenclature refers will not be unloaded. Try checking this box and viewing the resulting data upload file, then removing it and comparing the results. You will quickly understand its meaning.
Don't remember unloaded objects- the flag determines whether the system needs to CACHE the last unloaded objects when unloading. Caching allows you to speed up the process of uploading and loading data.
Use quick object search when uploading and loading- the flag determines whether to use a quick search for objects for uploading. It makes sense to use it for a small number of directory entries (the number of entries is no more than 1000 elements). The effect is achieved if many objects have the flag set Do not unload property objects by reference. With this scheme for uploading and loading data, the speed increases several times.
Automatically generate a number or code if it is not specified- the flag determines whether the system needs to automatically generate a new code or object number if it is not filled in before recording.
On-line exchange
Unload an object (entirely), only if there is a link to it- the setting determines under what circumstances the object must be unloaded. If the checkbox is checked, the object will be unloaded according to the following rules:
- According to the rules of unloading, if an object has already been unloaded, then unload it as is
- According to the rules of unloading, if the object was not unloaded, then we do not unload
- When uploading using a link to an object, we upload the entire thing
For example, if you do not need to transfer the entire item from one IS to another, but only the one to which there are links, then the checkbox will do.
Do not replace an object created in the receiver infobase when loading- the setting determines whether it is necessary to transfer (back) an object that was created in the infobase with which the exchange is organized. That is, if a document was created in infobase 1 and entered infobase 2 through an exchange, then should it be transferred to infobase 1 when changed in database 2? The setting allows you to specify the priority of an object when exchanging at the place of its creation. That is, changes in the infobase where the object was created are distributed everywhere, and changes in other databases do not affect this object in database 1.
Load object priority- the setting determines the priority of the object when loading in case of a collision of changes. The default value and in the case of an empty value is Above. If a collision occurs, the program analyzes the priority of the download object. Only if the priority of the download object is equal to Above will it be recorded in the receiver's infobase. If the priority is Same or Below, the program will record the corresponding information about the collision in the information base, but will not change the object.
Search field settings options- a table with possible options for setting up search fields for the user. The rule designer defines the possible combinations of search fields that a user can select when setting up an exchange. All settings specified by the rule developer must be processed in the “Search Fields” handler code. The SearchSettings variable in the handler determines the user-selected matching option (SettingNameForAlgorithm from the corresponding table row). If the user did not select any matching option, or was not offered any option, then Search Settings is an empty string.
On the "Advanced" tab, you can edit the name of the rule, its inclusion in a specific group, as well as the description of the rule.
