Грешка при изчисляване на салда в SKD и неговата софтуерна корекция, използвайки примера на универсален отчет. Неправилно изчисляване на салда при използване на skd 1s skd начални и крайни салда

Друга често срещана грешка при създаване на отчети за ACS за 1s предприятие е, че началните и крайните салда във виртуалните таблици на регистрите за натрупване са неправилно изчислени. Например, нека създадем прост отчет, който ще показва салда и движения в регистъра GoodsInWarehouses. Искането му ще изглежда така:

Ще създадем и прости вариантни настройки:

В резултат на това получаваме следния отчет:

Имате въпрос, имате нужда от помощта на консултант?

защото никъде не посочихме началото и края на периода, справката трябва да показва данни от началото на базата данни. Но в нашите групировки по склад и номенклатура има ненулеви начални салда. Лесно е да се разбере, че данните се показват неправилно, т.к. в началото на базата данни не трябва да има никакви остатъци. Въпреки че самото искане е правилно.

Факт е, че SKD има свой собствен механизъм за изчисляване на балансите. За правилната му работа е необходимо еднозначно определяне на разположението на записващите устройства по времевата ос. В този случай в селекцията има само препратка, така че системата за свързване не може да направи това. За да избегнете подобно поведение на ACS, изберете полето PeriodSecond в заявката. В този случай системата ще изчисли правилно балансите:

Трябва да се помни, че полетата с ролята "Точка" имат отметка "Допълнителни". И ако по някаква причина се изчисти от полето PeriodSecond, отчетът ще се върне към неправилната версия. За правилното изчисляване на салда или флагът "Допълнително" трябва да бъде отметнат в ролята, или полето трябва да присъства в избраните полета на отчета на ниво вариант.

Не знам колко хора вече са се сблъскали с грешка при изчисляване на начални и крайни салда по групи. Лично аз имах "късмет", освен това повече от веднъж. Причината, както успях да разбера, се крие в неправилните настройки на полетата с данни на ACS, важността на които много начинаещи (и не толкова) програмисти все още не са напълно наясно.

Когато SKD набор от данни се създава автоматично въз основа на заявка, обикновено няма проблем, тъй като самата платформа правилно попълва настройките на полето въз основа на текста на заявката. Но има ситуации, когато настройките на полето за данни не се попълват автоматично (например, използвате външен източник на данни), докато изходните данни съдържат движения с салда и обороти.

Ако не сте се сблъсквали с този проблем преди, тогава за по-добро разбиране на същността му предлагам да го възпроизведете сами, като използвате универсален отчет (по метаданни). Стартираме отчета, избираме всеки непразен регистър за натрупване със салда и обороти, поставяме отметка в квадратчето „Подробни записи“ в настройките на отчета (), посочваме някои групи и добавяме Регистратора към показаните полета. Voila - началният и крайният баланс се сумират за всяко групиране. Получава се отчет с абсолютно неверни цифри, които не могат да бъдат показани на потребителите по никакъв начин.

За да разрешите този проблем, е необходимо правилно да попълните настройките за полетата на набора от данни на ACS - по-специално полето "Роля", което е от ключово значение.

РЕШЕНИЕ интерактивно ( не е подходящ за Universal Report):

Отворете схемата за оформление на данните на вашия отчет и погледнете настройките на полето за набор от данни.

За полетата начален и краен баланс за всеки от ресурсите трябва да попълните ролята: изберете ролевата група "Остатък" и в нея посочете съответно стойността "Начален баланс" или "Краен баланс". Така ( ) това се прави в SKD конструктора.

По същия начин трябва да зададете ролята „Измерение“ за всички измерения на вашия набор от данни.

Но това не е достатъчно, за да работят отчетите правилно. За правилното изчисляване на остатъчните полета е необходимо да знаете периода на всяко движение, за да ги подредите в правилния хронологичен ред. Ако вашият оригинален източник на данни няма поле за период, трябва да го добавите там.Ако вече има поле за период в набора от данни, трябва да посочите ролята "Период" и съответния номер на период (за повече подробности относно номерирането на периоди вижте помощта).

Такива настройки на полетата с данни на ACS в повечето случаи позволяват да се постигне правилно изчисление на остатъците чрез групиране, когато с настройки по подразбиранете са изчислени неправилно.

Софтуерно РЕШЕНИЕ (на примера на Universal Metadata Report):

Сега нека видим как да коригираме същата грешка в отчета за общи метаданни. Универсалният отчет се различава от повечето други отчети по това, че схемата за съставяне на данни се генерира напълно програмно, така че вие ​​също трябва да конфигурирате програмно роли за полета с данни на ACS.

За роли начален и краен баланс за всеки от ресурситенай-лесният начин е да не преоткривате колелото (всичко вече е написано пред нас) и да използвате стандартната процедура FillDataSetFieldRemainder() отобщ модул GenericReports. Подавате там полето за набор от данни и името на ресурса като параметри и в резултат на това полето за остатък с правилно попълнена роля се създава в набора от данни.

По същия начин, когато създавате полета за набор от данни за измерения, трябва да им дадете ролята на измерение. Кодът ще бъде нещо подобно:

NewDimension = GenericReports.AddDataSetField(DataCompositionSchema.DataSets, Dimension.Name, Dimension.Synonym); NewDimension.Role.Dimension = true;

Описаните по-горе манипулации с полетата за ресурс и измерване са необходими, но не достатъчни за решаване на проблема - основният проблем на универсалния отчет е липсата на номериране на периоди. Полетата за период присъстват в набора от данни, но техните роли не са попълнени.

Полетата за периода се добавят към отчета чрез процедурата на генеричния модул GenericReports.AddPeriodFieldsToDataSet(), която се извиква от процедурата на обектния модул AddDataSetFields(). За съжаление тази процедура не записва номерата на периодите.

Освен това полетата "Номер на ред" и "Регистратор" никъде не се добавят програмно към отчета. Стори ми се странно, защото. те присъстват в крайния набор от данни.

Както се оказа, полета "Номер на ред" и "Регистратор"(Рекордер) се добавя от самата платформа автоматично, когато се инициализира конструкторът на настройките. Освен това платформата не попълва ролите за полетата, които създава, и е невъзможно програмното им попълване, което създава проблеми при по-нататъшната работа с тях. Но ако тези полета са създадени „ръчно“ и програмно са им присвоени правилните роли, тогава платформата не се опитва да ги създаде отново.

По-долу предлагам рецепта, която ми помогна почти напълно да разреша този проблем на платформата и универсалния доклад за метаданни:

Ето кодовия фрагмент на обектния модул:

// Добавяне на полета за период Ако TableName = "RemaindersAnd Turnovers" ИЛИ TableName = "Turnovers" Тогава GenericReports.AddPeriodFieldsToDataSet(DataCompositionScheme.DataSets); EndIf; трябва да се замени със следното: // Добавяне на полета за период If TableName = "RemaindersAnd Turnovers" ИЛИ TableName = "Turnovers" Then ListPeriods = GenericReports.AddPeriodFieldsToDataSet(DataCompositionScheme.DataSets); //Попълнете служебните полета и задайте ръчно периодите, т.к платформата не ги попълва Field = GenericReports.AddDataSetField(DataCompositionScheme.DataSets, "LineNumber", "LineNumber"); Field.Role.PeriodNumber = 1; Поле = GenericReports.AddDataSetField(DataCompositionSchema.DataSets, "Recorder", "Recorder"); Field.Role.PeriodNumber = 2; sc = 3; За всеки цикъл FieldPeriodFromListPeriods FieldPeriod.Value.Role.PeriodNumber = cn; Ако брой > 3 Тогава FieldPeriod.Value.Role.PeriodType = DataCompositionPeriodType.Optional; EndIf; sc = sc + 1; EndCycle; EndIf;

Успях да намеря едно ограничение, свързано с това решение. За правилното изчисляване на и против. остатъци, е необходимо при използване на каквито и да било данни от документа на регистратора в отчета да бъде избран и самият регистратор. В противен случай универсалният доклад след такива подобрения вече не предизвиква алергии у потребителите.

АКТУАЛИЗАЦИЯ: В коментарите ми казаха, че статия по тази тема някога е била публикувана на ITS диска. За съжаление тази статия ме подмина, но можеше само частично да ми помогне при решаването на проблеми с универсален доклад. Уви, проблемите на платформата с обслужването SKD полета, като "Записващо устройство", също не са описани там.

Във всеки случай се надявам, че моята статия ще помогне на всички, които имат подобни проблеми. Прекарах много време в търсене на това решение...

Добър ден, скъпи читатели на сайта на блога! Миналия път вече засегнахме темата, която говори за използването на функцията. И днес, в първата от тази поредица статии, ще научим за какво са предназначени ролите на полето за съставяне на данни, а също така разгледайте примери за попълване на тези роли.

Ролята на полето SKD показва какво е това поле. Всяка роля на поле може да съдържа собствено свойство. Например има числова стойности съдържа номера на периода, ако полето е точка. Ако стойността на свойството "Точка" е 0 (нула), това означава, че това поле не е точка. Или свойството "Размер" - съдържа знак, че полето е измерение. Ако полето е измерение, тогава тази информация се използва при изчисляване на сумите за останалите полета.

Можете да зададете роля за всяко поле на схемата за съставяне на данни. Роли влияят върху правилността на изчисляването на остатъците. По-специално, началният и крайният баланс за дадена маса. Ако в заявката е избрана виртуална таблица "Салда и обороти", тогава началните и крайните салда се изчисляват по сложен алгоритъм, особено ако използваме допълнителни сторнирания по периоди.

Но ако всичко това работи правилно в заявките, според набора от изходни полета, тогава нещата са малко по-лоши при съставянето на данни. В края на краищата, ние не знаем кои полета всъщност ще избере потребителят. Всичко ще зависи от конфигурацията на неговата версия на отчета, която той може да промени по всяко време. Следователно системата за съставяне на данни има свой собствен механизъм за изчисляване на първоначалните и крайните остатъци за определен набор от данни и ролите се използват съответно за това. Нека го отворим и да видим, че за всяко поле можете да задавате роли.

Нека добавим набор от данни за заявка. За да направим това, трябва да направим основния елемент "Query Builder" активен. Нека се обърнем към виртуалната таблица "Салда и обороти" на натрупващия регистър. какво виждаме

Както можете да видите от илюстрацията по-горе, можем да видим, че за някои полета ролята е попълнена. Това се случи, защото имаме зададен флаг "AutoComplete". Но това не винаги е възможно, така че понякога трябва да зададете ролята ръчно. Нека да видим няколко примера.

Да приемем, че в заявката, която използваме, например, използваме оператора на езика за заявки „SELECT“. Нека опишем това състояние:

CHOICE WHEN Остатъци от стоки Остатъци и обороти.Номенклатура = Стойност(Каталог.Номенклатура.EmptyReference) THEN Стойност(Директория.Номенклатура.Шампоан) ELSE Остатъци от стокиОстатъциИОбороти.Номенклатура END

Този запис означава, че ако номенклатурата съответства на нулева препратка (препращаме към препратката към стойността на функцията „Номенклатура“, нулева препратка), тогава ще бъде върната стойността на предварително дефинирания елемент. Да приемем, че в нашата конфигурация има такъв предварително дефиниран елемент и той се нарича "Шампоан". В противен случай връщаме стойността на самия артикул. Получаваме следното:

Както можете да видите, за полето "Номенклатура" ролята не е изпълнена. Но както можете да видите на изображението, всъщност ние нямаме зададена роля за полето „Field1“ и в този случай остатъкът няма да бъде изчислен правилно.

Има и други примери, при които ролята не може да бъде зададена сама. Например, това е използването, тоест определена таблица със стойности се подава във входа, например, заредена от друга база данни, и остатъците трябва да бъдат изчислени от нея. В този случай трябва сами да си разпределим ролите. Как се прави това, ще разгледаме в.

В края на статията искам да ви посъветвам безплатно от Анатолий Сотников. Това е курс от опитен програмист. Той ще ви покаже на отделна основа как да създавате отчети в ACS. Просто трябва да слушате внимателно и да запомните! Ще получите отговори на въпроси като:
  • Как да създадете прост отчет със списък?
  • За какво служат колоните Поле, Път и Заглавие в раздела Полета?
  • Какви са ограниченията за полетата за оформление?
  • Как правилно да настроите ролите?
  • Какви са ролите на полетата за оформление?
  • Къде мога да намеря раздела за оформление на данни в заявка?
  • Как да конфигурирате параметри в SKD?
  • Още по-интересно...
Може би не трябва да се опитвате сами да сърфирате в интернет в търсене на необходимата информация? Освен това всичко е готово за употреба. Просто започнете! Всички подробности за това какво има в безплатните видео уроци

Не знам колко хора вече са се сблъскали с грешка при изчисляване на начални и крайни салда по групи. Лично аз имах "късмет", освен това повече от веднъж. Причината, както успях да разбера, се крие в неправилните настройки на полетата с данни на ACS, важността на които много начинаещи (и не толкова) програмисти все още не са напълно наясно.

Когато SKD набор от данни се създава автоматично въз основа на заявка, обикновено няма проблем, тъй като самата платформа правилно попълва настройките на полето въз основа на текста на заявката. Но има ситуации, когато настройките на полето за данни не се попълват автоматично (например, използвате външен източник на данни), докато изходните данни съдържат движения с салда и обороти.

Ако не сте се сблъсквали с този проблем преди, тогава за по-добро разбиране на същността му предлагам да го възпроизведете сами, като използвате универсален отчет (по метаданни). Стартираме отчета, избираме всеки непразен регистър за натрупване със салда и обороти, поставяме отметка в квадратчето „Подробни записи“ в настройките на отчета (), посочваме някои групи и добавяме Регистратора към показаните полета. Voila - началният и крайният баланс се сумират за всяко групиране. Получава се отчет с абсолютно неверни цифри, които не могат да бъдат показани на потребителите по никакъв начин.

За да разрешите този проблем, е необходимо правилно да попълните настройките за полетата на набора от данни на ACS - по-специално полето "Роля", което е от ключово значение.

РЕШЕНИЕ интерактивно ( не е подходящ за Universal Report):

Отворете схемата за оформление на данните на вашия отчет и погледнете настройките на полето за набор от данни.

За полетата начален и краен баланс за всеки от ресурсите трябва да попълните ролята: изберете ролевата група "Остатък" и в нея посочете съответно стойността "Начален баланс" или "Краен баланс". Така ( ) това се прави в SKD конструктора.

По същия начин трябва да зададете ролята „Измерение“ за всички измерения на вашия набор от данни.

Но това не е достатъчно, за да работят отчетите правилно. За правилното изчисляване на остатъчните полета е необходимо да знаете периода на всяко движение, за да ги подредите в правилния хронологичен ред. Ако вашият оригинален източник на данни няма поле за период, трябва да го добавите там.Ако вече има поле за период в набора от данни, трябва да посочите ролята "Период" и съответния номер на период (за повече подробности относно номерирането на периоди вижте помощта).

Такива настройки на полетата с данни на ACS в повечето случаи позволяват да се постигне правилно изчисление на остатъците чрез групиране, когато с настройки по подразбиранете са изчислени неправилно.

Софтуерно РЕШЕНИЕ (на примера на Universal Metadata Report):

Сега нека видим как да коригираме същата грешка в отчета за общи метаданни. Универсалният отчет се различава от повечето други отчети по това, че схемата за съставяне на данни се генерира напълно програмно, така че вие ​​също трябва да конфигурирате програмно роли за полета с данни на ACS.

За роли начален и краен баланс за всеки от ресурситенай-лесният начин е да не преоткривате колелото (всичко вече е написано пред нас) и да използвате стандартната процедура FillDataSetFieldRemainder() отобщ модул GenericReports. Подавате там полето за набор от данни и името на ресурса като параметри и в резултат на това полето за остатък с правилно попълнена роля се създава в набора от данни.

По същия начин, когато създавате полета за набор от данни за измерения, трябва да им дадете ролята на измерение. Кодът ще бъде нещо подобно:

NewDimension = GenericReports.AddDataSetField(DataCompositionSchema.DataSets, Dimension.Name, Dimension.Synonym); NewDimension.Role.Dimension = true;

Описаните по-горе манипулации с полетата за ресурс и измерване са необходими, но не достатъчни за решаване на проблема - основният проблем на универсалния отчет е липсата на номериране на периоди. Полетата за период присъстват в набора от данни, но техните роли не са попълнени.

Полетата за периода се добавят към отчета чрез процедурата на генеричния модул GenericReports.AddPeriodFieldsToDataSet(), която се извиква от процедурата на обектния модул AddDataSetFields(). За съжаление тази процедура не записва номерата на периодите.

Освен това полетата "Номер на ред" и "Регистратор" никъде не се добавят програмно към отчета. Стори ми се странно, защото. те присъстват в крайния набор от данни.

Както се оказа, полета "Номер на ред" и "Регистратор"(Рекордер) се добавя от самата платформа автоматично, когато се инициализира конструкторът на настройките. Освен това платформата не попълва ролите за полетата, които създава, и е невъзможно програмното им попълване, което създава проблеми при по-нататъшната работа с тях. Но ако тези полета са създадени „ръчно“ и програмно са им присвоени правилните роли, тогава платформата не се опитва да ги създаде отново.

По-долу предлагам рецепта, която ми помогна почти напълно да разреша този проблем на платформата и универсалния доклад за метаданни:

Ето кодовия фрагмент на обектния модул:

// Добавяне на полета за период Ако TableName = "RemaindersAnd Turnovers" ИЛИ TableName = "Turnovers" Тогава GenericReports.AddPeriodFieldsToDataSet(DataCompositionScheme.DataSets); EndIf; трябва да се замени със следното: // Добавяне на полета за период If TableName = "RemaindersAnd Turnovers" ИЛИ TableName = "Turnovers" Then ListPeriods = GenericReports.AddPeriodFieldsToDataSet(DataCompositionScheme.DataSets); //Попълнете служебните полета и задайте ръчно периодите, т.к платформата не ги попълва Field = GenericReports.AddDataSetField(DataCompositionScheme.DataSets, "LineNumber", "LineNumber"); Field.Role.PeriodNumber = 1; Поле = GenericReports.AddDataSetField(DataCompositionSchema.DataSets, "Recorder", "Recorder"); Field.Role.PeriodNumber = 2; sc = 3; За всеки цикъл FieldPeriodFromListPeriods FieldPeriod.Value.Role.PeriodNumber = cn; Ако брой > 3 Тогава FieldPeriod.Value.Role.PeriodType = DataCompositionPeriodType.Optional; EndIf; sc = sc + 1; EndCycle; EndIf;

Успях да намеря едно ограничение, свързано с това решение. За правилното изчисляване на и против. остатъци, е необходимо при използване на каквито и да било данни от документа на регистратора в отчета да бъде избран и самият регистратор. В противен случай универсалният доклад след такива подобрения вече не предизвиква алергии у потребителите.

АКТУАЛИЗАЦИЯ: В коментарите ми казаха, че статия по тази тема някога е била публикувана на ITS диска. За съжаление тази статия ме подмина, но можеше само частично да ми помогне при решаването на проблеми с универсален доклад. Уви, проблемите на платформата със сервизни полета на ACS, като например "Recorder", също не са описани там.

Във всеки случай се надявам, че моята статия ще помогне на всички, които имат подобни проблеми. Прекарах много време в търсене на това решение...

41
Наскоро направих отчет с неопределен брой колони. Не исках да се забърквам с кода, реших да го направя на ACS. Нямаше проблем с това, беше необходимо резултатът да се разтегне до произволно оформление (собствено заглавие + ... 27
Въпреки че учащите SKD се натъкват на това на първия или втория ден, то трябва да е в секцията с често задавани въпроси. Прост пример за програмно извеждане на отчет за оформление с помощта на настройките по подразбиране. //Вземете схема от... 18
При генериране на отчети на ACS, по подразбиране всички групи се разширяват, но се случва веднага след генерирането да се наложи да се покаже отчет със свити групи! Този код в модула за отчет ви позволява да свиете... 10
В този раздел можете да посочите какъв вид връзки се правят между два или повече набора от данни, според какви параметри и условия..png 1. "Източник на връзка" - посочва се първият набор от данни, от ... 9
Че при разработване на отчети се изисква потребител с ограничени права да генерира отчет изцяло без проверка на правата! Особено ако RLS е конфигуриран. Има няколко начина да направите това: 1. Инсталирайте...