Вопрос к противникам контроля остатков в прошлых периодах — как вы относитесь к тому, что в УТ 11 остатки контролируются независимо от даты документа? Стали бы вы это исправлять при внедрении УТ 11?
>>ЕСЛИ контролировать остатки и запрещать проведение при недостаче на учетных остатках какой-то (одной) позиции — патологию ведь не рассматриваем, верно? — получится, что по всем остальным позициям остатки, на основании которых выполняется оперативный ввод данных (см.п.1) станут (останутся) неверными
Ввода реализаций задним числом вообще быть не должно. При перепроведении или редакторивании задним числом в случае отказа программа не отменяет проведение документа, остатки по остальным позициям не изменятся.
>>т.о. более оптимальным, нежели непроведение при нехватке остатков для документов, корректируемых «задним числом» (напомню — по факту отгрузки!) будет безусловное из проведение с включением в список документов для последующего регламентного контроля корректности их оформления.
Тоже вариант
Гарантировать программа ничего не может, если в нее вбиваются неверные данные. Но программа может и помогать в контроле правильности ввода, если включен контроль остатков, а может не помогать, если выключен контроль остатков, а может еще и немного вредить, если неправильно вносить данные.
Конечно контроль остатков не решит всех проблем возникающих с отгрузкой, но будет служить индикатором того, что данные в программе не соответствуют действительности.
>>Если у вас сотрудники настолько тупые, что отдают товар не глядя ни на что, то ни 1С ни какая либо другая программа тут бессильна.
Речь не про то как отдают, а про то как заносят данные в программу. Ситуация, когда привезли товар одной серии, потом его продали, а потом оказалось, что ошиблись где-нибудь, например в серии не так уж редка.
Спасибо, эту мантру я уже читал, знаю наизусть. А говорил я о том, что если в 1С сделали программу по определенной методике и если она логична и понятна, то это еще не значит, что она идеально, лишена недостатков и подходит для всех организаций. Много лет работали и еще работают в семерке с контролем остатков на дату документа и ничего, все живы.
>>Вы отдали со склада 4 ящика товара, и какая разница что в тот момент было на остатках в программе, если вы их физически отдали?
А если не отдали или отдали, но не их, или отдали, но не 4 ящика или отдали, но не те 4 ящика, а другие с другой серией и сроком годности?
>>Если остаток товара в программе при этом не совпадает с реальным, то вы ССЗБ.
Я то да, буду ССЗБ, но кроме меня пострадают еще и менеджеры по продажам, которые скажут клиенту, что товара нет, хотя он будет на складе валяться. Пострадают еще менеджеры по закупке, которые кинутся докупать товар, который еще есть на складе. В бухгалтерии неправильно рассчитается себестоимость и налоги. А финансисты подадут руководству отчет с неправильными цифрами.
Хм. Да и правда предлагает провести оперативно и неоперативно в УПП, извиняюсь. Но перед этим колдовал с чеками ККМ в УТ 11, они всегда проводятся оперативно, если текущей датой, даже с полными правами.
>>Бить по рукам — основания нужны
Если устно не понимают, то можно внести в регламент запрет на создание документов реализации за вчерашний день (можно и программно закрыть к этому доступ). В качестве исключений оставить только форс-мажорные обстоятельства, которые я с ходу даже и придумать не могу. Реализации за сегодняшний день в любом случае проводятся оперативно и в них время просто так невозможно изменить, платформа всё равно выставит текущее время.
>>«с другим оператором разбираются» — весьма вредно для процесса
А если менеджер Вася отгрузит сегодня литр спирта со склада, который по факту есть, а потом пойдет выписывать накладную, а программа ему не даст это сделать, потому что по учету спирта не оказалось. Он к кому пойдет ругаться — к программисту, что у него программа неправильно работает или всё-таки к кладовщику или оператору лучше пойти и с ним поговорить?
А по рукам бить не пробовали менеджеров, которые хотят 31 марта ввести реализацию товаров, с датой 30 марта? Во всех типовых конфигурациях пользователь имеет возможность ввести документ вчерашним днем, это почему-то никого не смущает. Разрешить добавлять документы только оперативно можно, но это создаст дополнительные проблемы и это совсем другая история А вот если при этом еще и остаток контролировать, то почему-то сразу караул нужно кричать.
>>Потому что он кристально честно вводит факт. а уход в минус происходит по причине корректировок, внесенных другим оператором
Ну и пусть с другим оператором разбираются почему тот корректировки внес. Он же не изолированно в вакууме работает, может и поинтересоваться, не растает
>>все-таки включенный контроль остатков в виде «кальки» с оперативного — на практике очень часто выливается в «номенклатурные войны» менеджеров — в случае непроведения по причине нехватки остатка менеджер спокойно «задвигает» свой документ перед уже проведенным документом, расходующим «дефицитную» номенклатурную позицию
Каким образом!? Если он проведет сегодняшнюю реализацию вчерашним днем, нарушая последовательность и нумерацию документов, то тут медицина бессильна, в этом случае отсутствие контроля остатков при неоперативном проведении вас никак не спасет, все равно.
>>«я ввожу то, что уже было отгружено фактически. а то, что ваша программа не дает это ввести — не моя проблема, а проблема программы»
Нет, это его проблема, а не программы. Если эта реализация по факту была, а по учету товар уходит в минус, значит какая-то другая реализация или поступление оформлены неверно и нужно поднимать и сверять документы, иначе потом все еще больше поплывет
Разницу между оперативным вводом и неоперативным я знаю. Однако из вашего комментария я не понял почему при вводе документов остатки нужно контролировать, а при исправлении нет. Работу замедлит, но если сервер берется с запасом, то не так уж значительно, т.к. при проведении в любом случае производятся множество других не менее ресурсоемких запросов к базе (списание партий при партионном учете, движение по регистрам УСН, взаиморасчетам и т.д.).
На хронологические моменты всех следующих документов проверять в момент проведения не вижу смысла, достаточно, чтобы оператор понимал, что такая ошибка служит сигналом для восстановления последовательности документов. Но последовательность нужно будет восстанавливать и без контроля остатков.
Я так и не понял из той ветки почему это плохо. Быстродействие несколько пострадает, но в остальном хуже от этого не будет. Если какой-то документ в прошлом ругается, то это уже звоночек — либо какой-то документ поступления изменился (серия, номенклатура, количество изменены неправильно), без изменения последующих реализаций, либо неправильно вписали количество также задним числом в другой реализации, либо проведение каких-либо документов отменено. И разбираться лучше не дожидаясь инвентаризации, чтобы не бегать потом с горящими глазами «аааа, кошмар, у нас ничего не сходится, у нас ничего не работает!!111!». Методики, разработанные 1С это хорошо, но истинной в последней инстанции являться не могут.
Судя по комментариям народ скорее веселит различие между ожиданием большинства студентов и тем, что они будут получать. 150 тысяч хотят получать каждый третий, а реально будут получать максимум каждый десятый. И большинство из них будут столько зарабатывать не сразу после выпуска, а лет через несколько.
На фрилансе таких единицы. Я пока знаком только с двумя — один программист 1С, с опытом почти 8 лет, другой консультант SAP тоже с немалым опытом.
Успешный бизнес далеко не всем удается построить
Почему именно такая экономика для вас идеальная? И не получится ли, что стоимость гвоздя в этой идеальной экономики в 3 раза выше, чем в нормальной не идеальной только за счет того, что кому-то пришло в голову вести учет поштучно?
Когда не знаешь где какую деталь продали, то считаешь либо по средней, либо по фифо, либо с использованием РАУЗ и т.д. Причем расчет будет однозначным (14 рублей себестоимости для каждой детали по средней, либо 10 и 18 рублей себестоимости по ФИФО). А у вас получается, что себестоимость будет зависеть от того перепутал или нет кладовщик на складе два идентичных гвоздя. Если один гвоздь отгрузил то себестоимость 10 рублей, а если из коробки достал другой гвоздь, то уже 18. А практической пользы от этой информации не будет ни для менеджеров, ни для кладовщиков, ни для финансистов, ни для владельцев бизнеса.
Представьте, что гвоздей не два, а сто миллионов. Вы принесете руководству подробный отчет на сто миллионов строк в каждой из которых будет указано когда он был куплен, когда он был продан, по какой цене купили, по какой цене продали?
А ниже видимо будет сноска «спасибо большое за помощь в создании отчета коллективу из 150 кладовщиков и операторов, а также десятку сисадминов и пятерым программистам, обслуживающим дата центр в котором в течении суток выводился и распечатывался данный отчет».
А я принесу отчет в котором будет одна строчка с информацией о том, что было продано сто миллионов гвоздей на сумму в 150 миллионов рублей, на складе осталось 50 миллионов гвоздей, на сумму 100 миллионов рублей. В связи с тем, что себестоимость оставшейся партии в составляет 2 рубля, вместо 1.5 предлагаю поднять цену на 50%.
>>Здесь бухгалтерская методология не копирует реальность, для отражения которой вроде бы предназначена, а наоборот, регламентирует расхождение между реальностью и информационной системой. Можно сказать, что регламентация вынужденная, а можно посетовать на отсутствие идентификации объектов реального мира. Решить автоматизатору подобную идентификационную проблему мудрено, конечно, но должен же он понимать, что решение заключается не только в написании идеального программного кода, но и в организации общего товарооборота, да и вообще – в какое неоднозначное дело вляпался.
Зачем кому-то может понадобиться знать какая реально деталь была продана — из первой партии или из второй, если для кладовщика и покупателя они идентичны?
>> И да, долгие споры о том, кто должен вести «черный список» закончились вынесением предложения загрузить этой работой третьи лица, сторонняя компания. Роскомнадзор получит право привлечь к этой работе избранную Роскомнадзором компанию/организацию.
Ввода реализаций задним числом вообще быть не должно. При перепроведении или редакторивании задним числом в случае отказа программа не отменяет проведение документа, остатки по остальным позициям не изменятся.
>>т.о. более оптимальным, нежели непроведение при нехватке остатков для документов, корректируемых «задним числом» (напомню — по факту отгрузки!) будет безусловное из проведение с включением в список документов для последующего регламентного контроля корректности их оформления.
Тоже вариант
Конечно контроль остатков не решит всех проблем возникающих с отгрузкой, но будет служить индикатором того, что данные в программе не соответствуют действительности.
>>Если у вас сотрудники настолько тупые, что отдают товар не глядя ни на что, то ни 1С ни какая либо другая программа тут бессильна.
Речь не про то как отдают, а про то как заносят данные в программу. Ситуация, когда привезли товар одной серии, потом его продали, а потом оказалось, что ошиблись где-нибудь, например в серии не так уж редка.
>>Вы отдали со склада 4 ящика товара, и какая разница что в тот момент было на остатках в программе, если вы их физически отдали?
А если не отдали или отдали, но не их, или отдали, но не 4 ящика или отдали, но не те 4 ящика, а другие с другой серией и сроком годности?
>>Если остаток товара в программе при этом не совпадает с реальным, то вы ССЗБ.
Я то да, буду ССЗБ, но кроме меня пострадают еще и менеджеры по продажам, которые скажут клиенту, что товара нет, хотя он будет на складе валяться. Пострадают еще менеджеры по закупке, которые кинутся докупать товар, который еще есть на складе. В бухгалтерии неправильно рассчитается себестоимость и налоги. А финансисты подадут руководству отчет с неправильными цифрами.
Если устно не понимают, то можно внести в регламент запрет на создание документов реализации за вчерашний день (можно и программно закрыть к этому доступ). В качестве исключений оставить только форс-мажорные обстоятельства, которые я с ходу даже и придумать не могу. Реализации за сегодняшний день в любом случае проводятся оперативно и в них время просто так невозможно изменить, платформа всё равно выставит текущее время.
>>«с другим оператором разбираются» — весьма вредно для процесса
А если менеджер Вася отгрузит сегодня литр спирта со склада, который по факту есть, а потом пойдет выписывать накладную, а программа ему не даст это сделать, потому что по учету спирта не оказалось. Он к кому пойдет ругаться — к программисту, что у него программа неправильно работает или всё-таки к кладовщику или оператору лучше пойти и с ним поговорить?
>>Потому что он кристально честно вводит факт. а уход в минус происходит по причине корректировок, внесенных другим оператором
Ну и пусть с другим оператором разбираются почему тот корректировки внес. Он же не изолированно в вакууме работает, может и поинтересоваться, не растает
Каким образом!? Если он проведет сегодняшнюю реализацию вчерашним днем, нарушая последовательность и нумерацию документов, то тут медицина бессильна, в этом случае отсутствие контроля остатков при неоперативном проведении вас никак не спасет, все равно.
>>«я ввожу то, что уже было отгружено фактически. а то, что ваша программа не дает это ввести — не моя проблема, а проблема программы»
Нет, это его проблема, а не программы. Если эта реализация по факту была, а по учету товар уходит в минус, значит какая-то другая реализация или поступление оформлены неверно и нужно поднимать и сверять документы, иначе потом все еще больше поплывет
На хронологические моменты всех следующих документов проверять в момент проведения не вижу смысла, достаточно, чтобы оператор понимал, что такая ошибка служит сигналом для восстановления последовательности документов. Но последовательность нужно будет восстанавливать и без контроля остатков.
Успешный бизнес далеко не всем удается построить
Представьте, что гвоздей не два, а сто миллионов. Вы принесете руководству подробный отчет на сто миллионов строк в каждой из которых будет указано когда он был куплен, когда он был продан, по какой цене купили, по какой цене продали?
А ниже видимо будет сноска «спасибо большое за помощь в создании отчета коллективу из 150 кладовщиков и операторов, а также десятку сисадминов и пятерым программистам, обслуживающим дата центр в котором в течении суток выводился и распечатывался данный отчет».
А я принесу отчет в котором будет одна строчка с информацией о том, что было продано сто миллионов гвоздей на сумму в 150 миллионов рублей, на складе осталось 50 миллионов гвоздей, на сумму 100 миллионов рублей. В связи с тем, что себестоимость оставшейся партии в составляет 2 рубля, вместо 1.5 предлагаю поднять цену на 50%.
Как думаете какая информация окажется полезнее?
Зачем кому-то может понадобиться знать какая реально деталь была продана — из первой партии или из второй, если для кладовщика и покупателя они идентичны?
www.v8g.ru/wass/
Нагрузят работой Михалкова?