В итоге товар оприходовали, фрахт и растаможку включили в себестоимость, начали возить между своими складами — а вторичную логистику по гребаному РСБУ нужно относить на затраты периода, а нам хочется включить в себестоимость, чтобы понимать сколько стоит паллета в воронеже, а сколько в хабаровске.
Ну причина проблем, как обычно, в прокладке. :)
Вот именно такая ситуация (ну разве что не паллета а контейнер, и не в воронеже и хабаровске, а в амстердаме и новом орлеане))) прекрасно была решена в навике. Все затраты, включая транспортные, включались в себестоимость, а в конце каждого квартала все транспортные затраты, и прочие, которые не должны быть на балансе, но были в составе себестоимости на складе — списывались реверсивной фин проводкой на затраты. И всё! И отчетность в полном соответствии с МСФО, и возможность анализа сохраняется. :)
Ясно. :)
Но лучше писать более четко. Потому как некорректное сальдо по некоторым счетам — не то же самое, как порванный баланс, когда сумма оборотов по всем счетам по кредиту не равна сумме оборотов по дебиту. Такие вещи только при ручном учете бывают, я не слышал ни про одну систему, где автоматом такие вещи не контролируются.
Я ведь уже написал, что лицензировать на ядро для небольших компаний — сам себе злобный буратино. :)
Читаем буквально в следующей строке:
«Сервер + клиентская лицензия CAL $931»
931 доллар ЗА СЕРВЕР без учета количества ядер!
Учитывая, что CALы у нас уже были куплены для других целей, стоимость MS SQL Standard Edition для целей аналитики составила эти самые 931 доллар и всё. Больше нам ничего платить не пришлось.
И даже если надо покупать CALы. Стоят они 200 баксов за юзера. Скольким юзерам в небольшой фирме нужен доступ к аналитике? 30-40, максимум 50. 50 * 200 = 10000 долларов на CALы. Приплюсовываем 1000 на серверную лицензию — 11000 долларов за софт для аналитики, что тоже отнюдь не заоблачная цена.
Не требует Standard Edition лицензировать каждое ядро. Можно, разумеется, и такую модель лицензирования выбрать — но тогда сам себе злобный буратино. :)
Мы купили лицензию на сервер (виртуальную машину). И стоила эта лицензия примерно одну тысячу долларов. Посмотри сам на Цены на SQL Server именно на Standard Edition. Правда, под аналитику у нас выделено не 22, а 14 ядер, но нам этого хватает.
А так как у нас ERP (навижин) и так крутилась на ms sql, и юзеры уже пользовались экселем (через него смотрим кубы), никаких дополнительных затрат на софт для аналитики нести не пришлось.
В том то и дело, что для небольших компаний ms sql standard (про оракл не знаю) во многих случаях очень даже приемлемый вариант как по цене, так и по скорости.
Наверно, параллельное чтение только у ентерпрайза — я в такие нюансы не вникал.
Но, как я уже говорил, для относительно небольших объемов данных стандарт едитион (плюс быстрые ссд диски) вполне хватает.
И совокупная стоимость получается существенно ниже альтернативных вариантов (если включать зарплату специалистов).
Поэтому я и говорю, что для небольших компаний есть весомые резоны делать аналитику на стандартной субд, той же мс скл. Совокупная стоимость достаточно низкая и при этом альтернативы получаются дороже.
Насколько я знаю, разные секции могут читаться параллельно. И стандарт едитион это поддерживает.
Вот немного на эту тему: Partitioned Tables and Indexes
Если честно, я не настолько глубоко погружался в этот вопрос (что именно параллелит ms sql). На практике, если нормально спроектировать структуру куба, всё работает с приемлемой скоростью (если мы говорим об объемах данных небольших и средних компаний — десятки / сотни миллионов записей).
По поводу небольших компаний — не соглашусь.
Небольшие компании — это десятки — сотни миллионов записей (не миллиарды — десятки — сотни миллиардов). И под такие объемы тот же Microsoft SQL Server Standard хорошо справляется (кубы и база в качестве DWH). Партицирования не хватает (в стандарте только 4 партиции разрешено), но жить можно.
А по цене — если арендовать сервер с сиквелом в том же Azure, то по цене вполне нормально. И для таких объемов данных — хватает.
+100500
Могут быть не очень опытные HRы — в этом нет ничего страшного. Но когда в роли HRа неадекватный человек — это симптом, характеризующий всю фирму.
Я для себя сделал вывод, что если HRы крайне низкого уровня — в такую фирму просто нет смысла идти. Если у руководства не хватает навыков отличить квалифицированного HRа от ламера — в такой фирме и в других отделах будет бардак.
Я уже даже не помню, где взял шаблон резюме (это было примерно 20 лет назад).
И с тех пор я просто обновляю его, а большая часть оформления (что выделять, что курсивом и тп) осталась из первоначального шаблона. Зачем что-то придумывать, если есть уже готовая форма? :)
"Потом есть великая вещь, оборотно-сальдовая ведомость твоего бизнеса. Она должна быть чёрная. Красная – это когда у тебя что-то не бьётся. Если ты всё сделал, потом сформировал сальдо-оборотку, она у тебя должна быть чёрная, сведена, дебет ноль, кредит ноль, всё хорошо. Это означает, что на всех этапах всё у тебя было хорошо. А если у тебя произошла какая-то ошибка, сальдо-оборотка красная."
А это как? То есть чисто технически — как в стандартной конфигурации 1С получается не свести дебет с кредитом? При ручном учёт это сделать совсем легко, а вот как в той же 1С порвать оборотку?
"Потому что на самом деле нормальный предприниматель всегда знает, сколько воды он продал, и сколько воды ему нужно поставить завтра в магазин, чтобы её продать. Это суть его бизнеса. На самом деле, если у предпринимателя нет управленческого учёта, то у него скорее всего бизнеса не будет."
Вот это всё же правильнее называть оперативным учётом. Управленческий учёт — это немного другое. Те же кост центры — управленческий, а 100 кг мяса в бургерную пришло — оперативный.
PDCA цикл Шухарта-Деминга никак не связан с MRP алгоритмом.
А вот то, что Деминг, прежде чем придумывать что-то свое, внимательно изучил опыт предшественников — очень даже связано с вашими «открытиями». Ведь вы даже не удосужились разобраться — что такое MRP. Вы ведь, судя по всему, даже ту лекцию Колумбийского университета не прочитали, ссылку на которую привели. :)
Когда программист начинает рассказывать байки про «улучшение качества отношений», как PR менеджер — сразу вспоминается анекдот про морскую свинку, которая ни к морю, ни к свиньям отношения не имеет.
С чего обсуждение начиналось?
«ERP система — это система поддерживающая первый, выталкивающий тип производства.»
В качестве доказательства привели сомнительную статью на википедии и ссылку на лекцию Колумбийского универа.
В лекции черным по белому написано:
«The three major inputs of an MRP system are the master production schedule, the product
structure records, and the inventory status records.»
Вместо того, чтобы или доказать, каким образом MRP является «выталкивающим» при том, что план производства является для него входящими данными, или признать свою ошибку, вы начинаете рассказывать байки про улучшение отношений.
Видите ли, если бы Деминг не потрудился в свое время глубоко изучить работы Шухардта, вряд ли он смог бы придумать то, что японцы называют циклом Деминга, а сам Деминг называл циклом Шухарта (PDSA цикл). :)))
Как показывает опыт, люди, не удосужившиеся изучить изобретенное предшественниками, в 99% изобретают не просто велосипед, а плохой велосипед.
Впрочем — дерзайте. Есть желание изобретать велосипеды и называть их новыми словами — кто я такой, чтобы мешать?
«Если человек в чем-то убежден, то флаг ему в руки.» :)))
Почитайте, например, ту лекцию Колумбийского университета, которую ВЫ и привели www.columbia.edu/~gmg2/4000/pdf/lect_06.pdf. :)))
И подставьте ваши данные — простой одноуровневый BOM (рецепт) и произвести надо «сейчас».
«MRP will determine from the master production schedule and the product structure records the
gross component requirements; the gross component requirements will be reduced by the available
inventory as indicated in the inventory status records.»
«Поступает заказ на изготовление блюда, система анализирует небольшие запасы на кухне, если все есть, то заказ уходит на кухню.
…
Если продукта нет или стало меньше критического значения, то автоматически формируется заявка на доставку необходимых продуктов у поставщика.»
Впрочем, если вам нравится изобретать велосипеды — дело ваше.
Вообще то, вы только что описали классический алгоритм MRP в связке с классическим алгоритмом пополнения запасов по минимаксу (именно так очень часто и работают ERP системы для недорогих видов запасов). :)))
А обещали описать какой-то другой алгоритм, более эффективный… Как после этого верить людям? :)))
Почитайте по ERP системам что-то более серьезное, чем википедия. Меньше будет велосипедов и выше качество решений.
Если решили углубиться в детали…
Сам по себе алгоритм MRP ничего не «решает» о количестве готовой продукции, которое необходимо получить на выходе. Основной план / график производства (спрос) — это входящая информация для алгоритма MRP.
Создаете график производства на основе неких планов — получаете «выталкивающую» схему (производственники говорят продажникам — вот, мы это произвели — продавайте).
Создаете график производства на основе фактических заказов от покупателей — и, ни одного байта не меняя в алгоритме MRP, — получаете «вытягивающую» схему (продажники говорят производственникам — вот, мы это продали — производите).
MRP ортогонален к противостоянию «выталкивание» / «вытягивание». Он вообще не про это.
MRP не обязательно подразумевает «толкающий тип» — почитайте более подробно, какие именно алгоритмы там применяются. Википедия не является истиной в последней инстанции.
Но можно сделать проще — поищите, сколько ERP систем поддерживают «производство на заказ» — удивитесь. :))) А это классический пример «вытягивания».
Ну причина проблем, как обычно, в прокладке. :)
Вот именно такая ситуация (ну разве что не паллета а контейнер, и не в воронеже и хабаровске, а в амстердаме и новом орлеане))) прекрасно была решена в навике. Все затраты, включая транспортные, включались в себестоимость, а в конце каждого квартала все транспортные затраты, и прочие, которые не должны быть на балансе, но были в составе себестоимости на складе — списывались реверсивной фин проводкой на затраты. И всё! И отчетность в полном соответствии с МСФО, и возможность анализа сохраняется. :)
Но лучше писать более четко. Потому как некорректное сальдо по некоторым счетам — не то же самое, как порванный баланс, когда сумма оборотов по всем счетам по кредиту не равна сумме оборотов по дебиту. Такие вещи только при ручном учете бывают, я не слышал ни про одну систему, где автоматом такие вещи не контролируются.
Читаем буквально в следующей строке:
931 доллар ЗА СЕРВЕР без учета количества ядер!
Учитывая, что CALы у нас уже были куплены для других целей, стоимость MS SQL Standard Edition для целей аналитики составила эти самые 931 доллар и всё. Больше нам ничего платить не пришлось.
И даже если надо покупать CALы. Стоят они 200 баксов за юзера. Скольким юзерам в небольшой фирме нужен доступ к аналитике? 30-40, максимум 50. 50 * 200 = 10000 долларов на CALы. Приплюсовываем 1000 на серверную лицензию — 11000 долларов за софт для аналитики, что тоже отнюдь не заоблачная цена.
Мы купили лицензию на сервер (виртуальную машину). И стоила эта лицензия примерно одну тысячу долларов. Посмотри сам на Цены на SQL Server именно на Standard Edition. Правда, под аналитику у нас выделено не 22, а 14 ядер, но нам этого хватает.
А так как у нас ERP (навижин) и так крутилась на ms sql, и юзеры уже пользовались экселем (через него смотрим кубы), никаких дополнительных затрат на софт для аналитики нести не пришлось.
В том то и дело, что для небольших компаний ms sql standard (про оракл не знаю) во многих случаях очень даже приемлемый вариант как по цене, так и по скорости.
Но, как я уже говорил, для относительно небольших объемов данных стандарт едитион (плюс быстрые ссд диски) вполне хватает.
И совокупная стоимость получается существенно ниже альтернативных вариантов (если включать зарплату специалистов).
Поэтому я и говорю, что для небольших компаний есть весомые резоны делать аналитику на стандартной субд, той же мс скл. Совокупная стоимость достаточно низкая и при этом альтернативы получаются дороже.
Вот немного на эту тему: Partitioned Tables and Indexes
Если честно, я не настолько глубоко погружался в этот вопрос (что именно параллелит ms sql). На практике, если нормально спроектировать структуру куба, всё работает с приемлемой скоростью (если мы говорим об объемах данных небольших и средних компаний — десятки / сотни миллионов записей).
Небольшие компании — это десятки — сотни миллионов записей (не миллиарды — десятки — сотни миллиардов). И под такие объемы тот же Microsoft SQL Server Standard хорошо справляется (кубы и база в качестве DWH). Партицирования не хватает (в стандарте только 4 партиции разрешено), но жить можно.
А по цене — если арендовать сервер с сиквелом в том же Azure, то по цене вполне нормально. И для таких объемов данных — хватает.
Могут быть не очень опытные HRы — в этом нет ничего страшного. Но когда в роли HRа неадекватный человек — это симптом, характеризующий всю фирму.
И с тех пор я просто обновляю его, а большая часть оформления (что выделять, что курсивом и тп) осталась из первоначального шаблона. Зачем что-то придумывать, если есть уже готовая форма? :)
"Потом есть великая вещь, оборотно-сальдовая ведомость твоего бизнеса. Она должна быть чёрная. Красная – это когда у тебя что-то не бьётся. Если ты всё сделал, потом сформировал сальдо-оборотку, она у тебя должна быть чёрная, сведена, дебет ноль, кредит ноль, всё хорошо. Это означает, что на всех этапах всё у тебя было хорошо. А если у тебя произошла какая-то ошибка, сальдо-оборотка красная."
А это как? То есть чисто технически — как в стандартной конфигурации 1С получается не свести дебет с кредитом? При ручном учёт это сделать совсем легко, а вот как в той же 1С порвать оборотку?
"Потому что на самом деле нормальный предприниматель всегда знает, сколько воды он продал, и сколько воды ему нужно поставить завтра в магазин, чтобы её продать. Это суть его бизнеса. На самом деле, если у предпринимателя нет управленческого учёта, то у него скорее всего бизнеса не будет."
Вот это всё же правильнее называть оперативным учётом. Управленческий учёт — это немного другое. Те же кост центры — управленческий, а 100 кг мяса в бургерную пришло — оперативный.
А вот то, что Деминг, прежде чем придумывать что-то свое, внимательно изучил опыт предшественников — очень даже связано с вашими «открытиями». Ведь вы даже не удосужились разобраться — что такое MRP. Вы ведь, судя по всему, даже ту лекцию Колумбийского университета не прочитали, ссылку на которую привели. :)
Когда программист начинает рассказывать байки про «улучшение качества отношений», как PR менеджер — сразу вспоминается анекдот про морскую свинку, которая ни к морю, ни к свиньям отношения не имеет.
С чего обсуждение начиналось?
«ERP система — это система поддерживающая первый, выталкивающий тип производства.»
В качестве доказательства привели сомнительную статью на википедии и ссылку на лекцию Колумбийского универа.
В лекции черным по белому написано:
«The three major inputs of an MRP system are the master production schedule, the product
structure records, and the inventory status records.»
Вместо того, чтобы или доказать, каким образом MRP является «выталкивающим» при том, что план производства является для него входящими данными, или признать свою ошибку, вы начинаете рассказывать байки про улучшение отношений.
Как показывает опыт, люди, не удосужившиеся изучить изобретенное предшественниками, в 99% изобретают не просто велосипед, а плохой велосипед.
Впрочем — дерзайте. Есть желание изобретать велосипеды и называть их новыми словами — кто я такой, чтобы мешать?
Да-да, я понял — вы придумали не велосипед, а ногоезд.
И он сильно круче велосипеда, так как принципиально другой.
Почитайте, например, ту лекцию Колумбийского университета, которую ВЫ и привели www.columbia.edu/~gmg2/4000/pdf/lect_06.pdf. :)))
И подставьте ваши данные — простой одноуровневый BOM (рецепт) и произвести надо «сейчас».
«MRP will determine from the master production schedule and the product structure records the
gross component requirements; the gross component requirements will be reduced by the available
inventory as indicated in the inventory status records.»
«Поступает заказ на изготовление блюда, система анализирует небольшие запасы на кухне, если все есть, то заказ уходит на кухню.
…
Если продукта нет или стало меньше критического значения, то автоматически формируется заявка на доставку необходимых продуктов у поставщика.»
Впрочем, если вам нравится изобретать велосипеды — дело ваше.
А обещали описать какой-то другой алгоритм, более эффективный… Как после этого верить людям? :)))
Почитайте по ERP системам что-то более серьезное, чем википедия. Меньше будет велосипедов и выше качество решений.
Ну приведите пример более эффективного алгоритма для мелкого производства. :)
Сам по себе алгоритм MRP ничего не «решает» о количестве готовой продукции, которое необходимо получить на выходе. Основной план / график производства (спрос) — это входящая информация для алгоритма MRP.
Создаете график производства на основе неких планов — получаете «выталкивающую» схему (производственники говорят продажникам — вот, мы это произвели — продавайте).
Создаете график производства на основе фактических заказов от покупателей — и, ни одного байта не меняя в алгоритме MRP, — получаете «вытягивающую» схему (продажники говорят производственникам — вот, мы это продали — производите).
MRP ортогонален к противостоянию «выталкивание» / «вытягивание». Он вообще не про это.
Но можно сделать проще — поищите, сколько ERP систем поддерживают «производство на заказ» — удивитесь. :))) А это классический пример «вытягивания».