alexander-lubich
Александр Любич

Большой труд. благодарю Вас Михаил.

(14)

да, поддерживаю.

если объективный обзор-сравнение,
разумеется без маркетинговой ангажированности от нашего основного на этом ресурсе вендора.
обещает быть весьма интересным материалом.

(1) ничем, по моей практике -статьи отсюда легче находятся поисковиком, но тут далеко не все не все и часто не так раскрыто.

на ИТС доступ есть не у всех для чтения статей и документации, может я

что по статье - "партнеры" это очень хороший механизм. я помню по крайней мере лет 10 назад была такая практика что бы избегать нежелательно избыточного внимания со стороны регулирующих органов требовалось деятельность общества поддерживать до двух лет с момента регистрации и до какого то объема оборота. ну и контрагенты исправно переобувались в новые юрлица что требовалось автоматизировать для целей взаиморасчетов и УУ.

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

Где это применять?

очень интересно состояние данной темы в 22 году

(3) Добрый день! как Вы делали?

разворачивали свой ГИС - сервер ?
реализовывали задачу офлайнового хранения карт?

QGIS штука клиент-серверная ... те требуется
а) развернуть сервер этого добра
б) обращаться к серверу из 1с (кроме 1с как я понимаю там есть еще свои нативные клиенты)

Добрый день!
поделитесь опытом плз. - какие методики Вы используете в своей практике с внешними подрядчиками и во внутреннем учете трудозатрат.

формализовал две крайности :

Классическое ценообразование – (минимум час – максимум – столько сколько на рынке стоит) - риски заказчика переплатить минимальны , но есть риски исполнителя встрять с задачей к которой он не совсем готов, на дольше чем предполагает оценка.

Астрономическое ценообразование– (минимум час –фактическое время) – у исполнителя рисков нет, все время будет оплачено, но у заказчика есть риски завышенного ценообразования например от задачи к которой исполнитель не был готов и получилось дольше ее решать.

Оба случая вполне могут работать «на глаз» с некоторым кредитом доверия так и скурпулезно считая минуты, проверяя «присутствие» специалиста в задаче.

Первый случай исключает риск переплаты заказчиком , все договоренности вносятся на этапе согласования, и далее не надо ни контролировать время фактического исполнения до часа, не заботиться о достаточной квалификации исполнителя переживая – не слишком ли он долго делает, лишь бы в общие согласованные рамки исполнения уложился, пусть найдет субподряд, или изучит чего то… это не заботы Заказчика. Например сделать Печатную форму за 5 часов. это будет стоить 5 часов даже если исполнитель это будет делать пол месяца и это допустимо.

Второй случай предполагает постояный контроль и постоянно ожидается линейное состояние квалификации по отношению к задаче – в процессе ли решения исполнитель сейчас?, а не слишком ли он долго делает задачу? Тут есть риск впасть в микроменеджмент .

Оба метода предполагают контроль- в первом случае сдельшина определенная рынком, но рынок может врать - продажники будут занижать стоимость лишь бы «залезть» в проект/работу и сбить цену. нужно вносить разумную корректировку или придумать коэффициент "риска".
те это досогласование стоимости.

Второй –периодически надо падать до микроменеджмента типа «фотографии рабочего дня» , что в целом штука весьма некомфортная ни исполнителю ни контролирующему. С декомпозицией задач и методов поиска решения, С вопросами – а почему Вы вот это делали так долго? тут Вы слишком долго курили, тут долго гуглили и тд и тп.

(6) Дмитрий , интересно Ваше мнение по вопросу "Когда заканчивается Enterprise Data и начинается RabbitMQ ?"

http://forum.infostart.ru/forum15/topic284494/message2848287/#message284828

парни из 1с мне ответили
- Пропускная способность ED ими не тестирована .
- достоинство шины - сама определяет получателя и доставку сообщение ему те задача источника только выплюнуть сообщение в шину и тут резко снижается риск блокировок таблиц изменений. потому что узел обмена у центральной базы будет только один - шина.

да книжка классная , сейчас читаю.

Прикрепленные файлы:

PROGRAMMING_Shablony_integratsii_korporativnykh_prilozhenii_774.pdf

(23) Дмитрий , интересно Ваше мнение по вопросу "Когда заканчивается Enterprise Data и начинается RabbitMQ ?"

http://forum.infostart.ru/forum15/topic284494/message2848287/#message284828

парни из 1с мне ответили
-Пропускная способность ED ими не тестирована .
- достоинство шины - сама определяет получателя и доставку сообщение ему те задача источника только выплюнуть сообщение в шину и тут резко снижается риск блокировок таблиц изменений. потому что узел обмена у центральной базы будет только один - шина.

да книжка классная , сейчас читаю.

Прикрепленные файлы:

PROGRAMMING_Shablony_integratsii_korporativnykh_prilozhenii_774.pdf