Преобразуване на данни
Тук се фокусирам върху създаването на subconto, тъй като това причинява основната трудност.
1. Създаване на правило за качване на данни.
Това правило генерира таблица със стойности за транзакции.
Разтоварване на кода на правилото:
Най-важният ред, необходим за Subconto:
SubcontoDt . Вмъкване ( Нова структура ( "Код" , "00005") , CurrentStringRequestResult . Изпълнител )
Нова структура ("Код", "00005") - добавя се кодът на елемента от плана на видовете характеристики, както е дефиниран в базата за получаване (в случая това е елемент "Изпълнители").
2. Създаване на правила за преобразуване на обекти
- За документа "Оперативно счетоводство"
получател - реквизит "Самоиздръжка" на документ "Оперативно счетоводство"

Ето основната линия:
Попълва се по същия начин за получателя и SubcontoKt
- За плана на видовете характеристики "Видове самоподдържащи се подсметки"
- За Subconto "Контрагенти"
3. Довършителен щрих
Нещо, което не съм виждал в нито един източник: ако в източника са създадени няколко правила за конвертиране на обекти от един и същи тип (например за контрагенти са създадени две правила за конвертиране на данни), то за да попадне системата в желаното правило, приоритетът на това правило трябва да е най-високият сред тях.
Реших да публикувам публикацията, тъй като аз самият прекарах доста време, докато намеря правилното решение. В литературата, която съществува, този момент е описан слабо, много правила за обмен трябваше да бъдат преразгледани.
Специални оферти











Изправени пред това как да прехвърлите непопълнени подконто, но в същото време компютърът оставя възможността за последващо прехвърляне на документа Операционна сметка с попълнени подконто. Просто недефинираният универсален обмен не се приема: прокълнат поради липсата на итератор. Това помогна:
Не разбрах напълно защо този ред е в манипулатора:
В крайна сметка можете изрично да посочите обекта в колоната „Правило за преобразуване“. Обикновено горната техника се използва, когато дадено правило трябва да бъде избрано динамично въз основа на входящи данни.
Също и с приоритет - според мен е очевидно, че едни и същи правила уреждат приоритета.
Благодаря ти! Статията като цяло помогна да намеря окончателното правилно решение за моя подобен проблем.
Ще добавя 5 копейки, които не са споменати тук, но за мен бяха много важни:
1. В SCS SubcontoDT (подобно на Kt) е необходимо да се добави условие в манипулатора по време на разтоварване за използване на PQS за различни типове subconto, по-специално: OtherwiseIf ValueType(Subconto) = Type("CatalogReference.GTE Numbers") Then PCOName = "GTE Numbers"; OtherwiseIf ValueType(Subconto) = Type("CatalogReference.WorldCountryClassifier") Then PCOName = "WorldCountryClassifier"; EndIf;
2. Така от т.1 следва, че не е необходимо да се създава отделно правило с различен приоритет!
3. Цялата заявка с по-нататъшното й прехвърляне към таблицата "IncomingData" е описана в PKO "OperationInput", редът "UploadBy Rule(, ,IncomingData , , "OperationInput");" - е излишен. Доколкото разбирам, важно е за примера с алгоритъма за разтоварване в PVD.