Pull to refresh

Comments 31

Само по себе существование отрицательных остатков в 1С говорит о многом об этой «системе учета».
ЕМНИП, это уже лет 20-ть как настраиваемая опция. И наличие отрицательных остатков говорит не об 1С, а об уровне учета в компании. Но тут есть моменты:
1. В маленьких компаниях выключение этой опции потому что мешает продавать это 99,99% признак бардака в системе
2. В больших компаниях проверка на отрицательные остатки обычно не нужна — т.к. «низовой» бардак уже переросли, и в основном это уже «временные» моменты по передвижке остатков по складам/юрлицам компании. Но как граничный «железный» семафор обычно оставляют, ну тут опять же если проверка не ухудшает производительность.
Отрицательные остатки в 1С не опция, если вы создавали решения с нуля, знали бы.
я создавал. И у нас это тоже опция. В чем проблема?
Если вы про техническую реализацию, то да платформенно в регистрах остатков знак остатка не ограничивается, но платформа это еще не система учета, а регистр накопления еще не регистр с остатками товара.

А вот уже создавая РН ОстаткиТоваров разработчик решает, допускаются ли в этом регистре отрицательные остатки.

В типовых решениях от 1С еще в ТиСк ред.8 контроль отрицательных остатков был опцией.
Учитывая то, что 1С так старалась сделать за нас регистры накопления, можно было бы изящно реализовать это средствами платформы, не говоря об изменениях задним числом, это одни из главных причин того, что на западе 1С никогда не займет хоть какую-нибудь значимую долю рынка ERP.
Хотя кому я это говорю, в России же все прокатит, это же 1С.
Вы вообще понимаете о чем вы пишите? Я надеюсь вы просто кидаете на вентилятор.
Ну я делаю проекты на западе, есть прокты сумарно в 12 разных странах. И там везде люди просто офигивают от возможностей 1С.
Это первое, а второе — жесткий запрет изменения задчим числом — бред. Так как это иногда надо, но оно должно быть контролируемо. И тут вам в помощь блокчейн. И задача решается просто и элегантно, и даже круче чем в этих сапах, ораклах и так далее.
Да я прекрасно понимаю о чем пишу.
В 12 странах говорите, это из СНГ? Я вот только вчера обходил всех партнеров 1С зарубежем, половина сайтов не работает, другая половина просто российские или украинские компании.
Пополам и СНГ и не СНГ.
От того что компания имеет офисы в разных странах — разве плохо?
Вы опять похоже не понимаете о чем говорите. Не там ищите, раз не находите.
Ну значит мы работали с разными 1С на разных международных клиентов, бывает. Удачи вам.
не говоря об изменениях задним числом, это одни из главных причин того, что на западе 1С никогда не займет хоть какую-нибудь значимую долю рынка ERP.

изменения задним числом — на западе это чисто административное требование МСФО, есть конфигурации в 1С где задним числом нельзя ничего исправлять без следов
вы несколько путаете причины, следствия и сами решения

вот из опыта — однажды менеджеры по ошибке грузанули в учетную систему пару миллионов проводок с ошибками (просто выбрав неверный файл)… откат его штатными средствами вызвал бы пару миллионов сторнирующих проводок и пару талмудов объяснительных записок для аудиторов на каждую из них.
Думаете это нормальное решение для бизнеса делать совершенно невозможными операции редактирования задним числом? даже по коррекции технических ошибок?

вы так удивляетесь такому кривому 1С, хотя блин взять какуюнить систему Visa или MC
я видел на базе их кода такие конструкции по проведению проводок (в их учетных системах)
типа
update account set amount=0 where acc_id=100
update account set amount=10 where acc_id=110
эти операции идут подряд, и выполняют логику переноса суммы в 10 единиц со счета 100 на счет 110, они идут НЕ в транзакции!!! тоесть если операция падает посередине — бабло просто пропадает, до момента свода баланса за неделю/месяц/когда клиент очнется
Это считается НОРМОЙ, и эта логика существует не первый десяток лет. и в том числе по этому банковские операции идут от 5 до 30 дней. чтобы потом по общим цифрам менеджеры вручную сводили баланс если видят расхождения. (замечали иногда что некоторые суммы в выписке банка подвисают на мноого дней… и висят в холде? (в некоторых клиентбанках там часики около цифры нарисованы) это в том числе по таким вот причинам происходит)

Логика 'у них там на западе всё круто, а у нас сплошная ерунда просто по определению' — она неверная, и там есть странные и кривые решения, и у наших решений есть понятные объяснения 'почему так'
«В лоб» отрицательные остатки закрываются парой вполне изящных запросов. Ну и платформенный механизм был бы совсем не юзер-френдли, т.к. по идее он должен тупо выбрасывать исключение.

Редактирование «задним числом» тоже легко можно запретить, буквально парой строчек кода. Но в текущей парадигме типовых конфигураций да, никак. Хотя элементы этого подхода в торговой подсистеме есть (корректировки заказов например).

Навскидку, я не видел учетных конфигураций в которых редактирование «задним числом» было бы закрыто для всех и всегда. Значит не сильно оно востребовано бизнесом. Те же корректировки заказов используют только для контроля работы младшего, линейного персонала.
Вы не согласны с тем, что отрицательное число — это тоже число, не лучше и не хуже положительного?
Встречал как-то комплексный остаток (удивительно хорошо подходит название ещё и потому, что complex с английского переводится как сложный). Вещественная часть остатка была положительной и большой. А вот мнимая, ортогональная часть, никак не способствовала успешной продаже товара. В данном случае это был неверно сформированный штрихкод, который отказывались сканировать сканеры на кассе. Товар — леденцы-драже — обитал с момента завоза на прикассовой зоне, и скучающие в случае очереди покупатели нередко клали его в корзину. Когда выяснялось, что товар не бьётся так же легко расставались. В итоге выяснилось, что ни одной упаковки драже так и не было продано, а по истечении срока реализации все пакетики были собраны и возвращены поставщику, за исключением повреждённых и утерянных.

А вообще закрывать обои гвоздями кмк уже все давно привыкли.
Тут всеже стоит разграничивать понятия. Мне интересно — как автор в минус продаст что то, с учетом современных маркировок.
Простой кейс — была обувь размер 35 и 36, пробили 36, а покупатель забрал 35. Ну бывает.
Теперь пришел другой, и забирает 36. Программа говорит — нифига.
Ваши действия? В минус? Ну ну.

И я так понимаю — что Вы вообще без понятия, как и что делается в той же 1С. И это, класическая детская болезнь людей, которые считают себя мега автоматизаторами.
Давайте еще поговорим про растаможку, когда вы продадите больше, чем купили, так как поставщик вам сделал пересорт. И теперь к вам налоговая прийдет на кофе.

Простите, но статья уровня мамкиных автоматизаторов.
Или так и говорите — что вы берете остатки склада, с учетом остатков организаций, и вы хотите отпускать в минус только складские остатки. Ну так тут не проблема вообще — это много где используется. А вот остатки организаций в минус — ну, я сочувствую вашим клиентам.
С растаможкой да, если еще излишки всяких там товаров народного потребления можно распихать между сотрудниками и знакомыми, то с коммерческим товаром для юрлиц отдельное веселье.
Выбрал покупатель в торговом зале колечко с алмазами за 1 млн. Подходит на кассу, а там по учетной системе нет на остатках и вы ему: «приходите через пару дней, когда отдел товарного учета разберется». И покупателя потеряли, и 1 млн, и репутация понизилась…

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

И че? Ювилирка обычно продается вообще в индивидуальных позициях, акромя конечно ширпотреба. Так как одна и та же модель, может иметь разный вес камня или металла, что существенно влияет на цену. Плюс сертификаты и прочая лабудень. Так что вы выбрали ну вообще не разумный вариант.
Ну пусть будет ТВ тысяч за 200. Вот он стоит. Покупатель хочет купить, а на остатках нет, т.к. менеджер забыл оприходовать, или не тот артикул оприходовал. Очень часто бывает, что менеджер по учету склада забывает на перемещение сделать приходный ордер.
Товар же в рознице должен быть продан здесь и сейчас. Представьте, что вы набрав тележку продуктов подъехали на кассу, а там вам половину не пробили, т.к. «не на остатках». Например в ПО SetRetail не было учета по остаткам несколько лет назад (на тот момент, когда мы внедряли).
В случае же заказа через интернет-магазин покупателю приходит оповещение «ваш заказ готов». Оно приходит после того, как менеджер интернет-магазина проверил наличие, сотрудники магазина отложили в сторонку (наклеили стикер «продано»).
вы какой то не пробиваемый. Но по тихоньку идете в нужном направлении.
А теперь давайте выяснять — какой остаток мы контролируем?
Есть остатки партий, организаций, складов, серий и т.д. Что мы контролируем?
И вот когда вы ответите на эти вопросы — вы поймете, почему именно столько регистров в 1С, почему они так скомбинированы, почему у них разные разрезы.
Поэтому, вся эта статья, и ваши попытки что-то рассказать — не актуальны лет так 10, и 1С для решения этих кейсов сделала специальные механизмы.

Поучавствуйте в каких то реальных проектах, где ведется нормальный учет остатков товара на складе, тогда я думаю к вам прийдет понимание.
Какая разница, что вы будете контролировать: остатки на складах, партии или товары организаций если менеджер забыл сделать приход? Ни каких остатков не будет, ни тех, ни других. Нет операции прихода. А товар на полке есть и покупатель хочет его купить.

Насчет товаров организации и партий. Товар принадлежит одному владельцу, а продает другая организация. Перепродажи (интеркомпани) делаются уже после продажи конечному покупателю. Т.е. товар продается в минус по организации, по партиям вообще проводка не делается (УТ 10, УПП 1.3). Ну а по остаткам на складах, как я выше написал, просто забыли оприходовать.

Я говорю про то, что контролировать минусовые остатки в массовой рознице не нужно. Особенно поточной, когда на каждую кассу очередь по несколько человек.

Для мелких магазинов (организаций) нужен контроль. У них нет отдельного отдела товарного учета из 10-15 человек которые оперативно ежедневно выявляют минуса, пересорты и т.п. и исправляют
Отлично. Вот мы и пришли к выводу, что есть места где нужен, есть места где не нужен.
Вот как бы и все. Что противоречит данной статье, которая утверждает, что он не нужен нигде.
Так что, я согласен, что в H&M, например, делать контроль остатков — бред, а в сувенирной лавке, где дорой и чаще всего эксклюзивный товар — просто обязан быть контроль. Есть риски как в одну так и в другую сторону. И выбирают включать контроль или нет — основываясь на рисках, вот как бы и все.
Просто здравый смысл. А не то что тут в статье написано.
Если количество равно 1, тогда контроль отрицательных остатков становится почти безвредным.
Но вы тут, как и многие другие, путаете контроль отрицательных остатков и резервирование
Сколько текста из за пустяка))
1. В адекватных современных продуктах контроль остаткав оперативной части учета есть возможность отключить.
2.Если бизнес заявляет, что виртуальные минуса и излишки недопустимы, и отключать ничего нельзя — то добро пожаловать нанимать оператора, который оперативно ищет ошибки в прошлом периоде. И да, оперативно, это уже после факта продажи, но в течении текущей смены. И есть программы которые так умеют.
3.План/факт никогда и нигде не будет сходиться. Все что имеет ценность имеет свойство теряться/ломаться/забываться/переставляться. Даже золотовалютные резервы.
Но степенью хаоса можно управлять.Все упирается в: (см пункт 2)
А если в течение текущей смены найти не удалось?
Если случай тяжелый и запутанный, то оператор передает проблему уровнем выше. Там уже принимают решение, что делать, и держат ситуацию на контроле.

Тут отдельный тонкий момент, что отрицательные остатки не дают корректно посчитать себестоимость и прибыль с продажи. С учетом того, что норма прибыли неуклонно снижается, то каждый такой минусовой остаток может, в свою очередь, сделать отрицательной прибыль от продаж данного товара в контролируемом периоде. Что уже совсем не айс, согласитесь.
Для абсолютного большинства компаний расчет прибыли нужен раз в квартал
Для торговых компаний нужна оперативная прибыль. То что будет докидываться раз в месяц/квартал отдел продаж не интересует — им надо генерировать прибыль каждый день, и ниже определенного порога прибыльности продаж им падать нельзя. Чистая прибыль для налогов, владельцев раз в квартал, да, оперативная же — максимум неделя. Суровый быт оптовиков с тысячами номенклатурных позиций.
Много лет в разных местах слышу от руководства «гениальное» решение — просто запретить продажу в минус)

Т.е. все-таки не разработчики виноваты? Я сам тоже склонен так думать

Да никто не виноват, разработчики дали возможность запретить и достаточно. А каждый бизнес уже сам должен разбираться со своими процессами, как эти огрехи складского учета отслеживать и корректировать.
Sign up to leave a comment.

Articles