18.10.2006, 14:30 | #1 |
Участник
|
Предв. просмотр проводок в закупке/заказе
Народ, собсно сабж!
Кто нить реализовывал?? подкиньте идейку в какую сторону рыть... Сделать в принципе надо по образу и подобию Общего журнала в ГК, однако что-то стопорнулся... Класс отвечающий за разноску накладных вроде как purchFormLetter_Invoice... Однако какой-то он замудренный... Сам объект класса вроде в форме PurchTable висит, однако в форме PurchEditLines (обработка накладной) он как то тож юзается, а потом снова передается в форму закупки и уже там вполняется метод run(). Вообщем, не очень понятна логика работы этого класса и как его привязать к форме для предварительного просмотра... |
|
18.10.2006, 14:42 | #2 |
NavAx
|
Есть инструмент "Прогноз движения средств" в закупках / заказах в кнопке запросов. Может устроит?
|
|
18.10.2006, 14:54 | #3 |
Участник
|
не, не пойдет... надо сделать по информативней
|
|
18.10.2006, 15:03 | #4 |
Участник
|
так же как и в гк и печати накладной без разноски - разносить, но не закрывать транзакцию, а вывести в форму результат.
|
|
18.10.2006, 15:08 | #5 |
Участник
|
|
|
18.10.2006, 15:13 | #6 |
NavAx
|
Цитата:
PHP код:
|
|
19.10.2006, 06:40 | #7 |
Участник
|
гм...
А как же вспомогательные таблицы которые используются в классе purchFormLetter_Invoice (PurchParmUpdate, PurchParmTable, PurchParmLine) ?? Я так понял они тоже играют свою существенную роль... Разву их не нужно учитывать?? да и метод update... А как же run() и все что там завязано в нем? |
|
19.10.2006, 07:23 | #8 |
Участник
|
а зря.
это и есть будущие проводки. только неоткореспондированные. |
|
19.10.2006, 07:35 | #9 |
Участник
|
блин ну может оно и так... однако задача уже поставлена и ее надо решать... И сделать надо по аналогии с предв. просмотром в общем журнале... Подобная задача уже решена на складских журналах. Однако в Закупке/Заказе все усложняется тем, что непонятна (пока) логика класса по разноске...и как его использовать...
|
|
19.10.2006, 07:45 | #10 |
Участник
|
Не надо использовать эту фичу в качестве образца.
Она сделана в рамках локализации. Суть фичи в общем журнале: 1. начинается транзакция 2. выполняются обычные проводки обычным алгоритмом (все проводки) 3. выполняется печать финансовых проводок 4. транзакция принудительно откатывается Как видите, сам подход ужасен. Такой подход приемлемо работает только если пользователей мало. Но такой подход еще терпим, если используется журнал ГК (поскольку в нем не создаются складские проводки и не выполняется сопоставление) Если вы повторите подобный подход в заказах/закупках, то псевдотранзакцией будет затронуто гораздо больше таблиц и на гораздо большее время. Если вас это не пугает - делайте по аналогии. |
|
19.10.2006, 08:17 | #11 |
Участник
|
Цитата:
Если использовать этот вариант, то он также требует существенной доработки, я думаю Вы это прекрасно понимаете... |
|
19.10.2006, 10:03 | #12 |
Участник
|
М-да. Некислая задача. Интересно, что в голове у заказчика такой задачи.
По сути: самый безопасный вариант - доработать прогноз движения средств. Мало шансов что-то важное сломать. А ковыряние классов purchFormLetter* более чем опасно - очень сложные они и баги замучаетесь выковыривать. Сугубо моё личное мнение. |
|
19.10.2006, 11:03 | #13 |
Member
|
Цитата:
Сообщение от sparur
...
нет аналитики никакой ... "Существенно дорабатывать" заключается только в прикручивании корреспонденции?
__________________
С уважением, glibs® |
|
19.10.2006, 11:56 | #14 |
Участник
|
|
|
19.10.2006, 12:02 | #15 |
Участник
|
Цитата:
Сообщение от Михаил Андреев
М-да. Некислая задача. Интересно, что в голове у заказчика такой задачи.
По сути: самый безопасный вариант - доработать прогноз движения средств. Мало шансов что-то важное сломать. А ковыряние классов purchFormLetter* более чем опасно - очень сложные они и баги замучаетесь выковыривать. Сугубо моё личное мнение. |
|
19.10.2006, 12:31 | #16 |
Member
|
Цитата:
Сообщение от sparur
...
НО ни финансовой ... Добавление ее в интерфейс — несложная задача даже для консультанта... ну по крайней мере моего поколения, которым для сдачи GNAD нужно было знать на память и не путать типы join и виды relations, которые есть в АОТ (а также кучу аналогичных вещей). Цитата:
Сообщение от sparur
...
ни тем более складской аналитики НЕТ там ...
__________________
С уважением, glibs® |
|
19.10.2006, 12:50 | #17 |
Участник
|
Цитата:
Сообщение от glibs
Финансовая есть. Она не отображается в интерфейсе. Но она есть. Посмотрите через паспорт записи.
Добавление ее в интерфейс — несложная задача даже для консультанта... ну по крайней мере моего поколения, которым для сдачи GNAD нужно было знать на память и не путать типы join и виды relations, которые есть в АОТ (а также кучу аналогичных вещей). В проводках по ГК то? А где она в них есть, не подскажете? Вообщем надо пытаться прикрутить корреспонденцию и найти таки фин аналитику... |
|
19.10.2006, 13:08 | #18 |
Участник
|
Добавлю свои небольшые замечания.
Прогноз движения средств показывает реальные суммы только в том случае, если вся закупка/заказ будет закрываться одной накладной. в общем случае этот механизм никак не является предварительным просмотром проводок, так как он никак не связан с обработкой накладной.
__________________
|
|
19.10.2006, 14:10 | #19 |
Участник
|
Цитата:
Сообщение от ppson
Добавлю свои небольшые замечания.
Прогноз движения средств показывает реальные суммы только в том случае, если вся закупка/заказ будет закрываться одной накладной. в общем случае этот механизм никак не является предварительным просмотром проводок, так как он никак не связан с обработкой накладной. Так что, неужели вариант с прогнозом отпадает? |
|
19.10.2006, 16:28 | #20 |
Участник
|
Не понимаю, чем вас не устраивает вариант описанный Mazzy?
Только вместо печати выводить проводки во временную таблицу, как при предварительном просмотре в журналах. |
|
|
|