25.12.2009, 14:30 | #1 |
Участник
|
Периодические реквизиты
Доброго времени суток, уважаемые жители аксфорума!
Заранее извиняюсь, если вдруг пишу не в ту тему. Проблема в следующем (axapta 3.0 SP5, sql 2000): У предприятия сменился КПП. Т.е. на документах в зависимости от даты документа необходимо выводить разный КПП, новый или старый. Как я понял, в аксапте не предусмотрен механизм периодического действия реквизитов..прав ли я? Видимо придется придумывать логику самому. Здесь хотел бы посоветоваться с гуру, каким образом было бы лучше это сделать. 1) создать табличку с полями: реквизит значение дата начала действия дата конца действия 2) естественно добавить грид на форму companyinfo 3) пробежаться по всем отчетам, в которых есть вывод реквизитов компании, и переписать вывод реквизитов в зависимости от даты документа. Подскажите, пожалуйста, в правильном ли я мыслю направлении?
__________________
..в каждой программе есть хотя бы одна ошибка.. Последний раз редактировалось Alexanderrrr; 25.12.2009 в 15:05. |
|
25.12.2009, 14:48 | #2 |
Administrator
|
Вы мыслите так, как реализует понятие периодический реквизит 1С . Я не говорю - плохо или хорошо - просто поясняю. Ваш вариант тоже неплох (так например, работают цены и версии спецификаций).
В Аксапте логика следующая: На момент разноски фиксируется "слепок" данных, который должен сохраниться. Последующая распечатка опирается исключительно на этот "слепок" и не опирается на текущие значения справочника (хотя для CompanyInfo в этом случае делается обычно исключение). Поэтому в Вашем случае - я бы (на мой взгляд) "протянул" КПП предприятия в накладную (т.е. сохранял бы значение КПП в шапке накладной (CustInvoiceJour)). Т.к. код един для Cust- и Vend- таблиц - то возможно придется "протянуть" КПП еще и туда (по ходу выявится). После этого - необходимо ориентировать печатную форму накладной на это новое поле и джобиком обновить поле старым КПП в исторических данных Хотя - это только мнение - может кто другую мысль выскажет.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 25.12.2009 в 14:51. |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
25.12.2009, 15:07 | #3 |
Участник
|
Мне кажется в общем случае первый вариант лучше, т.к. позволит формировать документы с верным реквизитом в зависимости от даты. Т.е. если я сегодня сделаю накладную за вчера (а ночью поменяли реквизит), то получу верное значение.
С другой стороны, изменение КПП, ИНН и т.п. как часто происходят? И если есть возможность хотя бы временно запретить проводку документов задним (или передним) числом, то можно обойтись и без модификаций - вариант, предложенный sukhanchik.
__________________
Ivanhoe as is.. |
|
25.12.2009, 15:30 | #4 |
Участник
|
Спасибо, ребят, за ответы!
Цитата:
Поэтому в Вашем случае - я бы (на мой взгляд) "протянул" КПП предприятия в накладную (т.е. сохранял бы значение КПП в шапке накладной (CustInvoiceJour)). Т.к. код един для Cust- и Vend- таблиц - то возможно придется "протянуть" КПП еще и туда (по ходу выявится).
После этого - необходимо ориентировать печатную форму накладной на это новое поле и джобиком обновить поле старым КПП в исторических данных Цитата:
С другой стороны, изменение КПП, ИНН и т.п. как часто происходят?
__________________
..в каждой программе есть хотя бы одна ошибка.. |
|
25.12.2009, 15:53 | #5 |
Administrator
|
Цитата:
Но перед тем как делать нечто универсальное - я бы взвесил следующие факторы: 1. Частота использования механизма (Незачем городить код, который заведомо в ближайшие года не будет использоваться - этого никто не оценит). 2. Вероятность обновления версии в ближайшем будущем (Чем меньше нашего кода - тем проще переносить код) 3. "Вписывание" механизма в существующую идеологию (какая-бы она ни казалась неудобной). Правда этот пункт является больше рекомендацией по принципу - если нет разницы - то лучше "вписаться". Но тем не менее. Код, "вписанный" в общую логику более понятен и с большей вероятностью будет работать без ошибок (= требуется меньше времени на тестирование). Так что решайте
__________________
Возможно сделать все. Вопрос времени |
|
25.12.2009, 16:04 | #6 |
Участник
|
Универсальное - не всегда хорошо
Но мне в данном случае тоже больше нравится первый вариант. Своего рода Date-Effective реквизиты. Офф-топ: Прикольный аватар по смыслу. Только англ. неправильный. Разве только если это специально, как ребенок говорит |
|
25.12.2009, 16:31 | #7 |
Участник
|
Цитата:
Во-первых, слишком мала точность таких реквизитов. Зависимость только от даты сильно сокращает область применения таких реквизитов. Если подумать чуть-чуть, то следующий шаг Date-Time-Effective реквизиты. Но и у такого подхода тоже есть масса недостатков. Что будет, если транзакция длится больше секунды? Если часть реквизитов поменялась в одну секудну, а часть в другую секунду, а сам документ (в рамках той же транзакции) вообще через минуту? И что будет, если таких документов, меняющих такие реквизиты, несколько? Если подумать еще немножно, то придешь к мысли привязывать такой реквизит к dateTime И одновременно документу-операции (так сделала 1С). Но тут начинаются сложности уже с быстрыми транзакциями - что делать, если несколько документов обработались в одну секунду? Какое значение реквизита считать правильным за пределами документа, если в одну секунду сменилось несколько значений? Для обхода это проблемы возникают некие внутренние идентификаторы, которые не понятны пользователям, дебильные запреты считывать периодический реквизит за пределами документа и т.п. Но этот путь приводит к логическому тупику (как и понятие Точка актуальности). Если же подумать хорошенько, то снова приходишь к мысли, что каждый документ-операция должен просто делать слепок всех необходимых ему данных. Что и делается в большинстве мест в Аксапте (за исключением прежде всего локализации). А мапы и объектно-ориентированное программирование должно помочь разобраться с массой полей в таблицах и в коде. В общем, подумай хорошенько над своими желаниями - они могут исполнится. Не надо периодических реквизитов. Пусть будет как сейчас. А для полного счастья нужны объектно-ориентированные группы полей в таблицах. |
|
|
За это сообщение автора поблагодарили: gl00mie (2). |
25.12.2009, 16:44 | #8 |
Участник
|
Цитата:
С точки зрения производственных заданий, управления складом имеет смысл формировать документы с верным реквизитом в зависимости от даты И ВРЕМЕНИ. А с точки зрения управления производственными заданиями (MESA) имеет смысл детализация до дробных частей секунды. правильным является подход: 4) записывать КПП (ИНН и прочие реквизиты непосредственно в документ) так, чтобы в любой момент можно было печатать документ не обращаясь к другим справочникам. |
|
25.12.2009, 16:47 | #9 |
Участник
|
Возможно наивное предположение. Но для подобных задач можно посмотреть на функционал Договоры. Через него можно привязывать (а затем отслеживать) необходимые по случаю реквизиты и параметры.
|
|
25.12.2009, 16:49 | #10 |
Участник
|
Тут вы прямо в точку попали
Цитата:
1. Частота использования механизма (Незачем городить код, который заведомо в ближайшие года не будет использоваться - этого никто не оценит).
Цитата:
2. Вероятность обновления версии в ближайшем будущем (Чем меньше нашего кода - тем проще переносить код)
Цитата:
3. "Вписывание" механизма в существующую идеологию (какая-бы она ни казалась неудобной). Правда этот пункт является больше рекомендацией по принципу - если нет разницы - то лучше "вписаться". Но тем не менее. Код, "вписанный" в общую логику более понятен и с большей вероятностью будет работать без ошибок (= требуется меньше времени на тестирование).
__________________
..в каждой программе есть хотя бы одна ошибка.. |
|
25.12.2009, 16:51 | #11 |
Участник
|
Вспоминаем исходную задачу:
Цитата:
Цитата:
Как можно печатать "разный КПП, новый или старый" при помощи функционала Договоры? (Маленький хинт - про смену договора в исходной задаче ничего не было сказано). |
|
25.12.2009, 16:55 | #12 |
Участник
|
Цитата:
4) записывать КПП (ИНН и прочие реквизиты непосредственно в документ) так, чтобы в любой момент можно было печатать документ не обращаясь к другим справочникам.
не потеряем ли мы здесь в производительности..? размеры таблиц вырастут.. спасибо за ответы!
__________________
..в каждой программе есть хотя бы одна ошибка.. |
|
25.12.2009, 16:56 | #13 |
Участник
|
Цитата:
Закройте старый период (Главная книга \ Настройки \ Периоды \ Период) |
|
25.12.2009, 17:01 | #14 |
Участник
|
Цитата:
Я, например, полностью согласен с формулировкой sukhanchik: Цитата:
Сообщение от sukhanchik
В Аксапте логика следующая: На момент разноски фиксируется "слепок" данных, который должен сохраниться. Последующая распечатка опирается исключительно на этот "слепок" и не опирается на текущие значения справочника (хотя для CompanyInfo в этом случае делается обычно исключение).
Поэтому в Вашем случае - я бы (на мой взгляд) "протянул" КПП предприятия в накладную (т.е. сохранял бы значение КПП в шапке накладной (CustInvoiceJour)). Т.к. код един для Cust- и Vend- таблиц - то возможно придется "протянуть" КПП еще и туда (по ходу выявится). После этого - необходимо ориентировать печатную форму накладной на это новое поле и джобиком обновить поле старым КПП в исторических данных Цитата:
И совсем не потеряете на операциях выборки (вместо сложного join у вас будет одна простая выборка из одной таблицы) А с большим объемом стоит бороться обычным сегментированием таблиц. |
|
25.12.2009, 17:13 | #15 |
Участник
|
Цитата:
Вы очень витиевато выражаетесь.
Не "в таблицы, используемые в отчетах", а в "документ, который распечатывается и участвует в отчетах". Цитата:
В Аксапте логика следующая: На момент разноски фиксируется "слепок" данных, который должен сохраниться. Последующая распечатка опирается исключительно на этот "слепок" и не опирается на текущие значения справочника (хотя для CompanyInfo в этом случае делается обычно исключение).
Поэтому в Вашем случае - я бы (на мой взгляд) "протянул" КПП предприятия в накладную (т.е. сохранял бы значение КПП в шапке накладной (CustInvoiceJour)). Т.к. код един для Cust- и Vend- таблиц - то возможно придется "протянуть" КПП еще и туда (по ходу выявится). После этого - необходимо ориентировать печатную форму накладной на это новое поле и джобиком обновить поле старым КПП в исторических данных ну а борьба с размером таблицы - верно, это уже совершенно другой разговор CustInvoiceJour, к примеру, у нас одна из проблемных в данный момент. Спасибо, парни, многое для себя узнал
__________________
..в каждой программе есть хотя бы одна ошибка.. |
|
25.12.2009, 17:16 | #16 |
Участник
|
Цитата:
Офф-топ:
Прикольный аватар по смыслу. Только англ. неправильный. Разве только если это специально, как ребенок говорит
__________________
..в каждой программе есть хотя бы одна ошибка.. |
|
25.12.2009, 18:32 | #17 |
Участник
|
Цитата:
Сообщение от mazzy
Это бухгалтерский подход.
С точки зрения производственных заданий, управления складом имеет смысл формировать документы с верным реквизитом в зависимости от даты И ВРЕМЕНИ. А с точки зрения управления производственными заданиями (MESA) имеет смысл детализация до дробных частей секунды. правильным является подход: 4) записывать КПП (ИНН и прочие реквизиты непосредственно в документ) так, чтобы в любой момент можно было печатать документ не обращаясь к другим справочникам. Я не зря написал "формировать документы" - т.е. ПЕРВИЧНОЕ заполнение ПОЛЕЙ в документе, в той же накладной. А про "задним числом" - почему сразу мысли про прошлый период? Сегодня поменяли КПП, завтра формируем накладную за позавчера (в рамках одного периода) - стандартный подход подставит последнее значение КПП, а не историческое.
__________________
Ivanhoe as is.. |
|
25.12.2009, 18:38 | #18 |
Участник
|
Цитата:
Сообщение от Ivanhoe
Если мы говорим про ИНН / КПП то у них есть понятие "время"? Прямо в документе, полученном в госоргане написано, что они действуют с 13:00?? Речь шла именно про них, а не про произвольные реквизиты!!! Mazzy, сами же не любите универсальных решений - не надо их искать у других
Я не зря написал "формировать документы" - т.е. ПЕРВИЧНОЕ заполнение ПОЛЕЙ в документе, в той же накладной. Цитата:
Поэтому "прошлы период" можно установить и запретить на дату изменения КПП Автор про это спрашивал. По-моему. |
|
Теги |
как правильно, периодические значения, полезное, crm2011 |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|