Доверенности

1.В модуле Docflow (Документооборот) в типе документа FormalizedPowerOfAttorney (Электронная доверенность) отмечены устаревшими серверные функции:

•CheckFormalizedPowerOfAttorneyState();

•SetRevokedState();

•GetValidationStateFromService();

•ProcessValidationResult();

•EnqueueValidation();

•UpdateValidationServiceStatus().

2.В модуле Docflow (Документооборот) отмечены устаревшими:

•серверная функция ProcessPowerOfAttorneyQueueItemResults();

•функция асинхронного обработчика HandleFPoARevocationSuccessRegistration().

3.В модуле PowerOfAttorneyCore (Электронная доверенность. Настройки) отмечены устаревшими серверные функции:

•CheckPowerOfAttorneyState();

•GetPowerOfAttorneyRevocationInfo();

•CreateEmptyValidationState();

•AddErrorToValidationState();

•EnqueuePoAValidation();

•GetPoAValidationState().

4.В модуле Docflow (Документооборот) в справочнике ApprovalRegistrationFtsStage (Этап регистрации электронной доверенности/заявления на отзыв в реестре ФНС) отмечены устаревшими серверные функции:

•GetValidationErrorRegistrationFts();

•GetSendingToFtsError();

•HasAnswerFromFts();

•GetFtsRegistrationError().

Передоверие и нотариальные эл. доверенности

1.В модуле Docflow (Документооборот) для типа документа FormalizedPowerOfAttorney (Электронная доверенность) добавлены новые свойства:

2.Для определение статуса доверенности в реестре ФНС теперь используется другое API Контур.Доверенностей (подробнее см. в документации Контур.API).

Доверенности на нескольких представителей

В модуле Docflow (Документооборот) в абстрактный документ PowerOfAttorneyBase (Базовая доверенность) добавлены свойства:

•IsManyRepresentatives – Несколько представителей;

•ManyRepresentativesPlaceholder – Кому выдана;

•Representatives – Представители.

Коллекция Representatives (Представители) состоит из элементов со следующими свойствами:

•AgentType – Тип представителя. Возможные значения: Person (Физическое лицо), Entrepreneur (Индивидуальный предприниматель) и LegalEntity (Юридическое лицо);

•IssuedTo – Кому выдана;

•Agent – Представитель.

Коллекция является основным источником данных о лицах, на имя которых оформляется доверенность.

Данные из прочих свойств доверенности, относящихся к представителю, теперь используются только для:

•программного заполнения коллекции Представители;

•работы с карточкой доверенности;

•автоматического формирования имени документа.

Особенности конвертации доверенностей

1.Для всех ранее созданных электронных доверенностей следующие свойства по умолчанию заполнены значениями:

•DelegationType (Возможность передоверия) – NoDelegation (Без права передоверия);

•IsDelegated (По передоверию) – False;

•IsNotarized (Нотариальная) – False.

2.Для всех ранее созданных электронных и бумажных доверенностей следующие свойства заполнены по умолчанию:

•IsManyRepresentatives (Несколько представителей) – False;

•Representatives (Представители) –значения из свойств AgentType (Тип представителя), IssuedToParty (Кому выдана) и Agent (Представитель).

Обмен с контрагентами

Новый формат УПД

1.Добавлены функции для парсинга УПД нового формата:

•ParseUniversalTransferDocument970() – парсинг УПД;

•ParseUniversalTransferRevision970() – парсинг исправления УПД.

2.Основание подписания со стороны контрагента заполняется в зависимости от способа подтверждения полномочий, указанного в титуле:

1 – «Должностные обязанности ({ФИО Подписанта})»;

2, 3, 4 – «Доверенность № {GUID} ({ФИО Подписанта})»;

5 – «Доверенность № {номер} ({ФИО Подписанта})»;

6 – «Иное ({ФИО Подписанта})».

3.В структуру TaxDocumentClassifier добавлено новое свойство TaxDocumentClassifierFormatVersion, которое хранит версию формата документа.

4.В сторонние библиотеки DCX добавлены:

•перечисление SignerPowersConfirmationMethod – способ подтверждения полномочий. Возможные значения: Duties, FormalizedPoA, PaperPoA, Other;

•свойства в FormalizedPoA:

ValidFrom (Дата совершения (выдачи) доверенности);

SystemId (ИД системы хранения);

SystemUrl (URL информационной системы, которая предоставляет техническую возможность получения информации о доверенности);

•класс PaperPowerOfAttorney (Бумажная доверенность) со свойствами: InternalNumber (Внутренний номер доверенности), ValidFrom (Дата совершения (выдачи) доверенности).

5.При генерации титулов покупателя и продавца способ подтверждения полномочий (СпосПодтПолном) подписывающего заполняется на основании его права подписи:

1 – для права подписи с типом основания «Должностные обязанности»;

3 – для права подписи с типом основания «Электронная доверенность»;

5 – для права подписи с типом основания «Доверенность»;

6 – для права подписи с типом основания «Другой документ».

Для способов подтверждения полномочий 3 и 5 заполняется информация о доверенности подписывающего.

6.В диалоговых окнах «Заполнение реквизитов покупателя» и «Заполнение реквизитов продавца» для УПД по приказу 970 убрано поле Полномочия и добавлено новое поле Доп. сведения. В нем заполняются дополнительные сведения о подписанте в титуле.

Изолированные области. Конвертация в PDF

Добавлена возможность конвертировать УПД по приказу 970 в формат PDF. Для этого в изолированной области DpadConverter модуля ExchangeCore (Электронный обмен. Настройки) добавлены функции:

Получение и создание документов эл. обмена

В серверном коде модуля Exchange (Электронный обмен) проведен рефакторинг функции получения или создания нового документа эл. обмена GetOrCreateNewExchangeDocument():

1.Создание формализованного или неформализованного документа вынесено в отдельные функции:

•CreateFormalizedExchangeDocument();

•CreateNonformalizedExchangeDocument().

2.Проверки соответствия формализованного документа одному из типов вынесены в функции:

•IsTaxInvoice() – счет-фактура;

•IsTaxInvoiceCorrection() – корректировочный счет-фактура;

•IsUniversalTransferDocumentWithoutSchfFunction() – УПД без функции СЧФ;

•IsUniversalTransferDocumentWithSchfFunction() – УПД с функцией СЧФ;

•IsUniversalTransferDocumentWithDopFunction() – УПД с функцией ДОП;

•IsUniversalTransferDocumentWithSchfDopFunction() – УПД с функцией СЧФДОП.

3.Добавлены функции, возвращающие список типов документов, соответствующих УПД с функциями:

•GetUniversalDocumentSchfTypes() – СЧФ (счет-фактура);

•GetUniversalDocumentDopTypes() – ДОП (первичный документ);

•GetUniversalDocumentSchfDopTypes() – СЧФДОП (универсальный передаточный документ).

4.Создание каждого типа формализованного документа вынесено в функции:

•CreateWaybillDocument() – накладная;

•CreateTaxInvoice() – счет-фактура;

•CreateContractStatementDocument() – акт;

•CreateUniversalTransferDocument() – УПД;

•CreateWorksTransferDocument() – ДПРР;

•CreateGoodsTransferDocument() – ДПТ.

5.Заполнение полей полученного после создание формализованного или неформализованного документа вынесено в функцию FillNewExchangeDocumentProperties().

6.Заполнение полей финансовых документов вынесено в функцию FillNewAccountingExchangeDocumentProperties().

7.Заполнение полей информации о документе эл. обмена в функцию FillNewExchangeDocumentInfoProperties().

8.Выделена функция для формирования имени документа на основании названия файла GenerateDocumentNameFromFileName().

9.Выделена функция для получения комментария из документа GetExchangeDocumentComment().

10.Типы документов, соответствующих УПД с функцией СЧФДОП, ДОП и СЧФ, получаются из функций:

•GetUniversalDocumentSchfDopTypes() – с функцией СЧФДОП;

•GetUniversalDocumentDopTypes() – с функцией ДОП;

•GetUniversalDocumentSchfTypes() – с функцией СЧФ.

11.Серверная функция модуля Exchange (Электронный обмен) CreateWaybillDocument() переименована в CreateGoodsTransferDocument().

12.Серверная функция модуля Exchange (Электронный обмен) CreateContractStatementDocument() переименована в CreateWorksTransferDocument().

13.Для функций CreateWaybillDocument() и CreateContractStatementDocument() созданы перегрузки с меньшим количеством параметров.

14.Сделаны публичными и виртуальными серверные функции:

•GetOrCreateExchangeInfoWithoutDocument();

•CreateTaxInvoice();

•CreateWaybillDocument();

•CreateContractStatementDocument();

•CreateUniversalTransferDocument();

•CreateExchangeDocumentVersion();

•GetTaxDocumentClassifier();

•SetDocumentTotalAmount().

15.Серверная функция GetInfoFromXML() модуля Exchange (Электронный обмен) разделена на следующие функции:

16.Функция для генерации титула покупателя разбита на более мелкие публичные виртуальные функции:

17.В модуле Exchange (Электронный обмен) серверная функция MarkDocumentAsSended() отмечена устаревшей и разделена на функции:

18.В модуле Exchange (Электронный обмен) добавлена виртуальная серверная функция CreateExchangeDocument() для создания документов эл. обмена различных типов.

19.В модуле FinancialArchive (Финансовые документы) серверная функция для генерации титула продавца GenerateSellerTitle() разделена на функции:

•публичная виртуальная функция CreateSellerSignatoryInfo() – создание структуры для формирования титула продавца;

•публичная статическая функция AddSellerTitleToDocumentVersion() – добавление информации из структуры титула продавца в версию документа.

20.В модуле Docflow (Документооборот) клиентская виртуальная функция – ApproveWithAddenda() разделена на функции:

•публичная статическая ApproveOrEndorseDocument() – утверждение документа или его согласование, если при утверждении возникла ошибка;

•публичная статическая функция ApproveOrEndorseAddenda() – утверждение приложений или их согласование, если при утверждении возникла ошибка;

•публичная виртуальная функция GenerateFormalizedDocumentDefaultTitles() – генерация титулов продавца и покупателя по умолчанию для формализованных документов.

Преобразование в PDF со сведениями о регистрации

1.Теперь метаинформация отметок из справочника Mark (Отметки) сохраняется при их формировании. Изменения коснулись существующих отметок об ЭП и отметки о поступлении. Новая логика используется при добавлении отметок о регистрации.

2.Устаревшая реализация преобразования в PDF оставлена для совместимости. Ее можно включить с помощью параметра UseObsoletePdfConversion в таблице Sungero_Docflow_Params. Значение параметра по умолчанию – False.

В устаревшей реализации не используются отметки о регистрации. Также она не поддерживает новые виды отметок, которые могут добавиться в следующих версиях и обновлениях. Для использования новых возможностей необходимо адаптировать логику перекрытий.

3.В модуле Docflow (Документооборот):

•добавлен тип справочника MarkKind (Вид отметки). Он предназначен для настройки стандартных видов отметок и создания новых без перекрытия или наследования.

•добавлена серверная функция ConvertToPdfWithMarks(), которая отвечает за преобразование документа в формат PDF c отметками.

•в тип документа OfficialDocument (Официальный документ) добавлены серверные функции:

ConvertToPdfWithMark() – преобразовывает документ в PDF с отметками. Функцию можно перекрыть, чтобы изменить добавление отметок для определенного типа документа.

GetBodyToConvertToPdfWithMarks() – получает содержимое документа для преобразования в PDF. Для наследников от абстрактного документа IncomingDocumentBase (Входящий документ) получает содержимое свойства PublicBody (Отображаемое представление для версии документа).

WriteConvertedBodyToVersion() – записывает результат преобразования в версию документа. Для наследников от абстрактного документа IncomingDocumentBase (Входящий документ) записывает результат в свойство PublicBody (Отображаемое представление для версии документа).

•серверная функция LogPdfConverting() отмечена устаревшей. Вместо нее рекомендуется использовать функцию LogPdfConversion(), добавленную в тип документа OfficialDocument (Официальный документ).

•в типе документа OfficialDocument (Официальный документ) отмечены устаревшими серверные функции:

•в изолированной области PdfConverter отмечены устаревшим следующие функции:

4.В модуле DocflowApproval (Документооборот. Движение документов) для блока ConvertPdfBlock (Преобразование в PDF) отмечены устаревшими серверные функции:

Обучение виртуального помощника на исторических данных

1.В стандартный плагин SmartProcessing утилиты RxCmd добавлены команды:

•train-ai-assistants, которая подготавливает данные для обучения классификаторов виртуальных помощников;

•stop-ai-assistant-train-data-preparing, которая сбрасывает дату начала обучения виртуального ассистента. При этом очищается значение параметра startDate. Команда используется, чтобы прекратить подготовку данных для обучения виртуального помощника.

2.В свойство-коллекцию Classifiers (Классификаторы) типа справочника AIManagersAssistant (Виртуальный помощник) добавлено свойство TrainingStartDate – дата начала отбора поручений для обучения виртуального помощника.

Указание вида носителя документа

В модуль Docflow (Документооборот) добавлены:

1.Тип справочника MediumType (Вид носителя документа) со свойствами:

2.Необязательное свойство Medium (Вид носителя) в тип документа OfficialDocument (Официальный документ) и в тип справочника CaseFile (Дело).

3.Необязательное свойство DefaultMedium (Вид носителя по умолчанию) в тип справочника DocumentKind (Вид документа).

Код категории договора

В модуль Contracts (Договорные документы) в тип справочника ContractCategory (Категории договоров) добавлено необязательное свойство Code (Код).

В модуле Docflow (Документооборот):

1.В тип справочника DocumentRegister (Журнал регистрации) в свойство-коллекцию NumberFormatItems (Формат номера) в перечисление Element (Элемент) добавлено значение CategoryCode (Категория договора (код)).

2.Оптимизировано получение регистрационного номера, для этого в типе справочника DocumentRegister (Журнал регистрации) отмечены устаревшими функции:

•GenerateRegistrationNumber();

•GetNextIndex();

•GetNextNumber();

•IsRegistrationNumberUnique();

•CheckRegistrationNumberFormat();

•GenerateRegistrationNumberFromDialog();

•GetIndexFromRegistrationNumber();

•IsEqualsRegistrationNumbers();

•ParseRegistrationNumber();

•GenerateRegistrationNumberPrefixAndPostfix().

Вместо них рекомендуется использовать их перегрузки с меньшим числом параметров.

Если перекрыта логика получения рег. номера и нет возможности адаптировать программный код под изменения, включите режим совместимости. Для этого в таблице базы данных Sungero_Docflow_Params в параметре UseObsoleteRegNumberGeneration установите значение True. Он используется в функциях:

•RunRegistrationDialog();

•IsRegistrationNumberUnique();

•GetRegistrationDialogParams();

•GetIndexFromRegistrationNumber();

•ValidateRegNumberUniqueness();

•GenerateRegistrationPrefixAndPostfix();

•GenerateRegistrationNumber();

•CheckRegistrationNumberFormat();

•NumberDocument();

•GetValueExample();

•GetRegexMatchFromRegistrationNumber().

Также параметр используется в событии До сохранения (в транзакции) типа документа OfficialDocument (Официальный документ).

Необходимо включить режим совместимости, если перекрыты функции:

•GenerateRegistrationNumber();

•GetNextIndex();

•GetNextNumber();

•IsRegistrationNumberUnique();

•CheckRegistrationNumberFormat();

•GenerateRegistrationNumberFromDialog();

•GenerateRegistrationNumberPrefixAndPostfix().

В режиме совместимости не поддерживается новый формат рег. номера с кодом категории договора. Он предназначен для постепенного перехода на новый API по получению рег. номера.

Для удобства работы с перекрытиями оптимизировано получение настроек регистрации. В типе справочника RegistrationSetting (Настройка регистрации) отмечены устаревшими функции:

При добавлении нового критерия в настройки регистрации перекройте виртуальные функции:

•GetAvailableRegistrationSettings() в серверных функциях модуля Docflow (Документооборот);

•GetDocumentRegisters() в серверных функциях типа справочника DocumentRegister (Журнал регистрации);

•GetAvailableSettingsByParams() в разделяемых функциях типа справочника RegistrationSetting (Настройка регистрации).

ВАЖНО. Добавленные критерии не учитываются в отчете «Настройка регистрации и нумерации документов» и при синхронизации с 1С. Их необходимо настроить отдельно.

Ответ на несколько писем

1.В типы документов IncomingDocumentBase (Входящий документ) и OutgoingDocumentBase (Исходящий документ) добавлены свойства:

•IsManyResponses (На несколько исходящих);

•InResponseToDocuments (В ответ на).

2.Для всех входящих писем:

•свойство IsManyResponses (На несколько исходящих) по умолчанию заполнено значением False;

•значение из свойства InResponseTo (В ответ на) копируется в свойство-коллекцию InResponseToDocuments (В ответ на).

3.Для всех исходящих писем:

•свойство IsManyResponses (На несколько входящих) по умолчанию заполнено значением False;

•значение из свойства InResponseTo (В ответ на) копируется в коллекцию InResponseToDocuments (В ответ на).

4.Для типа связи Response (Ответное письмо) очищен столбец Заполнить свойства на вкладке Параметры. Связь указывается программно в событии До удаления (BeforeSave).

Прекращение поддержки сервера приложений

В действиях и диалогах удалены избыточные проверки на тип клиентского приложения (ClientApplication.ApplicationType).

Библиотека DpadCP.Converter

Из модуля ExchangeCore (Электронный обмен. Настройки) удалена библиотека DpadCP.Converter, вместо нее добавлены новые библиотеки:

•NpoComputer.DpadCP.Core – ядро DPADCP (общие методы, для всех типов документов, простановка штампов);

•NpoComputer.DpadCP.Standard – поддерживаемые типы документов, которые ранее были в DPAD.Converter:

•универсальный передаточный документ по приказу 820 (УПД 820);

•документ о передаче товаров (ДПТ)/Документ о передаче результатов работ (ДПРР);

•счет-фактура (СФ);

•универсальный корректировочный документ (УКД);

•и пр.

•NpoComputer.DpadCP.InvoiceForPayments – счета на оплату;

•NpoComputer.DpadCP.GeneralTransfer970 – УПД по приказу 970.

Прочее

1.Функции для построения контрола состояния локализованы на русский язык. При настройке представления форм отображается локализованное название и описание функции.

2.В свойстве LeadingDocument (Договор) типа документа SupAgreement (Дополнительное соглашение) тип сущности изменен на ContractualDocument (Договорной документ).

3.Изменены параметры типа связи в типе документа SupAgreement (Дополнительное соглашение). В качестве источника теперь можно указывать любые договорные документы.

4.В сущности Addendum (Приложение к документу) отмечена устаревшей серверная функция RestoreAddendumRelationToLeadingDocument(), которая восстанавливает связь приложения с ведущим документом. Теперь связь удаляется при сохранении карточки приложения.

5.В серверном коде модуля Docflow (Документооборот) выделен регион для работы с расширением файлов. В него перенесены:

•функция GetOrCreateAssociatedApplicationByDocumentName() из серверного кода модуля Exchange (Электронный обмен);

•функция CreateAssociatedApp() из функций инициализации модуля Docflow (Документооборот). Функция переименована в CreateAssociatedApplication().

6.В модуле Exchange (Электронный обмен) перегрузка серверной функции GetOrCreateNewExchangeDocument() модуля больше не вызывает саму себя. Теперь в функции вызывается перегрузка с большим количеством параметров.

© Компания Directum, 2024