Navision и удержание истории по сотрудникам

[Uni_DeMoN_imported]

есть у навика один недостаток - не держит историю по сотрудникам.

Например надо распечать счёт-фактуру от числа, когда кассир или бухгалтер был другой, который уволился, а подтягивается-то новый естесно.
1с в этом отношении рулит.

Приходится залезать в настройки-таблицы и менять кассира или бухгалтера -мне кажется это неправильно.

Сделать самому это можно но при этом придётся перелопачивать всё отчёты где это задействуется. Может в новых версиях это исправят.

Кто что думает по этому поводу?

[Dzemon]

Мне кажется это довольно экзотическое требование.

[rootadmin]

Требование нормальное на самом деле. Действительно, много где в Навижне не хватает периодических реквизитов. Но потому и не хватает, что для их обработки нужно время и не везде их удобно использовать.

Мое мнение, чтьо в новых версиях это не исправят. Придется самому дописывать там, где особенно надо.

[Uni_DeMoN_imported]

Цитата:

Сообщение от rutadmeen

Требование нормальное на самом деле. Действительно, много где в Навижне не хватает периодических реквизитов. Но потому и не хватает, что для их обработки нужно время и не везде их удобно использовать.

Мое мнение, чтьо в новых версиях это не исправят. Придется самому дописывать там, где особенно надо.

с другой стороны, дописывание всей этой кухни может плохо сказаться на апгрейде версии к более новой придётся залезать в стандартный функционал- итак уже мучаемся с перелопачиванием модифицированных обьектов- куда уж больше то.
Моё мнение - это должен сделать центр решений msbs.
Но сделать это надо обязательно - МЫ же за автоматизацию...

[Kirvisniemi]

Периодические реквизиты на самом деле не что иное как обычная таблица с 4 колонками: номер таблицы, номер поля, дата изменения и новое значение.

Реализовать механизм, поддерживающий такие реквизиты, можно за 10 минут. Тем более, что есть такая замечательная таблица 405 Change Log Entry, из которой остается лишь выборки делать.

Посему желание внедрить периодические реквизиты скорее эмоциональное, чем разумное. Лучше бы сделали полноценный 3-уровень и визуальные OCX

[Uni_DeMoN_imported]

Цитата:

Сообщение от tyrex

Периодические реквизиты на самом деле не что иное как обычная таблица с 4 колонками: номер таблицы, номер поля, дата изменения и новое значение.

Реализовать механизм, поддерживающий такие реквизиты, можно за 10 минут. Тем более, что есть такая замечательная таблица 405 Change Log Entry, из которой остается лишь выборки делать.

Посему желание внедрить периодические реквизиты скорее эмоциональное, чем разумное. Лучше бы сделали полноценный 3-уровень и визуальные OCX

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

[Kirvisniemi]

Почему на первый взгляд?
Вот. Получилось за 7 минут

VAR
 Log: Record 405;

PROCEDURE GetPeriodicValue(Date:Date; TableNo:Integer; FieldNo:Integer) : Text[250];
    BEGIN
      // Функция получения значения периодического реквизита
      // Вход:
      //        Date  - дата, на которую требуется получить значение
      //        TableNo - номер таблицы
      //        FieldNo - номер поля
      // Выход - значение

      Log.RESET;
      Log.SETRANGE("Table No.",TableNo);
      Log.SETRANGE("Field No.",FieldNo);
      //Log.SETFILTER("Primary Key Field 1 Value",Value);
      IF Log.FIND('+') THEN
      REPEAT
         IF DT2DATE(Log."Date and Time")<=Date THEN EXIT(Log."New Value")
      UNTIL Log.NEXT(-1) = 0;
      EXIT('');
    END;

Жалющие могут дополнить фильтрацию по нужному ключу (закомментировано), а также выходное значение при пустой таблице. Алгоритм реализован в лоб. Я уже сейчас вижу как можно его упростить.

[Uni_DeMoN_imported]

Цитата:

Сообщение от tyrex

Почему на первый взгляд?
Вот. Получилось за 7 минут

VAR
 Log: Record 405;

PROCEDURE GetPeriodicValue(Date:Date; TableNo:Integer; FieldNo:Integer) : Text[250];
    BEGIN
      // Функция получения значения периодического реквизита
      // Вход:
      //        Date  - дата, на которую требуется получить значение
      //        TableNo - номер таблицы
      //        FieldNo - номер поля
      // Выход - значение

      Log.RESET;
      Log.SETRANGE("Table No.",TableNo);
      Log.SETRANGE("Field No.",FieldNo);
      //Log.SETFILTER("Primary Key Field 1 Value",Value);
      IF Log.FIND('+') THEN
      REPEAT
         IF DT2DATE(Log."Date and Time")<=Date THEN EXIT(Log."New Value")
      UNTIL Log.NEXT(-1) = 0;
      EXIT('');
    END;

Жалющие могут дополнить фильтрацию по нужному ключу (закомментировано), а также выходное значение при пустой таблице. Алгоритм реализован в лоб. Я уже сейчас вижу как можно его упростить.

спасибо конечно за грамотный исходный код, но Вы забываете, что надо, во первых, перелопатить весь функционал в системе, который отвечает за подтягивание необходимых периодических реквизитов, а это не только отчёты, но по всей вероятности и все остальные обьекты, во вторых, подумайте, если сотрудник уволился а нового нет, скажем неделя выпадает, а документы должен подписывать кто-то, кто исполняет обязанности (временно) этого лица.
Как тут быть?
Реализовать-то можно быстро, а потом всё равно придёться дописывать...
Спасибо всё равно.

[Тимур_imported]

После того, как господа разработчики обменялись кодами, предлагаю подумать над тем, что согласно правилам бухгалтерского учета хозяйственная операция должна оформляться первичным документом непосредственно в момент совершения операции. Законодательство допускает формирование документов в течении отчетного периода, но это обусловлено большим количеством ручного труда бухгалтеров. После же автоматизации операции должны формироваться вместе с документами вовремя. Поэтому если кто-то не выставляет счет-фактуру в течении 5-и дней - то это нарушение законодательства. Учет денежных средств в Росси вообще строгая штука: итоги по кассе подводятся каждый день.
Господа, не делайте из западных систем 1с. Это не слабость функционала Navision, а неправильность подходов к осуществлению учета в 1с.

[Uni_DeMoN_imported]

Цитата:

Сообщение от Тимур

После того, как господа разработчики обменялись кодами, предлагаю подумать над тем, что согласно правилам бухгалтерского учета хозяйственная операция должна оформляться первичным документом непосредственно в момент совершения операции. Законодательство допускает формирование документов в течении отчетного периода, но это обусловлено большим количеством ручного труда бухгалтеров. После же автоматизации операции должны формироваться вместе с документами вовремя. Поэтому если кто-то не выставляет счет-фактуру в течении 5-и дней - то это нарушение законодательства. Учет денежных средств в Росси вообще строгая штука: итоги по кассе подводятся каждый день.
Господа, не делайте из западных систем 1с. Это не слабость функционала Navision, а неправильность подходов к осуществлению учета в 1с.

спасибо за дельный совет Тимур
попробую полностью избавиться от пережитков постсоветской действительности...

[Dzemon]

Поддерживаю Тимура, ибо все усовершенствования - на 90% это борьба с раздолбайством.

[Uni_DeMoN_imported]

Цитата:

Сообщение от Dzemon

Поддерживаю Тимура, ибо все усовершенствования - на 90% это борьба с раздолбайством.

тут мне тоже посоветовали, что проблема эта решается скорее административными методами, чем программными...


(надо наверное по башке всем надовать и всё устаканится....
а то задолбыли совсем им (менеджерам, кассиру, бухгалтерам), видити ли надо перевыставлять счета из-за потери клиентом документа, распечать кассовый лист. платёжку от числа. когда был хз какой ИО и т.д.)

вобщем всем им по одному месту

[rootadmin]

Только иногда бывает проще сделать из программы 1С (не все, а часть, конечно), чем решить проблему административными методами.
Нервы дороже бывают.

[Dzemon]

Цитата:

Сообщение от rutadmeen

Только иногда бывает проще сделать из программы 1С (не все, а часть, конечно), чем решить проблему административными методами.
Нервы дороже бывают.

Да уж......
Только потом из Навижина такое дерьмо получается, что работать в нем невозможно. Тут главное вовремя сказать НЕТ!!!! и настоять на своем, опыт показывает, что неделя скандала экономит месяцы работы и кучу денет.

[Glazz]

Цитата:

Сообщение от Dzemon

Цитата:

Сообщение от rutadmeen

Только иногда бывает проще сделать из программы 1С (не все, а часть, конечно), чем решить проблему административными методами.
Нервы дороже бывают.

Да уж......
Только потом из Навижина такое дерьмо получается, что работать в нем невозможно. Тут главное вовремя сказать НЕТ!!!! и настоять на своем, опыт показывает, что неделя скандала экономит месяцы работы и кучу денет.

<{POST_SNAPBACK}>

Интересное предложение по получению истории значения.
Токма нужно незабывать включать журналирование этой таблицы и запрещать очистку журнала изменений )) А то как ОЙ.. и пи... ну вы поняли...
Смысл делать периодические реквизиты есть они нужны, я смотрю на это с точки зрения реализации заработной платы и кадров. Там это необхадимо сплошь и рядом. Кстати в 1С 8.0 отказались от пер. реквизитов но ввели регистры для того же самого..
Еще бы репортер навижену нормальный.. пусть хоть как в старой 1с ке..

ех...

[IGG]

"Тут главное вовремя сказать НЕТ!!!! и настоять на своем"
Штирлиц попробовал стоять на СВОЕМ. Ему было очень больно

[SVG]

Чета почитал и аж прослезился....
неужели в конторе такая текучка ГлавБухов и кассиров что даже надо автоматизировать их смену? Ужас )

[Wizard_imported]

одного раза достаточно...

[SVG]

Да ладно, раз в жизнь распечатать задним числом пару фактур - не проблема. Надо конечно уточнить размеры бедствия - может печатать надо сто фактур, и увольняются кассиры просто каждый месяц - тогда можно чуть доработать СтандОтчетУправление, там делов в общем-то на 20 минут, на форум больше потратили уже