19.03.2012 17:00
здравствуйте.
есть такой вопрос: при вводе операторами накладных, часто проявляются два вида ошибок: первая из-за разных алгоритмов округления у поставщика и в супермаге (что приводит к отличиям в суммах в несколько рублей-десятков рублей), вторая из-за ошибки оператора. если в административном модуле включить возможность запрета принятия накладных и дать разрешение только ответственному лицу, то магазины встанут, т.к. накладных очень много. если поставить проверку в виде "предупреждения", то операторы могут просто игнорировать это предупреждение. подскажите, пож-та, как можно решить эту проблему?
19.03.2012 17:03
а что насчёт включить проверку на соответствие суммы документа поставщика и суммы накладной?
19.03.2012 17:14
функция называется "Несоответствие суммы по документу с суммой по документу поставщика". я про неё и говорил. там есть три варианта: запретить, предупредить и не обращать внимание. так вот если ошибка проявилась из-за разницы в алгоритмах округления у поставщика и в супермаге, то разница в сумме копеечная для бухгалтерия значения не имеющая. а если это ошибка оператора, то могло бы быть два варианта использования этой функции - запретить операторам принимать принимать накладные с несоответствием, и дать права ответственному лицу - это не реальный вариант, т.к. накладных очень много. и второе - выводить предупреждение на экран при несоответствии сумм. но этот вариант легко оператором игнорируется. т.е. ни то ни то как бы и не подходит. т.е. было бы удобно например чтобы при копеечной разнице несоответствие пропускалось, а при разнице больше определённого уровня накладная блокировалась до выявления ошибки. но этой возможности в супермаге нет.
19.03.2012 17:15
А очень много, это сколько?
19.03.2012 17:18
а не лучше ли тогда использовать ввод суммы, а не цены в накладной?
19.03.2012 17:34
при правильном выборе режима округления разница возникает нечасто и она реально копеечная. легко подгоняется правкой последней позиции.

операторские ошибки ввода полной суммы накладной быстро и эффективно выводятся методом "получи по шапке".

сложнее, когда накладные приходят к операторам с большим количеством вычерков и без пересчета итоговой суммы. тут уж сами решайте, на какой должности у вас трудятся люди, вполне владеющие высоким искусством пересчета суммы накладной на калькуляторе. варианты видел разные. где оператору вменяли в обязанность пересчитать перед вводом накладной, где товароведу, который заказывал, где приемщику, где экспедитору поставщика... самый жесткий, который встречал - накладная с недовозом не принимается вовсе.
19.03.2012 17:51
Согласен с whitewizard. Сумма по накладной (не цена конкретного товара), которая забивается в СМ должна совпадать с накладной поставщика. ПОэтому по умолчанию должно стоять - округление суммы. Ну а если цена товара по накладной не сходится на десятые доли копеек - да и бог с ним.
19.03.2012 17:54
Цитата:
Andrew_Konev при правильном выборе режима округления разница возникает нечасто и она реально копеечная. легко подгоняется правкой последней позиции.

операторские ошибки ввода полной суммы накладной быстро и эффективно выводятся методом "получи по шапке".

сложнее, когда накладные приходят к операторам с большим количеством вычерков и без пересчета итоговой суммы. тут уж сами решайте, на какой должности у вас трудятся люди, вполне владеющие высоким искусством пересчета суммы накладной на калькуляторе. варианты видел разные. где оператору вменяли в обязанность пересчитать перед вводом накладной, где товароведу, который заказывал, где приемщику, где экспедитору поставщика... самый жесткий, который встречал - накладная с недовозом не принимается вовсе.
В таких случаях у нас, чтобы не тормозить процесс, забивается все по цене товара. Сумма вводится идентичная получившейся. А потом бухгалтерия и манагеры разруливают ситуацию с корректировкой накладной задним числом, если есть какие то косяки.
20.03.2012 00:38
Так а в чем проблема? Выставляем округление "сумма без налогов", вводим спецификация накладной, цены - сначала цена производителя и оптовая надбавка/скидка (особенности белорусской локализации), цена и сумма без налогов при этом пересчитаются. Если итог не бьет - проверить ВСЮ накладную по столбцу "Всего с НДС" - сравнить бумажный вариант со спецификацией в СМ (столбец "Сумма"). Ежели нашли расхождение - то в этой строке (строках) ввести правильно сумму (как в бумажном варианте, остальное пересчитается, при этом обязательно проверить столбец "Сумма НДС", его значение при необходимости можно скорректировать вручную, не меняя значение процентной ставки НДС.
Правка по последней позиции нам не очень подходит - у нас же учет в розничных ценах. Можно попасть при наценивании на превышение максимальной надбавки (если она есть).
Корректировать неверно введенный приход потом, как мне кажется, достаточно накладно. У нас накладная - документ строгой отчетности, при вводе еще и реестр розничных цен формируется, и товарный отчет - суммы в СМ и в бумажной накладной должны совпадать. Е распечатанные акты переоценки, в которых присутствуют не только розничные цены, но и цены поставщика, расходные накладные в ценах поставки с проставленными основаниями и т.д. Т.е. корректировка прихода потом может повлечь за собой перепечатку большого количества документов.
Поэтому, на мой взгляд, следует проверку суммы оставлять в режиме "запрет" и добиваться идентичности сумм сразу при вводе. Иначе, особенно как у топикстартера - в рамках сети, - вносить изменения будет нне очень приятно.
P.S. Я понимаю, что сколько людей - столько мнений, и извиняюсь за, возможно, излишнюю категоричность, но очень уж много времени уходит при поиске ошибки в товарном отчете или в выгрузке, когда бухгалтер находит расхождение между суммой по пачке бумажных накладных и суммой,
которую получает в том же товарнике. Особенно когда начинает сверку с поставщиком делать.
P.P.S. Опять же - все, что человек может сделать неправильно - он неправильно и сделает. Проверка,
о которой идет речь, предназначена же не только вылавливать ошибки поставщиков - но и ошибки операторов.
20.03.2012 02:18
Обращаю внимание участников дискуссии на то, что топикстартер использует белорусскую локализацию Супермага. Алгоритмы калькулятора в накладных, в том числе округление, отличаются от российских.
Часовой пояс GMT +3, время: 10:42.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.