Счёт-фактуры из накладных

[LCh]

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

Проблема возникает, когда по закупке оформлено две накладных (скажем, по какой-то из строк закупки в обеих накладных проводится одно и то же количество), в результате чего появляется две строки в InventTrans с разным PackingSlipId и одинаковым Qty. При оформлении счёт-фактуры невозможно определить, какую строчку из InventTrans выберет система.

Надо как-то заставить систему выбирать только нужные строки в InventTrans или как-то ненужные на время блокировать (что не желательно по известным причинам).

Форма, которая даёт возможность указать строки для фактурирования в разрезе накладной, есть.

[macklakov]

Большая просьба, указывайте версию axapta :-)
В 2.5 мы сделали так: при создании счета-фактуры выбирается номер накладной, на основании которой он выписывается. Пришлось писать ручками, но теперь пользователи работают быстрее и делают гораздо меньше ошибок, бухгалтерия счастлива :-)

[LCh]

Цитата:

Изначально опубликовано macklakov
Большая просьба, указывайте версию axapta :-)
В 2.5 мы сделали так: при создании счета-фактуры выбирается номер накладной, на основании которой он выписывается. Пришлось писать ручками, но теперь пользователи работают быстрее и делают гораздо меньше ошибок, бухгалтерия счастлива :-)

Версия 2.5, SP3. А в каком смысле - выбирается номер накладной? Где? Как? Стандартный функционал где-то есть? Быть может, PFL_Invoice может строится на основе накладной? Я не могу понять.

[macklakov]

Нет, функционал не стандартный, в форму SalesEditLines добавлено поле, соответственно перебиты классы формирования SalesParmLine. Закупки полностью симметричны заказам, так что решение применимо и к ним.

[LCh]

Цитата:

Изначально опубликовано macklakov
Нет, функционал не стандартный, в форму SalesEditLines добавлено поле, соответственно перебиты классы формирования SalesParmLine. Закупки полностью симметричны заказам, так что решение применимо и к ним.

Насколько я понимаю, Purch(Sales)ParmLine собирает фактически только строки из закупок и количество к обработке. Нам же требуется, чтобы потом система на основе этих строк искала записи в InventTrans только по определённой накладной.

[macklakov]

В PurchFormLetter_Invoice перебей updateNow

[Wamr]

стандартно Аксапта такого не поддерживает

ну изменили updateNow()..
потом захотели проформу..
потом кредит-ноту
потом возврат
и все, заметьте, по накладной..

советую рассмотреть все предстоящие изменения в системе для работы "по накладной", разобраться в механизмах формирования накладных, счетов, счетов-фактур (PurchFormLetter_XXX), изменения проводок (InventUpd_XXX) и т.д. и т.п.

СЕМЬ раз отмерь - один отрежь

[mazzy]

Цитата:

Изначально опубликовано LCh
Требуется оформлять счёт-фактуры на основе накладных. То есть, в InventTrans должны использоваться строки только с определённым номером накладной.

Здесь логическая дыра. В InventTrans не бывает ссылок на накладную.
Кроме того, InventTrans с одинаковым InventTransID могут суммироваться и разделяться. Как автоматически так и вручную.

Ссылка на накладную есть в CustInvoiceJournal.

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

Таким образом, как можно сделать то, что вы хотите при помощи стандартного функционала? Заполняете в заказе колонку Немедленная поставка тем, количеством, которое указано в накладной. Затем создаете счет-фактуру с фильтром немедленная поставка. Долго? Вручную неудобно? Зато делается без модификаций функционала.

Теперь настало время автоматизации. Создайте кнопку, которая автоматически заполняет колонку Немедленная поставка из накладной. Затем пусть пользователь создает СФ по этой колонке.

Хочется упростить действия пользователя еще? Пусть эта кнопка заполняет колонку и открывает форму создания СФ и пусть сама же устанавливает фильтр.

Не изменяйте функционал. Только добавляйте.
Старайтесь поменьше программировать.
А самое главное - никогда не платите абоненсткой платы...

[macklakov]

2 mazzy
Я конечно дико извиняюсь, но позвольте с Вами не согласиться в следующем:
1. в InventTrans есть поле PackingSlipId.
2. в Вашем варианте по немедленной поставке в с.ф. может попасть товар с неправильной складской аналитикой (к примеру ГТД) или конфигурацией

[mazzy]

Цитата:

Изначально опубликовано macklakov
1. в InventTrans есть поле PackingSlipId.

PackingSlipID в российской версии не накладная, а отборочная накладная.
В российской версии накладная - это Invoice.
Т.е. вашу задачу это поле не решает

Цитата:

Изначально опубликовано macklakov
2. в Вашем варианте по немедленной поставке в с.ф. может попасть товар с неправильной складской аналитикой (к примеру ГТД) или конфигурацией

товарищ гроссмейстер, вам мат. (С)...

а ведь правильно. Надо подумать.

[glibs]

Цитата:

Изначально опубликовано LCh
...
То есть, в InventTrans должны использоваться строки только с определённым номером накладной
...
Надо как-то заставить систему выбирать только нужные строки в InventTrans или как-то ненужные на время блокировать (что не желательно по известным причинам)
...

Вы бы лучше русским языком объяснили попонятней, что именно вам нужно, а не всякие там InventTrans.

Цитата:

Изначально опубликовано LCh
...Требуется оформлять счёт-фактуры на основе накладных...

Не уверен, что правильно понял суть вопроса, но не это ли вы ищете?

"Расчеты с поставщиками\Запросы\Журналы\Накладная", потом кнопочка "Обработка счета-фактуры".

Или суть иенно в InventTrans?

[mazzy]

Был неправ. Вместо PacingSlipID вполне можно использовать InvoiceID...
И все же, стоит воздержаться от программирования.

У glibs'а было предложение по обработке Сф из журнала накладных.
Не подходит?

[Wamr]

Как я понял, в данном вопросе (2.5sp3)
накладная - PackingSlip
счет-фактура - Invoice

Вот такой текст нашелся в Руководстве пользователя по логистики для заказаов

Цитата:

В случае отгрузки или проводки фактуры система обрабатывает строки данной формы по принципу ФИФО....
Это надо иметь в виду при работе с разными складами. Допустим, вы заказали по строке 10 единиц товара, из них 3 по одному складу и 7 по другому, и провели отгрузку двух партий товара с разных складов по одной единице. Тогда вам не удастся провести 1 единицу по бухгалтерии из второй отгрузки, которая значится последней в списке проводок. Прежде следует целиком провести первую отгрузку.

Аналогичная ситуация с закупками

[glibs]

Цитата:

Изначально опубликовано Wamr
...Как я понял, в данном вопросе (2.5sp3)
накладная - PackingSlip
счет-фактура - Invoice...

Упс... а ведь точно. Прошу прощения. Виноват. Я тоже повелся... Даже не могу вспомнить на что были похожи российские фактуры до СП4.

Wamr прав. Invoice и Packing slip никак не связаны. Более того, по одному, двум, трем и более Packing slip может формироваться один Invoice. По идее, можно и наоборот. Причем такое возможно не только на Западе, но и у нас. А еще один Invoice может выставляться за несколько закупок.

Наша "накладная" выполняет функции и Packing slip и Invoice. Т.е. на основании этого одного документа в системе регистрируются две операции: сначала физический приход (кладовщиком), потом признание задолженности и пр. (менеджером по закупкам).

В общем, отсутствие связи между этими вещами задумано на идеологическом уровне...

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

[LCh]

Я ошибся - Axapta стоит с SP2, а не SP3, поэтому кнопки обработать->счёт-фактура в журнале накладных нет. =\

Вот решение.
Задача была следующая (давайте по порядку):

В отделе бухгалтерии Х счёт-фаткура (InvoiceId) выписывается на основе накладной (PackingSlipId). И накладные и счёт-фактуры формируются суммарной обработкой - это не так важно.

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

Проблема в том, что стандартная обработка счёт-фактуры делает выборку строк из InventTrans только по статусу и закупке, не учитывая PackingSlipId (и это нормально).

Зачем нам это надо - нам надо соответсвие, сколько по закупке оприходовано, и сколько в разрезе накладной отфактурировано (и цена, и количество). Такую возможность даёт только InventTrans, где есть соответствие InvoiceId - PackingSlipId (которое, правда, не поддерживается).

macklakov посоветовал совершенно верно - берём за рога PFL_Invoice, и меняем. Но оказалось, что всё сводится к работе на пару минут - в классе InventUpd_Invoice в методе updateFinancialReceipt в строках while select InventTrans добавляем условие && InventTrans.PackingSlipId == _нашPackingSlipId. Остаётся только донести _нашPackingSlipId до метода (всего три вызова).

Способ безопасный, везде в методах, куда передаётся PackingSlipId, навешено значение по умолчанию. Сторно, кредит-ноты и т.п. не взбунтуют.

Всем спасибо!

[Wamr]

Предлагаю такой тест
1. Создать 2 накладные по закупке
2. По второй накладной провести сторно/кредит-нота
3. Отфактуровать 1ую накладную

[LCh]

Цитата:

Изначально опубликовано Wamr
Предлагаю такой тест
1. Создать 2 накладные по закупке
2. По второй накладной провести сторно/кредит-нота
3. Отфактуровать 1ую накладную

Прав. Облом понял. Видимо, кредит-ноту и сторно придётся изменить сделать. Но тут нам "повезло" - операции со сторно мы тоже переделывать будем, чтобы, например, указывалась накладная/сч.ф., и по всем строкам в накладная/сч.ф. проводилось сторно (у нас куча информации сопроводительной идёт, так что обычный функционал не подойдёт).

Мне кажется, InventUpdate дело закончится, всё равно он while select InventTrans везде делает, везде можно дополнительное условие поставить. Изменения плёвые, всё же я за это решение.

[Wamr]

Согласен, что изменений немного, проблема только в том чтобы понять где и сколько Кстати, если соблюдать BP, то изменения станут посложней

Неплохо бы еще "родной" функционал проверить...

Для такой "плёвой" модификации нужен ХОРОШИЙ тестировщик.