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

[sparur]

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

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

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

[Roman777]

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

[sparur]

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

[mazzy]

Цитата:

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

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

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

[sparur]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

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

[Алексей Контев]

Цитата:

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

однако задача уже поставлена и ее надо решать...

А можно все-таки вопрос по необходимости подобной модификации.
Я еще понимаю ее необходимость в журналах ГК. Там при вводе сложных проводок пользователь не всегда может точно сказать, как они сгруппируются и какая корреспонденция получится.
Но в закупках? Это необходимо только на этапе тестирования системы (чтобы обучающийся пользователь (менеджер?) мог поиграть настройками, посмотреть проводки и понять, как они формируются)
В рабочей базе все должно быть уже настроено. Менеджер, вводящий закупку/заказ понятия не имеет о бух. счетах.
Он может управлять только профилем разноски и налоговыми группами, которые по идее лучше в заказах/закупках тоже не трогать, а настроить по-умолчанию в контрагентах/договорах.
А про просмотр проводок в заказах я вообще не говорю. При нормальной активной работе это не реально. (сделать можно, но ч/з 2-3 недели уже никто их смотреть не будет, т.к. поймут, что если правильно задать профиль и проверить суммы налога (для закупок), то все разнесется правильно.

[BOAL]

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

[sparur]

Цитата:

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

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

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

[Roman777]

Цитата:

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

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

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

PHP код:

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]

Цитата:

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

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

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

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

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

[sparur]

Цитата:

Сообщение от Михаил Андреев

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

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

[Nick]

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

[sparur]

Цитата:

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

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

1) его надо дорабатывать (аналитика, корресподенция)
2) появилось мнение что данный вариант работает ТОЛЬКО если делать накладную на всю закупку, если это так, то не подойдет скорее всего
3) о какой печати идет речь?

[Nick]

1) вывод как в стандартной форме "Проводки (ГК) по документу" вас устраивает?
2) если на форме "закупка" делать кнопку - то на всю будет, а если на форме "обработка накладной" - можно и на часть
3) п.3 у Маззи

[sparur]

Цитата:

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

1) вывод как в стандартной форме "Проводки (ГК) по документу" вас устраивает?
2) если на форме "закупка" делать кнопку - то на всю будет, а если на форме "обработка накладной" - можно и на часть
3) п.3 у Маззи

1) да, в принципе устраивает.но проблема, озвученная Маззи, беспокоит.
2) вообщем, так и не могу определиться в каком же виде лучше все реализовать

[Nick]

Если есть время попробуйте сделать оба
вариант через закупку в форму "Прводки по документу" у нас занял не больше одного рабочего дня

[sparur]

Цитата:

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

Если есть время попробуйте сделать оба
вариант через закупку в форму "Прводки по документу" у нас занял не больше одного рабочего дня

Веремени то как раз недостает....
О каком варианте идет речь?? что Вы имеете ввиду под вариантом в форму "Проводки по док-ту"?

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

P.S. кстати если есть время то можно озвучить примерный план действий...Я не обижусь...

[Nick]

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