Периодические реквизиты

[Alexanderrrr]

Доброго времени суток, уважаемые жители аксфорума!

Заранее извиняюсь, если вдруг пишу не в ту тему.

Проблема в следующем (axapta 3.0 SP5, sql 2000):

У предприятия сменился КПП. Т.е. на документах в зависимости от даты документа необходимо выводить разный КПП, новый или старый.
Как я понял, в аксапте не предусмотрен механизм периодического действия реквизитов..прав ли я?

Видимо придется придумывать логику самому.
Здесь хотел бы посоветоваться с гуру, каким образом было бы лучше это сделать.
1) создать табличку с полями:
реквизит
значение
дата начала действия
дата конца действия
2) естественно добавить грид на форму companyinfo
3) пробежаться по всем отчетам, в которых есть вывод реквизитов компании, и переписать вывод реквизитов в зависимости от даты документа.
Подскажите, пожалуйста, в правильном ли я мыслю направлении?

[sukhanchik]

Вы мыслите так, как реализует понятие периодический реквизит 1С . Я не говорю - плохо или хорошо - просто поясняю. Ваш вариант тоже неплох (так например, работают цены и версии спецификаций).
В Аксапте логика следующая: На момент разноски фиксируется "слепок" данных, который должен сохраниться. Последующая распечатка опирается исключительно на этот "слепок" и не опирается на текущие значения справочника (хотя для CompanyInfo в этом случае делается обычно исключение).
Поэтому в Вашем случае - я бы (на мой взгляд) "протянул" КПП предприятия в накладную (т.е. сохранял бы значение КПП в шапке накладной (CustInvoiceJour)). Т.к. код един для Cust- и Vend- таблиц - то возможно придется "протянуть" КПП еще и туда (по ходу выявится).
После этого - необходимо ориентировать печатную форму накладной на это новое поле и джобиком обновить поле старым КПП в исторических данных

Хотя - это только мнение - может кто другую мысль выскажет.

[Ivanhoe]

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

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

[mazzy]

Цитата:

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

Мне кажется в общем случае первый вариант лучше, т.к. позволит формировать документы с верным реквизитом в зависимости от даты.

Это бухгалтерский подход.
С точки зрения производственных заданий, управления складом имеет смысл формировать документы с верным реквизитом в зависимости от даты И ВРЕМЕНИ.

А с точки зрения управления производственными заданиями (MESA) имеет смысл детализация до дробных частей секунды.

правильным является подход:
4) записывать КПП (ИНН и прочие реквизиты непосредственно в документ) так, чтобы в любой момент можно было печатать документ не обращаясь к другим справочникам.

[mazzy]

Цитата:

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

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

Конечно есть такая возможность.
Закройте старый период (Главная книга \ Настройки \ Периоды \ Период)

[Alexanderrrr]

Спасибо, ребят, за ответы!

Цитата:

Поэтому в Вашем случае - я бы (на мой взгляд) "протянул" КПП предприятия в накладную (т.е. сохранял бы значение КПП в шапке накладной (CustInvoiceJour)). Т.к. код един для Cust- и Vend- таблиц - то возможно придется "протянуть" КПП еще и туда (по ходу выявится).
После этого - необходимо ориентировать печатную форму накладной на это новое поле и джобиком обновить поле старым КПП в исторических данных

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

Цитата:

С другой стороны, изменение КПП, ИНН и т.п. как часто происходят?

Происходят редко, но ведь я не застрахован от такого в будущем. Хотелось бы такую ситуацию предусмотреть и сделать нечто универсальное..

[sukhanchik]

Цитата:

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

Хотелось бы такую ситуацию предусмотреть и сделать нечто универсальное..

Ivanhoe прав в том плане - что Ваше решение учитывает возможную выписку документов "задним числом".

Но перед тем как делать нечто универсальное - я бы взвесил следующие факторы:
1. Частота использования механизма (Незачем городить код, который заведомо в ближайшие года не будет использоваться - этого никто не оценит).
2. Вероятность обновления версии в ближайшем будущем (Чем меньше нашего кода - тем проще переносить код)
3. "Вписывание" механизма в существующую идеологию (какая-бы она ни казалась неудобной). Правда этот пункт является больше рекомендацией по принципу - если нет разницы - то лучше "вписаться". Но тем не менее. Код, "вписанный" в общую логику более понятен и с большей вероятностью будет работать без ошибок (= требуется меньше времени на тестирование).

Так что решайте

[kashperuk]

Универсальное - не всегда хорошо
Но мне в данном случае тоже больше нравится первый вариант.
Своего рода Date-Effective реквизиты.

Офф-топ:
Прикольный аватар по смыслу. Только англ. неправильный. Разве только если это специально, как ребенок говорит

[mazzy]

Цитата:

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

Но мне в данном случае тоже больше нравится первый вариант.
Своего рода Date-Effective реквизиты.

Ни в коем случае. Поработай с 1С.

Во-первых, слишком мала точность таких реквизитов.
Зависимость только от даты сильно сокращает область применения таких реквизитов.

Если подумать чуть-чуть, то следующий шаг Date-Time-Effective реквизиты.
Но и у такого подхода тоже есть масса недостатков.
Что будет, если транзакция длится больше секунды?
Если часть реквизитов поменялась в одну секудну, а часть в другую секунду, а сам документ (в рамках той же транзакции) вообще через минуту?
И что будет, если таких документов, меняющих такие реквизиты, несколько?

Если подумать еще немножно, то придешь к мысли привязывать такой реквизит к dateTime И одновременно документу-операции (так сделала 1С). Но тут начинаются сложности уже с быстрыми транзакциями - что делать, если несколько документов обработались в одну секунду? Какое значение реквизита считать правильным за пределами документа, если в одну секунду сменилось несколько значений? Для обхода это проблемы возникают некие внутренние идентификаторы, которые не понятны пользователям, дебильные запреты считывать периодический реквизит за пределами документа и т.п. Но этот путь приводит к логическому тупику (как и понятие Точка актуальности).

Если же подумать хорошенько, то снова приходишь к мысли, что каждый документ-операция должен просто делать слепок всех необходимых ему данных. Что и делается в большинстве мест в Аксапте (за исключением прежде всего локализации). А мапы и объектно-ориентированное программирование должно помочь разобраться с массой полей в таблицах и в коде.

В общем, подумай хорошенько над своими желаниями - они могут исполнится.
Не надо периодических реквизитов.
Пусть будет как сейчас.
А для полного счастья нужны объектно-ориентированные группы полей в таблицах.

[GM2005]

Возможно наивное предположение. Но для подобных задач можно посмотреть на функционал Договоры. Через него можно привязывать (а затем отслеживать) необходимые по случаю реквизиты и параметры.

[mazzy]

Вспоминаем исходную задачу:

Цитата:

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

У предприятия сменился КПП. Т.е. на документах в зависимости от даты документа необходимо выводить разный КПП, новый или старый.

Читаем совет:

Цитата:

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

Но для подобных задач можно посмотреть на функционал Договоры. Через него можно привязывать (а затем отслеживать) необходимые по случаю реквизиты и параметры.

GM2005, разъясните подробнее пожалуста.
Как можно печатать "разный КПП, новый или старый" при помощи функционала Договоры?
(Маленький хинт - про смену договора в исходной задаче ничего не было сказано).

[Alexanderrrr]

Тут вы прямо в точку попали

Цитата:

1. Частота использования механизма (Незачем городить код, который заведомо в ближайшие года не будет использоваться - этого никто не оценит).

как минимум смены реквизитов организации не было уже 3 года..но, как только что узнал, смена будет происходить гораздо чаще..

Цитата:

2. Вероятность обновления версии в ближайшем будущем (Чем меньше нашего кода - тем проще переносить код)

именно в ближайшее время планируется переход на ax2009+sql2005

Цитата:

3. "Вписывание" механизма в существующую идеологию (какая-бы она ни казалась неудобной). Правда этот пункт является больше рекомендацией по принципу - если нет разницы - то лучше "вписаться". Но тем не менее. Код, "вписанный" в общую логику более понятен и с большей вероятностью будет работать без ошибок (= требуется меньше времени на тестирование).

такой момент безусловно тоже стоит учитывать..спасибо..

[Alexanderrrr]

Цитата:

4) записывать КПП (ИНН и прочие реквизиты непосредственно в документ) так, чтобы в любой момент можно было печатать документ не обращаясь к другим справочникам.

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

спасибо за ответы!

[mazzy]

Цитата:

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

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

Не "в таблицы, используемые в отчетах", а в "документ, который распечатывается и участвует в отчетах".
Я, например, полностью согласен с формулировкой sukhanchik:

Цитата:

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

В Аксапте логика следующая: На момент разноски фиксируется "слепок" данных, который должен сохраниться. Последующая распечатка опирается исключительно на этот "слепок" и не опирается на текущие значения справочника (хотя для CompanyInfo в этом случае делается обычно исключение).
Поэтому в Вашем случае - я бы (на мой взгляд) "протянул" КПП предприятия в накладную (т.е. сохранял бы значение КПП в шапке накладной (CustInvoiceJour)). Т.к. код един для Cust- и Vend- таблиц - то возможно придется "протянуть" КПП еще и туда (по ходу выявится).
После этого - необходимо ориентировать печатную форму накладной на это новое поле и джобиком обновить поле старым КПП в исторических данных

Цитата:

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

не потеряем ли мы здесь в производительности..?
размеры таблиц вырастут..

Потеряете чуток на операциях создания, обновления (только за счет большего размера записи, дополнительное время на индексы тратится не будет поскольку эти поля не входят в индексы)
И совсем не потеряете на операциях выборки (вместо сложного join у вас будет одна простая выборка из одной таблицы)

А с большим объемом стоит бороться обычным сегментированием таблиц.

[Alexanderrrr]

Цитата:

Вы очень витиевато выражаетесь.
Не "в таблицы, используемые в отчетах", а в "документ, который распечатывается и участвует в отчетах".

Извиняюсь, именно это и имел ввиду

Цитата:

В Аксапте логика следующая: На момент разноски фиксируется "слепок" данных, который должен сохраниться. Последующая распечатка опирается исключительно на этот "слепок" и не опирается на текущие значения справочника (хотя для CompanyInfo в этом случае делается обычно исключение).
Поэтому в Вашем случае - я бы (на мой взгляд) "протянул" КПП предприятия в накладную (т.е. сохранял бы значение КПП в шапке накладной (CustInvoiceJour)). Т.к. код един для Cust- и Vend- таблиц - то возможно придется "протянуть" КПП еще и туда (по ходу выявится).
После этого - необходимо ориентировать печатную форму накладной на это новое поле и джобиком обновить поле старым КПП в исторических данных

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

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

Спасибо, парни, многое для себя узнал

[Alexanderrrr]

Цитата:

Офф-топ:
Прикольный аватар по смыслу. Только англ. неправильный. Разве только если это специально, как ребенок говорит

надо же..людям почему-то нравится мой аватар, везде замечают))

[Ivanhoe]

Цитата:

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

Это бухгалтерский подход.
С точки зрения производственных заданий, управления складом имеет смысл формировать документы с верным реквизитом в зависимости от даты И ВРЕМЕНИ.

А с точки зрения управления производственными заданиями (MESA) имеет смысл детализация до дробных частей секунды.

правильным является подход:
4) записывать КПП (ИНН и прочие реквизиты непосредственно в документ) так, чтобы в любой момент можно было печатать документ не обращаясь к другим справочникам.

Если мы говорим про ИНН / КПП то у них есть понятие "время"? Прямо в документе, полученном в госоргане написано, что они действуют с 13:00?? Речь шла именно про них, а не про произвольные реквизиты!!! Mazzy, сами же не любите универсальных решений - не надо их искать у других

Я не зря написал "формировать документы" - т.е. ПЕРВИЧНОЕ заполнение ПОЛЕЙ в документе, в той же накладной.

Цитата:

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

Конечно есть такая возможность.
Закройте старый период (Главная книга \ Настройки \ Периоды \ Период)

А про "задним числом" - почему сразу мысли про прошлый период? Сегодня поменяли КПП, завтра формируем накладную за позавчера (в рамках одного периода) - стандартный подход подставит последнее значение КПП, а не историческое.

[mazzy]

Цитата:

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

Если мы говорим про ИНН / КПП то у них есть понятие "время"? Прямо в документе, полученном в госоргане написано, что они действуют с 13:00?? Речь шла именно про них, а не про произвольные реквизиты!!! Mazzy, сами же не любите универсальных решений - не надо их искать у других

Я не зря написал "формировать документы" - т.е. ПЕРВИЧНОЕ заполнение ПОЛЕЙ в документе, в той же накладной.

ок.

Цитата:

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

А про "задним числом" - почему сразу мысли про прошлый период? Сегодня поменяли КПП, завтра формируем накладную за позавчера (в рамках одного периода) - стандартный подход подставит последнее значение КПП, а не историческое.

Финансовый период в Аксапте можно дробить с точностью до дня.
Поэтому "прошлы период" можно установить и запретить на дату изменения КПП
Автор про это спрашивал. По-моему.