Почему 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 спасет.

[ZVV]

Цитата:

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

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

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

Да, действительно недоработка...

[lev]

Цитата:

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

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

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

[lev]

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

[glibs]

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

[glibs]

Цитата:

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

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

А вы так не делайте.

[lev]

Цитата:

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

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

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

[Logger]

Цитата:

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

А вы так не делайте.

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

Но по-моему, это искуственное ограничение, вызванное особенностями структуры данных в Аксапте. В реальной жизни ничего не должно препятствовать иметь второй документ за дату с тем же номером. Т.е. invoiceId + transdate не должно быть ключом.

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

[ZVV]

Цитата:

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

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

Почему же...

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

[glibs]

Цитата:

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

...
Но по-моему, это ... ограничение, вызванное особенностями структуры данных в Аксапте.
...

Да. Просто ограничение.

Цитата:

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

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

Я решал такую задачу доработкой в виде ссылки накладной на другую накладную (неправильную). С печатью соответствующего номера. Но это для официальной первички. Не для реального учета.

[lev]

Цитата:

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

Почему же...

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

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

[glibs]

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

[lev]

Цитата:

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

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

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

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

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

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

Никто не говорил о том нравиться или не нравиться. И никто никого не упрекал, что сделано так или не так. Просто возник данный вопрос, на который хотелось услышать ответ. Скорее всего сделали не просто так, а по какой то причине.
Если вам эта причина не известна, не надо переходить на личности. То что мне нравиться или нет это уже мои проблемы.