Обсуждение контроля остататков и партионного учета. Любимое дерево. #422163


#0 by selenat
Поскольку ветка, где я излагал некоторую идею по этому поводу, утонула, создам еще одну специально для обсуждения определенной методики. Итак, повторю то, что писал в той ветке. Возьмем стандартный регистр ТоварыНаСкладах из УТ например. Добавим в него измерение ДатаПрихода, в которое будем заполнять момент приходного движения (это может быть не только поступление или оприходование, но например и перемещение, и возврат - т.е. любое приходное движение по стандартным измерениям регистра). Списание по этому измерению должно организовываться по принципу ЛИФО. Т.е. расход будет брать остатки с самого последнего прихода, который был до этого расхода. В чем теперь заключается контроль остатков? При проведении расходного документа делаем запрос остатков на ТА, причем только те остатки, ДатаПрихода которых меньше, чем дата этого расходного документа. Если такого остатка хватает, то это гарантирует нам неуход в минуса от этого расходного документа до ТА. Т.е. это критерий (необходимое и достаточное условие) возможности в дальнейшем восстановить последовательность по этому набору измерений.
#0 by selenat
Поскольку ветка, где я излагал некоторую идею по этому поводу, утонула, создам еще одну специально для обсуждения определенной методики. Итак, повторю то, что писал в той ветке. Возьмем стандартный регистр ТоварыНаСкладах из УТ например. Добавим в него измерение ДатаПрихода, в которое будем заполнять момент приходного движения (это может быть не только поступление или оприходование, но например и перемещение, и возврат - т.е. любое приходное движение по стандартным измерениям регистра). Списание по этому измерению должно организовываться по принципу ЛИФО. Т.е. расход будет брать остатки с самого последнего прихода, который был до этого расхода. В чем теперь заключается контроль остатков? При проведении расходного документа делаем запрос остатков на ТА, причем только те остатки, ДатаПрихода которых меньше, чем дата этого расходного документа. Если такого остатка хватает, то это гарантирует нам неуход в минуса от этого расходного документа до ТА. Т.е. это критерий (необходимое и достаточное условие) возможности в дальнейшем восстановить последовательность по этому набору измерений.
#1 by selenat
Поехали дальше. Если же это измерение (ДатаПрихода) использовать не в регистре ТоварыНаСкладах, а в регистре партий, то по этому же принципу можно не только проконотролировать в момент проведения документа - сможем ли мы в дальнейшем восстановить последовательность, но мы так же сможем однозначно ответить на вопрос - а нужно ли вообще восстанавливать последовательность по этому набору измерений. По сравнению с методом Маньяка это просто более точный метод. Потому что факт изменения документа по некоторой номенклатуре еще не означает, что по ней необходимо восстановить последовательность, может она осталась верной. А тут мы точно будем знать - нужно или нет.
#2 by selenat
Ну а теперь ложка дегтя. Проблемы начинаются, когда мы задним числом вводим приходное движение. Для того, чтобы метод работал, на нужно все время поддерживать в актуальном состоянии принцип списания ЛИФО по измерению ДатаПрихода. Это значит, что при вставке задним числом нового приходного движения, часть расходов, имеющих более позднюю дату, должны изменить свои движения, перераспределить свои списания в соответствии с ДатаПрихода этого нового вставляемого прихода. И вот тут возникает трабла, поскольку найти все эти документы расхода и откорректировать их движения - это в общем случае не очень быстрое действо, которое может тормозить оперативную работу пользователей. И отложить на потом это нельзя, поскольку нужно поддерживать состояние регистра в актуальном состоянии...
#3 by selenat
А теперь продолжим. Для выяснения некоторых вопросов бывает полезно брать остатки на 2 момента времени - на дату документа (который правим или вводим новый) и на ТА. Приведу 2 примера.
#4 by selenat
1. Вопрос о том, требует ли наша правка задним числом восстановления последовательности по данному набору измерений. Рассмотрим ввод задним числом нового расхода. Находим ту партию, которая должна списываться нашим документом согласно ФИФО. И смотрим - есть ли на остатках эта же партия в достаточном количестве на ТА. Если эта партия есть и на момент документа, и на ТА в количестве, указанном в этом документе, то восстановления последовательности не нужно, поскольку с момента документа до ТА не было перехода в списаниях с одной партии на другую.
#5 by а лю 427
одна фраза в "Для выяснения некоторых вопросов бывает полезно брать остатки на 2 момента времени - на дату документа (который правим или вводим новый) и на ТА. Приведу 2 примера." и все - дальнейшее - просто мусор.... На дату документа - очень медленно будет Алгоритм получится рабочий, но страшно тормозной... дальше обсуждать бессмысленно
#6 by selenat
2. О той самой ложке дегтя. Вводим задним числом новый приход. Поскольку по ДатаПрихода у нас должен сохраняться принцип ЛИФО, то возможно часть расходных движений нужно перекинуть на этот новый приход. А именно те расходы, которые идут в промежутке от этого нового вводимого прихода до следующего приходного движения (которое уже было в базе). Определить - требуется ли такое перераспределение, можно анализируя остатки партий на момент этого вводимого нами прихода и на ТА. Надеюсь, сами сообразите как. Если нет, объясню...
#7 by selenat
не дольше, чем стандартный контроль остатков в типовых...
#8 by а лю 427
а надо - быстро....
#9 by selenat
намек понял. Буду продумывать дальше...
#10 by а лю 427
смысл городить всю систему контроля в онлайте - есть только тогда, когда это - быстро....
#11 by selenat
оно конечно так. Но и обеспечение беспроблемного восстановления последовательности (неухода в минуса при восстановлении), работающее по скорости как стандартный контроль остатков или стандартное списание партий (когда они списываются сразу при проведении, а не отложенно), имхо уже неплохо. Во всяком случае пока радикального решения проблем не видно, улучшение типовых механизмов - уже хлеб...
#12 by а лю 427
думай... на самом деле все твои рассуждения уже дают основу решения - только правильно сложить надо...
#13 by selenat
да я и чувствую, что "истина где-то рядом". :)
#14 by Terv
а если пользюку ругнуться на то, что нельзя такое вставить? типа давай сам распроводи? PS. мне кажется не кошерно менять движения, без ведома... пользователь должен отвечать за свои вставки задним числом, а не систем
#15 by Terv
ЗЫ. а я что пропустил ветку? Пошел читать
#16 by selenat
ну, видишь ли, приходное движение всегда безопасно с точки зрения возможности восстановления последовательности. Это дополнительные расходы не всегда возможны. Ты ведь не заставляешь пользователя рспроводить все документы в стандартном механизме, чтобы он потом мог восстановить последовательность.;) Вообще говоря, так можно и всю систему парализовать. А разгребать каждый раз все равно будет программист...
#17 by selenat
да там почти все - бред. Можешь конечно перечитать, если время есть...
#18 by Terv
Пит уже указывал на то, что ввод задним числом, это всегда исключение ... что с этим делать, то? если цель себестоимость, то может быть пофиг, что он спишется не по порядку вряд ли проверяющие найдут ... а если партионка предписана законом то, что придется менять документы всем покупателям .. это тоже система должна сделать?
#19 by Terv
+ здесь единственно, нужно определить ... нарушает ли ввод задним числом последовательность или нет, что бы лишний раз панику не разводить.
#20 by Terv
я так по названию темы и подумал, даже заходить не стал.
#21 by selenat
и если нарушает, то просто запрещать? Боюсь, что за такие механизмы меня повесят за еггс...
#22 by Terv
я думаю нужно просто сообщить в каких документах нарушается последовательность  ... а дальше на выбор: - либо нарушаем последовательность списания - либо распроводим руками мешающие нам документы. права ессно на такую операцию только у избранных.
#23 by Terv
а ты объясни гл. бух всю соль .. если она у тебя толковая, то я думаю она скажет, что пусть пользователи распроводят. у тебя что ввод задним числом ежедневная операция?
#24 by selenat
указывать документы - это уже вряд ли возможно. Это уже движения анализировать надо - долгий процесс. Сам факт нарушения можно отследить достаточно быстро, а вот найти эти документы - уже долго...
#25 by selenat
речь об универсальном механизме. Вот стандартная последовательность, при всех своих сильных недостатках, - механизм достаточно универсальный...
#26 by Terv
ИМХО возврат товаров от покупателя и приход это всегда индивидуальна ... у меня допустим возврат всегда идет задним числом и это всегда брак ;)
#27 by Terv
* возврат товаров от покупателя и приход задним числом это всегда индивидуально и универсальное решение здесь не придумаешь. и вообще если у тебя не было прихода, то ты не имеешь права его продавать !.
#28 by selenat
приход мог быть. Остатка могло хватать. Но при дополнительном приходе, введенном задним числом псоледовательность уже могла нарушиться...
#29 by Terv
тогда у тебя это последовательность только для себестоимости ... а не предписанная законом...
#30 by Zixxx
И зачем тогда последовательность, лепите партии налету, запросом.
#31 by selenat
почему это?
#32 by Terv
ну если у тебя допустим ГТД, что ты тогда отдовал покупателю?
#33 by selenat
да, я помню про эту проблему. Но пока отложил ее на край сознания...
#34 by YauheniL
А если не вести партионный учет в том виде, в котором его предлагает 1с? А данные по партиям рассчитывать, когда это надо (момент вычисления себестоимости, например) а отчеты по себестоимости формируются уже по закрытым периодам по расчитанным данным
#35 by selenat
отлучусь ненадолго...
#36 by selenat
как это отменяет работу задним числом и необходимость перепроводить (если не первичные доки, то регламентный док, что сути не меняет)?
#37 by Регистратор
у вас там в ростове небывалый урожай на идеи по партионнуму учету
#38 by selenat
выполняем план за всех...
#39 by YauheniL
За работу задним числом в закрытых периодах нужно делать лоботамию без наркоза (по крайней мере, если заметят соотв. органы, что у организации меняется себестоимость продукции в течение года (т.е. в течение года за один и тот же месяц получаются разные данные), то это просто "полный вперед" => посадят всех несущих ответственность) Так вот, если абстрагироваться от работы задним числом в закрытых периодах, партионный учет нужен для более правильного расчета фин. результата (себестоимости) -- зависит от вида деятельности предприятия. До расчета "параметра" нас, в принципе, не интересует, какие документы и каким образом проведены. После расчета "параметра" период с расчитанной себестоимостью закрывается для работы пользователей. Если при расчете "параметра" возникает косяк (нет остатков на складе), тогда ситуацию надо решать сразу же, ибо это ошибка ведения учета Но такой подход противоречит стандартному подходу, предлагаемому 1С.
#40 by selenat
все не совсем так имхо. Во-первых, на самом деле исправлять инфу в периодах, по которым уже сдана отчетность в налоговую, можно. Нужно только подать в ту же налоговую исправления. Это раз. Во-вторых, конечно, исправлять ошибки прошлых периодов сегодняшними корректировками (типа сторно и т.д.) - это хороший подход. Но если бы это всегда было так просто, то и проблемы бы особой не было. Тогда даже за текущий период запрещаем всю работу задним числом и делаем все корректировками на ТА. Красиво? Да. А сможешь реализовать так, чтоб при всем многообразии возникающих ситуаций не парализовать работу фирмы? Не так то это на самом деле просто имхо...
#41 by selenat
Я все-таки хочу вернуть внимание всех к основной идее, изложенной в первых постах. Еще раз в двух словах. Монотонность функции остатка и списание по принципу ЛИФО дает нам возможность получать некоторую дополнительную информацию. После нового прихода мы остаток по старым партиям как бы "замораживаем". В результате по инфе на ТА (когда все итоги расчитаны) можно анализировать возможность или невозможность ввода определенных изменений задним числом. И ошибочные изменения задним числом резать сразу в момент ввода. Сейчас Пит намекает, что при правильной организации работы с регистрами можно вообще всю необходимую для анализа инфу получать на ТА. Подумайте над такой возможностью. Вообще, Пит в подобных ветках дает немало инфы. Вот только кто бы ее анализировал? Все обращают внимание только на то, что их назвали дятлами...
#42 by YauheniL
Про просто никто и не говорит... я говорю о том, что 1С предлагает всегда поддерживать себестоимость в разрезе партий в актуальном состоянии, что не всегда оптимально в силу разных причин. Гораздо лучше было бы считать себестоимость в конце учетного периода, сохранять результат, при необходимости к нему обращаться. Как я вижу эту схему: - документы прихода/расхода вводятся без всяких ограничений - документ "Закрытие периода" (например) расчитывает себестоимость и сохраняет ее .... куда нибудь - отчеты и остальные документы пользуются полученным результатом.. Позволю себе процитировать товарища : "Никакого секрета нет. Как правильно сказал <33> Вы должны четко разделять понятие "партионный учет" и "определение себестоимости".  Суть метода - отказ определения партий списания в момент проведения. В 99% случаев в момент проведения партии списываются не правильно (ГП стоит не там), поэтому в этом списании нет никакого смысла.  Если вам в какой-то момент надо определить доступные партии товара, или посчитать отчет с себестоимостью, то просто делаете виртуальное списание в момент формирования отчета. Это конечно тормозит отчет, но поверьте не существенно. Эти замечания касаются случая "определения себестоимости". А случай "партионного учета" неплохо реализован в ТИС, это когда вы явно указываете партию товара. <161> Конечно партионный учет в бухгалтерии - ЗЛО. А в управленческом учете чаще всего не нужен" ИМХО, в таком методе есть один минус: отчеты строятся слишком долго, если каждый отчет будет рассчитывать все данные с нуля. А если результат периодически сохранять, тогда производительность можно существенно повысить. Но чтобы сохранить промежуточный результат, требуется обеспечить неизменность тех данных, на основе которых он получен
#43 by Terv
ну в прошлой ветке Коллайдер развлекался... вандал.
#44 by selenat
Коллайдер и есть Пит...
#45 by Terv
гы... он ник отобрал, прикольно
#46 by selenat
интересный подход конечно. Но обеспечение неизменности данных для множества реальных ситуаций, которые могут возникнуть, вызывает у меня определенные сомнения...
#47 by Terv
давно известный подход ... нечего интересного. это не метод Пита.
#48 by selenat
а вообще, наверное это неплохо должно работать в сочетании с идеей типа той, что в первых постах озвучена...
#49 by Terv
+ ЗЫ. честно говоря надоело одно и тоже по кругу обсуждать.
#50 by selenat
само по себе действительно не интересно. Но это вполне может быть элементом мозаики. Т.е. правильная организация регистров и анализ инфы в сочетании с этой идеей может быть более продуктивным...
#51 by а лю 427
Списание партий и определение себестоимости в конце периода - лет 12-15 назад сделано в БЭСТе.... повторено пару лет назад в УПП, при этом решение в УПП подано как супер-пупер-инновация...
#52 by selenat
ну, я ведь создал ветку не для обсуждения всего, что связано с партионным учетом. Я опсиал конкрентую идею, с конкретной проблемой в реализации. По-моему раньше никто не описывал этого в таком виде. Поэтому и пытаюсь направить развитие мысли в четко определенном направлении...
#53 by а лю 427
"ИМХО, в таком методе есть один минус: отчеты строятся слишком долго, если каждый отчет будет рассчитывать все данные с нуля. А если результат периодически сохранять, тогда производительность можно существенно повысить. Но чтобы сохранить промежуточный результат, требуется обеспечить неизменность тех данных, на основе которых он получен" по крайней мере в БЭСТе расчет делается при закрытии месяца. И закрытие месяца в БЭСТе очень жесткое - все, ракета улетела и править просто нельзя...
#54 by Terv
я про год назад мы это уже обсуждали, странно что ты этого не помнишь в УПП сейчас 2 решения и не одно из них не похоже на первое это обычное развитие 7го .. списание по факту + корректировка регл. документом 2е очень похоже результат нашего прошлогоднего обсуждения.
#55 by selenat
у меня вообще плохая память. Видишь ли, один и тот же элемент, встроенный в разную идеологию может выглядеть совсем по-разному. Сейчас например я рассматриваю эту идею в сочетании с тем, что написал в первых постах...
#56 by Terv
весь сыр-бор ты здесь развел из за необходимости иметь себестоимость оперативно, если она в течение месяца не нужна, то идеально подходит регл. документ в конце месяца и "не надо лохматить бабушку" ... Вообще неплохо бы определиться с ответами на след. вопрос: - Нужна ли нам оперативная себестоимость, если нужна, то зачем? - Нужен ли нам партионный учет. Если нужен, то есть ли он реальный на складе или он просто виртуальный для целей себестоимости. - Чем обусловлена работа задним числом.
#57 by Пеппи
хм
#58 by Terv
+ если мы будем обсуждать сферического коня в вакууме, то получим аналог бредового решения от 1С. и ты к нам решила присоединиться?
#59 by Холст
тоже поклюю
#60 by Oleg_Nik
Делал нечто подобное на 7.7 Измерение ДатаПрихода лишнее - дату можно брать прямо из партии.. Из плюсов 1) работает на порядок (!) быстрее, 2) регулярное восстановление последовательности  можно забыть как страшный сон. Из минусов 1) последовательность списания партий может быть нарушена. Решается либо учетой политикой  "а хр.. найдут!", либо все же препроведениями перед закрытием периода. 2) Иногда возникает ситуация когда на момент списания партия есть, а не списывается патаму что уже списана позже. Придется приучить пользователя смотреть списания после текущего, это непросто... 3) В 8-ке мне показалось проще перепроводить все списания при измении задним числом прихода, благо это теперь можно.
#61 by selenat
не катит дата из партии. Почитай еще раз внимательно идею. У тебя один и тот же товар из одной и той же партии может приходить на один и тот же склад несколько раз. И нельзя все эти приходы сваливать в кучу, необходимо монотонное убывание функции остатка. А у тебя будет увеличение остатка по тому же приходному документу....
#62 by Terv
партионный можно вести без складов, для фирмы в целом.
#63 by Oleg_Nik
да, наверное. У нас партии от складов отдельно.
#64 by selenat
не имеет значения. Имеется в виду произвольный набор измерений. Можно это считать одним измерением многомерного пространства и рисовать плоский график - время/количество, имея в виду изменения по набору конкретных значений измерений, сколько бы их ни было...
#65 by YauheniL
А если партия -- сам документ прихода? Тогда естественным путем оператор не оприходует один и тот же товар несколько раз одной партией
#66 by selenat
для изложенной идеи тоже не имеет значения. Прорблему можно рассматривать в общем виде...
#67 by Terv
ну я так в частности, а то человека запутаешь. Ессно измерение лучше ... и запрос легче и прозрачнее.
#68 by selenat
можно так. Просто требование списания по ФИФО относятся к внешним для нас приходам, а движение прихода (которое в этом случае создаст нам новую партию) может быть внутренним документом (перемещение, корректировка серий/характеристк и т.д.)
#69 by selenat
согласен. Просто я его скорее сейчас запутаю абстрактными рассуждениями, было проще сказать про товар на складе.
#70 by YauheniL
Мне кажется, что корректировочные документы не должны образовывать партию в таком случае, т.е. документ "Перемещение товаров" должен находить партию и менять у нее склад, но тогда склад должен быть разрезом аналитики
#71 by Oleg_Nik
Не, не понял. При списании проверяешь осткти по складам на ТА, тоже, ессно. Те. после каждого проведения списания у тебя на ТА отрицательных остатков не будет. Если задним числом меняешь складцену в поставке или перемещении, ну так это по любому надо отдельно проверять.
#72 by Oleg_Nik
Имхается мне что ты себя запутаешь абстрактыми рассуждениями ;-)
#73 by Terv
поперемещай товар между складами туда -обратно и твоя проверка с фильтром по дате прихода (документа партии) не будет работать корректно именно поэтому и вводиться новое измерение "Дата прихода(пуступления)".
#74 by Oleg_Nik
Склады отдельно от партий =  при перемещении между складами регистр партии вообще не трогаем.
#75 by selenat
абсолютно точно. я сейчас не веду речь о том, какой набор стандартных измерений используется. В 8 есть склад, в 7 МОЛ. Можно вести или не вести учет в разрезе организации (т.е. иметь ее измерением), можно вести или нет серии и характеристики. Так вот возьми стандартный набор измерений любой из этих конф и считай весь этот набор одним измерением многомерного пространства. И по значению в этом измерении у тебя есть только приходы и расходы во времени. Все.
#76 by Terv
тогда ты обсуждаешь частный случай... но и в твоем случае придется создавать отдельную партия для возвращенного товара.
#77 by selenat
читаем . Неважен набор измерний. Важно, чтобы по этому набору каждый приход создавал новую партию, чтоб после этого она только монотонно убывала...
#78 by selenat
Кому -нибудь кроме Терва принцип идеи ясен? Или я слишком сложно изъясняюсь?
#79 by Terv
гм... ты же знаешь, что всем читать лень, лучше свой бред нести "чукча не читатель, чукча писатель" - типичный портрет мистянина. ;)
#80 by Oleg_Nik
Читаем ;-). А если серьезно, то идея вполне рабочая. +- полученые на практике.
#81 by YauheniL
Кстати, всплывает нюанс: реализуем товар по ЛИФО. Далее покупатель нам его возращает: а) если мы "отмотаем" ленту партий назад и найдем нужную, тогда возврат портит нам картину монотонного убывания ункции б) если мы создаем партию, тогда может быть такое, что эта партия будет реализована тогда, когда будут реализованы другие партии с датой возврата (но ведь эта партия намного старше). Если идет реализация чего-либо без сроков годности -- ладно. Иначе, можем продать просроченный товар
#82 by selenat
да я то ясно понимаю смысл того, что говорю. :) Мне просто надоедает спорить о том, ведем ли мы этот учет по складу, Молу или еще чему-нибудь. Хочется наконец самой идеей заняться... Так как ты на практике это используешь, если у тебя функция остатка не монотонна? В этом случае данные на ТА тебе ничего не могут дать....
#83 by Oleg_Nik
"отмотать" без вариантов. "монотоннаое убывание функции" это лишь слова,  скрок реализации, даже если нет срока годности реальность.
#84 by YauheniL
, Хотя есть вариант создания новой партии, но с датой, узнанной после "отмотки"
#85 by selenat
погоди. По измерению ДокументПоступления у нас идет списание по ФИФО (как того и требует учетная политика). Это по нашему служебному измерению (ДатаПрихода например) списание идет по ЛИФО. И любой возврат, перемещение и что угодно еще (любое приходное движение) будет создвать по этому измерению новую партию. Именно для того, чтобы обеспечить дальнейшую монотонность. Без нее ничего работать не будет...
#86 by selenat
+85 Т.е. мы не отматываем назад и не ищем нужную, а создаем новую с текущим ДатаПрихода...
#87 by Oleg_Nik
Система работает нормально уже далеко не первый год ( с учетом  ..) Поясни еще раз что ты понимаешь под монотонностью функции остатка и в чем ты видишь проблему, попробую ответить.
#88 by selenat
Под монотонностью я понимаю то, что после создания новой партии в момент прихода, количество по этой партии должно только убывать. Если в какой-то момент после прихода ты увеличиваешь количество по этой же партии (за счет перемещений, возвратов и т.д.), то инфа на ТА тебе уже не даст ничего...
#89 by YauheniL
Функция остатка имеет начальное значение, отличное от нуля. И не возрастает
#90 by Регистратор
А вот пара простых вопросов: 1.можно запросом вытянуть все сочетания документ x номенклатура где нарушен принцип фифо? 2.с измерением последовательности по номенклатуре слабо написать восстановление движений по регистру с учетом фильтра по списку номенклатуры партий без проведения документа?
#91 by Oleg_Nik
а возвраты??? для меня базовая идея проста как мычание - остатки проверяем на ТА и гарантируем что после любого списания минусов _на ТА_ не будет. Исправление поступлений проверяем отдельно. Сосбвенно все. Результат см выше.
#92 by selenat
вот и я тебя спрашиваю "а возвраты"? Если ты их пихаешь в ту же партию, что была, то на ТА инфа бесполезна. Ради этого я и говорю про еще 1 измерение ДатаПрихода, поскольку именно из-за возвратов например ДокументаПоступления с его датой недостаточно. Именно поэтому и надо создать новую партию с тем же ДокументПоступления, но новой ДатаПрихода...
#93 by Terv
г... вопросы.
#94 by Oleg_Nik
1. непросто 2. В 7-ке нельзя было провести другой документ из обработки проведения, в  8-ке мне тоже кажется что такой подход лучше. Правда я всеж перепровожу док полностью.
#95 by selenat
+92 грустно мне...
#96 by Регистратор
полное проведение может быть намного дольше чем проведение только по одному регистру
#97 by Terv
вот и я о том же, каждый год одно и тоже ... вообще удивляюсь как pit за 10 лет не удавился еще.
#98 by Регистратор
честное фифо может потребовать проведение бороды из последующих документов которая может быть довольно длинной, можно сократь вероятность этого эвристическими способами, но проблема все равно остается. Он лайн закладываться на восстановление этой бороды рисковано, тотже поправленный приход может создать необходимость переделать движения у тысячи документов :)
Тэги:
Ответить:
Комментарии доступны только авторизированным пользователям

В этой группе 1С