Цитата Сообщение от sibgaba Посмотреть сообщение
Собственно опять пришли к тому о чем я говорил: On-Line у нас или Off-Line - не важно. Цифры (в ОПИУ, в себестоимости) не будут верными пока не введем всю первичку...

ИМНО: Такой плюс ОнЛайна как контроль себестоимости можно хоронить...
У ОнЛайна есть два плюса:

Первый в том, что мы получаем информацию без задержки. Эта информация может быть разная: например, наличие "отрицательных" остатков говорит нам, что у нас присутствуют ошибки в учете (не отражен приход товара или некорректно заполнены рецепты), но нет смысла оспаривать тот факт, что ее наличие помогает принимать решения быстрее. Этот плюс — в первую очередь для владельца / управляющего.

Второй плюс — это то, что при нахождении ошибки мы можем ее сразу же исправить без длительной процедуры "откатывания" (или "перепроведения"). Этот плюс — для оператора (бухгалтера-калькулятора) который следит, чтобы первичка была введена, техкарты были правильными, а информация по складу достоверной, и по роду своих занятий должен исправлять найденные ошибки.

Первый плюс можно нивелировать идеальным администрированием: когда учет ведется день-в-день, операторы заменяют друг друга в случае болезни/отпуска/выходных и т.д. Проблема только в том, что в реальной жизни не бывает ничего идеального, и держать "взаимозаменяемых" сотрудников слишком дорого. В реальности, то, что мы видим у 9/10 клиентов, выглядит так: бух-калк считает своей обязанностью следить за складом, то есть вводить первичку и сравнивать книжные остатки с инвентаризацией. Поэтому у него в принципе нет задачи вести ежедневные списания: инвентура-то делается раз в месяц. Директор или владелец сам не открывает стор-хаус, потому что сторхаус - это программа для бухгалтера-калькулятора, там все сложно. Вместо этого он получает отчет о себестоимости, остатках и т.д. раз в месяц. Как результат — контроль "раз в месяц".

Сообщение от sibgaba
Например я покупал морковь по 10 рублей, мне привезли новую морковь по 100 рублей, но я её ещё не забил в iiko. Программа создаёт на складе отрицательный остаток и считает себестоимость этой моркови по средневзвешенной себестоимости. Если сформируем Отчёт о продажах, то себестоимость будет X (порядка 10 рублей), когда мы оприходовали морковь по новой цене на отрицательный остаток, то себестоимость естественно скакнёт вверх.



Соответственно после того как мы сделали приход - себестоимость в отчетах изменилась. Инвентаризаций не было... На излишки (да и какие это к черту излишки то, если реально на кухне морковь была) не спишешь...
Я не понял, что вам кажется странным или неправильным? То, что себестоимость изменяется при вводе данных "задним числом" или сама возможность "ввода в прошлом"?

Я попробую зайти с другой стороны:

Когда вы нашли ошибку в "прошлом" (пусть, как в нашем примере, не введен приход товара), независимо от того, в какой программе вы работаете, у вас есть выбор: исправить ошибку или отразить ее в учете. Исправить в нашем случае — это ввести приход задним числом. Отразить — это оприходовать красный остаток в инвентаризации и сделать переоценку текущей партии товара с учетом стоимости прихода, который вы забыли ввести ранее. По-моему, второй вариант — это страшный сон, оказаться в котором разумный человек может только при отсутствии первого варианта (возможности исправить ошибку).

Однако, исправление задним числом — это довольно ресурсоемкая операция, поскольку требует большого кол-ва вычислений, особенно при использовании схемы FIFO для расчета себестоимости, и сделать ее быстрой реально непросто. Поэтому большинство программ, при работе по FIFO, просто запрещают проведение документов, приводящих к красным остаткам (iiko здесь не исключение). Как идеальный результат мы должны бы получить учет без ошибок "в прошлом". В реальности, понятно, этого не происходит, поскольку закупки делаются до того, как товар закончится, и до того как остаток станет отрицательным, он уже несколько дней будет неверным (хоть и > 0). В результате, все равно придется пересчитывать задним числом или извращаться с инвентаризацией и переоценкой.