12.08.2002, 15:44 | #21 |
Шаман форума
|
Разграничение доступа на записи по фильтру - модуль RLP от Circle Capital, продается Навижн, есть в официальном прайсе (то есть, деньги давай )
Сторно - мне не попадались фирмы, где товарные операции анализировались по счетам бухучета. Это вопрос организации бизнес-процесса, если у вас это делает бухгалтер, и при этом всем хорошо, то и пусть себе.... Место кладовщика - теоретически бизнес-логика рассчитана на реализацию закупок/продаж с регистрацией на складе. Что в общем вполне правильно. Но на мелких фирмах и вправду может все делать один человек...Опять вопрос организации. Аксапта все стерпит |
|
13.08.2002, 15:11 | #22 |
Member
|
Цитата:
Изначально опубликовано komar
Разграничение доступа на записи по фильтру - модуль RLP от Circle Capital, продается Навижн, есть в официальном прайсе (то есть, деньги давай ) Цитата:
Изначально опубликовано komar
Сторно - мне не попадались фирмы, где товарные операции анализировались по счетам бухучета. Это вопрос организации бизнес-процесса, если у вас это делает бухгалтер, и при этом всем хорошо, то и пусть себе.... Цитата:
Изначально опубликовано komar
Место кладовщика - теоретически бизнес-логика рассчитана на реализацию закупок/продаж с регистрацией на складе. Что в общем вполне правильно. Цитата:
Изначально опубликовано komar
Но на мелких фирмах и вправду может все делать один человек...Опять вопрос организации. Аксапта все стерпит Глеб |
|
13.08.2002, 17:42 | #23 |
Шаман форума
|
Регистрация товара на складе вроде бы возможна и без лицензии на управление складом, через кнопу склад/регистрация в заказах. Мне кажется сие неудобным, и видится возможным следующий вариант бизнес-процесса - некто (может транспортный отдел или кто там еще) формирует список прихода (или как это теперь называется на англо-русском языке переводчиков Навижн), затем кладовщик формирует то, что теперь называется накладной, а в новой версии будет называться непонятно как, без формирования финансовой проводки, а далее бухгалтер по ТМЦ формирует то, что сейчас в стандартной версии именуется счет-фактурой, а будет, видимо, накладной, и счет-фактуру тоже делает. В таком процессе - место кладовщика находится в форме Заказы (можно поиграть правами доступа, чтобы чего не нужно не видел и не проводил) - это даже удобнее, чем регистрация/комплектация, которые и правда рассчитаны на расширенный склад. Аналогичный процесс можно соорудить и по отгрузке.
RLP - это официально признанное стандартное средство. Другого стандартного средства для разграничения доступа на уровне записей нет. Как работают на Западе, не видел. |
|
14.08.2002, 12:37 | #24 |
Участник
|
Цитата:
Изначально опубликовано glibs
А где, собственно, место кладовщика в системе Аксапта? Но на самом деле это слишком круто. Модуль управления складом не всем нужен. Работа кладовщика без этого модуля организуется непросто. Цитата:
Изначально опубликовано glibs
Должен ли он проводить накладные по приходам/отгрузкам в форме Закупки/Заказы? Цитата:
Изначально опубликовано glibs
И должен ли он вводить и разносить журналы складских проводок (наверное, ему для этого придется выучить план счетов, корреспонденцию и ряд других вещей)? Основная задача кладовщика проводить регистрацию и комплектацию. Это и есть первичные документы для бухгалтера. Но здесь проблема в том, что в станадртной версии эта функциональность развита только в модуле управление складом. Без этого модуля функциональность ограничена. Что есть без модуля управления складом: 1. Форма комплектации отгрузок (надо вставить эту форму в меню кладовщика) 2. Запрос всех складских проводок и регистрация и комплектация оттуда по каждой строчке (что утомительно) Вот как раз здесь я готов согласится, что нужна доработка. Нужно не расширять фукнциональность (ни в коем случае!), а предоставить более удобный интерфейс для существующей. Т.е. я обычно создаю форму в которой складские проводки группируются по TransRefID и кладовщик может зарегистрировать или скомплектовать весь документ одним нажатием кнопки. Становится удобно. Но еще раз повторюсь, что с модулем управлением складом, все становится на свои места. Там появляются еще и дополнительная складская функциональность. Цитата:
Изначально опубликовано glibs
Я лично себе этого не представляю. Мне кажется, что все эти действия должны делать бухгалтера (бухгалтер по материальному учету, бухгалтер отдела продаж или закупок – такое я встречал довольно часто) НА ОСНОВАНИИ ПЕРВИЧНЫХ ДОКУМЕНТОВ ОТ КЛАДОВЩИКА. По факту выполнения операции. Желательно сразу… До этого (в случае отгрузки, например) он их должен кладовщику выдать, как основание для отпускания чего-либо со склада в принципе. На основани первичных документов кладовщика (все правильно) Но эти первичныедокументы кладовщик должен вводить в систему сам, а не писать на бумажке. Тогда действительно все будет сразу Цитата:
Изначально опубликовано glibs
Вопрос вызван и тем, что я до сих пор не могу найти возможности организовать разграничение прав доступа на уровне складов. Выключаешь журнал складские проводки. Добавляешь в меню форму комплектации заказов. Если нужно, создай форму, которая позволяет регистрировать или комплектовать одной кнопкой. (если не хочешь, то покажи запрос по складским проводкам и найси пользоваться в этой форме кнопкой Склад) Цитата:
Изначально опубликовано glibs
Как ... обеспечить, чтобы кладовщики не лазили по чужим складам. Т.е.: 1. Сделай так, чтобы в параметрах журнала можно было бы давать склад по-умолчанию. 2. Сделай так, чтобы каждый кладовщик видел только свой журнал. 3. Установи косвенный доступ на LocationID в "Только для чтения" Есть две вещи которые делаются бесконечно, и которые можно программировать: 1. Безопасность и права доступа 2. Черно-белый учет Есть еще одна вещь, которую можно программировать. Но эта вещь конечна: 1. Удобство использования. |
|
14.08.2002, 14:42 | #25 |
Участник
|
Поправки
Полностью согласен с mazzy, хотелось бы поправить:
Цитата:
quote:
-------------------------------------------------------------------------------- Изначально опубликовано glibs Должен ли он проводить накладные по приходам/отгрузкам в форме Закупки/Заказы? -------------------------------------------------------------------------------- Ни в коем случае. Там цены и скидки. Но проблем будет действительно много: эти поля не в одной таблице, а целом веере (строки заказов, закупок, журналов и т.д.). Хотя технически проблема разрешима. Цитата:
Нужно не расширять фукнциональность (ни в коем случае!), а предоставить более удобный интерфейс для существующей.
Цитата:
В версии 2.5 обеспечить полный запрет сложно. (В следующей версии с помощью View). В 2.5 можно делать две вещи - либо фильтрация (делаешь сам, либо закупаешь модуль), либо создание пресетов и запрет на изменение склада.
|
|
14.08.2002, 15:52 | #26 |
Участник
|
Согласен.
Согласен и с тем, что программирование хорошо развито. Поэтому постоянно приходится бить себя по рукам. |
|
15.08.2002, 12:54 | #27 |
Member
|
Прежде всего, большое всем спасибо за отклики.
Цитата:
Изначально опубликовано mazzy
Неправильно.Эти действия должна делать СИСТЕМА! На основани первичных документов кладовщика (все правильно) Но эти первичныедокументы кладовщик должен вводить в систему сам, а не писать на бумажке. Тогда действительно все будет сразу Тут есть нюанс. Если у нас склад без ячеек, паллет, серийных номеров и партий, то привлекать к системе кладовщика особого смысла не вижу. Есть документ с подписями от кладовщика – он разносится бухгалтером без лишних телодвижений. В противном случае – нужно. Полностью согласен, что не бухгалтер в систему должен вводить складскую аналитику. При приходе – проще. Бумажки для прихода кладовщику передавать не нужно. А закупка уже должна быть введена. А так - то же самое. В остальном я со всем согласен. Вопрос вот в чем. Я видел рейтинг ERP систем ASA Power Ratings (http://www.accountingsoftwareadvisor...werratings.htm). Там бухгалтера США оценили логистику лучше, чем все остальные системы в рейтинге (всякие там SAP и компания). Значит это им нравится!? Так что же у них за технологии работы такие? Вдруг у них там хитрые и гениальные бизнес-процессы. Если знаете – поделитесь, пожалуйста, информацией. Глеб |
|
15.08.2002, 13:58 | #28 |
Участник
|
Цитата:
Изначально опубликовано glibs
Тут я либо не совсем понял, либо не согласен. Дело в том, что у нас (в смысле в Украине) отпуск чего-либо со склада возможен только при наличии накладной с подписями профильного менеджера и главного бухгалтера (и с точки зрения законодательства, и с позиций кладовщика). С другой стороны такая накладная делается на основании заказа (в общем случае). Заказ вводит менеджер. Формирует накладную предположительно он же. Несет (опять же, в общем случае) на подпись главбуху и потом отдает кладовщику. Кладовщик даже в станадртной версии видит форму с выписанными сборочными накладными. Кладовщик может подставить свое реальное количество сколько отпустил. Бух. не может провести сборочную накладную. Так как в реальности может быть отгружено меньше товара, чем написано в сборочной. Например: 1. вчера была инвентаризация. Обнаружили ящик пива 20 бутылок. 2. ввели в систему. Система знает, что в наличии 20 бутылок. 3. менеджер выписал 20 бутылок клиенту, создал сборочную накладную. 4. кладовщик начинает собирать заказ. И обнаруживает, что на складе есть только 19 бутылок. Разбилась, понимаешь. Он собирает 19 бутылок и вводит это количество в систему. 5. Менеджер получает информацию о том, что он заказывал 20, а собрали 19 и принимает решение о том, будет ли он предлагать клиенту меньшее количество или будет отменять заказ. Причем здесь бух? |
|
15.08.2002, 13:59 | #29 |
Участник
|
А, да, забыл.
Если менеджер решил продать меньшее количество и он договорился с клиентом, то менеджер выписывает СФ. Вот в этот момент система и делает бух.проводки. Опять же, причем здесь бух? |
|
15.08.2002, 14:05 | #30 |
Участник
|
И уж если продолжать дальше, то:
менеджер может договорится о меньшей поставке, тогда он уменьшает заказанное количество. Менеджер может оставить недостающее количество для последующей поставки. Тогда система будет держать заказ открытым. А кладовщик должен уведомить матответственное лицо (или начальника склада) о том, что "заказывают тут, понимаешь, а у нас нет". МОЛ (или начальник склада) должен инициирвать инвентаризацию. Если действительно обнаружилась недостача, то МОЛ (или начальник склада): а) вводит журнал инвентаризации, чтобы система знала, что товара меньше, б) начинает внутреннее расследование и принимает меры. Ну причем здесь бух? Это кстати, очень распространенное русско-СНГшное заблуждение - все операции вешать на буха. Бух не должен иметь столько прав. |
|
15.08.2002, 21:52 | #31 |
Member
|
1.
Цитата:
Изначально опубликовано mazzy
Ну причем здесь бух? Это кстати, очень распространенное русско-СНГшное заблуждение - все операции вешать на буха. Бух не должен иметь столько прав. Этот менеджер делает отфактуровку, если я все правильно понял. Значит он выполняет функции бухгалтера - делает проводки. Почему? Он выбирает профиль разноски, налоговые коды, может быть даже сопоставляет с предоплатой. В конце концов он выставляет финансовые аналитики. У нас этому менеджеру придется подготовить еще документы по налоговому учету. На практике я встречал 2 варианта. Один – когда все функции по продаже и оформлению документов выполняет один человек (менеджер), второй – когда 2: менеджер и бухгалтер. Не думаю, что корректным будет обсуждать какой из вариантов правильней (у каждого предприятия свои особенности, как технологические, так и кадровые). 2. Цитата:
Изначально опубликовано mazzy
менеджер может договорится о меньшей поставке, тогда он уменьшает заказанное количество. 3. Цитата:
Изначально опубликовано mazzy
Менеджер может оставить недостающее количество для последующей поставки. Тогда система будет держать заказ открытым. 4. Цитата:
Изначально опубликовано mazzy
А кладовщик должен уведомить матответственное лицо (или начальника склада) о том, что "заказывают тут, понимаешь, а у нас нет". МОЛ (или начальник склада) должен инициирвать инвентаризацию. Если действительно обнаружилась недостача, то МОЛ (или начальник склада): а) вводит журнал инвентаризации, чтобы система знала, что товара меньше, б) начинает внутреннее расследование и принимает меры. 5. Цитата:
Изначально опубликовано mazzy
Если менеджер решил продать меньшее количество и он договорился с клиентом, то менеджер выписывает СФ. Вот в этот момент система и делает бух.проводки. 6. Цитата:
Изначально опубликовано mazzy
Бух. не может провести сборочную накладную. Так как в реальности может быть отгружено меньше товара, чем написано в сборочной. 7. Цитата:
Изначально опубликовано mazzy
Например: 1. вчера была инвентаризация. Обнаружили ящик пива 20 бутылок. 2. ввели в систему. Система знает, что в наличии 20 бутылок. 3. менеджер выписал 20 бутылок клиенту, создал сборочную накладную. 4. кладовщик начинает собирать заказ. И обнаруживает, что на складе есть только 19 бутылок. Разбилась, понимаешь. Он собирает 19 бутылок и вводит это количество в систему. 5. Менеджер получает информацию о том, что он заказывал 20, а собрали 19 и принимает решение о том, будет ли он предлагать клиенту меньшее количество или будет отменять заказ. Причем здесь бух? А вообще согласен с вами. Постараюсь подытожить. Заказ готовит менеджер. Он же готовит накладную (без бумажки (документа) не обойтись). Потом кладовщик отпускает. И однозначно не он разносит на основании первичного документа. А если на складе есть аналитика, то кладовщик должен ее ввести в систему сам до того, как будет произведена разноска, т.к. тот, кто разносит, ее вводить не должен. В стандартной функциональности при несиспольщзовании управления складом места для кладовщика нет. Его нужно делать средствами разработки, но на уровне создания более удобных интерфейсов с минимум программирования, а не путем писания чего-то нового. Правильно? Спасибо за дискуссию. С уважением, Глеб |
|
16.08.2002, 14:03 | #32 |
Участник
|
1.
Цитата:
Изначально опубликовано glibs
Менеджер, бух – какая разница. Назовите его хоть паровозом. С бухом ты можешь говорить о 62, о 76, о 90 счетах. Бух тебе разложит по полочкам на какие бухгалтерские счета какие ДЕБИТОРЫ могут разносится, будет говорить о 64 или о субсчетах 62. Бух обязательно будет просить разложить реализацию по ставкам НДС. Бух обязательно отметит, что использование 64 счета надо бы минимизировать. Для буха очень важно какие продажи будут оплачиваться налом, а какие безналом. С менеджером ты можешь говорить о VIP-клиентах, о прочих клиентах, о категориях клиентов, об отсрочке платежа, о кредитной линии, о сроках доставки. Именно в менеджером можно обсуждать цветных клиентов (которые не попадают в бухгалтерию, кстати). Менеджер попросит тебя разложить реализацию по группам клиентов. Менеджеру, как правило, до фени все эти НДСы, НСП и прочая бухгалтерская «мутотень» Т.е. различие в подходе и в терминологии. Если ты обяжешь менеджера указывать бухгалтерский счет, то, скорее всего, у ТЕБЯ (а не у менеджера) будут проблемы. Если ты обяжешь бухгалтера указывать отсрочку платежа, то, скорее всего, он ничего не укажет. Если ты попросишь бухгалтера подготовить группы клиентов, то, скорее всего, по этим группам ты не сможешь управлять своими продажами. И т.п. Цитата:
Изначально опубликовано glibs
Этот менеджер делает отфактуровку, если я все правильно понял. Значит он выполняет функции бухгалтера - делает проводки. Почему? Он выбирает профиль разноски, налоговые коды, может быть даже сопоставляет с предоплатой. В конце концов он выставляет финансовые аналитики. Он создает счет-фактуру. Очень понятное действие для менеджера. Про проводку они ничего не знает. Он может только косвенно управлять проводками с помощью разноски. НИ В КОЕМ случае не давай группам разноски БУХГАЛТЕРСКИЕ имена!!! Разноски должны быть понятны менеджеру. Например, VIP, Физ.лица, Банки, Кредиты, Срочный. Т.е. такие названия, которые понятны для ваших менеджеров. А уж какие там проводки делает система – какая менеджеру разница. Мало того, я обычно закрываю у менеджеров и косвенный доступ к проводкам. Таким образом, менеджер делает привычное действие в привычных терминах. А уж задача системы, чтобы термины менеджера корректно отобразились в бухгалтерии. Насчет финансовых аналитик. Финансовые аналитики (ужасный перевод) – на самом деле изменения, которые видны во всех операциях во всей фирме. Вписывать в dimention бухгалтерские термины – огромная ошибка! На практике… Ты сам себе ответил. «когда все функции по продаже и оформлению документов выполняет один человек (менеджер)» Именно продажа, оформление документов. Ни больше, ни меньше! Бух.проводки не его дело. А тем более, налоговые проводки 2. Цитата:
Изначально опубликовано glibs
И переделает накладную. И предупредит кладовщика. А без накладной кладовщик все-равно ничего не отпустит - он же МОЛ. В Аксапте менеджер выпишет сборочную накладную, кладовщик увидит ее на своем рабочем месте. В твоей терминологии это «предупредит». Заметь, что в Аксапте не надо никуда звонить и ничего писать А затем менеджер печатает накладную и ОТДАЕТ ее КЛИЕНТУ. Клиент идет на склад. То, что у него есть документ с печатью, есть его авторизация. По этому документу кладовщик и отдает товар. Товар кладовщик уже собрал, когда получил сборочную накладную в системе. Заметим, что на накладной могут присутствовать хитрые штрих-коды и прочие элементы защиты. 3. Цитата:
Изначально опубликовано glibs
Если он разносит сам - то оставит. Иначе - предупредит бухгалтера. 4. Цитата:
Изначально опубликовано glibs
Не понял. Мне кажется, что если МОЛ или начальник склада будет иметь возможность списывать в системе недостающий товар, то это будет противоречить принципу двупроходности. Я говорил – инвентаризацию. Ты говоришь списание. Списание должно идти с подтверждением. За инвентаризацию отвечает только склад. Это его зона ответственности. Да в системе списание и инвентаризация приводит к похожим следствиям. Но заметь, что на списание и инвентаризацию можно и нужно поставить разные права. Все-таки за остатки отвечает склад. В случае недостачи количество на складе должен выровнять склад. Комиссия, подписи, акт. Но бухгалтерия тут совершенно не при чем (как и в случае с менеджером). А вот уже система сама должна корректно отобразить действия кладовщика в бухгалтерию. А ты должен настроить это отображение. 5. Цитата:
Изначально опубликовано glibs
Кто бы ни делал проводки: менеджер или бухгалтерия – они должны их делать на основании первичных документов. ... В данном случае речь идет о накладной, в которой проставлено фактически отпущенное количество ... и стоит подпись уполномоченного на получение ТМЦ представителя/сотрудника компании заказчика, подтверждающая то, что ТМЦ были им получены, а не кладовщик их куда-то дел. А с накладной… подумай еще раз. В Аксапте реализован неплохой документооборот, который затрагивает и менеджеров, и склад, и бухгалтерию. Посмотри, почитай документацию 6. Цитата:
Изначально опубликовано glibs
Так он должен проводить ту накладную, в которой стоит реально отпущенное количество и подпись получателя, подтверждающая фактически полученное количество. 7. Цитата:
Изначально опубликовано glibs
Ну, ничего себе! Я так понимаю, что Axapta соберет 20 бутылок. Она ведь еще не знает, что бутылка разбилась. А вот кладовщик – 19. И пока в систему не попадет информация о том, что одна бутылка списана по какой-то там причине (а вдруг он ее выпил на радостях, а разбитая бутылка уже была пустая – как в известной кинокомедии), менеджер о нехватке товара на складе не узнает (от системы). А вот если кладовщик предупредит менеджера – то можно и уменьшить. Но получиться это может только устно. Хотя… это тоже не метод. И ЕЩЕ РАЗ! Никто никого не предупреждает! Никто никому не звонит! Каждый на своем рабочем месте просто вносит данные, на которые имеют право. Каждый на своем рабочем месте смотрит информацию, которую предоставили другие. Реальный отпуск/прибытие товара может авторизироваться бумажными документами. Все необходимое для этого в Аксапте есть. В чем совершенно согласен, так это с тем, что система ничего ни о чем не знает, пока в нее кто-то не введет информацию. Вопрос в том кто? И когда? Цитата:
Изначально опубликовано glibs
А вообще согласен с вами. Цитата:
Изначально опубликовано glibs
В стандартной функциональности при несиспольщзовании управления складом места для кладовщика нет. Его нужно делать средствами разработки, но на уровне создания более удобных интерфейсов с минимум программирования, а не путем писания чего-то нового. Правильно? Если у тебя кладовщики будут требовать, чтобы система позволила им обрабатывать любые документы целиком, а не построчно, то тогда в стандартной функциональности без модуля управление складом надо добавлять форму. Спасибо за интересное обсуждение. |
|
21.08.2002, 21:20 | #33 |
Member
|
Уф! Добрался до любимого форума.
Цитата:
Изначально опубликовано mazzy
сторно по складу есть. приход-расход с отрицательным знаком. Вводится в заказах и закупках как возвраты. Я тут немного учил нашего менеджера, и вот что получилось. Нужно было сделать расход со склада всякой разной номенклатуры. В общем, пока я сбегал к своему компьютеру посмотреть, не пришла ли почта и просто поклацать по клавиатуре, менеджер в журнале складских проводок ввел номенклатуры, складские аналитики и все остальное и успел журнал разнести. Физическую себестоимость не указал (получилось - 0), так как для расхода велено было не указывать, т.к. отпускается по средней мгновенной. А вот количество указал с положительным знаком – в общем получился приход, причем даже не безоплатно полученных товаров, а непонятно каких. Обязательная комплектация была отключена и ошибка была выявлена только после разноски журнала и просмотра проводок. Проводок по ГК не было. Я сказал: «Ерунда, сейчас спишем назад». И призадумался. Если бы был расход, то можно было бы сделать приход по той же себестоимости. Правда, бухгалтерские проводки в таком случае сторном не пойдут. В Закупках/Заказах сторно вроде уже стало возможным организовать (по ГК). А тут вроде нет. Или я что-то где-то не дочитал? Но в данном примере приход. А если я буду делать расход, то эти номенклатуры у меня спишутся по средней мгновенной себестоимости (в общем, по другой). Так что это уже не сторно. В моем конкретном случае по приходу бухгалтерских проводок не было, а по расходу будут. Что скажете? Я понимаю, что ситуация не совсем реальная, хотя с другой стороны не ошибается только тот, кто ничего не делает. И если бы была обязательная комплектация/регистрация, то такое случайно было бы сделать очень сложно. Тем не менее, такая ситуация в системе исправима? Или все очень просто, а у меня просто "крыша едет" (поздно уже)? Я ушел от последней темы, но дискуссию я не забросил. Может, даже сегодня успею что-то написать. Хотя... наверное, уже завтра. Глеб |
|
22.08.2002, 12:08 | #34 |
Участник
|
Цитата:
Изначально опубликовано glibs
...получился приход, причем даже не безоплатно полученных товаров, а непонятно каких... Шел менеджер по складу- обнаружил неучтенный товар. Решил занести в систему... На форуме бухгалтеров как то спрашивали как провести 3 тонны цветного лома, которые нашли в цехе... Т.е. тебя интересует возврат не столько количества, сколько себестоимости. Первое, что приходит в голову - почему кладовщик должен заниматься себестоимостью? Вроде он знать ее не должен... Надо подумать. |
|
22.08.2002, 17:00 | #35 |
Member
|
Цитата:
Изначально опубликовано mazzy
Физическая интерпретация очень даже прозрачна. Шел менеджер по складу- обнаружил неучтенный товар. Решил занести в систему... На форуме бухгалтеров как то спрашивали как провести 3 тонны цветного лома, которые нашли в цехе... Если у вас учет белый, и вы на складе нашли что-то неучтенное, то это излишки. Думаю, что оформляется актом инвентаризации. У нас это сопровождается приходованием запасов/товаров на соответствующий бухгалтерский счет по дебету в корреспонденции со счетом доходов/прибылей. В налоговом учете это увеличит базу налогообложения. Цитата:
Изначально опубликовано mazzy
Т.е. тебя интересует возврат не столько количества, сколько себестоимости. Цитата:
Изначально опубликовано mazzy
Первое, что приходит в голову - почему кладовщик должен заниматься себестоимостью? Вроде он знать ее не должен... Надо подумать. |
|
22.08.2002, 20:02 | #36 |
Шаман форума
|
должен-не должен
Кладовщик может, и не должен, а вот система должна. Иначе какая она на фиг интегрированная. Мы как-то плавно скатились в вопросы организации труда кладовщика, а сторно по складу к этой проблеме отношения не имеет.
|
|
22.08.2002, 22:13 | #37 |
Member
|
Re: должен-не должен
Цитата:
Изначально опубликовано komar
Кладовщик может, и не должен, а вот система должна. Иначе какая она на фиг интегрированная. Мы как-то плавно скатились в вопросы организации труда кладовщика, а сторно по складу к этой проблеме отношения не имеет. Если вы позволите, я все-таки продолжу данную дискуссию. Заранее прошу прощения, что вторгся в вашу тему. Мелочи. Цитата:
Изначально опубликовано mazzy
Ой... Я приношу извинения. А можно на ты? Цитата:
Изначально опубликовано mazzy
Спасибо за интересное обсуждение. Цитата:
Изначально опубликовано mazzy
1. Разница офигительная! С бухом ты можешь говорить о 62, о 76, о 90 счетах. Бух тебе разложит по полочкам на какие бухгалтерские счета какие ДЕБИТОРЫ могут разносится, будет говорить о 64 или о субсчетах 62. Бух обязательно будет просить разложить реализацию по ставкам НДС. Бух обязательно отметит, что использование 64 счета надо бы минимизировать. Для буха очень важно какие продажи будут оплачиваться налом, а какие безналом. С менеджером ты можешь говорить о VIP-клиентах, о прочих клиентах, о категориях клиентов, об отсрочке платежа, о кредитной линии, о сроках доставки. Именно в менеджером можно обсуждать цветных клиентов (которые не попадают в бухгалтерию, кстати). Менеджер попросит тебя разложить реализацию по группам клиентов. Менеджеру, как правило, до фени все эти НДСы, НСП и прочая бухгалтерская «мутотень» Такими параметрами являются: - профиль разноски, - налоговая группа, - налоговая группа номенклатуры, - признак включения налога в цену, - в некоторых случаях счет разноски. Эти параметры определяют: - на какой бухгалтерский счет пойдет проводка по приходу или что будет списываться по бухгалтерии (является ли покупаемая/продаваемая номенклатура ОС, запасом, полуфабрикатом, МБП, товаром – это все разные бухгалтерские счета). - какие налоги будут начислены. У нас это целая песня – налоги зависят от того, связаны ли закупаемые товары с хозяйственной деятельностью, амортизируются они или нет (ОС – не ОС), используются ли эти товары для производства облагаемой НДС продукции или нет – право на возмещение НДС (а они могут использоваться и для той и для другой). По бартеру, комиссии, «связанным лицам», взаимозачетам отдельные схемы. - на какие счета проведется реализация/себестоимость реализации (это зависит от того, где в бухучете числится/будет числиться номенклатура - ОС, запас, полуфабрикат, МБП, товар). А еще есть накладные расходы (с учетом того, что в текущей версии Axapta они реализованы специфически) – в т.ч. и импортно/экспортные налоги. Я с вами согласен, что менеджер все это знать не должен. Но, если он будет разносить (отфактуровывать) закупку/заказ, все параметры должны быть корректно им выставлены. Теоретически, этого можно достичь при очень многих «если». Например, менеджер продает только товары определенной категории клиентов по одной-двум формам оплаты (оплата-предоплата). Тогда ему можно сделать инструкцию, мол, при сделке на таких условиях проставляешь такие параметры, при таких – другие. И пусть работает как мартышка. Но такого далеко не всегда можно достичь. Другой вариант – менеджер продает: вносит номенклатуру, условия сделки (сроки оплаты, скидки, прочее всякое разное), а другой менеджер (я его привык называть бухгалтером) разносит, предварительно изучив все условия и корректно определив налоги. Он же и налоговые документы выпишет (у нас это буквально еще одна накладная - налоговая - не имеющая никакого отношения к складу). Им даже можно доступ разграничить на уровне полей. Есть еще один момент. Пользователем системы является и Финансовый Директор. И он заинтересован в корректной простановке аналитик и формировании реальной себестоимости запасов путем корректного распределения накладных расходов. Это тоже нужно обеспечить, возможно, привлекая экономические службы (не к разноске, а к определению dimensionsи схемы распределения накладных расходов). Конечно, как правило, они будут корректно проставляться автоматически. Тем не менее, возможны варианты. Цитата:
Изначально опубликовано mazzy
Насчет финансовых аналитик. Финансовые аналитики (ужасный перевод) – на самом деле изменения, которые видны во всех операциях во всей фирме. Вписывать в dimention бухгалтерские термины – огромная ошибка! 2. Цитата:
Изначально опубликовано mazzy
А система автоматизации зачем? В Аксапте менеджер выпишет сборочную накладную, кладовщик увидит ее на своем рабочем месте. В твоей терминологии это «предупредит». Заметь, что в Аксапте не надо никуда звонить и ничего писать 3. Цитата:
Изначально опубликовано mazzy
А затем менеджер печатает накладную и ОТДАЕТ ее КЛИЕНТУ. Клиент идет на склад. То, что у него есть документ с печатью, есть его авторизация. По этому документу кладовщик и отдает товар. Товар кладовщик уже собрал, когда получил сборочную накладную в системе. Заметим, что на накладной могут присутствовать хитрые штрих-коды и прочие элементы защиты. 4. Цитата:
Изначально опубликовано mazzy
Оп! Заметь разницу в терминологии! Я говорил – инвентаризацию. Ты говоришь списание. Списание должно идти с подтверждением. За инвентаризацию отвечает только склад. Это его зона ответственности. Да в системе списание и инвентаризация приводит к похожим следствиям. Но заметь, что на списание и инвентаризацию можно и нужно поставить разные права. Все-таки за остатки отвечает склад. А вот с Журналом складских проводок проблема. Предположим, если нужно организовать передачу на филиал. Думаю, проблема элементарно решалась бы, если бы там был механизм подтверждения, как в журналах ГК: кладовщик вводит - бухгалтер подтверждает. Глеб |
|
23.08.2002, 12:57 | #38 |
Участник
|
Re: должен-не должен
Цитата:
Изначально опубликовано komar
Кладовщик может, и не должен, а вот система должна. Иначе какая она на фиг интегрированная. Расскажи. А то ты становишся похож на некоторых авторов этого форума. Gilbs, еще раз спасибо за вопрос. Чтобы Аксапта могла связать лоты и корректно проставить себестоимость по возврату, в складских журналах нужно указать номер возвращаемого лота. Тогда приход будет восприниматься как возврат и себестоимость будет взята из возвращаемого лота. |
|
23.08.2002, 13:21 | #39 |
Участник
|
Цитата:
Изначально опубликовано glibs
Это вам спасибо. Вы помогли мне во многом разобраться. Цитата:
Изначально опубликовано glibs
хотя, в заказах есть счет разноски реализации, а в закупках – счет прихода, и их использование может быть оправданным для некоторых операций А вот в приходах может некоторым и стоит оставить. Но только закрывай план счетов. Оставь опытным закупщикам только те счета, которые могут использоваться в закупках.И ничего больше. Цитата:
Изначально опубликовано glibs
Счета подставляются на основании параметров разноски. И если он что-то не так проставит в параметрах, он сделает неправильные проводки. А у тебя есть такая функция как validateWrite Потребуй от своих создать систему проверок (или сам создай) и запрограммируй эту систему проверок в Аксапте Научи Аксапту думать немножко перед записью Цитата:
Изначально опубликовано glibs
какие налоги будут начислены. У нас это целая песня – налоги зависят от того, связаны ли закупаемые товары с хозяйственной деятельностью, амортизируются они или нет (ОС – не ОС), используются ли эти товары для производства облагаемой НДС продукции или нет – право на возмещение НДС (а они могут использоваться и для той и для другой). По бартеру, комиссии, «связанным лицам», взаимозачетам отдельные схемы. Но он должен знать некоторые понятные ему интегральные характеристики. Эти интегральные характеристики и должны присуствовать в группах. А уж твоя задача обеспечить, чтобы эти интегральные характеристики всегда отвечали некоторым условиям проверки. Цитата:
Изначально опубликовано glibs
на какие счета проведется реализация/себестоимость реализации (это зависит от того, где в бухучете числится/будет числиться номенклатура - ОС, запас, полуфабрикат, МБП, товар). Неправда! То как проводится та или иная операция зависит прежде всего от характера САМОЙ операции. От ее параметров! В том числе, и "где в бухучете числится/будет числиться номенклатура" прежде всего зависит от параметров самой номенклатуры. Т.е. выдели эти характерные параметры. Проверь, что эти характерные параметры понятны менеджеру. Спрячь непонятные ему. Агрегируй несколько непонятных в один понятный. И т.п. В этом то как раз и состоит работа по внедрению. Цитата:
Изначально опубликовано glibs
...если он будет разносить (отфактуровывать) закупку/заказ, все параметры должны быть корректно им выставлены. Он должен проставить только те параметры, которые знает и за которые может отвечать. ВСЕ параметры проставить никто не сможет Цитата:
Изначально опубликовано glibs
Теоретически, этого можно достичь при очень многих «если». Например, менеджер продает только товары определенной категории клиентов по одной-двум формам оплаты (оплата-предоплата). Тогда ему можно сделать инструкцию, мол, при сделке на таких условиях проставляешь такие параметры, при таких – другие. И пусть работает как мартышка. Но такого далеко не всегда можно достичь. Но именно мартышка. Именно инструкции. А твоя задача, чтобы система обеспечивала исполнение инструкций. Тогда ты достигаешь еще одного эффекта. Вместо суперпрофессионала тебе будет достаточно обычного человека на рабочем месте (может быть даже менее обученного, но более дешевого) Цитата:
Изначально опубликовано glibs
Другой вариант – менеджер продает: вносит номенклатуру, условия сделки (сроки оплаты, скидки, прочее всякое разное), а другой менеджер (я его привык называть бухгалтером) разносит, предварительно изучив все условия и корректно определив налоги. Он же и налоговые документы выпишет (у нас это буквально еще одна накладная - налоговая - не имеющая никакого отношения к складу). Им даже можно доступ разграничить на уровне полей. Самое главное условие - каждый должен отвечать за свои параметры. Из этого условия выводится следствие - каждый должен вводить только те параметры, за которые может отвечать. Не больше. Но и не меньше Цитата:
Изначально опубликовано glibs
И их менеджер по складу может себе позволить отпустить товар на основании того, что в системе есть отгрузочная накладная. Собрать заказ он может на основании данных системы. Отпустить только на основании бумажки. Именно так в Аксапте и реализовано. Цитата:
Изначально опубликовано glibs
у них packing list и packing slip являются документами в нашем понимании этого термина? Цитата:
Изначально опубликовано glibs
Но вариант поступления накладной кладовщику от менеджера тоже возможен. При этом товар действительно может быть скомплектован раньше. Но не отгружен. Цитата:
Изначально опубликовано glibs
Насколько я понимаю, при разноске инвентаризации товар списывается со склада и с бухучета одновременно. Хотя вы правы – это может сделать начальник склада или кто-то в этом роде, т.к. в журнале инвентаризации корсчет фиксированный. Но при этом должен быть еще один человек, который будет мониторить обороты по этому счету и выяснять причину списания, и сносить это на затраты или организовывать возмещение с МОЛа. Иначе они туда весь склад спишут. Цитата:
Изначально опубликовано glibs
А вот с Журналом складских проводок проблема. Предположим, если нужно организовать передачу на филиал. Думаю, проблема элементарно решалась бы, если бы там был механизм подтверждения, как в журналах ГК: кладовщик вводит - бухгалтер подтверждает. |
|
23.08.2002, 16:38 | #40 |
Member
|
Re: Re: должен-не должен
Цитата:
Изначально опубликовано mazzy
Gilbs, еще раз спасибо за вопрос. Цитата:
Изначально опубликовано mazzy
Чтобы Аксапта могла связать лоты и корректно проставить себестоимость по возврату, в складских журналах нужно указать номер возвращаемого лота. Тогда приход будет восприниматься как возврат и себестоимость будет взята из возвращаемого лота. Расходы и кредит-ноты по Закупкам списываются только по средней себестоимости (в расходах по складу номер лота указать нельзя). Как и было в моем случае. У меня есть подозрение, что сделано это неспроста и неслучайно. Интересно, для чего?! По данному поводу раньше уже где-то было на форуме. Только тогда на эту проблему с данной точки зрения никто не обратил внимания. А за предыдущую дискуссию большое спасибо. Глеб |
|
Теги |
как правильно, коррекция, накладная, сторно, удаление, crm2011 |
|
Похожие темы | ||||
Тема | Ответов | |||
Сторно ввода в эксплуатацию ОС | 16 | |||
Обработка входящего НДС | 12 | |||
Висит обработка фактуры | 12 | |||
Суммарная обработка накладной | 1 | |||
Корректная обработка НДС по счёту со скидкой по оплате | 1 |
|