Підтримка клієнтів:
+38 (050) 434-03-33
  • Про компанію
  • Продукція:
  • Акції
  • Підтримка
  • Партнерство
  • Клуб Головного Бухгалтера
  • Доробки ПК «Облік Ресурсів» за червень 2020
    ЗАГАЛЬНЕ ЗА СИСТЕМОЮ:
    1. Для розділів “Акти виконаних робіт” та “Вихідні рахунки на оплату” створена платна додаткова функція “Експорт у Medoc” Ef_export2medoc.fxp.
    На формі функції передбачені наступні поля:
    • Шаблон звіту“. У цьому полі вказується шаблон документа акта виконаних робіт зі специфікаціями (Actrepsua_medoc.xlt, властивість шаблону REPTAG = “RP_ACTS”) або будь-якого вихідного рахунку на оплату (Chrepua_medoc.xlt, властивість шаблону REPTAG = “REP_CH”), за яким створюється XML-документ для експорту у програму M.E.Doc;
    • Шлях для збереження XML-документів“. У цьому полі вказується папка, у якій зберігаються у створені XML-документи;
    • XML-шаблони“. У цьому полі вказується par-файл документа, за яким створюється XML-документ для експорту у програму M.E.Doc: для акту виконаних робіт це actreps_medoc000000.par, для вихідного рахунку на оплату – chrep_medoc000000.par Обидва документи будуються за xsd-схемою medoc000000.xsd

    Умови відбору записів: “Поточна“, “Відмічені“, “Всі“. За допомогою цих перемикачів виконується відбір документів, за якими створюються XML-документи для експорту у програму M.E.Doc.

    Принцип роботи функції:
    Функція виконує створення XML-документів за відібраними актами виконаних робіт або вихідними рахунками. Кількість створених XML-документів відповідає кількості відібраних актів виконаних робіт або вихідних рахунків.
    Підготовчі роботи у програмі Medoc:
    Користувач перед імпортом у програму Medoc одноразово повинен виконати наступну настройку.
    У програмі Medoc у розділі “Шаблони первинних документів” користувач самостійно або на підставі будь-якого вже існуючого шаблону створює власні шаблони акта виконаних робіт з кодом AFACT01 та вихідного рахунку на сплату з кодом AFCH01.
    Але у шаблоні акта виконаних робіт обов’язково повинні бути присутніми наступні теги:
    DOCDATE – до цього тегу заноситься дата акта виконаних робіт,
    NUM – номер акта,
    DOCSUM – значення поля акта “Всього”,
    DOCSUM_TEXT – поле акта “Всього” прописом,
    SUMPDV – поле акта “ПДВ”,
    SUMWITHOUTPDV – поле акта “Разом без ПДВ”,
    FIRM_NAME – найменування організації з поля “Виконавець:”,
    FIRM_RUKPOS – посада керівника виконавця,
    FIRM_RUK – ПІБ керівника виконавця,
    FIRM_EDRPOU – код ЄДРПОУ організації з поля “Виконавець:”,
    SIDE_CD_K- найменування організації з поля “Замовник:”,
    SIDE_EDRPOU_K – код ЄДРПОУ організації з поля “Замовник:”,
    FIRM_CBANK – код МФО організації з поля “Виконавець:”,
    FIRM_NMBANK – найменування банка організації з поля “Виконавець:”,
    FIRM_RS – номер розрахункового рахунку організації з поля “Виконавець:”,
    SIDE_MFO_K – код МФО організації з поля “Замовник:”,
    SIDE_BANK_K – найменування банка організації з поля “Замовник:”,
    SIDE_CDSHR_K – код МФО організації з поля “Замовник:”,
    OSN_DATA – дата документа, згідно якого виписаний акт виконаних робіт,
    OSN_TIP – найменування документа, згідно якого виписаний акт виконаних робіт,
    OSN_NOMER- номер документа, згідно якого виписаний акт виконаних робіт,
    TAB1_A – значення поля таблиці акта “№ з/п”,
    TAB1_NOMENKLATURA_NAME – значення поля таблиці акта “Найменування”,
    TAB1_A3 – значення поля таблиці акта “Кількість”,
    TAB1_NOMENKLATURA_CHARCODEUMEASURE – значення поля таблиці акта “Одиниця вим.”,
    TAB1_A5 – значення поля таблиці акта “Ціна”,
    TAB1_A6 – значення поля таблиці акта “Сума”.
    У шаблоні вихідного рахунку на сплату обов’язково повинні бути присутніми наступні теги:
    DOCDATE – до цього тегу заноситься дата вихідного рахунку на сплату,
    NUM – номер рахунку,
    DOCSUM – значення поля рахунку “Всього до сплати:”,
    DOCSUM_TEXT – поле рахунку “Всього до сплати:” прописом,
    SUMPDV – поле рахунку “ПДВ:”,
    SUMWITHOUTPDV – поле рахунку “Разом без ПДВ:”,
    FIRM_NAME – значення поля “Постачальник:”,
    FIRM_RUK – ПІБ керівника постачальника,
    FIRM_EDRPOU – значення поля “Код ЄДРПОУ:” постачальника,
    FIRM_ADR – значення поля “Адреса:” постачальника,
    FIRM_TELEFON – значення поля “Тел.:” постачальника,
    SIDE_CD_K – значення поля “Покупець:”,
    SIDE_EDRPOU_K – значення поля “Код ЄДРПОУ:” покупця,
    SIDE_CDADR_K – значення поля “Адреса:” покупця,
    SIDE_TEL_K – значення поля “Тел.:” покупця,
    FIRM_CBANK – значення поля “МФО:” постачальника,
    FIRM_NMBANK – найменування банка з поля “Р/рахунок:” постачальника,
    FIRM_RS – номер розрахункового рахунку з поля “Р/рахунок:” постачальника,
    SIDE_MFO_K – значення поля “МФО:” покупця,
    SIDE_BANK_K – найменування банка з поля “Р/рахунок:” покупця,
    SIDE_CDSHR_K – номер розрахункового рахунку з поля “Р/рахунок:” покупця,
    FIELD1 – значення поля “Останній строк до сплати”,
    TAB1_A – значення поля таблиці рахунку “№ з/п”,
    TAB1_NOMENKLATURA_NAME – значення поля таблиці рахунку “Найменування”,
    TAB1_A3 – значення поля таблиці рахунку “Кількість”,
    TAB1_NOMENKLATURA_CHARCODEUMEASURE – значення поля таблиці рахунку “Одиниця виміру”,
    TAB1_A5 – значення поля таблиці рахунку “Ціна” (Для шаблона “Рахунок (зниж.)” chrep_sale.xlt це значення поля таблиці рахунку “Ціна зі знижкою”),
    TAB1_A6 – значення поля таблиці рахунку “Сума” (Для шаблона “Рахунок (зниж.)” chrep_sale.xlt це значення поля таблиці рахунку “Сума зі знижкою”).
    2. В розділі “Журнал платежів” реалізована можливість прив’язки банківської операції з типом “видаток” до платіжного документу, завдяки якому дана операція виконувалась. Для цього у вказаному розділі, на формі додавання/редагування платежу, групу полів “Платіжний документ” доповнено однойменним полем з можливістю вибору платіжного документу (далі ПД) з розділу “Платіжні документи“, що відповідає даному платежу. При виборі в полі “Платіжний документ” посилання на пов’язаний ПД, в ньому відображається інформація про тип, номер, дату та суму цього ПД, – при цьому поля “Тип“, “Номер“, “Дата” та “Сума” заповнюються відповідними значеннями вибраного ПД та стають недоступними для редагування (ця можливість відновлюється після очистки посилання на ПД в полі “Платіжний документ“).
    Крім цього, для можливості переходу до пов’язаного запису в розділі “Платіжні документи” з розділу “Журнал платежів“, пункт контекстного меню “Перехід у…” (розділу “Журнал платежів“) доповнено підпунктом “Платіжні документи” з реалізацією відповідної стандартної функціональності.
    3. В контекстному меню розділу “Платіжні документи” додано пункти “Відпрацювання в ЖП“, “Анулювання відпрацювання в ЖП” та “Перегляд історії відпрацювання в ЖП” з реалізацією відповідної функціональності для можливості реєстрації по платіжному документу банківської операції з типом “видаток” в розділі “Журнал платежів“, її анулювання та перегляду історії відпрацювання, відповідно. Реєстрація платежу з типом “видаток” в розділі “Журнал платежів“, що створюється за допомогою пункту контекстного меню “Відпрацювання в ЖП“, – є разовою (проводиться на повну суму платіжного документу), тобто можливість часткового відпрацювання відсутня.
    Відображення відмітки про відпрацювання даного платіжного документа в розділі “Журнал платежів” додано на форму редагування його заголовку, – для цього на вкладці “Додаткові дані” групу полів “Дати відпрацювання” доповнено полем “Відпрацювання в ЖП” з відображенням дати пов’язаної виписки з розділу “Журнал платежів“.
    4. В умовах відбору розділу “Платіжні документи“, на вкладці “Додаткові дані“, групу полів “Стан документа” доповнено елементами “Відпрацювання в ЖП“, “у період з” та “по“, де
    • Відпрацювання в ЖП” – комбо-бокс зі значеннями “пусто” (за замовчуванням), “проведено” і “не проведено” для можливості відбору платіжних документів по наявності відмітки про відпрацювання в розділі “Журнал платежів“;
    • у період з” та “по” – поля (типу “дата”) для визначення інтервалу відбору по даті відпрацювання в розділі “Журнал платежів” (доступні для редагування за умови вибору в комбо-боксі “Відпрацювання в ЖП” значення “проведено“).
    5. Оскільки пов’язані записи розділів “Платіжні документи” та “Журнал платежів” є тотожними (відображають факт однієї і тієї ж оплати), то для запобігання подвійному відпрацюванню в обліку господарських операцій (далі ГО), функцію “Відпрацювання в обліку“, в кожному з вказаних розділів, доповнено механізмом перевірки наявності відмітки про відпрацювання в обліку ГО на пов’язаному документі, а саме: за умови наявності на пов’язаному документі вказаної відмітки, програмою видається відповідне повідомлення про те, що відпрацювання в обліку ГО вже зроблене з іншого розділу (за умови відпрацювання в обліку ГО по відміченим документам, доступна можливість пропустити виконання операції відпрацювання для такого поточного документу, а також можливість розповсюдити обрану дію на інші документи з аналогічною проблемою за допомогою чекера “Поширити“).
    6. В контекстне меню розділу “Журнал платежів” додано пункт “Автоматична прив’язка ПД” (SHIFT-F9). Функція, що викликається при його виборі, виконує пошук документів в розділі “Платіжні документи” по обов’язковому збігу реквізитів в заголовку платіжного документа (“Тип“, “Номер“, “Дата“, “Сума“, “Платник” та “Одержувач“), з даними, вказаними в однойменних полях поточного платежу. При цьому пошук платіжного документа (далі ПД) відбувається тільки серед тих ПД, які не містять на заголовку відмітки про відпрацювання в розділі “Журнал платежів” (тобто, не містять дату в полі “Відпрацювання в ЖП” на вкладці “Додаткові дані“). Якщо, раптом, за вказаним вище збігом реквізитів знайдено більше одного ПД, то до поточного платежу буде прив’язаний перший знайдений платіжний документ.
    По завершенні роботи функції “Автоматична прив’язка ПД“, видається повідомлення про кількість успішно прив’язаних платіжних документів.
    7. Функціонал імпорту із зовнішніх файлів, що настроюється (ef_eixdata.fxp), доповнено функцією This.GetLinkPD(), яка виконує пошук існуючого платіжного документа (далі ПД) в розділі “Платіжні документи” за вказаними реквізитами.
    Опис параметрів функції:
    This.GetLinkPD(cTypePD_RNcNumberPDdDatePDnSumPD, [cPayerPD_RN], [cReceiverPD_RN]), де
    • cTypePD_RN – RN типу платіжного документа, який потрібно знайти (обов’язкове для заповнення);
    • cNumberPD – номер платіжного документа, який потрібно знайти (обов’язкове для заповнення);
    • dDatePD – дата платіжного документа, який потрібно знайти (обов’язкове для заповнення);
    • nSumPD – сума платіжного документа, який потрібно знайти (обов’язкове для заповнення);
    • [cPayerPD_RN] – RN платника платіжного документа, який потрібно знайти (необов’язкове для заповнення). За замовчуванням (пусте значення, “”) – відбувається пошук ПД з незаповненим полем “Платник“;
    • [cReceiverPD_RN] – RN отримувача платіжного документа, який потрібно знайти (необов’язкове для заповнення). За замовчуванням (пусте значення, “”) – відбувається пошук ПД з незаповненим полем “Одержувач“.
    Принцип роботи функції This.GetLinkPD():
    Дана функція виконує пошук існуючого платіжного документа в розділі “Платіжні документи” за точним збігом відповідних реквізитів, що передаються в дану функцію у вигляді значень її параметрів. Якщо ПД за вказаними параметрами знайдено, то функція This.GetLinkPD() повертає його RN, інакше – пусте значення (“”).
    Для можливості автоматичного створення зв’язку між платежем, що імпортується в розділ “Журнал платежів“, та відповідним йому ПД, знайденим за допомогою функції This.GetLinkPD(), у таблиці PART створюється (виключно при імпорті у вказаний розділ) додаткове “віртуальне” поле PDRN, яке, для забезпечення вказаної вище можливості, необхідно заповнити RN’ом, отриманим в результаті роботи функції This.GetLinkPD().
    Наприклад, Replace In PART PDRN With This.GetLinkPD(PART.TYPD, PART.NUMD, PART.DATD, PART.ITSUM, PART.ORGFR, PART.ORGTO).
    Модуль “Адміністратор”
    1. В розділах “Карти користувачів Системи” та “Права користувачів“, в перелік розділів, на які призначаються права доступу користувачів, додано розділ “Хронологія зміни запису” (спільний для всіх модулів) з можливістю призначення базового набору прав доступу. Права, що призначені поточному користувачеві на даний розділ, перевіряються і обробляються відповідним чином при роботі з хронологією зміни запису (викликається за допомогою комбінації клавіш “Ctlr+F12”) в тих модулях системи, для розділів яких увімкнене збереження хронології змін. Тобто тепер, робота з хронологією зміни запису неможлива для користувачів, у яких в правах доступу на розділ “Хронологія зміни запису” відсутнє мінімально необхідне для цього право “Читання“.
    Примітка. В модулі “Заробітна плата” доступ до “Журналу хронології“, що викликається за допомогою комбінації клавіш “Ctlr+F12” в розділах “Нарахування/Утримання” та “Постійні виплати“, а також за допомогою кнопки “Перегляд” (на вкладці “Хронологія” в розділі “Настройка Системи“), як і раніше, визначається правом “Журнал запуску автоматичних функцій“. При роботі з хронологією зміни запису, що викликається за допомогою комбінації клавіш “Ctlr+F12” в усіх інших розділах даного модуля, доступ визначається наявністю відповідних прав на розділ “Хронологія зміни запису“.
    В модулі “Бухгалтерія” доступ до “Журналу хронології“, що викликається за допомогою кнопки “Перегляд” (на вкладці “Хронологія” в розділі “Настройка Системи“), як і раніше, визначається правом “Журнал запуску автоматичних функцій“.
    В модулі “Адміністратор” доступ до “Журналу хронології“, що викликається за допомогою кнопки “Історія операцій вилучення даних” (на вкладці “Хронологія” в розділі “Настройка Системи“), зроблено доступним лише для користувачів з наявністю повноваження “Адміністратор системи“.
    2. В розділі “Карти користувачів Системи“, перелік загальносистемних повноважень користувача, що викликається кнопкою “Повноваження: Склад” на формі редагування прав користувача, доповнено новим повноваженням (чекером) “Адміністратор хронології“. Даний чекер стає доступним за умови наявності у поточного користувача повноваження “Адміністратор системи“. За наявності у користувача повноваження “Адміністратор хронології“, при роботі з хронологією зміни запису (викликається за допомогою комбінації клавіш “Ctlr+F12”), йому доступні функції контекстного меню “Очистити історію” та “Відновити“, – за відсутності даного повноваження вказані пункти в контекстному меню не відображаються.
    Примітка. Після перетворення бази даних повноваження “Адміністратор хронології” за замовчуванням відсутнє у всіх користувачів системи.
    3. В розділі “Настройка Системи“, на вкладці “Безпека” додана настройка (чекер) “Завершувати сеанс роботи по тайм-ауту … хвилин“, яка призначена для можливості автоматичного завершення поточного сеансу роботи в системі, за умови відсутності будь-яких дій користувача на протязі часу, вказаного в даній настройці. Поле “” стає доступним для редагування та обов’язковим для заповнення при увімкненні чекера “Завершувати сеанс роботи по тайм-ауту“.
    Для можливості відображення часу, що залишився до завершення поточного сеансу роботи, в перелік кнопок панелі інструментів “Настройки” додана кнопка “Час до завершення сеансу” зі стандартною функціональністю (тобто кожен користувач, в окремо взятому модулі, може налаштовувати відображення і розміщення даної кнопки на панелі інструментів “Настройки” на власний розсуд). При налаштуванні відображення кнопки “Час до завершення сеансу” на панелі інструментів, на ній відображається працюючий таймер зворотного відліку часу до завершення поточного сеансу роботи (у форматі, “хвилини:секунди”), – при натисканні на дану кнопку, час на таймері “скидається” до значення, що вказане в настройці системи “Завершувати сеанс роботи по тайм-ауту … хвилин“.
    Примітка. Слід зазначити, що таймер зворотного відліку часу до завершення поточного сеансу роботи призупиняється під час друку звітів. Крім цього, час даного таймеру приймає значення “00:00” і не рухається за умови, що користувачем налаштовано відображення кнопки “Час до завершення сеансу” на панелі інструментів “Настройки“, а настройка системи “Завершувати сеанс роботи по тайм-ауту … хвилин” вимкнена.
    Особливості функціонування таймеру зворотного відліку часу при роботі в інтерфейсах TouchScreen різних модулів системи:
    • при роботі з інтерфейсом TouchScreen в модулі “Ресторан“, за умови, що таймер зворотного відліку часу добігає нульового значення, замість автоматичного завершення поточного сеансу роботи в системі відбувається автоматичний запуск стартового екрану TouchScreen, тобто перехід до екрану реєстрації користувача;
    • в інтерфейсах TouchScreen “Облік відвідувань” та “Планування відвідувань” модуля “Спорт, краса, здоров’я“, в правому верхньому куті головного екрану, додане відображення таймеру зворотного відліку часу. За умови, що даний таймер добігає нульового значення, у вказаних інтерфейсах відбувається автоматичне завершення поточного сеансу роботи в системі.
    4. В розділі “Карти користувачів Системи“, на формі додавання/редагування облікового запису користувача, вилучено чекер “Термін дії пароля не обмежений“. Відповідно, поле “Пароль діє до” зроблене необов’язковим для заповнення, – відсутність дати в даному полі означає, що термін дії пароля необмежений.
    Ліворуч від поля “Пароль діє до” на формі, що розглядається, додане поле “Обліковий запис діє до” для визначення дати, до якої діє поточний обліковий запис користувача. Відсутність дати в даному полі означає, що термін дії облікового запису необмежений. Перевірка можливості роботи користувача у системі за критерієм тривалості терміну дії облікового запису виконується на формі входу в систему, – за умови невідповідності даному критерію, вхід в модуль стає неможливим по причині блокування облікового запису, про що користувачеві видається відповідне повідомлення.
    Також змінена функціональність поля “Пароль діє до” на формі “Зміна пароля користувача“, що викликається при вході в систему за умови, що період дії пароля даного користувача закінчився, а саме: вказане поле за замовчуванням заповнюється датою, отриманою шляхом додавання до поточної дати значення, що вказане в настройці системи “Тривалість дії пароля … днів” (на вкладці “Безпека“). Якщо кількість днів у даній настройці системи не вказана, то поле “Пароль діє до” на формі, що розглядається, не заповнюється – тобто, термін дії пароля вважається необмеженим. Аналогічна функціональність реалізована також для однойменного поля на формі додаткової функції “Who Am I…“.
    5. В розділі “Настройка Системи“, на вкладці “Безпека“, додана група полів “Настройки безпеки паролів” з наступним переліком елементів:
    • Тривалість дії пароля … днів” – діюча настройка системи, що перенесена з групи полів “Паролі” зі збереженням існуючої функціональності;
    • Кількість збережених паролів” – числове, необов’язкове для заповнення, поле, що призначене для визначення кількості паролів, які при зміні пароля неможливо використовувати повторно (максимальна кількість паролів для збереження, що може бути вказана в даному полі, обмежена значенням 5). Якщо значення в даній настройці не вказане, то всі користувачі системи зможуть при зміні пароля використовувати, при потребі, його попереднє значення. Інакше, якщо значення в даній настройці системи вказане, то при зміні пароля користувачем (одним із існуючих способів: або на формі редагування облікового запису в розділі “Карти користувачів Системи“, або на формі “Зміна пароля користувача“, що викликається при вході в систему, якщо термін дії пароля закінчився, або за допомогою додаткової функції “Who Am I…“) новий пароль, у разі його успішного підтвердження, зберігається у так званому “стеку” паролів поточного користувача, максимальна кількість паролів якого обмежена значенням, вказаним в настройці системи “Кількість збережених паролів“. При заповненому “стеку”, в момент додавання в нього нового паролю, його записи (паролі) вилучаються за методом FIFO (перший пароль в “стеку” вилучається, а новий додається в його кінець). Відповідно, при зміні значення в настройці системи “Кількість збережених паролів” в менший бік, кількість записів (паролів) в “стеку” кожного користувача також зменшується за методом FIFO, – тобто, при необхідності очищення “стеку” для всіх користувачів, достатньо очистити значення даної настройки системи.
    При зміні пароля користувачем (любим з наведених вище способів) виконується перевірка наявності нового (введеного) пароля у “стеку” даного користувача, – за умови наявності такого пароля у “стеку”, програма не дозволить його використання і запропонує придумати інший пароль, який раніше не використовувався;
    • Перевіряти складність пароля на відповідність мінімальним вимогам” – вкладена група полів (з чекером, що передує її назві), яка містить поля “Мінімальна довжина пароля … символів“, “Кількість ЗАГОЛОВНИХ символів“, “Кількість рядкових символів“, “Кількість спеціальних символів“, “Кількість цифр“, – всі перераховані поля є необов’язковими для заповнення та стають доступними для редагування за умови, що чекер, який передує назві групи “Перевіряти складність пароля на відповідність мінімальним вимогам” увімкнений.
    Поле “Мінімальна довжина пароля … символів“– діюча настройка системи, що перенесена з групи полів “Паролі” з деякими змінами функціональності, а саме: оскільки значення в даному полі не може бути меншим, ніж сума значень, що вказані в інших полях даної групи, тому воно автоматично змінюється (але виключно в більшу сторону) при зміні значень в цих полях (при цьому виконується перевірка, щоб максимальне значення, яке можливо вказати в даному полі, не перевищувало 15).
    Поля “Кількість ЗАГОЛОВНИХ символів“, “Кількість рядкових символів“, “Кількість спеціальних символів“, “Кількість цифр” визначають відповідні критерії перевірки пароля користувача при його зміні. Тобто за умови, що чекер, який передує назві групи “Перевіряти складність пароля на відповідність мінімальним вимогам” увімкнений, при зміні пароля любим із наведених вище способів, виконується перевірка складності введеного паролю на відповідність мінімальним вимогам, які визначаються значеннями полів групи “Перевіряти складність пароля на відповідність мінімальним вимогам“.
    У випадку виявлення такої невідповідності, користувач отримає попереджувальне повідомлення, в якому, зокрема, будуть перераховані критерії, яким має відповідати пароль.
    Примітка. Набір спеціальних символів, що мають бути використані при формуванні пароля, у відповідності до значення, вказаного в настройці “Кількість спеціальних символів“, визначається наступним переліком значень: “~“, “!“, “@“, “#“, “$“, “%“, “^“, “&“.
    Модуль “Бухоблік”
    1. К о н ф і г у р а ц і я “Х”. Додана можливість формування звіту “Відомість 8“, затвердженого наказом Мінфіну № 356 від 29 грудня 2000 р. Для цього в пункт головного меню “Звіти“/”Журнали (наказ Мінфіну №356)” додано підпункт “Відомість 8“, з якого буде викликатись додрукарська форма з наступними полями:
    • шейп “Формувати за період” з полями “з“..”по” – для вибору періоду, за який потрібно сформувати звіт;
    • шейп “Відбір по аналітичних рахунках” – при формуванні звіту для всіх налаштувань звіту буде застосовуватись значення аналітичних рахунків, вказаних в цьому шейпі. Якщо в налаштуваннях звіту для якогось рівня аналітики буде вказане значення, то для цього рівня аналітики цього налаштування значення аналітичних рахунків шейпа “Відбір по аналітичних рахунках” застосовуватись не будуть;
    • грід “Настройки розділу” – для настройки рядків, за якими буде виконуватись формування звіту.
    В пункт “Звіти“/” Журнали (наказ Мінфіну №356)“/”Відомість 8” додано шаблон звіту “Відомість 8” (jj8repUa.xlt).
    В “нульовій” та “демонстраційній” базі виконані настройки гріда “Настройки розділу.
    2. К о н ф і г у р а ц і я “Х”. В розділі “Звіти“/”Журнали (наказ Мінфіну №356)” внесено зміни в настройки розділів. Тепер, якщо в настройках верхнього рівня в полі “Рахунок” вказана маска рахунка, то у вкладених настройках при введені вручну значення в поле “Рахунок” буде записано тільки той рахунок, який відповідає масці рахунка та доступний для вибору зі словника.
    3. К о н ф і г у р а ц і я “Б”. У відповідності з наказом Мінфіну №938 від 23.08.2012 в розділ “Розпорядження” додано шаблони звітів “Додаток 24 до Порядку казначейського обслуговування місцевих бюджетів” (rasrepspecmestUa.xlt) та “Додаток 17 до Порядку казначейського обслуговування місцевих бюджетів” (rasrepzgfmestUa.xlt), друк яких виконується з пункту контекстного меню “Друк звіту“/”Розподіл виділених бюджетних асигнувань“.
    Також з розділу “Розпорядження” з пункту контекстного меню “Друк звіту“/”Розподіл виділених бюджетних асигнувань” видалено звіт “Додаток 21 до Порядку казначейського обслуговування місцевих бюджетів” (rasdod21Ua.xlt) як такий, що втратив актуальність.
    4К о н ф і г у р а ц і я “Б”. У зв’язку з оновленням структури електронного файлу виписки (dbf-файлу), який формується за допомогою ПТК “Клієнт казначейства–Казначейство“, внесені зміни до ini-файлу імпорту виписок в розділі “Журнал платежів” – відкоригований файл vb_kazna.ini.
    Примітка. Оскільки в розділі “Журнал платежів” реалізована можливість прив’язки банківського платежу до платіжного документа, завдяки якому цей платіж був створений, тому у вказаному вище ini-файлі, для застосування даної можливості, було додано, в якості параметра імпорту, чекер “Виконувати автоматичну прив’язку ПД” (включений за замовчуванням).
    Модуль”Зарплатня”
    1. Згідно листа НСЗУ, який надано керівникам КНП, які надають первинну медичну допомогу, відповідно до пункту 241 Типової форми договору про медичне обслуговування населення за програмою медичних гарантій, затвердженої постановою Кабінету Міністрів України від 05.04.2018 №410, до розділу “Звітні форми” доданий новий звіт “Форма 1-НС” (Statrep_forma1ns.xlt), для заповнення таблиць “7. Оплата праці та соціальне забезпечення” та “8. Кадри”.
    Для розрахунку таблиці “7. Оплата праці та соціальне забезпечення” використовуються масиви ключів, що починаються з “Зарпл.”, “Нарах.” та “Соц.заб.”. Для розрахунку таблиці “8. Кадри” використовуються масиви ключів, що починаються з “Штатн.пр.”, “Зовн.сум.”, “ЦПХ” та “Л/г”.
    Настройка ключів відбувається у розрізі значень поля “Склад” : “Керівники”, “Керівники структурних підрозділів”, “Лікарі”, “Середній медичний персонал”, “Молодший медичний персонал”, “Інші працівники”; у розрізі значень поля “Категорія особового рахунку” : “Штатний”, “Зовнішній сумісник”, “Договір ЦПХ”; у розрізі значень поля “Особлива позначка 5 (особ.рах)” : “23”, “91”, “92”, “94”. Для ключів, що починаються з “Штатн.пр.”, “Зовн.сум.”, “ЦПХ”, та закінчуються на “CO” передбачені додаткові умови відбору, наприклад, “RP_HIS(ANK.RN, Rp_Period(5, oRep.nYear1, oRep.nMonth1)+”-“+Rp_Period(5, oRep.nYear2, oRep.nMonth2), ” 60″) >0″.
    У діючі на підприємствах бази додати настройки у розділі “Настройка“/ “Заголовки” для нового шаблону “Форма 1-НС” можна за допомогою функцій контекстного меню “Експорт” та “Імпорт” з “нульової” або “демонстраційної” бази.
    Модуль “Фінанси”
    1. У відповідності з наказом Мінфіну №938 від 23.08.2012 в розділ “Розпорядження по фінансуванню” в пункт контекстного меню “Друк звіту“/”Розподіл виділених бюджетних асигнувань” додано шаблон звіту “Розпорядження про виділення коштів загального фонду місцевих бюджетів (Додаток 17) ” (rspmesbrepUa.xlt).
    Також внесено зміни в шаблон звіту “Розпорядження про виділення коштів спеціального фонду місцевих бюджетів (Додаток 24)” (rspmesrepUa.xlt), друк якого виконується з пункту контекстного меню “Друк звіту“/”Розподіл виділених бюджетних асигнувань“.