Предв. просмотр проводок в закупке/заказе

[sparur]

Народ, собсно сабж!

Кто нить реализовывал?? подкиньте идейку в какую сторону рыть...
Сделать в принципе надо по образу и подобию Общего журнала в ГК, однако что-то стопорнулся...

Класс отвечающий за разноску накладных вроде как purchFormLetter_Invoice... Однако какой-то он замудренный... Сам объект класса вроде в форме PurchTable висит, однако в форме PurchEditLines (обработка накладной) он как то тож юзается, а потом снова передается в форму закупки и уже там вполняется метод run(). Вообщем, не очень понятна логика работы этого класса и как его привязать к форме для предварительного просмотра...

[Roman777]

Есть инструмент "Прогноз движения средств" в закупках / заказах в кнопке запросов. Может устроит?

[sparur]

не, не пойдет... надо сделать по информативней

[BOAL]

так же как и в гк и печати накладной без разноски - разносить, но не закрывать транзакцию, а вывести в форму результат.

[sparur]

Quote:

Originally Posted by BOAL

так же как и в гк и печати накладной без разноски - разносить, но не закрывать транзакцию, а вывести в форму результат.

общий механизм известен... не ясны некоторые нюансы, в частности работа класса по разноске Закупки/Заказа...

[Roman777]

Quote:

Originally Posted by sparur

общий механизм известен... не ясны некоторые нюансы, в частности работа класса по разноске Закупки/Заказа...

Вот пожалуйста направление, по которому нужно копать:

PHP Code:

static void Job23(Args _args)
{
    purchFormLetter     purchFormLetter;
    VendInvoiceJour     invoiceJour;
    PurchTable          purchTable;
    ;

    ttsbegin;
    purchTable = purchTable::find("00000188_073");
    purchFormLetter = purchFormLetter::construct(DocumentStatus::Invoice);
    purchFormLetter.transDate(01\09\2006);
    purchFormLetter.update(purchTable, "");

    while select invoiceJour
        where invoiceJour.PurchId == purchTable.PurchId
    {
        Info(strfmt("%1", invoiceJour.InvoiceAmount));
    }

    ttsabort;
} 


Идея, я думаю, ясна.

[sparur]

Quote:

Originally Posted by Roman777

Идея, я думаю, ясна.

гм...
А как же вспомогательные таблицы которые используются в классе purchFormLetter_Invoice (PurchParmUpdate, PurchParmTable, PurchParmLine) ??
Я так понял они тоже играют свою существенную роль... Разву их не нужно учитывать?? да и метод update... А как же run() и все что там завязано в нем?

[mazzy]

Quote:

Originally Posted by sparur

не, не пойдет... надо сделать по информативней

а зря.
это и есть будущие проводки. только неоткореспондированные.

[sparur]

Quote:

Originally Posted by mazzy

а зря.
это и есть будущие проводки. только неоткореспондированные.

блин ну может оно и так... однако задача уже поставлена и ее надо решать... И сделать надо по аналогии с предв. просмотром в общем журнале... Подобная задача уже решена на складских журналах. Однако в Закупке/Заказе все усложняется тем, что непонятна (пока) логика класса по разноске...и как его использовать...

[mazzy]

Quote:

Originally Posted by sparur

И сделать надо по аналогии с предв. просмотром в общем журнале...

Не надо использовать эту фичу в качестве образца.
Она сделана в рамках локализации.

Суть фичи в общем журнале:
1. начинается транзакция
2. выполняются обычные проводки обычным алгоритмом (все проводки)
3. выполняется печать финансовых проводок
4. транзакция принудительно откатывается

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

Но такой подход еще терпим, если используется журнал ГК (поскольку в нем не создаются складские проводки и не выполняется сопоставление)

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

[sparur]

Quote:

Originally Posted by mazzy

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

Да это не есть хорошо... Однако в фиче "Прогноз движения средств" все очень ограничено... Нет, как вы и сказали, корр.счетов, нет аналитики никакой...

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

[Михаил Андреев]

М-да. Некислая задача. Интересно, что в голове у заказчика такой задачи.
По сути: самый безопасный вариант - доработать прогноз движения средств. Мало шансов что-то важное сломать. А ковыряние классов purchFormLetter* более чем опасно - очень сложные они и баги замучаетесь выковыривать.
Сугубо моё личное мнение.

[glibs]

Quote:

Originally Posted by sparur

...
нет аналитики никакой
...

Никакой может и нет, а финансовая точно есть. Вам какую надо?

"Существенно дорабатывать" заключается только в прикручивании корреспонденции?

[sparur]

Quote:

Originally Posted by glibs

Никакой может и нет, а финансовая точно есть. Вам какую надо?

"Существенно дорабатывать" заключается только в прикручивании корреспонденции?

или я что то не догоняю или у меня урезана эта фича... НО ни финансовой, ни тем более складской аналитики НЕТ там

[sparur]

Quote:

Originally Posted by Михаил Андреев

М-да. Некислая задача. Интересно, что в голове у заказчика такой задачи.
По сути: самый безопасный вариант - доработать прогноз движения средств. Мало шансов что-то важное сломать. А ковыряние классов purchFormLetter* более чем опасно - очень сложные они и баги замучаетесь выковыривать.
Сугубо моё личное мнение.

уже склоняюсь к варианту доработки прогноза... НО пока еще не окончательно определился...

[glibs]

Quote:

Originally Posted by sparur

...
НО ни финансовой
...

Финансовая есть. Она не отображается в интерфейсе. Но она есть. Посмотрите через паспорт записи.

Добавление ее в интерфейс — несложная задача даже для консультанта... ну по крайней мере моего поколения, которым для сдачи GNAD нужно было знать на память и не путать типы join и виды relations, которые есть в АОТ (а также кучу аналогичных вещей).

Quote:

Originally Posted by sparur

...
ни тем более складской аналитики НЕТ там
...

В проводках по ГК то? А где она в них есть, не подскажете?

[sparur]

Quote:

Originally Posted by glibs

Финансовая есть. Она не отображается в интерфейсе. Но она есть. Посмотрите через паспорт записи.

Добавление ее в интерфейс — несложная задача даже для консультанта... ну по крайней мере моего поколения, которым для сдачи GNAD нужно было знать на память и не путать типы join и виды relations, которые есть в АОТ (а также кучу аналогичных вещей).

В проводках по ГК то? А где она в них есть, не подскажете?

в проводках по ГК то конешно ее нет, но она есть в строках закупки, и ее желательно бы тоже отобразить... Но я думаю это не критично, так что забудем...
Вообщем надо пытаться прикрутить корреспонденцию и найти таки фин аналитику...

[ppson]

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

[sparur]

Quote:

Originally Posted by ppson

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

вот те на... это совсем плохо если так обстоит... необходимо именно просмотр проводок накладной!!! то есть если в накладной будет 1 строка из 5-ти что в закупке, то и просмотр должен показать будущие проводки именно по этой одной строке...
Так что, неужели вариант с прогнозом отпадает?

[Nick]

Не понимаю, чем вас не устраивает вариант описанный Mazzy?
Только вместо печати выводить проводки во временную таблицу, как при предварительном просмотре в журналах.