Добрый день
БП 3.0 учёт с/с МПЗ по средней
партионного учёта нет
хотят знать себестоимость продаваемых товаров в разрезе поступлений
Причём по LIFO
Сейчас бухгалтер перебирает по карточке счёта.
Т.е вручную смотрит какие у реализации были ближайшие поступления (которых хватило)
Может ли данная задача быть автоматизирована ?
БП 3.0 учёт с/с МПЗ по средней
партионного учёта нет
хотят знать себестоимость продаваемых товаров в разрезе поступлений
Причём по LIFO
Сейчас бухгалтер перебирает по карточке счёта.
Т.е вручную смотрит какие у реализации были ближайшие поступления (которых хватило)
Может ли данная задача быть автоматизирована ?
По теме из базы знаний
- Как не нужно "запускать" проекты 1С
- Сравнение себестоимости простых торговых операций УТ10 и УТ11
- Учёт себестоимости в УТ 11
- Применение программистом таблицы рисков для оценки технического задания
- Автоматизация предприятий пищевой отрасли на базе 1С:ERP (прослеживаемость состава готовой продукции от сырья до реализации)
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
когда хотят знать в разрезе поступлений, тогда и включают партионный учет.
Ну а дальше, действительно, втыкать LIFO.
Либо, просто автоматизировать, то что делает ваш бухгалтер, только программно. (я так понимаю он просто сумму списания руками проставляет в ТЧ документа ?).
А значит, эту работу можно легко автоматизировать, либо изменив обработку проведения.
Либо внешнюю обработку заполнения табличных частей документа сделать, которая будет делать ровно то, что делает бухгалтер. Берем обороты по 41 счету, и последние поступления считаем и заполняем.
партионного учёта нет
хотят знать себестоимость продаваемых товаров в разрезе поступлений
когда хотят знать в разрезе поступлений, тогда и включают партионный учет.
Ну а дальше, действительно, втыкать LIFO.
Либо, просто автоматизировать, то что делает ваш бухгалтер, только программно. (я так понимаю он просто сумму списания руками проставляет в ТЧ документа ?).
А значит, эту работу можно легко автоматизировать, либо изменив обработку проведения.
Либо внешнюю обработку заполнения табличных частей документа сделать, которая будет делать ровно то, что делает бухгалтер. Берем обороты по 41 счету, и последние поступления считаем и заполняем.
Разберитесь, как включить партионный учет, и измените запрос, получающий партии - чтобы сортировка была по УБЫВ, а не ВОЗР. Способ учета ЛИФО запрещен законодательством, так что в типовом решении не поддерживается, но по сути это просто сортировка остатков по дате их возникновения.
(5)
А почему нельзя?
Все, что поддается хоть какой-то логике, вполне легко выводится.
Напишите бухгалтерам такой отчет. Это вообще, одна из самых распространенных задач для 1С программиста. К тому-же развивает навыки работы с СКД, запросами и вообще пониманию как хранится информация в базе.
возможно ли в отчёт подобрать данные по поступлению методом LIFO
А почему нельзя?
Все, что поддается хоть какой-то логике, вполне легко выводится.
Напишите бухгалтерам такой отчет. Это вообще, одна из самых распространенных задач для 1С программиста. К тому-же развивает навыки работы с СКД, запросами и вообще пониманию как хранится информация в базе.
(6) Мне перед тем, как поставить задачу программистам, хотелось бы понять алгоритмическую возможность
Пример:
- январь - поступление 5 шт
- февраль- реализация 3 шт
- март поступление 5 шт
- апрель - возврат реализации 2 шт
- июнь - реализация 5 шт:
2 из апрель возврата - который сформирован январским поступлением
3 из мартовского поступления
Пример:
- январь - поступление 5 шт
- февраль- реализация 3 шт
- март поступление 5 шт
- апрель - возврат реализации 2 шт
- июнь - реализация 5 шт:
2 из апрель возврата - который сформирован январским поступлением
3 из мартовского поступления
(7)
вроде простой и понятный алгоритм.
1 шаг, строим виртуальную таблицу партий приходов, глубину можно ограничить.
Эта таблица будет, такой же как обычный регистр накопления с включенным партионным учетом.
Поступление - со знаком+ Расход, со знаком -, документ, дата
2. Шаг формируем сумму, раскручивая таблицу из шага 1 в обратном порядке. Отнимая предшествующие возвраты.
Это такой же партионный учет, с той разницей, что эта таблица будет каждый раз виртуально строится, что будет, естественно, работать медленнее, чем если бы брать готовую информацию из регистра.
Но в целом все выполнимо.
вроде простой и понятный алгоритм.
1 шаг, строим виртуальную таблицу партий приходов, глубину можно ограничить.
Эта таблица будет, такой же как обычный регистр накопления с включенным партионным учетом.
Поступление - со знаком+ Расход, со знаком -, документ, дата
2. Шаг формируем сумму, раскручивая таблицу из шага 1 в обратном порядке. Отнимая предшествующие возвраты.
Это такой же партионный учет, с той разницей, что эта таблица будет каждый раз виртуально строится, что будет, естественно, работать медленнее, чем если бы брать готовую информацию из регистра.
Но в целом все выполнимо.
(9) но это применимо только для какого то конкретного товара, или конкретной реализации.
Если необходимо рассчитывать себестоимость продаж за период, то все будет печальней чем кажется.
Потому что, себестоимость рассчитанной реализации, будет влиять на себестоимость последующей рассчитываемой реализации.
А значит нам каждый раз надо рекурсивно строить новую и новую таблицу.
Т.е. если такой алгоритм нарисовать, то построение таких огромных рекурсивных расчетов, может просто наглухо завесить систему, особенно если данных много.
Подавно и человек, вручную такое не рассчитает.
Ну а если у вас, человек это умудряется анализировать, значит у вас все проще..или продаж мало, или в периоде не требуется так считать.
Если необходимо рассчитывать себестоимость продаж за период, то все будет печальней чем кажется.
Потому что, себестоимость рассчитанной реализации, будет влиять на себестоимость последующей рассчитываемой реализации.
А значит нам каждый раз надо рекурсивно строить новую и новую таблицу.
Т.е. если такой алгоритм нарисовать, то построение таких огромных рекурсивных расчетов, может просто наглухо завесить систему, особенно если данных много.
Подавно и человек, вручную такое не рассчитает.
Ну а если у вас, человек это умудряется анализировать, значит у вас все проще..или продаж мало, или в периоде не требуется так считать.
Всё пошло от того, что гл.буху поставили задачу - Подготовить отчёт по с/с позиций в конкретных реализаций.
Дело происходит в БП3.0
Заказов в ней нет.
Партионного учёта нет (в смысле у нас не включен).
Вот ей и надо знать с какого поступления была списана позиция.
По буховской традиции - она выводит карточку 41 и смотрит - а какое поступление было ближайшем к реализации.
Т.е задача изначально выбивается из нормального расчёта с/с
Дело происходит в БП3.0
Заказов в ней нет.
Партионного учёта нет (в смысле у нас не включен).
Вот ей и надо знать с какого поступления была списана позиция.
По буховской традиции - она выводит карточку 41 и смотрит - а какое поступление было ближайшем к реализации.
Т.е задача изначально выбивается из нормального расчёта с/с
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот