Почему CustInvoiceTable лишили Voucher -а ?

[Logger]

Собственно, сабж...
С удивлением обнаружил что там нет Voucher-а

Хотя везде в системе он в документах есть. Это вроде бы как основной идентификатор документа в системе. Даже в переносе, который не делает никаких проводок по ГК есть ваучер. И CustInvoiceJour который создается на основе CustInvoiceTable естественно тоже есть LedgerVoucher и он заполняется в момент разноски. Более того в момент разноски из CustInvoiceJour-а в CustInvoiceTable переносится InvoiceId - почему бы то же самое не сделать с документом ГК - (выделяются они в паре, а переносится только InvoiceId)?

Поковырял код - судя по коду роль ваучера играет InvoiceId
Даже уникальность его внутри даты проверятеся.
Непонятно зачем, правда

Ax 3.0 SP5

[glibs]

В заказах и закупках нет ваучера тоже. И в производственых заказах.

Не во всех журналах есть ваучер.

Не разделяю вашего удивления.

[mazzy]

Цитата:

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

Хотя везде в системе он в документах есть.

CustInvoiceTable - не документ, а черновик (журнал). Такой же как заказ и закупка, как правильно отметил glibs.

Цитата:

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

Поковырял код - судя по коду роль ваучера играет InvoiceId

Не совсем так.
InvoiceID играет роль кода заказа
В момент разноски в Voucher может копироваться этот invoiceID,
а может создаваться свой код.

Поведение зависит от галочки Наследование.


На скриншоте:
1. Номерная серия для нумерации Накладных на услуги (Free text invoice/Накладная с произвольным текстом)
2. Номерная серия для нумерации Voucher при разноске Накладных на услуги
3. Галочка "Наследование". Если включена, то Voucher принимает значение из номера накладной. Если выключена, то система генерит новый номер согласно номерной серии.

Обратите внимание, что в принципе у Накладных на услуги может быть своя номерная серия, отличная от Накладных, созданных по заказу продажи. Я обычно указываю одну и ту же номерную серию.

[Logger]

Спасибо за ответы.
Про черновики понятно.

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

А вот для строк складских журналов всегда возможен только один ваучер - вот он и пробивается при разноске (если не был прописано при создании). При том что строки - это тоже черновик. Т.е. система смотрит не на то - является ли строка или шапка черновиком, а на однозначность соответствия.

В накладных на услуги мне не нравится именно неоднозначность из-за отсутствия ваучера. По идее если у нас есть накладная на услуги CustInvoiceTable, то по ней возможна лишь одна запись в CustInvoiceJour. (в отличие от заказов и закупок, где накладных может быть несколько) Поэтому в CustInvoiceTable напрашивается ваучер.

Без него по конкретной CustInvoiceJour метод
\Data Dictionary\Tables\CustInvoiceJour\Methods\custInvoiceTable

CustInvoiceTable custInvoiceTable(boolean _update = false)
{
    CustInvoiceTable custInvoiceTable;
    ;
    custInvoiceTable.selectForUpdate(_update);

    select custInvoiceTable
        where custInvoiceTable.invoiceId            == this.invoiceId            &&
              custInvoiceTable.invoiceDate          == this.invoiceDate          &&
              custInvoiceTable.numberSequenceGroup  == this.numberSequenceGroup;

    return custInvoiceTable;
}

может вернуть как правильный CustInvoiceTable - так и левый, у которого по несчастливой случайности номер совпал.

[lev]

Цитата:

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

может вернуть как правильный CustInvoiceTable - так и левый, у которого по несчастливой случайности номер совпал.

у меня часто встречались случаи когда для двух разных поставщиков создавались накладные с одним и тем же номером, в одной и той же дате

[Logger]

Цитата:

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

у меня часто встречались случаи когда для двух разных поставщиков создавались накладные с одним и тем же номером, в одной и той же дате

Ну мне бы было не до смеха
И как лечили ?

[ZVV]

Цитата:

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

Ну мне бы было не до смеха
И как лечили ?

Может добавить в этот метод условие на клиента?
Насколько я понимаю, они не могут поменятся по пути от custInvoiceTable до custInvoiceJour?

[Logger]

Цитата:

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

Может добавить в этот метод условие на клиента?
Насколько я понимаю, они не могут поменятся по пути от custInvoiceTable до custInvoiceJour?

Не могут. Но не всегда и это спасет.
На одном проекте народ любил накладные на услуги сторнировать. и проводить снова с тем же InvoiceId.

В таком случае только Voucher спасет.

[lev]

Цитата:

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

Ну мне бы было не до смеха
И как лечили ?

Нужно на проблемы жизни смотреть с оптимизмом
Все поиски накладной делали в разрезе поставщика\клиента, даты накладной, номера накладной, и группы номерных серий.

[lev]

Попутно назрел такой вопрос. Вот интересно почему в таблицах VendInvoiceJour и CustInvoiceJour не сделали записи уникальными в разрезе Поставщика\Клиента, Номера накладной, Даты накладной, и Группы номерных серий?
Есть ли у кого какие соображения?

[glibs]

В параметрах РП есть контроль по Поставщик - Номер накладной - Дата накладной. Посмотрите там варианты.

[lev]

Цитата:

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

В параметрах РП есть контроль по Поставщик - Номер накладной - Дата накладной. Посмотрите там варианты.

Ax 3.0 SP3 Не увидел такого...

[ZVV]

Цитата:

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

Ax 3.0 SP3 Не увидел такого...

Почему же...

Пареметры РП - Обновления - Проверка использования номера накладной

[lev]

Цитата:

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

Почему же...

Пареметры РП - Обновления - Проверка использования номера накладной

Ну поле то есть, а в нем только параметры типа: "Разрешать дубликаты", "Запрещать дубликаты" и т.п. А по поводу в каком разрезе эта уникальность должна быть, ничего нету по идее конечно это рулиться индексом, но в стандарте на шапках накладных уникальных индексов нет, а сейчас добавлять их уже поздно.
Вот мне и интересно почему сделали такую структуру данных.

[glibs]

Цитата:

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

...
А по поводу в каком разрезе эта уникальность должна быть, ничего нету
...

Читайте между строк. Либо в пределах финансового года и поставщика, либо в пределах поставщика.

Цитата:

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

...
Вот мне и интересно почему сделали такую структуру данных.
...

Ну, не догадались, что она вам не понравится, и сделали.

Сравните поля, которые вы предлагаете в индекс с той проверкой, которая реализована в параметрах. Разницу видите?

Наверное, у них была цель сделать то, что они сделали, а не то, чего вам хочется.

Скажете, что стандартная проверка не логична? Ну или ваше логичнее ее? С прикладной точки зрения.

[glibs]

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

.

Давайте я выдвину такую гипотезу.

Сидели братья Дамгарды. Сделали журнал накладных. Ну вот с составным ключем, да еще и неявным (не описанном в БД). Потом придумали проверку (описана выше). Осознание потребности в уникальности по описанным выше четырем полям у них в голове не возникло.

"Не было причины сделать — не сделали". Сгодится в качестве причины?

[lev]

Цитата:

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

"Не было причины сделать — не сделали". Сгодится в качестве причины?

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