Заказ звонка

Закрыть

*
*
*

Ошибки в оборотах

Страницы: 1 2 След.
RSS
Ошибки в оборотах
Ввожу расход за прошлый год. Нацчился делать это правильно но вылезла ошибка в оборотах на материалах у которых нет расходов. Пересчет учетных карточек запускал, не помогает.
Такой эффект происходит если расход сделать раньше прихода в учетной карточке но в данном случае ошибки в позициях где только одни поступления.
Изменено: shurick - 24.01.2014 19:20:43
Еще такая ошибка возникает если сделать период с 01.01.13 по сегодня а если конец передвинуть на конец прошлого года то минусы пропадают. Я когда заносил расходы периодически делал проверку оборотами но период ставил тот которым на тот момент заканчивались расходы а потом случайно не сдвинул конец и получил такое... Что делать? Боюсь вводить дальше чтобы не переделывать ВСЕ потом.
Изменено: shurick - 24.01.2014 19:28:31
А вот тут материал которого на начало года не существовало вообще. Два поступления сделаны еще тогда, не задним числом, без переноса документа.
Цитата
shurick пишет:
Научился делать это правильно
Значит всё таки не научились...

Как вы знаете, пользовательские модули (Приход / Расход) не предполагают операций задним числом. Пришло на склад - отметили. Отметили выдачу - выдали. Когда принимаем/выдаём, тогда и отмечаем. Собирается информация о текущих событиях - получается стройная картина движения материалов, остатков, оборотов.

Отрицательных остатков при таком раскладе образоваться не может в принципе. Модуль Расход просто не даёт выдать то, чего нет или выдать больше чем есть на складе.

Внесение каких-то изменений и корректировок задним числом доступно только администратору. Вручную. Для исправления ошибок, если таковые вдруг случаться.

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

1. надо делать всё вручную (создавать документы, карточки и т.д.). Т.к. если вы будете пытаться параллельно использовать штатные модули Приход и Расход, которые «заточены» под работу в реальном времени и алгоритмы FIFO и LIFO, то как они могут и не понять такую «подтасованную» информацию. Которая не согласуется с реальным временем и последовательностью действий.

2. надо делать всё очень методично и аккуратно, в точности воспроизводя вручную алгоритм работы программы. Создавать карточки при приходе, выбирать нужные карточки при расходе, не забывать менять при этом дату везде текущую на «подложную». Не нарушать порядок.

Если вы будете делать не так, или где-то что-то упустите случайно, то потом вся такая «подтасованная» конструкция запросто может и развалиться.

Теперь к сути вопроса.

1. Учитывая вышесказанное, 99% вероятности, что дело не в ошибке в программе. Программа в данном случае с вероятностью близкой к 100% работает правильно. Проблемы в том, что ручная «подтасовка» данных, судя по всему, не совсем удалась. Вероятнее всего, где-то на каком-то этапе был нарушен один из вышеуказанных принципов. Или несколько сразу.

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

Цитата
shurick пишет:
Пересчет учетных карточек запускал
А это что значит?
Если вы самостоятельно на этой базе данных запускали какие-либо скрипты на уровне SQL сервера, то это очень плохо. Этого делать категорически не рекомендуется.

С точки зрения последствий для работы программы, это как открыть в автомобиле капот, открыть маслозаливную горловину двигателя и влить туда бутылку жидкости неизвестного типа и содержания.
Теоретическая вероятность, что от этого работать станет лучше, существует. Но небольшая. Более вероятно, что станет хуже. Причём сразу после вливания это может быть и незаметно. В худшем случае, через какое-то время двигатель полностью выйдет из строя.
В целом, по теме (всё нижесказанное, исключительно IMHO автора, вы можете не согласиться):

Я вообще-то изначально был радикально против любых подобных операций в складской системе VOGBIT задним числом. И дело даже не столько в том, что пытаясь использовать программу таким нештатным образом, вы неизбежно наживаете себе гарантированную головную боль (эта тема яркое тому подтверждение). Корень зла, IMHO в другом. Глубже.

Для чего вообще нужен VOGBIT? В первую очередь, чтобы улучшать производственную систему, совершенствовать её, делать более эффективной. Чтобы в итоге она работала лучше: лишнее не тратилось, производительность была высокой, качество стабильным, процессы предсказуемыми и т.д. Это цель, «стратегия». За счёт чего эта цель достигается? Какая «тактика»? В целом в основу работы программы положен следующий принцип: по ходу деятельности реальной производственной системы реальная информация об этой деятельности «по крупицам» собирается в системе. Тут что-то сделали – отметили, там отдали – отметили и т.д. Эти разрозненные кусочки общей картины в программе складываются, систематизируются, и представляются руководителю в таком виде, что он наглядно видит чёткую, общую картину. Ему становится понятно, где слабые места, что нужно сделать для улучшения, а чего наоборот, не стоит делать. Он понимает, где и какое воздействие требуется. Кроме того, такой стиль работы сам по себе предполагает выстраивание определённого порядка. Вся деятельность «натягивается» на некий «скелет», упорядочивается, появляются определённые правила, как и что должно делаться. А такие правила, это как раз то, что отличает высокоорганизованное эффективное производство от того, что называется «на коленке».

Как это выглядит в приложении к складскому учёту:

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

При правильной организации делать так совсем не сложно. Главная проблема внедрения заключается в том, что склад находится «в середине» бизнес процесса. К нему просто нужно подходить только в определённый момент. А не сразу (как бы не хотелось). Очень трудно и неудобно будет, например, пытаться организовать на складе учёт в программе, если производство в этой программе полноценно не работает. И наоборот – легко, если производство, которое обслуживается складом, само полноценно в VOGBIT уже работает.

Какой эффект будет если именно так выстроить работу:
Во-первых, появляется порядок. Ничего никуда не денется. Всякое движение упорядочено и учтено, а не хаотично. Во-вторых, через неделю, месяц, два у руководителя автоматически появляется полная и актуальная картина. Реальные остатки, обороты, скорость движения тех или иных позиций, «неликвиды», информация, что куда пошло и т.д. Причём, что называется, «само». То есть, если именно оперативный учёт на складе чётко организован, то дальше для получения подобных отчётов и информации уже ничего делать не надо. Никакой головной боли. Своды за месяц/квартал/год - всё получается само собой, автоматически.

Теперь вернёмся к вопросу о «задним числом». Что это означает? С моей точки зрения то, что оперативный учёт на складе на самом деле то не организован. Не поступает оттуда ежедневно достоверная информация, что пришло и что ушло. Нет этого (иначе, откуда операции «за прошлый год»? ). То есть фундаментально в производственной системе изменений не произошло. Как всё было в этом её месте, так по сути и осталось.

То, что мы пытаемся задним числом вводить в VOGBIT, какие-то приходы и расходы на складе – это НЕ значит, что мы получаем учёт. Это, скорее, как «подгонка» решения задачи под известный ответ, вместо настоящего «решения» этой задачи. Причём в отличие от "подгонки" в школьной задаче, в данном случае мы ещё и не знаем заранее, правильный ли тот ответ, под который мы подгоняем smile:) В итоге мы получаем не реальную картину как работает система, а всего лишь модель, которую сами же и построили. Получается не учёт, а модель учёта...

IMHO, главное зло в попытке воспроизводить в программе учёт, которого на самом деле не было, это то, что это получается такой глобальный самообман. Как играть в покер самому с собой. Каждое отдельное действие, вроде бы, осмысленное. Выдать карту, поменять карту, собрать комбинацию. Но вот в общем, если на всё это посмотреть – разве интересно?
Константин, очень приятно что Вы не поленились в выходной день написать такую пламенную речь агитирующую за то что лучше быть богатым и здоровым чем бедным и больным.
То что мы не вводим расходы в реальном времени это издержки внедрения а не потому что нам так нравится или не знаем как надо правильно.

Теперь если вернуться к технической стороне вопроса то все очень просто. В базе имеется два приходных ордера, проведение которых делает отрицательным остаток на начало года. Причем один из них сделать задним числом мной с переносом даты а вот второй сделан летом точно когда и было поступление. Расходов по ним и тем более введенных задним числом нет. И если первый рушит остаток только по одному входящему в него материалу то второй настоящий по всем, ну или почти по всем. Я сейчас их удалю и введу заново и они наверняка станут работать нормально но хотелось бы понимать причину такого явления потому что в будущем не исключены такие же ошибки и хочется знать ответ заранее а не метаться в панике перед сдачей баланса когда нужно уже получить данные о материалах в производстве.

Запросы которые я запускал вручную я не сам придумал а Вы мне прислали:
Upd ate Stock.RegCards
Se t Stock = 0, StockSum = 0
exec Stock.RecalcAccDocs
Ну в общем разобравшись на свежую голову во всех случаях выявились косяки ручного ковыряния. Где-то расход раньше прихода в учетной карточке, где-то места хранения перепутаны...

Кстати, как поступление ТМЦ по одной накладной поставщика разнести на разные склады? Если делать два раза поступление в Складском учете то создадутся разные накладные поставщика как я понимаю. С точки зрения математики ничего страшного но при проверке реестров документов в бумажке будет одна общая сумма а в программе несколько маленьких.
Может при оформлении прихода поставить один и тот же "номер накладной поставщика"?
Тогда в программе расчётных документа (и прихода соответственно) будет два, но будет видно, что они сделаны на основании одного и того же "внешнего" документа. Получится, как бы, две половники одной и той же "внешней" накладной.
А вручную приклеить к расчетному документу накладной поставщика два учетных можно?
Если руками всё делать, а не через штатный модуль Приход, то всё можно.
А зачем?
Чем не устраивает вариант с двумя расчётными документами? Ну будет половинка содержания накладной бумажной в одном расчётном документе, половинка в другом расчётном документе. В комментарии у обоих будет стоять один и тот же номер накладной поставщика. Что такого?
Страницы: 1 2 След.
Читают тему (гостей: 1, пользователей: 0, из них скрытых: 0)