Связь таблицы 111 с 113

[Константин!]

Господа, как можно 100% определить связь между строки таблицы Sales Shipment Line и Sales Invoice Line? Вариант типа DocNo, Item No, Quantity мне кажется не приемлемым т.к возможно задвоение товара с одним номенклатурным номером и количеством.

[SVG]

Если учесть что учет счетов и накладных может осуществляться раздельно - такой однозначной связи нет в принципе. Другое дело, если у вас счет и накладная учитываются вместе, тогда шанс есть
А собственно вам зачем? Может можно сделать правильнее? Работать не с учтенными документами, а с книгами?

[Yoil]

Пожалуй, по номеру строки в Value Entry и в Item Ledger Entry.
Но это при условии, что при учете заказа сразу создавался и счет и накладная. А то ведь можно сделать из одного заказа три счета и пять накладных, после чего все становится еще более замороченно
Присоединяюсь к вопросу SVG: а Вам зачем?

[Константин!]

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

Мы решили реализовать это следующим методом:
Есть одна общая фирма где все производят операции расхода и прихода разводя их по фирмам с помощью глобального измерения.
С приходом достаточно все прозрачно пришло в общую фирму отправил ее в другую по глобал измерению. А вот с расходом все сложнее. Рассматривается вариант когда Одна строчка SalesLine списывает товар из двух приходных партий первая из которых принадлежит фирме А а вторая фирме В а расход сам принадлежит фирме С.
По концу дня запускаем пакетник который бежит по учтенным Счетам на ходит их Расходные накладные потом набор записей в 32 по каждой записи 32 определяем из каких приходных партий (т339) мы это списали закидываем их в темповую табличку с кол-вом которое израсходовали а вот теперь надо эти строки преобразовать в нормальные SalesInvoiceLine чтобы потом безболезненно перекинуть готовую строчку в другую фирму.

Я конечно понимаю что алгоритм не идеален но как придумал так придумал сильно не ругайте. Если ни как это проблема не решается то буду думать как менять алгоритм. Заранее спасибо..

[SVG]

Вкусная задачка

1. не обязательно бегать так сложно - счет-расходная-32-339, можно просто бегать по 32, ну или 32-339
2. не совсем понятно в чем проблема - нашли например расход от фирмы А, который применился (частично или полностью) к операции прихода фирмы Б. Ну так и делаем перемещение из Б в А на ПримененноеКолво по с\с из этой самой приходной операции.
Зачем нам счета и прочие радости?
Вам ведь важно только чтоб остатки и с\с сходились.

По уму надо применение еще этих приходной и расходной операции перебрасывать на это перемещение... Но тут надо подумать... Аккуратно...

[Константин!]

По первому пункту : НАчали бегать со счетов т.к. посчитали что наличие счета дает нам основание что операция закончина и отмене не подлежит т.к. огрузку можно отменить (в некоторых случаях).
По второму: Когда расход фирмы Б израсходовал приход фирмы А мне нужно
1) сформировать расход в А (что она продала товар фирме Б) по продажной цене-1%
2) в Б сделать приход этого товара по продажной цене -1%
3) В Б сделать расход этого товара клиенту по продажной цене

Я просто хотел в общей таблички для всех фирм зарание собрать все линии а потом их тупо перенести тTransfield-ом в тужные фирмы и начать учитывать.

С применением оплат еще будем головоломка но это в будушем

[SVG]

Пункт 3 зачем? Если мы уже товар продали...

В поисках сегодняшних продаж все же можно бегать по только по 5802.ValueEntry
Если очень грубо - накладная делает строки в 32й, счет делает строки в 5802. Т.е. вам надо просто пробежаться, посмотреть товары, колва и суммы - все это есть в 5802. А 32я операция из 5802 достается очень просто - они напрямую связаны через
ItemLedgerEntryNo в 5802

ЗЫ У вас трешка?

[Константин!]

Мы продали в общей фирме надо теперь продать в реальной фирме(т.е есть фирмы А,В,С и общая где все работают и где реальные остаки).

Это все понятно что грубо можно так делать, а хочется 100%.

Возникает еще вопрост как я это все буду учитывать на автомате в разных фирмах?

[SVG]

Это не грубо - работать по ValueEntry Вполне потянет. Тем более там точный список товаров с продажными суммами.
С учетом не понял вопроса? С терминологией надо аккуратней - фирма, это такое понятие в навижне, а у вас я так понимаю это просто глобальное измерение. Создать покупки и продажи с нужным глоб измерением - несложно.

[Константин!]

СТОП.

Есть 4 -ре фирмы А,В,С,Общая именно фирмы с раздельными таблицами настройками и т.д.

Все добропорядочные люди Работают в фирме с именем "Общая" . Делают в ней Заказы покупки И заказы продажи. На заказы покупки они устанавливаю глобальные измерения которое может принимать три значения(Фирма А, Фирма В, Фирма С),тем самым установив глобальное измерение Фирма А они имеют ввиду что они сделали приход на Фирму А. Такая же история с заказами продажи они устанавливаю Глобальное измерение на заказ продажи и говорят что продали с этой фирмы.

Под конец дня пакетное задание анализирует учтенные Счета Фактуры продажи и Покупки и формирует документы в фирмах соответствующих их глобальному измерению.

Т.е. элементарна такая ситуация когда заказ продажи в фирме "Общая" с глобальным измерением "Фирма А" израсходует товар из Приходных Партий с разными Глобальными Измерениями например "Фирма А" и "Фирма В"
С кол-вом которое израсходовано из приходной Партии с совпадающем глобальным измерением т.е. "Фирма А" все просто мы его пере направляем в Фирму А делая там расход на это кол-во, а вот с кол-вом израсходованным из партии с глобальным измерением "Фирма В" все сложнее надо сначала передвинуть этот товар из Фирмы В в Фирму А а потом оформить документы на продажу в Фирме А клиенту.

Насчет учета: нужно после того как создали все эти документы товара движения в Фирмах А,В,С их учесть программно....

[SVG]

Я так понял вам надо перебрасывать продажи в соотв.фирму, при этом склад этой фирмы "должен соответствовать" продажам. Это несложно - для фирмы А - найти все применения НАШИХ продаж к НЕНАШИМ приходам, и сделать покупку соотв.колва в нашей фирме (то, что вам надо оформлять это путем "В продает А по продажным ценам" - это так надо? таковы условия?)
ну в общем с поиском для переброски нужных товаров, количеств и прочего - проблем больших нет, плясать можно хоть от счетов, хоть от книг - как вам удобнее, я б по VE работал
А учет - просто учет. Т.е. условно - на серваке запускаем три клиента с фирмами А,В,С и в них вешаем на расписание наш кодеюнит или репорт.

[Константин!]

В принципе все вроде даже вырисовывается, кстати спасибо за VE я так и сделаю, но вот выесняет что они могут двигать товар м\у фирмами по себстоимотям это плохо т.к. нужно получить правельную себестоимость и выстраивать последовательность учета документов, сначала учесть расход в фирме В потом Приход в Фирме А по себестоимоти фирмы В а только пото раскод в фирме А на клиента. Как бы вы с этим поступили?

[SVG]

Вопрос интересный. Если не нужна рентабельность одного отдельно взятого документа продажи (например для подсчета прибыли одного торгаша), то в принципе нас не колышет точная привязка - т.е.
в фирме А продали 10 штук товара
из трех партий -
1. 2 штуки из партии фирмы А по 5р
2. 5 штук из партии фирмы Б по 4р
3. 3 штуки из партии фирмы Б по 6р

Клепаем в фирме А приход 2 штуки по 5р
Клепаем в фирме А покупку у фирмы Б прям двумя строчками -
5 штук по 4р
3 штуки по 6р
Клепаем в фирме А продажу клиенту, и пофиг к чему она привяжется. А вот если надо рентабельность каждой сделки... Предлагаю запасаться иадом

[Константин!]

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

[SVG]

А если мы купили товар двумя партиями - по 5 рублей и по 10, а продали скажем партиями 6 и 9 - упаришься считать... При переброске применение не сохраняется...

[Константин!]

согласен, надо покумекать