Създаваме отчет с определена честота в системата за съхранение. Стандартен параметър & Период и проблеми при използване на 1s стандартен период в заявка

Нека създадем отчет с един набор от данни за заявка:

Сега нека отидем в раздела с параметри и да видим, че системата, в допълнение към нашия параметър &MyDate, също е създала параметъра &Period.
За да наблюдаваме визуално периодите, ще създадем основна форма за отчет и ще поставим таблично поле с данни върху нея: Settings Composer.Settings.DataParameters

Нека запазим отчета и го отворим в предприятието. В полето на таблицата с параметри се показва само параметърът &Период:

Съответно всяка промяна в този параметър няма да даде желания резултат.

Защо параметърът &MyDate не е наличен? Разбира се, защото в раздела параметри той има отметка Ограничение на наличността.

Махнете отметката от квадратчето. Сега виждаме и двете в наличните параметри. Само при генериране на отчета ще видим, че отчетът реагира на параметъра &Period, а не на &MyDate.

В този пример най-простото нещо, което трябва да направите, е да преименувате параметъра &MyDate в заявката на &Period и да постигнете желания резултат. Но може би имате заявка, в която параметърът &Period вече е бил използван, или вашите религиозни възгледи не ви позволяват да използвате този параметър, във всеки случай можете да разрешите проблема по следния начин:

UPDот потребителя бу!:

Основният проблем при използване на „стандартни“ (добавени от системата) параметри е, че при използване на няколко виртуални таблици в отчет, ако този параметър е дефиниран, неговата стойност ще се използва във всички останали случаи вместо „собствените“.

Нека ви дам един пример:

Във втората подзаявка стойността на „стандартния“ параметър PERIOD ще се използва като параметър за дата на отрязък, а не стойността OtherDate.

Този „проблем“ ще бъде наблюдаван дори ако втората подзаявка е изведена към втория набор от данни и е свързана с помощта на ACS. Опцията, използваща във втората заявка израз като „ADDATE(&Period, MONTH, -1)“ също няма да работи, месецът няма да бъде изваден. Но преименуването на параметъра „Период“ в заявката например на „Първа дата“ решава този проблем.

Между другото, точно същият проблем се наблюдава и при виртуалните таблици за натрупване и счетоводни регистри, използвани за получаване например на оборот. Там системата добавя параметрите „Начало на периода” и „Край на периода”.
Така че в случай на заявки с дори леко повишена сложност, има смисъл да изключите наличността и използването на „стандартни периоди“.

И така, да започваме.

За простота, разбирайки примера, ще изградим един прост циркулиращ регистър за натрупване.

В моя случай това е набирателният регистър "Осчетоводяване на незавършеното производство".

Например, ние ще посочим неговите параметри твърдо (а не чрез меко налагане на параметри върху системата за контрол на достъпа):

Моля, обърнете внимание, че честотата на виртуалната маса е „Запис“.

Но, както беше отбелязано по-горе, имаме нужда от периода по отношение на периодичността, така че предлагам да изчислим полето „Период“ по следния начин (не е много хубаво, но не съм виждал по-добри опции):

Както се вижда от екранната снимка, към заявката се предава параметър, който потребителят посочва във формуляра: Стойността на изброяването "Честота" - това изброяване се среща в почти всички стандартни решения.

Ще посочим наличните му типове в раздела „Параметри“:

С тази настройка форматираме цикъла си, така че всичко да е красиво и приятно за окото)

Ето и самите формати:

Месец: DF="MMMM yyyy "y.""

Ден: DF = дд.ММ.гггг

Седмица: DF = ""Седмица от "дд.ММ.гггг"

Квартал: DF = "до "квартал" yyyy "y.""

Година: DF = "yyyy "y.""

Десетилетие: DF = ""Десетилетие с "dd.MM.yyyy"

Половин година: DF = ""Половин година от" дд.ММ.гггг"

Това е всичко. Резултатът е прекрасна картина:

Тази статия обсъжда някои от характеристиките на настройка на период при използване на система за съставяне на данни (DCS), проблеми, които възникват поради разликите в концепцията за период между обикновен потребител и системата 1C, а също така предлага начини за разрешаването им .
Повечето отчети, които са разработени с помощта на система за съставяне на данни (DCS), изискват от потребителя да въведе периода, за който ще бъде съставен отчетът. По правило в ACS въвеждането на периода се организира чрез параметри, като се използва следната конструкция, вж. Фиг. 1Този метод за въвеждане на период се счита за „класически“, той е описан в статия за ITS и друга литература, посветена на развитието в 1C, така че нека го вземем за основа. Нека разгледаме като пример проста заявка, която получава всички документи Продажби на стоки и услуги за даден период, вж. Фиг.2Когато използва този отчет, потребителят задава периода чрез параметрите, вж. Фиг.3Всичко изглежда правилно... НО има малък проблем:

Работата е там, че по-голямата част от потребителите „разбират“ периода по различен начин, отколкото 1C го „разбира“, примери:
1). Нека помислим Фиг.3
От гледна точка на потребителя периодът не е посочен, т.е. НЕОГРАНИЧЕН, тоест ВСИЧКИ документи без ограничения за дата трябва да бъдат включени в отчета.
„От гледна точка“ на системата 1C параметърът-период е зададен и ... двете му граници са равни на 01.01.0001 и само документи с празна дата ще бъдат включени в отчета, което на практика означава нито един документ няма да бъде включен.
2). Нека помислим Фиг.4
От гледна точка на потребителя отчетът трябва да включва всички документи от датата 28.01.2010 г.
„От гледна точка“ на 1C, периодът 28.01.2010 г. – 01.01.0001 г. ще предизвика изключение.

Можете, разбира се, да се опитате да обясните на потребителя защо отчетът не показва документите, които той очаква да види, и как периодът е представен от „гледната точка“ на 1C, но това е неблагодарна задача и също е грешно. Една добра програма трябва преди всичко да бъде удобна за потребителя, защото програмата съществува за потребителя, а не обратното, следователно ще трябва да „научите“ 1C да разбира периода, както го разбира потребителят, а именно:
1). Началото на периода и краят на периода не са посочени -> всички документи.
2). Посочва се само Началото на периода –> всички документи започващи от Началото на периода
3). Освен това ще проверим дали Край на периода >= Начало на периода и ако това не е вярно, тогава ще приемем, че Краят на периода не е посочен, т.е. 2).
Въз основа на горното, изразът за параметъра Крайна дата ще изглежда така:

SELECT WHEN &Period.EndDate=DATETIME(1,1,1) THEN DATETIME(3999,12,31,23,59,59) ELSE SELECT WHEN &Period.EndDate<&Период.ДатаНачала ТОГДА ДАТАВРЕМЯ(3999,12,31,23,59,59) ИНАЧЕ &Период.ДатаОкончания КОНЕЦ КОНЕЦ

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

Някои функции за настройка на периода в системата за контрол на достъпа.

Повечето отчети, които са разработени с помощта на система за съставяне на данни (DCS), изискват от потребителя да въведе периода, за който ще бъде съставен отчетът.

Като правило, в ACS, въвеждането на периоди се организира чрез параметри, като се използва следната конструкция, вижте Този метод на въвеждане на периоди се счита за „класически“, той е описан в статия за ITS и друга литература, посветена на развитието в 1C, така че нека го вземем за основа. Нека разгледаме като пример проста заявка, която получава всички документи Продажби на стоки и услуги за даден период, вж.

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

Работата е там, че по-голямата част от потребителите „разбират“ периода по различен начин, отколкото 1C го „разбира“, примери:

От гледна точка на потребителя периодът не е посочен, т.е. НЕОГРАНИЧЕН, тоест ВСИЧКИ документи без ограничения за дата трябва да бъдат включени в отчета.

„От гледна точка“ на системата 1C параметърът-период е зададен и ... двете му граници са равни на 01.01.0001 и само документи с празна дата ще бъдат включени в отчета, което на практика означава нито един документ няма да бъде включен.

От гледна точка на потребителя отчетът трябва да включва всички документи от датата 28.01.2010 г.

„От гледна точка“ на 1C, периодът 28.01.2010 г. - 01.01.0001 г. ще предизвика изключение.

Можете, разбира се, да се опитате да обясните на потребителя защо отчетът не показва документите, които той очаква да види, и как периодът е представен от „гледната точка“ на 1C, но това е неблагодарна задача и също е грешно. Една добра програма трябва преди всичко да бъде удобна за потребителя, защото програмата съществува за потребителя, а не обратното, следователно ще трябва да „научите“ 1C да разбира периода, както го разбира потребителят, а именно:

1). Началото на периода и краят на периода не са посочени -> всички документи.

2). Посочва се само началото на периода -> всички документи, започващи от началото на периода

3). Освен това ще проверим дали Край на периода >= Начало на периода и ако това не е вярно, тогава ще приемем, че Краят на периода не е посочен, т.е. 2).

Въз основа на горното, изразът за параметъра Крайна дата е:

WHEN &Period.EndDate=DATETIME(1,1,1)

ТОГАВА DATETIME(3999;12;31)

КОГА &Период.Крайна дата<&Период.ДатаНачала

ТОГАВА DATETIME(3999;12;31) DATETIME(3999;12;31;23;59;59)

&Период.Крайна дата

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

Забележка: този механизъм за настройка на параметри е предназначен за по-стари платформи 1C 8.1 и 8.2 (и конфигурации, работещи под техен контрол); по-старите версии на платформата 1C имат вградени механизми за управление на празни параметри и няма нужда да прибягвате до механизма описан в тази статия, в допълнение В някои версии на платформата 1C са възможни грешки и неправилна работа.

Добър ден, скъпи читатели на сайта на блога! В последната статия научихме защо са необходими тези роли. И днес, във втората от тази поредица от статии, ще разгледаме настройване на роля със свойството „Период“., а също така разгледайте примери за попълване на тези роли. Остатъкът се изчислява с помощта на полето с роля „Период“. Точно както в полето с ролята на „Измерение“, за която ще говорим друг път. И така, да започваме!

Нека създадем нов отчет:

1. В конфигуратора изберете елемента от менюто „Файл“ - „Нов“ - „Външен отчет“.
2. Кликнете върху бутона „Отворете диаграмата на състава на данните“. В диалоговия прозорец, който се отваря, щракнете върху бутона „Край“.
3. Сега нека създадем, който има достъп до виртуалната таблица „Регистри на натрупване“.
4. Щракнете с десния бутон върху възела „Набори от данни“ и изберете реда „Добавяне на набор от данни - Заявка“.
5. Сега щракнете върху бутона „Конструктор на заявки“. Нека изберем регистъра за натрупване „Стоки в складове, остатъци и обороти“ (USP конфигурация).
6. Нека отворим диалоговия прозорец „Параметри на виртуална таблица“ и посочим, че ще се използва периодичността „Автоматично“, т.е. ще бъде възможно да посочите няколко периода.

Сега нека конфигурираме изходните полета. Нека това са следните полета: „Регистратор“, „ПериодМесец“, „Номенклатура“, „Качество“ и информация за салдата. Добавянето на поле става чрез двукратно щракване с левия бутон на мишката върху желаното поле или чрез бутон “>”. След като добавите полетата, щракнете върху бутона „OK“.

Моля, обърнете внимание, че за някои полета автоматично се конфигурира роля със свойството „Период“.

Да погледнем какво съществува настройки на ролята за свойството „Период“.. Първо се посочва поредният номер на периода. Номерирането трябва да бъде непрекъснато, като се започне от едно, от най-ниските периоди до най-високите, т.е. първо ще има, например, номерът на реда, след това „Рекордер“, след това вторият, ден, седмица, месец, тримесечие, година.

Следователно полетата, които се появяват в нашата заявка, трябва да бъдат номерирани. Забележете, че имаме две полета за период - "Регистратор" и "ПериодМесец". Ниското поле е „Регистратор“, присвоено му е едно, а високото поле е „ПериодМесец“, присвоено му е две. Ще разгледаме това по-подробно в следващата статия.

Нека настроим нашия отчет:

1. Нека отидем в раздела "Ресурси" и дефинираме ресурсите на нашия отчет.
2. Щракнете върху бутона “>>”, за да изберете всички полета за ресурси.
3. Сега нека отидем в раздела „Настройки“ и да създадем настройка под формата на списък.
4. Кликнете върху бутона „Дизайнер на настройки за съставяне на данни“ (бутонът под формата на магическа пръчка).
5. Тип отчет: "Списък". Щракнете върху бутона "Напред".
6. Нека конфигурираме изходните полета, като щракнете върху бутона ">>". Нека ги подредим така: “ПериодМесец”, “Номенклатура”, “Качество”, “Регистратор”.
7. Щракнете върху бутона „Напред“ и настройте групирането. Ще настроим групирането в следния ред: “ПериодМесец”, “Номенклатура”, “Качество”. Групирането „Регистратор“ ще се покаже под формата на подробни записи.
8. Щракнете върху бутона „OK“.

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

И тази грешка е свързана с функцията за получаване на салда от регистратора. За да се показват коректно тези салда, трябва да добавите още едно поле към изходните полета на заявката - полето “PeriodSecond”. За да добавите полето „PeriodSecond“, отворете отчета в конфигуратора и щракнете върху бутона „Отворете схемата за съставяне на данни“. Сега щракнете върху бутона „Query Builder“ и добавете „PeriodSecond“. В този случай полето “Регистратор” ще остане първото поле на периода, “PeriodSecond” ще бъде второто, а “PeriodMonth” ще бъде третото.

За какво е секунда? Системата за съставяне на данни изчислява баланси чрез изчисление и за да се определи недвусмислено позицията на записващото устройство върху времевата ос, връзката към самия записващо устройство не е достатъчна; необходима е и секунда, тоест датата на този записващ файл, и тогава системата за оформление ще може да получи правилния баланс чрез изчисление. Ако посочим правилния ред на полетата и генерираме отчета отново, ще получим:

Сега не остана остатък за стартиране на дейности по номенклатурата на Плинта. След това за следващия период съвпада с крайния баланс, тоест виждаме наистина правилен резултат. Можете да изтеглите примерен отчет от връзката по-долу. Хареса ли ви статията? Какво може да се промени, какво може да се добави? Чувствайте се свободни да споделите за това в коментарите!

В края на статията искам да ви препоръчам един безплатен от Анатолий Сотников. Това е курс от опитен програмист. Той ще ви покаже на отделна основа как да създавате отчети в системата за контрол на достъпа. Просто трябва да слушате внимателно и да запомните! Ще получите отговори на следните въпроси:

• Как да създадете прост отчет със списък?
• За какво служат колоните Поле, Път и Заглавие в раздела „Полета“?
• Какви са ограниченията за полетата за оформление?
• Как да конфигурирате правилно ролите?
• Какви са ролите на полетата за оформление?
• Къде мога да намеря раздела за съставяне на данни в заявка?
• Как да конфигурирате параметрите в системата за контрол на достъпа?
• Става още по-интересно...

Може би не трябва да се опитвате сами да сърфирате в интернет в търсене на необходимата информация? Освен това всичко е готово за употреба. Просто започнете! Всички подробности за това какво има в безплатните видео уроци

Ето един от уроците за маркиране на състава на данните в заявка: