Обработка накладной по закупке по 2 и более профилям разноски

[Buba]

Axapta 3.0, SP3
Стандартный функционал закупки позволяет указать только один профиль разноски по поставщику. Получая от поставщика товарную накладную, имеем в ее строках позиции, расчеты за которые должны учитываться на разных субсчетах 60.ххх.
До сих пор это достигалось путем обработки по закупке двух и более накладных, для которых в "шапке" закупки каждый раз указывался требуемый профиль разноски.
Сейчас возникло требование: 1 товарная накладная (твердая копия) - 1 накладная в системе.
Как решение попробовали подставить в строки закупки поле "профиль разноски" и в соответственно в классе разноске "подсовывать" уже эти значения, без изменения общей логики. Однако это не дало ожидаемого результата.

Кто-нибудь сталкивался с такой задачей?
Какими могут быть альтернативные "перелапачиванию логики разноски" способы решения задачи?

[EVGL]

Избавиться от субсчетов изменением учетной политики?

P.S. Еще вариант: если отношения с поставщиком нормальные и тот - не монополист, которому все до лампочки, то можно заставить его выставлять по несколько накладных. Мои клиенты, например, встают на задние лапки перед своими клиентами и выставляют, например, отдельные счета за транспортные услуги, если требуется.

[lev]

Quote:

Originally Posted by Buba

Axapta 3.0, SP3
Стандартный функционал закупки позволяет указать только один профиль разноски по поставщику. Получая от поставщика товарную накладную, имеем в ее строках позиции, расчеты за которые должны учитываться на разных субсчетах 60.ххх.
До сих пор это достигалось путем обработки по закупке двух и более накладных, для которых в "шапке" закупки каждый раз указывался требуемый профиль разноски.
Сейчас возникло требование: 1 товарная накладная (твердая копия) - 1 накладная в системе.
Как решение попробовали подставить в строки закупки поле "профиль разноски" и в соответственно в классе разноске "подсовывать" уже эти значения, без изменения общей логики. Однако это не дало ожидаемого результата.

Кто-нибудь сталкивался с такой задачей?
Какими могут быть альтернативные "перелапачиванию логики разноски" способы решения задачи?

Насколько я знаю можно по нескольким закупкам разнести одну накладную

[EVGL]

Quote:

Originally Posted by lev

Насколько я знаю можно по нескольким закупкам разнести одну накладную

И что? Разве у одной накладной может быть два заголовка и две строки VendTrans? Исключено.

[lev]

Quote:

Originally Posted by EVGL

И что? Разве у одной накладной может быть два заголовка и две строки VendTrans? Исключено.

У наклодной заголовок будет один, да и строки в VendTrans будут в единичном экземпляре просто в накладную попадут строки из двух закупок и в итоге получится на одну бумажную накладную, одна фин накладная в системе.

Вот выдержка из документации по Торговле и логистике Ах 3.0:

Quote:

Суммарная обработка
Во всех ситуациях, разобранных выше, мы имели дело с одной закупкой. Однако система позволяет обрабатывать несколько закупок сразу, и при этом (что главное) формировать сводную документацию. Забегая вперед, укажем, что суммарная обработка может осуществляться в полуавтоматическом режиме (с вводом ведущей закупки) и в автоматическом режиме. Рассмотрим сначала суммарную обработку в полуавтоматическом режиме.

Как настроить критерии суммарной обработки
1. Откройте форму Параметры модуля Расчеты с поставщиками (пункт Расчеты с
поставщиками/Настройки/Параметры главного меню).

2. Перейдите на вкладку Суммарная обработка. Нажмите кнопку Параметры суммарной
обработки для вызова одноименной формы, в которой задаются критерии суммирования закупок.

3. Форма состоит из пяти вкладок по числу документов, оформляемых по закупке: Заявка, Счет на оплату, Акт приемки, Отборочная накладная и Накладная. По умолчанию для каждого документа выбрано два критерия совместной обработки: Валюта и Счет на. Дело в том, что суммарная обработка закупок, выраженных в разных валютах или относящихся к разным поставщикам, невозможна по определению. Нельзя выставить суммарный счет двум разным поставщикам в разной валюте.

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

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

Как активизировать полуавтоматическую суммарную обработку
1. В форме Закупки выберите несколько закупок с помощью левой клавиши мыши.

2. Нажмите кнопку Обработка и выберите тип документа, который будет сформирован в ходе суммарной обработки закупок. Перейдите на вкладку Прочее. Нас интересует одноименное поле Суммарная обработка, в котором задается режим суммарной обработки. Значение по умолчанию этого поля определяется параметром Суммарная обработка модуля РАСЧЕТЫ С ПОСТАВЩИКАМИ.

4. Выберите в поле Суммарная обработка опцию Счет на, если Вы хотите сформировать обобщенные документы по каждому поставщику (и валюте), сопоставив их первой попавшейся закупке у соответствующего поставщика. Если Вы собираетесь отнести итоговый документ определенной закупке, выберите опцию Заказ и укажите код «главной» закупки в появившемся поле.

5. Нажмите кнопку ОК. Первым делом система разбивает закупки по сочетаниям поставщика и валюты. Далее выполняется проверка закупок на предмет соответствия опциональным критериям суммарной обработки:
• в режиме Счет на, если у закупок совпадают коды поставщика и валюты, но не
совпадают значения полей, выбранных в качестве дополнительных критериев
суммирования, система выдает сообщение об ошибке.
• в режиме Заказ, если коды поставщика и валюты не совпадают, выдается сообщение об ошибке. Если поставщик и валюта во всех выбранных закупках одинаковые, но проверка по дополнительным критериям не прошла, система, в зависимости от параметра Проверка ошибок модуля РАСЧЕТЫ С ПОСТАВЩИКАМИ, переходит к суммированию документов, выдает предупреждение или информирует пользователя об ошибке.

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

7. Просмотреть документ по кнопке Запрос можно, обратившись к «главной» закупке. С «подчиненными» закупкам документ напрямую не связан. Для того чтобы найти документ, включающий в себя номенклатуру и суммы «подчиненной» закупки, обратитесь к вкладке Проводки. В поле Объединено система фиксирует код «главной» закупки, которой сопоставлен объединенный документ.

Возможно эта документация устарела и я не прав! Или я чего то недопонимаю. Тогда поправьте меня, буду только рад.

[EVGL]

Боюсь, что недопонимаете. Они не дебетовые счета разбивают (они и так разбиты, наверное), а кредитовые! 60 - это задолженность перед поставщиком в России. Т.е. одна накладная - две или более кредиторских задолженностей.

[lev]

Quote:

Originally Posted by EVGL

Боюсь, что недопонимаете. Они не дебетовые счета разбивают (они и так разбиты, наверное), а кредитовые! 60 - это задолженность перед поставщиком в России. Т.е. одна накладная - две или более кредиторских задолженностей.

ааа, тогда я не правильно понял суть задачи топик стартера, сорри

сасибо EVGL

[Alexius]

Наиболее безболезненно мне кажется создать новое понятие "Мастер-накладная", которая будет равна "твердой копии" и состоять из нескольких обычных. При разноске накладной необходимо сделать ее формирование и разноску нужного кол-ва обычных накладных, сгруппированных по профилю разноски, проставленному в строках. Сформировать одну фактуру по "Мастер-накладной" не проблема. Кажется это не должно привести к серьезным доработкам. Дополнительно можно попробовать объединить и старые накладные.

PS. При варианте "развала" проводки по поставщику нужно много думать

[UNRW]

Было дело, 7 лет назад на AX 3.0 делал модификацию - профиль разноски ставился в строках накладных, помню что разносилось все 1 операцией, но не помню сколько накладных создавалось по поставщикам.
Заняло 8 часов работы.

[d&m]

Quote:

Originally Posted by UNRW

делал модификацию - профиль разноски ставился в строках накладных
.

ммм достаточно странно, так как при разноске накладной делается один VendTrans, а по одному VendTrans - одна проводка в ГК по счету поставщика (из профиля разноски - к примеру, 60ый счет).

к чему я клоню: бессмысленно просто добавить профиль разноски в строку накладной. либо тогда нужно делать несколько vendTrans-ов под каждую накладуню с соответсвтующим кол-вом проводок в ГК по 60ому счету - а это уже далеко не 8 часов...

также добавлю, что в 2009 версии можно ставить разные прифили разноски в строках, на только при разноске строки все равно группируются по профилю разноски. Т.е. в итоге: 1 профиль разноски -> 1 накладная -> 1 vendtrans -> 1 проводка в ГК по счету поставщика

[TasmanianDevil]

UNRW, разноску Voucher'ов, действующих в PurchFormLetter_Invoice переписывали с жестким указанием корреспонденции ?
Изначально там корреспонденции нет, она запускается в самоем конце, когда уже есть следующие неоткорреспондированные проводки :

• Самая "жирная" кредитовая проводка в ГК по задолженности перед поставщиком
• От 1 до N дебетовых проводок ГК по движению номенклатуры
• От 1 до N дебетовых проводок ГК по налогам

В случае простого деления первого пункта на N частей (грешен, издевался таким образом над системой) у механизма корреспонденции напрочь сносит башню

[Buba]

Quote:

Originally Posted by d&m

ммм достаточно странно, так как при разноске накладной делается один VendTrans, а по одному VendTrans - одна проводка в ГК по счету поставщика (из профиля разноски - к примеру, 60ый счет).
...

Для решения задачи было бы приемлемо 1 накладная (твердая копия) - N накладных в системе (VendTrans), но на одном документе ГК.
Но тут опять же без глубокой проработки механизма разноски возникает проблема корреспонденции.

Quote:

Originally Posted by TasmanianDevil

...у механизма корреспонденции напрочь сносит башню...

[jays]

Buba, в DAX2009 SP1 RU3 появилась новая склад.аналитика - Профиль учета. Добавилась возможность задавать соответствие "Профиль учета - Профиль разноски по поставщику".
Это была хорошая новость. Плохая:
При разноске закупки с двумя строками с разными профилями, на форме разноски накладной увидишь две накладные. Соответственно по одной закупке будет разнесено две накладные по разным профилям.

Как вариант
- уболтать пользователей отказаться от второго требования "1 накладная в системе"
- исправить алгоритм печати ТОРГ-12 чтобы собирал несколько накладных по полю VendInvoiceJour.PurchId (а может быть и по полю VendInvoiceJour.ParmId)
- ну и самое сложное - сделать указание профилей в строках закупок.

[pitersky]

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

[Ivanhoe]

Quote:

Originally Posted by Buba

Axapta 3.0, SP3
Сейчас возникло требование: 1 товарная накладная (твердая копия) - 1 накладная в системе.

Quote:

Originally Posted by Buba

Для решения задачи было бы приемлемо 1 накладная (твердая копия) - N накладных в системе (VendTrans), но на одном документе ГК.

Мне кажется, чтобы предложить решение задачи, нужно понять в чем задача состоит

Buba, поясните в чем же состоит требование - кто, что и где хочет видеть в Axapta и, главный вопрос, для чего?

[Buba]

Quote:

Originally Posted by Ivanhoe

Мне кажется, чтобы предложить решение задачи, нужно понять в чем задача состоит

Buba, поясните в чем же состоит требование - кто, что и где хочет видеть в Axapta и, главный вопрос, для чего?

Заказчик (а-ля финдиректор) внедряет оперативный учет дебиторской и кредиторской (ДК) задолженности.

Главное требование: все документы по учету ДК должны аккумулироваться в регистре (документы оперативного учета - ДОУ) и только потом на их основе делаться бух.проводки.

В части закупок этот принцип реализован на основе отборочной накладной: чел от подразделения обрабатывает отборочную накладную, она "падает" в регистр, претерпевает от казначеев ряд смен статусов после чего бухам становится доступна возможность разнести накладную, но исключительно на основе прототипа - отборочной накладной, т.е. конкретного ДОУ.
При этом бух отвечает только за бух.аналитику и корреспонденцию. Все остальное (количество, даты, номер документа) ему недоступно.
Таким образом, деятельность буха сводится только к контролю и нажатию кнопки "разнести".

Категорическое требование 1 твердая копия накладной - 1 ДОУ, обосновывается заказчиком так: "Когда казначею поступает накладная для ее оплаты он не должен испытывать затруднений с идентификацией его электронного аналога в системе, т.е. не должен много думать, когда в системе он вдруг увидит 2 и более ДОУ вместо ожидаемого одного.

Да, мы рассматривали разные варианты "поколдовать" с объединением 2 и более ДОУ в один для таких исключительных случаев, без "насилования" стандартной фин.функциональности, но с учетом уже реализованной нетривиальной бизнес-логики это чрезвычайно трудозатратно.

[EVGL]

То, что вы описали, можно сделать как миниум 3 способами в системе, включая Ваш.
Тем не менее, главный вопрос остался без ответа: зачем нужно несколько субсчетов?

[Buba]

От поставщика получен перечень ТМЦ, часть и которых учитывается на субсчетах по учету ОС, другая - по учету ТМЦ, третья - по объектам капитальнго строительства и т.д. Субсчета для учета расчетов с поставщиками определены учетной политикой.

[fed]

Quote:

Originally Posted by EVGL

То, что вы описали, можно сделать как миниум 3 способами в системе, включая Ваш.
Тем не менее, главный вопрос остался без ответа: зачем нужно несколько субсчетов?

Рискну предположить, что разделение сальдо по 60ому счету по видам использования закупаемых материалов/товаров/услуг нужен для построения отчета о движении денежных средств прямым способом. Фактически - отчет сведется к дебитовым движениям по субсчетам 60ого.

Говоря о самой задаче: Я не вижу ее решения в рамках разумной модификации стандартного функционала. Я бы предложил бухгалтерии слегка сменить учетную политику и потом подготовил бы отдельный отчет, который по данным сопоставлений по поставщику собирает данные о том, на оплаты каких товаров/услуг/материалов были направлены денежные средства...

[EVGL]

Quote:

Originally Posted by fed

Я бы предложил бухгалтерии слегка сменить учетную политику и потом подготовил бы отдельный отчет, который по данным сопоставлений по поставщику собирает данные о том, на оплаты каких товаров/услуг/материалов были направлены денежные средства...

Полностью согласен.
Кроме того, в данном случае часть учетной политики, которая доставляет Вам эту головную боль, никак не влияет на результат деятельности предприятия, т.к. счета не затратные. В таких условиях политику можно и сменить.