Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
Типовый порядок кассовой ревизии. Недостачи - кладутся в кассу из кармана кассира. Излишки - приходуются со спец.счета. Более ничего никого не колышет. Сумма личных денег, которую разрешается иметь кассиру, строго ограничена. И вообще, давайте не будем лезть в область орагнизации РКО или организации работы с наличностью. Тут все начиналось про более высокие материи. "пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 18:57 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
DogenНу Ваше дело, конечно, но я бы в таком случае написал инструкцию, запрещающую кассиру удалять записи о реально сделанных операциях. В конкретном случае - обязать кассира внести запись о приходе средств. Это нужно для того, чтобы уменьшить вероятность ошибок кассира. Ой, Вашими бы устами да медку бы зачерпнуть. ;) DogenСистема, однако, должна хранить всю информацию о том что документ был и что он был удален. И его последнее состояние (как минимум). Система то как раз все хранит, дабы глупость каждого видна была. DogenНо мышление Ваше порочно. Ибо деньги в данном случае реально були выданы. Не надо путать мое мышление, с мышлением кассира. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 18:58 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
pkarklin DogenНу Ваше дело, конечно, но я бы в таком случае написал инструкцию, запрещающую кассиру удалять записи о реально сделанных операциях. В конкретном случае - обязать кассира внести запись о приходе средств. Это нужно для того, чтобы уменьшить вероятность ошибок кассира. Ой, Вашими бы устами да медку бы зачерпнуть. ;) DogenСистема, однако, должна хранить всю информацию о том что документ был и что он был удален. И его последнее состояние (как минимум). Система то как раз все хранит, дабы глупость каждого видна была. DogenНо мышление Ваше порочно. Ибо деньги в данном случае реально були выданы. Не надо путать мое мышление, с мышлением кассира. ;) Если у Вас кассиры - идиоты, то запретите им менять документы. У меня - не совсем идиоты. Зависит от кадровой политики. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 19:00 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
Вообще к сторнировочным проводкам в банке легко привыкнуть. СБ РФ так и работает. В коммерческих банках можно всякое встретить :) Меня же интересует более хитрая область - прием и отпуск товара. Во, завтрева до логистики дойдем! "пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 19:01 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
DogenВообще к сторнировочным проводкам в банке легко привыкнуть. СБ РФ так и работает. В коммерческих банках можно всякое встретить :) Меня же интересует более хитрая область - прием и отпуск товара. Во, завтрева до логистики дойдем! "пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги" Ок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 19:04 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
Не возражаете, если я нахально вклинюсь в обсуждение со своим мнением? :) Я попытаюсь примирить опонентов и свести их к единой точке зрения. Мне кажется, что основное противоречие между опонентами заключается не в сути рассматриваемого вопроса, а в терминологии. ПМСМ, правы обе стороны, просто каждая сторона понимает одни и те же термины немного по-своему... "Сторнирование" - это бухгалтерский термин. И он подразумевает вполне конкретные действия в конкретных ситуациях. Правилами российского бухучета полагается именно сторнированием регистрировать некоторые хозяйственные операции (например, возврат ТМЦ на склад). Такая операция регистрирует не "ошибку пользователя" и ее исправление, а вполне штатную ситуацию, которая рассматривается как самостоятельная операция, а не исправление какой-то ошибки. В плане исправления ошибок в российском законодательстве тоже имеется свой набор требований. В частности, ошибки, относящиеся к текущему налоговому периоду, исправляются с применением правил сторнирования. Но если ошибки обнаружены в прошедших учетных периодах, в частности, в проводках, которые должны были найти отражение на субсчетах счета 90, то их исправление делается НЕ сторнированием. Исправительные проводки отражаются на специальных аналитиках субсчетов счета 91 (то есть, другого счета), что нарушает правила сторнирования. Вся эта свистопляска со сторнированием и его отсутствием направлена на достижение неких шаманских целей фискальных органов, как верно заметил mazzy. Mazzy совершенно правомерно обращает внимание на достоверность информации, на исключение возможности злоупотреблений по отношению к владельцам бизнеса по крайней мере в тех ситуациях, в которых эти ситуации возможно устранить соответствуюшей организацией работы программного обеспечения. При этом он использует термин "сторнирование" для обозначения "регистрируемых исправлений". Но регистрация исправлений и удаления информации - это НЕ синоним термина "сторнирование". Отсюда и проистекают различия во взглядах оппонентов. С моей точки зрения, вполне достаточно внести в систему автоматическую регистрацию всех телодвижений с возможностью заинтересованным лицам просмотра этих телодвижений. С точки зрения ИТ-технологий это правильнее назвать "журнализация", а не "сторнирование". "Сторнирование" - это только один из вариантов "журнализации", с моей точки зрения далеко не самый удачный. Если ERP-система предусматривает возможность автоматической журнализации на более продвинутом уровне, то это только плюс ERP-системы. То есть, у пользователя имеется возможность просто удалить накладную, исправив просто техническую ошибку. Но при этом в системе останется полная информация о том, что накладная была, кем, когда и где она была введена, какую именно информацию она содержала, кем, когда и с какого компьютера она была удалена, то никакой необходимости в отражении операции удаления накладной именно "сторнированием" уже не будет. Заинтересованные лица, которые имеют соответсвтующие права, могут просмотреть информацию с учетом всем удаленных и исправленных документов. Журнализация - штука весьма и всеьма необходимая, кто же спорит? Ну что, удалось мне вас примирить ваши точки зрения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 19:14 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
DogenТиповый порядок кассовой ревизии. Недостачи - кладутся в кассу из кармана кассира. Излишки - приходуются со спец.счета. Более ничего никого не колышет. Вы пропустили очень важный момент. Правильно будет так: Недостачи (если будут обнаружены) - кладутся в кассу из кармана кассира. Излишки (если будут обнаружены) - приходуются со спец.счета. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 20:07 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
GaryaЯ попытаюсь примирить опонентов и свести их к единой точке зрения. Спасибо. GaryaПри этом он использует термин "сторнирование" для обозначения "регистрируемых исправлений". Но регистрация исправлений и удаления информации - это НЕ синоним термина "сторнирование". Отсюда и проистекают различия во взглядах оппонентов. Еще раз спасибо за очень важное замечание. В дисскусиях про удаление до него доходит очень не часто. Народ устает раньше :) Термин "сторнирование" использую сознательно. Про "журнализацию" знаю. Считаю, что "журнализация" не даст необходимого эффекта по наведению порядка и повышению достоверности данных. Результаты журнализации могут использоваться ТОЛЬКО специально обученными людьми - как правило администраторами. А свя фишка состоит в том, чтобы "сторно-операции" были видны в обычных отчетах! Эти сторно операции нужны бизнесу для принятия управленческих решений. Использование журнализации заметает проблему под коврик и делает ее незаметной именно потому, что коррекций как правило не видно. В этот момент мне обычно приводят в пример отчеты и документы, которые надо показывать клиенту, в которых не должно быть корректировочных проводок. Типичный случай - акт сверки. Так вот. Мое мнение - в обычных отчетах СТОРНО операции должны быть видны обязательно. Если возникает необходимость в спецотчетах, то лучше сделать спецотчет. Только так можно свести количество махинаций и дебильных ошибок к минимуму. Только так можно повысить достоверность данных, как правильно заметил Garya. В противном случае бардак остается бардаком, а проблема просто заметается под коврик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 20:15 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
Garya"Сторнирование" - это бухгалтерский термин. И он подразумевает вполне конкретные действия в конкретных ситуациях. Правилами российского бухучета полагается именно сторнированием регистрировать некоторые хозяйственные операции (например, возврат ТМЦ на склад). Такая операция регистрирует не "ошибку пользователя" и ее исправление, а вполне штатную ситуацию, которая рассматривается как самостоятельная операция, а не исправление какой-то ошибки .... Вся эта свистопляска со сторнированием и его отсутствием направлена на достижение неких шаманских целей фискальных органов, как верно заметил mazzy. В OLTP я хочу видеть возврат товара. В принципе не буду против "отпуска отрицательных количеств", но это плохо согласуется с моей идеологией построения системы оперативного учета. Регистрация такой операции в бухучете путем сторнировочной проводки - еще лучше. Настроим проводку с соответствующей корреспонденцией счетов и отрицательной суммой. Кстати, спасибо за замечание про сторнирование операций возврата. GaryaС моей точки зрения, вполне достаточно внести в систему автоматическую регистрацию всех телодвижений с возможностью заинтересованным лицам просмотра этих телодвижений. ... в системе останется полная информация о том, что накладная была, кем, когда и где она была введена, какую именно информацию она содержала, кем, когда и с какого компьютера она была удалена, то никакой необходимости в отражении операции удаления накладной именно "сторнированием" уже не будет. Это конечно. Mazzy смешивает жизненное требование отследить все операции с документом и требование отражать определенным образом корректировки и возвраты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 09:49 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
mazzy DogenТиповый порядок кассовой ревизии. Недостачи - кладутся в кассу из кармана кассира. Излишки - приходуются со спец.счета. Более ничего никого не колышет. Вы пропустили очень важный момент. Правильно будет так: Недостачи (если будут обнаружены) - кладутся в кассу из кармана кассира. Излишки (если будут обнаружены) - приходуются со спец.счета. :) Wow! Конечно, обнаруженные. Но что значит не обнаруженные ? Плюс ко всему в обычном режиме при ревизии просматривается или распечатывается кассовый журнал, без анализа журнала OLTP и т.п. Это делается без привлечения администраторов системы и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 09:57 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
Первая попытка свести точки зрения опонентов в одну с треском провалилось... Итак, попытка №2. :) Mazzy, объясни мне пожалуйста, все ли операции по модификации каких-либо данных можно отследить с помощью сторнирования? В учетных системах, а также в ERP-системах, как правило, информация делится на информацию двух видов - условно-постоянную и условно-переменную. Условно-постоянная информация обычно помещается в справочники (словари), условно-переменная в регистры, журналы, учетные счета и т.п. С помощью "сторнирования" можно отследить, как я понимаю, только изменения условно-переменной информации. Но злоупотребления могут производиться модификацией также и условно-постоянной информации. Например, злоумышленник изменил содержимое справочника, в котором зафиксирована продажная цена на некоторый вид товара. После чего все остальные пользователи, не ведая о том, проводят операции, в том числе с контрагентом, с которым он вступил в сговор, по пониженной цене. Когда сделка будет зафиксирована, он изменит цену в справочнике обратно на ту, которая должна быть. Сторнирований нет, всё шито-крыто. Злоупотребление есть, и выявить его только одним сторнированием невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 12:33 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
GaryaПервая попытка свести точки зрения опонентов в одну с треском провалилось... Итак, попытка №2. :) Mazzy, объясни мне пожалуйста, все ли операции по модификации каких-либо данных можно отследить с помощью сторнирования? В учетных системах, а также в ERP-системах, как правило, информация делится на информацию двух видов - условно-постоянную и условно-переменную. Условно-постоянная информация обычно помещается в справочники (словари), условно-переменная в регистры, журналы, учетные счета и т.п. С помощью "сторнирования" можно отследить, как я понимаю, только изменения условно-переменной информации. Но злоупотребления могут производиться модификацией также и условно-постоянной информации. Например, злоумышленник изменил содержимое справочника, в котором зафиксирована продажная цена на некоторый вид товара. После чего все остальные пользователи, не ведая о том, проводят операции, в том числе с контрагентом, с которым он вступил в сговор, по пониженной цене. Когда сделка будет зафиксирована, он изменит цену в справочнике обратно на ту, которая должна быть. Сторнирований нет, всё шито-крыто. Злоупотребление есть, и выявить его только одним сторнированием невозможно. я, конечно, не mazzy, но не могу промолчать Это другая область, там свои тараканы. Мы в основном про документы говорили. Но вопрос хороший, может помочь определиться с терминологией. Условно-постоянную информацию характеризует медленный рост таблиц, ее содержащих ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 12:51 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
GaryaПервая попытка свести точки зрения опонентов в одну с треском провалилось... Итак, попытка №2. :) Mazzy, объясни мне пожалуйста, все ли операции по модификации каких-либо данных можно отследить с помощью сторнирования? В учетных системах, а также в ERP-системах, как правило, информация делится на информацию двух видов - условно-постоянную и условно-переменную... сторнирование как способ журнализации применяется для критических операций - финансовых проводок и даижений материала. Проводки и ДМ сами по себе "ходят" не часто, как правило, это есть результат логистической цепочки - заказ - исходящая поставка как основание для отгрузки - [операция отпуск материала] - документ\проводка отпуска материала - [операция фактурирования] - документ\проводка фактурирования в этой цепочке документ\проводка отпуска материала документ\проводка фактурирования модифицируются через сторно все остальное - "обычное" изменение логистических документов (заказа, поставки), например, по кол-ву, цене, номенклатуре с журнализацией изменений в виде "значение поля до - значение поля после" что касается отображения сторно \ изменений, то, в потоке документов по сделке необходимо показывать документы сторно. Изменения - по требованию, для конкретного документа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 13:06 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
GaryaПервая попытка свести точки зрения опонентов в одну с треском провалилось... Итак, попытка №2. :) И снова спасибо. GaryaMazzy, объясни мне пожалуйста, все ли операции по модификации каких-либо данных можно отследить с помощью сторнирования? Конечно же нет. Речь шла о документах. Об условно-переменной. Журнализация конечно же не отменяется :) Здесь несколько уровней. Первичка - документы - условно-переменная. Та информация, которую вводят операторы. Та информация, которая непосредственно является основной для принятия управленческих решений. Здесь уместнее держать сторно. Есть справочники - прайсы - условно-переменная. Отличие от предыдущего: а) доступ скорее всего ограничен. б) эта информация используется в первичке. Т.е. на управленческие решения влияет косвенно. Конечно же и здесь можно требовать сторно. Но отлично осознаю, что это будет уже перебор :) Хотя и для подобной справочной информации в некоторых системах вводится хранение всей истории. Например, периодические реквизиты в 1Св7, регистры сведений в 1Св8, журналы коммерческих соглашений в Аксапте... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 13:07 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
mazzy Первичка - документы - условно-переменная. Та информация, которую вводят операторы. Та информация, которая непосредственно является основной для принятия управленческих решений. Здесь уместнее держать сторно. Это данные , используемые для получения информации , используемой для принятия управленческих решений. Имхо, Вы слишком большое значение придаете отдельному документу. Он обычно занимает доли процента от общего оборота за некий внятный период, который, например, рассматривается при принятии решений. И директору сторно, не сторно - до балды, извините. Ему нужны интегральные параметры. Однако сторно в оперативном учете нужно (красное, "западное" - не суть важно), его можно использовать для ужесточения регламента работы с OLTP. Это всегда полезно, но - до разумных пределов (вспомним про компромиссы). mazzy Есть справочники - прайсы - условно-переменная. Отличие от предыдущего: а) доступ скорее всего ограничен. б) эта информация используется в первичке. Т.е. на управленческие решения влияет косвенно. Конечно же и здесь можно требовать сторно. Но отлично осознаю, что это будет уже перебор :) Какое сторно может быть для записей в справочнике, например, товаров??? А вот версионность поддерживать стоит, благо справочники маленькие по объему (относительному, конечно). Это не перебор, в сложных системах можно и на такое потратиться, имхо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 13:41 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
Так как насчет логистики поставок? И учета документов ВЭД? Кому что понравилось/не понравилось в российских и западных системах? WMS предлагаю не касаться, слишком специфическая тема, неплохо бы ее в отдельный топик вынести. "пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 13:44 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
DogenИмхо, Вы слишком большое значение придаете отдельному документу. Я этого не говорил. Я говорил, что документы не должны правиться бесследно. Правка должна обязательно оставлять следы :) DogenИ директору сторно, не сторно - до балды, извините. Ему нужны интегральные параметры. Полностью согласен. И один из интегральных параметров - относительная величина сторнирований и правок :) Насчет того, что правки занимают доли процента - это и есть большая иллюзия. Попробуйте. Вы удивитесь. Мои исследования показывают, что в среднем до 10-30 процентов документов правятся, если система это позволяет. Почему?! Вы обнаружите, что есть проведенные документы, которые правятся неоднократно! Вы обнаружите, что есть правки очень старых проведенных документов. И вы обнаружите, что доля таких правок существенна. Попробуйте запустить анализ хотя бы существующего лога, если вы работаете с 1С. Не говоря уже о дополнительных усилиях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 13:59 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
mazzy Насчет того, что правки занимают доли процента - это и есть большая иллюзия. Попробуйте. Вы удивитесь. Мои исследования показывают, что в среднем до 10-30 процентов документов правятся, если система это позволяет. Почему?! Вы обнаружите, что есть проведенные документы, которые правятся неоднократно! Вы обнаружите, что есть правки очень старых проведенных документов. И вы обнаружите, что доля таких правок существенна. Попробуйте запустить анализ хотя бы существующего лога, если вы работаете с 1С. Не говоря уже о дополнительных усилиях. Я не работаю с 1С: Не надо прям так сразу, раз не друг Аксапты так значит еще с 1С: не спрыгнул Касательно 1С: у меня мнение таково: хорошая вещь для экспорта сводных данных из OLTP. Отчетность отслеживает изменения в законодательстве и т.д. и т.п. Но вещь эта неповоротливая и ненадежная. Личное мнение, не надо устраивать со мной войну на эту тему Частоту правки документов я изучал специально, но на примере одной отдельно взятой компании. Выглядит это примерно так: 20% документов в базе по тем или иным причинам удалены (их переделали заново и т.п.). Правда, половина из них - не товарные документы, а денежные проводки. Ну и еще архитектура такая, что при начале выписки документа создается пустой документ в БД. А то было бы меньше. Если документ начали править, то изменений обычно бывает 3-4. Какой процент документов подвергается исправлению, сейчас сказать не могу, но это десятки процентов. Все эти исправления происходят в первые час-два. Повторюсь, все это обусловлено заложенными в конце 1990-х в использовавшуюся систему решениями. Частота правки документов через несколько дней после их оформления - 1-2%, не больше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 14:12 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
mazzyХотя и для подобной справочной информации в некоторых системах вводится хранение всей истории. Например, периодические реквизиты в 1Св7, регистры сведений в 1Св8, журналы коммерческих соглашений в Аксапте...Небольшое уточнение. Периодические реквизиты в 1С и т.п. - это НЕ журнализация изменений. Это "версионность" записей. То есть, возможность иметь несколько различных значений, действующих на различных отрезках учетного времени. А журнализация отслеживает изменения, в результате которых только последняя версия записи остается действующей , а все предыдущие варианты никоим образом не влияют на информацию, которая вводится в систему после модифификации записи. Задача журнализации - определить, кто, когда, с какого компьютера вносил изменения в систему. Задача версионности - обеспечить коректную работу системы, распечатку документов и отчетов при изменении реквизитов организации, смене сотрудниками фамилий и т.п. Те примеры, которые ты привел, не соответсвтуют задачам журнализации. Они решают задачи версионности. Весьма существенное замечание Dogen по поводу того, что руководство интересуют по большей части итоговые показатели. В детали они начинают вникать только если обнаружатся какие-то подозрительные изменения итоговых показателей. Поэтому на самом деле сторнирование не является таким уж выигрышным по сравнению с журнализацией с точки зрения повышения выявляемости злоупотреблений. Если возникло желание узнать подробности, включив просмотр журнализированных операций, то это можно сделать и руководителю, если софт такие возможности предоставляет. Совсем не обязательно подключать для этого какого-либо специалиста, если такие просмотры можно осуществлять единообразно по любым категориям информации, и они удобны в использовании. Более того, если есть какие-либо подозрения на злоупотребления, произведенные модификацией информации, можно включить просмотр только той информации, которая подверглась изменениям за определенный период, и очень быстро выявить те изменения, которые нас действительно интересуют. Формировать отчеты только по сторнировочным проводкам, конечно же, тоже можно. Но зачастую менее удобно. Интерактивные BI-системы предоставляют возможность топ-менеджменту ковыряться в информации именно "сверху-вниз", от итоговых показателей к подробностям. И такой подход лично я считаю более эффективным, нежели ориентация на отчеты фиксированной формы, предназначенные для разглядывания в виде, распечатанном на бумаге. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 14:18 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
DogenЯ не работаю с 1С: Не надо прям так сразу, раз не друг Аксапты так значит еще с 1С: не спрыгнул Извините, просто я безграмотный и не знаю как можно анализировать лог изменений документов в других системах :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 14:23 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
mazzy DogenЯ не работаю с 1С: Не надо прям так сразу, раз не друг Аксапты так значит еще с 1С: не спрыгнул Извините, просто я безграмотный и не знаю как можно анализировать лог изменений документов в других системах :) Ну это зависит какая у Вас система :) У меня лог в одной из таблиц БД, соответственно мне его легче анализировать. Структура его выработалась из практики - раз-другой ее усложняли. Но в любом случае это просто лог. Подходит разве что для получения доп.информации при разборках. Как в 1С: - не знаю, к сожалению. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 14:27 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
Garya mazzyХотя и для подобной справочной информации в некоторых системах вводится хранение всей истории. Например, периодические реквизиты в 1Св7, регистры сведений в 1Св8, журналы коммерческих соглашений в Аксапте...Небольшое уточнение. Периодические реквизиты в 1С и т.п. - это НЕ журнализация изменений. Это "версионность" записей. То есть, возможность иметь несколько различных значений, действующих на различных отрезках учетного времени. Ох. И согласен, и не согласен. Не будем уводить в сторону. Если интересно, лучше открыть новую ветку. GaryaА журнализация отслеживает изменения, в результате которых только последняя версия записи остается действующей , а все предыдущие варианты никоим образом не влияют на информацию, которая вводится в систему после модифификации записи. Задача журнализации - определить, кто, когда, с какого компьютера вносил изменения в систему. Задача версионности - обеспечить коректную работу системы, распечатку документов и отчетов при изменении реквизитов организации, смене сотрудниками фамилий и т.п. Те примеры, которые ты привел, не соответсвтуют задачам журнализации. Они решают задачи версионности. ок. пусть будет так. GaryaВесьма существенное замечание Dogen по поводу того, что руководство интересуют по большей части итоговые показатели. Я согласен. Но я еще говорил, что количество правок - очень интересный показатель. Многие пока его либо не считают, либо не знают, что его можно считать. GaryaВ детали они начинают вникать только если обнаружатся какие-то подозрительные изменения итоговых показателей. Поэтому на самом деле сторнирование не является таким уж выигрышным по сравнению с журнализацией с точки зрения повышения выявляемости злоупотреблений. Garya, тебе эта фраза не напоминает приведенную выше о том, что недостача в кассе списывается с кассира... Причем там было пропущено слово "обнаруженная" недостача :) А еще бывает необнаруженная. Сторно нужно для того, чтобы выявить и очень четко подчеркнуть эту необнаруженную часть :) GaryaЕсли возникло желание узнать подробности, включив просмотр журнализированных операций, то это можно сделать и руководителю, если софт такие возможности предоставляет. Надеюсь ты пробовал так сделать хотя бы на полугодовом журнале. Ну хотя бы логи прокси сервера за месяц :) Правда ведь? GaryaСовсем не обязательно подключать для этого какого-либо специалиста, если такие просмотры можно осуществлять единообразно по любым категориям информации, и они удобны в использовании. Я тебе как руководитель говорю: я например, лог прокси анализировать не буду. Нет, я смотрю на размер этого лога. Я даже внутрь заглядываю и пролистываю пару страниц :) Но анализирует этот лог спец для того, чтобы выдать аналитическую информацию. Сейчас мне расскажут о инструментах анализа прокси-лога. Я знаю. И даже пробовал. Вся фишка таких инструментов состоит в фразе "если вы настроите правила анализа..." А я не знаю этих правил! Мне нужен анализ лога, как раз для того, чтобы эти правила создать! То же самое относится к журналам изменений. Если ты знаешь где у тебя пи... воруют. То, конечно же можно натравить некий анализатор. Но сначала надо составить эти правила. Сторно же видны в отчетах сразу. Без дополнительных инструментов. Сторно кричат - вот они мы - ошибки! Сторно так мешают менеджерам, что не обратить на них внимание просто невозможно... Так давайте искоренять причину появления сторно, чтобы минимизировать. А не заметать под коврик (в журнал) Garya Более того, если есть какие-либо подозрения на злоупотребления, произведенные модификацией информации, можно включить просмотр только той информации, которая подверглась изменениям за определенный период, и очень быстро выявить... Очень надеюсь... верю... убеден, что ты уже выявлял и знаешь о чем говоришь. У меня поиск хитрых схем занимал безумное время. У меня сбор доказательства, что это юзер изменил документ (а он отрицает это зараза), занимал кучу сил и нервов. Очень надеюсь, что это я ошибаюсь или чего-то не умею... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 14:39 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
Garya mazzyХотя и для подобной справочной информации в некоторых системах вводится хранение всей истории. Например, периодические реквизиты в 1Св7, регистры сведений в 1Св8, журналы коммерческих соглашений в Аксапте...Небольшое уточнение. Периодические реквизиты в 1С и т.п. - это НЕ журнализация изменений. Это "версионность" записей. То есть, возможность иметь несколько различных значений, действующих на различных отрезках учетного времени. А журнализация отслеживает изменения, в результате которых только последняя версия записи остается действующей , а все предыдущие варианты никоим образом не влияют на информацию, которая вводится в систему после модифификации записи. Задача журнализации - определить, кто, когда, с какого компьютера вносил изменения в систему. Задача версионности - обеспечить коректную работу системы, распечатку документов и отчетов при изменении реквизитов организации, смене сотрудниками фамилий и т.п. Те примеры, которые ты привел, не соответсвтуют задачам журнализации. Они решают задачи версионности. А вот корректная реализация версионности устраняет необходимость в логировании действий с документами. Хотя и ест ресурсы. GaryaВесьма существенное замечание Dogen по поводу того, что руководство интересуют по большей части итоговые показатели. В детали они начинают вникать только если обнаружатся какие-то подозрительные изменения итоговых показателей. Поэтому на самом деле сторнирование не является таким уж выигрышным по сравнению с журнализацией с точки зрения повышения выявляемости злоупотреблений. Если возникло желание узнать подробности, включив просмотр журнализированных операций, то это можно сделать и руководителю, если софт такие возможности предоставляет. Совсем не обязательно подключать для этого какого-либо специалиста, если такие просмотры можно осуществлять единообразно по любым категориям информации, и они удобны в использовании. Более того, если есть какие-либо подозрения на злоупотребления, произведенные модификацией информации, можно включить просмотр только той информации, которая подверглась изменениям за определенный период, и очень быстро выявить те изменения, которые нас действительно интересуют. Формировать отчеты только по сторнировочным проводкам, конечно же, тоже можно. Но зачастую менее удобно. Интерактивные BI-системы предоставляют возможность топ-менеджменту ковыряться в информации именно "сверху-вниз", от итоговых показателей к подробностям. И такой подход лично я считаю более эффективным, нежели ориентация на отчеты фиксированной формы, предназначенные для разглядывания в виде, распечатанном на бумаге. Это такой, гипотетический, топ-менеджер, который ковыряется. Который еще и денег не пожалел на подобную систему :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 14:43 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
mazzy в своем жутко эмоциональном спиче прав, конечно. но вот хотелось бы иметь системы, которые и версионность поддерживают, и логи записывают. и пользоваться тем чем захочется. чем эти технологии будут шире распространены и будут гибче, тем они будут дешевле. так что вопрос скорее всего в том, чтобы иметь системы, которые не определяют технологии работы, а ее поддерживают. конечно, хорошо бы искоренить причины сторнировки. но мне (сегодня) выгоднее иметь склад без современных технологий складского учета, потому что это мне экономит сотни тысяч енотов. а трачу я меньше. и так далее... "пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 14:50 |
|
||
|
Дефицит функциональности западных ERP по сравнению с отечественными
|
|||
|---|---|---|---|
|
#18+
ПРЕДЛАЛАЮ ВЕРНУТЬСЯ К ТЕМЕ ТОПИКА ! ! ! Различие в терминах и тех.решениях сводит на "нет" ценность дискуссии про правку документов. Тем более дискуссия не нова. Дифицит фун-ти объясним легко: её непросто или нерационально(долго/дорого) делать. Это касается в т.ч. переделок док-тов. Что же именно стало дефицитом ? ДАВАЙТЕ ПОГОЛОСУЕМ НА ЭТУ ТЕМУ: У КОГО ЧЕГО НЕ ХВАТИЛО В Ф-ТИ ЗАПАДНЫХ СИСТЕМ ? Маё ИМХО(Navision Attain): Не хватает буквально всего :) Даже можно простить практически нулевую отчётность, т.к. она зачастую имеет местную специфику. Изменению подверглись почти все формы и таблицы в т.ч. ключевые. Всё это, как и полагается :) сопровождалось морем ошибок. Пришлось добавить массу проверок, т.к. во многих местах запросто можно грохнуть запись, на которую есть куча ссылок. Безопасность примитивная, а точнее убогая. Сторнирование документов - самодельное :) В некоторых местах проблемы с округлением. Короче...слов нет... Хотя NA как бизнес-конструктор местами очень даже неплох. - Вам понравилась невеста ? - Ну... местами... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 14:50 |
|
||
|
|

start [/forum/topic.php?fid=29&msg=32901159&tid=1528585]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
143ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
1ms |
| others: | 229ms |
| total: | 481ms |

| 0 / 0 |
