Задачи класса ERP, которые не решаются на 1С
БТР
07.06.2002 - 19:31
Как и обещал, открываю новую ветку.
Вот что написал
mazzy
283 - 07.06.2002 - 19:15 Тот 282: "Он знает, что никто ничего конкретного не скажет. Потому как давно бы все это известно было. Что вот нельзя решить задачу в 1С, сформулированную в терминах учета - и все тут."
.
Вот, Тот, БТР, это задачи, которые не решаются на 1С.
1. трехвалютный учет в бухгалтери (mazzy.ru/exercise/tt/multicurrency/);
2. будущие (плановые, бюджетные) проводки на регистрах, не запрашивая информацию с начала деятельности предприятия;
3. работа со временем во всех компонентах 1С (учет времени, планирование времени, календарное планирование не только по датам).
.
Решайте сколько пожелаете... хоть с нуля ваяйте... если будете привлекать компоненты, то обоснуйте и обясните где кончается 1С и начинается нестантартная программа :)
.
Если вам не нравятся ограничения (например, в п.2) то обоснуйте стоимость решения без этих ограничений.
.
Уверен, что решите. Вы же все можете. Только объясите пожалуйста стоимость вашего решения и стоимость поддержки. Хотя бы в часах работы.
.
Про типовые даже говорить не буду...
БТР
1 - 07.06.2002 - 19:33
ВОт то, что ответил
БТР
284 - 07.06.2002 - 19:29 (283) Не так быстро, mazzy :)
Будь добр, ставь вопросы не технические, а аналитические. Иначе, мне не совсем понятен смысл этих задач. Короче говоря, ЗАЧЕМ ты считаешь необходимым применять перечисленные тобой технические решения.
Конкретно.
1. В каких ситуациях нужен трехвалютный учет (пойду, посмотрю, что там у тебя по ссылочке)
2. Что ты подразумеваешь под будущими проводками на регистрах, конкретный пример, пожалуйста
3. Приведи, пожалуйста конкретный пример с использованием времени, судя по тому, что тебе нужно - сквозной, то есть, бизнес-процесс, в котором время появляется и бизнес-процесс, где затем это время используется.
ex-Alex
2 - 07.06.2002 - 19:38
По п.1 - в случаях работы и импортом. Есть валюта бух. учета - мы в России. Есть валюта корпоративного учета - очень уж хочется наши тугрики посчитать вне зависимости от цены на нефть или наличия свободных остатков на корсчетах банков. Есть валюта обязательств перед поставщиками. Они, мерзкие, накак в рублях считать не хотят. И по курсу ЦБ. И еще норовят каждый в своей валюте.
БТР
3 - 07.06.2002 - 19:43
(2) то есть, мы имеем, в общем случае, аналитику по валюте учета, историю изменения отношений различных курсов друг к другу, остатки денежных средств в различных валютах и операции, которые производятся в разных валютах. Верно? Теперь, подкинте мне для затравочки первую проблемку. Что не так при работе с валютными счетами? (Прошу прощения, я не работал с импортом и экспортом как бухгалтер, поэтому буду вникать по ходу дела, окей?)
ex-Alex
4 - 07.06.2002 - 19:51
Тут не важно знание экспорта-импорта. Суть в трех суммах одновременно. Причем курс пересчета не принятый в 1С. Т.е. курс USD к рублю и затем курс рубля к EUR не равен курсу USD к EUR. т.е. нужны кросс-курсы. Кроме того еще одна проблема - так называемые "согласованые курсы". Т.е. в договоре может быть оговорено, что при платеже с валютного счета может применятся некий нестандартный курс. Получается, что нужно еще и три курса хранить (хотя тут не уверен - только сейчас ковыряю эту гадость - без детального анализа не могу утверждать на 100%)
mazzy
5 - 07.06.2002 - 19:55
1. сходи все же по ссылкочке :). Это нужно для учета в корпоративной валюте. Если проще, для цветного учета.
2. план/факт на регистре. :) Ты уже отвечал в этой ветке. Я тебе уже говорил, что твое решение неприемлимо по производитльности.
3. я уже говорил. например, планирование производственных процессов.
Ок. я туда же (в эту ветку) помещу ответ...
ЗЫ по первой задаче тут уже копья ломали. решения нет до сих пор :)
БТР
6 - 07.06.2002 - 20:20
(5) 1.По ссылочке сходил. Сходу в проблему не врубился. Пообсуждаем (см. ниже)
2. Давай поподробнее. Мне нужна конкретная операция (или набор операций), когда возникает необходимость план/факта на регистре. Чтобы мозгом по древу не растекаться :)
3. Хорошо, планирование производственных процессов. Это широко. Пожалуйства, приведи один пример, в котором время появляется, а затем для чего-то используется. Ладно?
(4,5) Так, хорошо. Допустим, я имею валютные счета в долларах, евро и фунтах-стерлингах, имею пяток контрагентов (допустим - поставщиков), кроме того, имею собственную корпоративную валюту (допустим у.е.) в целях нормализации корпоративного учета, и государство требует от меня вести учет в национальной валюте (в данном случае - рубли).
Я имею на счетах 52 и 60 валютный учет, так как необходимо в конкретных валютах знать свои остатки и результаты взаиморасчетов. Так же мне нужно эту же информацию знать в корпоративной валюте для финансового учета, причем, задана определенная регулярность пересчета остатков в корпоративной валюте (допустим раз в день, по утвержденным корпоративным курсам к этим валютам). И также мне нужно иметь эти показатели в национальной валюте в целях бухгалтерского учета, причем, существует ПБУ, по которым раз в месяц (?) производится переоценка показателей в рублях по курсу (какому, кстати? ну считаем, что этот курс у нас заводится).
Далее, я получаю от поставщиков товары, при этом я должен по бухгалтерскому учету приходовать товар в национальной валюте по курсу (видимо тому же, по которому делаются переоценки? или нет?). Но я еще хочу в целях финансового анализа оценивать свои запасы в корпоративной валюте (рассчитывая по курсу валюты поставщика к корп. валюте, или же из нац. валюты?). Ну и кроме того, существуют курсовые разницы, когда необходимо переоценить стоимость товаров, если оценка в корпоративной валюте изменилась по результатам взаиморасчетов.
Это правильный сценарий? Что я упустил? Какие альтернативы необходимо использовать?
Давайте утвердимся и пойдем дальше.
БТР
7 - 07.06.2002 - 20:26
(доп. к 6) Так. Еще мы имеем случаи, когда взаиморасчеты происходят не в валюте поставщика, а в другой, в этом случае у нас фиксируется курс этих двух валют друг к другу, а сумма в национальной и корпоративная валюте зачитывается по курсам ... каким?
БТР
8 - 07.06.2002 - 20:37
Немножечко отойду от стандартной парадигмы валютного учета в 1С. Предполагаю, что валютный признак счета не используется. Будем двигать в пределах баланса и забаланса.
То есть, имеем такие счета:
41 Товары на складе в руб
*41 (заб) Оценка товаров на складе в у.е.
52 Валютные счета, оценка в руб
*52ЕВР (заб) Валютные счета в евро
*52ЮСД (заб) Валютные счета в долларах
*52ФСТ (заб) Валютные счета в фунтах стерлингах
*52(заб) Валютные счета, оценка в у.е.
60 Взаиморасчеты с поставщиками в руб
*60ЕВР (заб) Взаиморасчеты с поставщиками в марках
*60ЮСД (заб) Взаиморасчеты с поставщиками в долларах
*60ФСТ (заб) Взаиморасчеты с поставщиками в фунтах стерлингах
*60 (заб) Взаиморасчеты с поставщиками в у.е.
80 Курсовые разницы в руб.
*80 (заб) Курсовые разницы в у.е.
81 Переоценка валют в руб.
*81 (заб) Переоценка валют в у.е
Есть замечания по такой структуре?
БТР
9 - 07.06.2002 - 20:39
Во избежание путаницы, предлагаю считать, что реальных движений в рублях не происходит, а все рублевые счета являются оценкой в целях бухгалтерского учета.
mazzy
10 - 07.06.2002 - 20:51
Ага все правильно.
Есть только одно но:
существуют объекты учета, которые НЕЛЬЗЯ переоценивать. Например, ОС, Например, себестоимость товаров.
.
поэтому для таких объектов сальдо в корпоративной валюте принципиально НЕЛЬЗЯ получать из сальдо в национальной валюте (или любой другой) по текщему курсу.
.
2. Опа. Как это? План/факт продаж, например. По группам, номенклатурам, датам, клиентам с сезонными колебаниями, с альтернативами процей чешуей. Самое главное, что факт делается на регистре. :) Поэтому чтобы было удобно сравнивать план тоже логично сделать на регистре. Причем структура планового регистра должна быть как можно ближе к фактическому регистру - тогда сравнение и сопоставление делается быстро и удобно.
.
3. Я уже приводил.
Есть производственный процесс. Он описывается как последовательность операций (возможно граф). Каждая операция выполняется определенное время (минуты, часы). Между операциями возможны простои.
Когда будет изготовлена определенное количество готовой продукции? И прочие аналогичные вопросы... Посмотри в прошлую ветку.
Прибой
11 - 07.06.2002 - 20:53
Где говоришь астираханские шилюхи№;%:?
mazzy
12 - 07.06.2002 - 20:55
Иэх... Эту схему предложил Галимов уже давным давно.
Проблема в том, что ты не моежшь получить одновременно сколько ЕВР было в операциях с ЮСД :)
Я же все расписал...
.
Ты не торопись...
Тут уже несколько человек говорили, что в полчаса наваяют.
Около года прошло, ни один еще не сделал. Спроси у Галимова, если будет необходимо.
БТР
13 - 07.06.2002 - 21:06
(12) А я и не тороплюсь. Я хочу понять, в чем тут фишка. (С) МэндМс.
Насчет "не можешь получить одновременно сколько ЕВР было в операциях с ЮСД" - не понял, что за операции? Приведи пример?
(11) Отбой!
(10) Постой, постой, с переоценкой не спеши. Каждая переоценка имеет свой смысл и свой регламент. С чего ты взял, что я собираюсь что-то необоснованно переоценивать? Из чего вытекает твой вывод? Я не умею читать мысли и не понял относительно чего твое замечание
2. Постой, тут дело не в регистрах и структуре их. Я не понял, причем здесь будущие проводки. Вернее, даже в том, зачем нужны будущие проводки в системе. Давай начнем все-таки с конкретной ситуации. Хорошо?
3. Так, хорошо. Мы имеем некое описание производственного процесса. Имеем длительность каждой операции процесса (например в секундах). Имеем итого в секундах. Считаем по формуле НЕОБХКОЛДЕТ/КОЛДЕТВСЕК. Переводим секунды в месяцы, дни, часы, минуты. Расширь проблему. Пока затыка не увидел.
mazzy
14 - 07.06.2002 - 21:22
1. Пример... Если честно, то второй раз я на это не поведусь :) Я в прошлый раз объяснял долго-долго. Потом сделал пример и страницу на своем сайте. Смотри туда. Если будут вопросы, готов ответить.
.
Насчет переоценки. Это я заранее. :) Опять же таки по опыту прошлой дискуссии. Если не собираешься необоснованно переоценивать, тогда все ок. Задача понята правильно.
.
2. Молодец. Хорошая школа. Ты, наверняка хорошо работаешь с клиентами.
Только я говорю о классе задач. Этот класс называется план/факт. План - это будущие данные. Факт - прошлые. Для того, чтобы записывать план мы должны записать данные в будущее. Кроме того, мы должны иметь возможность суммировать, разные планы и т.п.
.
3. Затыка не увидел? Ню-ню. Т.е.
= пользователь должен вводить в секундах?
= может ты забыл о том, что "месяцы, дни, часы, минуты" надо переводить в секунды?
= на вопрос когда будет готово будешь отвечать через 60000 секунд? или будешь дату переводить в секунды, прибавлять секунды и переводить обратно в "месяцы, дни, часы, минуты"?
= что еще ты забыл?
:)
Т.е. тебе нужны будут функции преобразователи. Их будет много. В запросах их использовать будет нельзя, так как серьезно снизится производительность...
.
Назови, пожалуйста, стоимость твоих работ по разработке и ПОДДЕРЖКЕ этого хозяйства и твои прогнозы по производительности.
БТР
15 - 07.06.2002 - 21:39
(14) Подожди ты со стоимостью :) Дай вникнуть.
3. Нет. Пользовательское представление в виде часов, минут, секунд, а хранение и обработка в секундах. Соответственно, все запросы в секундах, а функций только две - туда/сюда. Я не знаю ситуаций, когда необходимо хранить значение не в секундах.
2. Хорошо. Мы имеем класс задач. Согласен. Но этот класс задач можно реализовывать десятками способов. Как конкретно - зависит от того, что требуется сделать. Но, в общем случае я предлагаю не путать дату регистрации операции (не важно, по плану или по факту) и период действия операции. Ты уверен, что компонента расчет не реализовывает необходимую функциональность? (шутка, вообще-то)
Почему не сделать период действия операции аналитикой? Ведь так здорово можно вести группировки и входимость периодов! Можно разные операции планировать, исполнять и анализировать с разной точностью во времени.
Видишь, мы не разберемся с проблемой абстрактно. Нужно взять хотя бы одну конкретную задачу, когда такой способ учета становится неприемлем. И еще. Мне не очень понятна разница между будущей проводкой и текущей проводкой с аналитикой по будущему периоду действия. Назови хоть одну проводку которую ты делаешь будущей датой. Любую. Ради интереса.
1. Я посмотрел туда. И пока не увидел проблемы. Сейчас попробую твой пример переписать в вышеприведенном плане счетов (см. ниже)
Да, спасибо на добром слове.
mazzy
16 - 07.06.2002 - 21:46
3. Понятно. Что насчет стоимости этого решения?
2. Не. давай абстрактно.
= В фактических проводках тоже будем указывать период?
= как насчет произвольного периода?
= если в плане период, а в факте дата, то как делать сравнение? Я понимаю, что можно. Ты скажи о сроках и стоимости.
1. Ок.
Andy22
17 - 07.06.2002 - 22:18
2 slw в предыдущем топике
"Встречная история - был сервер TS 2х400 Celeron загрузка 100% -> 2х600 загрузка максимум 80% быстродействие возросло не на 50, а на 78%. Вывод: апгрейдить нужно критические цчастки.
А насчет $10К за 10мин - при таких объемах система режется на несколько частей. Про это БТР достаточно подробно расписал."
По серверу - естественно, до определенного момента вкладывание денег в x86 сервера очень хорошо себя окупает. У меня вот тоже все же быстродействие увеличилось заметно. Но вот дальше то что делать? Извращаться? Терминал-сервер ставить? Тут кто нибудь знает сколько терминал сервер и полсотни клиентских лицензий к нему стоит?
По поводу разделения на части - нифига подобного. Вопрос надежности решается либо покупкой многократно резервируемой техники (горячая замена винтов, камней, сетевых карт) либо использованием кластеров с общей дисковой подсистемой. Ни то ни другое для 1С не подходит. Что делать, если мне нужно обеспечить количество сбоев не более суток в год?
Когда я пришел на теперешнее место работы тут было на один коакс. сегмент навешено ок. 20 машин и "сервер" на обычной мамке с PII. 1С можно сказать просто не работала. Сейчас естественно нормальная 100Мб сетка из 3 сегментов со свитчами, сервер я уже писал какой. Вместо файловой 7.5 sql 7.7. И все равно пару раз за день на какой нибудь из машин сбойнет. Редко но бывает приходится перезапускать sql сервер. Вы считаете что это приемлемо?
Для сравнения самописная зарплата писаная на Дельфи под тот же SQL за прошлый год сбойнула два или три раза, причем проблема решалась перегрузкой клиента. А такие страшные наряды (которые БТР поминал) считались меньше минуты на 1500 человек. Куда дольше считались налоги, особенно в конце года, но и их расчет в 5-6 минут укладывался. И это все на дохлом P-166 с 16М памяти.
Ну и наконец теперяшняя проблема - в справочнике номенклатуры при нажатии на клавиатуре на букву Д (выбираю номенклатуру с наименованием на букву д) 1Cка виснет намертво, все остальные буквы прокатывают без проблем. Если переделать базу в dbf версию глюк исчезает. Я понимаю что это мелочь. Но что мне делать в текущей ситуации? Писать в 1С? Молиться богу?
БТР
18 - 07.06.2002 - 22:27
1.
01-01 Дт61 Кт51 500 руб
01-01 Дт*61 Кт*51 17,61 у.е.
05-01 Дт61 Кт51 500 руб
05-01 Дт*61 Кт*51 17,57 у.е.
10-01 Дт41 Кт61 1200 руб
10-01 Дт*41 Кт*61 41,52 у.е.
10-01 Дт60 Кт61 1000 руб
10-01 Дт*60 Кт*61 1000/СКД(61)*СКД(*61)=35,18 у.е.
20-01 Дт61.2 Кт52 1290 руб
20-01 Дт*61ДМ Кт*52ДМ 100 ДМ
20-01 Дт*61 Кт*52 48,54 у.е.
30-01 Дт41 Кт60.2 1300 руб
30-01 Дт*41 Кт*60 48,08 у.е.
30-01 ----- Кт*60ДМ 100ДМ
30-01 Дт60.2 Кт61.2 1290руб
30-01 Дт60.2 Кт 81 10 руб (курсовая разница)
30-01 Дт*60ДМ Кт*61ДМ 100ДМ
30-01 Дт*60 Кт*61 48,08ДМ
30-01 Дт*81 Кт*60 0,46 у.е. (курсовая разница)
31-01 Дт*80 Кт*51 -0,46 у.е. (переоценка)
31-01 Дт*80 Кт*60 0,60 у.е. (переоценка)
31-01 Дт80 Кт 52 -10 руб. (переоценка)
31-01 Дт*80 Кт*52 0,92 у.е. (переоценка)
31-01 Дт80 Кт 60.2 -10 руб. (переоценка)
2. Да, в фактических проводках тоже будем указывать период. Просто, соответствующей текущей дате.
=что значит произвольный период?
=сравнение можно делать по точности планирования, то есть, по периоду, которое было задано в планировании.
О стоимости. Ты подожди. Решения ЧЕГО? Написать две функции? Вести учет операции по затратам времени? Ведь это же должно делаться для достижения каких-то целей. А ты говоришь - абстрактно :)
3. Ну, тот же вопрос. Какие задачи мы решаем? План/факт по продажам? Добавляем справочник и субконто Периоды, разрешаем десять уровней, убираем код, расширяем наименование до 100 символов, добавляем три реквизита - НачалоПериода, КонецПериода и дополнительный связывающий реквизит ВключаетсяВПериод. В документе ЗаявкаПокупателю добавляем реквизит ОжидаемыйПериодИсполнения и делаем проводку по дебету забалансового счета
ЗП Заявки покупателей Период Заявка Номенклатура
В документе отгрузки имеем реквизит ПоЗаявке типа ЗаявкаПокупателя, при проведении выбираем аналитику по субконто Период, задав субконто Заявка и Номенклатура, и делаем проводки по кредиту по полученному периоду. Получаем план-факт на счете ЗП. Разумеется, то же можно делать и в регистре ЗаявкиПокупателей.
Ну, какая тут может быть стоимость абстрактного решения?
Вот теперь, можешь сказать, чего в этом решении не хватает?
БТР
19 - 07.06.2002 - 22:32
(17) Без обид. Ты не в колее обсуждения. Давай не будем меряться пальцами. Почему бы не обсуждать конкретные аналитические задачи и их возможные технические решения?
БТР
20 - 07.06.2002 - 22:35
В (18) пока не задумывался над переоценкой. mazzy, как в твоем примере расчитываются суммы переоценки?
БТР
21 - 07.06.2002 - 22:36
(18,20) А, понял. На курс 31-01. Тогда все правильно в моем примере.
На сегодня все. Пошел спать. Жду комментариев.
Andy22
22 - 07.06.2002 - 22:39
2(19) Что то мне кажется что ты опять уходишь от ответа.
Что же касается конкретных аналитических задач - при желании на 1С можно реализовать почти все. Для примера я делал текстовую печать для матричников, с превью и кучей наворотов. Делал очень хитрый многоплановый учет продаж. Но проблема 1С не в возможности/невозможности решения той или иной задачи, а в том что будет ли такое решение целесообразным.
das
23 - 08.06.2002 - 10:58
Многовалютность в бухкомпоненте решается по разному: заводи в справочнике "Валюты" реквизит "Кроскурс" для каждой валюты или подчиняй ему справочник "Кроскурсы", добавляй в план счетов чиловые реквизиты для количесва и суммы по каждой кросвалюте или заведи паралельные планы счетов для каждой кросвалюты. При этом не ломаются даже типовые так, как бухи этого не увидят - они учитывают в валюте операции и нацвалюте. А аналитикам коорпорации добавятся только несколько хитрых отчетов.
Для планирования нужно добавить новую кросвалюту ПУЕ(планово-условная единица) и навешать ей прогнозных кроскурсов.
Возни много (ведь кроскурсы на каждой бирже свои), но аналитикам плотят больше чем бухам.
das
24 - 08.06.2002 - 11:46
Что касается будущего: Стандартные инструменты 1С (проводка, период, ДатаДок, ТА, ГП) служат для описания свершившихся фактов и не могут описать план.
Для плана удобнее дописать в регистр реквизиты типа "Дата", "Смена", "Время"... а снижение скорости компенсировать технологически: покруче машины для немногочисленных планирующих, ВК "Быстрые регистры" и т.п.
Увлечение детализацией плана не всегда оправдано: 20 лет назад сделали календарно-сменное планирование - машина потребовала все заказы запускать в первые 5 дней месяца. Пришлось перейти на циклограммы.
БТР
25 - 08.06.2002 - 12:30
(22) Дело в том, что до того, как обсуждать "потянет/потянет" нужно решить, что конкретно нужно тянуть, не так ли? Вот я и предлагаю перевести проблему в плоскость конкретных задач, конкретных решений и конкретной производительности. Иначе будет пустой флуд, типа "а вот я-то при советах у-у-у" (С) Масяня
(23) Не спеши заваливать техническими решениями. Давай в проблеме разберемся. mazzy вовсе не новичок, чтобы на элементарных проблемах спотыкаться, которые другим на ползуба.
(24) Хм. Это ты в книжке прочитал? Лично я попробовал вести аналитику по периоду и пока не понял, в чем загвоздка с производительностью. Да, и тебе не кажется, что документ "план выпуска" это тоже свершивсийся учетный факт? Чем решать все задачи одним махом, может таки попытаемся разобраться в уже трех означенных?
Dich
26 - 08.06.2002 - 13:25
(17) Ну, по железным ресурсам и их разделению можно столько статей написать...
Есть вариант разделения данных на оперативные данные и данные консолидированные, которые рассчитываются при изменении оперативных. Это даже не столько ОЛАП, сколько концепция - разделить мухи и котлеты, неважно, каким путем. Важно, что эти данные должны быть физически разделены не в пределах одного сервера баз данных, а разных. И тогда все ресурсы подсистемы ввода данных будут нацелены только на ввод информации. Задачи по агрегированию будет выполнять совсем другой сервер. По доступу к агрегированным данным - тоже. Таким образом, даже эта примитивная схема клиент-сервер, где трехзвенкой и не пахнет, может хорошо распределить общую нагрузку на ИС.
А дальше можно привязывать и трехзвенку... Можно также частично переложить нагрузку на ВЕБ-технологии даже в пределах интранет (в этом случае не исключено, что потребуется еще один отдельный сервер для поддержания ИИС, но это реально!). CGI тоже как класс никто еще не ликвидировал... да мало ли... сколько профи, столько и решений проблемы. И не всегда экстенсивных...
Просто еще раз повторяю, за рамки 1С необходимо вырываться, но она еще очень долго будет находится в оперативной части многих корпоративных ИС.
das
27 - 08.06.2002 - 13:40
(25(24)) Увы, для книжек времени маловато.
Учетного содержания в документе "План" - 0.
Я не не навязываю решений - просто показываю, что "означенные проблемы" решаемы.
Гораздо больше проблема при внедрении любой КИС - отчуждение информации. Сосчитать можно что угодно, чем угодно.
- После того как кладовщики начали приходовать-отпускать по машинописным ордерам, накладным, ЛЗК достоверность оперативных остатков поднялась с 0 до 95%
- После того как сборочные цеха начали получать детали в сопровождении машинописных ярлыков, оперативная оценка незавершонки стала доступной с 1-го числа а не с 25-го
- После того как ОГК и ОГТ подключились к PDM, проект цены заказа получаем после зеленого свистка нормоконтролера.
Но сколько крови это стоило!
Оперативная погрешность оценок дежится на уровне 3-5% прикрываясь "острой производственной необходимостью", хотя ее уже можно учитывать при анализе.
P.S. Писать можно кто на чем горазд (или прикручивать чужие дешевые кубики) - важнее способ их использования.
БТР
28 - 08.06.2002 - 15:20
(27) Что ты понимаешь под учетным содержанием? Учетный регистр "ЗаявкиПокупателей" - это учетное содержание?
Рыжий Ап
29 - 08.06.2002 - 17:48
Аппи!
Шаров
30 - 08.06.2002 - 18:09
2(mazzy)
"2. будущие (плановые, бюджетные) проводки на регистрах, не запрашивая информацию с начала деятельности предприятия;"
 
Допустим, запланировали в марте на июнь и провели план мартом. Прошел июнь, появился факт, а план погасился. Надо построить отчет с планом и фактом на июнь. Для этого надо выбрать плановые движения. Но с какой даты. Ведь можно было планировать на июнь и в феврале. Одно из решений - получать движения регистра с первого планового документа в ИБ. Но можно для планового периода (июнь) задать дату, до которой нельзя вводить плановые документы. В примере такой датой могло быть 1-ое марта и, соответственно, максимальный срок упреждения факта – три месяца. Тогда движения плана нужно выбирать только с этой даты. Если не ошибаюсь, так решено в Финансовом планировании от 1С. Интересно как в Корпоративных финансах от Инталева (2АЛьФ).
БТР
31 - 08.06.2002 - 18:54
(30) Не очень понял с информацией от начала деятельности предприятия.
В смысле, что в отчет должны попасть документы по плану, так?
А ЗАЧЕМ? Неужели недостаточно аналитики? Что дополнительного могут дать конкретные плановые документы? Их разумеется можно получить по движениям регистров, но зачем это нужно?
Рыжий Ап
32 - 08.06.2002 - 20:42
Аппи!
slw
33 - 08.06.2002 - 21:36
По поводу многовалютного учета (разноцветного). По моему здесь забыли о таком варианте, как использования нескольких планов счетов (разноцветных).
Шаров
34 - 08.06.2002 - 22:44
(31) Лучше конечно уточнить у mazzy. Я думаю, что в отчет должны попасть не плановые документы, а плановые цифры в разрезе плановых аналитик. Если план фиксируется на остаточном регистре ОУ, то цифры можно получить либо из остатков, либо из движений. В (30) я рассматриваю вариант "из движений".
 
Возможен, наверное, и вариант "из остатков" со списанием цифр из регистра плана регламентным документом. В этом варианте усложняются планфактные отчеты, захватывающие момент списания плана.
 
Возможен, наверное, и вариант реализации учета плана на оборотных регистрах ОУ или счетах БУ, для всех субконто которых установлен режим "только обороты". В этих случаях не нужно проводить регламентное списание плановых цифр из регистра учета плана. Если АЛьФ захочет, то наверняка сможет дать сравнительную характеристику реализации плановых регистров на регистрах ОУ и счетах БУ.
БТР
35 - 09.06.2002 - 13:41
(33) Нет, еще просто не вспоминали :)
(34) Э... Не понял логиги. что именно усложняется в планфактных отчетах? В смысле, что регистр закрывается и увидеть план-факт по остаткам исполненных планов нельзя, так? Можно ведь использовать два регистра - оборотный и остатков параллельно. И получить функциональность бухгалтерских итогов.
SO
36 - 09.06.2002 - 13:58
2(16): Попробую ответить на 2. У нас реализован прием заказов на определенную дату, т.е. текущим числом можно принять заказ на будущую дату. При этом есть возможность строить отчеты по заказам на определенную дату (период) и планировать производство. Тормозов никаких нет. Также не вижу проблем с реализацией заказа на определенный период, т.е. заказ действует с 01.06. по 10.06. Объясни, чем это отличается от плана продаж на определенный период. Если необходимо учитывать период с точностью до минуты/секунды/доли секунды, можно взять на вооружение уже откатанный механизм DATE_TIME_IDDOC у 1С.
Рыжий Ап
37 - 09.06.2002 - 17:52
Аппи!
slw
38 - 09.06.2002 - 18:05
По поводу плановых документов.
Я в своё время эту задачу решил так:
Ввел справочник периоды планирования. В этот справочник писал 1 элемент на 1 период. Там же был периодический реквизит документ планирования в который документы себя записывали в соответствии с датой на которую сделано на которую сделано планирование.
2. В регистр остатков ввер измерение период планирование являющееся этим самым справочником.
После этого если мне нужны плановые цифры берем остатки по нужным интервалам планирования.
А если нужна история планирования то идем в спрапвочник и смотрим какой документ был самым первым для данного периода. С него строим запрос. И всё. Проблема закрыта.
Шаров
39 - 09.06.2002 - 21:36
2(35)
>Э... Не понял логиги. что именно усложняется в планфактных отчетах?
Усложняется способ извлечения данных из ИБ для построения отчета по сравнению с вариантом, описанным в (30). Это предположение.
 
 
>В смысле, что регистр закрывается и увидеть план-факт по остаткам исполненных планов нельзя, так?
 
Практически да. Увидеть план можно, если построить запрос до документа списания плана. Если плановых периодов в одном отчете будет несколько, то и запросов придется делать несколько. Списание плана – это движение на отклонение плана от факта, в случае одного остаточного регистра для плана и факта, либо движение на величину плана, в случае если план учитывается в отдельном остаточном регистре.
 
 
>Можно ведь использовать два регистра - оборотный и остатков параллельно. И получить функциональность бухгалтерских итогов.
 
Можно. Пока кажется, что не нужно. Достаточно оборотов (или движений) одного регистра. Приход – план, расход – факт, разница между приходом и расходом (но не остаток) – отклонения. Если ты делал на двух регистрах и распишешь схему, будет приятно.
 
 
2(38) Тоже вариант. Динамический период упреждения. Гибко. Спасибо. В значение периодического реквизита можно не прописывать документ, ведь этот значение уже установлено этим документом.
БТР
40 - 09.06.2002 - 22:09
Что касается справочника периодов, то у меня сейчас такая структура
Наименование - строка, ДатаНачала - дата, ДатаКонца - дата, а сам справочник 10 уровневый. То есть, в результате, у меня элемент имеет такое полное наименование:
2002/2 квартал/июнь/1 декада/9
Рыжий Ап
41 - 10.06.2002 - 09:58
Аппи!
ex-Alex
42 - 10.06.2002 - 10:03
Народ, ау!! Вы опять в дебри теоретизирования.
Вернитесь на грешную землю. Например к многовалютному учету. Использование разных планов счетов - некий путь решения. Если бы не некоторые но... Переоценка обязательств происходит в двух случаях - на момент выполнения обязательства и на момент составления отчетности. Второй случай - это закрытие периода (или любой произвольный момент в зависимости от правил). Первый критичнее - переоценка должна быть на некий документ одновременно с расчетом курсовых (или суммовых) разниц. Когда данные на разных планах - это вызывает некоторые затруднения. Кроме того самых планов может быть и без валюты несколько - многие, например ведут корпоративный или GAAP.
Кроме того - субсчет для кажной валюты - не выход. Дабавили валюту - добавили субсчет? Например когда нужно хранить суммы в валюте обязательств. Переоценивать то их нужно.
Добавлять в справочник валют дополнительно к курсам кросс-курсы - не выход. Это что, при добавлении новой валюты каждый раз код править? Кросс-курсы в виде подчиненного справочника гораздо лучше.
БТР
43 - 10.06.2002 - 10:26
(42) Ты спокойнее, без спешки. Давай сначала разберемся с проблемой аналитически. Я специально выделил все валютные счета (НЕ СУБСЧЕТА!!!) за баланс - для большей прозрачности и непривязанности. В конце-концов, проблема явно не в технической реализации. Можно хоть количество использовать для учета в корпоративной валюте - какая разница?
Что касается второго плана счетов - можно, но необязательно. Неважно, где вести управленческий баланс в корпоративной валюте - на втором плане счетов, в забалансе, в основном плане счетов с использованием разделителя учета, в регистрах, в журнале расчетов... Все равно - это ОТДЕЛЬНЫЙ от бухгалтерского баланс.
Что касается переоценок - существуют два момента. Во-первых это курсовые разницы (кстати, кто объяснит различие между курсовыми и суммовыми разницами?). Они возникают при изменении курса расчетов или валюты расчетов между моментами оплаты и поставки и рассчитываются непосредственно в момент закрытия расчетов с контрагентом. Так же есть переоценка валютных остатков. Она требуется в момент фиксации остатков (например конец некоего отчетного периода - квартал, месяц, декада, неделя, сутки, смена и т.п.) для уточнения оценки баланса в национальной или корпоративной (управленческой) валюте.
Ни та, ни другая операция у меня не вызывают проблем.
Поэтому я и спрашиваю, в чем проблема многовалютного учета. На мой взгляд все вполне корректно и реализуется, что называется в полтычка. Практически, то, чего нет в типовой - это учет в корпоративной валюте. Для чего добавляем справочник кросс-курсов (валюта1, валюта 2, периодический курс) и в план счетов необходимые забалансовые счета (без валютного признака) из списка:
У01, У02, У04, У05, У10, У20, У41, У43, У50, У51, У52, У55, У58, У60, У62, У67, У68, У69, У70, У71, У73, У75, У76, У79, У80, У81, У83, У86, У90, У91, У94, У97, У98, У99.
И - главное. Перестаем смешивать в одну кучу учет управленческий и учет бухгалтерский.
Какие мысли по данному поводу?
YAndrey
44 - 10.06.2002 - 10:28
Мягко говоря работа с многими валютами сделаны в 1С крайне неудачно, может я чего не допонимаю...
ppson
45 - 10.06.2002 - 10:44
Оппонентам.
1) Многовалютный учет - отсутствие валюты триангуляции
2) Плановые проводки - для контроля, когда один пользователь их формирует, другой проводит (контролирует)
3) Отсутствие времени - геморная проблема но решаема. Касаемо особенностей самого языка
to БТР - касаемо нашей дисскурсии в сабдже 1С и ERP - боюсь что у тебя списание по средней не соответствует ПБУ 5/01.
ex-Alex
46 - 10.06.2002 - 10:47
Я не спешу - я пытаюсь вернуть разговор в нормальноe русло (в том числе преследуя личные эгоистические интересы, но это замнем :)). А то опять флуд пошел.
Различия в курсовых и суммовых разницах по большей части лежат в области терминологии. Вопрос в том кому платим - резиденту или нерезиденту. И чем - рублями или валютой. Предлагаю не углубляться в это несущественное различие. Курсовая (суммовая) разница действительно возникает в момент возникновения (погашения обязательтв). По сути происходит переоценка погашаемого обязательства на момент погашения. Тут ты понял абсолютно правильно. Как и с переоценкой. Которая кроме окончания периода может быть произведена в любой момент - но это опять не важно.
А вот дальше ты, ИМНО, чуть не прав. Давай оставим для простоты только 60 счет. Например мерзкий буржуин поставил нам ТМЦ. В договоре с этим буржуином указана валюта взаиморасчетов - EUR. Мы должны зафиксировать сумму этого обязательства в EUR (валюта обязательства), в валюте бух. учета - RUR и в валюте корпоративного учета - USD.
С кросс-курсом правильно. А вот "без признака валютного учета" - не укладывается :(
tnnick
47 - 10.06.2002 - 10:48
For massy (сори, если не правильно написал имя).
По задаче трехвалютного учета: операции с поставщиком - DM, российский учет - рубли, внутренний учет - USD. Все верно? Или я чего-то упустил? Если все, тогда решение может быть такое: два плана счетов, один для российского учета (руб), другой для внутреннего учета (USD). Расчеты с поставщиком по счету с признаком валютного учета. Чего здесь не будет хватать для аналитической отчетности?
БТР
48 - 10.06.2002 - 10:52
(44) Конкретнее, что именно неудачно? И как должно быть удачно?
(45) 1)Что такое валюта триангуляции? Если она сделана в 1С, то как она выглядит? И как выглядит учет при ее отсутствии?
2) В смысле, что плановая проводка формируется двумя людьми - один формирует, другой проводит? На мой взляд - это в корне не верно. Нигде в мире двойная запись не имеет черновиков. Для таких ситуаций выделяются отдельные счета.
Например
Иванов (начальник отдела АСУ) делает проводку
Дт ХочуЗаказать[Июль 2002][Шариковая ручка][АСУ/Иванов] Кт Бюджет [Июль 2002][АСУ] 5 шт 40 руб
Петров (специалист финансового отдела) делает подтверждающую проводку
Дт Заказы [Июль 2002][Шариковая ручка] Кт ХочуЗаказать[Июль 2002][Шариковая ручка][АСУ/Иванов] 2 шт 16 руб
3) Не совсем понял, что именно в моем списании по средней не соответствует ПБУ 5/01? Можно пример?
ppson
49 - 10.06.2002 - 11:00
Вообще все эти проблемы решаемы средствами языка, просто они буду очень медленно работать.
1) валюта триангуляции - валюта кросскурсов.
2) "Нигде в мире двойная запись не имеет черновиков" - тебе так кажеться. В мире кстати мало где есть принцип двойной записи. Во многих бухгалтерских системах отсутствует корреспондеция счетов как таковая. Контроль нужен за рядом операций: банк, касса и т.д.
Но все это решаемо средствами языка только очень геморно и с потерей производительности.
касаемо средней - у тебя насколько я понял, т.к. пользователи заносят документы строго хронологично, что используется метод расчет мгновенной средней, то есть текущий суммовой остаток МПЗ делится на текущий количественный остаток МПЗ и по полученной себестоимости формируется проводка. Или я ошибся?
Reder
50 - 10.06.2002 - 11:06
По поводу трехвалютного учета. У меня в справочнике валют, кроме курсов еще храняться кросс-курсы относительно валюты корпоративного учета. И соответсвенно идет счет.
YAndrey
51 - 10.06.2002 - 11:09
Ну я буду говорить, что знаю... Кажется в 1С вообще нет многовалютности. Я, например, хочу сделать проводку со счета в долларах на счет в марках, а сумму операции указать в рублях... На регистрах я бы это написал, а вот на счетах...
SerBabah
52 - 10.06.2002 - 11:12
Хм, странно, что Mazzy говорит, "Тут уже несколько человек говорили, что в полчаса наваяют. Около года прошло, ни один еще не сделал."
Мы спорили с ним давно. Я утверждал, что это реализуемо на 1C. И использовал для реализации именно 2 плана счетов с разделителями. Тогда разговор свелся к суммовым разницам, и на этом закончился. Можно ветку даже поискать...
.
В некоторых местах из-за валют проводку можно "расщеплять" на кореспонденции.
ex-Alex
53 - 10.06.2002 - 11:12
То 50. Я же писал уже - решили что-то купить в Монголии - что, нужно реквизит "тугрик" добавлять в справочник?
Reder
54 - 10.06.2002 - 11:14
Не реквизит тугрик, а запись валюты тугрик.
БТР
55 - 10.06.2002 - 11:18
(46)Хорошо, давай в данном конкретном случае сделаем с валютным признаком :)
Дт 41 Кт 60.1 100EUR 2918руб - получили ТМЦ за 100 евро по курсу 29.18
<> Кт У60 100EUR 91у.е. - оценили задолженность перед поставщиком по прямому курсу 1 EUR=0.91у.е.
Дт 60.1 Кт 52 100 EUR 2921руб - погасили задолженность перед поставщиком по курсу 29.21
Дт 60.1 Кт 99 0EUR -3руб - переоценили остаток задолженности перед поставщиком по формуле 100EUR/СКК("60.1","EUR")*СКК("60.1","РУБ")-2921
Дт У60 <> 100EUR 92у.е. - оценили погашение задолженности перед поставщиком по прямому курсу 1 EUR=0.92у.е.
Дт У60 <> 0EUR -1у.е. - переоценили остаток задолженности перед поставщиком по формуле 100EUR/СКК("60.1","EUR")*СКК("У60")-92
tnnick
56 - 10.06.2002 - 11:19
По поводу организации справочника валют. Если нужно иметь курсы валюты по отношению к другим валютам, сделайте справочник валют (как стандартный, только без реквизита курс), сделайте подчинненый ему с реквизитом типа "валюта" и периодический реквизит "курс". Будете иметь кросскурсы любой валюты по отношению ко всякой :)) Нда, придеться переписать функцию вычисления курсов, ну и что? Хотите гибкость - получайте.
БТР
57 - 10.06.2002 - 11:30
(51)
Ни с того ни с сего проводка со счета в долларах на счет в марках не происходит. Обязательно будет две проводки. Например.
Дт 76 Кт 52 100USD 3100руб - проданы доллары
Дт 52 Кт 76 200DM 3150руб - куплены дойч-марки
Дт 76 Кт 99 0DM 50руб - переоценена задолженность контрагента
Dmitry1
58 - 10.06.2002 - 11:32
Я работаю не с самой лучшей на свете ERP системой, но могу сказать, что даже такие системы между собой сравнивать трудно, а вы их с 1С сравниваете. В ERP главное - производительность, что по сути 1С не дает, например сколько 1С будет выполнять запрос по таблице в 1,5 млн. строк без сохранения промежуточных итогов с выборкой по 5-и полям? А эта система выполняет за 15 секунд. Все что тут обсуждается - это методы ввода, а вы попробуйте на данных, хранящихся в 1С с историей за 4 года пропрогнозировать!
ppson
59 - 10.06.2002 - 11:32
57) - опять не прав. в многих стандартах разрешена проводка такая.
Что ты думаешь по поводу:
Дб 60 (USD) Кр 60 (EUR)?
ppson
60 - 10.06.2002 - 11:35
58) - обсуждалась проблема производительности.
уже решена не в пользу 1С.
можешь посмотреть сабдж "ERP и 1С".
Все равно многие уверены в всесилие 1С.
PS
61 - 10.06.2002 - 11:36
(49) Не утерпел. Уж извини.
"Во многих бухгалтерских системах отсутствует корреспондеция счетов как таковая"- абсолютно не согласен... Просто большинство западных программ, если речь о них, сделано по образу и подобию бумажного (журнально-ордерного) учета 30-х годов прошлого века. Там дебет, действительно вносится отдельно, кредит отдельно. Этот геморрррой, они вынуждены компенсировать рабочими местами и жесткой организацией документооборота. И все равно баланс не сходится. У них даже норма есть:).
Баланс должен быть, его не может не быть.
ppson
62 - 10.06.2002 - 11:38
61) - согласен. она кстати и в России живет.
Журнально-ордерную систему еще никто не отменял.
БТР
63 - 10.06.2002 - 11:39
(59) Ну... Если очень нужно, то почему бы и нет? Делай сложную проводку.
Дт 60 <> 100USD 0руб
<> Кт 60 112EUR 0руб
ppson
64 - 10.06.2002 - 11:42
<> - это что?
а если проводка в нац.валюте, а списать надо еще вдобавок пересчитанную по кросскурсам валюту с валютных счетов?
Единственно что я вижу - это реализация через забалансовые счета, а если еще и корреспонденция не нужна, то на 100 через Забалансовые счета. Тогда проблема с составлением отчетности.
Кстати ты мне не ответил на вопрос по средней.
slw
65 - 10.06.2002 - 11:42
Я так и не понял в чем проблема с многовалютным учетом. Допустим нам надо вести два учета: корпоративный в USD и бухгалтерский в руб. Делаем два плана счетов: 1 - корпоративный, 2 - бухгалтерский. Нам клиент осуществил платеж в размере 100 EURO. Делаем проводки (в скобках указан план счетов):
Курс Валюты к руб $ - 30, EURO - 28
(1)Д52 - К62 Сумма 93,33 ВалСумма 100 Валюта EURO
(2)Д52 - К62 Сумма 2800 ВалСумма 100 Валюта EURO
Через 2 дня курс изменился
Курс Валюты к руб $ - 30,5, EURO - 28,5
Фиксируем курсовые разницы
(1)Д52 - К99 Сумма 0,11
(2)Д52 - К62 Сумма 500
То(39) Ну не знаю я что в этот периодическии реквизит писать :)), вот и писал сам документ.
БТР
66 - 10.06.2002 - 11:44
(49) Что касается скользящего среднего - ты совершенно прав, именно так у меня и делается. А в чем проблема?
Что касается баланса - тебя кто-то ввел в заблуждение. Все стандарты международного учета основаны на балансе и парадигме двойной записи.
PS
67 - 10.06.2002 - 11:49
(59) Хотелось бы посмотреть на их оборотку. Вероятно задолженность по разным стронам, в зависимости от валюты:) Чушь откровенная, мягко говоря. Обычная перекладка баланса в другую валюту влечет за собой корректирующие проводки и изменение P&L. Другое дело что ,возможно ,некоторы программы позволяют обозначенную проводку, оставля детали реализации (см. 57) за собой. Но я ничего подобного не видел.
Lazy Stranger
68 - 10.06.2002 - 11:52
Попробую тоже поразмышлять на тему мультивалютного учета.
Итак, мы хотим хранить в качестве остатков (конечного сальдо на счете) сумму в 3 валютах, то есть 3 независимых суммы. Вообще говоря, конечных сальдо по одному и тому же элементу у нас может быть столько, сколько элементов в справочнике "Валюты", единственное неудобство - вместо одной проводки нужно делать несколько (по одному и тому же счету, забалансовые счета не используем) Для учета в основной упр. валюте будем использовать поле "Сумма"(не валютная), для учета в рублях заведем в справочнике специальную валюту "Бухгалтерский учетный рубль", остальные валюты - валюты реальных операций. Операция 5 из примера mazzy.ru/exercise/tt/multicurrency/ будет отображаться двумя проводками:
1) Д61 К52 Сумма 43.00 валюта БухРуб вал.сумма 1290.00
2) Д61 К52 Сумма 0.00 валюта DM вал.сумма 100.00
И собственно всё. На любой момент знаем сальдо во всех валютах без запоминания и отслеживания кросс-курсов.
БТР
69 - 10.06.2002 - 11:54
(64) <> - значит не выбран счет
Что касается проводки в нац.валюте и пересчете - ты имеешь в виду переоценку в корпоративной валюте? Или я неверно понял? Что касается управленческого учета, то конечно лучше делать либо с разделителем учета, либо на другом плане счетов, либо на забалансе, в зависимости от того, насколько детальным нужно делать управленческий учет.
ppson
70 - 10.06.2002 - 11:55
66) - а я и не говорил об отсутствии двойной записи, я говорил об отсутствии корреспонденции, а это две разные вещи немного.
В ПБУ говорить о средней за период:
    Сумма на начало + Сумма прихода за период
Ср = -----------------------------------------
    Кол.на начало + Кол. прихода.
т.е. средняя считается за период (месяц, неделя) и остатки оцениваются исходя из этой средней
ПБУ 5/01 п.18
ppson
71 - 10.06.2002 - 11:59
В Внешторгбанке СССР была такая корреспонденция.
Еще такую же хрень я видел в немецком (или австрийском банке).
Lazy Stranger
72 - 10.06.2002 - 12:01
Дополнение к (68)
В принципе, так как сумма в корп. валюте всегда вычисляется либо через рублевую, либо через валюту операции, можно её убрать во вторую проводку (и констатнту в справочнике валют) и тогда вторую проводку формировать автоматом:
1) Д61 К52 Сумма 1290 валюта DM вал.сумма 100
2) Д61 К52 Сумма 100 валюта УпрUSD вал.сумма 43
slw
73 - 10.06.2002 - 12:02
(69) А как ты собираешься сделать проводку по балансовому счету без корреспондирующего счета? 1С это запрещает. Скорее нужно использовать какой-то транзитный счет.
Lazy Stranger
74 - 10.06.2002 - 12:03
Sorry, вторую проводку читать как:
2) Д61 К52 Сумма 00 валюта УпрUSD вал.сумма 43.00
PS
75 - 10.06.2002 - 12:06
(70) А еще есть учетная политика. А там можно запросто переписать эту формулу, пользуясь тем, что преиод - понятие растяжимое. И вообще, ПБУ несет рекомендательный, а не обязательный характер. Даже ПС можно придумать свой, если кишка не тонка и рыльце сухое и чистое:)
ppson
76 - 10.06.2002 - 12:08
А мне все равно как в ПБУ, это мои клиенты хотят как в ПБУ.
и период хотят год. Вообще эта тема относиться к поднятому в сабдже 1С и ERP наличия многих тысяч проводок по складу и уверениям БТР что в этом нет необходимости.
ppson
77 - 10.06.2002 - 12:10
сорри - период хотят месяц
slw
78 - 10.06.2002 - 12:12
(76) Но вопорос о производительности 1С не относится к данному топику. Или ты не согласен?
ppson
79 - 10.06.2002 - 12:15
78) в какой то степени относиться, но не в вопросах возможности функционала.
Вопрос снимается.
PS
80 - 10.06.2002 - 12:19
(71) Ага. Тогда все понятно. Ты неверно изобразил проводку. Надо так (без двойной записи)
Проводка 1..........Дб 60.USD
Проводка 2..........Кр 60.EUR
С точки зрения программы все корректно. Я могу даже предположить, что в их софте для каждой валюты открыт субсчет. Видимо финансовый результат выявляется позднее.
ОFF
(БТР) Когда домой? А то зашлют меня в Сибирь... а это, похоже, навсегда:) А еще пивка охота в хорошей компании.
БТР
81 - 10.06.2002 - 12:19
(69) Сложная проводка содержит кореспондирующий счет. RTFM. Сложные проводки применяются в случаях, когда необходимо по одному счету дебета провести несколько счетов по кредиту. И наоборот. Или когда нужно валютные суммы или количество сделать разные по дебету и кредиту. В сложной проводке сумма дебета должна быть обязательно равна сумме кредита.
(76) Ты говоришь о средней за период. Иначе говоря - средневзвешенной. А я говорю о средней скользящей. Она тоже разрешена. Это аналог FIFO для учета накопительных партий (например для сыпучего или жидкого сырья, перемешиваемых в одном хранилище). Я поинтересуюсь, где это разрешено. Но, в целом, никто и не мешает переоценить в конце месяца складские запасы и себестоимость реализованной продукции, товаров и списанного в производство сырья.
БТР
82 - 10.06.2002 - 12:21
(80) Ой, не знаю... Меня могут напрямую еще куда-нибудь...
SerBabah
83 - 10.06.2002 - 12:24
К (52)
Вот у меня есть реализация 2х "своих" планов счетов.
1 - для ЦФУ (с разделителями), 2й - консолидированный.
2й похож на 1й, и я бы грустил по поводу дублирования проводок, но, например, в 1м плане счетов не вся счета закрываются (и по ним аналитика - оборотная) - это счета переводов потоков м/д ЦФУ. Во 2м ПС эти счета закрываются.
БТР
84 - 10.06.2002 - 12:45
Может, он чего-то недосказал? Ждем-с.
RuslanD
85 - 10.06.2002 - 12:48
 К чему эти споры?
 Реализовать трехвалютный, четырехвалютный и т.д. учет в 1С можно, но не стандартными средствами, а смесью программирования и стандартных средств... может это будет медленно, может нет, не важно... Сделать это можно.
 Важно другое... решить эту задачу предлагает человек, работающий не на 1С, а на другом продукте-конструкторе, для которого, многовалютный учет (больше двух валют) встроенная фича, либо легко реализуем средствами его конструктора. И цель этой задачи подчеркнуть недостаток конструктора от 1С и подчеркнуть преимущество его конструктора. К сожалению не знаю настолько предмет, чтобы дать ему задачу, которую его Аксапта тоже "может" решить как и 1С задачу о многовалютности.
 Спрашивается зачем решать эту задачу? У кого-то возникала необходимость решать такую задачу в жизни?
PS
86 - 10.06.2002 - 12:58
(84) Пока народ курит...Сходи на почту,pls //le...@mail...
slw
87 - 10.06.2002 - 13:03
У меня возникала, только в более сложном чем здесь описано варианте. Там ещё от договора и валюты задавался % на конвертацию. Типа платим в руб. с клиентом взаиморасчеты в EURO, корпоративная валюта USD. При этом: при платежах в EURO коэф. = 1, при платежах в USD коэф 1,03, при платежах в руб коэф 1,05.
Но смешвать мух с котлетами (управленческий и бухгалтерский учеты) я не стал - это велось в разных базах.
PS
88 - 10.06.2002 - 13:17
(87) Мимо. Речь, видимо, о том, что в 1С у проводки только 3 ресурса:
Количество, валсумма, и сумма. Т.е. нельзя отразить несколько валютных сумм и валют в одной проводке. Надо извращаться с аналитикой.
....
ИМХО, для целей бухгалтерского учета в этом нет необходимости. Да и для "управленческого" учета резонов немного. Например, зачем мне оценка задолженности с контрагентом в разных (более чем в двух) валютах? Одна валюта - учет у меня, другая - с ним. А третья зачем? Может пояснит кто?
ppson
89 - 10.06.2002 - 13:20
88) Вот в том то и вопрос что основной ответ на все вопросы - а зачем это нужно. А раз не нужно то все это в 1С решаемо.
Зачем клиенту вести покрытие счетов в двух валютах + еще договор в третьей
ppson
90 - 10.06.2002 - 13:22
сорри.
Это зачем то нужно клиенту, пусть если это какая то многонациональная корпорация. или в моей примере
Дб 60 (одна валюта) Кр 60 (другая валюта)?
2) как быть с жесткой корреспонденцией счетов
3) как быть с планируемыми (контролируемыми) проводками?
slw
91 - 10.06.2002 - 13:29
(90) По поводу планируемых проводок. А что мешает сделать документ с реквизитами операции? Один создает, другой проводит. И всё.
А жесткая корреспонденция счетов - это что?
PS
92 - 10.06.2002 - 13:30
(89) Добавлю, там, где количество ресурсов больше обычного - используют регистры. Как правило, это узконаправленный учет. Ну, скажем, машинные масла: упаковки, килограммы, литры. Или уголь: тонны и тонны условного топлива. Но никак не весь учет.
На 1С еще не нужно в кваку играть:) а раз не нужно, то решаемо.
Алексей З
93 - 10.06.2002 - 13:35
to ppson. (sorry) Загляни в свое мыло. Чермет мечется!
БТР
94 - 10.06.2002 - 13:38
(90) Что значит жесткая корреспонденция? Ты про разрешенные проводки, что-ли?
И еще раз про планируемые проводки. Мне не понятно о чем ты говоришь. Приведи пример. Чем тебя не устроило мое решение с заявками?
PS
95 - 10.06.2002 - 13:41
(90) Кстати. Работал с многонационалыми корпорациями. Там люди поступают просто. Если работают в стране, где жестко обозначена валюта учета, рубли например, ведут учет в национальной валюте. А перекладку делают по средневзвешенному курсу, с изменением финансового резултата в нац. валюты мамы-страны. Иначе в собственной валюте. И практически нигде не считают каждую операцию в двух валютах. Это реализую на разных ПС. Оговорка "практически", только потому, что везде и всюду я небыл.
ppson
96 - 10.06.2002 - 14:10
Бог с ним, с планами счетов.
1) Все это решаемо, только очень гемморно. через использование забалансовых счетов или регистров. При использовании балансовых все едет.
2) К несчастью один мой клиент считает проводки в двух валютах.
Кстати в банках ежедневный баланс, которые ежедневно может передаваться в головной.
3) Пример проводок:
1. Дб 60 (Eur) Кр 76 (Usd)
2.
Дб 50
Кр 50
Кр 60
Кр 76
Дб 62
Кр 76
Но это все не касается России. У нас присутствует корреспонденция.
4) Проводки требующие контроля - банк, касса, склад и т.д. Когда один пользователь вводит документ и формирует (планирует) проводки (не проводя по балансу или еще по какому то другому регистру учета), другой контролирует и проводит по балансу (регистру). Тоже решаемо конечно.
RESUME:
Все в 1С можно реализовать. Если не на бухсчетах, то на регистрах.
tsd
97 - 10.06.2002 - 14:17
Посмотрел на название ветки, прочитал все написанное выше и так и не увидел ни одной задачи, которую на 1С решить нельзя.
Рыжий Ап
98 - 10.06.2002 - 14:31
Аппи!
БТР
99 - 10.06.2002 - 14:56
А давайте все дружно позовем mazzy
Без лица
100 - 10.06.2002 - 14:58
100
PS
101 - 10.06.2002 - 15:13
(96) Дык вот, осталось добавить, что геморррой есть всегда, какя бы платформа не использовалась. И критерий ее выбора - отнюдь не вопрос возможностей софта. Он лишь в том числе. Но это уже совсем другая история.
Кстати, прокачусь по Аксапте. Любой может убедится в том, что как платформа для работы с предметной областью, в сравнении с 1С, она очень слаба. Достаточно пройтись по сайтам продавцов решений на ней в разделе вакансии. В подавляющем большинстве требуются програмисты на С++ и прочих языках.
БТР
102 - 10.06.2002 - 15:28
mazzy!
БТР
103 - 10.06.2002 - 15:53
Ну где же спецы по проблемам ERP технически не решамым на платформе 1С?
Ау! Где вы? Поматросили и бросили :( Так я и не узнаю, чего не может 1С.
slw
104 - 10.06.2002 - 15:56
(103)Ну не понимаем мы его (mazzy) тонкую душу. На мы бы всё попроще.
PS
105 - 10.06.2002 - 16:02
(103) Мне, вот, только что позвонили и сказали, что 1С вообще не работает. А ты гришь ERP.
Хоть бы кто, хоть бы на чем, показал работающий MRP в отдельно взятой конторе:). А то софты писать все горазды. А вот чтоб у кого-то было как по учебнику...
БТР
106 - 10.06.2002 - 16:19
(105) А, тебе что, в первый раз с такой проблемой позвонили?
А MRP - это позавчерашний день. Я десятка три фирм знаю, которые потребность в материалах считают в 1С.
PS
107 - 10.06.2002 - 16:27
(106) " MRP - это позавчерашний день" - возможно. Нет сомнений, что в 1С. Только вот как насчет своевременности и одновременности. В нужное время в нужном месте. Честно говоря ничего подобного не видел. Не видел пустых складов и работы с колес. Вот это я к чему. С интересом бы посмотрел на такую организацию в России.
ppson
108 - 10.06.2002 - 16:33
101) - "Любой может убедится в том, что как платформа для работы с предметной областью, в сравнении с 1С, она очень слаба"
Что имеется в виду?
Л е н a
109 - 10.06.2002 - 16:43
(106)
БТР, ты меня удивляешь! Потребность в материалах - это не просто "Всего на заказ", а когда и сколько. Если тебе на заказ надо 200 тн стали, то не обязательно покупать все сразу - особенно если заказ начинает делаться сегодня, а закончится через год, а сталь нужна будет через пол-года.
И это не вчерашний день. Это позавчерашний и вчерашний и сегодняшний и завтрашний. Всегда какой-нибудь ресурс будет ограничен :-/ материалы-деньги-оборудование...
(107)
А вот работа с колес и нулевые склады - это противоположная крайность. В России это будет не скоро... и не потому, что считают в среде 1С :-)
PS
110 - 10.06.2002 - 16:43
(108) Я хочу сказать, что готовое решение (эксклюзивное) требует бОльших затрат ресурсов (времени и людей). Причем обязательны высококвалифицированые специалисты не владеющие знаниями предметной области, что резко увеличивает затраты времени постановщика.
ppson
111 - 10.06.2002 - 16:49
110) согласен
ppson
112 - 10.06.2002 - 17:07
Сдох сабдж?
БТР
113 - 10.06.2002 - 17:18
(109) А никто и не говорит, что потребность это то, что сваливается в кучу и лежит. Разумеется, потребность четко распределяется по времени, с учетом множества показателей, вроде минимального объема закупа, времени поставки, срока хранения, сезонности, плановых и минимальных запасов и т.п. Я сказал только о том, что планировать потребность в материалах уже недостаточно. Нужно планировать и загрузку мощностей, и загрузку персонала, и, ГЛАВНОЕ, финансовые ресурсы, а это уже далеко не МРП. Это уже МРП2 :)
И самое смешное, что чаще всего все это делается. Причем в экселях, акцессах и на бумаге. Там, где поставлено бюджетирование, там есть все необходимые расчеты.
(108) Видишь ли, есть разница между предметно-ориентированной средой и объектно-ориентированной. Когда я разрабатываю модель в 1С, ты видел, я оперирую понятиями счет/субконто, сальдо, обороты, дебет, кредит, количество, сумма и т.п. То есть, я могу В ЭТИХ ТЕРМИНАХ общаться и с бухгалтером, и с экономистом, и с программистом. Да, глубже в 1С есть свои ньансы, которые конечным пользователям глубоко непонятны и неинтересны. В аксапте же, не зная взаимосвязи модулей, бесполезно даже представлять себе учетную модель. Все равно не срастется. Вернее, сращивать будет программист, знающий структуру таблиц. В результате, проектировщик должен мыслить сразу на двух уровнях - системном и пользовательском и постоянно контролировать, чтобы в этих представлениях не было серьезных расхождений и рассогласований
tsd
114 - 10.06.2002 - 17:32
собственно говоря если вернуться к сабджу, то как мне кажется задачи учета можно решать любые. Главным критерием будут тормоза в работе системы, с чем у 1С есть проблемки, но опять же все зависит от характера решаемых задач. Если БДР план-факт ,который делают 2 раза в день, выполняется не 20 сек.(напр. На Оракле), а 5 мин., то это не критично.
ppson
115 - 10.06.2002 - 17:34
Есть два метода анализа: от общего к частному и наоборот.
На примере движков систем это видно. то что у одних преймущество - у других недостаток и так далее.
Nomad
116 - 10.06.2002 - 17:54
2(113)
"Там, где поставлено бюджетирование, там есть все необходимые расчеты."
Очень сильное замечание :)
Кстати, про задачу со временем в планировании операций - таки нет дельного решения, одни намеки :)
Скажем, понимание того, что время можно хранить в строке - оно не решает задачи планирования операций - нужно с умом применить это время.
Скажем, для того, чтобы определить, с какой параллельностью можно запустить операции на наборе ресурсов в 08 часов 05 минут, если доступность ресурсов определяется ранее распланированными операциями.
mazzy
117 - 10.06.2002 - 18:10
Офигеть, сколько за выходные накопилось...
БТР, если ты еще здесь, обязательно прочту ближе к вечеру и отвечу.
tsd
118 - 10.06.2002 - 18:15
(116) время в течении суток довольно просто перевести в число (минуты, секунды смотря какая точность нужна) , а если еще добавить Дату параметром анализа ....
БТР
119 - 10.06.2002 - 18:33
(117) Наконец-то! Да, я буду здесь долго сегодня
(116) Таки нет постановки задачи :) Поэтому и намеки на решение
То есть, например, у нас есть спланированное расписание с точностью до минуты занятости ресурсов, и есть список операций, которые нужно рассчитать на свободное время, я верно понял?
Допустим, есть десять станков и каждая из операций может распределяться по этим станкам, занимая на определенное в этой операции время для данного станка, в неком заранее определенном для данной операции интервале. Такая формулировка задачи пойдет?
Nomad
120 - 10.06.2002 - 18:34
2(118)
Млин, да проблема не в представлении времени :))
Проблема скорее в обширности аналитики и офигительном количестве запросов и расчетов. При этом распланированную операцию нужно сохранить вместе с временем начала, завершения, задействованными ресурсами, параллельностью и прочими прибамбасами. Операций - не одна тысяча. Спланирована она может быть из любого периода (в общем случае). Должна выделяться - чтобы можно было передвинуть вручную. Отражаться сразу в нескольких вариантах планов.
И много еще чего.
А вы заладили: время - число, можно складывать/вычитать ...
Nomad
121 - 10.06.2002 - 18:53
2(119)
Как частный случай - да :)
Дополнительно:
1. синхронности нет, т.е. операции - выполняются параллельно, но стартуют не одновременно
2. задано некоторое количество операций. все они привязываются к некоему графику потребления результатов этой операции.
3. Потребеление результатов - дискретно и неравномерно
4. Перивые результаты должны быть произведены к моменту начала потребления в объеме первого потребления
5. Последние операции назначаются так, чтобы их результаты могли быть потреблены в соответствии с графиком потребления
6. Возможно смещение "назад по времени"
7. Переналадка оборудования дает затраты времени - следовательно при назначении операции на ресурс нужно определять предыдущий тип загрузки - если это производство не по текущему типу операции - к началу операции прибавляем время переналадки
8. Время старта первой операции должно быть как можно более поздним.
Для затравки хватит :))
БТР
122 - 10.06.2002 - 19:16
(121) Уй, изверг, навернул. Давай в терминах каких-нибудь конкретных. Абстрактности обычно понимаются разными людьми по разному.
Итак, мы можем изготавливать изделия А, Б, В, Г и Д, по каждому изделю мы имеем свой перечень операций. У нас есть двадцать станков. Каждая операция на каждом из станков может иметь свое время выполнения, либо вообще не может выполняться на некоторых станках, кроме того, в зависимости от того, на какую операцию настроен станок, перенастройка на другую операцию требует отдельного времени. Так же, возможны простои отдельных станков для текущего обслуживания, иначе говоря, есть плановый график загрузки станков. Далее, мы имеем раздельно план и факт, так как, реально, могут сдвигаться графики загрузки станков, время выполнения также может отличаться от нормативов.
Кроме того, у нас есть план потребности в деталях, с объемами и временем момента, когда этот объем необходим. Соответственно, оптимизация плана должна быть такой, чтобы операции выполнялись максимально близко к тому моменту, когда их результат востребован.
Вроде так? Единственное, не понял что такое "смещение назад по времени". Смещение чего? И еще, я бы заложин возможность некого временного запаса между исполнением операции и временем потребления, различного для каждой операции по каждому станку.
Такая постановка задачи устраивает?
БТР
123 - 10.06.2002 - 19:37
Итак, мы имеем:
- справочник Изделия
- документ ПланВыпуска, в котором на определенную дату (или период) указывается следующая информация: Изделие, ОбъемВыпуска, Дата+Время выпуска
- справочник Оборудование, где перечислено имеющееся оборудование
- справочник Операции, подчиненный справочнику изделия, где описывается, какие операции необходимо выполнять для изготовления этого изделия
- справочник ВремяВыполненияОпераций, подчиненный справочнику Оборудование, в котором хранится информация о том, какие Операции можно выполнять на этом оборудовании, и сколько необходимо времени для выполнения этой операции, страховой запас по времени на выполнение операции, а так же строка Переналадка , в которой хранится список значений, по времени переналадки на данную операцию с других возможных для этого оборудования операций
- Справочник ПланЗагрузкиОборудования, подчиненный справочнику Оборудование,где для данного Оборудования указываются интервалы, в которые можно планировать исполнение операций, в виде НачалоИнтервала, КонецИнтервала.
Необходимо сформировать отчет, который производит расчет порядка выполнения операций по вышеуказанной информации в виде: Оборудование, Операция (либо указание к переналадке с операции на операцию), ВремяНачала, ВремяЗавершения таким образом, чтобы все операции выполнялись максимально поздно.
Так пойдет?
БТР
124 - 10.06.2002 - 19:41
Да, в завершение. Необходимо сформировать документ "График выполнения операций", для того, чтобы в дальнейшем пользоваться готовой расчитанной информацией. А вместо отчета сделать печатную форму этого документа
Ладно, БТР
125 - 10.06.2002 - 19:49
Вот задачка. План сверстан и посуточно выполняется. Изменения есть, нужно его корректировать и заказывать вагоны под продукцию ЗАРАНЕЕ, за трое суток. (Все это решается средствами самопальной системы уже 7 лет. В досе.) А вот и сама проблема.
.
Отгрузка продукции. Учет ведется в 1С.
Ограничения - терминал может принять не более 8 вагонов одновременно. Погрузка определнных видов продукции параллельно в разные вагоны - запрещена по технике безопасности. Причем некоторые можно грузить, но не на соседних сливах, а через один/два - минимальное расстояние указано в ТБ.
Вагоны покупателям грузятся с условиями - например, размер партии - не более 4-х вагонов (по договору, у клиента тоже площадка ограниченная). Отправка следующей партии - не менее чем через 24 часа. Это все криво-коряво можно решить на 1С с ее кривой арифметикой. Но на все это накладывается еще одно ограничение - предприятие принимает факсы и звонки клиентов с просьбой ускорить или замедлить или отложить отгрузку в пределах оговоренного договором срока без штрафных санкций. Такие звонки учитываются только те, которые поступают до 17-00. То да се - передали в расчетный центр, посчитали, график на оперативку в 17-30. Отсюда время расчета - реально не более 10 минут. Ребята как ни изгалялись - и БУ и ОУ - по времени то, что они соорудили, не всегда могло просчитаться в срок (если какой-нибудь хитрый вариант). Такое происходило два раза в неделю (почему то вторник и четверг). Выкрутились за счет сторонней программы.
.
Так что есть определенные задачи, особенно в оперативном планировании, где, как и в приведенном примере, особенности реализации платформы встают колом (Жесткие временные рамки - результат должен быть получен в определенное время). Как правило, это касается достаточно крупных предприятий (мелочь этим не занимается - не доросли еще). А на крупных - и так документооборот достаточно велик, что еще более усложняет задачу. (пример чем то перекликается с приведенным в (121). И таких задач по мере роста многих предприятий становится все больше. Т.е. задач действительно оперативного управления, а не "посмертного" учета (планирования) с отставанием даже на сутки. Можно сказать - используйте средства других систем, тогда зачем 1С. Хотелось бы иметь большую часть в рамках одной системы.
maxlab
126 - 10.06.2002 - 19:53
А классическую задачу коммивояжера кто нибудь в 1С делал? Я не говорю что нельзя...я просто спрашиваю :-)
БТР
127 - 10.06.2002 - 20:08
(125) Ты не гоношись. Все что касается сложных и быстрых расчетов можно делать во внешней программе, а на основании расчета результаты заносить в 1С и будет тебе единая система. Даже когда на С пишут операционку, некоторые критичные места на ассемблере переписывают. Ладно бы 1С не позволяла. Так ведь позволяет. Структура данных с аналитикой - в 1С, а расчетные программы (которых будет буквально до десятка на самом навороченном предприятии) - на дельфях или в VC. А особо критичные места расчета - на ассемблере. Или тебе не лень делать на VC все эти оборотки, анализы счетов и субконто и прочую дребедень?
Тем не менее, дай подумать над задачей. К тому же, может кто-нибудь сказать, что эти задачи решены в типовых поставках взрослых систем? Сомневаюсь. Наверняка это нужно программировать самостоятельно. Да еще и на языке достаточно низкого уровня. А если все равно программировать, то какая разница - внешнюю компоненту для 1С или функцию для аксапты или сап/р3?
Но так или иначе, я хочу подумать над задачей. Потому что она более-менее реальна и обоснована (как и твоя, кстати) мне хочется знать алгоритм. Разумеется, если будет слишком много вычислений, я не буду предлагать этот алгоритм выполнять в среде интерпретатора, логично?
Вопрос к г-ну Mazzy
128 - 10.06.2002 - 21:04
Прошу прощения у БТРа за отступление от темы... но очень интересно.
Милейший г-н Маззи!
Хочется спросить Вас, решена ли в Аксапте задача не ЕРП класса, а просто одна маленькая необходимость - если главбух вне модуля кассы вводит проводку по кассе (корректирующую, к примеру, или еще какую-нибудь), она попадет в "Кассовую книгу"?
Автор задачки для БТР
129 - 10.06.2002 - 21:07
Я и не гоношусь. Это ограничения платформы как таковой (реализации), а не принципов построения.
.
Я всегда так делаю. Перед тем как ребятки изгаляться начали на 1С, я им сказал - теоретически можно, практически - нереально в силу ограничений (кривая арифметика и интерпретатор). Конкретно эту задачу на делфе делал не я (но некоторые именно считалки - я). Не в этом суть.
.
По конкретному алгоритму - надо поискать книгу, по которой делалось - я давал ее ребяткам. Вот теперь и вспоминаю - вернули или нет. Тираж тысячи 2 с половиной экз. Там постановки задач и методы их решения на конкретных примерах - примерно штук 40. На примере языка PL/1. Книжку, каюсь, спер в библиотеке - в продаже нигде не видел, да и саму книгу видел у людей только пару раз. Найду книгу - запощу сюда название и автора. Выпуск где то 83-86 года. Алгоритм интересный, но много вычислений - интерпретатор просто не потянет при временных ограничениях.
.
Насчет аксапты и прочих систем - видел описание на английском - типа сравнительное описание имеющихся стандарных расчетных процедур/функций. Самопальное, распечатано и переплетено (примерно 99-2000 год). Тогда пропустил, сейчас жалею, что не откопировал - тряс ею спец из-за бугра. Так многие алгоритмы там реализованы в штатных или дополнительных библиотеках, надо только сформировать массив параметров и поставить вызов. Приведено система - название функции - что делает - метод, которым реализована - ссылка на описание данного метода в литературе (тоже на английском). Так что по большей части реализвацией многих типовых РАСЧЕТНЫХ алгоритмов заниматься, похоже, там не придется (хотя не знаю из-за отсутствия достаточного опыта работы с этими системами. А спец (крутая внедренческая контора из-за бугра, скорее даже обследование и рекомендации по выбору системы) тряс - типа в этой системе вот есть, в этой системе есть, в этой нет. Мне пришлось с ним бодаться в основном в теории - но смена владельца и руководства кардинально поменяла планы и к сожалению, поучаствовать в реализации не пришлось - не кутили ничего.
.
Описанная задача реальна, в основном на базах широкого профиля и крупных проихводствах. Задача реальна, я такую решал еще на последних СМ, но с распадом страны стала невостребованной. Сейчас снова появляется необходимость восстановления систем такого направления - опер управления, в котором необходимо получить решение с началом в заданное время за не более чем ХХХ минут. Т.е. точки смены плана фиксированы, но все возмущающие воздействия копятся и запуск в указанное время. Финансовые задачи - там несколько иная постановка. С тем же многовалютным учетом я работал очень мало - сказать ничего не могу.
.
Еше задачка на эту тему, можешь поспрошать людей - расчет смешения бензинов на нефтеперегонке. Тоже - резервуары, полуфабрикаты, накопление, получение анализов полуфабрикатов. До ХХ часов. Затем - расчет по критерию максимального выхода в тоннах или максимального выхода такой то продукции или максимально дорогого продукта (типа бензина Экстра) или все критерии в куче. Расчет (достаточно быстрый). Затем - команды Задвижку А1 - открыть на четверть, А2 - закрыть, Ах - наполовину.
.
И очень хочется хранить и считать все в рамках одной системы, но 1С - коротки штанишки в реакции (вся в дырках щеголяет, как последний бомж), а системы на VC или дельфях - не хочется в дорогом клифте с галстуком бабочкой грузить навоз на конюшне в мерседес-600 и возить его на поля - ремонт этого мерса дороговато станет.
mazzy
130 - 10.06.2002 - 21:33
Спасибо всем, кто принимает участие в обсуждении.
.
Я опять ошибся с прогнозом. В прошлый раз я подумал, что БТР шутил с ЕРП, а теперь подумал, что эта тема вряд ли кого заинтересует... Мда... как я круто ошибался. Надо было слазить в тырнет в выходные... :
.
Сразу небольшая оговорка: я не хочу здесь обсуждать Аксапту. Считаю ее здесь оффтопиком. Если уж очень хочется, то заводите ветки. А еще лушче, здесь говорить об 1С, а об Аксапте в специализированных форумах.
.
Извините, что ответ получился длинным.
.
БТР 18: Спасибо, что взялся за анализ. Если ты проанализируешь свой 61 счет, то не увидишь сколько УЕ соответствует дойчмаркам. Это означает что 1С не сможет тебе выдать информацию в "Дт*60 Кт*61" о "48,08УЕ". Без перебора проводок в этот момент ты эту сумму никак не вытащишь!!! Ты увидишь только что ВСЕГО на *61 лежит 7.02 УЕ. Это ВСЕГО и по рублевым проводкам, и по ДМ проводкам. Попробуй. В этом то и соль :)
.
"Произвольный период" это период с любой датой. Ты предлагаешь использовать предопределенные периоды - неделя, декада, месяц. А как же анализ?
.
Про извраты с будущими проводками. Можно, наверное. Но это усложняет создание отчета план/факт. И самое главное, вынуждает анализировать за весь период существования предприятия.
.
И еще, я нисколько не сомневаюсь в компетентности всех участников. Скажите, сколько это чудо будет стоить по разработке и поддержке?
.
Шаров 30: Идея с ограничением горизонта планирования интересна... А как же планы на год? Т.е. на долговременных планах ставим крест? Т.е. долговременные планы сделать все-таки нельзя? :)
mazzy
131 - 10.06.2002 - 21:35
das 24: "Стандартные инструменты 1С (проводка, период, ДатаДок, ТА, ГП) служат для описания свершившихся фактов и не могут описать план."
Совершенно точно. Так они задуманы.
.
"...а снижение скорости компенсировать технологически: покруче машины для немногочисленных планирующих"
Вот и я о том же. Назовите цену! Хотя бы для себя. И подумайте - такое решение приемлиимо с практической точки зрения?
.
БТР 25: "Лично я попробовал вести аналитику по периоду и пока не понял, в чем загвоздка с производительностью."
Еще раз повторю и больше не буду. Это значит, что тебе придется либо перебирать все проводки, либо ограничивать горизонт планирования (сильно ограничивать).
.
Почему? Потому что одновременно придется показывать сколько запланировано, сколько фактически сделано и отклонение. Только сумма отклонения ни о чем не говорит. Отклонение в 100 рублей это много или мало? Если запланирован 1000000, то мало. Если же запланирован 1 руб, то много :).
.
.
slw 33 и tnnick 47: "По поводу многовалютного учета ... По моему здесь забыли о таком варианте, как использования нескольких планов счетов"
Не не забыли. Это был самый первый вариант. И пожалуй, единственный хоть что-то дающий. Однако, два плана счетов дают возможность получить попарно Вал-Руб и Вал-Корп. Руб-Корп получить из двух планов счетов нельзя. Можно навернуть и третий план счетов для того, чтобы получать корпоративные эквиваленты рублям. Но на практике получается совершенно неуправляемая конструкция.
.
БТР 35: "Не понял логиги. что именно усложняется в планфактных отчетах? В смысле, что регистр закрывается и увидеть план-факт по остаткам исполненных планов нельзя, так?"
Если плановый регистр отличается от фактического, то запрос будет гораздо сложнее, чем для одинаковых регистров. Не так ли? Сколько будет стоить поддержка и сопровождение сложных запросов?
.
"Можно ведь использовать два регистра - оборотный и остатков параллельно. И получить функциональность бухгалтерских итогов."
Нельзя :) Что делать с будущими проводками?
Я как раз это и хотел показать: если делать на бухитогах, то непонятно, что делать с дополнительными ресурсами, а если делать на регистрах, то непонятно, что делать с будущими проводками. (это и для PS 92)
mazzy
132 - 10.06.2002 - 21:36
SO 36: "можно взять на вооружение уже откатанный механизм DATE_TIME_IDDOC у 1С"
Я подозреваю о чем ты говоришь. Скорее всего я с тобой не согласен (из-за стоимости решения). Но очень надеюсь, что я ошибаюсь. Можешь конкретнее?
.
slw 38: "...В этот справочник писал 1 элемент на 1 период. Там же был периодический реквизит документ планирования в который документы себя записывали в соответствии с датой на которую сделано на которую сделано планирование. В регистр остатков ввер измерение период планирование являющееся этим самым справочником После этого если мне нужны плановые цифры берем остатки по нужным интервалам планирования."
Ага. А регистр у тебя не закрывался никогда? Это не очень хорошо (на самом деле, отвратительно) сказывается на производительности.
.
Шаров 39: "Усложняется способ извлечения данных из ИБ для построения отчета по сравнению с вариантом, описанным в (30)."
Согласен.
.
БТР 43: "В конце-концов, проблема явно не в технической реализации."
Согласен.
.
"Можно хоть количество использовать для учета в корпоративной валюте - какая разница?"
Нельзя. Количество используется очень часто именно как количество. Его использование в других целях является сильным ограничением.
.
"Неважно, где вести управленческий баланс в корпоративной валюте - на втором плане счетов, в забалансе, в основном плане счетов с использованием разделителя учета, в регистрах, в журнале расчетов... Все равно - это ОТДЕЛЬНЫЙ от бухгалтерского баланс."
Согласен.
.
"Так же есть переоценка валютных остатков"
Не всегда.
.
"Она требуется в момент фиксации остатков ... для уточнения оценки баланса в национальной или корпоративной (управленческой) валюте"
ОТНОСИТЕЛЬНО ВАЛЮТЫ ОПЕРАЦИИ, а не просто так :)
.
"Ни та, ни другая операция у меня не вызывают проблем"
Да ну? См. начало этого постинга... :)
.
ppson 49:""Нигде в мире двойная запись не имеет черновиков" - тебе так кажеться."
Согласен.
"В мире кстати мало где есть принцип двойной записи. Во многих бухгалтерских системах отсутствует корреспондеция счетов как таковая"
Корреспонденция и принцип двойной записи это совершенно разные вещи. Двойная запись может существовать и без корреспонденции :)
.
"Но все это решаемо средствами языка только очень геморно и с потерей производительности."
Согласен. Вплоть до потери смысла в реализации средствами этого языка.
.
SerBabah 52: "Мы спорили с ним давно. Я утверждал, что это реализуемо на 1C. И использовал для реализации именно 2 плана счетов с разделителями. Тогда разговор свелся к суммовым разницам, и на этом закончился. Можно ветку даже поискать..."
Привет. Я помню. Мы как раз говорили о том, что переоценивать нельзя. А без переоценки вариант с двумя планами счетов не работает... :) С радостью готов принять от тебя работающий вариант. Обязательно выложу на сайт с признанием собственной неправоты. И здесь об этом расскажу.
.
ppson 59: Точно.
.
PS 61: Точно.
.
slw 65: Slw, спасибо, что попытался разобраться с этой проблемой. Отлично. Осталось немного.
1. Сделай проводку в Евро
2. Сделай проводку в Гринах, например (этого у тебя не было)
3. Скажи, как после этого ты получишь сколько корпоративной валюты соотсветствует Гринам? :)
Если ты вывернешь наизнанку, то сколько корпоративной валюты соотвует рублям? :)
.
Lazy Stranger 68, 72: Спасибо, что подключился. Вроде, и в прошлый раз ты участвовал в обсуждении.
Да? Все говоришь? А сколько рублей соответствует тому что находится в корпоративной валюте? :) Ты просто вывернул планы счетов. В результате ты не можешь сказать о третьем соответствии.
.
Уважаемые! Три валюты - три соответствия! Два плана счетов дают только два соответствия между валютами.
mazzy
133 - 10.06.2002 - 21:38
RuslanD 85: "К чему эти споры?Реализовать трехвалютный, четырехвалютный и т.д. учет в 1С можно, но не стандартными средствами, а смесью программирования и стандартных средств..."
В том то и дело, что нельзя.
.
"...решить эту задачу предлагает человек, работающий не на 1С"
:)
Личные выпады пропускаем... Предположения о моих коварных замыслах тоже... :)
.
"Спрашивается зачем решать эту задачу? У кого-то возникала необходимость решать такую задачу в жизни?"
Да, возникла. Причем у многих. :)
И именно трехвалютность, а не четырех- и пяти- и т.д. валютность :).
.
PS 88: "для целей бухгалтерского учета в этом нет необходимости"
Именно для бухгалтерского это и нужно.
Если вести чисто-конкретно управленческий учет, то все можно решить переоценками. Но тогда инфляционная разница не выделяется никак. :)
.
PS 95: "Работал с многонационалыми корпорациями. Там люди поступают просто ... А перекладку делают по средневзвешенному курсу, с изменением финансового резултата в нац. валюты мамы-страны. Иначе в собственной валюте. И практически нигде не считают каждую операцию в двух валютах."
Точно. Это прописано и в FASB и в IAS. Только там же говорится, что так можно делать для НЕинфляционных экономик. Если рост курса велик, то погрешность становится слишком большой и сводит на нет большинство анализируемых параметров. Но там же говорится и о том, что вести параллельный учет слишком тяжело... :) Может и доживем до светлого будущего, когда сможем вести учет как все нормальные люди...
.
ppson 96: "Все в 1С можно реализовать. Если не на бухсчетах, то на регистрах."
Кто бы спорил :). Назови цену разработки и поддержки. Потом поговорим о практическом смысле такой реализации.
.
Лена 109: Точно.
.
PS 110: "Я хочу сказать, что готовое решение (эксклюзивное) требует бОльших затрат ресурсов (времени и людей). Причем обязательны высококвалифицированые специалисты не владеющие знаниями предметной области, что резко увеличивает затраты времени постановщика."
Ну?!! Вот самое интересное началось!!! Ну, сколько? Назови хотя бы сроки?
mazzy
134 - 10.06.2002 - 21:42
Вопрос к г-ну Mazzy 128: "Хочется спросить Вас, решена ли в Аксапте задача ..."
А вот и вопрос по Аксапте... :)
Очень хороший вопрос. Он очень болезненный для Аксапты. Если интересно, то заводите топик или переходите в специализированный форум. Здесь давайте поговорим об 1С? Ладно?
Шурик71
135 - 10.06.2002 - 22:12
Мысль на тему задачек планирования времени.
БухУчет.
В сумму пишем кол-во секунд (минут, в зав. от точности) от УсловнойДатыНачала.
Дт План = 9000000 //некая дата - запланирована операция
---
Дт Факт.Начало = 8999000 - Кр План //начали выполнять
---
Дт Факт.ТехПроц1 - Кр Факт.Начало = 8999000
Дт Факт.ТехПроц1 - Кр План = 500 //выполнена ч.1
---
Дт Факт.ТехПроц2-Кр Факт.ТехПроц1 = СКД(Факт.ТехПроц1)
Дт Факт.ТехПроцесс2 - Кр План = 400 // часть2
---
Дт Факт.ТехПроц3-Кр Факт.ТехПроц2 = СКД(Факт.ТехПроц2)
Дт Факт.ТехПроцесс2 - Кр План = 100 // часть3
---
В результате видим выполнение плана, состояние процесса...
БТР
136 - 10.06.2002 - 22:19
Уфф... mazzy, я понимаю, как непросто было отвечать тебе. Представляю, сколько буду расковыривать ответ для тебя. Пошел печатать ветку :)
БТР
137 - 10.06.2002 - 23:05
mazzy, для начала скажи мне, как ты себе представляешь (отвлеченно от платформы) реализацию проводок будущим числом? Просто интересно, если это просто обозначает наличие итогов для любого периода, то я тебе легко дам аналог построенный на регистре.
Заранее предупреждаю, к тому, что следует дальше относится с шуткой юмора.
---------------------------------------------
Регистр.ОборотыПоСчетам (оборотный, периодичность - год)
Измерения:
-ПланСчетов типа <<ПланСчетов>> - ну, тут мы просто делаем разделитель по планам счетов
-ДатаДействия типа <Дата> - вот это то самое измерение, которое дает нам хоть прошлые, хоть будущие периоды и отвязывает нас от точки актуальности. Таблица будет огроменной, но кто сказал, что на любой другой платформе при таком условии расчета итогов таблица окажется меньше?
-СчетДт типа <<Счет>> - сюда пишем счет дебета проводки
-Субконто1Дт типа <<Субконто>> - тут, разумеется, необходимые субконто дебета
-Субконто2Дт типа <<Субконто>> - тут, разумеется, необходимые субконто дебета
-Субконто3Дт типа <<Субконто>> - тут, разумеется, необходимые субконто дебета
-СчетКт типа <<Счет>> - сюда пишем счет дебета проводки
-Субконто1Кт типа <<Субконто>> - тут, разумеется, необходимые субконто кредита
-Субконто2Кт типа <<Субконто>> - тут, разумеется, необходимые субконто кредита
-Субконто3Кт типа <<Субконто>> - тут, разумеется, необходимые субконто кредита
-ВалютаДт типа Справочник.Валюты - сюда пишем измерение по валюте дебета
-ВалютаКт типа Справочник.Валюты - сюда пишем измерение по валюте кредита
Ресурсы:
СуммаБух типа Число - тут просто сумма проводки в рублях
СуммаВалДт типа Число - здесь сумма в валюте по счету дебета
СуммаВалКт типа Число - здесь сумма в валюте по счету кредита
СуммаУпр типа Число - тут сумма проводки в у.е. для корпоративного учета
КоличествоДтБазЕд типа Число - тут количество по счету дебета в базовых ед.
КоличествоКтБазЕд типа Число - тут количество по счету кредита в базовых ед.
КоличествоДтЕдИзм типа Число - тут количество по счету дебета в выбраной ед.
КоличествоКтЕдИзм типа Число - тут количество по счету кредита в выбраной ед.
КоличествоДтАбсЕд типа Число - тут количество по счету дебета в абсолютном показателе
КоличествоКтАбсЕд типа Число - тут количество по счету кредита в абсолютном показателе
Реквизиты
КурсДтБух типа Число - это памятка по курсу валюты в дебете к руб.
КурсДтУпр типа Число - это памятка по курсу валюты в дебете к у.е.
КурсКтБух типа Число - это памятка по курсу валюты в кредите к у.е.
КурсКтУпр типа Число - это памятка по курсу валюты в кредите к у.е.
ЕдИзмДт типа Справочник.ЕдиницыИзмерения - это пошли далее единицы измерения
ЕдИзмКт типа Справочник.ЕдиницыИзмерения - сначала учетная
БазЕдДт типа Справочник.ЕдиницыИзмерения - потом
БазЕдКт типа Справочник.ЕдиницыИзмерения - базовая
АбсЕдДт типа Справочник.ЕдиницыИзмерения - ну и единица измерения
АбсЕдКт типа Справочник.ЕдиницыИзмерения - абсолютного показателя
-----------------------------------------------------------------------
Ну что, завалим нафиг 1С Предприятие убойным регистром?
Собственно говоря, к этому регистру нужен еще регистр остатков.
----------------------------------------
Регистр.ОстаткиПоСчетам (остатков)
Измерения:
-ПланСчетов типа <<ПланСчетов>> - ну, тут мы просто делаем разделитель по планам счетов
-ДатаДействия типа <Дата> - вот это то самое измерение, которое дает нам хоть прошлые, хоть будущие периоды и отвязывает нас от точки актуальности. Таблица будет огроменной, но кто сказал, что на любой другой платформе при таком условии расчета итогов таблица окажется меньше?
-Счет типа <<Счет>> - сюда пишем счет
-Субконто1 типа <<Субконто>> - тут, разумеется, необходимые субконто
-Субконто2 типа <<Субконто>> - тут, разумеется, необходимые субконто
-Субконто3 типа <<Субконто>> - тут, разумеется, необходимые субконто
-Валюта типа Справочник.Валюты - сюда пишем измерение по валюте дебета
Ресурсы:
СуммаБух типа Число - тут просто сумма проводки в рублях
СуммаВал типа Число - здесь сумма в валюте по счету
СуммаУпр типа Число - тут сумма проводки в у.е. для корпоративного учета
КоличествоБазЕд типа Число - тут количество по счету в базовых ед.
КоличествоЕдИзм типа Число - тут количество по счету в выбраной ед.
КоличествоАбсЕд типа Число - тут количество по счету в абсолютном показателе
Реквизиты
КурсБух типа Число - это памятка по курсу валюты к руб.
КурсУпр типа Число - это памятка по курсу валюты к у.е.
ЕдИзм типа Справочник.ЕдиницыИзмерения - это пошли далее единицы измерения
БазЕд типа Справочник.ЕдиницыИзмерения
АбсЕд типа Справочник.ЕдиницыИзмерения
БТР
138 - 10.06.2002 - 23:20
Разумеется, в шутке юмора есть доля истины. Во первых, эту дребедень можно упростить для управленческого учета. Во-вторых, такую фигню я бы сделал непосредственно в виде своей таблицы в SQL - эдакий свой учетный регистр. А бухгалтерские проводки оставил бы в покое. Потому как не пойму до сих пор, при чем здесь корпоративная валюта, проводки будущим числом и бухгалтерский учет :)
Ну, а теперь по объемам реализации.
В свое время мы в Колибри впятером переделали бухгалтерский учет на собственные таблицы SQL. Переделали все бухгалтерские отчеты, переделали журнал проводок, документ Операция. Перестали зависеть от бухитогов. Все это заняло период с 25 июля по 15 сентября очень интенсивной работы (переработка была очень большой, работали по 110-120 часов в неделю). Так что можешь оценить стоимость. Но учти, что такая работа остается разовой. Далее на этой платформе можно реализовывать любой учет и любые движения. А сама платформа у 1С достаточно дешева. И самое главное - достаточно раскручена. Потому что все, что сделано в 1С продается как 1С. И это главный политический фактор, который удерживает меня в рамках 1С, даже если по сути дела от 1С остаются интерфейсы. Надо сказать, интерфейсы дорогово стоят. Если считать всерьез, то на проект по переработке ядра было затрачено 4200 человеко часов (7 недель х 120 часов х 5 человек), а на то, чтобы реализовать ядро и интерфейсы в другой системе потребуется раз в пять больше ресурсов. Какой выход? Аксапта? Трудно сказать. Ядро явно не идеальное, методология тоже не супер. Насколько легко мне будет перестроить документооборот в Аксапте? Не знаю. Спать пора. Сейчас мозги вскипят.
Шаров
139 - 11.06.2002 - 00:39
2(130) Идея с ограничением горизонта планирования интересна... А как же планы на год? Т.е. на долговременных планах ставим крест? Т.е. долговременные планы сделать все-таки нельзя? :)
 
Идея не просто интересна, она одно из решений предложенной тобой 2-ой "не решаемой" задачи из (0).
Ограничивается не длина периода планирования, а длина промежутка времени между фиксацией плана и началом поступления факта (период упреждения). Мне подсказали, что в плановой экономике СССР период упреждения был меньше месяца при планировании на год. Долговременное планирование (на периоды больше года) делается по укрупненной аналитике и, следовательно, менее критично к производительности.
 
Мне поначалу казалось, что V7 – это учетная система, не предназначенная для планирования. Предметной компоненты планирование ведь нет. (Кстати, в некоторых системах вообще нет предметных компонент ;). Но, похоже, вопрос сводится к терминологии, если планирование рассматривать как УЧЕТ плана.
Nomad
140 - 11.06.2002 - 00:44
По сути задачи - это так, мелочь, на самом деле. Таких и более серьезных - тысячи, пример см. ниже.
Для того же Фобоса - время расчета чуть ли не секунды. Там эвристика, нормальные полиномиальные алгоритмы и вся прочая дребедень. Дискретность времени - 5 секунд - более чем достаточно.
Но это специализированная система, с оптимизированным под задачу хранилищем данных. И на эти задачи натягивать 1С - глумливо как-то, пардон.
С другой стороны - мне именно сейчас приходится этим заниматься. Посему буду ярко и отчетливо благодарен любому, кто будет в состоянии ввязать со мною в диспут на эту почти религиозную тему.
P.S. Прикольная задача. И ответ, точнее подстказка, будет сразу :)
Планирование на птицефабрике. Про задохликов опустим, но выбора "что первично - курица или яйцо" не избежать.
Итак:
1. яйцо - сырье, полуфабрикат, готовая продукция
2. курица - то же самое :) + ресурс (наверное, типа оборудование)
3. производительность курицы зависит от возраста
Вопрос: сколько корма купить в августе?
Подсказка - циклограмма :)
А вообще, тема очень интересная, Маззи всех раззадорил и понеслось. Теперь все это бы в конструктивном ключе завершить :)))
mazzy
141 - 11.06.2002 - 01:29
Шаров 139: Не понимаю. Можешь подробнее? Что значит упреждение? Это значит вводить плановые данные не раньше, чем за неделю-месяц?
.
Nomad 140: :) На самом деле я и сам не ожидал такой реакции. Это был ответ на реплику Тота.
Nomad
142 - 11.06.2002 - 01:35
2(141)
Я, миль пардон, и впрямь не знаю, как лучше обратиться :)), но ты оказался нужным человеком в нужном месте, за что отдельное спасибо :))
ZhV
143 - 11.06.2002 - 01:53
Классно - просто монстры ... А мне можно ...
Знаю я одну систему (и фирму) , в которой для документа определен обьект -
граф состояний .
Не мое know-how - но поделюсь...чужим .
В 1С и и многих других системах для документа (или обьекта аналогичого
назначения) определено всего два состояния - "не проведен"/"проведен".
Но если определить граф переходов - промежуточные состояния
и описать условия и операции для этих переходов - чем не планирование.
Простейший проверенный вариант , который хорошо работал в торговой
системе -"сформирован"-"зарезервирован"-"отгружен"-"оплачен"-
"закрыт навсегда". Каждая операция перехода может иметь контрольную дату исполнения... Кстати , в старых ТиС было что-то похожее - срок оплаты,глубина кредита,частичное проведение ...не знаю как это работало,
не пользовался.
в принципе нет проблем для определения циклических участков графа
"запланирован"-{"частично исполнен"-"откорректирован":в цикле }-"завершен"
Граф не обязательно линейный , можно определить прохождение по разным
ветвям - по заданным условиям - например отгрузка без резервирования. Определение вершин графа, условий и операций прямого и обратного(т.е. отмены выполнения) перехода задается примерно как модуль проведения в 1С.
На самом деле там теория еще хитрее - это было сделано людьми с учеными званиями с ФТК/Политех СПб .
Или я не в тему ?
tsd
144 - 11.06.2002 - 06:52
Уважаемый mazzy позвольте не согласиться с Вами по поводу высказываний о невозможности планирования на любой период и, в частности, ответа на slw 38. Кстати не только планирования, финансовому понадобилось чтобы иногда факт тоже можно было рассматривать по периодам не только вперед :) . Ввод измерения, содержащего минимальный период как раз таки и позволит раскидывать суммы как вперед так и назад. В том, регистр никогда не закрывается и в него пишется один тип движения как раз на мой взгляд ничего страшного нет, скорее наоборот итоги всегда актуальны и их можно легко и быстро достать. Разделение плана и факта по разным регистрам как раз облегчает задачу выборки данных. Никаких сложных запросов нет, кстати не совсем понятно, что подразумевается под высказыванием - «Сколько будет стоить поддержка и сопровождение сложных запросов». В завершение отмечу, что сия система уже довольно долго и успешно используется.
По поводу трех валютного учета много сказать не могу, но почему обязательно использовать только план счетов? Бухгалтерии, для их отчетности, требуется только национальная валюта и валюта взаиморасчетов с клиентами, а корпоративная валюта им в принципе по бубну. Подозреваю что подключив регистр эту проблему решить можно, а попытка решения только на бухучете скорее связана с тем, что в фирме исторически используется только эта компонента.
Кстати стоимость разработки и поддержки КИС на 1С (да и стоимость железа наверное) несоизмерима с системами уровня Аксапты
Опять повторюсь но, единственным на мой взгляд ограничением является скорость, но здесь как раз можно внешние компоненты и т.п. и все равно стоимость разработки и сопровождения окажется гораздо ниже чем у других систем.
Знающий достаточно много
145 - 11.06.2002 - 07:25
Насчет фразы в (144) - "Опять повторюсь но, единственным на мой взгляд ограничением является скорость, но здесь как раз можно внешние компоненты и т.п. и все равно стоимость разработки и сопровождения окажется гораздо ниже чем у других систем." - так вот, скорость не единственное ограничение 1С (но иногда самое критическое). А насчет стоимости - пройденный этап, проверено, просчитано - прослезились.
Стоимость затрат на разработку и сопровождение растет даже не в геометрической, а более крутой зависимости. К тому же все начинает разъезжаться - тут маззи насчет стоимостей и прочего прав. 100% - система будет аналогична по стоимости другим. Преимущество только одно - скорость разработки на начальном этапе значительно выше по сравнению с другими, однако после начала боевой эксплуатации - затраты на сопровождение тоже резко велики - вся экономия в ХХХХХХце.
Все это - следствие мифа о легкой приспособляемости (на практике говорится - а какие проблемы с администрированием?). Так вот, миф о легкости достижения результата для фирмы-крошки (что действительно верно) переносят на достаточно большую фирму, что есть выдавание желаемого за действительное. Вообще есть даже математический критерий, который позволяет оценить момент перехода (точнее, необходимость перехода) на систему классом выше.
PS
146 - 11.06.2002 - 10:05
(45) Вообще есть даже математический критерий, который позволяет оценить момент перехода (точнее, необходимость перехода) на систему классом выше.-
С этого места подробнее, pls. Кроме того, почему это на 1С дороже? С чем сравнивать. Или выше абсолютная сумма и проекты на порядок длиннее?
Кстати, есть эмпирический критерий перехода на систему классом ниже:)
ppson
147 - 11.06.2002 - 10:38
75) - все можно. и прибыль свою тиаким образом посчитать. только надо быть очень осторожным с теми же запасами, если ты их оценишь не по методике МФ, то у тебя могут быть проблемы с МНС в части уплаты налога на имущество
128) - пример проводки.
133) - считал. вышли на сумму сравнимую с покупкой сравнимую с известной тебе системы. поэтому и закрыли проект полузавершенным. точнее завершенным на уровне написанного ТЗ.
.
148 - 11.06.2002 - 12:50
.
Шаров
149 - 11.06.2002 - 13:07
2(141)Не понимаю. Можешь подробнее? Что значит упреждение? Это значит вводить плановые данные не раньше, чем за неделю-месяц?
 
Это значит проводить плановые документы не раньше, чем за месяц-год. Тот план, который сравнивается с фактом, утверждается незадолго (меньше месяца) до начала собственно периода, на который он составлен. Если требуется автоматизировать многоэтапный процесс составление плана, то можно, например, завести отдельный регистр "Предварительный план".
 
2(143) А ты можешь описать, как реализован в конфигурации граф состояний документов?
slw
150 - 11.06.2002 - 13:17
2(132)
1. (1)Д52 - К62 Сумма 93,44 ВалСумма 100 Валюта EURO
(2)Д52 - К62 Сумма 2850 ВалСумма 100 Валюта EURO
2. (1)Д52 - К62 Сумма 100
(2)Д52 - К62 Сумма 3050 ВалСумма 100 Валюта USD
3. Корпоративная валюта грины - сколько есть столько и есть ($286,88)
4. По БУ у нас базовая валюта рубли - 8750. Пересчитывая корпоративную валюту в рубли - (8749,84)
Может я чего-то не понял, но по моему задача очень простая.
.
151 - 11.06.2002 - 14:40
.
Рыжий Ап
152 - 11.06.2002 - 17:28
Аппи!
mazzy
153 - 11.06.2002 - 18:12
tsd 144: "позвольте не согласиться... Ввод измерения ... позволит раскидывать суммы как вперед так и назад. В том, регистр никогда не закрывается и в него пишется один тип движения как раз на мой взгляд ничего страшного нет, скорее наоборот итоги всегда актуальны и их можно легко и быстро достать"
.
Давайте последний раз насчет периода. Использование измерения не позволит использовать даты. И заставит делать запросы за весь период. Это следует из сути работы с регистрами. Больше об этом не буду.
.
Насчет незакрывающего регистра. Пусть это высказывание будет на вашей совести :)
.
Шаров 149: "Это значит проводить плановые документы не раньше, чем за месяц-год. Тот план, который сравнивается с фактом, утверждается незадолго (меньше месяца) до начала собственно периода, на который он составлен"
Мдя. Т.е. технические проблемы переводим в разряд организационных. Тоже выход... Но на 1С то сделать нельзя :))))
.
slw 150: "Задача простая"
С радостью приму работающее решение. Готов публично признаться в своей неправоте. Обязательно выложу на своем сайте твое работающее решение. Обязуюсь во всех последующих обсуждениях делать ссылку на автора работающего решения.
:)
slw
154 - 11.06.2002 - 18:24
2(153) 1. По поводу периода: давай не в последний раз. Ведь в (38) я писал:"Берем остатки по нужным интервалам плнирования". Для того что бы взять остатки не требуется шерстить всю базу. Код привести?
2. Извини не понял - это сарказм по поводу предложеного решения (типа сколько не объясняю проблему - понять не могут) или всё же с твоей точки зрения это правильное решение. В первом случае попытайся мылом мне объяснить в чем проблема и что я не понимаю (ну бывает непонимание(по ссылке я кстати сходил)).
mazzy
155 - 11.06.2002 - 18:37
1. Привести.
2. Извини за сарказм. Можно я не буду мылом? Я согласен - бывает непонимание. Это нормально. Я в прошлый раз убил на это кучу времени - пришлось просто выложить на сайт то что надо получить в результате. Если есть интерес, то просто заставь 1С хотя бы получить анализ по трем валютам. На сайте есть этот отчет. По ходу ты сам наткнешься на эти проблемы.
Если для тебя эта задача неактуальна, то мы просто убьем время :)
AlexG
156 - 11.06.2002 - 18:42
Кстати, один из приемов для планирования при помощи регистров (sorry, если не совсем в тему) - у нас в регистре, куда вносятся заявки на товары (их заносят манагеры, потрепашись с клиентами -)), первое измерение - ГодМесяцДеньПланирования (число, целое). Заносимое значение довольно примитивно получается из даты (11.06.2002 -> 20020611). И соответственно, в запросах те или иные периоды (планирования) - наложением условия типа < или > на сие измерение...
Примитив - но много чего позволяет сделать (и без переборов движений по регистру обычно -)). По-моему, такими простыми приемчиками можно бывает многие вопросы решить...
mazzy
157 - 11.06.2002 - 19:00
Хм... похоже придется про периоды...
.
Итак, предположим.
Есть регистр с планом.
В этом регистре есть измерение, которое определяет период (неважно как)
.
Ситуация.
1. Я планирую что-то на будущее. Например, составляю план продаж на осенне-зимний период.
2. Регистры двигаются только документом.
3. Поэтому, технически, мой план будет документом.
4. Документ должен иметь дату.
5. Чтобы не сбить ТА, документ должен иметь дату, близкую к текущей (ни в коем случае не осенне-зимнюю). А сейчас июнь.
6. Следующей весной я захочу выполнить анализ план/факт.
.
Проблема:
Для составления отчета план/факт 1С будет вынуждена либо:
= хранить только отклонения (что явно недостаточно для анализа)
= либо анализировать проводки с начала деятельности (что очень медленно)
= либо оставлять регистр незакрытым (что катастрофически скажется на быстродействии при длительной эксплуатации)
.
Уважаемые, у вас есть другие варианты?
.
AlexG - просто ты оставляешь регистр незакрытым. И скорее всего, данных у тебя немного. И сделал ты этот примитив, судя по всему, недавно :)
.
Уважаемые, если вы считаете, что незакрытый регистр - это нормально. То так и скажите - "будущие проводки можно сделать на 1С, если оставлять регистр незакрытым". А после этого прочитайте документацию и рекомендации по программированию на 1С.
slw
158 - 11.06.2002 - 19:06
(155) Итак имеется:
Справочник ПериодыПланирования - код - строка, 4. Уровни - 1
справочник Статьи - уровней - 5 Наименование -20
Документ План
Реквизит(Ш) Статья - тип справочник Статьи
Реквизит(Ш) ДатаПлана
Реквизит(Ш) Сумма
Я задаю их как рекизиты шапки, что бы не заморачиваться н перебор строк.
Регистр Бюджет
Измерение Статья - тип Справочник статьи
Измерение Период - тип справочник ПП.
Ресурс Сумма
Горизонт планирования месяц.
Итак: при проведении документа формируем код справочника ПериодыПланирования как
строка(ДатаГод(Док.ДатаПлана))+Строка(ДатаМесяц(Док.ДатаПлана))
Если такого элемента нет то создаем.
Спр = создатьОбъект("Справочник.ПериодыПланирования");
Код = строка(ДатаГод(ДатаПлана))+Строка(ДатаМесяц(ДатаПлана));
Если Спр.НайтиПоКоду(Код) = 0 Тогда
   Спр.Новый();
   Спр.Код = Код;
   Спр.Записать();
КонецЕсли;
Делаем Движение в регистр Бюджет
Регистр.Бюджет.Статья = Док.Статья;
Регистр.Бюджет.Период = Спр.ТекущийЭлемент();
Регистр.Бюджет.Сумма = Сумма;
Регистр.ДвижениеПриходВыполнить();
Делаем отчет от ДатаНач по ДатаКон
Перем СЗ;
СЗ = СоздатьОбъект("СписокЗначений");
ДТ = НачМесяца(ДатаНач);
Пока Дт <= ДатаКон Цикл
   Код = строка(ДатаГод(Дт))+Строка(ДатаМесяц(Дт));
   Если Спр.НайтиПоКоду(Код) = 0 Тогда
      Продолжить;
   КонецЕсли;
   СЗ.ДобавитьЗначение(Спр.ТекущийЭлемент());
КонецЦикла;
ТекстЗапроса = "
  |Статья = Регистр.Бюджет.Статья;
  |Период = Регистр.Бюджет.Период;
  |Сумма = Регистр.Бюджет.Сумма;
  |Группировка Статья;
  |Группировка Период Все ВошедшиеВЗапрос;
  |Функция КонОст = КонОст(Сумма);
  |Условие(Период в СЗ);
  |";
Запрос = СоздатьОбъект("Запрос");
Запрос.Выполнить(ТекстЗапроса);
Вот собственно и все. По поводу истории планирования я код не привожу,
но он является всего лишь расширением текущего примера.
mazzy
159 - 11.06.2002 - 19:12
:) Действительно все.
Остаются вопросы.
1. Когда ты планируешь закрыть регистр бюджет? (см. 157 постинг)
2. У тебя получилось с точностью до месяца? Что будет, если планирование вести с точностью до недели? А с точностью до дня?
AlexG
160 - 11.06.2002 - 19:21
А кроме регистров остатков бывают еще и оборотные... Они, по терминологии mazzy, вообще не "закрываются"... К чему бы это?
mazzy
161 - 11.06.2002 - 19:27
:)
А для оборотных регистров надо задать период. Какой?
Или считать за весь период деятельности.
:)
Опять же. Готов принять любой работающий вариант.
slw
162 - 11.06.2002 - 19:35
(157)1. Сейчас специально изучил описание встроенного языка - там ничего по поводу обязательного закрытия нет. Так же посмотрел во втором томе конфигурирования - там нет раздела про регистры. Первый пока недоступен. Если не трудно напиши где ты это прочитал. Пока что, как ты понимаешь, закрытие регистров не выполняется.
2. Я привел пример с точностью до месяца. Никто не запрещает задавать другие горизонты планирования. Например с точностью до недели:Строка(ДатаГод(Дата))+Строка(НомерНеделиГода(Дата))
С точностью до дня строка(ДатаГод(Дт))+Строка(ДатаМесяц(Дт))+Строка(ДатаЧисло(Дт)).
Сделать справочник не линейным, а двухуровневым. На первом уровне горизонт планирования, а на втором уже собственно период планирования.
mazzy
163 - 11.06.2002 - 19:43
1. Нуралиев С. Методика или рекомендации программирования на 1С... Не помню точного названия. У франчайзей есть. В документации вроде было про закрытие регистров. Перед описанием регистров есть большая вводная про то как хранится, про то как запрашивать и рекомендации.
.
2. Ничто не мешает. Только число незакрытых остатков сильно возрастает.
.
Можно я выключусь из дискуссии?
Если будет готовый пример, то с радостью посмотрю.
.
Пока.
tsd
164 - 11.06.2002 - 20:19
К Slw – привет Слава, сразу не узнал (хотя подозрения были :), в дополнение к 158 скажу, сейчас там работает примерно так:
СписПериодов – список значений, содержащий необходимые для отчета периоды планирования
Рег = СоздатьОБъект(“Регистр.Бюджет”);
Рег.УстановитьЗначениеФильтра(“Период”,СписПериодов,2);
Рег.ВыгрузитьИтоги(ТабИтогов,1,1);
В таб итогов имеем планируемые суммы по статьям на нужные периоды.
А уж далее с ними как заблагорассудится поступайте
Кстати так работает гораздо быстрее чем через запрос. Проверялось не раз, так что без веских аргументов пинать не пытайтесь :)
slw если остался интерес мыль.
Как видите уважаемый Mazzy здесь нет никакого сложного запроса. А вся поддержка будет заключаться в своевременнтом вводе данных пользователями :)
(153) Суть работы с регистрами не заключается в использовании только запросов. у регистров достаточно методов, которые в различных ситуациях выгоднее применять.
(161) Регистр не оборотный а остатки.
(163) готовый пример есть и работает уже несколько лет, хотите посмотреть приезжайте, с радостью примем :)
mazzy
165 - 11.06.2002 - 21:59
Дык, tsd.
Вы же тоже регистр Бюджет не закрываете...
Работает несколько лет? А бюджетирование вы одной суммой делаете или все-таки по статьям затрат? А сколько статей затрат? Каков горизонт планирования? А то что slw наверху писал, стало быть не входит в запрос? :)
.
Надеюсь ошибиться.
Надеюсь получить прототип работающего решения.
Надеюсь обсудить прототип работающего решения, выложенное в публичный доступ.
Надеюсь, что объявлю о своей неправоте.
.
Я не буду продолжать этот топик.
Жду прототипа.
Спасибо всем за участие.
tsd
166 - 11.06.2002 - 22:40
(165) Работаете несколько лет? - Первый документ в системе, двигающий регистр Бюджет датирован 20.08.1999г.
Бюджетирование делается по статьям затрат в разрезе подразделений и подотделов. сколько там статей затрат точно не скажу, насколько помню больше 50. Горизонт планирования, если понимать под этим максимальный период планирования вперед (ну и теоретически назад :) любой, т.е. в плане бюджета вы задаете интервал или период на который планируется данная сумма по конкретной статье.
То, что написал slw (если я конечно не ошибся кто он :) в той фирме работало раньше(если мы конечно говорим об одной и той же конторе), потом когда я менял структуру системы, я полностью изменил алгоритмы.
регистр бюджет (вернее два регистра План и факт) не закрываю т.к. как уже сказал выше считаю это излишним и не влияющим на скорость работы.
Насчет прототипа: попробую описать как все это работает и пришлю Вам или к WildHare
На всякий случай продублирую это Вам по мылу.
ДМ
167 - 12.06.2002 - 22:52
2(0)
Используем выходной... Ответы на вопросы "как же должно быть на самом деле" позволяют двигаться вперед. Внесем посильный конструктив на предмет того, чего же не хватает V7 для "правильного" решения поставленных задач.
1. Повторяюсь. Проблема мультивалютного учета и связанной с ней проблемы учета товара в разных единицах измерения (а также, уверен, многих других схожих проблем) связана с тем, что в V7 ресурсы и измерения регистра хранятся в одной таблице. "На самом деле" ресурсы должны храниться в отдельной таблице, подчиненной таблице измерений. Одним из измерений таблицы ресурсов должна быть единица измерения. При такой "развязке" не важно, в скольких валютах ведется учет или в скольких единицах измерения одновременно учитывается товар.
2. Проблема с планом/фактом IMHO решается проще. Во-первых, если план всегда должен быть точно закрыт фактом, то можно использовать обычные регистры остатков (например, контур "Платежный календарь"), поскольку нет проблемы с "закрытием остатков регистра". В общем же случае для план/факта нужны так называемые "простейшие регистры" (в работе "От V7 к W8" они названы "базовыми функциональными зависимостями"). Вроде бы появление подобных регистров ожидается в V8 (под псевдонимом "регистры сведений"). Для данного типа регистров нет понятия "период хранения итогов" (не должно быть?), их "итоги" всегда актуальны. Для реализации план/факта одно из измерений такого регистра должно быть временем (временным периодом).
P.S.
Вообще говоря, с точки зрения прогресса не важно, насколько актульна проблема для большинства. Как известно, что при открытии электромагнитных волн немногие были способны оценить их практическую пользу.
.
168 - 13.06.2002 - 10:23
.
mazzy
169 - 13.06.2002 - 12:54
slw, tsd.
Надо сказать, что вы меня действительно зацепили. Я уже сделал тестовую конфигурацию.
.
Должен признать,
что план МОЖНО сделать на 1С вашим способом...
...НО какой ценой!!!!
.
Собираюсь в выходные выложить на свой сайт свою конфигурацию. Может и ты выложишь? Тогда и посмотрим на работащих примерах?
БТР
170 - 13.06.2002 - 15:42
mazzy, позволить напомнить тебе мой вопрос. Каким образом в аксапте реализован механизм хранения итогов? Они, таки, не закрываются, или, таки анализируются за весь период? Почему это ты решил, что незакрытый регистр это такая уж большая проблема? Создай незакрытый регистр на тысячу движений, сделай десяток запросов по итогам, потом добавь миллион движений и выполни те же запросы. В моем эксперименте замедление составило 8-9%. Количество незакрытых движений влияет на размер индексной таблицы. Более ничего страшного не происходит. Да, у меня в эксперименте регистр содержал 12 измерений и 7 ресурсов. Это я когда-то давно исследовал как много движений выдержит оперативный учет до полной смерти. Скажу честно, убить не удалось. На диске было мало свободного места. Всего 11 Гигабайт.
Но ты все же скажи, как это реализовано в Аксапте? Таки закрывается или таки с начала деятельности сканируется?
Тот
171 - 13.06.2002 - 15:59
2(169) Я по-моему где то писал уже: замени КАКОЙ ЦЕНОЙ на ЗА КАКУЮ ЦЕНУ. И всем станет проще и понятней.
PS
172 - 13.06.2002 - 16:12
(170) Привет. Кстати о Аксапте. Открылись вакансии консультантов. Может того...а? Тогда можно будет судить не понаслышке.
slw
173 - 13.06.2002 - 16:13
(166) Ты не ошибся. Контора та же самая и зовут её "А+". Я правда этот алгоритм, вместе с историей планирования, ещё в пару контор протолкнул.
(170)Незакрытые регистры это действительно не проблема. НО если считается, что их надо закрывать - давайте закрывать. Выиграем 8-9%. То же время/деньги.
(171) На написание документа "Закрытие плана" у меня ушло ~20 мин. А на всю конфигурацию, которую я сегодня описал, вместе с тестированием, 2 часа моей единственной и неповторимой жизни :). Сколько это будет по твоим расценкам? Разумеется я помню и о цене владения, но нам никто не мешает повесить этот (или какой-нибудь ещё) алгоритм на закрытие месяца.
mazzy
174 - 13.06.2002 - 17:58
БТР: об аксапте - в другом месте, пожалуйста.
всем: незакрытые остатки влияют не на rg, а на ra.
slw: :) значит два часа. так и запишем... :)
всем: позже-позже. Сейчас сильно нет времени
ex-Alex
175 - 13.06.2002 - 18:15
То slw. У вот тут, батенька, вы не правы. Это проблема, и очень большая. Не надо нарушать базовые принципы 1С. Не закрытые остатки плодятся из периода в период в геометрической прогрессии. При достаточном объеме данных получаются серъезные проблемы.
Кстати - если в базе 20 человек, средняя зарплата которых 150 американских рублей - то 8-9% - это 240-270 в месяц. Это достаточно скромные раскладки.