Приходится им по работе править накладные задним числом - приходы и расходы. В результате УТ 10.3 выдаёт ошибку "не распределилось по партиям..." но документы то проводятся! и у них минуса в отчетах постоянно и как следствия оприходования и списания - бухгалтер вешается. С нового года хотим положить конец беспорядку. свернули базу. сейчас инвентаризацию сделаем. а как дальше быть? Я видал на всем известном ресурсе подсистему для контроля остатков но она с ограничениями. Может самому чтото можно сделать, подскажите пути решения? я пока хочу при проведении документов включить проверку на момент проведения документа остатков и не проводить документ в случае если остаток недостаточен. Но этож чтож получается, в модуль документа лезть придется, типовую менять в документах перемещения и реализации. ну и перепроведение базы делать раз в неделю и драть их за появление минусов

дык, может каким-то пользователям просто запретить проводить неоперативно?

(1)а нельзя. Они ведь манагеры. если ошибку в документе, неправильное количество поставили, то хочешь-нихочешь, приходится править. И бывает ведь накладные заранее делаются при получении по электронке, а по факту пришел не весь товар, опять приходится править. Только после этого надо перепроводить всё а они не делают того.

(2) напиши проверку остатков при неоперативом проведении

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

(0) Наказывать телесно.

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

Мы решили эту проблему 2,5 года назад еще на 7.7 запретив всем перепроводить документы задним числом. Хотя и пользователей постоянно 20-30 человек. По началу были не довольны, но со временем успокоились.
На данным момент перепровожу сам документы. Задним числом бывает очень редко, пару раз за месяц. Если касячут текущим днем, тупо снимаем с проводки, переделывают сами заново.
P/S/ В день создается примерно 250-300 документов.

(5) хороший вариант =)

Отказаться от партионного учета. Юзать РАУЗ, среднее

Ха. извечная проблема на которую нет каких то общих вариантов решений.

(7) Т.е. ты за юзверей вносишь изменения задним числом?

(7) ну ты веселый. у нас 2000 заявок в день. и номенклатуры по 200 строк бывает. саморезы. недогруз, перегруз. не то в доке и т.д. и т.п. рекламации. клиенты требуют исправлять доки. и хоть тресни.

(11) поскольку это бывает пару раз в месяц, делаю сам вместе с юзером

и те кто набивают нипричем. и склад тоже. получили коробку с саморезами. отгрузили. клиент у себя открыл - а там брак или недофасованный ящик. все это узнается только после того как конечный клиент уже будет коробку открывать.

(13) ну так с такими объемами я бы не лез в советчики.

Всетаки минуса не от того что перепроводят задним числом.

(16) ясень пень. от того что исправляют. причем исправления тоже друг другу рознь. уменьшение количества или сумм не ошибка. ошибка увеличение количества, изменений позиций.
еще с десяток моментов могут быть в заивисмости от бизнес-процессов

Проблема в том что вводят неправильные данные, а они могут быть хоть текущим числом, хоть с пройденным контролем остатков.

(17) +1

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

(17) >> уменьшение количества или сумм не ошибка. ошибка увеличение количества, изменений позиций.
что за бред

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

(20) у тебя - может быть.
вообще  - такая же ошибка как у манагеров

Я у себя уюрал в первую очередь изменение времени приходных накладных при изменении в текущем числе. сразу процентов 50 ошибок исчезло. в оприходовании тоже самое надо сделать! там тоже постоянно док текущего числа любят тупые менять.

запретить изменять проведенные  документы , если надо скорректировать количество - пусть вводят сторнирующие документы

Вы определитесь, что собираетесь решать контроль остатков или ввод неправильных данных.

А да. ещё и пересортица бывает. названия похожи.

(23) расход наоборот всегда оперативно надо. а приход запретить. вот основная ошибка.

(9) В УТ 10.3 есть РАУЗ?

(25) это вообще не вариант!

(29) Значит на УПП или КА нужно перейти ))

(0) Во первых если такая проблема с остатками поставь проверку остатков при не оперативном проведении.
Основные причины не списания по партиям:
1) Время документа В регистре Партии учитывается до секунды
Те если поступление 11.00 а реализация 10.59 то по партиям не спишет
2) Стоит ли в договорах галочка Вести обособленный учет товаров по заказам Если стоит и это реально не нужно тогда сними ее.
В связи с этим Могут зависать остатки по партиям в разрезе измерения заказ покупателя,
3) Сбои при проведении когда в разрезе заказа покупателя стоит объект не найден

В общем посмотри в всех разрезах. и закрой регистром ошибки

В помощь могу предложить пару обработок
закрытие регистров
http://infostart.ru/public/79662/
Поиск не проведенных по партиям
http://infostart.ru/public/19482/

(25)а ведь вы правы! просто запретить менять документы и делать стронирующие и всё!

(28) не в оперативности дело.
а в том, что эта так же ошибка безмозговости при работе с базой.
разные документы - разные способы борьбы.

(30) +1

(30)поясни

(35)и ты тоже

(37) сторнирующие доки сделают остаток по регистрам верным, но уничтожат реальную картину товарооборота в отчетах

(33) ДАААА?? а перепечатывание доков тоже идет с этими сторнирующими документами??? а в бухгалтерии они тоже отражаются??

(36) какой датой они будут делать сторно?

(38)почему ? отчеты берут данные из доков?

(39) приведи пример когда нужно "перепечатывать док"

(40) канеш текущей

да пофигу регистры! это первичка. как ты перепечатаешь торг 12? доки праватся не для того чтобы там что ошибку исправить. а потому что требуется перепечатать доки. и соответствие с бухгалтерией.

(42) ну ничего себе. да любая отгрузка.

(39)перепечатывание доков , это в смысле продажа?

(39)мне казалось что сторно - это бухгалтерский термин значит не прокатит. не всё я учел

(44)а как перепечатывают доки в случае не полного возврата?

(2) У нас есть маленькая процедура, которая вызывается в "ПриНачалеРаботыСистемы"( или "Перед", не помню щас). Она при входе пользователя проверяет дату запрета изменения, и если она меньше сегодняшней даты - то устанавливает сегодняшнюю. То есть обычные юзеры не могут поменять ничего задним числом. Если возникает такая необходимость, то специально обученный ответственный человек сдвигает дату, вносит изменения.

(45) пример

(46) конечно. да и не только продажа. все доки потом в бухгалтерию у тебя выгружаются? и чо у тебя по бух учету будет? а взаиморасчеты тоже будешь показывать с корректировками? клиента не ипут ваши проблемы. им нужны документы исправленные.

(49) Плюс к этому, автоматически скриптом каждую ночь вызывается обработка восстановления последовательности. И если последовательность "зависла" на старых датах - значит что то внесено неверно.

А я понял какой контроль нужно поставить.
1)при проведении реализации задним числом, проверять не появится ли минус в результате этого проведения. Если да, то не проводить.
2)При проведении поступления также проверять не появятся ли минуса в результате этого проведенения. Если появятся, то опять же не давать ничего делать. вот так. тогда хочешь не хочешь - придется всё исправлять им

(48) возврата может и не быть фактического. клиент за 1000км. ему произведен недогурз к примеру. или перегрузили чего то больше чем в доке.

http://subsystems.ru/blog/item/37-автоматическая-установка-даты-запрета-редактирования.html

(53) да..но доков в базе не два. а десятки. проверять надо все движения.

(49) они у вас каждый день запускают программу снова?

(54) пример : я выписал счет на тысячу куёвен , мне привизли эту тысячу из них 200 брак , я делаю на них возврат , мне нужны бабки назад , ты мне торг 12 на 1000 куёвин предоставишь?

у нас понедельное закрытие партионного учета, исправления недельной и более давности с разрешения фин дира

РАУЗ есть (у меня дома) в УТ11. Гы-гы-гы. Там в принципе только РАУЗ. А с апреля 2011 поддержка 8.1 будет закончена. Так то.

(51) у меня тогда хитромордые додумались в экселе править счет-фактуры. Только - тсссс!

(60) И нет серий.

(59) +1

(58) а клиент не хочет делать возвратную накладную а требует - нафуй мне надо возврат. я возвращаю. переделайте мне первичку и ниипет.

Eugeneer харэ тут уже демагогию разводить :)) здесь все-таки не твои клиенты-лохи, а профессионалы собрались :))

(64) берешь и переделываешь первичку , т.е. полностью сторнируешь предыдущий док , выписываешь новый . в чем проблема?

(64) Мало ли что хочет клиент - порядок нарушать никак низзя.

(64) а эти 200 куевин ты потом списанием на хознужды оформишь? :))

(66) ну да. конечно разогнались. нашим бухам такие проблемы.

(65) Мужик по уму мерекает, дело молотит ! (с)

(66) Судя по всему клиенту нужен новый документ но со старой датой. А это - непорядок

(68) просто док правят. уменьшают количество. типа они на складе (естественно клиент их привезет без бумажек). склад подтверждает что принял. все по службке происходит.

(57) "они у вас каждый день запускают программу снова"

Не понял, что ты имеешь ввиду

Да это у большинства фирм так. если вы не знаете. пойдите у своих спросите. прозреете чо там происходит.

(56)ааа. ты имеешь ввиду что если старое к примеру поступление правим, то даже, если после его проведения, остаток на текущую дату не уйдёт в минус, то он мог уходить в минус гдето между текущей датой и датой редактируемого документа и тогда уже после перепроведения, не получится распределить по партиям?

(73) Думаю имеется ввиду ситуация, когда юзер на ночь не закрыл программу и у него получилась вчерашняя дата запрета редактирвоания

(72) а если он тебе заявит что из 1000 куевин 900 брак и потребует накладную на 100 куевин, а потом скажет верни мне деньги 900 куевин обратно? и скажет что никакие 900 куевин в глаза не видел? :))

(75) приход пришел. товар переместили. по складу порядок. приход исправят вылезет минус к примеру по одному складу но не вылезет по другому. там все накатывающим комом может идти.

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

(72) и (74) бред

Единственный и верный вариант. Исправление не должны делать все!!! Первое - запрет редактирования задним каждый день в ато режиме. полный доступ тока у главбуха и его зама. исправление любое! только под контролем.

(74) то что это у большинства так, так это не значит что это правильно :))

(81) У нас, по сути, так и реализовано. Ответственный чел запрашивает разрешения на изменение у бухгалтерии.

(74) автоматизируя бардак вы получите автоматизированный бардак (с)

(81) тебе бы вместе с мавроди ммм открывать :))

(81) да всё правильно.
я как то давно список делал, но много лет прошло, сразу не найду.
ещё не всё написал.

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

Все что связано с движениями в плюс ошибок не вызывает кроме времени. Ошибки все происходят когда делают движения в расход.
Да и в 1С все контроли связаны только с расходом.

ну все ... уже бред какой-то пошел :))

самое простое - отказатся от партионого учета.

Самое правильное - для неоперативного проведения обязать явно указывать партию и ее проверять на форме на 2 даты (документа и текущей), кстати при этом им придется в явном виде вручную фигачить, уверяю что количество желающих сразу уменьшится

(62)а есть смысл сейчас пока начало года перейти на УТ11 ?

(88) у же который раз говоришь о каких то не понятных ошибках.

(81) а если в день 15-20 возвратов , тоже должен глБух все исправлять?

(91) переходи :)

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

вставлю и свои 3 копейки...
у нас тоже так сделано, как в (49), и все исправления по типу (81)
только еще и запрещено изменение уже проведенных документов даже в течении одного дня... но у нас оборот небольшой, редко что-то надо исправлять - все привыкли изначально, что их нельзя исправить и делают мало ошибок...

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

(93) если такое количество возвратов это говорит что на фирме не все гладконе с учетом а вообще с работой всей фирмы.

(97) да ну ? может количество возвратов все таки как то зависит от объема продаж в целом?

(97) ты же говорил что у тебя постоянно такое и все ништяк? :))

ошибки делсят на две категории - ошибки ввода (юзеры - тут никуда не дется), ошибки склада фактические.
Обе категории административные. И решаются наведением порядка работы сотрудников. бухов обучать, склад - управлять.

Я так и не понял, какую мысль отстаивают Eugeneer и    Aleks73 ?

(99) не 15 в день точно. бухов увольняют с кривыми руками, склад воспитывают.

(92) да все понятно же:))
если вы УВЕЛИЧИТЕ приход(Все что связано с движениями в плюс), то ничего у вас в минус не полезет, а если вы УМЕНЬШИТЕ приход (огда делают движения в расход), то могут вылезти минуса... то же самое с реализацией... если вы кол-во уменьшите, то ниче не посыпется, а если увеличите, то может по дороге что-то уйти в минус...

+(98) бывают случае что клиент выписал не то количество или вообще не тот товар + брак , не довложения . причин на самом деле куча

+(104) бывает просто передумал брать ту или иную позицию . не всегда только те  проблемы которые Вы перечислили в (100)

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

(105) да проблем сотни. я их даже не в состоянии перечислить.

(103) а что к проблемам только минусы приводят?

(102) Вам просто не доводилось сталкиваться с большими объемами продаж .

(106) А за бугром бух учета нет?

(106) мдя, я бы на твоем месте, уже просто сделал вид, что у меня вырубили инет и не появлялся бы в этой ветке :))

Лично я пытаюсь запретить перепроведение документов. Пока безуспешно.

(109) ну да конечно. 12 лет работаю. 9 лет на фирме со 120 юзерами в 1С. 3 года с 60 юзерами.

+(112) Очень старые корни последовательностей документов.

(113) а толку? :))

(110) не поверишь. у них даже нету бух программ. можешь вести бизнес в чем захочешь.

(116) и отчетности нет?

(116) у нас тоже можно вести в чем хочешь, главное сдавай отчетность в нужной форме :)) + у нас много черного нала

И бизнес там не теневой. Ошибешся в уплате налога, за тебя напомнят сколько до цента ты должен.

И при чем здесь редактирование документов?

(101) видимо такую, что нужно разрешать всем все править без каких-либо ограничений, ничего никому не запрещать, всем раздавать строго пряники, и самому потом косяки отлавливать...:)))))

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

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

самим же легче потом, хоть спросить есть с кого...

(120) видимо об этом он написал в (106)

В семерке любые контроли наделать очень просто было. там все конфы правились за час. Дописать контроль в УПП или УТ это переписать просто пипец конфу. поэтому никто этим не занимается.

(108) вопрос в сабже во всяком случае именно про минуса...
наверное, еще к каким-нибудь приводят, я о них не знаю, у меня ничего не правят:)

(121)резервировать?

если кто не в курсе в самой УТ например есть встроенные грабли которые сами делают минуса (правда не по остаткам)

у нас на предприятии полностью закрыт доступ на изменение проведенных документов , и проведение документов задним числом , в очень редких случаях глБух просит изменить что то задним числом и это уж точно не документы которые влияют на остатки товара на складах

+(121) тьху, все наоборот:)))
я поняла, против чего Eugeneer и    Aleks73

кстати минуса могут быть еще не только в разрезе товара. Вы посмотрите в разрезе серийных номеров (ГТД) какие кошмары творятся. там вообще жэсть.

(123) в УПП проще, т.к. там есть контроль по данным одного регистра, и который выполняется с помощью одного запроса.

(127) Мечта поэта.

+(128) вобщем, все надо запретить:)) такую мысль))

Пипец.
1С уже до версии 8.2 дошла, а до сих пор "заднее число" работает через заднее место. Элементарную задачу недопущения отрицательных остатков до сих пор не могут решить.

+(126) например по регистру заказы покупателей.
Например у вас две фирмы - оптовая и розничная. манагер делает заявку - НДС там автоматом по его настройкам. заява с ндс. но по рознице  нет НДС. реализацию делают без НДС (уже бух вводит). если заявка с НДС и реализация без НДС. все пипец ошибка по регистру. плюс-минусы. итоги не закрыты. база пухнет. все тормозит.

(132) А я по прежнему не пойму.

Ваш контроль остатков ниочем. Он лишь обеспечит положительный остаток но никак не "правильные данные".

(135) мысль?:)

Кто нить в курсе нафига было в регистре заказов ставку НДС делать измерением? я например до сих пор не понимаю.
А еще ставку барть из карточки. а если в базе две фирмы с НДС и без НДС то проге почему то пофигу когда она доки делает она на карточку смотрит.

(134) Т.е. заказ по одной фирме, а реализация по другой? Это - пипец.

(131) у нас такая "мечта" работает, да:)
правда, документооборот, наверное, не такой бешеный...

(139) я разве говорил про разные фирмы? одна фирма. хотя часто бывает и такое что не ту фирму выбрали в заявке.

(141) Если одна фирма - почему с НДС и без НДС ?

+(142) А если разные фирмы - закрыть заказ покупателя.

+(143) А не корректировать.

жисть-то она ведь посложнее, чем конфигурация 1С..
и "не править никогда" - не получится.
у нас в конфе-7 есть константа-разрешение править Счета, право на исправления - только СверхСуперАдминистраторов, с которых и спрашивается потом результат..
вот и нет "минусов"..
отдавать на откуп рядовым бухам, для которых в сей момент важен только остаток, и плевать на остальные регистры и документы - верный способ угробить базу.

(142) ну манагер набил заявку. все настройки берутся из карточки юзера. набил он например по ошибке на одну фирму. неправильно. заявка заполнилась с НДС. потом фирму исправили. НДС при этом в доке не меняется (можешь проверить).
Бух делает реализацию. видит какого то уя ндС. убирает галку. заявка с НДС реализация без НДС. по регу плюсы-минусы.

и наоборот также. вообще ставка НДС в карточке товара это допотопная методика. 10 лет назад в конфигурациях 77 в карточке товара валюта учета задавалась если кто помнит. вот веселуха была.

+145 лучше выслушать ультразвуковой визг бушек, чем вытаскивать базу из клоаки..
компромиссное, или прямое решение для ситуации, обычно находится

(146) Бардак.

(149) да это я все три года назад исправлял когда начинали работать. в базе 400 исправлений.

(149) бардак бардаком, а возможности накосячить должны быть минимальны...

(145)(148) Полностью согласен. Все зависит от уровня работников фирмы. Завалят базу или не завалят.

на ИС есть комплексная проверка учета - всех регистров.
экспресс процерка ведения учета. для всех конф. УТ ,КА .БП
скачайте. сформируйте и прозрейте! чо у вас по регистрам творится.

(0)У нас УПП Проблема решена.
1. Закрываем периоды от редактирования полностью.
2. Править документы в закрытом периоде запрещено.
3. При необходимости внести корректировки в старый документ, делаются корректирующие документы. Старый не трогается.
4. Каждую ночь автоматическое восстановление последовательности.

В принципе... все решалось административно.

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

(152) да однозначно завалят, если дать им такую возможность... проверено...
не будешь ты ходить и всем объяснять про особенности партионного учета, и т.д. и т.п.
и в рядовые бухи не будешь нанимать высоко огранизованных глав.бухов или вообще программистов...
все, что можно закрыть, нужно закрыть... имхо...))
и дать права узкому кол-ву юзеров...

нате http://infostart.ru/public/21398/
будет очень забавно если кто нить сюда сообщит количество строк ошибок (по всем регистрам)

(155) самый хороший пост!:)
но чтобы к этому прийти, ветку все равно стоит почитать:))

Как исправить косяк с тем что у тех пользователей у которых полные права проводят документы и в последующем остатки по партиям не совпадают с остатками товаров

а сколько ошибок по заказам покупателей и поставщикам бывает?? там тоже непаханное поле просто.

причем там ошибки не заднего числа! а именно прямые ошибки. из за того что бухи вообще не шарят как работать с программой.

(159) не назначать полные права пользователям, которые не понимают, что они делают в базе...
объяснить, как правильно сделать, в конце концов... если ошибки повторяются - штрафовать... потом уволить, если что:))

проблема в том что когда приносят документы кладовщики то просят отредактировать количество товаров. кладовщики получают документы от водителей которые развозят товар. водилы уходят на несколько дней в рейс. потому документы приносят тока минимум через 4-5 дней

Ну почему Вы не ставите знаки препинания? Не возможно читать.

(163) не надо исправлять существующие доки, вводите новые которые будут сторнировать.

Знакомая фигня, контора ЧТО ХОЧУ ТО ВОРОЧУ. Хочу меняю, хочу списываю. Потом пол зарплаты списываю с работников из-за убытков. Привет вашему руководству.
Проблема не программная, а головняковая, российская

И тут Остапов понесло ...

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

(168) это не флуд, а для многих очень актуальная проблема. Решается она комплексно: 1) описание причин приводящих к исправлению документов задним числом, полностью от этого уйти нельзя, поэтому необходимо для начала сделать этот процесс подконтрольным т.е. програмно запретить несанкционированную модификацию документа. 2) назначить ответственного например старшего оператора которому будут делать заявку на исправление. 3) регламентные процедуры восстановления последовательности, анализ не списанных партий и т.д.

всё это позволит минимизировать хаос возникающий в результате модификаций документов задним числом....

ну и конечно после всего должны быть и административные меры за грубые нарушения - штрафы и т.д.

(171) Штрафы действуют только на неквалифицированную рабочую силу. Поэтому штрафы не выход, а вот исправление в свободное от работы время вполне выход.

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