Вопрос по архитектуре учета (не типовая задача из области торголви) #657192

Есть потребность построить определённый упр. учет, хотелось бы обсудить архитектуру, т.к. ничего простого в голову не приходит. Требуется вести учет при продажи проданный объём в разрезе некоторой аналитики (и потом строить отчет по продажам в разрезе этих аналитик). Детали не описываю, это не принципиально, а принципиальны следующие нюансы: 1. По одной из аналитик (одно измерение) при продаже указывается первое значение, потом, в самом конце, изменяется (единожды) на другое значение (сейчас это происходит отдельным документом; есть документ и регистрирующий эту аналитику перед использованием - ну там на её в регистры разные параметры вешаются - так сказать - идёт принятие к учету, а уж потом по ней идут продажи). При этом с одного на другое значение переносится только опр. часть продаж. В итоговый отчет должны попасть оба значения в одной строке (в разных колонках). 2. Есть операции корректировки реализации, и продажи до и после корректировки должны выводиться в итоговом отчете в одной строке (в соотв. колонках; в принципе есть потребность ещё отдельно вывести и все корректировки - но это доп. детализация). 3. По аналитике требуется контроль остатков (в первую очередь при перепривязывании с одной на другую). Сейчас всё это построена на одном нетиповом регистре остатков (аналитика в измерениях, в ресурсах объёмы продаж, в раздельных исходные продажи и скорректированные), но - как-то плохо складывается архитектура итогового отчета из-за перепривязки по одной из аналитик (ну и с корректировками тоже не всё гладко). Изначально я хотел ещё и регистр сведений добавить, но эту идею у нас не одобрили, вот мучаюсь, думаю опять вернуться к вопросу о регистре сведений - для хранения детального состояния по каждой продаже по всем параметрам.А остаточный регистр оставить только для контроля остатков. Кто что подскажет о том, как лучше архитектуру делать?

неужели никто не может помочь :(

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

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

пвх и регистр сведения. тут и думать не надо.

Неужели всё так плохо :( В некотором упрощении: 1. Пусть есть некий аналитический элемент A значения которого привязываются к реализации в объёме реализации (сумма, количество), может привязываться к нескольким реализациям. 2. Пусть есть некоторый аналитический элемент B значения которого привязываются к реализации, уже связанной с A, в некотором объёме (сумма, количество), т.е. можно считать, что часть реализации и A связывается с B (при этом с B может быть установлено много таких связей). Связывание осуществляет отдельный документ. Под A и B можно понимать, например серии номенклатуры (но только в разрезе реализаций, т.е. учета нереализованных товаров по сериям на складах не ведётся). 3. Нельзя связать с B реализаций с A больше, чем их было при проадаже (по сумме и колшичеству) - контроль остатков 4. На самом деле с A и И тоже связаны некоторые параметры, в т.ч. их объёмы - так вот эти остатки тоже нельзя превышать (при связывании), т.е. при реализации и связывании с A, остаток по A уменьшается. Аналогично при связывании с В - остаток по B уменьшается (увеличения нет, остатки задаются при регистрации A и B). 5. Есть операции корректировки реализации, идут в рамках связи реализации и аналитического элемента A, но в учете связанного объёма реализации и A этот объём (сумму и количество) нужно учитывать раздельно: исходный и финальный-скорректированный (может корректироваться несколько раз).   6. На самом деле ещё вся аналитика должна вестись раздельно в разрезе финальных цен (они должны быть точными, как в документах, а не расчетными). При этом корректировки меняют цены (на определённое количество, разбивая исходную продажу на части по разным ценам). 7. В результирующем отчете за период (по первичной реализации) выводится итоговая связка: реализация + A (со всеми параметрами, включая исходный объём) + B (со всеми параметрами, включая исходный объём) + цена и объёмы (сумма и количество) исходные + скорректированные (финальные) + перечень всех корректировок, приведших от исходной реализации к финальной цене. Сейчас всё это построено на одном остаточном регистре накопления -  измерения реализация + цена + A/B аналитика (в одном измерении); ресурсы: сумма, количество, сумма исходная, количество исходное; реквизит корр аналитика A или  B при переносе остатклов из A и на B, осуществляемом при привязке A к B. Остатки по B заполняются в этом регитстре при ео регистрации. Остатки по A отдельно не в этот регистр не вволятся (хранятся в параметрах A), а первый раз регистр заполняется при связывании реализации и A в объёме связывания. При перепривязывании A к B остатки происходит взаимное гашение остатков по реализации + A и B (по и с пустой аналитикой, но заполнением реквизит корреспонденции с аналитикой A) - в итоге все остатки гасятся в 0. При корректировке корректируются только ресурсы количество и сумма (исходные не изменяются) и происходит списание со старой цены на новую цену (перенос остатка в объёме корректируемого количества). При такой архитектуре структура запроса результирующего отчета получается очень громоздкой и очень плохо обрабатывается ситуация где нужно установить объём связи A и B (приходится обрабатывать регистр до записей, чтобы определить эту связь через реквизит корр аналитики). Как улучшить архитектуру?

по. 4. слово "связаны" нужно заменить на "имеют" по 7. выводятся обе цены (исходная и финальная)

по 4. большая буква "И" - это B

Я сейчас, как вариант, хочу разнести: 1. Не формировать остатки по B при регистрации в регистре остатков т.е. так же как по A. 2. Аналитику по A и B из одного в два разных измерения. 3. При реализации - заполнять только измерение A 4. При привязке A к B списывать по связке реализация + A (c пустым B) и добавлять уже по связке реализация + A + B (т.е. уже с заполненными измерениями для A и B); а затем делать такую же проводку, но с расходом, чтобы списать остатки в 0 (они больше не нужны) по этой аналитике (в текущем объёме), чтобы они не зависали в регистре. 5. В отчете как и сейчас, анализировать обороты. 6. Так как корректировка идёт только до привязке к B (корректировать всегда с пустым значением по B). 7. Контроль остатков по A делать по остатку реализация + A (без указания B - т.е. по всем) и исходному объёму A (в параметрах A), аналогично по B (но без указания A). Контроль остатка реализации связанной с A делать по остатку реализация + A (с заданным пустым B).

пишите дальше ))

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

Ещё улучшения варианта: отказаться от остаточного регистра в пользу оборотного. Тогда при привязки A к B не нужно будет затем списывать сформированный остаток по связи. А остатки для контроля получать в качестве оборота за период - но это снизит производительность проведения - так что это, не лучший, конечно вариант. Плюс плохо сочетается с необходимости вести учет раздельно по финальным ценам и корректировкам этих цен (с разнесение исходных продаж с аналитиков по разным ценам в разном количестве).

Хорош шифроваться, изложи нормально, иначе толку не будет.

Всё делает один человек. Просто сначала регистрирует продажи в разрезе A, затем многократно (в самом плохо случае) корректирует цену в разрезе реализаций и A (разнося количество  на разные цены), а затем, перепривязывает A на B (тоже достаточно произвольно, скажем так, объём по B покрывается объёмами реализаций в разрезе A и разных цен, но одна реализация + A может распределиться на разные B). А потом строится итоговый отчет, показывающий всю "историю" и все связи от и до по каждой продаже в строке (там в отчет ещё много чего дополняется) - на самом деле это упрощённая модель реального процесса, который содержит ещё больше этапов.

Я просто пытаюсь абстрагировано упростить. Сам процесс - это многоэтапный экспорт, A и B различные таможенные декларации. Привязка A к B - это завершение операции экспорта - переход от временной декларации к постоянной. А реализация, например, тоже многоэтапаная, с отгрузкой безперехода прав, длительным движением ЖД транспортом, длительным хранением на чужом складе (как бы в пути), затем ещё длительной отправкой морским путём, и всё разными партиями. Прим этом в итоге цены  постоянно корректируются. Но это уже всё лирика.

Спец по торговле один на всю страну и он сейчас писает в ветке про инфостарт

А причём здесь торговля? Здесь вообще нетиповой учет. да, построен он на регистрах накопления, и что, вопрос был об архитектуре, можно предложить любое решение на любых учетных элементах, хоть на табличных частях, хоть на регистрах расчета ;)

я ни хрена не понял, но у вас там все неправильно. Зачем задним числом цены в документе продажи править? Зачем аналитику задним числом ломать?

а почему бы вам не сделать партионный учет в разрезе первой декларации (партии), с которой проводить уже документами второй декларации..

Опишите задачу так, как она стоит, без "абстрагированных упрощений" :)))

она уже описана .. как понимаю тащут товар на таможенный склад  , а тот ее постепенно выпускает.

Причём здесь "задним  числом" - я про это ни слова не сказал. Цены меняются последовательно, документами "Корректировка реализации". Фактически так и есть, просто учет партий идёт в сериях номенклатуры Практически так и есть

В на

На самом деле, "задним числом"  работа конечноидёт, но это не критично. "Задним числом" в реализациях проставляется привязка к А, т.к. на момент реализаций она далеко не всегда ещё известна (долго идут документы). Задним числом идёт корректировка цены продажи (документами Корректировка реализаций), т.к. распоряжения поступают с большой задержкой, да и не всегда их успевают все сразу исполнить, а актуальность по ценам никому в оперативе не нужна. Задним числом идёт привязка A к B, потому что этим нет времени заниматься в течение месяцев и делается это перед сдачей отчетности, чтобы получить итоговый отчет.

читать не стал. в чем беда?

Беда в том, что всем, кажись, пофиг

скорее в том, что ты объяснить не можешь все в одном посте, да чтоб еще понятно было.

че надо автоматизировать опиши, без "это пишется сюда, потом перезаписывается и будет большой отчет"

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

Отгрузка без БПС + товар в пути + привязка к временной ГТД  (по определённой сумме/количеству с контролем остатков по временной ГТД и отгрузке) + хранение на складе без договора на ОХ + Реализация + товар в пути + изменение цен реализованного товара (разнесение количества по частям на разные цены и их последующее многократное изменение) + инвентаризация товара в пути + привязка временной ГТД к постоянной ГТД (по определённой сумме/количеству с контролем остатков по постоянной ГТД и исходной связкеи реализации и временной ГТД) + отчет за период, в котором одна такая связка будет выводиться одной строкой: отгрузка + реализация + временная ГТД (с остатками) + постоянная ГТД (с остатками) + цена исходная + цена финальная + количество/сумма исходные + количество/сумма финальная + все корректировки цены + НДС + налоговый период Товар отгружается сразу (через отгрузку без перехода права собственности; хотя есть случаи обычной реализации), а затем движется к покупателю за границу. При этом временная ГТД может привязывать как в момент отгрузки, так и в момент реализации отгруженных товаров (либо/либо), реализации отгруженных товаров идут частями (собираются из отгрузок по кусочкам). Привязка к постоянной ГТД идёт частями - наполнения постоянной ГТД временными ГТД со всеми реализациями. С промежуточного склада товар продолжает двигаться частями, с последующей корректировкой цены.

Я не вижу, в чем проблема. Регистр остатков - измерения: товар, документ отгрузки, временная декларация. Движения по этому регистру: Документ отгрузки: отгрузка№ "345-567", временная декларация "пока не создана", количество +10 Документ временная декларация (две записи в регистр на каждую строку ТЧ): Документ постоянная декларация: отгрузка№ "345-567", временная декларация "6544ФЫВ", количество -5 количество не должно уходить в минус, по каким постоянным декларациям все ушло - смотрим по документу регистратору. Если эта схема не подходит - надо понимать нюансы, что именно вам нужно. Именно об этом я и спрашивал.

Примерно так сейчас и реализовано Но архитектура не нравится, т.к. при построении отчета и восстановления связи временной и постоянной ГТД приходится спускаться до уровня записей, т.к. привязка временной к постоянной хранится только в записях регистра как измерение временной к реквизиту постоянной, чтобы перенос с временной на постоянную обнулил остатки, которые не должны дальше висеть в учете. Вот по этому и возникает идея  изменить структуру регистра остатков или ввести регистр сведений (видимо не периодический даже, хотя это тоже хороший вопрос) где сохранять привязку временной к постоянной (да за одно ещё и цены (исходные и финальные, в разрезе корректировок) и сумму/количество исходные - т.к. это, в общем-то, не изменяемые величины - закреплены строго за одной операцией - одной строкой).

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

Может я не въехал в задачу, но по-моему все это реализуется в типовой УТ 10 (которая с партиями) через продажу товара между организациями и перемещения между складами.

нарисуй юлок схему движения товаров. все сразу станет понятно

Как мне казалось, схему я уже достаточно подробно обрисовал, в т.ч. в и Уточняю: Одна отгрузка может быть реализована несколькими реализациями отгруженных товаров (частями), как и наоборот, одна реализация отгруженных товаров, может реализовывать несколько отгрузок - это нетиповая доработка, но суть главного вопроса не в этом. Одна временная ГТД может быть закреплена за некоторым количеством строк исходной отгрузки, со всеми вытекающими (сделано через "Серии номенклатуры"). Корректировка реализации коррректирует одну реализацию, но может корректировать часть количества, перенося его на другую цену (нетиповая доработка) вместе с закреплённой временной ГТД. Связь между временными и постоянными ГТД может быть многие ко многим, но чаще - многие к одному. А структура регистра в общем-то соответствует и Уточню: Что в структуру ещё добавлено измерение "Цена", чтобы вести учет в разрезе финальных цен, т.к. их нужно выводить в итоговом отчете, и ни должны быть точными, а не сумма / количество, т.к. из-за корректировок одна реализация может распасться на множество отдельных кусочков, с разными ценами. Что ещё нужно уточнить? Продажи товаров между организациями нет. Есть только продажа конечному контрагенту. Перемещений между складами тоже нет, т.к. товар отгружается с нашего склада в самом начале (Реализация товаров и услуг с видом операции Отгрузка без перехода права собственности; есть и продажи с переходом права собственности, но далее процесс такой же, упрощается только отгрузка/продажа), а  далее товар формально находится в состоянии "В пути", какого-либо специального учета товара в этом состоянии я в типовых 1С не видел. Временный склад базирования (между реальными длительны перемещениями) нам не принадлежит и мы с ним никаких договорных отношений не имеем (вроде как договор заключён у покупателя, уж извините схема не самая прямая, но тут ничего не поделаешь, да и не особо это важно). Нужен только учет сколько товара закреплено за таможенными ГТД и перекидывать его с одной на другую (с временной на постоянную), а в конце видеть одной строкой все данные от отгрузки до финальной постоянной ГТД и налогового периода учета НДС по сделки. Юридически, реальная сделка продажи с контрагентом закрепляется только после отправки товара контрагенту с промежуточного склада, когда формируются корректировки реализаций, устанавливающие финальную цену. До этого, товар лишь числится формально проданным, а реально - это всё процесс отгрузки/доставки.

зачем? регистра не хватает? "Корректировка реализации коррректирует одну реализацию, но может корректировать часть количества, перенося его на другую цену (нетиповая доработка) вместе с закреплённой временной ГТД." что значит - перенося на другую цену? создается еще одна реализация? "в структуру ещё добавлено измерение "Цена", чтобы вести учет в разрезе финальных цен" измерение???? Сам бизнес процесс у вас достаточно стандартный (для сложных условий поставок и необходимости контроля момента перехода прав собственности), но судя по описанию, реализация в системе - не очень. Если по существу вопроса - в регистре остатков 5 измерений - товар, документ отгрузки, документ реализации, временная декларация, постоянная декларация. Ресурс - количество, остатки только положительные. Больше ничего там быть не должно, в особенности цены. Цену надо брать из документа реализации (с учетом всех корректировок).

Что-то куда-то кого-то понесло "Серия номенклатуры" является олицетворение (элементом учета) ГТД (как и в типовой УПП, где это реализуется). Привязка к продаже идёт только через регистр накопления "Остатки по ГТД" (не типовой), из учет по остаткам на складах и организации серии номенклатуры исключены (т.к. они возникают в учете только в момент реализации/отгрузки, и даже позже). Перенос на другую цену означает, то что ранее продали 1000 штук по 1 рублю, а после корректировок по согласования стороны вместо продажи по 1 рубля продали 300 по 2 рубля, 500 по 3 рубля 200 по 4. Соответственно, так как учете регистре "Остатки по ГТД" идёт в разрезе цен (измерение), то корректировка списывает нужную часть остатка с одной цены и записывает на другую. И таких изменений может быть несколько по одной и той же продаже, 1 рубль -> 2 ->4 ->2 и каждый раз с разным количеством. А в итоговом отчете - нужно видеть точную цену, назначенную в последней корректировке по каждой части (разной цене) исходной продажи. Цена является измерением, т.к. по ней раздельно хранятся продажи одной и той же реализации, разное количество по разным итоговым ценам. Бизнес-процесс усугублён многими факторами. Может реализация и не очень - но я поэтому и создал эту тему. А тут сейчас поступили новые требования - я от них вообще уже в шоке - придётся существенно всё расширять, а это при уже в ведённой в эксплуатацию системе, с постоянно заполняемыми данными в рабочей базе. По последнему вашему абзацу - значит вы тоже за то, чтобы из одного измерения по декларации перейти к двум. Но как вы предлагаете брать цену из реализации с корректировками - шерстить исходные документы, табличные части - ИМХО это вообще полный бред. А ресурсов уже предполагается 6: пары (количество + сумма) для: отгружено, реализовано в начале, скорректировано в конце. Но с количеством ещё нужно думать - стоит ли его дублировать для всех 3-х состояний. Скорее всего нет, т.к. хоть и на каждом этапе будет выявляться недостача (или излишек) - то это, видимо будут переносить на отдельные строки учета. Это уже просят и это так же нужно будет выводить в отчете.

"Серия номенклатуры" является олицетворение (элементом учета) ГТД (как и в типовой УПП, где это реализуется). если мне не изменяет память, в УПП это используется для закупок (импорт), а не продаж (экспорт). у вас совсем другая задача, и использовать серии - неправильно. "Перенос на другую цену означает, то что ранее продали 1000 штук по 1 рублю, а после корректировок по согласования стороны вместо продажи по 1 рубля продали 300 по 2 рубля, 500 по 3 рубля 200 по 4. Соответственно, так как учете регистре "Остатки по ГТД" идёт в разрезе цен (измерение), то корректировка списывает нужную часть остатка с одной цены и записывает на другую. И таких изменений может быть несколько по одной и той же продаже, 1 рубль -> 2 ->4 ->2 и каждый раз с разным количеством. А в итоговом отчете - нужно видеть точную цену, назначенную в последней корректировке по каждой части (разной цене) исходной продажи. Цена является измерением, т.к. по ней раздельно хранятся продажи одной и той же реализации, разное количество по разным итоговым ценам." в 1С все идет от документа. В бумажных документах, которые вы печатаете поставщику и по которым оформляете декларации что? один документ, в котором 5 строк с одним и тем же товаром, но разной ценой, или 5 документов, в каждом из которых разная цена? "Но как вы предлагаете брать цену из реализации с корректировками - шерстить исходные документы, табличные части - ИМХО это вообще полный бред. " а у вас в системе только один регистр? :))) обычно есть еще что-то под названием "реализация", "продажи" и т.п. "По последнему вашему абзацу - значит вы тоже за то, чтобы из одного измерения по декларации перейти к двум." наверное, да. так будет проще "А ресурсов уже предполагается 6: пары (количество + сумма) для: отгружено, реализовано в начале, скорректировано в конце. Но с количеством ещё нужно думать - стоит ли его дублировать для всех 3-х состояний. Скорее всего нет, т.к. хоть и на каждом этапе будет выявляться недостача (или излишек) - то это, видимо будут переносить на отдельные строки учета. Это уже просят и это так же нужно будет выводить в отчете." ????????????????? ресурс ОДИН - количество.

>>если мне не изменяет память, в УПП это используется для закупок (импорт), а не продаж (экспорт). у вас совсем другая задача, и использовать серии - неправильно. УПП ущербна. Не вижу принципиального отличия. От остатков на складах я серии отвязал. Мне просто нужно было что-то, что уже есть в типовых документах, чтобы заполнять в ТЧ и использовать в движениях. Да и серии содержат номера ГТД, да в типовой УПП это используется при импорте, просто там не предусмотрено, что такие же ГТД могут возникать при экспорте. По поводу цен. В бух учете всем рулят счет-фактуры - это если говорить о необходимости для корректного учета, с точки зрения законодательства. Изначально в документе одинаковые цены на товар (но по правилам учета в оптовой торговле допускаются и разные цены на товар в одном документе), изменение цены идёт в корректировках реализаций. Сейчас одна корректировка изменяет только одну цену на другую  рамках определённого количества. По корректировкам вводятся корректировочные счета-фактуры. >>а у вас в системе только один регистр? :))) >>обычно есть еще что-то под названием "реализация", "продажи" и т.п. Всё дело в нужной детализации. И в правильном получении цены. в УПП нет подходящего типового регистра, заполняемого по продажам, по которому можно было бы точно узнать финальную цену продажи, разнесённой на разные цены корректировками реализаций. Здесь, скорее такая же потребность, радии которой в регистре "Заказы покупателей" введено измерение "Цена". А как вы сделали такое выделение цитаты внизу? Так, с ресусрами конечно нужно подумать, что у нас в требованиях для итогового отчета по строке продажи: 1. Разделение детализации по связкам Документ отгрузки + Документ реализации + Временная ГТД + Постоянная ГТД (причём любая из этих "измерений", кроме "Документа отгрузки" может быть ещё пустой, т.е. в отчет начинают попадать данные сразу с момента отгрузки и далее потихоньку будут со временем дополняться, а строки дробиться при раздроблении отгрузки на части). 2. К детализации ещё нужно отнести Финальную цену (от последней корректировки, т.к. исходные продажи ещё будут разноситься-разделяться на разные цены в разном количестве) 3. Исходная цена реализации (до корректировок), если реализации ещё нет - цена отгрузки. 4. Количество отгрузки: тут хитро хотят, либо это количество исходной отгрузки (если ещё не реализовано), либо это количество совпадает с количеством реализации(по строке с закреплённой реализацией), либо отдельной строкой отгруженное количество, ещё не реализованное (реализация не заполнена) 5. Количество реализованное (по итогу реализации, когда есть уже закрепление части отгрузки за реализацией) 6. Стоимость реализации (в исходных ценах реализации, когда реализация не пустая) 7. Стоимость с учетом всех корректировок (т.е. по последней корректировки данной связки отгрузка+реализация+в.ГТД+п.ГТД) 8. Общие остатки по в.ГТД и п.ГТД (на текущую дату) в строке (остатки ГТД измеряются как в количестве, так и в сумме) 8. Список всех корректировок, проведённых по связке для достижения исходной цены. 7. ну там ещё куча разных дат, налоговых периодов и т.п. выводится Сейчас весь этот учет построен на одном нетиповом остаточном регистре "Остатки ГТД", вопрос с ресурсными сейчас, видимо нужно дорабатывать - я думаю, что вы правы при наличии измерения Цена - количество достачно в одном ресурсе: 1. Количество (в одном ресурсе, вроде как будет достаточно, т.к. нереализованное отгруженное будет отделяться от реализованного разными строками; а при разнесении на разные цены и количество и стоимость тоже будет в разных строках) 2. Стоимость отгрузки/реализации (в одном ресурсе, т.к. формально стоимость имеет значение только с момента реализации, но до момента реализации её тоже нужно выводить в отчете, поэтому ресурс будет заполняться и уже в момент отгрузки, т.к. цена там тоже указывается) 3. Стоимость финальная (с учетом корректировки), т.к. в отчет нужно выводить исходную стоимость и финальную стоимость приходится разделять их в разных ресурсах для эффективности построения отчета, а заполняться они будут разными документами. Почему не пересчитывать стоимость по количеству и цене из измерения - потому-что в этом случае есть погрешность из-за округления. 4. Других ресурсов нет. НДС нет, т.к. это экспорт по ставке 0%. Соответственно в измерениях остаточного регистра "Остатки ГТД" придется  разместить:

автор, извини за офф. Но вот на будущее совет : большие куски текста, не поделенные на абзацы , ну о-о-о-о-чень тяжело читаются. особенно если это какая-то абстрактная проблема... Особенно , если это проблема не твоя.. особенно если бесплатно помогаешь. :) Ну, вот как-то так. Извини, надеюсь без обид.

Схема движения по регистру «Остатки ГТД»: Регистрация в. и п. ГТД: Приход Формирование записей в регистре "Остатки ГТД" только в разрезе измерения "Временная ГТД" или "Постоянная ГТД". Ресурсы: Количество - исходный количественный объём ГТД Стоимость финальная - исходный суммовой объём ГТД Отгрузка  без ППС (в.ГТД не указывается): Приход Измерения: Документ отгрузки, Цена Ресурсы: Количество, Стоимость отгрузки/реализации Реализация отгруженных товаров (может указываться в.ГТД, но может сразу и не указываться): Расход Измерения: Документ отгрузки, Цена Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме реализации Приход Измерения: Документ отгрузки, Документ реализации, Временная ГТД (может быть пустой), Цена Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме реализации Если Временная ГТД заполнена Расход Измерения: Временная ГТД Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме реализации Привязка временной ГТД (для случая если реализация прошла без в.ГТД) Расход Измерения: Документ отгрузки, Документ реализации, Цена Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме привязки к в.ГТД Приход Измерения: Документ отгрузки, Документ реализации, Временная ГТД, Цена Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме привязки к в.ГТД Расход Измерения: Временная ГТД Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме привязки Корректировка реализации (только разнесение по разным ценам) Расход Измерения: Документ отгрузки, Документ реализации, Временная ГТД, Цена (текущая до корректировки) Ресурсы: Количество – в объёме корректировки Стоимость отгрузки/реализации – пропорционально количеству с остатка Стоимость финальная – пропорционально количеству с остатка (при первой корректировки =  0) Приход Измерения: Документ отгрузки, Документ реализации, Временная ГТД, Цена (новая после корректировки) Ресурсы: Количество – в объёме корректировки Стоимость отгрузки/реализации – пропорционально количеству с остатка (без изменений) Стоимость финальная – стоимость корректировки (количество*цена новая) из документа Экспорт по ГТД (итоговый документ – привязка к постоянной ГТД): Расход Измерения: Документ отгрузки, Документ реализации, Временная ГТД, Цена (из остатков) Ресурсы: Количество – в объёме привязки к п.ГТД Стоимость отгрузки/реализации – пропорционально количеству с остатка Стоимость финальная – пропорционально количеству с остатка Приход Измерения: Документ отгрузки, Документ реализации, Временная ГТД, Постоянная ГТД, Цена (из остатков) Ресурсы: Количество – в объёме привязки к п.ГТД Стоимость отгрузки/реализации – пропорционально количеству с остатка (без изменений) Стоимость финальная – пропорционально количеству с остатка (без изменений) Расход (дублирующее движение к предыдущему, чтобы списать остатки и оставить только оборот – один в один – только вместо прихода тут расход) Измерения: Документ отгрузки, Документ реализации, Временная ГТД, Постоянная ГТД, Цена (из остатков) Ресурсы: Количество – в объёме привязки к п.ГТД Стоимость отгрузки/реализации – пропорционально количеству с остатка (без изменений) Стоимость финальная – пропорционально количеству с остатка (без изменений) Расход Измерения: Постоянная ГТД Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме привязки к п.ГТД Инвентаризация экспорта (товара в пути): осуществляется до привязки Постоянной ГТД Недостача: Расход Измерения: Документ отгрузки, Документ реализации, Временная ГТД, Цена (из остатков) Ресурсы: Количество – в объёме недостачи Стоимость отгрузки/реализации – пропорционально количеству недостачи с остатка Стоимость финальная – пропорционально количеству недостачи с остатка Приход Измерения: Постоянная ГТД – специальный предопределённый элемент для недостачи Ресурсы: Количество – в объёме недостачи Стоимость отгрузки/реализации – пропорционально количеству с остатка (без изменений) Стоимость финальная – пропорционально количеству с остатка (без изменений) Расход (дублирующее движение к предыдущему, чтобы списать остатки и оставить только оборот (пока остатки по недостаче не нужны) – один в один – только вместо прихода тут расход) Измерения: Постоянная ГТД – специальный предопределённый элемент для недостачи Ресурсы: Количество – в объёме недостачи Стоимость отгрузки/реализации – пропорционально количеству с остатка (без изменений) Стоимость финальная – пропорционально количеству с остатка (без изменений) Расход Измерения: Постоянная ГТД Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме привязки к п.ГТД Излишки: Под излишки оформляется одна обычная реализация товаров (этот вариант продажи представлен ниже) и используется здесь и как отгрузка и как реализация, для Временной ГТД указывается специальный предопределенный элемент (т.к. этой декларации для излишков не существует и она используется только для идентификации излишков в отчете). Далее сразу идёт Экспорт по ГТД (см. выше) Реализация товаров купля продажа (может указываться в.ГТД, но может сразу и не указываться): Приход Измерения: Документ отгрузки (реализация товаров), Документ реализации (реализация товаров), Временная ГТД (может быть пустой), Цена Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме реализации Если Временная ГТД заполнена и это не предопределённый элемент для излишков (т.к. по нему нет общих остатков по ГТД) Расход Измерения: Временная ГТД Ресурсы: Количество, Стоимость отгрузки/реализации - в объёме реализации Всё. Правда, бизнес-процесс этим не исчерпывается, ещё есть ряд операций по учету НДС, подтверждения 0% ставки, контроля подачи документов в налоговые органы, учета просроченных объёмов (по подаче и подтверждения документов), учета доп. параметров самих в.ГТД и п.ГТД и т.п.  – всё это тоже выводится в отчет, но уже к регистру «Остатки по ГТД» и учету по таможенным декларациям имеет уже косвенное отношение.

Кто-то там просил схемку - их есть тут - правда эта уже улучшенная схема, та, которую я видимо будут сейчас реализовывать вместо текущей, описанной в и . Согласен, вообще я стараюсь разбивать на абзацы, но не всегда это замечаю. Или под абзацами понимаются раздельные посты?

Ниче себе. Это что, отрывки из докторской диссертации?

Не злорадствуй - меня просили, я написал, может кому-нибудь ещё будет полезно потом, кто что-то подобное будет решать. Да заодно у меня хоть какое-то ТЗ наконец появилось (у нас в компании как-то не принято работать по ТЗ или проектам, что меня очень расстраивает) - теперь будет сложнее запутаться в решении.

Нашёл неточность в описании при движениях по ресурсу "Стоимость финальная". Этот ресурс так же заполняется при реализации (сейчас это не указано) и равен ресурсу "Стоимость отгрузки/реализации", поэтому при первой корректировке он не нулевой (т.к. корректировки может и не быть, например, в случае прямой продажи без отдельной отгрузки). Нулевой этот ресурс только во время первой отгрузки (да и тут, в общем-то его можно было бы заполнить, только потребности в этом нет).

Да, и ещё забыл добавить, что все стоимости выражаются как в регламентированной валюте, так и в валюте таможенных деклараций (везде USD) - поэтому все суммовые ресурсы идут парами: валютная сумма + рублёвая сумма Курс может меняться при продаже и при корректировке.

буду писать кусочками >>если мне не изменяет память, в УПП это используется для закупок (импорт), а не продаж (экспорт). у вас совсем другая задача, и использовать серии - неправильно. УПП ущербна. Не вижу принципиального отличия. От остатков на складах я серии отвязал. Мне просто нужно было что-то, что уже есть в типовых документах, чтобы заполнять в ТЧ и использовать в движениях. Да и серии содержат номера ГТД, да в типовой УПП это используется при импорте, просто там не предусмотрено, что такие же ГТД могут возникать при экспорте. :))))) то есть вы используете то же, что и в ущербной УПП, но совсем другим способом. для этого дополнительно отвязывали серии от движений товаров. задачу это не решило, создали еще один регистр, где хранится та же информация. внимание, вопрос - зачем вырывать гланды через ж.. автогеном без наркоза? ;)))

Мне отвечать тоже покусочкам?

Мне так было удобнее. Во-первых, я не внёс изменения в формы типовых документов, а внести в тест некоторых общих процедур простой код по игнорированию значению серий - плёвое дело и оно хорошо контролируется при типовых обновлениях. Во-вторых, типовые регистры мне всёравно ничего не дали бы. Наиболее близкие по смыслу это "Товары переданные" и "Продажи". Если с переданными товарами ещё как-то можно работать, хотя без доработки тут не обошлось бы - т.к. связи с документом передачи в регистре нет - но можно замутить было со сделкой. То с продажами хуже - т.к. нужно отдельно учитывать продажи до корректировки реализации и после, а так же в регистре нет связи с в.ГТД и п.ГТД - т.е. это тоже пришлось бы добавлять. Та же загвоздка и с финальной ценой - т.к. по одной продаже нужно чётко хранить продажи в разрезе разных финальных цен с высокой точностью по цене. Ну и ещё связывать пришлось бы оба регистра - что ещё более усложнило бы отчет. И где здесь вырываний гланд через мягкое место? УПП ущербна.

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

...

Еще раз - зачем было трогать серии номенклатуры (чем это было удобнее)? Ведь все равно пришлось создавать отдельный регистр остатков?

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

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

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

С импортом никаких проблем не будет. я просто расширю виды ГТД (сейчас это два вида "Временная" и "Постоянная"), добавив ещё, например, "Импортная" и сделаю чуть разную логику обработки для текущих и импортных ГТД (в основном в при продаже, где сейчас отключено списание со складов в разрезе ГТД). Но... это вряд ли. Мы импорт не будем перепродавать, по крайней мере в рамках этого юр. лица и этой учетной системы. А уж экспорта импорта не будет 100%. Да и не пересекались бы разные товары (импортный и отечественный) в рамках одной поставки, ну или хотя бы в рамках одной экспортной ГТД - такая путаница никому не нужна была бы. Совершенно верно. Всё, в общем случае, соотносится как многие ко многим.

С импортом никаких проблем не будет. я просто расширю виды ГТД (сейчас это два вида "Временная" и "Постоянная"), добавив ещё, например, "Импортная" и сделаю чуть разную логику обработки для текущих и импортных ГТД (в основном в при продаже, где сейчас отключено списание со складов в разрезе ГТД). Ты же упоминал, что отвязал от товарных движений и остатков? И именно с этим и будут проблемы :)))

В одной ГТД есть несколько строк с одним и тем же товаром по нескольким разным ценам? Если да, то действительно, цену проще как измерение сделать.

Ну, я же в написал, что сделаю разную логику для импорта и экспорта. До момента продажи всё осталось без изменений. Разница будет в том, что в момент продажи экспортные ГТД не будут списывать остатки со складов (и из товаров к передаче) и не будут формировать движения по новому регистру "Остатки по ГТД", всё остальное останется без изменений. Увы, есть, как в разрезе временных, так и в разрезе постоянных ГТД. Но даже без этого, я считаю, что в УПП (как и в Торговле) неверно то, что, например, в регистре "Продажи" (который оборотный) нет измерения Цена (как в регистре "Заказы покупателей"), и нет соответствующей поддержки в документ "Корректировка реализации", т.к. реально без этого нет возможности точно узнать цену каждой строки продажи. Но да ладно, у меня изначально был более глобальный вопрос - о всё учете, н только про разделение по ценам, включая привязки временных к постоянным ГТД, учете данных по исходным отгрузкам и финальных данных по итоговой цене, получении и выводе в отчете истории всех корректировок финальной цены и, главное, как архитектурно правильно обеспечить закрытие остатков по остаточному регистру (чтобы не разделять его на остаточный и оборотный) и сохранить контроль остатков.

Сейчас я реализую своё же предложение из , , (ресурсы сумм идут парами Сумма в валюте и Сумма регламентированная). Будут ли замечания или конкретные предложения по модернизации такого подхода?

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

По-моему, то, что Вы предлагаете ещё больший бред. Всё-таки стоило бы почить остальное обсуждение. Проблема в том, что на протяжении 90% всего бизнес процесса используются остатки и лишь в итоговом отчете используются обороты (при иной архитектуре, можно было бы и без оборотов обойтись). И зачем мне целых два регистра накопления, когда у меня и на одном всё "практически" прекрасно строится.