Задача “Интернет-магазин” (№9)
13.04.2012
комментария 63
Первая задача для самостоятельного решения.
Все вопросы по уточнению задачи можете задавать до 18 апреля. 20 апреля будет опубликовано решение задачи.
Вопросы по решению пожалуйста формулируйте в таком виде чтобы ответ на него не требовал просмотра конфигурации.
Пример “плохого вопроса”: “Посмотрите у меня документ не проводится”, “Я правильно сделал регистр?”.
Пример “хорошего вопроса”: “Я создал регистр накопления остатков с измерениями такими, ресурсами такими, преследовал цель накопления себестоимости в таких то разрезах, это правильно?”
Если не активировали токен — посмотрите видео-инструкцию (видео N5)
Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись — напишите нам на e-mail поддержки.
Здравствуйте!
Често говоря, эта задача заставила почувствовать себя идиотом. Очередная попытка “добить”.
Решение посмотрел, но вопросы остались.
Главный – себестоимость продажи. Сейчас расчет и списание происходит во время продажи. В отчете надо показать себестоимость Товаров в пути. Хорошо, перенесу расчет в регистрацию заказа. Но в решении сказано, что списание надо делать в момент продажи. Тогда и расчет окажется бессмыленным – пять заказов с одинаковой номенклатурой рассчитаются “по полной” и через пару дней спишутся, загнав себестоимость глубоко в минус. Получается, надо списывать в Регистрации заказа и восстанавливать себестоимость непроданных заказов документом Возврат на центральный склад?
Второй – хотелось бы видеть в решении работу с характеристиками. Как быстрее, проще, но в достаточном объеме это реализовать? Я вижу решение в дополнительных реквизитах РН ОстаткиТоваров – при проведении регистрации заказа суммировать харрактеристики и записывать в реквизиты РН (характеристики будут храниться в разрезе номенклатуры). А в отчете я сгруппирую по заказу и получу сводные данные. Или сделать реквизиты документа Заказ – Объем и Вес, где будет рассчитаны характеристики сводно по заказу, а в отчете просто взять эти данные. С ПВХ как то не очень дружу, хотелось бы подробностей:).
Спасибо!
“Получается, надо списывать в Регистрации заказа и восстанавливать себестоимость непроданных заказов документом Возврат на центральный склад?” – это одно из решений. В случае подобного подхода нужно себестоимость “недопроданных” товаров хранить отдельно.
“С ПВХ как то не очень дружу, хотелось бы подробностей” – Возьмем нормальную задачу из сборника по оперативному учету с ПВХ, там и покажу. На следующей недели будет как раз ее решение опубликовано.
«20 апреля будет опубликовано решение задачи», а где оно опубликовано?
До конца недели опубликуем, сорри!
не найду видео-решения данной задачи… подскажите где скачать?
До конца недели опубликуем.
Доброй ночи! В Калининграде 23-20 я еще успеваю задать вопрос. И так: В задаче сказано, что цена заказа не измена. Но ведь нигде не сказано, что при формировании заказа, цена должна вычисляться (по среднему, например)? Или всё же цена должна где-то вычисляться?
Цена или себестоимость? Цена может быть абсолютно любой и не вычисляется вообще никак.
Павел, как ваше мнение?
для хранения остатков использую Регистр ОстаткиТоваров с измерениями:
Склад
Заказ
Номенклатура.
Для Центрального склада остатки хранятся в разрезе Склада и Номенклатуры, а для ТочекВыдачи остатки хранятся в разрезе Склад, Заказ, Номенклатура.
Также добавлен регистр РезервТоваров с измерениями Склад, Заказ, Номенклатура, СкладВыдачи. (измерение СкладВыдачи нужно для того, чтобы получив остатки по нему узнать какие заказы ожидают отправку в точку выдачи)
Движения по этому регистру делает документ ЗаказКлиента (приход) и документ ПередачаВТочкуВыдачи (расход.. отменяет резерв переданных заказов).
Не самый простой вариант, но имеет право на существование.
Создание еще одного документа, который явно не указан в задании, будет минусом? Я не про поступление товаров, про него, в принципе, сказано, а про добавление документа “Прием заказа в точке выдачи” в указанную цепочку.
Я не думаю что это явный минус, но как Вы понимаете, реализовать прием можно и в документе передачи. В общем я бы не стал придираться к решению, но отметил бы этот факт.
Вопрос по отчету “Продажи”.
Правильно ли я понял, что может быть так, что в данном отчете будет запись о продаже, но не будет до какого-то времени данных о количестве выданных или анулированных заказах?
Поясните… Отчет отражает все зарегистрированные операции на момент его составления.
С ваших предыдущих постов я сделал вывод, что документом продажи в данной задаче считается “ЗаказКлиента”. Если данный документ формирует движения по Продажам, тогда данные о выручке и себестоимости будут, а вот выданного заказа может и не быть, т.к. после оформления заказа (продажи) этот заказ еще едет в точку, а затем выдается клиенту (возможно на следующий день)…
следовательно возможна такая ситуация: 31.03 оформлен заказ; 01.04. заказ выдан клиенту.. таким образом в отчете за март данные о продажах попадут, но без одного выданного заказа, а в марте данные о выданных заказах попадут, но без данных о выручке…
Вопрос по документу “Возврат заказов на центральный склад”.
Правильно ли я понял… у данного документа должна быть табличная часть с реквизитом “ЗаказКлиента”. Необходимо предусмотреть автозаполнение данной табличной части заказами пришедшими в ТочкуВыдачи, но не проданными в течении 2х дней.
Да, такая реализация будет хорошей. Можно и без автозаполнения.
Добрый день Павел. Будьте добры, скажите, где я не прав. Проведённый заказ фиксирует резерв товара и цену товара. Все заказанные товары поступают на точку и могут находится там 2 дня. Т.о. товары на точках и есть товары в резерве. И возврат их из точек на склад – есть снятие с резерва обратно на склад. Теперь путь. Путь, это такая же точка, при отметки что товары приехали и, соответственно, перепровождении документа товар снимается с пути и приходуется на точку и «ждёт»два дня. Вопрос: надо ли контролировать эти два дня. Кстати стоимость цена товара рассчитывается в момент проведения заказа и фиксируется по моему в отдельном РН. Или всё плохо, все не так и вообще…)))
Я извиняюсь, по-моему, насчет отдельного РН для товаров в резерве я как-то погорячился.
Вот теперь очень близко к истине. :)
Отчет “Заказы в пути” формируется на дату или за период?
На дату. Это “остатки”.
Насколько корректным с точки зрения производительности может быть такой способ реализации механизма проведения?
1. При помощи запроса сформировать таблицу значений, дописать в нее необходимых колонок (функция “заполнитьзначения”).
2. Результирующую таблицу загрузить в набор движений.
Ответ нашел сам в видео №1.
Другой вопрос.
В видео №1 для контроля остатков используется запрос к регистру ОстаткиТоваров, где в параметрах виртуальной таблицы используется подзапрос.
Неужели этот способ корректнее, чем Левое соединение таблицы документа и регистра?
Мотивацию можете прочитать тут: http://nashe1c.ru/materials-view.jsp?id=321
Осторожно! Экзаменаторы не любят необоснованного использования промежуточных ТЗ при загрузке данных в движения.
Вот если ТЗ как объекта у Вас не будет, то загрузка движений на основе запросе дело хорошее. При достаточном объеме строк конечно.
В отчетах можно увидеть параметр себестоимость, но она не может образоваться без какого-либо оприходования товара. Между тем среди необходимых документов нет документа выполнияющего функцию оприходования товара. Значит ли это что неявно предполагается, что такой документ должен быть создан или же нет?
В задаче сказано: Товары поступают на центральный склад компании. По моему все довольно явно указано.
В табличной части документа Передача заказов в точку выдачи регистрируются заказы или товары? (т.е. кладовщик выбирает каким-то образом заказы и по составу этих заказов заполняется табличная часть)…
Заказы
ввела в заблуждение фраза: “документ вводится кладовщиком центрального склада на основании текущих заказов”. Подумал о стандартном механизме ввода на основании…
Себестоимость при списании как считать?
Смотря что Вы подразумеваете под “при списании”. Уточните про какой документ идет речь.
Как я понимаю, документ Выдача товара регистрирует движения с данными о продажах: Выручка, Себестоимость…
Каким способом получать данную себестоимость?
и как быть если такого уточнения нет будет в задании на аттестации?
Себестоимость фиксируется в момент продажи. Подумайте что является моментом продажи. Это вовсе не выдача товаров клиенту. Хотя, конечно, можно тут поспорить.
Себестоимость, равно как и продажные цены фиксируются в момент оформления заказа. И после этого “едут” за заказом везде.
На сертификации если нет возможности уточнить задание, следует написать сопроводительную записку с аргументацией своих действий. Если сдаете очно, то можно уточнить у экзаменатора.
“Выдача товара” – документ вводится менеджером точки выдачи, в документе указываются номера заказов которые забирает клиент, после проведения этого документа товар считается проданным, а деньги полученными.
“Возврат заказов на центральный склад” – документ вводится в конце дня, все, не проданные в течении 2х дней заказы, считаются аннулированными и возвращенными на центральный склад.
Из подчеркнутых выражений сделал вывод, что факт продажи – это выдача товара…
Нужно ли хранить историю по количеству товаров в Пути?
Т.е. нужно ли в отчете по остаткам на начало прошлого месяца видеть сколько на тот момент было товаров в Пути?
Конечно.
Я правильно понял, что центральный склад всего один?
Да.
Хотя по мне так это не играет никакой роли при решении.
Товары поступают на центральный склад компании. Документ поступления создавать или можно начальные остатки занести непосредственно в регистр накопления центрального склада?
Как Вам удобно. Создание приходной как бы не отнимет у Вас больше времени чем создание документа для ввода начальных остатков :)
Под “свойствами” подразумевается реквизиты справочника номенклатура или план видов характеристик и отдельный регистр для хранения значений свойств?
В задаче явно не указано, потому хочу делать свойства – реквизитами справочника.
Как пожелаете. Я рекомендую после того как у Вас будет ясная картина с метаданными попробовать и через ПВХ реализовать свойства.
Могут ли заказы отгружаться в точку выдачи и клиенту частично? Т.е. по одному заказу две отгрузки в точку выдачи или две продажи?
Нет
а в типовых конфигурациях часто используют виртуальный склад “Товары в пути”, в результате, для учета товаров в пути, можно использовать те же регистры, что и для учета товаров.
Какой бы способ решения выбрать…?
Это один из вариантов решения. Все дело в структуре регистров с которых будет этот разрез храниться.
Товары в пути…
Для учета напрашивается решение сделать регистр накопления для учета товаров в пути.
Приход делает документ “Передача товаров в точку выдачи”
Если установлен флаг “Принято”, то дополнительно делаем движения расход.
+ надо бы указывать актуальный период у расходных движений, т.е. нужна еще одна дата в документе.
Что-то громоздко получается.
Насколько корректным может быть решение, если использовать для учета товаров в пути регистр сведений?
Регистр будет заполняться при проведении документа.
Если же установить флаг “принято”, то движения больше не формировать, а регистр – очищать.
Плюс – не будет расти база
Минус – теряется “история”.
Предлагаю для решения задачи исходить из того, что остатки в точках выдачи контролируются на конец дня. В точках выдачи принципиально не может быть неоперативных движений. Это упростит задачу.
Про центральный склад такую поправку применять не следует.
Я вообще не хотел проверять остатки на точках..
Мы же контролируем остатки на центральном складе – заказ фактически резервирует товар, отпуск товара только по заказу. Товара на точке просто не может не хватить – разве нет?
Верно, тем более при передаче товара клиенту сам товар вообще не указывается, только заказ.
Т.е. нужно резервировать уже заказанный товар?
Тогда в мыслях получается примерно следующее:
РН.ОсновнойСклад -> РН.РезервТоваров -> РН.ТоварыВПути -> РН.ТоварыНаТочках
Как-то громоздко получается.
Действительно, кажется будет проще если всё сделать на одном регистре, а товары в пути, резерв, основной склад — предопределенные склады. Однако тут возникает другая сложность, получается по некоторым “складам” будет нужен разрез Заказы, а по другим нет.
С другой стороны, ни в одном отчете нет показателя Резерв, может и не стоит с этим заморачиваться, а контролировать остаток только в момент отгрузки на точку?
Не хватает своей фантазии принять корректное решение, прошу помощи, где-то я запнулся в проектировании.
Контроль нужен только при регистрации заказа клиента.
И как это меняет вопрос о резервировании?
На центральном складе 10 штук сепулек, Петя заказал 7 штук. Эти 7 штук так и остались лежать на складе, т.е. ещё не отгрузили их на точку.
Приходит Вася, хочет заказать 5 сепулек. И как?
На складе вроде 10, но из них 7 уже заказано.
Может имеется в виду, что при заказе, сразу перекидывать товары на “ТоварыВПути”.
Где я заблуждаюсь?
Я намекал на “Свободные остатки”. Вася не должен иметь возможность заказать сепульки которые мы уже пообещали продать Пете.
Я дико извиняюсь, но вы только запутываете.
Или я совсем туплю.
«Свободные остатки» и резервирование товаров это не одно и то же?
Два дня переписки ниочем.
Решение о структуре метаданных постарайтесь принять сами, это 90% от объема решения.
Я сейчас постараюсь детально объяснить про товары, но если мой ответ Вас не устроит, сформулируйте вопрос. На вопросы “И как?” и прочие я наверно вряд ли отвечу так чтобы его закрыть.
И так, товары…
У товаров есть несколько состояний:
1. Товар лежит на складе. Его можно продать кому угодно.
2. Товар лежит на складе, но на нем есть пометка, что он является частью определенного заказа. Продавать этот товар нельзя.
3. Товар лежит в багажнике машины. Он едет в точку выдачи. И на нем до сих пор лежит бумажка ссылающаяся на заказ.
4. Товар лежит в точке выдачи и его состояние никак не отличается от того что было в п.2, за исключение географического расположения.
Так ведь и не было вопроса про метаданные.
Я спросил “Нужно ли резервировать товары?”
Ни в тексте задания, ни в отчетах никакой информации по этому поводу не нашёл.
Благодарю за детальный ответ, попробую принять оптимальное решение.
Павел, т.е. предполагается, что перед перепроведением документа “ПередачаЗаказовВТочкуВыдачи” в точке приема будет дата устанавливаться на текущую?
Т.е. с центрального склада товар отправился в точку 10.04.
Товар пришел в точку 11.04. => Дата документа изменится на 11.04 и затем документ проводится оперативно?
ой. не в ту ветку вопрос задал… этот вопрос относится к вашему ответу
от 14.04 в 02:11 про оперативное проведение документа “ПередачаЗаказовВточкуВыдачи”.
Товары “уехали” и “приехали” это разные события. И время у них разное.