(опер.учет) Пришел к тому что необходимо полностью запретить изменения и проведения "задним числом", количество проблем вызываемое этим стало критичным. Если партионку еще можно восстановить перепроведением, и это не так страшно, то собственная схема обработки заявок и резервирования, понятное дело от вольностей "задним числом" гулять может как угодно, и это не так безболезненно...
Предположительно хочу вынести всю корректировку, для начала Приходных накладных, в отдельный документ КорректировкаДокумента, который все изменения связанные с количеством товара, а до кучи и со стоимостью партий будет проводить точкой актуальности. А проведение задним числом Приходных накладных запретить. Заодно и точную статистику собрать по подобным корректировкам.
Реализовывал ли кто-либо подобные вещи и где вылезают проблемы? Я вот думаю, например, бухгалтерия не поймет, если приход и корректировка будут во времени разнесены, особенно в разных месяцах. (Это если причина корректировки - банальная ошибка оператора).

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

Поймет. Это им не корректором баланс подмазывать

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

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

Ты удивишься, но продуманная классификация товаров, стандарт в наименовании и продуманность признаков могут существенно сократить ошибки операторов. Без прочих организационных и программных мероприятий.
 
Часто в практике встречал ситуацию, когда совершенно одинаковые товары разносили по разным позициям. "Оне другие, оне от Того-то получены...". Этот дурацкий принцип способен сильно замутить всю аналитику. Я вот даже встречался с вполне анекдотическим случаем: оприходовали горючку для погрузчиков на отдельные позиции номенклатуры, с разной ценой, конечно, а при этом горючка эта сливалась в _одну_ емкость... О как.

(6) знакомо до боли, но это пройденный этап. каталог, сами названия стандартизированны, это все даже утверждено высокими указами и работает.

Ну, значит мы одной крови :)

(5)выражаю огромное уважение =)

ап.
были ли реализации подобной схемы?

.

На мой взгляд проблема не в том как правильно организовать корректировку ранеевведенных документов в замен корректировки задним числом, а в том что боязно оставить след о таких корректировках в информационной базе.
Хоть данные из ИБ и не могут служить доказательством в суде, но как информация для оперативных мероприятий очень даже представляет ценность.
Поэтому исправляя задним числом мы "подчищаем" за собой следы.
А "аудиторский след" при всей его полезности для наведения порядка, может в "критические дни" вывести на большие неприятности.
:-))

В фискальном, бухгалтерском учете конечно подобного не будет. Но себя то запутывать не надо подчищанием следов. Кстати, никакого ч/б нет.

Ну, если все "белое и пушистое", тогда проблем нет :-)).
В качестве реализации посмотри в ТиС документы: ПоступлениеДопРасходы , Сторно .

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

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

(14) за наводку спасибо, я их пока обходил вниманием.

Если корректировать приход в плане увеличения, все будет гладко, а если уменьшать, то нужно сперва разобраться как можно оприходовать то чего нет

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

(19) нужно разделить объективные причины необходимости исправлений задним числом, например: приходуем товар на который еще не получены документы от поставщика и субъективные причины : невнимательность в том числе.
Я в своих замечания имел в виду объективные причины, с субъективными мы боремся посредством рубля :-)).
Для того, чтобы уменьшить риск ошибок оператора существует "ввод на основании".
По поставке мы оформляем документ "Заказ постащику" и когда приходит товар, то на складе приходная вводится на основании "Заказа", что существенно уменьшает возможность неправильного ввода при приемке товара.
Весь товар перемеряется и пересчитывается.
По отгрузке: начальным документом является "Заявка покупателя", которая автоматом привязывается к "Заказу поставщику", все последующие документы участвующие в цепочке документов отгрузки вводятся на основании "Заявки покупателя"
Для исключения ошибок выбора не той номенклатуры используется спец конфигурация "Классификатор номенклатуры", ответственность за ведение которого возложена на одного человека, остальные могут ввести новую позицию в справочник номенклатура, только путем выбора из классификатора.
и т.д.
Исключить человеческий фактор невозможно, но мы обязаны использовать организационно-программые методы уменьшения возможности допустить случайную ошибку.
:-))
 

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

Мы оформляем "Заказ поставщику" только когда заказ уже реально размещен на заводе. Т.е. фактически - это товары в пути.
В принципе можно для плановых целей сделать новый документ нпр "Планируемый заказ поставщику" который не будет двигать стандартные регистры и уже после "утряски" всех вопросов с поставщиком на его основании делать стандартные "Заказ поставщику", а дальше по схеме.
Для управления резервами у нас сделана внешняя обработка которая позволяет поставить в резерв нужную "заявку покупателя", в том числе и "не подтвержденную", сняв соответственно резерв с других заявок. Это тоже позволяет "рулить" не исправляя документы задним числом

кину свои пять копеек в эту тему.
по поводу 0. У нас так работают. Проблемы организационные есть и после года внедрения. Есть попытки кое-каких личностей перепровести что-то задним числом. Но если есть сила ломать бухов то сдюжишь, вони будет немеряно, эт точно.
В целом решение положительное, а если все документ будут вводиться толко на ТА то и система станет быстрее и код проще.
Правда есть тут одна идея, которую я виидел в одной системе. Суть такова.
В течении месяца докменты можно менять без восстановления последовательностей. И без перерасчета каких либо итогов. Потому что на этом промежутке документы не создают никаких критичных к этому данных. А при закрыти этого периода всякие критичные к последовательности данные рассчитываются и всяческое перепроведение в этом периоде запрещается.
Пример. В терминах ТиС
Документ приходная накладная формирует движения только по регистру отстатков и не делает по регистру партий.
расходная тоже.
Потом в конце месяца закрывается период и обработкой делаются движения по регистру партий.

(22) у меня заявки и резервирование свои самописные, с нуля. по ним "аудиторский след" в почти полной мере, все проводится только текущим временем, и функционал под это сделан.

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

(23)по моему в Управлении торговлей подобное проведение по партиям отдельным документом используется, нет? Где-то слышал уже.
а что до борьбы с бухами, тут по моему надо разделять бухучет и реальный. пусть они с бухбазе компонуют как хотят... попробуем =)

(26) А у нас наоборот в бух базе бухи работают, только в период сдачи отчетности, в остальное время все работают в тоговле, по-этому в бухню выгрузки идут тогда, когда в торге все подправлено :-))

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

Так там как раз все и происходит в навижене, а бух выгружают только результаты раз в месяц ИМХО

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

Ты посмотри проводки по док ПоступлениеДопРасходы - там их нет!
Потому что выгрузка расчеты берет из регистров, поэтому себестоимость товара выгружается уже с учетом изменений

(31) ввел тебя в заблуждение, это мы сами исправляли :-))

(32) ну вот, а я уж подумал что светлое будущее наступило =)

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

(35) именно.

mazzy, ты не мог бы прокомментировать гипотетическую ситуацию произошедшую при схеме учета Navision + бухгалтерия в 1С:
Был приход.
Через N-ное время обнаруживается что приход завысили. Количество завысили, или просто цену. Но партия этого прихода уже затронута движениями, продажей например. Вводится корректировка или сторно, как точно не знаю, пока только пытаюсь освоить принципы. Вероятно что при этом корректировка должна откорректировать все движения связанные с партионным учетом и списание партий в т.ч. Все это проводится (учитывается?) датой обнаружения ошибки. В каком виде все это может отобразиться в бухгалтерии?

(37) Я такое делал. На бухии с партионным учетом....
Все корректировки - датой обнаружения ошибки, а не прихода.
Отдельным документом - так и называется - Корректировка.
.
P.S. просто у меня партии по части товара изменить нельзя (медикаменты), а по части можно... Делается достаточно элементарно, если под ногами не путается ГП....

.

(38)Я вот тоже купил велосипед, ездиет замечательно если ноги не скользят когда от земли отталкиваюсь, все элементарно, только эти непедали под ногами путаются, непонятно зачем они вообще нужны

1C со своим ИтогиАктуальны и РассчитатьРегистры сама себе
наплодила "Проблему Заднего Числа", которая в других
системах отсутсвует напрочь. Но при известной ловкости
проблема решаема.

(41) интересно, как система выглядит после применения этой известной ловкости?

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

Проблема заднего числа существует сама по себе 1с ее не плодила, просто в разных системах существуе различный подход к ее решению, знаю что в аксапте вообще нет понятия "работы заднем числом", любой ввод информации происходит в реальном времени, может это и правельней, даже скорее всего.
Что касаетя 1с то организация работы пользователя задним числом и корректное отслеживание последсвий такой раборты целиком лешит на плечах разработчика прикладного решения, а то и на самом пользователе и "ИтогиАктуальны" , "РассчитатьРегистры" и "ГП" - инструменты созданые специально для этого,а не для того чтобы усложнить комуто жизнь.

(44) "корректное отслеживание последсвий такой раборты целиком лешит на плечах разработчика прикладного решения".
.
Вот именно. В ТиС отслеживание последствий лежит на конечном пользователе.

(46) Вот только почему благодаря "специальным созданным для
этого инструментам" люди влегкую не задумываясь один
приход могут 100 раз продать?
(0) А вообще, какие проблемы то конкретно?
Так и не понял.
Вариантов то всего вроде два: увеличили расход или
уменьшили приход.