Выписка накладной по нескольким заказам

[Андре]

SP2.

Данная фишка у кого-нибудь нормально работает. Попробовал - куча недоработок. Например цены не все печатаются стал разбираться набрел на следующий гениальный код:

PHP код:

//  Класс SalesPackingSlipLauncher_Ru
//  метод:   prepareDynamicLine()

    select firstonly salesLine
        where  salesLine.SalesId == custPackingSlipTrans.SalesID &&
               salesLine.LineNum == custPackingSlipTrans.LineNum &&
                  salesLine.ItemId  == custPackingSlipTrans.ItemId; 


Создал два заказа, в каждом по две строки. Соответственно этот код вызвается 4 раза - по 2 раза для каждого заказа. Однако вот эта вещь custPackingSlipTrans.SalesID всегда равна первому заказу. Ладно есть поле custPackingSlipTrans.origSalesId, которое вроде соответствует действительности.
Но есть еще одна проблема - SalesLine. Если посмотреть строки 2-х заказов, то в них salesLine = 1и 2 для одного заказа, и 1 и 2 для другого. Эта же величина custPackingSlipTrans.LineNum принимает значения от 0 до 3 последовательно. Это все баг ???
И собственно вопрос по существу. Если я выписываю накладную, но клавишу обработа не ставлю, то в таблицу custPackingSlipTrans ничего не попадает...
Где заполняется переменная custPackingSlipTrans ??? Объявлена она в этом же классе SalesPackingSlipLauncher_Ru. Но поиск по классу показал, что в методах только извлекаются значения из этой переменной, но нигде она не инициализируется.

Может кто поможет ?

Благодарю.

[Wamr]

Создание накладной по заказу всегда делалось в классе SalesFormLetter_PackingSlip..
или это какой-то другой процесс?

[Андре]

Хм. Отчет - SalesPurchPackingSlip_Ru. Он вовсю оперирует с такой штукой, как dynamicData. Этот dynamicData собственно формируется в классе SalesPackingSlipLauncher_Ru.

Хотя думаю, что указанный тобой класс тоже отрабатывает, но несколько раньше.

Мы говорим про один и тот же отчет - SalesPurchPackingSlip_Ru ?

[Wamr]

Я говорю, о том где создается накладная и соответственно её строки (CustPackingSlipTrans).
А ты, видимо, о том где результат печатается

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

[Андре]

Цитата:

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

Это надо обдумать. Спасибо.

[Wamr]

Можно попытаться выдрать кусок приложения связанный с печатью накладной из более поздних SP, если кто-дь подтвердит, что там эта проблема пофиксина.

[Андре]

Хм. В SP5 класс SalesPackingSlipLauncher_Ru вообще отсутствует.

[Андре]

Цитата:

Где заполняется переменная custPackingSlipTrans ???

Да. Спасибо. Нашел.

SalesFormLetter::main:

PHP код:

    if (salesFormLetter.prompt())
        salesFormLetter.run(); 


SalesFormLetter.run():

PHP код:

 if (salesSummary.createNewJournal(salesTable))
                    this.createJournal(); 


SalesFomrLetter.createJournal():

PHP код:

    if (proforma)
        this.insertProforma();
    else
        this.insertJournal(); 


А уже в этих методах вызываются методы initJournal, initJournalLine и writeJournalLine, где и заполняется эта переменная. Что здесь можно поправить я еще подумаю.

Но вопрос был не только в этом.

Цитата:

Изначально опубликованно Андре:
Это все баг ???

И все таки это баг ? Он признан Navision/Columbus или кто там за это отвечает ? Как все выходили из этого положения ? Неужели все сами разбирались и сами все для себя правили ? Подозревая, что на последний вопрос ответ будет - "да" спрошу: а это норамльная ситуация ? Неужели такие вещи ничем не регламентируются, неужели поставщик програмного продукта(конкретного, программного продукта) не обязан исправить все ошибки в своем программном обеспечении ?

[Wamr]

Да это баг.

О чем и говорит отсутствие этого класса (и этого кода в аналогичном классе) в SP5
Как я понимаю, исправление ошибок в SP нормальная практика для программных продуктов.

P.S.
Единственный верный способ связывать строки накладной и заказа InventTransId

[Андре]

Цитата:

Как я понимаю, исправление ошибок в SP нормальная практика для программных продуктов.

Обычное дело - бесплатно распространять sp, а Navision/Columbus берет за это деньги.

[mazzy]

Цитата:

Изначально опубликовано Wamr
Единственный верный способ связывать строки накладной и заказа InventTransId

Нет.

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

Будьте осторожны.

[Wamr]

Цитата:

Изначально опубликовано mazzy
Есть операции разделения и суммирования InventTransID

Есть операции разделения и суммирования InventTrans. При этом изменяется количество записей в таблице InventTrans, но все они имеют одинаковое значение InventTransId (Номер лота)

Цитата:

По одному InventTransID может быть выписано несколько накладных (тривиальный случай - накладная и кредит-нота).

Я говорил о поиске строки заказа по строке накладной, а не проводок. А все проводки по строке заказа будут иметь одинаковый номер лота (InventTransId), независимо от документа (накладная, счет)

Цитата:

По одной строчке накладной может быть создано несколько InventTransID.

Как?

[mazzy]

Цитата:

Изначально опубликовано Wamr
Есть операции разделения и суммирования InventTrans. При этом изменяется количество записей в таблице InventTrans, но все они имеют одинаковое значение InventTransId (Номер лота)

Ага. Я протормозил. В исходном постинге ты не говорил об однозначном соответствии. Виноват.

Цитата:

Изначально опубликовано Wamr
Я говорил о поиске строки заказа по строке накладной, а не проводок. А все проводки по строке заказа будут иметь одинаковый номер лота (InventTransId), независимо от документа (накладная, счет)

Не. Не согласен. А суммовая обработка?

Про заказ и складские строки. Насколько я помню, у меня были случаи, когда по одной строчке заказа было сформировано несколько InventTrans c разными InventTransID. Помнится, я сам удивилялся. Причиная была в кредит-нотамах и возвратах с возможностью пропуска складской аналитики. Когда выяснял причину, то еще напоролся на периодические заказы, но туда глубоко не рыл.

[Wamr]

Цитата:

Изначально опубликовано mazzy
Не. Не согласен. А суммовая обработка?

А суммовая обработка даст 2 строки в 1ом документе (с этого вся дискуссия и началась) каждая со своим номером лота

Цитата:

Про заказ и складские строки. Насколько я помню, у меня были случаи, когда по одной строчке заказа было сформировано несколько InventTrans c разными InventTransID. Помнится, я сам удивилялся. Причиная была в кредит-нотамах и возвратах с возможностью пропуска складской аналитики. Когда выяснял причину, то еще напоролся на периодические заказы, но туда глубоко не рыл.

Если InventTransId изменился, то как однозначно привязать проводку к строке заказа? (никак)
А ты не путаешь с InventDimId.. вот этот может как угодно меняться в рамках 1го InventTransId?

[mazzy]

могет быть. сумлеваюси. Но это давно было.
попробую и проверю. Спасибо на всякий случай.

[Андре]

Всем спасибо, все переделал.

А именно все документы по сбыту - накладная, счет-фактура и счет.

Реализовал так - в таблицы TmpReportInvoice_Ru и ей подобные добавил поле InventTransId куда из строки заказа в процессе формирования документов вытягивал это значение. При печати документов уже по InventTransId искал соответствующую строку в SalesLine и брал из нее соответствующую информацию.

Пока вроде все работает. Глюков не замечено.