а междумордие с выбором нужного из обслуживаемых по отсканированному счетов нарисовать — это, наверное, задача по-твоему нерешаемая?..
как по мне так даже удобнее будет — приложился — сразу увидел счета доступные в данном банкомате, выбрал счет — поехало дальше по нему стандартное меню…
«подкараулить у банкомата» etc. — универсальная и совершенно одинаково нейтрализуемая (и организационно, и по стоимости) опасность для любого способа идентификации при съеме денег со счета (и даже выемки денег из собственного кармана, например).
тут же, как мне кажется, речь о том, чтобы иные (не универсальные) недочеты исключить.
прим.: про отрезку пальцев: не думаю, сканер будет настолько туп, чтобы не отличать здоровый и живой палец от дохлятины…
ну по такой логике любого ограбленного или обманутого мошенниками (например) можно радостно назвать «зомбированным».
а отсутсвтие «ящика» в доме от зомбирования далеко не вседа предохраняет (в Вашем случае, судя по всему, не предохраняет совершенно наверняка). причем причины такого явления прозрачны и понятны любому человеку, у которого логика не парализована зомбированием. Вы не в безвоздушном пространстве живете,
манипулирование информационными потоками в пределах относительно замкнутой социальной группы приносит плоды в том числе даже в случае самоизоляции от этих информационных потоков. проще говоря — ты же в социуме живешь, неизбежно общаясь со знакомыми (случайными и не очень), друзьями… и прекрасно получаешь нужный информационный посыл опосредованно — причем — сюрпраайс! — подобные процессы порой бывают даже более эффективными в части составления «нужного» мнения — ибо в общении ты получаешь информацию в более адаптированном (к своей специфике составления мнения) виде.
так что бравирование «отсутствием ящика» в подобных дискуссиях — скорее проигрышный аргумент, выдающий разве что неумность на фоне неистового желания хоть как-то доказать свою правоту в благостном согласии с официальными иделогическими постулатами.
Скажите пожалуйста, появилась ли возможность «включения» инкрементной копии в «родную цепочку»?..
Вопрос касается случая, когда из инкрементного архива дисков выполняется восстановление системного раздела (на котором расположен и сам ATI) — при этом Акронис вполне естественно «забывает» об архивациях, выполненных после того момента, на который был выполнен бэкап, из которого выполнено восстановление. при этом в списке архивов дисковый архив «разваливается» на два, в одном из которых пропадает кнопка «архивировать», а в другом неизвестнв схема архивирования. и «забытый» архив «болтается» с какими-то кривыми параметрами. причем ситуация не исправляется проверкой архива — хотя, по логике, должна бы.
Смысл есть, только он есть следствие некоторой, кхм, нечистоплотности фирмы Акронис.
При выпуске каждой новой версии фирма Акронис полностью сворачивает работы по исправлению ошибок в старших версиях.
Термин же «нечистоплотность» появляется когда к этому факту добавляется то, что фирма Акронис новые версии не предоставляет зарегистрированным пользователям старших версий, но в дополнение к отказу исправления ошибок в старших версиях — и продолжая исправлять только в новых версиях ошибки, выявленные в старших версиях — фактически принуждает пользователей старших версий покупать новые версии.
отнюдь.
у терморектального анализа есть один существенный недостаток, с которым согласны даже сами терморектоанализаторы. и который сводит на нет ползу такового анализа, ибо касается ненадежности таким образом полученных данных.
а у именно такого содержания логов вполне себе возможна и иная причина (спасибо вайфай-роутеру) причина, нежели злой умысел человека, не дающего для подозрений иного повода помимо этих самых логов.
прим.: кстати, «скрытый том» в трукрипт-контейнере тоже именно для энтузязистов подобного анализа придуман… )))
а вигруалку — в скрытый том трукрипт-контейнера (в открытом обычную порнуху), и по кускам распихать в облака.
надо попараноить — собираем из облака на рам-драйв виртуалку, запускаем-параноим… звонок в дверь — выключаем комп и алё…
логи?.. какие логи?.. да понятия не имею кого вы имеете ввиду…
(уффф, чота я разошёлся)
а я как лох на аутпосте сижу.
после того, как опробовал все вышеприведенные.
(уселся с попкорном и колой на скамеечку в ожидании обмена мнениями о выбранных критериях сравнения программ именно этой категории и именно в таком наборе)
Похоже на идиосинкразию. Давайте ппробуем ещё раз, по слогам.
1) основной поток ввода — выписка и оперативное проведение документов, расходующих товары — безусловно необходим конроль отрицательных остатков при проведении, поскольку оформляемые документы являются основанием для выполнения отгрузки.
2) не(!)основной поток ввода — редактирование и ввод документов «задним числом» — по факту уже выполненной отгрузки товаров. ЕСЛИ контролировать остатки и запрещать проведение при недостаче на учетных остатках какой-то (одной) позиции — патологию ведь не рассматриваем, верно? — получится, что по всем остальным позициям остатки, на основании которых выполняется оперативный ввод данных (см.п.1) станут (останутся) неверными — что приведет к ещё большему практическому(!) ущербу, нежели ты так живенько описывал.
3) не(!)основной ввод данных — «задним числом» — является как-бы-мини-фор-мажором, и для проверки корректности внесенных изменений «задним числом» требуется не такой же контроль, как при оперативном вводе — подокументный контроль от текущего до последнего. причем по результатам такого контроля (и с целью приведения оперативных остатков в актуальное состояние) требуются немного совершенно не такие действия, как при оперативном (просто не проводить такие документы — не подходит, поскольку ошибка в актуальных остатках при тупо непроведенном таком документе — существенно больше, чем при проведенном даже в минус).
т.о. более оптимальным, нежели непроведение при нехватке остатков для документов, корректируемых «задним числом» (напомню — по факту отгрузки!) будет безусловное из проведение с включением в список документов для последующего регламентного контроля корректности их оформления.
и — ещё раз, по слогам: непроведение документов, которые вводятся или корректируются «задним числом» ведет к гораздо большей неактуальности оперативных остатков (используемых для контроля при оперативном вводе), нежели их безусловное проведение. точка.
Бить по рукам — основания нужны. какая буква в «при отдельном регламенте по-документного контроля остатков в случае выявления(регистрации) фактов корректировки документов «задним числом».» тебе непонятна?..
О том, чтобы добавлять только оперативно — я и не заикался. по кругу бегать — тоже желания мало, на «почему-то» отвечено вполне по-русски выше.
«с другим оператором разбираются» — весьма вредно для процесса (точнее — для целевой функции), а также для морального климата — не говоря уж о том, что «другого» сначала найти надо, и «кто первый начал» — вопрос в подобных конфликтах слабо решаемый. а уж о том, чтобы вменять менеджеру-продажнику в обязанности «с другими операторами разбираться» — и говорить, простите, смешно.
Чо значит «каким образом»?.. если он (пи дефолтном оперативном режиме создания новых документов) может ввести информацию «задним числом» (откорректировать дату документа, например) — значит имеет возможность изменять позицию документа. нет, спасёт. при отдельном регламенте по-документного контроля остатков в случае выявления(регистрации) фактов корректировки документов «задним числом».
Да вот нихрена это не его проблема. Потому что он кристально честно вводит факт. а уход в минус происходит по причине корректировок, внесенных другим оператором. Если ты этого не понимаешь — то мне остается только руками развести и свернуть диалог, уж извини.
мнда… ну не поняли и не поняли, не трагедия.
можете также не понять следующие факты, также почерпнутые из практики
при указанном вами «не вижу смысла»: все-таки включенный контроль остатков в виде «кальки» с оперативного — на практике очень часто выливается в «номенклатурные войны» менеджеров — в случае непроведения по причине нехватки остатка менеджер спокойно «задвигает» свой документ перед уже проведенным документом, расходующим «дефицитную» номенклатурную позицию (ну, мотивация у продажников такая — так или иначе зависит от объемов продаж. такая бедулька))).
и следующий, в принципе довольно простой факт: отказ проведения документа в связи с нехваткой учетных остатков по одной из позиции — по сути ведёт к искажению актуальных остатков (точнее — к сохранению их неактуальности), причем логика оператора в таком случае проста и логична (в рамках его штатных обязанностей и мотивации) — «я ввожу то, что уже было отгружено фактически. а то, что ваша программа не дает это ввести — не моя проблема, а проблема программы».
и — «сервер с запасом» — это, простите, фантастика. не в том смысле, что такие сервера, а в том смысле, что такая 1с-ина.
но, повторюсь, можете спокойно и дальше «не понимать» — не трагедия ни полраза. обеспечите работой других одинэснитов — только и делов. )))
а давайте Вы сами попробуете сравнить:
1) оперативный ввод документа, расходующего товары, будет служить основанием для отгрузки со склада;
2) неоперативный ввод документов «задним числом» — вводится по результатам фактически выполненной отгрузки товаров со склада.
Разницу, касающуюся необходимсти контроля остатков — заметили?
Двлее. По п.2 возможны разночтения — для того, чтобы не допустить элементарных ошибок (пересорта, например) в исполнении оператора, возможно, и следует выполнять контроль остатков. НО. Это — уже другой пункт регламента, другая операция (в отличие от оперативного ввода), совмещение которой с проведением документа (при том, что это может привести к существенному замедлению основного потока ввода документов) — вряд ли разумно.
Особенно если учесть тот факт, что контроль при проведении «задним числом» должен быть несколько иным, нежели автор нарисовал, НЕ «калькой» с контроля при оперативном проведении. Контроль при неоперативном проведении должен контролировать остатки не только на хронологическую позицию проводимого документа, но и на хронологические моменты всех(!!!) «следующих» доккументов. Что ещё более замедлит работу.
как-то так.
Ваша фамилия, случайно, не Осипов?.. «усовершенствование» как раз в его «гениальном» стиле.
Кстати, ещё штришок относительно последствий Вашего «усовершенствования».
Анализ остатка на хронологический момент документа (с запретом проведения если не хватит — или даже просто с помещением такого документа и его автора в категорию «подозрительных») — источник «номенклатурных войн продажников». Ибо позволяет «задвинув» свой документ перед расходующим то же самое — «перехватить» продажу заканчивающихся товаров. Тот самый хрестоматийный случай «лишней информации».
гнилая отмазка.
гугль является владельцем сайта в сети “Интернет”, содержащего запрещенную информацию (в кэше).
или они гугль разбанили, а кєш евонній — забанили?.. тооонко.
ну и как, предсказания и надежды оправдались? если нет — что помешало?
necroposter mode off
как по мне так даже удобнее будет — приложился — сразу увидел счета доступные в данном банкомате, выбрал счет — поехало дальше по нему стандартное меню…
тут же, как мне кажется, речь о том, чтобы иные (не универсальные) недочеты исключить.
прим.: про отрезку пальцев: не думаю, сканер будет настолько туп, чтобы не отличать здоровый и живой палец от дохлятины…
а отсутсвтие «ящика» в доме от зомбирования далеко не вседа предохраняет (в Вашем случае, судя по всему, не предохраняет совершенно наверняка). причем причины такого явления прозрачны и понятны любому человеку, у которого логика не парализована зомбированием. Вы не в безвоздушном пространстве живете,
манипулирование информационными потоками в пределах относительно замкнутой социальной группы приносит плоды в том числе даже в случае самоизоляции от этих информационных потоков. проще говоря — ты же в социуме живешь, неизбежно общаясь со знакомыми (случайными и не очень), друзьями… и прекрасно получаешь нужный информационный посыл опосредованно — причем — сюрпраайс! — подобные процессы порой бывают даже более эффективными в части составления «нужного» мнения — ибо в общении ты получаешь информацию в более адаптированном (к своей специфике составления мнения) виде.
так что бравирование «отсутствием ящика» в подобных дискуссиях — скорее проигрышный аргумент, выдающий разве что неумность на фоне неистового желания хоть как-то доказать свою правоту в благостном согласии с официальными иделогическими постулатами.
и этта… osi сосёт… нет, не так даже — а вот: сасёт. причем капсом.
Вопрос касается случая, когда из инкрементного архива дисков выполняется восстановление системного раздела (на котором расположен и сам ATI) — при этом Акронис вполне естественно «забывает» об архивациях, выполненных после того момента, на который был выполнен бэкап, из которого выполнено восстановление. при этом в списке архивов дисковый архив «разваливается» на два, в одном из которых пропадает кнопка «архивировать», а в другом неизвестнв схема архивирования. и «забытый» архив «болтается» с какими-то кривыми параметрами. причем ситуация не исправляется проверкой архива — хотя, по логике, должна бы.
При выпуске каждой новой версии фирма Акронис полностью сворачивает работы по исправлению ошибок в старших версиях.
Термин же «нечистоплотность» появляется когда к этому факту добавляется то, что фирма Акронис новые версии не предоставляет зарегистрированным пользователям старших версий, но в дополнение к отказу исправления ошибок в старших версиях — и продолжая исправлять только в новых версиях ошибки, выявленные в старших версиях — фактически принуждает пользователей старших версий покупать новые версии.
у терморектального анализа есть один существенный недостаток, с которым согласны даже сами терморектоанализаторы. и который сводит на нет ползу такового анализа, ибо касается ненадежности таким образом полученных данных.
а у именно такого содержания логов вполне себе возможна и иная причина (спасибо вайфай-роутеру) причина, нежели злой умысел человека, не дающего для подозрений иного повода помимо этих самых логов.
прим.: кстати, «скрытый том» в трукрипт-контейнере тоже именно для энтузязистов подобного анализа придуман… )))
надо попараноить — собираем из облака на рам-драйв виртуалку, запускаем-параноим… звонок в дверь — выключаем комп и алё…
логи?.. какие логи?.. да понятия не имею кого вы имеете ввиду…
(уффф, чота я разошёлся)
после того, как опробовал все вышеприведенные.
(уселся с попкорном и колой на скамеечку в ожидании обмена мнениями о выбранных критериях сравнения программ именно этой категории и именно в таком наборе)
1) основной поток ввода — выписка и оперативное проведение документов, расходующих товары — безусловно необходим конроль отрицательных остатков при проведении, поскольку оформляемые документы являются основанием для выполнения отгрузки.
2) не(!)основной поток ввода — редактирование и ввод документов «задним числом» — по факту уже выполненной отгрузки товаров. ЕСЛИ контролировать остатки и запрещать проведение при недостаче на учетных остатках какой-то (одной) позиции — патологию ведь не рассматриваем, верно? — получится, что по всем остальным позициям остатки, на основании которых выполняется оперативный ввод данных (см.п.1) станут (останутся) неверными — что приведет к ещё большему практическому(!) ущербу, нежели ты так живенько описывал.
3) не(!)основной ввод данных — «задним числом» — является как-бы-мини-фор-мажором, и для проверки корректности внесенных изменений «задним числом» требуется не такой же контроль, как при оперативном вводе — подокументный контроль от текущего до последнего. причем по результатам такого контроля (и с целью приведения оперативных остатков в актуальное состояние) требуются немного совершенно не такие действия, как при оперативном (просто не проводить такие документы — не подходит, поскольку ошибка в актуальных остатках при тупо непроведенном таком документе — существенно больше, чем при проведенном даже в минус).
т.о. более оптимальным, нежели непроведение при нехватке остатков для документов, корректируемых «задним числом» (напомню — по факту отгрузки!) будет безусловное из проведение с включением в список документов для последующего регламентного контроля корректности их оформления.
и — ещё раз, по слогам: непроведение документов, которые вводятся или корректируются «задним числом» ведет к гораздо большей неактуальности оперативных остатков (используемых для контроля при оперативном вводе), нежели их безусловное проведение. точка.
О том, чтобы добавлять только оперативно — я и не заикался. по кругу бегать — тоже желания мало, на «почему-то» отвечено вполне по-русски выше.
«с другим оператором разбираются» — весьма вредно для процесса (точнее — для целевой функции), а также для морального климата — не говоря уж о том, что «другого» сначала найти надо, и «кто первый начал» — вопрос в подобных конфликтах слабо решаемый. а уж о том, чтобы вменять менеджеру-продажнику в обязанности «с другими операторами разбираться» — и говорить, простите, смешно.
Да вот нихрена это не его проблема. Потому что он кристально честно вводит факт. а уход в минус происходит по причине корректировок, внесенных другим оператором. Если ты этого не понимаешь — то мне остается только руками развести и свернуть диалог, уж извини.
можете также не понять следующие факты, также почерпнутые из практики
при указанном вами «не вижу смысла»: все-таки включенный контроль остатков в виде «кальки» с оперативного — на практике очень часто выливается в «номенклатурные войны» менеджеров — в случае непроведения по причине нехватки остатка менеджер спокойно «задвигает» свой документ перед уже проведенным документом, расходующим «дефицитную» номенклатурную позицию (ну, мотивация у продажников такая — так или иначе зависит от объемов продаж. такая бедулька))).
и следующий, в принципе довольно простой факт: отказ проведения документа в связи с нехваткой учетных остатков по одной из позиции — по сути ведёт к искажению актуальных остатков (точнее — к сохранению их неактуальности), причем логика оператора в таком случае проста и логична (в рамках его штатных обязанностей и мотивации) — «я ввожу то, что уже было отгружено фактически. а то, что ваша программа не дает это ввести — не моя проблема, а проблема программы».
и — «сервер с запасом» — это, простите, фантастика. не в том смысле, что такие сервера, а в том смысле, что такая 1с-ина.
но, повторюсь, можете спокойно и дальше «не понимать» — не трагедия ни полраза. обеспечите работой других одинэснитов — только и делов. )))
1) оперативный ввод документа, расходующего товары, будет служить основанием для отгрузки со склада;
2) неоперативный ввод документов «задним числом» — вводится по результатам фактически выполненной отгрузки товаров со склада.
Разницу, касающуюся необходимсти контроля остатков — заметили?
Двлее. По п.2 возможны разночтения — для того, чтобы не допустить элементарных ошибок (пересорта, например) в исполнении оператора, возможно, и следует выполнять контроль остатков. НО. Это — уже другой пункт регламента, другая операция (в отличие от оперативного ввода), совмещение которой с проведением документа (при том, что это может привести к существенному замедлению основного потока ввода документов) — вряд ли разумно.
Особенно если учесть тот факт, что контроль при проведении «задним числом» должен быть несколько иным, нежели автор нарисовал, НЕ «калькой» с контроля при оперативном проведении. Контроль при неоперативном проведении должен контролировать остатки не только на хронологическую позицию проводимого документа, но и на хронологические моменты всех(!!!) «следующих» доккументов. Что ещё более замедлит работу.
как-то так.
Кстати, ещё штришок относительно последствий Вашего «усовершенствования».
Анализ остатка на хронологический момент документа (с запретом проведения если не хватит — или даже просто с помещением такого документа и его автора в категорию «подозрительных») — источник «номенклатурных войн продажников». Ибо позволяет «задвинув» свой документ перед расходующим то же самое — «перехватить» продажу заканчивающихся товаров. Тот самый хрестоматийный случай «лишней информации».
гугль является владельцем сайта в сети “Интернет”, содержащего запрещенную информацию (в кэше).
или они гугль разбанили, а кєш евонній — забанили?.. тооонко.